502 Bad Gateway: What It Means and How to Fix It
Published:
Last Updated:
Category: Marketing DX
Authors: Shusaku Yosa
502 Bad Gateway means a server acting as a gateway or proxy received an invalid response from an upstream server. A 504 means it did not receive a timely upstream response. Visitors can check availability and report the problem; operators should locate the failing layer and preserve logs before changing infrastructure.
Compare the server errors
Status | Definition in brief | First investigation |
|---|---|---|
500 | Unexpected internal server condition | Application and server logs |
502 | Invalid upstream response | Gateway, proxy, upstream connection |
503 | Temporary overload or maintenance | Capacity and service state |
504 | Upstream response not received in time | The slow or timed-out segment |
These definitions follow RFC 9110. Products can translate errors differently, so use logs to identify the actual cause. For access denials, follow the separate 403 Forbidden guide.
What visitors can do
- For ordinary browsing, wait briefly, reload, and check official incident notices.
- See whether one page or the whole site is affected. Another browser or network can help isolate a local condition.
- If the issue persists, send the operator the URL, timestamp and time zone, message, and request ID.
After submitting a payment, order, or application, check the history, confirmation message, or support channel before resubmitting. Processing may have succeeded even though its response failed. Changing your DNS settings is not a standard fix for a server-to-server failure; cache or local-network changes belong to specific, evidenced cases.
Operators: capture evidence and locate the layer
Record affected URLs, times, regions, frequency, request IDs, and recent releases or configuration changes. Trace the path through CDN, load balancer, reverse proxy, application, and dependencies. Do not start with an indiscriminate restart that loses useful evidence.
Compare edge and origin behavior within your authorized operational procedures. Cloudflare environments can involve failures at either the origin or Cloudflare; follow the official 502/504 troubleshooting guide to collect relevant timestamps, hostnames, and logs.
Observation | Candidate cause | Next evidence | Response direction |
|---|---|---|---|
Upstream connection refused | Stopped process or wrong listener | Process, port, health check | Repair the verified service or destination issue |
Connection closes unexpectedly | Crash, constraint, invalid response | Application errors and resources | Investigate the exception or limit |
Upstream timeout | Slow application, database, or external API | Latency by segment | Fix the bottleneck; adjust settings deliberately |
Errors after release | Configuration or dependency change | Version and change boundary | Consider a tested rollback |
Errors during traffic spikes | Resource or connection limits | Queues, CPU, memory, DB connections | Improve processing or relevant capacity |
Longer timeouts and larger servers are responses to particular causes, not universal remedies. A slow query or malformed response may remain after either change. Also, a timeout does not necessarily surface as 502 in every implementation.
Review the CMS and cache configuration
Correlate recent plugin, theme, runtime, and hosting changes with logs. Before disabling components or rolling back, confirm the backup, restoration procedure, and affected scope. Clarify the responsibilities of the CMS operator, host, CDN, and custom developer with the CMS operations guide.
Cache only responses that are appropriate for sharing. Do not treat all dynamic pages alike: login, payment, and personalized information require deliberate exclusion and update rules. If destinations or loops are involved, inspect the redirect configuration.
Prove recovery beyond the homepage
Check | Evidence |
|---|---|
Affected public pages | Intended content and HTTP 200 response |
Critical actions | Login, form, or checkout completes correctly |
Errors and load | Failures subside at the identified segment |
Incident record | Cause, scope, change, and rollback documented |
Monitoring | Important URLs and dependencies are covered |
In a fictional inquiry site, the homepage may work while the form API returns 502. Test successful, failed, and repeated submissions rather than declaring recovery from a page load. Check for duplicate outcomes where processing may have completed before the response failed.
Track search effects without a time guarantee
Google can reduce crawling during 5xx errors, and persistent failures can affect indexed URLs. There is no universal “safe number of hours” or fixed removal deadline. Review Google's status-code handling, then inspect the response and Search Console indexing and crawling data after repair. Keep outage duration, recrawling, and search performance as separate observations.
Turn the incident into a better check
Record customer impact separately from the technical cause. “The inquiry could not be submitted” and “an upstream API connection ended during processing” are different observations. Choose a monitoring improvement and a pre-release test that would detect the same failure earlier. Keep log locations and escalation contacts, rather than ending the record with “fixed by restart.”
