How do I troubleshoot HTTP 502 errors when I make requests through a Classic Load Balancer?

Short description

HTTP 502 (bad gateway) errors can occur for one of the following reasons:

• The web server or associated backend application servers that run on Amazon Elastic Compute Cloud (EC2) instances return a message. Your Classic Load Balancer can't parse the message.
• The web server or associated backend application servers return a 502 error message of their own.

To find the source of 502 errors:

• Turn on access logs on your Classic Load Balancer to view the backend and response code for each request. An access log entry contains an elb_status_code and a backend_status_code field. Use these codes to determine the source of the 502 error.
• Check the load balancer's Amazon CloudWatch metrics to view backend-generated 502 errors that appear under the HTTPCode_Backend_5XX metric. ELB 502 errors appear under the HTTPCode_ELB_5XX metric.

If the backend response is the source of the 502 error, then the following responses can cause the issue:

• More than 1 CRLF between each header. For more information, see Core rules on the Datatracker website.
• A Content-Length header that contains a non-integer.
• More bytes in the body than the Content-Length header value.

If your backend servers generate the 502 error, then contact your application's owner. If the Classic Load Balancer generates the 502 error, then the HTTP response from the backend is malformed.

Resolution

To troubleshoot ELB 502 errors, complete the following steps:

1. Check if the response body that the backend application returns complies with HTTP specifications. Refer to the following documentation on the Datatracker website:
   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 key and the value syntax, such as Content-Type:text. Be sure that Content-Length or transfer encoding isn't missed in the HTTP response header. For more information about web server HTTP header fields, see the Permanent message header field names on the Internet Assigned Numbers Authority (IANA) website. To review the returned HTTP responses, run the following command:

   curl -vko /dev/null server_instance_IP

3. Check the access log for duplicate HTTP 502 errors. 502 errors for both elb_status_code and backend_status_code show that there's an issue with a backend web server instance. Identify the web server instance that's experiencing the issue, then check the web server logs. See the following log locations for common web servers and operating systems (OSs):
   Apache logs
   For CentOS, RHEL, Fedora, and Amazon Linux: /var/log/httpd/ directory.
   For Debian and Ubuntu Linux: /var/log/apache2 and /var/log/lighthttpd/ directories.
   NGINX logs
   Defined in the nginx.conf file: access_log /path/to/access.log. The default location is /var/log/nginx/access.log.
   IIS logs
   For Windows IIS 7, IIS 7.5 and IIS 8.0: inetpub\logs\Logfiles directory. For more information about the Internet Information Server (IIS) logs, see HTTP status codes in IIS on the Microsoft website.
   Note: If you confirmed that Elastic Load Balancing generated your 502 errors and that your backend response conforms to RFC conventions, then contact AWS Support.

Related information

Troubleshoot a Classic Load Balancer: Response code metrics

Health checks for the instances for your Classic Load Balancer

Elastic Load Balancing connection timeout management