My web client receives an HTTP 502 error message when making requests to a website through a Classic Load Balancer.

HTTP 502 (Bad Gateway) errors can occur if either the web server or associated backend application servers running on EC2 instances return a message that cannot be parsed by your Classic Load Balancer (ELB) OR if the web server or associated backend application servers return a 502 error message of their own.

Either the Classic Load Balancer or your backend servers could generate a 502 response; however, this guide covers ELB-generated 502 errors. For troubleshooting backend 502 errors, contact your application's owner.

1.    To find out the source of your 502 errors:
        Enable ELB access logs on your Classic Load Balancer. With these logs, you can see the backend and ELB response code for each request. An access log entry contains (among other information), two fields: elb_status_code and backend_status_code. Use these codes to determine the source of the 502 error.
        You can also view the load balancer Cloudwatch metrics. Backend-generated 502 errors appear under the metric 'HTTPCode_Backend_5XX', whereas ELB-generated 502 errors appear under the metric 'HTTPCode_ELB_5XX'.

2.    If the source of your 502 errors is the load balancer, this means that the HTTP response from the backend is malformed. Use the following steps to find out why.

1.    Check if the response body returned by the back-end application complies with HTTP specifications as mentioned in the following RFCs (which supersede RFC 2616):

2.    Confirm that the header has the correct syntax; for example, it is in the form of a key and the value (such as content-type:text). Ensure that content-length or transfer encoding is not being missed in the HTTP response header. For more information about web server HTTP header fields, see List of HTTP header fields. HTTP responses can also be examined in the HTTP response that is returned by running a command similar to the following:

curl -vko /dev/null server_instance_IP

Note: Curl for Windows can be downloaded from the CURL / Download website.

3.    Check the ELB access logs for duplicate or successive HTTP 502 errors, which indicate that there is a problem that needs to be addressed on 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. Here are the log locations for some common web servers and operating systems.

Apache logs

  • 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.

Nginx logs

  • The nginx access log location is defined in the nginx.conf file.  It takes the form "access_log /path/to/access.log"
  • The default location is /var/log/nginx/access.log

IIS logs

  • 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 have confirmed that your 502 errors are ELB-generated and that your backend's response conforms to RFC conventions, go to the AWS Support Center for assistance.

Examples of backend responses which will cause an ELB 502 error:

  • A response containing two sets of CRLF in a row. As specified in RFC 7230, a single CRLF denotes the end of HTTP headers.
  • A response containing a "content-length" header which contains a non-integer. As specified in RFC 7230, this header must be an integer.

Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center

Published: 2016-09-09

Updated: 2017-09-06