Cloudflare 521 and firewall blocks

Why a firewall causes 521

Cloudflare routes traffic through its own front edge, so the origin only ever sees the edge IPs, not your visitor's public IP. If a firewall or security group on the origin does not explicitly allow the Cloudflare ranges, those connections are refused (showing as 521) or dropped silently (showing as 522).

This is the most common cause of a 521 that appears only after you switch a record to proxied: the origin works fine for a direct DNS-only test from your office, because your office IP is allowed, while the edge address is not.

| Symptom | Likely firewall state |

| Works directly, fails through Cloudflare | Edge ranges not on the allowlist |

| Works some countries, fails others | Partial allowlist or geo filter |

| 522 instead of 521 | Packets dropped, not refused |

| Works after downtime, then 521 | Dynamic IP rule changed |

Allowlist the Cloudflare ranges

1. Open the current list at the only official source: https://www.cloudflare.com/ips/. Cloudflare keeps this list current and warns that the IP set changes over time.
2. Add every IPv4 and IPv6 range to your host firewall (AWS Security Group, DigitalOcean, hosting "IP filter", iptables, or CSF). Each rule opens TCP ports 80 and 443 only, not the file system.

Example iptables rows:

iptables -A INPUT -p tcp --dport 443 -s 173.245.48.0/20 -j ACCEPT
iptables -A INPUT -p tcp --dport 80  -s 103.21.244.0/22 -j ACCEPT

1. Put TCP 443 and 80 before any catch-all drop rule. On hosts with a default deny policy, add these rules to the top of the chain.
2. Add a drift mechanism. Because the ranges change, script the allowlist next to the host config so a future list edit stays in sync. Some control panels do this automatically for Cloudflare; do not rely on it silently.
3. Re-test from outside your office network using a curl request, then check the site behind the proxied record to confirm the 521 has cleared.

Test before and after

Before you change rules, capture the failure state:

curl -I https://www.example.com/
# 521/522 or a TCP error

After the rule, the same curl should return HTTP/2 200 with a Cloudflare response header (cf-ray). If it still fails, go back to the origin, because a firewall is not the only thing that refuses edges.

Extra cause: security plugins

If you use a host security plugin, fail2ban, or IP-denylist system, check whether it monitors the Cloudflare ranges as one address source. Everything that your office IP is allowed for, the edge must also be allowed for, except for the visitor's real IP, which you have lost anyway because of proxying.

Keep the allowlist narrow

Allow only the Cloudflare ranges on the public web ports. Introducing "allow anything from the internet" as the fix defeats the purpose of the firewall and keeps DDoS sources valid. The correct target is the documented edge list, nothing else.

Prevention

• Subscribe to Cloudflare's IP range endpoint or monitor the known ranges in your ops pipeline.
• After any hosting or firewall migration, re-run the range sync as part of the checklist.