Orange Book
Troubleshooting

Troubleshoot Cloudflare 520–526 errors

Capture code, time, URL, and CF-RAY first, then locate 520 through 526 across network, TLS, and origin-response stages.

Edited and verified by Orange Book Editorial Team ·

TROUBLESHOOTING · EVIDENCE FIRST520–526network · TLS · application response

Do not randomly change DNS, SSL, and firewall settings

Similar 5xx pages can represent different connection stages. Capture the code, time with timezone, full URL, CF-RAY, and frequency first. Then compare the request through Cloudflare with a direct-to-origin request.

Location of Cloudflare 520 through 526 errors across DNS and TCP, TLS, and origin response stages
Locate the failed stage first: 521–523 usually concern the origin connection, 525–526 TLS, and 520/524 the origin response.Open original
Detailed description
After a visitor reaches Cloudflare, Cloudflare locates and connects to the origin, performs TLS, and waits for the origin application to return HTTP. Codes 521, 522, and 523 represent refusal, timeout, or routing; 525 and 526 represent handshake or certificate problems; 520 and 524 represent an invalid or slow response.
  1. 01
    Capture

    Preserve code, time, URL, and CF-RAY.

  2. 02
    Compare

    Compare proxied and Host/SNI-preserving direct-origin requests.

  3. 03
    Locate

    Narrow the failure to network, TLS, or HTTP response.

  4. 04
    Change

    Change one evidenced cause at a time and retain rollback.

Error-code map

ErrorStageCommon directionFirst evidence
520Origin returned an empty, unknown, or unexpected responseApplication crash, malformed or excessive headers, early connection closeOrigin and proxied headers plus origin logs at the same time
521Origin refused the TCP connectionService not listening or firewall refusalListening port and firewall logs
522Cloudflare timed out connecting to or receiving acknowledgement from the originPacket loss, overload, silent firewall dropNetwork and load metrics; whether origin logs saw the request
523Cloudflare could not reach the originWrong origin IP in DNS or a routing problemOrigin IP in Cloudflare DNS and routing
524Origin connection succeeded but no HTTP response arrived within the default 125 secondsSlow query, synchronous image/PDF work, blocked external APIRequest duration, slow queries, and job timeline
525TLS handshake with the origin failedProtocol, cipher, SNI, or certificate-chain problemOrigin TLS test and handshake logs
526Origin certificate was invalid under Full (strict)Expiry, hostname mismatch, self-signed certificate, or broken chainCertificate hostname, validity, and chain

Four-step investigation

Capture correlatable evidence

Through Cloudflare
curl -sS -D - -o /dev/null https://example.com/problem-path

Save the complete headers and Ray ID from the error page. Record time and timezone, URL, HTTP method, authentication state, affected regions, and the latest deployment or origin change. Do not paste tokens, cookies, or sensitive request bodies into a public ticket.

Connect directly while preserving Host and SNI

Example: connect example.com to a test origin IP
curl -sS -D - -o /dev/null \
  --connect-to example.com:443:203.0.113.10:443 \
  https://example.com/problem-path

Replace the documentation IP with a verified origin IP. If the proxied path fails and the direct path succeeds, investigate Cloudflare-to-origin allowlists, TLS, and routing. If both fail, prioritize the origin application or infrastructure. A direct request bypasses Cloudflare protections, so use it only in a controlled diagnostic.

Investigate one stage at a time

  • 521–523: confirm the origin IP in DNS, listening ports, Cloudflare IP allowlist, routing, and load.
  • 525–526: inspect certificate hostname, validity, full chain, SNI, and supported TLS. Do not treat a long-term downgrade from Strict as a fix.
  • 520/524: correlate application and proxy logs, slow queries, and external dependencies. Confirm whether a Worker or another component generated the response first.

Repeat the same request after the smallest fix

Change one target at a time. Repeat the same URL, method, and identity condition, then compare error rate, full headers, and origin logs. The fix is complete only when the evidence chain recovers without weakening firewall or TLS boundaries.

Do not make an AI-built image or PDF utility wait synchronously for 125 seconds

Conversion after upload, image batches, PDF parsing, or long model calls can exceed a synchronous request window. Put long work in a Queue or Workflow, return a job ID immediately, and let the UI poll status. Increasing a timeout does not create a bounded job.

When to escalate to deeper evidence

For intermittent failures that remain unexplained, add origin resource graphs, load-balancer logs, or a packet capture limited to the smallest relevant time window. A capture can contain cookies, tokens, and request bodies. Restrict access and redact it before sharing.

Unexpected cache responses use a different tree; continue to CF-Cache-Status troubleshooting. For request layers, see the request lifecycle architecture.

Primary sources

Did this page help you complete your goal?

Beta feedback is generated in this browser and is never uploaded automatically.

Architecture: ownership along one request

Understand the Cloudflare request lifecycle through responsibility boundaries, data flow, and failure ownership.

Troubleshooting: why CF-Cache-Status is not HIT

Distinguish DYNAMIC, BYPASS, and MISS from response headers, then locate cache problems with read-only steps.

On this page

Error-code mapFour-step investigationCapture correlatable evidenceConnect directly while preserving Host and SNIInvestigate one stage at a timeRepeat the same request after the smallest fixWhen to escalate to deeper evidencePrimary sources