Skip to content
Rescue 404
Rescue

Cloudflare Errors

Cloudflare Error 520

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

520

Cloudflare Error 520 means Cloudflare reached your origin and got an empty, malformed, or otherwise unusable HTTP response—fix origin crash logs, oversized headers, firewall interference, and protocol mismatches before changing DNS or SSL modes.

HTTP 520 is Cloudflare’s catch-all when the origin answers in a way the edge cannot treat as a valid HTTP response. It is not a TCP timeout (522), a refused connection (521), or a slow-but-valid response (524). This guide shows how to read the Ray ID, isolate whether the origin is crashing or returning junk, and clear the host-side problems that usually produce 520.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • HTTP 520 means Cloudflare reached the origin but received an empty, invalid, or otherwise unexpected response. (Cloudflare Error 520)
  • Cloudflare publishes the proxy IPv4 and IPv6 ranges origin firewalls must allow when a hostname is orange-cloud proxied. (Cloudflare IP addresses)
  • Setting a DNS record to DNS-only (grey cloud) bypasses the Cloudflare proxy so you can test the origin without edge interference. (Proxy status)

What the error means

With an orange-cloud hostname, browsers talk to Cloudflare first; Cloudflare then requests your origin. Error 520 fires when that origin contact yields something unexpected: an empty reply, missing status line, headers Cloudflare cannot parse, or a connection that drops mid-response after a partial exchange. That sits between “never connected” failures (521/522) and “connected but too slow” (524). On WordPress stacks, 520 often tracks PHP/web-server crashes, security tools resetting Cloudflare IPs, cookie/header bloat past size limits, or an origin that advertises HTTP/2 then mishandles it—not a theme CSS glitch or a browser cache issue.

Common symptoms

  • Visitors see Cloudflare’s “520: Web server is returning an unknown error” page with a Ray ID
  • The failure may be constant or intermittent depending on which edge or which URL is hit
  • Grey-cloud or direct-origin tests sometimes still fail, or succeed only for simple static files
  • Host error logs show PHP fatals, segfaults, or abrupt worker restarts around the same timestamps
  • Problem began after a plugin/security change, header/cookie growth, or HTTP/2-to-origin toggle
  • Only heavy or authenticated pages 520 while a plain HTML file on the same host loads
  • SSH and the hosting panel stay reachable while public proxied HTTPS shows 520

Most likely causes

  1. 01 Origin web server or PHP workers crash mid-request and return nothing usable
  2. 02 Firewall, CSF, Imunify, fail2ban, or a security plugin resetting connections from Cloudflare IP ranges
  3. 03 Response headers or cookies exceeding Cloudflare’s practical size limits (often from excessive Set-Cookie)
  4. 04 Malformed or empty responses missing a proper HTTP status line or required framing
  5. 05 HTTP/2 to origin enabled while the origin advertises ALPN support but does not speak HTTP/2 correctly
  6. 06 Authenticated Origin Pulls or client-cert expectations misconfigured so the origin aborts the exchange
  7. 07 Application or reverse-proxy bugs that close the socket before headers are fully written

What changed before the problem started

  • Plugin, theme, or custom code update that started fatalling under load
  • New WAF, security plugin, or host firewall rule affecting Cloudflare connectors
  • Login, cart, or A/B tooling that ballooned cookie and header size
  • HTTP/2 to Origin or protocol optimization toggled in Cloudflare
  • Migration or panel rebuild that left the web stack unstable or misconfigured
  • Authenticated Origin Pull or TLS client-auth settings changed without matching origin config

Troubleshooting steps

  1. 01

    Confirm the code is 520 and capture the Ray ID

    Read the Cloudflare error page carefully—520 is not 521, 522, or 524. Copy the Ray ID, note the failing URL, and whether the failure is constant or intermittent. That packet anchors every host and Cloudflare support conversation.

  2. 02

    Bypass the proxy briefly to see raw origin behavior

    Grey-cloud the DNS record or request the origin IP with the correct Host header. If the origin still crashes, returns blank, or serves a PHP fatal, fix hosting first—Cloudflare is surfacing a bad origin response, not inventing the outage.

  3. 03

    Check origin error logs at the Ray ID timestamps

    Open Apache/Nginx/LiteSpeed and PHP-FPM/application logs around each 520. Look for fatals, segfaults, upstream resets, or “connection reset by peer.” A repeating crash signature is the shortest path to the real fix.

  4. 04

    Allowlist Cloudflare IPs and clear false security bans

    If the origin firewall or a security plugin blocks or resets Cloudflare ranges, edges get empty or aborted replies that surface as 520. Allowlist Cloudflare’s published IPs and clear any auto-bans of those ranges before disabling protection wholesale.

  5. 05

    Reduce header and cookie bloat on failing paths

    Inspect Set-Cookie and custom headers on a failing URL. Login, cart, and marketing pixels sometimes stack cookies until headers become too large for the edge to accept. Trim unused cookies and avoid dumping large session payloads into headers.

  6. 06

    Stabilize the web/PHP stack before flipping SSL modes

    Restart crashed PHP-FPM or the web server only after noting the crash reason, then retest the same URL. Do not treat 520 as an SSL-mode problem first—certificate handshake failures usually present as 525 or 526 once TCP works.

When to stop troubleshooting

Escalate if the origin keeps crashing after a clean restart, you cannot read host logs or firewall rules, Authenticated Origin Pull was enabled by another admin you cannot reach, or ecommerce URLs stay broken through peak hours. Hand over the Ray ID, failing URLs, grey-cloud test results, and the log lines that match the outage window—do not keep toggling Cloudflare features that cannot repair a crashing origin.

Information to collect before requesting help

  • 01 Cloudflare Ray ID from the 520 page
  • 02 Exact failing URL(s) and whether static files also fail
  • 03 Whether grey-cloud or direct-origin testing still fails
  • 04 Host PHP/web-server log excerpts at the matching timestamps
  • 05 Recent plugin, firewall, HTTP/2, or Authenticated Origin Pull changes
  • 06 Screenshot of the 520 page and current Cloudflare proxy status
  • 07 Whether cookies/headers on the failing path look unusually large

How a professional repairs the problem

We confirm a true 520, reproduce against the origin with the proxy bypassed, and read crash and reset logs at the Ray ID window. We clear firewall false positives against Cloudflare ranges, trim pathological headers, correct protocol or Authenticated Origin Pull mismatches, and stabilize PHP/web workers. Once the origin returns clean HTTP responses, we re-enable the proxy and watch the same URLs under normal traffic.

Frequently asked questions

Does purging Cloudflare cache fix Error 520? +
Usually no. 520 reflects a bad or empty origin response on a request Cloudflare had to contact the origin for. Purge only helps if you were also troubleshooting a different cached error after the origin is already healthy.
How is 520 different from Cloudflare 522? +
522 means Cloudflare never finished connecting to the origin in time. 520 means contact happened but the reply was empty, malformed, or otherwise unusable. Fix uptime and firewall pathing for 522; fix crashes, headers, and protocol bugs for 520.
Is 520 the same as a WordPress critical error? +
Not exactly. A critical error is WordPress telling you PHP crashed with a visible message. A 520 can be caused by the same crash if the origin returns nothing Cloudflare will accept—but visitors see Cloudflare’s page, not WordPress recovery UI.
Can oversized cookies really cause 520? +
Yes. When response headers grow past what the edge tolerates, Cloudflare may treat the reply as unusable. Trim unused cookies and avoid stuffing large payloads into headers.
Should I switch SSL/TLS mode to fix 520? +
Not as a first step. Handshake and certificate problems more often show as 525 or 526. For 520, start with origin stability, logs, firewall allowlists, and header size.
Why do only some pages show 520? +
Different routes run different code, plugins, and cookie sets. A fatal or header explosion on checkout can 520 while the homepage stays fine. Reproduce per URL instead of assuming the whole server is down.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.