Why Am I Getting Cloudflare Error 521: Web Server Is Down?

Error 521 is generated at Cloudflare’s edge, not by your application, so none of your own error handling runs and none of your logs necessarily record it. That is already useful information: the visitor reached Cloudflare perfectly well, so whatever is broken sits on the second hop, between Cloudflare and your server. Your browser records the response as HTTP status 521, which is not a standard status code at all — it is one Cloudflare defines for itself, so “Cloudflare 521” and “error code 521” describe the same single thing. A 521 error also only happens on a proxied record— on a DNS-only record there is no proxy in the path to be refused, and the visitor would simply see your server’s own failure instead.

Refused, not unreachable

Cloudflare defines error 521 as the origin web server refusing connections, and that word does most of the diagnostic work. A refusal is a reply. Your server, or something in front of it, received Cloudflare’s packet and sent back a TCP reset — the same thing that produces connection refused when you run curl against a port with nothing behind it. Because it is a reply rather than a wait, a 521 error appears almost instantly.

This is the cleanest way to tell it apart from its neighbours. If Cloudflare had been ignored rather than refused it would have kept retrying and reported 522 after 19 seconds. If there had been no network route to your address at all, it would have reported 523. One misconfigured firewall can produce either 521 or 522 depending on a single word in the rule: REJECT sends the reset and gets you a 521, DROP stays quiet and gets you a 522.

The cause people miss: which port Cloudflare knocks on

Before touching the firewall, check this, because it is the one cause of error 521 that originates in the Cloudflare dashboard rather than at your origin. Your SSL/TLS encryption modedecides which port Cloudflare opens a connection to at your server, and Cloudflare’s own 521 documentation states the mapping plainly:

So a server that only ever spoke plain HTTP is refusing connections on port 443 the moment the mode moves to Full or Full (strict) — nothing is bound there, so the kernel resets every incoming connection, and every request returns error 521 from then on. This is why 521 errors so often start right after somebody “improved the SSL settings”, and why the fix is either to enable HTTPS at the origin or to move the mode back. Note that this is a different failure from a bad certificate: if your origin does answer on 443 but presents a certificate Cloudflare will not accept, you get 526 rather than 521.

The four causes, in the order worth checking

1. The web server process is not running. Cloudflare lists an offlined origin application as one of the two most common causes. A crashed nginx, an httpd that failed to restart after a config reload, or a container that exited will all refuse connections while the host itself stays perfectly reachable. Check the service status and the origin error log for the crash.
2. The server is running but not on the port your mode needs. The case above: bound to 80 while Cloudflare is knocking on 443, or the reverse.
3. A firewall is rejecting Cloudflare’s addresses.The other most common cause. Security software at the origin may block legitimate connections from particular Cloudflare IPs, so Cloudflare’s advice is to allow all Cloudflare IP ranges at the origin rather than a subset. Rate limiting counts here too: a rule that trips after a burst will produce intermittent 521 errors that look like a flapping server.
4. The origin does not support HTTPS at all. Distinct from being bound to the wrong port — the service is there, but TLS was never configured. The remedy is the same as case two, with more work: install a certificate, or drop back to a mode that uses port 80 while you do.

Confirming it yourself

Both of the checks that matter can be run in a minute. The first asks your origin what it is actually listening on; the second bypasses Cloudflare entirely and knocks on the origin address directly, so a connection refusedhere reproduces the 521 error outside the proxy and proves the fault is not Cloudflare’s.

# On the origin, list what is actually listening
ss -lntp | grep -E ':(80|443)\s'

# From anywhere, knock on the origin address directly
curl -sv --connect-timeout 5 https://203.0.113.10/ --resolve example.com:443:203.0.113.10

If the direct request succeeds while the proxied one still returns a 521 error, the difference is almost always which addresses are allowed: your own IP is permitted and Cloudflare’s ranges are not. If the direct request is refused too, the origin is at fault regardless of Cloudflare, and the first two causes above are where to look.

Where 521 sits among the origin errors

The whole 52x family describes the Cloudflare-to-origin hop, and they are distinguished only by how the origin failed:

A short rule for the three: 521 is a refusal, 522 is silence, 523 is no route. When you do escalate, Cloudflare asks you to give your hosting provider the specific error code, the time and timezone it happened, and the exact URL — and to check the logs of any load balancer, cache, proxy or firewall sitting between Cloudflare and the web server, because the cause is not always in the origin’s own log. The 5xx index covers the rest of the family, and the encryption modes reference covers the setting behind the port trap above.

FAQ