Cloudflare Error 521, "Web Server Is Down", means Cloudflare's edge reached out to your origin server and the origin actively refused the TCP connection. Not a timeout, not a garbled response, a refusal, usually a TCP RST packet, because nothing is listening on the port Cloudflare dialed or a firewall is rejecting Cloudflare's address ranges. The visitor's connection to Cloudflare is fine, which is why they see an error page at all. The broken hop is the one between Cloudflare and the server behind it.
What 521 actually says ¶
When a request arrives at Cloudflare's edge for a proxied site, Cloudflare opens its own TCP connection to the origin: it sends a SYN packet to the origin IP on the configured port and waits for a SYN-ACK. Three things can go wrong at this step, and Cloudflare gives each one its own error code:
- The origin refuses. A RST or an ICMP port-unreachable comes back almost immediately. That is 521. The machine at that address is alive at the network level, but the port is closed or a firewall is explicitly rejecting the connection.
- The origin stays silent. The SYN goes out and nothing ever comes back. That is Error 522, a silent drop, an overloaded accept queue, or a broken network path.
- The origin answers with something unparseable. The connection works, but the bytes that come back are not valid HTTP. That is Error 520.
The refusal in 521 is diagnostically valuable. Silence (522) could be anywhere along the path. A refusal proves packets are reaching a host that is up at the kernel level, so the problem is confined to the port, the listening process, or an explicit firewall rule.
521 vs 520 vs 522 at a glance ¶
| Code | What Cloudflare saw | Where to look first |
|---|---|---|
| 520 Unknown Error | Origin replied, but the response was not parseable HTTP. | Origin application logs, malformed or truncated responses. |
| 521 Web Server Is Down | TCP connection actively refused, RST came back fast. | Is the process running, is the port open, is Cloudflare allowlisted. |
| 522 Connection Timed Out | SYN sent, no SYN-ACK within the window, silence. | Silent firewall drops, accept-queue saturation, routing. |
Quick mental shortcut: 521 means the origin said no, 522 means the origin said nothing, 520 means the origin said something unintelligible.
Four common causes of 521 ¶
- The origin process is down. The web server crashed, was stopped for maintenance and never restarted, or failed to come back after a deploy. The operating system is still up, so it answers Cloudflare's SYN with a RST because no process is bound to the port. This is the literal reading of "web server is down" and the most common cause after a bad deploy or an out-of-memory kill.
- A firewall is rejecting Cloudflare's IP ranges. Someone tightened iptables, a cloud security group, or a fail2ban policy, and Cloudflare's published edge ranges got caught in it. One detail matters here: a rule set to REJECT sends a refusal back and produces 521, while a rule set to DROP swallows the packet silently and produces 522. Same misconfiguration, two different error codes.
- The DNS record points at the wrong IP. The origin record in the Cloudflare dashboard still points at a server that was decommissioned, resized, or rotated to a new address. Whatever machine now holds the old IP has no reason to accept connections for your site, so it refuses them. Migrations that update the servers but not the DNS record are a classic source of sudden, total 521s.
- The origin only listens on port 80 while Cloudflare connects on 443. Cloudflare's SSL/TLS mode decides which port the edge dials. Flexible mode connects to the origin over plain HTTP on port 80. Full and Full (strict) connect over HTTPS on port 443. If the origin was set up without TLS and the zone's SSL mode is Full, every edge connection goes to a port nothing is listening on, and the origin refuses all of them.
Why the owner sometimes sees the site working fine ¶
521 produces a confusing situation: visitors get the error page while the operator swears the site is up. All of these make "works on my machine" true and irrelevant at the same time:
- Different port. The owner tests the origin over HTTP on port 80, which is up. Cloudflare dials 443, which refuses. Both observations are correct.
- Different source address. The firewall allowlists the office or home IP, so the owner connects fine while every Cloudflare edge address gets rejected.
- Different path entirely. Testing from localhost, from inside the same VPC, or over an SSH tunnel bypasses the perimeter firewall that is doing the rejecting.
- Cached copy. A browser cache or service worker serves a stale page and no real request is made at all.
The only test that counts is the one that reproduces Cloudflare's exact path: a connection from an outside network, to the exact IP in the DNS record, on the exact port the SSL mode implies.
Owner checklist, in order ¶
- Confirm something is listening. On the origin, run
ss -ltnand look for the port Cloudflare connects to, 443 for Full modes, 80 for Flexible. If it is missing, restart the service and read the logs to find out why it died. - Hit the origin directly by IP from an outside network.
curl -vk --resolve example.com:443:ORIGIN_IP https://example.com/from a machine outside your network. "Connection refused" from outside while the same command works locally is the firewall signature. A working response from outside means the refusal only affects Cloudflare's ranges specifically. - Verify the Cloudflare IP allowlist at every layer. Cloud security group, OS firewall, fail2ban, any edge appliance. Cloudflare publishes its ranges at
cloudflare.com/ips-v4andips-v6, and those lists change occasionally, so a stale allowlist can start failing without anyone touching the config. - Check the DNS record's target. In the Cloudflare dashboard, confirm the origin record points at the server you think it does. After any migration, this is the record most often forgotten.
- Match the SSL/TLS mode to what the origin serves. If the origin has no certificate, Full mode will dial a closed 443 forever. The durable fix is to install a certificate at the origin, Cloudflare issues free origin certificates for exactly this, and run Full (strict). Downgrading to Flexible hides the error but leaves the Cloudflare-to-origin leg unencrypted.
- Watch the recovery. A monitor on isitdown.io probes the site with 4 independent methods every 5 minutes and opens an incident after 2 consecutive failed rounds, so you will know whether the fix held past the first manual refresh.
What visitors can do ¶
Almost nothing, and that is worth knowing so you stop trying. The refused connection is between Cloudflare and the origin, a layer no browser setting, DNS flush, VPN, or cache clear can touch. Two actions are still useful:
- Verify the scope. Run the domain through isitdown.io. If all four probe methods fail the same way, the outage is real for everyone and there is nothing local to fix. The down-for-everyone diagnostic covers the full decision tree.
- Note the Ray ID. The string at the bottom of the error page identifies the exact failed request in Cloudflare's logs. If you report the problem to the site operator, that ID is the most useful thing you can include.
FAQ ¶
Can anything on my computer cause a 521?
No. 521 is generated by Cloudflare after your request already arrived at its edge successfully. Everything client-side, your DNS, your browser, your network, has already done its job by the time the error is produced. It is purely a server-side condition.
How long does a 521 usually last?
It depends on the cause. A crashed process under a supervisor restarts in seconds and the error clears on its own. A firewall rule, a wrong DNS target, or an SSL mode mismatch persists until a human changes the configuration. A 521 that lasts more than a few minutes almost always needs operator action.
Does 521 mean the whole server is offline?
Usually not. A refused connection proves the opposite at the network level: a machine at that address is up and responding to packets. What is down is the specific service on the specific port, or the firewall is rejecting the specific source. A fully offline or unroutable server tends to produce 522 or 523 instead, because nothing answers at all.