Debugging Cloudflare 522 Errors: A Step-by-Step DNS Audit

The Dreaded Error 522: Connection Timed Out

If you manage a web application behind Cloudflare, you've likely encountered the Error 522: Connection Timed Out screen. Unlike a 502 Bad Gateway (which means your server actively rejected the connection) or a 404 (file not found), a 522 means Cloudflare's edge servers reached out to your origin server and heard absolutely nothing back for 15 seconds.

In my decade of managing enterprise infrastructure, a 522 error is rarely a random fluke. It almost always points to a fundamental misconfiguration in your DNS routing, your firewall, or your server's network stack. Here is the exact audit checklist I use to debug 522s for clients.

Step 1: Audit the A Record IP Address

The most common cause of a 522 is a silent mismatch between Cloudflare's DNS records and your actual server IP. This frequently happens after migrating hosts (e.g., moving from DigitalOcean to AWS) and forgetting to update the proxy records.

The Fix:

1. Log into your hosting provider and find the absolute, true public IPv4 address of your current server.
2. Log into Cloudflare, navigate to the DNS tab.
3. Verify that the A record pointing to your root domain exactly matches the server IP.
4. If you recently changed this IP, ensure that the cloud icon is orange (Proxied). If it's grey (DNS only), you aren't actually using Cloudflare's CDN.

Step 2: The Firewall Whitelist Problem

Cloudflare acts as a reverse proxy. This means that to your origin server, every single incoming HTTP request appears to be coming from a Cloudflare IP address, not the end user's IP.

If you have a strict firewall (like ufw on Ubuntu or an AWS Security Group) configured to block rapid requests or unknown IPs, it might start silently dropping Cloudflare's traffic. When the firewall drops the packets instead of rejecting them, Cloudflare waits for 15 seconds and throws a 522.

The Fix: You must explicitly whitelist all of Cloudflare's IP subnets in your origin server's firewall. Cloudflare publishes their IP ranges at https://www.cloudflare.com/ips/.

If you are using ufw on Linux, you can run a script to allow these ranges:

for i in $(curl -s https://www.cloudflare.com/ips-v4); do ufw allow from $i to any port 443; done
for i in $(curl -s https://www.cloudflare.com/ips-v6); do ufw allow from $i to any port 443; done

Step 3: SSL/TLS Encryption Mode Mismatch

Cloudflare offers several SSL modes: Flexible, Full, and Full (Strict). A mismatch here will cause routing failures that masquerade as timeouts.

If your Cloudflare SSL is set to Full, Cloudflare will attempt to connect to your origin server over port 443 (HTTPS). If your origin server only has Apache/Nginx listening on port 80 (HTTP), the connection will simply time out, resulting in a 522.

The Fix:

1. Check your origin server. Is it configured with an SSL certificate (even a self-signed one) and actively listening on port 443?
2. If YES: Set Cloudflare to Full or Full (Strict).
3. If NO (your server only listens on port 80): Set Cloudflare to Flexible. (Note: I highly advise against Flexible mode for security reasons. Always install at least a Let's Encrypt cert on your origin).

Step 4: Server Resource Exhaustion

Finally, if your DNS is correct, firewalls are open, and SSL is matched, the problem is likely your server itself.

If your origin server is under a heavy load (e.g., 100% CPU utilization or out of RAM), the web service (Nginx/Apache) might be alive but unable to spawn a worker process to answer Cloudflare's request within 15 seconds.

The Fix: SSH into your server and run htop or top. Look for CPU spikes or memory exhaustion. Check your web server error logs (/var/log/nginx/error.log) to see if worker connections are maxing out.

By methodically checking DNS, Firewalls, SSL, and Server Load, you can reliably isolate and resolve the root cause of a Cloudflare 522 error.