HTTP error codes: 502 Bad Gateway fixes

A 502 Bad Gateway means a proxy, CDN, or load balancer reached your site but got a bad response from the origin. Refresh once as a visitor; as the owner, check origin health, logs, DNS, firewall rules, and the last deploy before changing hosts.

Most HTTP error pages are symptoms, not diagnoses. The same screen can come from a browser cache, a missing file, a blocked request, a crashed application worker, or an upstream service that stopped answering. Separate visitor checks from owner checks first, then follow the request path.

For a hosting customer, the useful question is not what the number means in isolation. It is who controls the next step: browser, DNS, CDN, web server, application, database, or hosting support. That ownership split decides whether you wait, roll back, or escalate.

Quick map of common HTTP errors

The pattern is simple enough, and also where people get sloppy. Client-visible codes are not always client-caused, and server-side codes do not all point to the same machine. A CDN can display the error while the real failure sits on the origin behind it.

How to read 502 without guessing

A 502 appears when an intermediary gets a response it cannot use from the upstream server. In ordinary hosting language, that intermediary might be a reverse proxy, a CDN edge, a load balancer, or a web server passing requests to an application process.

For a visitor, the ceiling is low. Refresh once, try another network, and check whether other sites work. If the error follows you across browsers and devices, stop clearing cache in circles. The owner or provider has the useful logs.

For the site owner, work backwards from the visible edge. Confirm DNS still points where you expect. Confirm the origin answers directly if your setup allows it. Then inspect proxy and application logs around the first failed request.

Common owner-side causes

• Origin process down: the web server is alive, but the application worker is crashed, restarting, or unreachable.
• Timeout mismatch: the app is still working, but the proxy gives up before a slow request finishes.
• Firewall or WAF block: an edge service or origin firewall blocks traffic that should pass between layers.
• Bad deploy: a configuration change breaks upstream sockets, ports, environment variables, or service names.
• Overload: CPU, memory, connection pools, or database waits push healthy requests into failure.

These causes look almost identical from the outside. That is why the first serious fix is evidence, not a host migration. A new VPS will not fix a broken deploy pattern if the same proxy timeout and worker crash move with it.

How 500, 503, 403, and 404 differ in practice

A 500 is the catch-all for a server failure. Treat it as an application or runtime investigation until logs prove otherwise. Look for exceptions, exhausted memory, failed database connections, broken file permissions, or a dependency that changed underneath the app.

A 503 usually says the service cannot handle the request right now. It may be deliberate maintenance, queue saturation, an overloaded origin, or a provider-side outage. Do not hide a real capacity problem behind a maintenance banner unless the logs support that story.

A 403 is refusal, not absence. It often comes from file permissions, IP rules, login requirements, hotlink protection, bot protection, WAF rules, or country blocks. If a page worked yesterday, compare access rules and security changes before changing application code.

A 404 is absence from the server’s current routing view. The file may be gone, the slug may have changed, or a rewrite rule may no longer match. For SEO, the fix is often a redirect or intentional gone response, not a fake homepage redirect.

Visitor checks versus owner checks

Visitors should avoid destructive troubleshooting. Refreshing, changing networks, and trying a private window can separate local browser noise from a real site failure. Beyond that, repeated reloads just add pressure if the origin is already struggling.

Owners need a sharper path:

• Identify whether the error appears at the CDN edge, web server, application, or database boundary.
• Compare the first error time with deploys, certificate changes, DNS edits, firewall changes, and traffic spikes.
• Read the logs for the component immediately behind the layer that returned the page.
• Roll back the smallest recent change before rewriting infrastructure.

The host-buying lesson is blunt. Support quality matters most during ambiguous failures. Cheap hosting is bearable when logs are clear and support can confirm node health; it is expensive when every 502 turns into a blame game.

What to check before blaming the host

Before opening a ticket, collect the minimum evidence. Note the affected hostname, approximate time window, whether all paths fail or only one route, and whether the error changes when the CDN is bypassed. Keep screenshots secondary; logs and timestamps matter more.

If you use managed hosting, ask for origin logs, process restarts, resource throttling signals, and recent node incidents. If you run your own VPS, check service health, disk pressure, memory pressure, reverse proxy configuration, and database connectivity.

Provider comparisons should focus on failure handling, not only headline specs. Look for transparent status pages, backup restore clarity, support response scope, and whether logs are available without a premium plan. Those details decide how painful the next outage feels.

When to wait, roll back, or move hosts

Wait when a single 503 lines up with declared maintenance or a short traffic spike, and when logs show recovery without repeated restarts. Waiting is not a strategy if the same route fails every busy hour.

Roll back when the first failure follows a deploy, plugin change, firewall rule, DNS edit, certificate renewal, or runtime upgrade. A fast rollback beats a heroic live debug when customers are already staring at error pages.

Consider changing hosts only after you have evidence of provider-side limits, missing logs, poor escalation, or repeated node failures. Moving without that evidence just resets the clock and adds migration risk to an unsolved application problem. Rent boring infrastructure, but diagnose the boring part first.

Freshness and method

This article uses the current HostScout writing context, verified article inputs, and official HTTP status semantics. It deliberately avoids volatile provider prices, uptime promises, and plan specifications because those figures are not needed to explain the troubleshooting path.