Fix Cloudflare Error 522 Connection Timed Out

An HTTP Error 522 (Connection Timed Out) displayed on a Cloudflare-proxied domain indicates a fundamental Layer 4 TCP connection breakdown between Cloudflare's nearest edge data center (Point of Presence) and your origin web server.

Because Cloudflare sits as a reverse proxy in front of your domain, your origin server sees incoming requests arriving from Cloudflare's anycast IP ranges—not from the individual visitor's client IP. If your origin web server also encounters upstream application socket crashes, consult our guide on resolving NGINX 502 Bad Gateway errors.

If your host firewall, security daemon, or ISP detects thousands of requests originating from these IP ranges, it may misidentify Cloudflare as a DDoS attack and silently drop TCP SYN packets.

This guide provides terminal commands and server configurations to diagnose and resolve Error 522.

---

Technical Overview: The Failed TCP Handshake

[Visitor Browser] 
       │ 1. HTTP GET /
       ▼
[Cloudflare Edge Proxy]
       │ 2. Sends TCP SYN packet to Origin Port 80/443
       ▼
[Origin Server Firewall (UFW / iptables / AWS SG)]
       │
       ├── Scenario A: Firewall drops SYN packet (No response)
       ├── Scenario B: Origin CPU at 100% (Backlog queue full)
       └── Scenario C: Incorrect A record IP pointing to dead host
       │
       ▼ (15 Seconds Elapsed)
[Cloudflare Returns HTTP 522: Connection Timed Out to Visitor]

To optimize resolution times before requests even reach Cloudflare's edge, explore our benchmark analysis of the best DNS settings for low latency.

---

Step 1: Whitelist Official Cloudflare IP Blocks in Your Firewall

Cloudflare publishes an authoritative list of all IP ranges used by its edge proxies. If you run UFW, iptables, fail2ban, or csf on Linux, you must allow unrestricted inbound traffic from these ranges on ports 80 and 443.

Script to Automate Cloudflare Whitelisting on Ubuntu/Debian (UFW):

#!/bin/bash
# Fetch and whitelist official Cloudflare IPv4 ranges
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    sudo ufw allow from $ip to any port 80,443 proto tcp comment 'Cloudflare IPv4'
done

# Fetch and whitelist official Cloudflare IPv6 ranges
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
    sudo ufw allow from $ip to any port 80,443 proto tcp comment 'Cloudflare IPv6'
done

# Reload UFW rules
sudo ufw reload

---

Step 2: Verify Origin DNS Records in the Cloudflare Dashboard

A frequent cause of Error 522 after server migration is a stale DNS A or AAAA record pointing to an inactive IP address. If visitors experience client-side name resolution loops, reference our DNS_PROBE_FINISHED_NXDOMAIN troubleshooting guide.

1. Log into your Cloudflare Dashboard.
2. Select your domain and click DNS > Records.
3. Inspect your root @ and www records.
4. Ensure the IPv4 address matches your origin server's current public IP:

   # Verify your current origin public IP from server shell:
   curl -4 ifconfig.me
   

---

Step 3: Enable TCP Keep-Alive in NGINX or Apache

Cloudflare relies heavily on persistent TCP connections to reduce connection establishment latency. If your origin server terminates idle connections prematurely, Cloudflare's edge may attempt to reuse a stale socket and time out:

Recommended NGINX Configuration (/etc/nginx/nginx.conf):

http {
    # Keep-alive settings for reverse proxy edge
    keepalive_timeout 65s;
    keepalive_requests 1000;
    
    # TCP optimization
    tcp_nopush on;
    tcp_nodelay on;
}

Reload NGINX:

sudo nginx -t && sudo systemctl reload nginx

---

Step 4: Inspect Cloud Security Groups (AWS, DigitalOcean, GCP)

If you are hosting your origin server on cloud infrastructure:

• AWS EC2: Check your instance's Security Group Inbound Rules. Ensure HTTP (Port 80) and HTTPS (Port 443) allow traffic from 0.0.0.0/0 or the specific Cloudflare IP CIDRs.
• DigitalOcean: Review Cloud Firewalls associated with your Droplet.
• Linode / Akamai: Check Cloud Firewall rules and Linode Network Helpers.

---

Step 5: Advanced Kernel SYN Backlog and Queue Tuning

Under sudden spikes in web traffic or streaming loads, the Linux kernel's TCP listen backlog can overflow, causing incoming SYN packets from Cloudflare edge nodes to be silently dropped.

# Check if your server has dropped listen queue connections:
netstat -s | grep -i "listen"
# Example output: "3814 times the listen queue of a socket overflowed"

Apply Kernel Tuning in /etc/sysctl.conf:

# Increase listen backlog for high-traffic proxies
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Enable TCP SYN cookies to defend against SYN flood exhaustion
net.ipv4.tcp_syncookies = 1

# Reduce SYN/ACK retries to free pending connection slots
net.ipv4.tcp_synack_retries = 2

Execute sudo sysctl -p to load these values into the live kernel.

---

Step 6: Test Direct Origin Reachability

Bypass Cloudflare entirely from your local terminal to verify whether your origin web server is accepting connections:

# Direct test against origin IP on port 443 (replace with your actual server IP)
curl -Iv --resolve bufferfixer.com:443:YOUR_ORIGIN_IP https://bufferfixer.com

If this command outputs Connected to YOUR_ORIGIN_IP followed by HTTP/2 200, your server is operational, and any remaining Error 522 is strictly tied to edge firewall blocks or routing drops.

For additional server management blueprints, visit our Servers & Hosting archive, review our editorial verification standards, or submit an inquiry to our engineering team.