Fix: Error 502 Bad Gateway (Cloudflare)

When Cloudflare proxies your traffic, a 502 Bad Gateway means the edge connected toward your origin and did not get a valid HTTP response back. Because Cloudflare sits in front of everything, its branded error page becomes the public face of any origin failure, which sends people hunting through Cloudflare settings when the answer is almost always on the origin server. The error page itself tells you which side failed; read it before touching anything.

Error 502 Bad Gateway (Cloudflare)

What this error means

Cloudflare terminates the visitor’s connection at the edge, then opens its own connection to your origin (your server, load balancer, or host) and proxies the request. A 502 is Cloudflare reporting that this second hop failed: the origin refused the connection, reset it, answered with something that is not valid HTTP, or a hop between the edge and the origin broke. Cloudflare’s 502 and 504 pages include a status strip naming the failing party (browser, Cloudflare, host), which is the fastest triage signal you will get.

Behind the Cloudflare page there is usually an ordinary origin failure: a crashed app, a dead web server, an SSL mode mismatch, or a firewall dropping Cloudflare’s IPs. Cloudflare-side 502s do happen, but they are the exception and they show up on the Cloudflare status page.

Common causes

• The origin web server or application is down or crashing, so Cloudflare gets connection refused or reset.
• SSL mode mismatch: Cloudflare set to Full or Full (strict) while the origin serves no HTTPS, or serves an expired or self-signed certificate under Full (strict).
• The origin firewall or security group does not allow Cloudflare’s published IP ranges, or a rate limiter on the origin is dropping them.
• The origin’s own reverse proxy (Nginx, Apache) is up but its upstream application is dead, so the origin itself generates the 502 and Cloudflare passes it through.
• DNS at Cloudflare points at a stale origin IP after a server migration.
• An actual Cloudflare incident, confirmed on cloudflarestatus.com.

How to fix it

STABILIZE first. Test the origin directly. If the origin is down, restart the application or web server; that is the outage, and everything else is analysis.

1. Bypass Cloudflare and hit the origin exactly the way Cloudflare does, using the real origin IP with the site’s hostname:

curl -sv https://203.0.113.10/ -H "Host: www.example.com" --resolve www.example.com:443:203.0.113.10 -o /dev/null

2. On the origin, check that the web server and the application behind it are both alive:

systemctl status nginx
ss -ltnp | grep -E ":443|:80"
tail -50 /var/log/nginx/error.log

DIAGNOSE with the two results. Direct test fails: the origin is the problem, and the origin’s own logs name it (dead app process, expired certificate, full disk). Direct test succeeds but Cloudflare still serves 502: the origin is treating Cloudflare differently, so check the firewall against Cloudflare’s IP list, and check the SSL/TLS mode in the Cloudflare dashboard against what the origin actually serves on the port Cloudflare connects to. The error page said Cloudflare and the status page confirms an incident: wait it out or temporarily pause Cloudflare if the origin can safely take direct traffic.

FIX the specific mismatch. Allow Cloudflare’s ranges through the origin firewall (the list is published at cloudflare.com/ips):

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  ufw allow proto tcp from "$ip" to any port 443
done

For SSL mode problems, the correct end state is Full (strict) with a valid certificate on the origin; Cloudflare’s free Origin CA certificate is made for exactly this. Fix the origin certificate rather than downgrading the mode to Flexible, which sends visitor traffic to your origin over plain HTTP. If the origin’s own Nginx was producing the 502, follow the upstream fix on the origin: match the proxy configuration to where the application really listens and restart the dead process.

How to prevent it

• Run Full (strict) SSL with an origin certificate that is monitored for expiry, so certificate rot cannot take the site down.
• Keep the origin firewall allowlist synced with Cloudflare’s published IP ranges, ideally by automation.
• Monitor the origin directly (not just through Cloudflare) so you see origin failures without the edge in the way.
• Use Cloudflare health checks or load balancer monitors to get alerted the moment the edge cannot reach the origin.
• After any server migration, update the origin IP in Cloudflare DNS as part of the runbook, not as an afterthought.

When to call a senior engineer

Call for help when 502s are intermittent and neither side’s logs obviously explain them, when the SSL chain between Cloudflare and the origin needs to be rebuilt properly on Full (strict), or when an origin that keeps buckling under proxied load needs real capacity and failover design. Erzon engineers can test each hop from edge to application independently, pin down the failing layer with evidence, and set up origin monitoring and TLS so the next failure is a page to you, not a branded error page to your customers.