Error 521: Your Origin Is Refusing Cloudflare, Not the Internet

A 521 is not generated by your server. It is generated by Cloudflare when your origin actively refuses the connection — and the distinction matters because the three causes are the process being down, a firewall dropping Cloudflare specifically, and a TLS mode mismatch, and they need entirely different fixes.

The error page says web server is down, which is true about a third of the time. The rest of the time the server is running perfectly, answering you fine, and refusing Cloudflare’s addresses in particular — which is a much more confusing situation because everything looks healthy from where you are standing. Here is how to tell the three apart in about two minutes.

What 521 means precisely
The two-minute triage
The firewall case, which is most of them
The TLS mode case
Preventing the next one
How this fits the rest of the stack
FAQ

What 521 means precisely

Cloudflare’s 5xx codes describe where the failure happened, and they are worth distinguishing because people treat them interchangeably.

520 — the origin returned something empty, malformed or unexpected. It answered; the answer made no sense.
521 — the origin refused the TCP connection outright. Connection refused, or the connection was actively rejected.
522 — the connection timed out. Cloudflare tried and got no response at all, which usually means packets are being dropped silently rather than rejected.
523 — the origin is unreachable at the network level, typically a DNS or routing problem with the origin record.
524 — the connection succeeded but the origin took too long to produce a response.

The difference between 521 and 522 is diagnostically valuable. Refused means something actively said no — nothing listening on that port, or a firewall configured to reject. Timed out means something silently dropped the packets, which is a firewall configured to drop rather than reject, or a network path problem.

So a 521 narrows it considerably: the packets reached your origin, and your origin said no.

The two-minute triage

Run these in order from a machine that is not your origin. Each one eliminates a cause.

Is the process running and listening? On the origin, check that your web server is up and bound to the port your TLS mode requires. Confirm the listening address too — a process bound to 127.0.0.1 accepts nothing from outside, and this is a common outcome of a config change.
Can you connect from outside at all? From an external host, open a TCP connection to the origin IP on port 80 and 443. If that is refused for you too, it is not a Cloudflare problem and you have a simpler outage.
If it works for you and not Cloudflare, it is the firewall. This is the single most common 521 cause. Something is allowing your address and refusing Cloudflare’s ranges.
Check the TLS mode. In Full or Full (Strict), Cloudflare connects to your origin on 443 and expects TLS. If your origin only listens on 80, that connection is refused and you get a 521 with a perfectly healthy server.
Check for automated blocking. Fail2ban, a security plugin, or a rate limiter that saw many requests from a small set of addresses — which is exactly what a proxy looks like — and banned them.

Step five deserves emphasis because it is the one that produces intermittent 521s. All your traffic arrives from Cloudflare’s addresses, so any per-IP rate limiting at your origin is effectively rate limiting your entire site, and it fires under load.

The firewall case, which is most of them

When traffic is proxied, every request to your origin comes from Cloudflare’s address ranges rather than from real visitors. Anything at your origin that makes decisions per source address is now making decisions about the proxy.

What to fix:

Allow the published proxy IP ranges in your host firewall, your cloud security group, and any application-level blocking. Do not hand-copy the list — fetch it from the published endpoint on a schedule, because it changes.
Include IPv6 ranges. A frequent partial fix allows the IPv4 list only, producing a site that works for some visitors and 521s for others, which is a genuinely difficult symptom to interpret.
Exempt proxy addresses from rate limiting and automated banning. Then do your rate limiting on the real client address, which arrives in a header the proxy sets.
Check every layer. Cloud security group, host firewall, web server access rules, and application-level blocking are four separate places that can each refuse a connection, and fixing one while another still blocks looks like the fix did not work.

The better long-term arrangement is to lock the origin down to accept connections only from the proxy — which means restricting rather than merely allowing. That prevents anyone bypassing the proxy by connecting to the origin address directly, and it means the allowlist is actively maintained because breaking it breaks the site immediately rather than silently.

The TLS mode case

This one produces a 521 on a server that is running fine, and the cause is a mismatch between what the proxy expects and what the origin offers.

Flexible — proxy connects to origin on port 80, unencrypted. Origin must listen on 80. Traffic between proxy and origin is plaintext, which is why this mode is a stopgap rather than a destination.
Full — proxy connects on 443 and requires TLS, but does not validate the certificate. A self-signed certificate is acceptable.
Full (Strict) — proxy connects on 443 and validates the certificate, which must be trusted and must match the hostname.

The 521 happens when the mode expects 443 and nothing is listening there, or when the origin’s certificate is missing in Strict mode. Both are configuration mismatches rather than failures.

The fix is to serve TLS at the origin and use Full (Strict). If you do not want to manage a public certificate for the origin — reasonable, since visitors never see it — an origin certificate issued by the proxy provider is designed exactly for this and is trusted by the proxy without being publicly valid.

Do not solve this by switching to Flexible. It makes the error go away and leaves the connection between the proxy and your server unencrypted, which is worse than the problem you started with.

Preventing the next one

521s cluster around a small number of recurring situations, and each has a durable fix.

Monitor the origin directly, bypassing the proxy. A check that goes through Cloudflare tells you the site is up; a check straight to the origin IP tells you whether the origin is up. You want both, because the gap between them is exactly where a 521 lives.
Automate the IP allowlist. A scheduled job that pulls the published ranges and updates your firewall removes the failure mode where the list goes stale and the site breaks months after anyone touched it.
Rate limit on the real client address, taken from the header the proxy sets, never on the connecting address.
Alert on certificate expiry at the origin, not only on the public certificate. In Strict mode an expired origin certificate is a full outage.
Make the server start on boot, and verify that by rebooting once deliberately rather than finding out during an unplanned restart.

The broader observation: a 521 is a symptom of the origin being a separate thing you maintain, with its own firewall, its own certificate, its own service management and its own reboot behaviour. Platforms where the deploy target is managed do not produce this class of error, because there is no separately-configured origin to refuse a connection.

How this fits the rest of the stack

Most of the causes above are origin maintenance — firewall lists, certificate renewal, service-on-boot, per-IP limits — which is real work that does not appear on any invoice until it produces an outage. The RunxBuild hosting calculator covers the part that does: the service, the database, the storage and the bandwidth. On RunxBuild the deploy target is managed rather than a server you configure: certificates are issued and renewed on deploy, the service restarts on failure, and build and runtime logs sit in the same place so a failing request and the deploy that caused it are visible together.

Useful related references:

FAQ

What does Cloudflare error 521 mean?

Your origin server actively refused the TCP connection from Cloudflare. The packets arrived and something said no — either nothing is listening on the required port, or a firewall is rejecting Cloudflare’s address ranges. It is distinct from 522, which means the connection timed out because packets were silently dropped.

Why does my site work for me but show 521 to visitors?

Almost always a firewall allowing your address and blocking Cloudflare’s ranges. All proxied traffic reaches your origin from Cloudflare IPs, so any per-source-address blocking or rate limiting at the origin applies to the proxy rather than to real visitors.

Can a 521 be caused by SSL settings?

Yes. In Full or Full (Strict) mode, Cloudflare connects to your origin on port 443 and expects TLS. If the origin only listens on port 80, that connection is refused and you get a 521 on a perfectly healthy server. Serve TLS at the origin rather than switching to Flexible, which leaves the proxy-to-origin hop unencrypted.

How do I fix a 521 caused by fail2ban?

Exempt the proxy’s published IP ranges from automated banning and rate limiting, then apply those controls to the real client address from the header the proxy sets. Because all traffic arrives from a small set of proxy addresses, per-IP limits at the origin effectively throttle your whole site and fire under load.

How do I stop 521 errors from recurring?

Monitor the origin directly as well as through the proxy, automate the IP allowlist from the published ranges rather than hand-copying it, include IPv6, alert on origin certificate expiry, and confirm the web server starts on boot by rebooting deliberately once.