Cloudflare Error
Cloudflare Error 520: Web Server Returns an Unknown Error
Cloudflare received an empty, reset, or otherwise unparseable response from your origin server.
What This Error Means
A 520 means Cloudflare successfully connected to your origin server, but the response it got back was empty, malformed, or something Cloudflare's edge couldn't parse as a valid HTTP response. Unlike a 522 (connection timeout) or 521 (server down), the connection itself succeeded — the origin server responded with something, just not something usable.
Why It Occurs
This most commonly happens when the origin web server (Nginx, Apache, a Node.js process, etc.) crashes or is killed mid-request, closes the connection abnormally, or sends headers that violate HTTP protocol expectations (oversized headers, invalid characters). It can also occur if the origin process hits a resource limit (out of memory) exactly while generating the response.
Symptoms
- ⚠ Visitors see a Cloudflare "Error 520" page instead of your site
- ⚠ Intermittent — the site works most of the time but occasionally shows 520
- ⚠ Correlates with origin server restarts or crashes in its own logs
Common Causes
- • The origin application crashed or was killed (OOM kill) while generating a response
- • A misconfigured web server sending malformed or oversized response headers
- • A reverse proxy or load balancer in front of the actual application returning an unexpected response
- • A WAF or security module on the origin silently dropping the connection instead of returning a proper error
How to Fix It
- Check your origin server's own error logs (Nginx error.log, application logs) for the exact timestamp of the 520 — the root cause is almost always visible there, not on Cloudflare's side
- Check for out-of-memory kills: on Linux, `dmesg | grep -i "killed process"` shows OOM kills with timestamps to correlate
- If using Nginx as the origin's web server, check `large_client_header_buffers` — a response with headers larger than this limit gets rejected
- Confirm the origin application isn't crashing on a specific request pattern — check for a stack trace in application logs at the same timestamp
- If intermittent and load-related, check origin CPU/memory usage during the failure window — resource exhaustion under load is a common trigger
Verification
- ✓ Reproduce the request that triggered the 520 and confirm the origin now returns a normal, complete HTTP response
- ✓ Monitor origin logs for a period after the fix to confirm no recurrence
Prevention
- → Set up origin server monitoring/alerting for crashes and OOM kills, not just uptime pings
- → Configure appropriate resource limits and headroom on the origin so it degrades gracefully under load instead of crashing