502 and 504 errors both involve a server acting as a gateway or proxy, but they point to different failures. A 502 indicates an invalid response from an upstream server. A 504 indicates that an upstream response did not arrive in time.
Those status codes identify the reporting relationship, not the complete root cause. A website may have a CDN, load balancer, reverse proxy, application server, and database in the request path. The first useful task is to identify which component generated the error.
At getaboutcolumbia, this troubleshooting process follows the failing request through those layers and explains why simply raising every timeout can make the situation worse.
Identify the gateway and its upstream
Record the affected URL, timestamp, response headers, and any request identifier shown on the error page. The web server log investigation should start with that evidence. Branding on an error page is helpful, but custom pages and nested proxies can make the source less obvious.
The MDN definition of 502 Bad Gateway describes an invalid upstream response. In practice, inspect the reporting proxy’s logs for the exact connection or response failure rather than treating 502 as a synonym for one particular application crash.
The MDN definition of 504 Gateway Timeout identifies failure to receive a timely upstream response. Determine whether the wait occurred while connecting, waiting for response data, or traversing another dependency. Different components may apply different limits.
Map the request path in plain language: browser to CDN, CDN to reverse proxy, reverse proxy to application, and application to its dependencies. Write down the hostname, address, port or socket, and owner for each relevant hop. A forgotten intermediate proxy can otherwise leave a whole timeout layer unexplained.
Test a safe representative request at each authorized boundary. Preserve the intended hostname and authentication context where required. Direct access to an origin IP can produce a different virtual host or certificate path, so a successful IP request is not automatically an equivalent test.
Use the failure pattern to choose the next check
If static files work but application pages fail, inspect the application service and its upstream connection. If only one route fails, inspect the work that route performs. If all routes fail through the CDN but succeed through an approved origin test, focus on the edge-to-origin path and its policies.
For a hypothetical deployment failure, a reverse proxy may still reference an old application socket while the new process listens elsewhere. Restarting the database will not correct that address mismatch. Compare the active service endpoint with the effective proxy configuration before restarting unrelated components.
A timeout on a report page can instead reflect a slow query or a remote API wait. Database query measurement and application traces help identify which dependency occupies the request. Long-running report generation may belong in an asynchronous job with a status interface rather than a synchronous web request.
Read the exact semantics of any timeout before changing it. The Nginx proxy_read_timeout documentation specifies an interval between successive reads, not a single limit on total response duration. Other directives and products have their own meanings, so matching numeric values does not necessarily create matching behavior.
Raising a timeout can keep workers occupied longer. If the original problem is saturation, that can lengthen queues and spread failures to unrelated requests. Check concurrency, connection limits, and PHP-FPM worker capacity before deciding that more waiting is the appropriate remedy.
Examine recent changes in routing, certificates, deployment configuration, firewall rules, and dependency credentials. A gateway error following a change is a useful lead, but confirm the mechanism. Correlation becomes stronger when the logged error matches the changed setting.
When a rollback or bounded fix restores service, repeat the affected transaction and watch error rates over a meaningful interval. Verify background work and writes that may have continued after the client timed out. Retrying a non-idempotent action without checking its outcome can create duplicates.
Preserve the sequence of symptoms, diagnostics, and actions. An incident record should explain which gateway failed, which upstream was involved, what evidence established the cause, and how recovery was verified. That is more reusable than a note saying the site needed a restart.
Mistakes to avoid
Do not blindly retry purchases, submissions, or other state-changing requests after a timeout. The server may have completed the operation even though the response was lost or delayed. Check the operation’s status through the application’s supported mechanism.
Avoid changing every proxy timeout simultaneously. You lose the ability to identify the limiting layer and may mask an underlying capacity or dependency problem without resolving it.
Two final recommendations
Add request correlation and upstream timing to the normal observability setup before the next incident. The ability to follow one failing request is more useful than a larger collection of unrelated logs.
Assign an owner to each external dependency and record its timeout and retry policy. Application behavior should remain understandable when that dependency is slow or unavailable.
Conclusion
502 and 504 errors distinguish an invalid upstream response from an upstream wait that exceeded a limit. Both require tracing the reporting gateway and the next service in the chain.
Use logs, endpoint checks, application timing, and recent changes to identify the actual failure before adjusting capacity or timeout settings.
Verify both recovery and transaction outcomes. A careful upstream investigation fixes the cause while reducing the risk of duplicate work or another outage.
