Troubleshooting 502, 503, and 504 errors can be frustrating because they often signify communication problems between the browser and one or more of the following: web server, reverse proxy, application server, database, or other back-end services.
For Web Application Development teams, learning the differences between these errors can simplify the debugging process, as each status code indicates a different type of failure.
What Do 502, 503, and 504 Errors Mean?
From a user perspective, these errors may appear similar, but they occur for different reasons. A request may pass through multiple layers of infrastructure before reaching the application, and a failure at any of those layers can cause an infrastructure response to be broken.
502 Bad Gateway: The proxy or gateway received an invalid response from an upstream server.
503 Service Unavailable: The server is currently unable to handle the request.
504 Gateway Timeout: The gateway waited too long for an upstream server to respond.
Knowledge of which error has occurred provides a starting point for the developers to locate the failed component.
Why Does a 502 Bad Gateway Error Happen?
A 502 error is typically seen when a reverse proxy or gateway is unable to communicate with the backend application. It is possible for a proxy to be functioning correctly, but for an upstream service to be unavailable or to give an unwanted response.
Some reasons for this may include:
Application crashes: The backend service process may have terminated due to a bug, out of memory exception, or configuration problem.
Incorrect proxy configuration: Wrong ports, pstream addresses, or protocols can lead to communication breakdowns.
Invalid backend responses: The application can suddenly close the connection or return partial/invalid data.
Unavailable upstream services: A dependent application/service may have stopped responding.
Developers should check proxy and application logs, not simply restart the server. This helps identify if the problem is with the proxy, the backend process, or a dependent service.
Why Does a 503 Service Unavailable Error Happen?
A 503 error indicates that the server is reachable but is currently unable to process the request. This is usually the case when the server is overloaded, unavailable, or is being worked on.
Some reasons may include:
Server resource exhaustion: This can be the case when the CPU, memory, workers, or connection limits have been exceeded.
Application downtime: The backend process is not available, but the web server remains active.
Maintenance: The application is returning a 503 to indicate that maintenance is in progress.
Dependency failure: A database/service is unavailable.
In Web Development, it is important to monitor these dependencies because the main application can be available, but a supporting service can cause an outage.
Why Does a 504 Gateway Timeout Error Happen?
A 504 indicates that a proxy/gateway exceeded the timeout for an upstream service. A 502 can indicate the same thing, but the backend may still be processing the request.
Things that usually cause this problem are:
- Slow database queries
- Protracted backend operations
- Unresponsive third-party services
- Network delays between servers
- Misconfigured timeouts
Increasing the timeout will only temporarily fix the problem. Developers should find the reason for the long request and determine if the operation can be improved or if it can be performed in the background.
How to Troubleshoot 502, 503, and 504 Errors
When troubleshooting these errors, developers should follow the request path when trying to resolve the issue. This structured approach helps narrow down the failing component of the path.
Identify the Source
The first step in resolving these errors is determining whether the issue is with the CDN, load balancer, reverse proxy, web server, or the application itself. Often, the answer can be found in the response headers or infrastructure logs.Check Application Logs
The logs should be searched for around the time the error occurred. Exceptions, crashed processes, and dependency failures can all be found in the logs and can help determine the cause of the error.Check Server Resources
Check the CPU, memory, and disk space usage. Also check the active connections and worker processes. Resource exhaustion can cause 503 errors and can eventually become 504 errors.Check Proxy Logs
There are proxy logs for Nginx, Apache, HAProxy, and cloud load balancers. Refused connections and upstream timeouts will often be logged, but not necessarily in the application logs.Test Dependencies
If the application is communicating with a database, internal API, queue, or a third-party service, then those should be tested as well. This helps determine if the application is failing or if it is communicating with a service and is essentially stuck waiting.
How to Prevent These Errors
Reliable communication between all the layers of the application helps avoid gateway errors. A Web Application Development Company will help build a reliable infrastructure and consider both the application code and the infrastructure.
Some helpful practices include:
- Set appropriate connection and response timeouts.
- Monitor the health of the application and the server resources.
- Use reliable process managers for the backend services.
- Improve slow database operations.
- Move heavy tasks to background workers.
- Watch both external and internal dependencies.
- Set up load balancers and reverse proxies correctly.
- Keep application and infrastructure logs centralized.
Health checks and automatic alerts are useful because they can alert developers of increasing error rates, as opposed to waiting for users to complain about an outage.
Final Thoughts
Although they look similar, 502, 503, and 504 errors indicate different issues. An invalid upstream response causes 502 errors, 503 indicates that a service is unavailable temporarily, and 504 indicates that an upstream service has taken too long to respond.
The correct approach is to figure out what layer is failing, look at the logs, check the resources, and evaluate the dependencies. With an appropriate monitoring strategy, as well as timeouts configured correctly, and the right architecture, backend management, and a resilient architecture, these types of errors can be greatly reduced, and more reliable web applications can be created.
Top comments (0)