Debug Cloudflare 520, 522, 524 when origin server is fine
Direct Answer: Cloudflare 520, 522, and 524 errors indicate upstream connectivity problems. Even if the origin server is healthy, they arise from missing TCP/TLS handshake, blocked port, or firewall. Debug by checking TLS certs, firewall rules, connectivity, and using tools like SarangAI’s origin checker.
Cloudflare 520, 522, and 524 appear even when the origin works. This guide gives quick checks, root‑cause analysis, and step‑by‑step fixes.
At 02:45 UTC on 2024‑09‑12 a PagerDuty alert fired for “Cloudflare 520 spike”. Production dashboards showed mixed 520/522/524 errors while the origin server CPU was under 2 % and health checks passed. A recent Kubernetes deployment added a new network policy, prompting a roll‑back.
How Cloudflare 520, 522, and 524 errors actually work
520 – TCP‑handshake failure
Cloudflare sends a TCP SYN, expecting SYN‑ACK. If the origin sends a RST or drops the SYN, Cloudflare logs a raw TCP reset and returns HTTP 520. No HTTP request reaches the origin, so application logs are empty.
522 – TLS‑handshake failure
After TCP success, Cloudflare sends a ClientHello with SNI. If the origin rejects the SNI, uses an unsupported TLS version, or presents an invalid chain, the handshake aborts. Cloudflare records “TLS handshake timeout” and returns 522. Origin logs often show ssl: handshake failure or alert protocol_version.
524 – Application timeout
A TCP connection completes, but Cloudflare never receives the first application byte within its 5‑second window. This is logged as “origin did not respond”. Common causes: firewall drops on port 80/443, upstream listening on a different port (e.g., 8080), or IPv6‑only binding while Cloudflare probes IPv4.
Deep‑dive into the TCP layer
SYN – Cloudflare sends SYN to 10.0.2.10:443.
SYN‑ACK – Origin replies only if the port is open.
ACK – Cloudflare acknowledges.
If step 2 never arrives (port filtered, firewall drop, host unreachable), Cloudflare generates a 520 before any HTTP request is sent.
Deep‑dive into the TLS layer
ClientHello – Includes supported ciphers, ALPN, SNI.
ServerHello – Origin selects cipher/TLS version.
Certificate exchange – Origin sends its chain.
Key exchange – Finished messages.
Any step failure (certificate validation, unsupported version, SNI mismatch) aborts the handshake, causing a 522. Origin ssl_log may show alert_certificate_unknown or handshake_failure.
Why 524 appears after a successful TCP
After the three‑way handshake, Cloudflare waits for the first data packet. No data within 5 seconds triggers 524. Typical culprits: firewall rules that drop traffic on port 80/443, upstream service listening on a different port, or IPv6‑only binding.
About the author
Admin SarangAI · AI Tools Editor
Part of the SarangAI editorial team covering AI tools, product releases, emerging technology trends, and practical web utilities for developers and creators.
Date: 2024‑09‑12 02:30 UTC Symptom: 30 % of edge requests returned 520/522/524 within 5 minutes of a new service rollout. curl -I https://example.com timed out; dig +trace resolved correctly; origin /health returned 200. Root cause: A new Kubernetes Deployment added a NetworkPolicy denying inbound traffic on port 443 for origin-service. The policy applied while the Pod was still scheduling, briefly closing the port. Resolution: Removed the restrictive rule (kubectl delete netpol deny-ingress), waited 90 seconds for rollout, and cleared Cloudflare cache via API. Error rates fell below 0.1 % after the purge.
The policy inadvertently blocked the entire /8 subnet, which included Cloudflare edge IPs. Fixing it required deleting the policy and confirming the Pod rollout.
Step‑by‑step remediation walkthrough
Confirm origin DNS resolution
dig +short example.com
Expected: Returns the origin IP (e.g., 10.0.2.10). Fix DNS if missing.
Validate TCP reachability
curl -v https://example.com 2>&1 | head -n 20
Expected: TLS handshake completion (< HTTP/2 200) or a clear SSL error such as curl: (60) SSL certificate problem: unable to get local issuer certificate.
#!/usr/bin/env python3
import socket, ssl, dns.resolver, subprocess, sys
def dns_resolve(host):
try:
answers = dns.resolver.resolve(host, 'A')
return str(answers[0])
except Exception as e:
print(f"DNS resolution failed: {e}")
sys.exit(1)
def tcp_connect(ip, port, timeout=5):
try:
sock = socket.create_connection((ip, port), timeout)
sock.close()
return True
except Exception as e:
print(f"TCP connect error: {e}")
return False
def tls_handshake(ip, port, server_hostname, timeout=5):
try:
context = ssl.create_default_context()
with socket.create_connection((ip, port), timeout) as sock:
with context.wrap_socket(sock, server_hostname=server_hostname) as ssock:
ssock.do_handshake()
return True
except Exception as e:
print(f"TLS handshake error: {e}")
return False
host = "example.com"
ip = dns_resolve(host)
print(f"Resolved {host} -> {ip}")
if tcp_connect(ip, 443):
print("TCP port 443 is open")
if tls_handshake(ip, 443, host):
print("TLS handshake succeeded")
else:
print("TLS handshake failed – likely a 522")
else:
print("TCP port 443 unreachable – likely a 520/524")
Run with python3 check_origin.py. Output maps directly to Cloudflare error codes.
Common mistakes when debugging these errors
Assuming the origin is down – Health checks may pass while a firewall blocks the port. Verify connectivity before restarting services.
Ignoring TLS cert chain – A self‑signed or expired cert triggers 522 even though TCP works. Use SarangAI's SSL chain checker to expose the exact failure.
Misreading proxy status – Cloudflare’s “proxy status: DNS only” can hide upstream errors. Ensure the zone is fully proxied.
Forgetting to clear stale cache – Recent origin config changes may be cached, causing 520/524. Run a cache purge after any origin modification.
Using the wrong port – Debugging with port 80 when the origin listens on 8080 yields 524. Double‑check the origin field in the Cloudflare dashboard.
Additional pitfalls:
Over‑relying on curl -I – It only checks TCP/TLS; a 524 can still be masked if the origin responds after the 5‑second window. Use nc -zv for pure TCP verification.
Missing SNI in custom clients – Some tools omit SNI, causing Cloudflare to fall back to a default IP and resulting in a 522. Add -servername example.com or equivalent.
Confusing Cloudflare’s “origin response timeout” with application slowness – The 5‑second window starts after TCP handshake, not after the HTTP response begins. If API calls regularly exceed 4 seconds, consider increasing the timeout via the Cloudflare API.
Quick diagnostic tools
Running a few commands can isolate the problem in under a minute. Use the free DNS propagation checker on SarangAI to confirm that the origin resolves from multiple edge locations. Validate the TLS chain with SarangAI's SSL chain checker, which will list the exact certificate error. Finally, use the free HTTP status checker and SSL checker to confirm reachability, TLS version, and certificate expiry.
Example cURL session with realistic error
$ curl -v https://example.com 2>&1 | grep -E "SSL|error|curl"
* Trying 10.0.2.10:443...
* Connected to 10.0.2.10 (10.0.2.10) port 443
* ALPN: offering http/1.1
* Server certificate: …
* SSL certificate problem: unable to get local issuer certificate
* closing socket
curl: (60) SSL certificate problem: unable to get local issuer certificate
The curl error maps directly to a Cloudflare 522 because the origin presents a cert signed by an unknown CA.
Save as verify_origin.sh, chmod +x verify_origin.sh, and run after any origin change.
When the origin is fine: checklist
DNS resolves to the correct IP from a Cloudflare edge.
TCP ports 80/443 are open on the origin host.
TLS handshake succeeds (openssl s_client or equivalent).
Firewall/security group allows inbound traffic from Cloudflare IPs (list available in the Cloudflare dashboard under “Firewall → Rules”).
Cloudflare cache is cleared after recent origin changes.
Error comparison table
Error
Trigger condition
HTTP status
Typical symptom
Quick fix
520
TCP connection reset or refused
520
“connection timed out”
Verify origin TCP port
522
TLS handshake failure / unsupported version
522
“TLS handshake timeout”
Check certificate chain
524
TCP connection established but no data within timeout
524
“origin did not respond”
Ensure firewall allows port
Key Takeaways
Cloudflare 520/522/524 are connectivity symptoms, not origin health flags.
Run dig, nc, and openssl s_client to isolate TCP/TLS issues in 2‑3 minutes.
Use SarangAI's SSL chain checker and the free DNS propagation checker to validate certificates and resolution.
Common missteps include ignoring TLS certs and assuming the origin is down; verify firewall rules and cache first.
Frequently Asked Questions
What is the fastest way to confirm the origin is reachable?
Run nc -zv <origin_ip> 443 and check for “Connection succeeded”. Follow up with curl -sS -o /dev/null -w '%{http_code}' "https://<host>/" --resolve "<host>:443:<origin_ip>" to confirm the origin answers directly.
Why do 520, 522, and 524 appear together during an outage?
A network policy that blocks traffic on port 443 can cause TCP resets (520), TLS failures (522), and timeouts (524) depending on packet timing. Fixing the firewall rule resolves all three.
Can a valid SSL certificate still cause a 522?
Yes. If the origin’s certificate uses a weak cipher suite or an unsupported TLS version, the handshake fails and Cloudflare returns 522 even though the certificate is otherwise valid.
How does cache purging affect these errors?
Stale cache may serve an old origin configuration that references a down endpoint, leading to 520/524. Purging the cache forces Cloudflare to re‑evaluate the origin on each request.
Is there a free tool to automate this debugging?
Yes. A short shell script can combine dig, nc, openssl s_client, and curl to run the same DNS, TCP, TLS, and HTTP checks in one pass and fail CI when any layer is broken.
