HTTP 521 Web Server Is Down: A Cloudflare Triage Guide

Jul 28, 2026 · HTTP Status Codes

There's a mean little irony built into the 521 status code: your visitors see a branded Cloudflare error page, conclude Cloudflare is having an outage, and wait for someone else to fix it. Meanwhile the actual problem is sitting in your rack, or your VPS, or your Docker host — because 521 means Cloudflare reached out to your origin server and the origin actively refused the connection. Cloudflare is up. The edge is fine. Your web server slammed the door.

Of Cloudflare's custom error family, 521 is the most literal: "Web Server Is Down." And unlike its murkier sibling 520, it has a mercifully short list of causes.

Refused, not slow: what a 521 status code pins down

The word that matters is refused. When Cloudflare attempts a TCP connection to your origin and gets an immediate RST — the packet-level equivalent of "nothing here, go away" — that's a 521. Contrast with a 522, where the connection attempt just hangs until it times out: that points at packets being silently dropped, usually by a firewall. Refusal is fast and explicit; it means the machine is reachable and responding to packets, but nothing is listening on the port Cloudflare is calling, or something is deliberately rejecting it. That distinction cuts your search space in half before you've run a single command.

The three usual reasons your origin refuses Cloudflare

One: the web server isn't running. nginx or Apache crashed, was stopped for maintenance and never restarted, failed to come back after a reboot, or died during an unattended package upgrade. The machine is up (so it sends RSTs), but no process holds port 443. This is the most common cause and the fastest to confirm.

Two: a firewall is rejecting Cloudflare's ranges. With Cloudflare proxying, all traffic to your origin arrives from Cloudflare's edge network, not from visitors' addresses. A security tool that decides those IPs look suspicious — fail2ban banning them after a burst of traffic, a hosting provider's DDoS protection, an overzealous iptables rule set to REJECT — blocks your entire site in one move. If the firewall REJECTs, you get 521; if it silently DROPs, the same mistake produces 522 instead.

Three: a port or TLS mismatch. Cloudflare connects to the origin on standard ports, and its SSL mode determines whether it speaks TLS. If your origin only listens on port 80 while Cloudflare's mode ("Full" or "Full (strict)") calls port 443 — or the origin's TLS setup is broken so the listener rejects handshakes — the result surfaces as 521. This is the classic day-one misconfiguration for sites newly onboarded to Cloudflare, and also the classic post-incident regression when someone changes the origin's ports during unrelated work.

Confirming the diagnosis from the origin side

Three commands on the origin box settle it. First, is anything listening? ss -tlnp | grep -E ':(80|443)' — no output means cause one; restart the web server and you're done. Second, does the server answer locally? curl -skI https://localhost/ -H 'Host: yoursite.com' — success locally plus failure from outside means the process is fine and the block is in between, which is the firewall. Third, check the firewall state: iptables -L -n (or your provider's security group console) looking for REJECT rules that could catch Cloudflare's published IP ranges, and fail2ban-client status if fail2ban runs, checking its ban list for Cloudflare addresses. If all three look clean, verify the Cloudflare side: the DNS record's proxy status, the SSL mode, and whether the origin IP Cloudflare has on file is actually your current server — a 521 after a server migration very often means the DNS record still points at the old box, which is up but empty.

Getting back online, step by step

1. Restart the web server if it's down (systemctl restart nginx) — then find out why it was down before closing the incident. journalctl -u nginx --since "-2 hours" usually names the culprit: OOM kill, config error on reload, certificate file missing at startup.
2. If it's a firewall block, allow Cloudflare's published IP ranges explicitly, and configure fail2ban to read the real client IP from the CF-Connecting-IP header instead of banning the edge. Never solve this by turning the firewall off.
3. If it's TLS or port mismatch, either fix the origin listener or set Cloudflare's SSL mode to match reality — and prefer fixing the origin, because downgrading the mode to "Flexible" leaves the Cloudflare-to-origin leg unencrypted.
4. After recovery, watch for recurrence. A 521 that returns nightly at the same hour is a scheduled job — log rotation reloading a broken config, a backup script stopping services — and the timestamp pattern in your monitoring will convict it.

Does a 521 hurt your search presence?

To Googlebot, a 521 is just another 5xx server error, and the usual arithmetic applies: minutes or hours of downtime are forgotten, but a crawl rate reduction kicks in if errors persist across days, and weeks of unavailability start pulling URLs from the index. What makes 521 worth extra paranoia is that it's usually total — the origin refuses everything, so every page on the site errors at once, including for crawlers. There's no partial-failure grace here. It's the difference between one aisle being closed and the whole store being dark.

Hearing about the next one before your customers do

A 521 is the single easiest error to detect automatically: the site is down for everyone, so any external check catches it on the first attempt. The only question is whether you have that check. Get alerted the minute your site goes down with an uptime monitor probing from outside your own network — and ideally add a second check against the origin's IP directly, bypassing Cloudflare. The pair tells you instantly which side of the edge broke, which is exactly the question a 521 makes everyone waste their first fifteen minutes arguing about.