Troubleshooting Cloudflare Error 521: Web Server is Down (CSF & IPTables Rate Limiting)

Cloudflare’s Error 521: Web server is down indicates that Cloudflare was able to connect to the origin server on port 80 or 443, but the origin server actively refused the connection. While this is often attributed to a crashed Apache or Nginx service, experienced system administrators know that a perfectly healthy web service can still return 521 errors.

The culprit? Aggressive rate limiting and connection tracking dropped by ConfigServer Security & Firewall (CSF) or underlying iptables rules. Because Cloudflare acts as a reverse proxy, all traffic to your origin server arrives from a small pool of Cloudflare IP addresses. If your server is configured to block IPs making too many concurrent connections, it will quickly ban Cloudflare’s proxy IPs, resulting in a 521 error for legitimate end-users.

Here is a deep-dive technical guide into diagnosing and resolving this exact scenario using raw Linux logs, terminal commands, and CSF configuration adjustments.

1. Confirming the Web Server is Actually Alive

First, eliminate the obvious. Ensure that your web server is running and listening on the expected ports. We’ll use ss (socket statistics) rather than netstat:

ss -tulpn | grep -E ':(80|443)'

You should see output indicating your web server (e.g., Nginx, Apache, or LiteSpeed) is binding to these ports:

tcp   LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=1234,fd=6))
tcp   LISTEN 0      511          0.0.0.0:443       0.0.0.0:*    users:(("nginx",pid=1234,fd=7))

If the service is up, check if you can make a successful local HTTP request bypassing the external network:

curl -I -H "Host: yourdomain.com" http://127.0.0.1/

If it returns HTTP/1.1 200 OK, the web server is fine. The drop is happening at the firewall layer.

2. Diagnosing CSF / IPTables IP Drops

When CSF blocks an IP due to rate limiting or port flooding, it logs the event in /var/log/lfd.log or the system’s messages log. Let’s search for Cloudflare’s known IPv4 ranges in the LFD (Login Failure Daemon) block logs.

grep -E "173.245.|103.21.|103.22.|104.15.|104.16." /var/log/lfd.log

Alternatively, you can query iptables directly to see if any Cloudflare subnets are actively trapped in the DROP chain:

iptables -L -n | grep "104.21."

If you see an output like this, Cloudflare has been jailed:

DROP       all  --  104.21.55.122       0.0.0.0/0

Checking Kernel Connection Tracking (CT_LIMIT)

A common misconfiguration is a low CT_LIMIT in CSF. This tracks concurrent connections per IP. Since all traffic is tunneled through Cloudflare, the concurrent connection count from a single Cloudflare IP can easily exceed 300+.

You can observe active connections per IP using:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 10

If you see Cloudflare IPs heavily dominating this list and subsequently getting blocked, CT_LIMIT is your prime suspect.

3. Resolving the Issue in CSF

To permanently resolve this, you must configure CSF to ignore Cloudflare’s proxy IPs and adjust connection tracking.

Step A: Whitelist Cloudflare IPs

Cloudflare publishes a list of their IPv4 and IPv6 ranges. You need to add these to /etc/csf/csf.allow and /etc/csf/csf.ignore.

Create a quick bash script to fetch and apply these automatically:

#!/bin/bash
# Update Cloudflare IPs in CSF
CF_IPS_URL="https://www.cloudflare.com/ips-v4"
CF_IPV6_URL="https://www.cloudflare.com/ips-v6"

echo "# Cloudflare IPs" > /tmp/cf_ips.txt
curl -s $CF_IPS_URL >> /tmp/cf_ips.txt
curl -s $CF_IPV6_URL >> /tmp/cf_ips.txt

# Add to csf.allow and csf.ignore if not present
while read ip; do
    if ! grep -q "$ip" /etc/csf/csf.ignore; then
        echo "$ip" >> /etc/csf/csf.ignore
        echo "$ip" >> /etc/csf/csf.allow
    fi
done < /tmp/cf_ips.txt

# Restart CSF and LFD
csf -r
systemctl restart lfd

Note: Adding IPs to csf.ignore tells the LFD daemon completely bypass them during blocking checks.

Step B: Adjusting CT_LIMIT and PORTFLOOD

Open /etc/csf/csf.conf and review your rate-limiting rules.

nano /etc/csf/csf.conf

Find the CT_LIMIT variable. If you prefer not to globally whitelist Cloudflare (not recommended), you would at least need to raise this significantly:

# Previously set to 150
CT_LIMIT = "0" 

(Setting CT_LIMIT = "0" disables it entirely, relying instead on your web server’s rate limiting, which is safer when behind a WAF like Cloudflare).

Additionally, verify PORTFLOOD. It limits connections per time interval:

PORTFLOOD = "80;tcp;100;5,443;tcp;100;5"

If you are behind Cloudflare, PORTFLOOD on ports 80 and 443 will almost certainly trigger falsely. Disable it or remove ports 80/443 from the string.

4. Web Server Side: Restoring Visitor IPs

Even with CSF fixed, if your web server logs only show Cloudflare IPs, it might hit Nginx or Apache’s internal limit_req or mod_evasive constraints. You must restore the original visitor IP.

For Nginx, edit nginx.conf and add:

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
# Add the rest of the CF IPv4 and IPv6 blocks...
real_ip_header CF-Connecting-IP;

For Apache, ensure mod_remoteip is enabled:

RemoteIPHeader CF-Connecting-IP
RemoteIPInternalProxy 104.16.0.0/13
RemoteIPInternalProxy 104.24.0.0/14
# Add the rest...

The Hardware Constraint: When to Upgrade

If you are dealing with extremely high-traffic WooCommerce sites or large-scale proxy setups, standard shared hosting or low-tier VPS environments often lock you out of modifying csf.conf directly or restrict kernel-level connection tracking. In such scenarios, bypassing shared server constraints requires moving to bare-metal Dedicated Servers. Specifically, utilizing low-latency regional options like Dedicated Servers in Pakistan for South Asian audiences gives you absolute root control over kernel parameters (sysctl), iptables, and hardware firewalls to process thousands of concurrent connections effortlessly without arbitrary WAF or rate-limit blocks.

Summary

When faced with a Cloudflare 521 error, always verify internal connectivity before assuming the web server daemon has crashed. CSF and iptables rate-limiting are common silent killers of reverse-proxy configurations. By properly whitelisting Cloudflare’s network boundaries and adjusting connection tracking limits, you can ensure a stable, robust routing flow from edge to origin.