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

I see HTTP 502 errors when my client makes requests to a website through a Classic Load Balancer (CLB). How can I troubleshoot this?Short descriptionHTTP 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:Turn on Elastic Load Balancing (ELB) access logs on your Classic Load Balancer to see the backend and 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 Amazon 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 that 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:Resolution1.    Check if the response body returned by the backend application complies with HTTP specifications. Refer to the following documentation from RFC Editor:RFC 7230 - HTTP/1.1: Message Syntax and RoutingRFC 7231 - HTTP/1.1: Semantics and ContentRFC 7232 - HTTP/1.1: Conditional RequestsRFC 7233 - HTTP/1.1: Range RequestsRFC 7234 - HTTP/1.1: CachingRFC 7235 - HTTP/1.1: Authentication2.    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 the Internet Assigned Numbers Authority documentation at List of HTTP header fields. Examine the HTTP responses returned by running a command similar to the following:curl -vko /dev/null server_instance_IP3.    Check the ELB access log for duplicate HTTP 502 errors. 502 errors for both elb_status_code and backend_status_code indicate that there's 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:Apache logsThe 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.NGINX logsThe NGINX access log location is defined in the nginx.conf file: access_log /path/to/access.logThe default location is /var/log/nginx/access.logIIS logsThe 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 Microsoft's documentation at The HTTP status code in IIS 7.0 and later versions. If you confirmed that your 502 errors are ELB-generated and that your backend's response conforms to RFC conventions, contact AWS Support.

Related informationTroubleshoot a Classic Load Balancer: Response code metricsTutorial: Create a Classic Load BalancerIdentity and access management for Elastic Load BalancingConfigure health checks for your Classic Load BalancerElastic Load Balancing Connection timeout management