How to Fix Cloudflare Error 521: Don't Clear the Cache, Trace the Path

When your site suddenly shows Web server is down — Error code 521, the first instinct is often to clear the Cloudflare cache or change DNS. But 521 usually has nothing to do with those settings.

It means: Cloudflare can receive the visitor’s request, but the origin refused Cloudflare’s connection. The problem usually lands on the origin web service, a firewall, a cloud security group, a WAF, or a load balancer sitting in front of the origin.

So when handling a 521, the first things to look at aren’t the browser or the cache, but two things: whether the web service is actually listening on its port, and whether the server is rejecting Cloudflare’s IPs. Cloudflare lists “origin web server offline” and “Cloudflare requests being blocked” as the most common causes — see the Error 521 docs.

If you’re only a visitor with no server or Cloudflare dashboard access, you can’t fix 521 locally. Save the error page URL, the time it happened, and the Ray ID, then send them to the site administrator or hosting provider. Cloudflare support also only assists domain owners with troubleshooting.

First confirm the error code: 521 is different from other 5xx

Cloudflare’s 5xx pages look very similar, but the troubleshooting directions differ a lot. The keyword for 521 is connection refused. If the reality is a connection timeout or a slow application response, you should follow the 522 or 524 path instead of blindly adding IPs to an allowlist. The official explanations for each error code are in Cloudflare 5xx errors.

Error code	What it actually means	Where to look first
521	Origin refused Cloudflare’s connection	Web service, 80/443 listening, firewall, WAF, ban rules
522	Connection or initial response timed out	Network path, server load, connection queue, timeout settings
523	Cloudflare can’t reach the origin	DNS, routing, origin IP reachability
524	Connected to origin, but processing took too long	PHP, database, APIs, long-running tasks
525 / 526	TLS handshake or strict certificate validation failed	443, TLS, certificate chain, cert domain and validity

The 5 most common causes of 521

The web service isn’t running, or isn’t listening on the port at all

After Nginx, Apache, or Caddy stops, Cloudflare can’t reach the origin and returns 521. The service stopping isn’t always someone shutting it down manually: a bad config on deploy, a full disk, exhausted memory, wrong permissions on a certificate file, or the system killing the process can all take 80 or 443 out of service.

If you have SSH access, run the commands below on the server first. They only inspect state and won’t change any config.

# Is the service still running; pick per your environment
sudo systemctl status nginx --no-pager
sudo systemctl status apache2 --no-pager

# Are 80 and 443 actually being listened on by a process
sudo ss -ltnp '( sport = :80 or sport = :443 )'

# Check recent errors, and whether disk / memory is exhausted
sudo tail -n 100 /var/log/nginx/error.log
free -h
df -h

On Debian / Ubuntu the Apache service is usually named apache2; on RHEL / CentOS it may be httpd.

If the service state looks wrong, check the logs before fixing. After changing Nginx config, run sudo nginx -t first and reload only after it passes; for Apache, run sudo apache2ctl configtest first. Don’t restart repeatedly at the first sign of trouble. A restart may temporarily bring the page back, but it can also bury clues like OOM, port conflicts, and bad deploys.

A firewall, cloud security group, or host WAF blocked Cloudflare

With the Cloudflare proxy enabled, the origin doesn’t see each visitor’s real IP but Cloudflare’s egress IPs. To a firewall, those IPs may generate a large number of connections in a short window. If UFW, iptables, a cloud security group, a host provider’s WAF, or Fail2ban triggers a ban as a result, Cloudflare’s requests get rejected and you end up seeing 521.

It’s easy to go to two extremes here: either allowlist a single Cloudflare IP, or open the origin’s 80/443 to the entire internet. Neither is right. The correct approach is: on only the web ports you need, allow the complete IPv4 and IPv6 ranges Cloudflare officially publishes. The IP list should come from the official Cloudflare IP page — don’t copy a static list from an old tutorial.

If you use UFW, the rules look like this. The example CIDR is only a syntax demonstration, not a complete allowlist:

# Example: allow one Cloudflare IPv4 range to reach 80 and 443
sudo ufw allow from 173.245.48.0/20 to any port 80 proto tcp
sudo ufw allow from 173.245.48.0/20 to any port 443 proto tcp
sudo ufw status numbered

Changing UFW isn’t enough. Cloud servers usually have at least two layers of rules: the OS firewall and the cloud provider’s security group. If there’s also a WAF, DDoS protection, a load balancer, or a control panel like aaPanel in front of the site, check whether those layers are logging DROP, REJECT, bans, or rate limits too.

Fail2ban, a WordPress security plugin, or a rate-limit rule caught Cloudflare by mistake

This is one of the harder 521 cases to spot. When the real visitor IP isn’t restored correctly, Nginx, Apache, WordPress security plugins, and WAFs may see every user as one of Cloudflare’s few egress IPs. Once a user trips login protection or a rate limit, the security rule bans Cloudflare rather than that user; the result is that other visitors on the same egress get hit too.

Don’t turn off all your security features because of this. The correct order is: trust only proxied requests coming from Cloudflare’s ranges, then use CF-Connecting-IP as the real client address to do rate limiting, auditing, and banning by real IP. If you unconditionally trust this header from all sources, an attacker can bypass Cloudflare and spoof IPs. Configuration details are in Restoring original visitor IPs.

A common Nginx config looks like this. Production needs all of Cloudflare’s officially published IPv4 and IPv6 ranges filled in; configuring only one example range leaves the risk of intermittent 521.

# For example: /etc/nginx/conf.d/cloudflare-realip.conf
set_real_ip_from 173.245.48.0/20;
# Continue adding the rest of Cloudflare's official IPv4 / IPv6 CIDRs

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

After saving, run sudo nginx -t first and reload only after the syntax checks out. Apache sites should use mod_remoteip and RemoteIPTrustedProxy. Cloudflare no longer maintains the old mod_cloudflare and recommends switching to mod_remoteip.

The SSL/TLS mode and the origin port don’t match

If Cloudflare’s SSL/TLS mode is Full or Full (Strict), the origin should accept HTTPS connections on 443; with Flexible, the origin usually needs to serve HTTP over 80. In its 521 troubleshooting docs, Cloudflare explicitly requires the origin application to listen on the port that matches the SSL/TLS mode.

Cloudflare SSL/TLS mode	Origin requirement	Practical advice
Flexible	HTTP/80 available	Fine for temporary compatibility, not for long-term production
Full	HTTPS/443 available, origin has a certificate	Allows self-signed or Origin CA, but doesn’t validate certificate identity. See Full encryption mode.
Full (Strict)	HTTPS/443 available, certificate valid, trusted, and matching the domain	Preferred for production.

When 443 isn’t listening or is rejected by a firewall, it can still show up as 521. Conversely, if 443 is already reachable but the TLS negotiation or strict certificate validation fails, the error usually turns into 525 or 526 instead. Separating the two kinds of problems saves a lot of detours.

Something’s wrong with the load balancer, containers, or port configuration

In the cloud, the origin isn’t always a single VM. The connection path may be Cloudflare → load balancer → Ingress → container. A load balancer that pulled all backends out, an Ingress with no available Pod, a backend security group rejecting traffic, or health checks that keep failing can all leave Cloudflare with a 521 in the end.

Trace this kind of problem along the path: check the load balancer’s listeners and target health first, then the security group and Ingress controller, and finally the Pod and application logs. Cloudflare specifically notes that the root cause isn’t necessarily in the web server logs — it may live in an intermediate load balancer, cache, proxy, or firewall.

Also, the Cloudflare proxy doesn’t support every port. A normal website is best served over 80/443; if the URL uses another port, check the official port list first to confirm it’s supported. Cloudflare supports several sets of HTTP/HTTPS ports, but some non-standard ports aren’t cached by default.

A troubleshooting order from lowest to highest cost

521 often drags on for a long time — not because the problem is complex, but because the troubleshooting order is wrong. Checking from lowest to highest cost below usually narrows the range faster.

Order	What to check	Normal state
1	Nginx, Apache, Caddy, and the application process	Service running, 80/443 in `LISTEN`
2	Service logs, memory, disk, OOM records	No repeated restarts, full disk, or process killed by the system
3	UFW/iptables, cloud security group, WAF, Fail2ban	Cloudflare’s complete IP ranges aren’t rejected, banned, or rate-limited
4	Cloudflare SSL/TLS mode and origin listening	Flexible maps to a working 80; Full / Strict maps to a working 443
5	Real visitor IP configuration	Trust only the Cloudflare proxy, then enforce security rules by real IP
6	Error data on the Cloudflare side	521 stops increasing, Ray ID correlates with origin logs

In the Cloudflare dashboard, open Analytics → HTTP Traffic (shown as Analytics & Logs on some accounts) and filter 5xx by Edge status code or Origin status code. It can help you see clues like the affected URLs, sources, and Cloudflare data centers. Error Analytics is based on a ~1% traffic sample; if Log Explorer is available on your account, you can also look up a single request using the Ray ID from the error page.

What to do when you don’t have server access: working with your host

Shared hosting, managed WordPress, or SaaS site-builder users usually can’t see the firewall. A ticket that just says “the site won’t open” makes it hard for them to locate the issue quickly. Cloudflare recommends providing the error code, the time and time zone it occurred, and the full URL; the Ray ID should be included too.

You can use the passage below directly:

Since YYYY-MM-DD HH:MM UTC, visiting https://example.com/path returns Cloudflare Error 521 — Web server is down. Please check the origin web service, the host firewall / WAF / Fail2ban, the load balancer, and any upstream proxies, and confirm they aren’t rejecting or rate-limiting Cloudflare’s official IPv4/IPv6 ranges. Relevant Ray ID: fill in the Ray ID. The Cloudflare SSL/TLS mode is fill in the mode; please also confirm the listening state of origin 80/443 and the backend health status.

This passage doesn’t assume a root cause, but gives support all the information they need to locate the issue.

After fixing it, don’t just check whether the homepage loads

Intermittent 521 is the easiest to misjudge as “already fixed.” One successful refresh may only mean the request happened to hit a node without the problem, or the auto-ban rule temporarily didn’t trigger. Complete verification at three layers is recommended:

Verification location	How to check	Passing criteria
Origin host	Check service, ports, and health checks	Service stable, expected ports listening normally
Network boundary	Check security group, firewall, WAF, and rule logs	Cloudflare ranges reachable, origin not unnecessarily exposed
User request	Visit via the domain with the Cloudflare proxy enabled, watch the Cloudflare error trend	No new 521, and Ray ID can correlate logs when needed

Going forward, bring Cloudflare’s official IP list into configuration management, restore the real visitor IP correctly, and set up alerts for service state, certificate expiry, disk, memory, load balancer health, and the 521 error rate. If your origin isn’t suited to exposing inbound ports to the public internet, you can also evaluate Cloudflare Tunnel: it lets the origin establish outbound-only connections, reducing the need for a public IP and inbound listening.

FAQ

Can clearing the Cloudflare cache fix 521?

Usually not. The cache won’t make an already-stopped web service listen on 80/443 again, and it won’t lift a firewall ban on Cloudflare.

Can turning off the Cloudflare proxy (orange cloud to gray cloud) fix it?

Changing the record’s proxy status from “Proxied” (orange cloud) to “DNS only” (gray cloud) can serve as a short-term diagnostic, helping you judge whether the problem lies in the Cloudflare-to-origin segment. But it bypasses Cloudflare’s proxy and protection and shouldn’t be a long-term solution. The problem should still be solved on the origin service and allow rules.

Why does 521 appear only in some regions, or only occasionally?

Common causes include: only some Cloudflare ranges were allowed, a WAF or Fail2ban banning intermittently, a load balancer with only some backends unhealthy, or certain egress IPs being rejected by a security device. Correlating the time of occurrence and the Ray ID against firewall, load balancer, system, and application logs usually reveals a pattern.

Does 521 mean the server is down?

Not necessarily. A stopped web service causes 521, but even when the server is online, a firewall, cloud security group, WAF, or rate limit actively rejecting Cloudflare will return 521 too.

Summary

The key to 521 isn’t “Cloudflare is broken” but that the origin refused Cloudflare. Starting from service state, port listening, firewall, and Cloudflare IP allowlisting, then checking the TLS mode and the real visitor IP, is usually far more effective than clearing the cache or repeatedly toggling the proxy.

When the problem can’t be found right away, don’t judge by the refresh result alone. Put the time of occurrence, the URL, the Ray ID, the SSL/TLS mode, and the origin, firewall, and load balancer logs from the same window together — only then can you tell whether it’s a service crash, a mistaken rule ban, or an intermediate-path issue.