Cloudflare Error 521: Web Server Is Down. Why the Origin Refuses Cloudflare

Cloudflare's documentation defines it plainly: "Error 521 occurs when the origin web server refuses connections from Cloudflare" (Cloudflare: Error 521). The visitor sees Cloudflare's "Web server is down" page with a Ray ID, and the HTTP status is 521. Cloudflare itself works; the hop from Cloudflare to your server does not.

"Refuses" is precise: the origin host is reachable on the network and answers the TCP connection attempt with a rejection (a TCP RST, usually because nothing listens on the port, or a firewall rule rejects it). Compare the neighbours:

• 522 Connection timed out — the origin never answered the connection attempt.
• 523 Origin is unreachable — there is no network route to the origin's IP.
• 525 SSL handshake failed — the TCP connection worked, TLS did not.

The firewall case has a classic trigger. All proxied traffic arrives from Cloudflare addresses, so a brute-force detector that reads raw connection IPs sees one "client" making thousands of requests and bans it. Configure the web server to log the visitor IP from the CF-Connecting-IP header (nginx: set_real_ip_from for each Cloudflare range plus real_ip_header CF-Connecting-IP;) so bans hit attackers, not Cloudflare.

1. Reproduce while bypassing Cloudflare. Connect to the origin IP directly with the right host name:

   curl -sv --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null
   # * connect to 203.0.113.10 port 443 failed: Connection refused

   "Connection refused" reproduces 521. Repeat on port 80 with http:// if you use Flexible.
2. Check the listener on the origin.

   ss -ltnp | grep -E ':(80|443) '
   systemctl status nginx --no-pager

3. Check firewall rules for drops or rejects that cover Cloudflare:

   iptables -S | grep -E 'DROP|REJECT'
   nft list ruleset | grep -iE 'drop|reject'
   fail2ban-client status

   Compare banned addresses with curl -s https://www.cloudflare.com/ips-v4 and curl -s https://www.cloudflare.com/ips-v6.
4. Match the SSL/TLS mode under SSL/TLS, Overview in the dashboard with what the server offers.
5. Ask the host. Cloudflare recommends sharing the error code, the time with time zone and the failing URL with your hosting provider; managed hosting often has its own firewall in front of your server.

A 521 page is about the website's own server, so nothing on your device causes it or fixes it: clearing the cache, changing DNS or switching browsers will not help. The page tells you which part failed. The browser-to-Cloudflare leg is marked as working, the "Host" box shows the error, and the Ray ID at the bottom identifies your request in Cloudflare's logs. If you can reach the site owner, send them that Ray ID and the time you saw the error. Then wait and retry: a 521 caused by a restart or a deploy often clears within minutes, while one caused by a firewall rule lasts until the owner changes it.

curl -s -o /dev/null -w '%{http_code}\n' --resolve example.com:443:203.0.113.10 https://example.com/
# 200
curl -sI https://example.com/ | grep -iE '^(HTTP|server|cf-ray)'
# HTTP/2 200
# server: cloudflare

The first command proves the origin accepts connections; the second, that the proxied site works end to end. Error Analytics in the dashboard (filter by edge status code 521) should drop to zero. The HTTP status checker shows the status your public URL returns from outside your network.

• Cloudflare 523 — no route to the origin
• Cloudflare 522 — the origin did not answer in time
• Cloudflare 520–530 overview — every 52x code side by side
• ECONNREFUSED — the same refusal seen by an application
• Cloudflare 526 — the origin certificate failed validation
• Cloudflare 1003 — a Cloudflare IP opened directly instead of the host name