Trace Cloudflare 520 to malformed or missing origin responses, oversized headers and origin security rules without misdiagnosing it as a 522 or 524 timeout. The safest recovery is the one supported by a repeatable test: establish the failure boundary, apply a single scoped change and compare the exact original action.
Symptoms: recognize the exact failure
Use the actual error text and product context before applying advice found for a similar-looking code. A meaningful diagnosis establishes when the failure starts, which users or devices are affected, and what continues to work.
- Visitors see Cloudflare Error 520 while the origin website occasionally appears healthy.
- Failures correlate with a specific path, login state or large cookie/header set.
- The origin has a PHP crash, incomplete response or security policy event at the same time.
Capture the affected product/version, timestamp, recent installation or configuration change and a sanitized error message. If a failed operation may have created an order, payment, data change or email, check for a successful earlier attempt before trying again.
Before changing settings: protect your data and access
Do not expose origin IP addresses, disable WAF rules permanently or share Cloudflare tokens. A 520 is not equivalent to 521, 522 or 524; each points to a different origin interaction.
Save relevant configuration or files before altering them. On managed devices or production services, follow the owner’s approval and backup policy. Prefer a staging or test account for risky comparisons. One change at a time lets you distinguish cause from coincidence and provides a clear rollback.
Step-by-Step Troubleshooting
Select Beginner for low-risk checks. Use Advanced for targeted diagnostics once you have captured the original error and protected your data.
Collect the Ray ID and exact request time
Copy the Ray ID from the error page plus URL, timestamp and whether the visitor was logged in. Do not share cookies, passwords or full private headers.
Check if the problem is one route or site-wide
Compare the homepage, a public static asset and the affected route. If one endpoint fails, identify the application or backend handler rather than changing DNS globally.
Check recent hosting and application changes
Review deployments, WAF updates, caching rules and PHP/server changes around the first 520. Keep a known-good rollback revision before making further changes.
Look at the origin logs first
Ask the host for the origin request corresponding to the Ray ID and time; capture the status, upstream event and application error if available.
Correlate request with origin status and crashes
Inspect web-server and application logs around the failing path. A worker crash, incomplete FastCGI response or malformed status line can produce a 520 rather than a standard 500.
Measure headers without collecting secrets
Use a sanitized header-only request to a safe public endpoint; inspect header size, repeat Set-Cookie behavior and reverse-proxy transforms. Strip cookies and authorization headers from any shared diagnostics.
curl -I --max-time 10 https://example.com/healthReview Cloudflare-to-origin security controls
Check origin firewall logs, allow rules for Cloudflare IP ranges and any authenticated origin-pull setting. Do not blanket-allow the Internet or disable origin authentication.
Reproduce with a bounded origin comparison
Where you administer the server, compare the same public route through the authorized origin test path and Cloudflare, preserving Host/TLS requirements. Roll back only the confirmed deployment or configuration fault.
Diagnosis: how to distinguish the likely causes
The numbered Beginner and Advanced procedures above produce evidence. Use it with the following decision table rather than applying every possible fix. An apparent match is a hypothesis until the original action succeeds after the isolated correction.
| Possible cause | Evidence to look for | Safer next action |
|---|---|---|
| Origin sent malformed or empty HTTP | The web server closes or returns a response without valid status/headers. | Inspect origin access/error logs and upstream crash reports. |
| Headers or cookies exceed supported limits | The failure is linked to authenticated sessions or unusually large headers. | Compare request/response headers without exposing session tokens. |
| Cloudflare-origin security mismatch | The origin rejects Cloudflare IPs or uses incorrect authenticated origin-pull settings. | Review firewall events and proxy configuration with authorization. |
What to record if the first checks are inconclusive
When comparing attempts, keep the input and environment as similar as possible. Document which device, user, endpoint, account or server was tested, the exact command or menu action, its result and any new message. A symptom disappearing once is useful evidence but not proof of a durable repair.
If a change has no effect, revert it before testing another theory. Repeated reinstallations, account resets or broad security exceptions can introduce new problems that obscure the original cause.
How to verify that the repair worked
Repeat the original failure scenario, not a loosely related test. Then check a nearby function that could have been affected by the change. This distinguishes a real repair from a workaround that only avoids the broken step.
- The same request path returns a valid HTTP response repeatedly through Cloudflare.
- Origin errors and oversized header or rejection events stop during comparable traffic.
Keep the result in a short incident record: original symptom, environment, confirmed cause, exact fix, follow-up test and rollback method. If the cause was never confirmed, label it as unresolved even when one retry succeeds.
Complete the following article-specific checklist while checking the original operation; the progress counter is a reading aid, not a guarantee that every configuration or account is healthy.
Solution Checklist
If it still fails: rollback and escalation
Restore the original WAF, proxy and origin-authentication configuration after a failed isolation test. Roll back the last confirmed faulty deployment rather than changing multiple upstream layers.
Escalate with the exact error, sanitized logs or screenshots, time of failure, product/version, affected scope and what each controlled test changed. Do not send passwords, session cookies, recovery codes, authentication tokens, private customer data or unrestricted database dumps.
How to prevent the problem from returning
- Monitor HTTP 5xx by route and pair edge Ray IDs with origin request identifiers.
- Keep response cookies bounded, alert on application worker crashes and test proxy changes in staging.
Schedule updates and configuration changes with a known-good backup, a narrow verification procedure and a rollback owner. Alerts should target the observable failure, not just a generic service-up indicator.
Frequently asked questions
Does this error always have one cause?
No. Cloudflare error 520 describes an observed failure in a particular product or workflow; surrounding log entries, update history and the scope of the problem determine which cause is most likely.
Should I reinstall or reset the device immediately?
Usually not. Reinstallation or a reset can erase useful diagnostic evidence and affect files or settings without addressing a remote service, account, permission or network cause. Exhaust read-only and reversible checks first.
When should I ask the vendor or administrator?
Escalate when the issue follows an account across devices, needs privileged access, affects production data, involves potential hardware failure or continues after the supported troubleshooting steps.
Related PRBLEM troubleshooting
For a distinct but related failure, compare the diagnosis in Cloudflare error 522. Different error codes can share symptoms but still require separate, evidence-based fixes.
Further reading: official documentation
Instructions and menus can change by version, hosting provider and policy. Verify the current manufacturer documentation for your exact environment before following privileged or data-changing examples.
Disqus hosts the discussion. Comments load automatically as you approach this section and may use cookies.