Cloudflare Error 522: Connection Timed Out

A 522 means Cloudflare tried to open a TCP connection to your origin server and never got an answer. The handshake didn't complete inside Cloudflare's window, so the request never made it past the front door. No data exchanged, no headers read.

Whose fault is it

A 522 is an origin-side failure nearly every time. Cloudflare's edge tried to establish a TCP connection and got nothing back within the timeout. Your server may even look online to you while failing Cloudflare's connection attempts.

What a timeout means versus a refusal

The key distinction is silence versus rejection. A 521 is an active refusal: the server sends back a clear "no." A 522 is silence: Cloudflare sends the initial TCP SYN packet and never receives the SYN-ACK that completes the handshake. Cloudflare retries with a short backoff, then gives up and returns the 522.

Silence is usually caused by one of two things: the server is too overwhelmed to answer, or a firewall is configured to drop packets rather than reject them. A drop produces silence; a reject produces a 521. This is why the fix paths for the two codes differ.

The common causes, most likely first

1. A firewall is silently dropping Cloudflare's packets The most common cause. A server firewall (iptables, UFW, CSF) or a hosting-panel security layer is dropping inbound connections from Cloudflare's IP ranges. Silent drops, as opposed to RST rejections, are exactly what produces a 522 rather than a 521. Allowlist all current Cloudflare ranges from cloudflare.com/ips for all TCP traffic on 80 and 443, not just for the SYN packet.
2. The origin server is overloaded CPU pegged, RAM full, no free worker processes to accept new connections. The server is technically up but can't pick up the phone. Common on shared hosting during traffic spikes. Run top or htop and check whether resources are maxed at the times the errors occur.
3. The DNS record points to the wrong IP The A or AAAA record in your Cloudflare DNS zone points to an IP that's wrong, stale after a server migration, or no longer yours. Cloudflare faithfully sends requests into the void. Confirm the record matches your current origin IP.
4. Network or routing problems Packet loss or routing issues between Cloudflare's edge and your hosting provider's network. Less common and harder to fix on your end, but you can confirm it with an MTR or traceroute from the origin to the Cloudflare IP in your access logs.
5. KeepAlive is disabled on the origin Cloudflare reuses persistent TCP connections. If your server closes the connection after every request, the repeated reconnection attempts raise the odds of a timeout under load. It's rarely the sole cause, but it makes every other problem worse. Set keepalive_timeout 75; in Nginx or KeepAlive On in Apache.

How to diagnose it

1. First, confirm the site is actually down for everyone and Cloudflare itself isn't having an incident. Check cloudflarestatus.com.
2. Test whether the origin responds at all. From another machine: curl -v --connect-timeout 10 https://ORIGIN_IP/ -H "Host: yourdomain.com". A hang confirms the timeout; "connection refused" would mean you actually have a 521.
3. SSH into the origin and check resource usage with htop. If CPU or RAM is maxed, that's your cause.
4. Inspect the firewall for rules touching Cloudflare ranges, and confirm they allow established and related TCP traffic, not just new SYN packets. A rule that permits the handshake start but drops follow-up packets is a classic 522 trap.
5. Run mtr ORIGIN_IP from a Cloudflare-adjacent network if you suspect routing loss.