🛠️ ITBlogs.pro

Cloudflare 521, 522 and 525 Errors: How to Fix Them

Oct 16, 2026 · Networking · 4 min read

Cloudflare shows its own error page when it can't get a good answer from your origin server. The 52x codes tell you where the connection failed, so read the number before you start guessing.

Code Meaning Usual cause
521 Web server is down Nothing is accepting connections on the port Cloudflare uses
522 Connection timed out Packets are dropped (firewall) or the server is overloaded
523 Origin is unreachable Wrong IP in DNS, routing problem
524 A timeout occurred Server connected but took over 100 s to respond
525 SSL handshake failed Origin doesn't speak HTTPS on 443
526 Invalid SSL certificate SSL mode is Full (strict) and the certificate is invalid/expired

521: connection refused

Cloudflare reached your IP, but nothing answered on the port. Two very common reasons:

  1. Web server is down. Check systemctl status apache2 (or nginx).
  2. SSL mode is Full or Full (strict) but nothing listens on port 443. Cloudflare connects over HTTPS, finds no listener, and shows 521. Check:
sudo ss -tlnp | grep -E ':(80|443) '

If only :80 appears, install a certificate and enable HTTPS (below).

522: timeout

Cloudflare's packets never arrive, or never get answered. Check from the outside in:

1. Is the DNS record pointing at the right server? In the Cloudflare dashboard the A record must be this server's public IP. Remember a stray AAAA (IPv6) record too.

2. Is a firewall dropping the traffic? There are two places to check: the OS firewall and your hosting provider's cloud firewall, which filters before the packets reach your machine:

sudo ufw status
sudo iptables -S | head

If the OS firewall looks fine but traffic still doesn't arrive, look at your provider's console (security groups / cloud firewall) and allow TCP 80 and 443.

3. Prove whether packets arrive at all. Trigger a request, then watch:

sudo tcpdump -ni any 'tcp dst port 80 and tcp[tcpflags] & tcp-syn != 0'

No SYN packets while a request is made = traffic is blocked or sent elsewhere. SYNs arriving but no answer = server-side problem.

Don't be fooled when testing from the server itself

Many VPS images map the hostname to a local address in /etc/hosts:

127.0.1.1  example.com

So curl https://example.com from the server never goes through Cloudflare and always "works". Test with an explicit resolve, or from another machine:

curl -I https://example.com --resolve example.com:443:SERVER_IP

Enabling HTTPS on the origin (fixes 521/525/526)

Let's Encrypt works fine behind the Cloudflare proxy because the HTTP-01 challenge goes over port 80:

sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

Port 80 must be reachable from Cloudflare while it validates. Afterwards set SSL/TLS → Overview → Full (strict) in Cloudflare. Renewal is automatic (systemctl list-timers certbot.timer), but it needs port 80 to stay open.

Never use "Flexible" mode for a real site. It sends visitor traffic to your origin unencrypted and often causes redirect loops.

524: slow responses

The server answered the connection but not the request within 100 seconds. Fix the slow script or query, or move long jobs to a background queue. Raising limits rarely helps.

Bonus: see real visitor IPs (Apache)

Behind the proxy, every request appears to come from a Cloudflare IP. Restore the real address with mod_remoteip:

sudo a2enmod remoteip
# /etc/apache2/conf-available/remoteip-cloudflare.conf
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
# ...one line for each range published at https://www.cloudflare.com/ips/
sudo a2enconf remoteip-cloudflare && sudo apache2ctl configtest && sudo systemctl reload apache2

Only trust the header from Cloudflare's published ranges, otherwise anyone can fake their IP. The ranges change occasionally, so refresh them with a small monthly script.

Quick decision tree

  1. Which code? Look it up in the table.
  2. 521: is the server up, and is port 443 listening if you use Full SSL?
  3. 522: does tcpdump see SYNs? If not, DNS or a firewall.
  4. 525/526: fix the certificate on the origin.