Cloudflare Error 520: Web server returned an unknown error
Cloudflare 520 is generated when the origin sends an empty, unknown or unexpected response. Common causes include origin crashes, malformed or oversized headers, firewall/security blocks, incorrect HTTP/2-to-origin behavior, or an early connection close. The useful evidence is the affected URL, Ray ID and origin logs.
Find the invalid origin response
Capture the URL, timestamp and Cloudflare Ray ID, then inspect origin/reverse-proxy logs for crashes, empty/malformed responses, oversized headers or blocked Cloudflare connections.
- Reproduce the failing URL and record the Ray ID and exact time.
- Inspect application/web-server/proxy logs for crashes, early connection closes or empty responses.
- Check for oversized response headers/cookies and malformed HTTP status/header output.
- Confirm firewalls/security plugins are not blocking Cloudflare IPs.
Why this branch first: Cloudflare lists origin crashes, blocked Cloudflare traffic, oversized headers and empty/malformed responses as common 520 causes.
TroubleByte diagnostic path
Capture URL, time and Ray ID.
Inspect app/web/proxy logs.
Check headers, firewall and HTTP/2-to-origin behavior.
Use HAR/Ray/origin evidence if unresolved.
Original TroubleByte diagnostic map. It summarizes the cited troubleshooting order; it is not a vendor screenshot.
Use the symptom to choose the next branch
Does the origin itself return/close abnormally for the same request?
Fix the origin/application response first.
Compare Cloudflare-to-origin protocol, firewall and headers.
Is the failure limited to specific paths or users with very large cookies?
Inspect application response/header size and path-specific code.
Check broader origin connectivity/protocol/log evidence.
Original TroubleByte decision aid derived from the cited troubleshooting scope. It does not replace vendor documentation.
What this usually means
Unlike a generic browser error, 520 is Cloudflare reporting that the origin response could not be used as a valid HTTP response. If direct origin testing also crashes or closes early, the origin is the focus. If origin direct requests are healthy, compare Cloudflare-to-origin protocol, firewall and header behavior before changing DNS.
What we verified from the source material
Cloudflare defines 520 as an empty, unknown or unexpected origin response and lists crashes, firewall/security blocks, oversized headers, malformed responses and HTTP/2 origin misconfiguration among common causes.
Prerequisites and checks
Prepare first
- Have access to origin web/application logs.
- Record a current Ray ID and exact timestamp from an error page.
- Do not expose the origin publicly just to test; use controlled direct-origin methods.
Checks that prevent the wrong fix
- Capture the affected URL, timestamp/timezone and Ray ID.
- Check origin, reverse-proxy and application logs around the request.
- Inspect response headers/cookies and HTTP/2-to-origin behavior if direct origin requests differ from proxied requests.
Applies to
Solutions, in order
Find the invalid origin response
- Reproduce the failing URL and record the Ray ID and exact time.
- Inspect application/web-server/proxy logs for crashes, early connection closes or empty responses.
- Check for oversized response headers/cookies and malformed HTTP status/header output.
- Confirm firewalls/security plugins are not blocking Cloudflare IPs.
Why this can work: Cloudflare lists origin crashes, blocked Cloudflare traffic, oversized headers and empty/malformed responses as common 520 causes.
Compare proxied and origin protocol behavior
- Test the origin directly only in a controlled/admin-safe way using the correct Host/SNI.
- If HTTP/2 to origin is enabled, verify the origin actually handles the negotiated protocol correctly.
- Use Cloudflare error/log analytics to compare edge and origin status.
- Escalate with Ray ID and HAR evidence if the origin remains healthy.
Why this can work: Cloudflare specifically documents incorrect HTTP/2-to-origin behavior and recommends logs/Ray ID/HAR evidence for unresolved 520 cases.
How to know the fix actually worked
- The affected URL returns a valid normal HTTP response through Cloudflare.
- Origin logs no longer show the crash/malformed-response condition that matched the 520.
Do not count a temporary disappearance of the symptom as a confirmed fix if the problem normally returns after a restart, reconnect or several minutes of use.
When not to keep changing things
- If troubleshooting requires bypassing Cloudflare, do not leave the origin exposed or DNS-only longer than necessary for a controlled test.
Escalation: If the origin behaves correctly directly but 520 persists through Cloudflare, provide Cloudflare Support the Ray ID, HAR files and origin evidence described in its 520 documentation.
Sources used for this record
Primary · checked Sep 8, 2026Cloudflare — Error 520First-party documentation used as the primary evidence source for this troubleshooting record.Corroborating · checked Sep 8, 2026Cloudflare — Cloudflare 5xx errorsFirst-party documentation used as corroborating evidence for this troubleshooting record.Discuss this exact problem
Share what happened on your system, ask a focused follow-up question, or add evidence that may help someone with the same symptom. Community posts are separate from TroubleByte editorial verification.
Start a discussion
Revision history
Show 1 recorded revision
2026-09-08 — Created for the v1.1 content-scale pass from current first-party documentation; public indexing is controlled by the launch allowlist.
