Cloudflare 521 origin refused connection

What 521 means

Cloudflare 521 "web server is down" means Cloudflare tried to open a TCP connection to your origin server, and the origin actively refused it. The origin is reachable on the network (no timeout, no black hole), but nothing is listening on the expected port, or something closed the connection because of a policy.

Refusal is a different failure stage than the family:

| 521 | Origin refused the connection |

| 522 | Connection timed out |

| 523 | Origin unreachable |

| 524 | Origin did not respond in time |

| 525 / 526 | TLS layer failure |

What causes 521

• The origin server is down, crashed, or stopped, so the port has no listener.
• The web server service (nginx, Apache, LiteSpeed, IIS) stopped but the OS is up.
• The origin listens on a different port than the one stored in the Cloudflare DNS/proxy record.
• The server only binds to 127.0.0.1 instead of the public interface, so external edge connections are refused.
• A firewall or the host's security layer rejects connections from the Cloudflare edge netblocks (see the 521 firewall guide).
• IP-based blocks from a security plugin or fail2ban that never learned Cloudflare's proxy IPs were legitimate.
• A reverse proxy or load balancer in front of the app service failed and returned a reset.

Ordered fixes

1. Check status from the origin machine. Ask the host systemctl status nginx, systemctl status httpd, or the IIS console. The service can be stopped because a deploy, a reboot, or a cgroup went away.
2. Confirm the listener:

ss -tlnp | grep 443

If nothing is listening on :443, the fix starts in the web server, not in Cloudflare. If something listens on an unusual port, fix the origin record or the bind.

1. Resolve any firewall, security group, or iptables rule. Many hosts require allowlisting the Cloudflare edge ranges inside the security group, only for 443 and 80.
2. Restart the service and retest. From your terminal, curl the origin IP directly while pretending to be the site hostname:

curl -v --resolve www.example.com:443:203.0.113.25 https://www.example.com/

A clean HTTP response means the origin is healthy and the remaining question is why Cloudflare cannot reach it.

1. Check the Cloudflare IP range. If you recently switched hosting, the origin record in the dashboard may point to an IP that is no longer the server. Update the DNS record and confirm the state.
2. Watch the origin logs. Access and error logs or the host may show reset by peer, connection refused, or a rejected handshake from the edge ranges during the incident window.

Firewall notes

• The Cloudflare auth guide always links to the published IP list at cloudflare.com/ips, which is the only source you should allowlist from.
• Blocking rule examples that are too wide (for example, "drop all connections, only my office allowed") will break the proxied site with 521 while the origin looks healthy to the admin.
• After changing a rule, retest from a different network, not just from the office.

Prevention

• Add a lightweight TCP health check per 5 minutes so the next outage is caught before visitors.
• Document the origin IPs in an ops note, so the dashboard record can be checked quickly.
• Keep the web server and firewall changes in source control or at least in a script reproducible by the host.