Amazon CloudFront
Developer Guide (API Version 2016-09-29)

Troubleshooting CloudFront Response Errors

When CloudFront requests an object from your Amazon S3 bucket or custom origin server, your origin sometimes returns an HTTP 4xx or 5xx status code, which indicates that an error has occurred. The HTTP protocol uses response headers to specify an HTTP status code. If CloudFront returns HTTP status code 502 (Bad Gateway), it means that CloudFront can’t serve the requested object because it can’t connect to the origin server. The following sections describe common causes for the error and possible solutions.

HTTP Status Code 502 (Bad Gateway)

An HTTP 502 status code (Bad Gateway) indicates that CloudFront was not able to serve the requested object because it could not connect to the origin server.

SSL/TLS Negotiation Failure Between CloudFront and the Origin Server

When you're using a custom origin, the SSL/TLS certificate that is installed on your origin includes a domain name in the Common Name field and possibly several more in the Subject Alternative Names field. (CloudFront supports wildcard characters in certificate domain names.) One of the domain names in the certificate must match one or both of the following values:

  • The value that you specified for Origin Domain Name for the applicable origin in your distribution.

  • The value of the host header if you configured CloudFront to forward the host header to your origin. For more information about forwarding host uheaders to your origin, see Configuring CloudFront to Cache Objects Based on Request Headers.

If the domain names don’t match, the SSL/TLS handshake fails, and CloudFront returns an HTTP status code 502 (Bad Gateway) to the viewer.

To check if the domain names match, you can use SSL Labs:

  • SSL Labs

    Type the domain name of your origin in the Hostname field, and then choose Submit. Review the Common names and Alternative names fields from the test to see if they match your origin’s domain name.

To check your connection, you can use Open SSL:

  • Open SSL

    1. For SNI (Server Name Indication): openssl s_client –connect domainname:443 –servername domainname

    2. For non-SNI: openssl s_client –connect domainname:443

Replace the domainname in the command with the origin domain used to configure the CloudFront distribution that you want to test.

These commands are used to make an SSL connection to an origin, which outputs the details about the certificate used for the handshake. You can use them to verify that the certificate on your origin is correctly configured.


If you are not forwarding the Host header, replace domainname with your origin’s domain name. If you are forwarding the Host header, replace domainname with the CNAME that you are using with your CloudFront distribution.

If you don't see your origin’s domain name in the SSL Labs test, or if you are unable to connect using OpenSSL, then the certificate on your origin likely isn't using the domain name or subject alternative name (CNAME) that CloudFront would use in the connection.

If you’re using AWS Certificate Manager (ACM), see Request a Certificate in the AWS Certificate Manager User Guide to request a new certificate.

Origin Is Not Responding with Supported Ciphers/Protocols

CloudFront connects to origin servers using ciphers and protocols. For a list of the ciphers and protocols that CloudFront supports, see Supported Ciphers and Protocols. If your origin does not respond with one of these ciphers or protocols in the SSL/TLS exchange, CloudFront fails to connect. You can validate that your origin supports the ciphers and protocols by using SSL Labs:

  • SSL Labs

    Type the domain name of your origin in the Hostname field, and then choose Submit. Review the Common names and Alternative names fields from the test to see if they match your origin’s domain name.

    After the test is finished, find the Protocols and Cipher Suites sections in the test results to see which ciphers or protocols are supported by your origin. Compare them with the list of Supported Ciphers and Protocols.


If you’re using Elastic Load Balancing, see SSL Security Policies for Elastic Load Balancing in the Elastic Load Balancing User Guide to learn how to set the ciphers and protocols. Using the Predefined Security Policy ELBSecurityPolicy-2016-08 gives CloudFrontaccess to your elastic load balancer. If you want to restrict it further using a custom policy, you must allow the ciphers that CloudFront supports.

SSL/TLS Certificate on the Origin Is Expired, Invalid, Self-signed, or the Certificate Chain Is in the Wrong Order

If the origin server returns the following, CloudFront drops the TCP connection, returns HTTP status code 502 (Bad Gateway), and sets the X-Cache header to Error from cloudfront:

  • An expired certificate

  • Invalid certificate

  • Self-signed certificate

  • Certificate chain in the wrong order


If the full chain of certificates, including the intermediate certificate, is not present, CloudFront drops the TCP connection.

For information about installing an SSL/TLS certificate on your custom origin server, see Requiring HTTPS for Communication Between CloudFront and Your Custom Origin.

Origin Is Not Responding on Specified Ports in Origin Settings

When you create an origin on your CloudFront distribution, you can set the ports that CloudFront connects to the origin with for HTTP and HTTPS traffic. By default, these are TCP 80/443. You have the option to modify these ports. If your origin is rejecting traffic on these ports for any reason, or if your backend server isn’t responding on the ports, CloudFront will fail to connect.

To troubleshoot these issues, check any firewalls running in your infrastructure and validate that they are not blocking the supported IP ranges. For more information, see AWS IP Address Ranges in the Amazon Web Services General Reference. Additionally, verify whether your web server is running on the origin.