Cloudflare 522 Connection Timed Out: trace reachability from edge to origin
A 522 means the edge could not establish or complete a timely connection to origin. Focus on origin reachability, filtering, and capacity rather than repeatedly purging cache.
Maintained by Kevin · Ovalk
Scope and prerequisites
A Cloudflare-proxied hostname connecting to an origin server. Workers-only failures and DNS-only hostnames need a different diagnostic path.
Know the intended origin, listening port and firewall owner. Direct-origin probes must come from an authorized network and preserve hostname/SNI. Do not publish an origin bypass or weaken TLS validation.
Common symptoms
- The site displays Cloudflare error 522.
- Direct origin access works differently from CDN access.
- Origin logs show no request or show connection buildup.
1. Verify origin health and listeners
Check the application, reverse proxy, and ports locally, then verify the public path from an allowed external network. A locally failing origin belongs in application or load investigation first.
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" http://127.0.0.1/health
ss -lntp | grep -E ":80|:443"2. Inspect filtering and connection capacity
Security groups, host firewalls, connection tracking exhaustion, descriptor limits, and SYN queues can all make edge connections time out. Check whether intended Cloudflare source ranges are allowed.
sudo iptables -S
ss -s
sysctl net.core.somaxconn3. Use a controlled bypass for comparison
In a controlled environment, test with an explicit host-to-origin mapping to validate Host header, TLS SNI, and application response. Do not leave a publicly exposed origin bypass as the long-term fix.
curl -I --resolve example.com:443:ORIGIN_IP https://example.com/Interpret the evidence
| Observation | What to check next |
|---|---|
| 522 with no origin request log | The HTTP request may not have reached the application. Inspect TCP reachability, origin address and filtering rather than assuming a cache problem. |
| Origin works from one network only | Compare source-based rules, routing and load. A successful administrator request does not establish reachability from Cloudflare. |
| 524 instead of 522 | Reclassify the incident: a connected origin that takes too long to return an HTTP response has a different failure stage. |
Illustrative diagnosis
A hypothetical example to explain the reasoning, not a reported customer incident or a claim of testing on your stack.
An origin health check works locally, but Cloudflare shows 522 after a firewall change. The rule allows the administrator’s IP and omits the intended CDN source ranges. Local success does not test that edge-to-origin route. Compare firewall counters and the approved rule change, restore the necessary restricted access, and retest through the proxied hostname.
Verify recovery
- Request the original failing URL through Cloudflare and correlate its timestamp with origin access/error logs and firewall counters.
- Observe representative traffic and multiple probes. Confirm that the origin is not unintentionally reachable from unapproved sources after the rule change.
Rollback and stopping point
Save the prior approved firewall and origin configuration. If a rule change broadens exposure or causes other failures, restore it through the available console and reapply the smallest verified correction. Cache purges do not repair a failed origin connection.
Prevention and long-term repair
- Monitor origin availability, connection queueing, and end-to-end TTFB.
- Maintain CDN origin IP allowlists through automation.
- Provide an authenticated origin diagnostic path rather than a public IP bypass.
References and corrections
Use the documentation for your installed version. The references below explain the underlying behavior; commands still need environment-specific validation.
Report a correction to Kevin — include the page URL, version and a redacted reproduction. See our editorial policy.