Cloudflare Error 522 and 521: What They Mean and How to Fix Them

Cause 1: Server Overloaded (CPU or RAM Exhaustion)

The most common cause of 522 errors. If your server's CPU is pinned at 100% or it has run out of RAM, the web server process cannot handle new connections in time. This frequently happens during traffic spikes, runaway PHP processes, or unoptimized database queries.

Diagnosis

SSH into your server and run these commands:

# Check CPU and memory usage in real-time
top -bn1 | head -20

# Check system load average (should be below your CPU core count)
uptime

# Check available memory
free -m

# Find the top CPU-consuming processes
ps aux --sort=-%cpu | head -10

# Check for PHP-FPM processes stuck in a loop
ps aux | grep php-fpm | wc -l

Fix

• Immediate: Kill runaway processes: kill -9 $(pgrep -f "php-fpm" --oldest) (only if clearly stuck)
• Short-term: Reduce PHP-FPM max_children to prevent overcommitting RAM. A common formula: (Total RAM - 1GB for OS) / Average PHP process size
• Long-term: Enable PHP OPcache, install Redis for object caching, optimize slow database queries, add a CDN for static assets

Cause 2: Firewall Blocking Cloudflare IP Ranges

When Cloudflare proxies your site, all requests to your origin server come from Cloudflare's IP ranges — not from your visitors' IPs. If your firewall (iptables, nftables, UFW, CSF, or a hosting provider firewall) does not whitelist these IPs, requests get silently dropped and Cloudflare reports a 522.

Diagnosis

# Check if Cloudflare IPs can reach your web server
# Test from outside your server (or use a different machine):
curl -I --max-time 10 http://YOUR_SERVER_IP

# Check firewall rules on the server
iptables -L -n | grep -E "80|443|DROP|REJECT"

# For nftables
nft list ruleset | grep -E "80|443|drop|reject"

# For UFW
ufw status verbose

# Check if connections are being rate-limited
netstat -an | grep :80 | wc -l
netstat -an | grep :443 | wc -l

Fix

Whitelist all Cloudflare IP ranges. The current ranges are published at cloudflare.com/ips. See the dedicated section below for firewall-specific commands.

Cause 3: Keepalive Timeout Too Low

Cloudflare uses HTTP keep-alive connections to your origin server to reduce latency. If your web server closes these connections too quickly (before Cloudflare sends the next request on the same connection), Cloudflare encounters a "connection reset" and reports a 522.

Diagnosis

# Check Nginx keepalive timeout
grep -r "keepalive_timeout" /etc/nginx/nginx.conf /etc/nginx/conf.d/

# Check Apache KeepAliveTimeout
grep -r "KeepAliveTimeout" /etc/apache2/ /etc/httpd/

Fix

Cloudflare expects origin keepalive timeouts of at least 300 seconds (5 minutes). Set these values in your web server config:

Nginx:

keepalive_timeout 300;
keepalive_requests 1000;

Apache:

KeepAlive On
KeepAliveTimeout 300
MaxKeepAliveRequests 1000

Cause 4: Large Response Payload or Slow Backend

If your WordPress site is generating a page that requires heavy database queries, calling external APIs that are slow to respond, or generating very large pages (e.g., a product catalog with thousands of items), the response generation may exceed Cloudflare's timeout.

Diagnosis

# Check slow query log (MySQL)
tail -50 /var/log/mysql/slow-query.log

# Check PHP-FPM slow log
tail -50 /var/log/php-fpm/slow.log

# Check WordPress debug log
tail -50 /path/to/wordpress/wp-content/debug.log

# Check Nginx error log for upstream timeouts
grep "upstream timed out" /var/log/nginx/error.log | tail -20

Fix

• Enable WordPress debug logging: add define('WP_DEBUG_LOG', true); to wp-config.php
• Install a query monitor plugin to identify slow database queries
• Use a caching plugin (WP Super Cache, W3 Total Cache, or Redis Object Cache) to serve cached pages instead of generating them fresh
• Move expensive operations to background jobs with WP-Cron or a queue system

Cause 1: Web Server (Nginx/Apache) Stopped or Crashed

The most common cause. The web server process may have crashed due to a misconfiguration, a failed update, or an out-of-memory kill by the Linux OOM killer.

Diagnosis

# Check if Nginx is running
systemctl status nginx

# Check if Apache is running
systemctl status apache2    # Debian/Ubuntu
systemctl status httpd      # CentOS/RHEL

# Check if anything is listening on port 80/443
ss -tlnp | grep -E ":80|:443"

# Check recent system logs for OOM kills
dmesg | grep -i "oom\|killed" | tail -10

# Check the web server error log
tail -50 /var/log/nginx/error.log
tail -50 /var/log/apache2/error.log

Fix

# Start the web server
systemctl start nginx

# If it fails to start, check the config syntax
nginx -t    # Nginx
apachectl configtest    # Apache

# If OOM killed, check memory usage and reduce PHP-FPM workers
free -m
# Edit PHP-FPM pool config: reduce pm.max_children

Cause 2: Firewall Actively Rejecting Cloudflare IPs

Unlike the 522 scenario (where packets are silently dropped, causing a timeout), a 521 typically occurs when the firewall actively rejects the connection (sends a TCP RST or ICMP unreachable). This happens with deny rules or when fail2ban has banned Cloudflare IPs.

Diagnosis

# Check for Cloudflare IPs in fail2ban jail
fail2ban-client status
fail2ban-client status sshd    # or your jail name

# Check for explicit DROP/REJECT rules
iptables -L -n --line-numbers | grep -i "drop\|reject"

# Test connectivity from the server itself
curl -I http://localhost
curl -I https://localhost

Fix

If fail2ban has banned Cloudflare IPs, unban them and add them to the ignore list:

# Unban a specific IP
fail2ban-client set JAIL_NAME unbanip IP_ADDRESS

# Add Cloudflare ranges to fail2ban ignore list
# Edit /etc/fail2ban/jail.local:
# ignoreip = 127.0.0.1/8 173.245.48.0/20 103.21.244.0/22 ...

Cause 3: Server Crashed (OOM, Disk Full, Kernel Panic)

If the entire server is down (not just the web server), you will see a 521 because nothing is responding on any port. Common causes include the OOM killer terminating critical processes, the disk filling up (which prevents logging and crashes services), or a kernel panic.

Diagnosis

# Check disk usage — 100% full will crash most services
df -h

# Check memory
free -m

# Check system uptime (did it recently reboot?)
uptime

# Check for OOM kills in system log
journalctl -k | grep -i "oom\|killed" | tail -20

# Check dmesg for kernel issues
dmesg | tail -30

Fix

• Disk full: Clear log files (truncate -s 0 /var/log/large-file.log), remove old backups, clean package cache (apt clean)
• OOM: Add swap space as an emergency measure: fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
• After clearing space: Restart services: systemctl restart nginx php-fpm mysql

Cause 4: Wrong Origin IP in Cloudflare DNS

This is embarrassingly common. If you recently migrated servers, changed hosting providers, or restored from a backup, the DNS A record in Cloudflare might still point to the old server's IP address.

Diagnosis

# Check what IP Cloudflare is connecting to
# In Cloudflare dashboard: DNS → Records → check A record

# Verify from your terminal (bypassing Cloudflare):
dig +short example.com @1.1.1.1

# Verify the correct server IP
hostname -I

# Test direct connection to the correct IP
curl -I --resolve example.com:80:YOUR_CORRECT_IP http://example.com
curl -I --resolve example.com:443:YOUR_CORRECT_IP https://example.com

Fix

Update the A record in Cloudflare DNS to point to your current server's IP address. Make sure the orange cloud (proxy) icon is enabled. Changes propagate within seconds since Cloudflare controls the DNS.