Cloudflare Error 522: Connection Timed Out

Quick reference

Code	522 Connection Timed Out
Category	Cloudflare Edge Error
Standard HTTP?	No — Cloudflare proprietary
Vendor reference	Cloudflare documentation

What 522 means

Cloudflare 522 "Connection Timed Out" means Cloudflare's edge server sent a TCP SYN packet to the origin server and the origin never completed the three-way TCP handshake — the SYN-ACK never arrived within the timeout window. Cloudflare waited, the connection timer expired, and Cloudflare returned 522 to the browser.

The difference from 521 is the TCP outcome: 521 means the origin actively refused the connection (RST packet), indicating the host is up but no service is listening. 522 means the origin did not respond at all — the SYN packet went unanswered. This can mean the host is completely unreachable, is under heavy load and not processing new TCP connections, or is silently dropping packets from Cloudflare's IP ranges (a firewall drop vs. a firewall reject).

522 can also occur when Cloudflare is reusing an existing idle TCP connection (keep-alive) to the origin and that connection has been silently closed by a network device between Cloudflare and the origin — a router, load balancer, or stateful firewall that expired the connection state without notifying either endpoint.

Two distinct 522 scenarios

Scenario A — New connection timeout (TCP SYN timeout): Cloudflare opens a fresh TCP connection to the origin, sends SYN, and gets no SYN-ACK. Causes: origin overloaded with SYN backlog full, firewall silently dropping Cloudflare IPs (iptables DROP vs. REJECT), routing issue between Cloudflare and origin, or origin host completely down.

Scenario B — Keepalive connection timeout (idle connection closed): Cloudflare reuses an existing persistent connection to the origin. An intermediate device (load balancer, NAT gateway, stateful firewall) expired the idle connection state without sending a FIN/RST to either side. When Cloudflare writes to what it believes is an open connection, the packet is dropped or the origin's TCP stack sends a RST on a connection it no longer has state for. Cloudflare interprets the absence of response as a timeout.

Diagnosis steps

Step 1 — Check origin server load. When 522s correlate with traffic spikes, the origin SYN backlog may be exhausted:

# Check CPU and load average:
top -bn1 | head -5
uptime

# Check TCP connection queue:
ss -s
# Look at: SYN-RECV count — high values indicate SYN flood or overload

# Check if the listen backlog is tuned:
cat /proc/sys/net/core/somaxconn
cat /proc/sys/net/ipv4/tcp_max_syn_backlog

Step 2 — Verify Cloudflare IP allowlist.

# Check for DROP rules on port 80/443:
iptables -L INPUT -n -v | grep -E '443|80'
# An ACCEPT rule for Cloudflare CIDRs should appear before any DROP/REJECT rules

# Silently dropped packets show up in iptables DROP counter:
iptables -L INPUT -n -v | grep DROP

Step 3 — Test TCP connectivity directly. Temporarily grey-cloud the domain in Cloudflare (bypass proxy) and test direct origin TCP:

nc -zv YOUR_ORIGIN_IP 443 # If timeout: origin unreachable or firewall dropping # If refused: 521 condition (process not running) # If connected: intermittent or keepalive issue

Step 4 — Check for idle connection drops. Review your load balancer or NAT gateway idle timeout settings. AWS ALB default idle timeout is 60 seconds, but Cloudflare may hold keepalive connections longer. Set Cloudflare's keepalive timeout shorter than your load balancer's idle timeout.

Fixes by cause

Origin overloaded: Scale the origin (more workers, horizontal scaling). Increase the TCP listen backlog:

# Increase SYN backlog capacity: echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog echo 4096 > /proc/sys/net/core/somaxconn # Make permanent in /etc/sysctl.conf: net.ipv4.tcp_max_syn_backlog = 4096 net.core.somaxconn = 4096

Firewall silently dropping Cloudflare IPs: Change DROP rules to ACCEPT for Cloudflare IP ranges, or switch from implicit DROP to REJECT so Cloudflare gets a RST (which would change the error to 521 and confirm the firewall is the issue):

# Add ACCEPT rules for all Cloudflare IPv4 ranges BEFORE any DROP rules:
curl -s https://www.cloudflare.com/ips-v4 | while read cidr; do
  iptables -I INPUT -s "$cidr" -p tcp -m multiport --dports 80,443 -j ACCEPT
done

Keepalive connection drops (load balancer idle timeout): Configure nginx on origin with keepalive parameters that match the Cloudflare-to-origin connection behavior:

# nginx — tune keepalive to close before load balancer/NAT times out
http {
    keepalive_timeout 620s;  # slightly less than Cloudflare's 650s keepalive
    keepalive_requests 1000;
}

# For AWS ALB: set idle timeout to 620+ seconds
# Console: EC2 → Load Balancers → Attributes → Idle timeout

TCP keepalive probes: Enable TCP-level keepalive probes so the kernel detects dead connections faster:

# /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 6

522 vs related errors

Code	TCP outcome	Primary cause
522	SYN timed out / no response	Origin unreachable, overloaded, or firewall DROP
521	Connection refused (RST)	Origin up but no web server listening
524	Connected, then HTTP timed out	Origin processing too slow
523	Host unreachable	No route to origin host
504	Standard gateway timeout	Upstream timeout at proxy or gateway

Frequently asked questions

Why do I see 522 only during high traffic?

Under high traffic, the origin's TCP listen backlog fills up. New SYN packets from Cloudflare queue in the kernel's SYN backlog. When the backlog is full, the kernel silently drops new SYNs — Cloudflare never gets a SYN-ACK and times out. This is the most common cause of traffic-correlated 522s.

Can Cloudflare's Health Checks reduce 522 impact?

Yes. Cloudflare Health Checks (available on paid plans) proactively monitor origin availability. When an origin fails health checks, Cloudflare can route traffic to a backup origin or pool before user-visible 522s accumulate. Configure health checks to detect the same TCP timeout condition Cloudflare sees on real traffic.

What is the Cloudflare-to-origin TCP timeout window?

Cloudflare's TCP connection timeout to origin is 15 seconds for the initial SYN. If the SYN-ACK does not arrive within 15 seconds, Cloudflare returns 522. For established connections, Cloudflare maintains keepalives and the idle timeout before returning 522 on a stale connection is approximately 90 seconds.

Does a 522 always mean the origin is down?

No. 522 can occur on a perfectly healthy origin if a firewall or NAT device between Cloudflare and the origin is silently dropping packets. Test direct TCP connectivity from outside Cloudflare to distinguish origin-down from firewall-drop scenarios.

Server Errors Hub · All Guides · Home