I see HTTP 502 errors when my client makes requests to a website through a Classic Load Balancer. How can I troubleshoot this?
HTTP 502 (bad gateway) errors can occur for one of the following reasons:
- The web server or associated backend application servers running on EC2 instances return a message that can't be parsed by your Classic Load Balancer.
- The web server or associated backend application servers return a 502 error message of their own.
To find the source of these 502 errors:
- Enable ELB access logs on your Classic Load Balancer to see the backend and Elastic Load Balancing (ELB) response code for each request. An access log entry contains two fields: an elb_status_code and a backend_status_code. Use these codes to determine the source of the 502 error.
- View the load balancer CloudWatch metrics to see backend-generated 502 errors, which appear under the HTTPCode_Backend_5XX metric. ELB-generated 502 errors appear under the HTTPCode_ELB_5XX metric.
If the backend response is the source of the ELB 502 error, the issue might be caused by:
- A response containing more than one CRLF between each header.
- A response containing a Content-Length header which contains a non-integer.
- A response has more bytes in the body than the Content-Length header value.
If the 502 error is generated by your backend servers, contact your application's owner. If the 502 error is generated by the Classic Load Balancer, the HTTP response from the backend is malformed. Follow these steps to troubleshoot ELB-generated 502 errors:
1. Check if the response body returned by the backend application complies with HTTP specifications as mentioned in the following RFCs:
RFC 7230 - HTTP/1.1: Message Syntax and Routing
RFC 7231 - HTTP/1.1: Semantics and Content
RFC 7232 - HTTP/1.1: Conditional Requests
RFC 7233 - HTTP/1.1: Range Requests
RFC 7234 - HTTP/1.1: Caching
RFC 7235 - HTTP/1.1: Authentication
2. Confirm that the response header has the correct syntax: a key and the value, such as Content-Type:text. Be sure that Content-Length or transfer encoding is not missed in the HTTP response header. For more information about web server HTTP header fields, see List of HTTP header fields. Examine the HTTP responses returned by running a command similar to the following:
curl -vko /dev/null server_instance_IP
3. Check the ELB access log for duplicate HTTP 502 errors. 502 errors for both elb_status_code and backend_status_code indicate that there is a problem with one or more of the web server instances. Identify which web server instances are exhibiting the problem, then check the web server logs of the backend web server instances. See the following log locations for some common web servers and operating systems:
- The web server logs for CentOS, RHEL, Fedora, and Amazon Linux are located in the /var/log/httpd/ directory.
- The web server logs for Debian and Ubuntu Linux are located in the /var/log/apache2 and /var/log/lighthttpd/ directory.
- The nginx access log location is defined in the nginx.conf file: access_log /path/to/access.log
- The default location is /var/log/nginx/access.log
The web server logs for Windows IIS 7, IIS 7.5 and IIS 8.0 are stored in the inetpub\logs\Logfiles directory. For more information about the Internet Information Server (IIS) logs, see The HTTP status code in IIS 7.0, IIS 7.5, and IIS 8.0. If you confirmed that your 502 errors are ELB-generated and that your backend's response conforms to RFC conventions, contact AWS Support.