Cloudflare 522: what it means and how to fix it

What does Cloudflare 522 mean?

A 522 is a Connection Timed Out response generated by Cloudflare, not directly by your origin server.

The key distinction is that the user's request successfully reached Cloudflare, but Cloudflare timed out while trying to establish a TCP connection to the origin, or did not receive the expected acknowledgment within the relevant timeout window.

In plain terms:

• User → Cloudflare: OK
• Cloudflare → Origin: connection timed out

In most cases, the problem is somewhere between Cloudflare and the origin: the origin service itself, firewall or security policy, DNS configuration, resource exhaustion, or the network path.

Less commonly, regional network conditions or a Cloudflare-side incident may also contribute.

So when you see a 522, do not immediately restart the server — and do not assume Cloudflare itself is down. First determine which layer is failing.

First, narrow down where the failure is

Before changing configuration, classify the symptom:

• Direct origin access also fails → inspect the origin service, listening ports, firewall, and upstream network first
• A controlled origin test succeeds, but proxied traffic fails → inspect source-IP policies, Cloudflare IP handling, and path differences. When testing the origin directly, preserve the correct Host header and TLS SNI to avoid a Host/SNI mismatch masking the actual failure
• Only some regions fail → investigate regional routing, ISP paths, or edge-path differences
• 522 appears intermittently under load → inspect CPU, connection queues, file descriptors, workers, and traffic spikes
• 522 started after a migration or network change → check A / AAAA records, security groups, ACLs, and recent firewall changes

This will not give you the final root cause, but it can reduce the search space quickly.

Five common causes

1. The origin service is not actually listening correctly

"Server is online" and "web service is reachable" are different statements. This is the cheapest thing to verify — run one command before touching firewall rules or DNS.

Examples:

• Nginx stopped
• the service listens only on 127.0.0.1
• a container port is not published correctly
• port 443 is not listening
• the application did not restart after a reboot

How to verify:

ss -tlnp
# or
netstat -tlnp

Confirm whether 80 / 443 are listening, whether the bind address is 0.0.0.0 / :: or only 127.0.0.1, and whether the expected process owns the socket.

For Docker or Kubernetes workloads, continue into port mappings, Services, Ingress, and host networking as needed.

2. Firewall or security policy blocking Cloudflare traffic

When Cloudflare proxies traffic, the connection reaching your origin typically comes from Cloudflare infrastructure rather than directly from the visitor's public IP. If your origin uses source-IP allowlisting and Cloudflare's published IP ranges are missing or incomplete, connections may be dropped before they ever reach Nginx or your application.

Check more than just the cloud security group:

• iptables / nftables
• ufw / firewalld
• fail2ban
• cloud security groups and network ACLs
• upstream firewalls
• third-party WAF or host security software

How to verify: If the origin restricts inbound traffic by source IP, confirm that the current Cloudflare IPv4 and IPv6 ranges are allowed on the ports your service actually uses.

Important: if ports 80 and 443 are already intentionally open to the public and you do not use source-IP restrictions, adding a separate Cloudflare allowlist is not inherently required. In that case, look for accidental blocking, rate limits, automated bans, or upstream filtering.

3. Origin resource or connection exhaustion

A running process is not the same as a healthy server that can accept new connections.

Common failure modes:

• sustained CPU saturation
• memory pressure
• full TCP listen queues
• file descriptor exhaustion
• insufficient Nginx worker capacity
• exhausted application thread pools
• sudden traffic spikes

A strong signal: the site is usually healthy, but 522 errors appear intermittently during peak traffic.

How to verify: correlate the exact 522 time window with CPU and load average, memory and swap, TCP connection states, listen queue pressure, file descriptor usage, Nginx error logs, and application logs.

Do not only inspect whether the server looks healthy now. Inspect what happened when the 522 occurred.

4. Incorrect A or AAAA records

If Cloudflare DNS still points to the wrong destination, origin health elsewhere does not matter.

Look for records pointing to:

• an old server or released public IP
• a decommissioned instance
• the wrong load balancer
• a stale or incorrectly configured IPv6 endpoint

A common migration mistake: the A record is updated to the new origin, but the AAAA record still points to the old IPv6 address. This creates confusing failures in dual-stack environments.

How to verify: review all relevant records — A, AAAA, CNAME, and stale historical records. Confirm that every active record points where you expect.

5. Origin network or intermediate path problems

Your laptop's path to the origin is not the same as Cloudflare's path to the origin. That means this situation is possible: local access works, external monitoring works, but some Cloudflare paths still fail.

Potential causes:

• cloud provider regional network events
• ISP routing issues
• upstream ACL changes
• DDoS mitigation behavior
• recent security-group or network-policy changes
• unstable cross-region connectivity

How to verify: use Cloudflare Trace to identify the edge location (colo) handling the request, then compare results from multiple regions to determine whether the failure appears geographically concentrated.

Keep this limitation in mind: a regular cloud VM in the same region does not reproduce Cloudflare's actual network path to your origin. Regional probes are useful evidence, not proof.

Recommended troubleshooting order

When you see a 522, work through this sequence before making broad changes:

1. Check origin ports — are 80 / 443 actually listening? Is the service bound to the expected interface?
2. Check firewall and security policy — security groups, ACLs, iptables, fail2ban, upstream WAF, accidental blocking of Cloudflare traffic
3. Check origin capacity — CPU, memory, active connections, backlog, file descriptors, Nginx / application workers
4. Check DNS — A, AAAA, CNAME, stale records, recent migration changes
5. Check logs — Nginx access log, Nginx error log, application logs, system logs
6. Check for regional patterns — are only some users affected? Is the issue concentrated in a region?

A useful heuristic: if there are no corresponding entries in the web server access logs during the failure window, the failure may be occurring before an HTTP request reaches the web server — look upstream at ports, firewall, and network first. If requests do appear in the access log, continue investigating higher layers.

522 vs other Cloudflare 5xx errors

| Code | Meaning | | ------- | ---------------------------------------------------------- | | 521 | Origin refused or could not accept the connection | | 522 | Connection between Cloudflare and the origin timed out | | 523 | Cloudflare could not reach the origin | | 524 | Connection succeeded, but HTTP response took too long | | 525 | SSL handshake failed between Cloudflare and the origin | | 526 | Cloudflare could not validate the origin SSL certificate |

A simple mental model:

• 521 → connection refused
• 522 → connection timed out
• 523 → origin unreachable
• 524 → connected, but response too slow
• 525 / 526 → TLS or certificate problem

Different status codes point to different failure layers. Distinguishing them early prevents wasted troubleshooting.

Use Website Check for a faster first pass

Manual inspection remains essential for a real incident, but Website Check can help with the first diagnostic pass.

It provides a quick view of available signals: DNS resolution, HTTP status, SSL / TLS information, CDN-related characteristics, and structured check results.

These signals do not replace origin logs, firewall rules, or cloud monitoring. They can, however, help answer the first question: should you inspect DNS, HTTP, TLS, or continue deeper into the origin and network path?

Good incident response rarely comes from a single button. It starts by identifying the layer that is actually failing.