Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

CloudFront 502 Bad Gateway ERROR

0

Hello,

I made a Pay-as-you-go CloudFront distribution with a Custom Origin outside AWS, to a website that runs at a hosting provider Bluehost: https://pfa.mihaiadam.com . I used the valid SSL certificate of the Origin site in Certificates Manager and then in Cloud Front. The CloudFront Origin is a sub-domain of a Bluehost main domain. The CloudFront alternate domain name is same as the Origin sub-domain. The origin protocol in CloudFront is HTTPS. Bluehost sub-domain works from web browser. The CloudFront origin domain exactly matches the domain name on the SSL certificate of the origin server. These are Cipher Suites of Bluehost.

The configuration does not work with this error in web browser when using the links : https://<Distribution domain name>.cloudfront.net/ or https://pfa.mihaiadam.com (configured through AWS CloudFront with Route53 Record type A and Alias: Distribution domain name) .

502 Bad Gateway ERROR
The request could not be satisfied.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront) HTTP3 Server
Request ID: jBnJbcROSbpKxf_Q6AwcphMrzK25DT7kGsgt2ZYg14hzJuj9_CJlew==

I suppose that there is a connection error between AWS and Custom Origin outside AWS. It could be due to the SSL certificates.
The error log from CloudFront is:

{
    "date": "2026-06-26",
    "time": "15:10:08",
    "x-edge-location": "<edge-location-id>",
    "sc-bytes": "1171",
    "c-ip": "<my_ip>",
    "cs-method": "GET",
    "cs(Host)": "d1loy92691gahb.cloudfront.net",
    "cs-uri-stem": "/",
    "sc-status": "502",
    "cs(Referer)": "-",
    "cs(User-Agent)": "Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/149.0.0.0%20Safari/537.36%20Edg/149.0.0.0",
    "cs-uri-query": "-",
    "cs(Cookie)": "-",
    "x-edge-result-type": "Error",
    "x-edge-request-id": "5lBxiNAjX-z5iucNEWaJ1rdG_CjZMvDJyEef3OK92kSwOpoxg6H7UA==",
    "x-host-header": "d1loy92691gahb.cloudfront.net",
    "cs-protocol": "https",
    "cs-bytes": "497",
    "time-taken": "1.027",
    "x-forwarded-for": "-",
    "ssl-protocol": "TLSv1.3",
    "ssl-cipher": "TLS_AES_128_GCM_SHA256",
    "x-edge-response-result-type": "Error",
    "cs-protocol-version": "HTTP/2.0",
    "fle-status": "-",
    "fle-encrypted-fields": "-",
    "c-port": "60446",
    "time-to-first-byte": "1.027",
    "x-edge-detailed-result-type": "OriginCommError",
    "sc-content-type": "text/html;%20charset=UTF-8",
    "sc-content-len": "932",
    "sc-range-start": "-",
    "sc-range-end": "-",
    "c-country": "RO",
    "cache-behavior-path-pattern": "*"
}

The only debugging log is the one above and SSL viewer from https://www.ssllabs.com/ssltest/. Could you please specify which is the AWS IP that connects to the Custom Origin website, so that to check if the request reach the website ? Is there other way to debug this ? Could you please specify how to fix this ?

Thank you,

Topics
Networking & Content DeliverySecurity, Identity, & Compliance
Tags
Amazon CloudFrontAWS Certificate Manager
Language
English

asked 2 months ago90 views

3 Answers
0
Accepted Answer

Hi,

I tested your origin directly and the SSL story checks out — the cert (CN=pfa.mihaiadam.com, Let's Encrypt) is valid, the chain verifies (return code: 0), TLS 1.2/1.3 are both supported, and a direct curl https://pfa.mihaiadam.com/ returns HTTP 200 from Apache. So the "incomplete chain / cipher mismatch" theory is almost certainly not your problem. OriginCommError here is a connection-level failure, not a cert rejection.

Most likely root cause: a self-referential origin loop

You wrote:

"The CloudFront alternate domain name is same as the Origin sub-domain" + "Route53 Record type A and Alias: Distribution domain name"

That's the smoking gun. You have:

  • Origin domain = pfa.mihaiadam.com
  • Alternate domain name (CNAME) = pfa.mihaiadam.com
  • Route53 pfa.mihaiadam.com A-alias → the CloudFront distribution

When these are the same name, CloudFront resolves its origin hostname pfa.mihaiadam.com via public DNS → which (via your Route53 alias) points back to CloudFront → CloudFront talks to itself → OriginCommError / 502. It also explains why even the *.cloudfront.net URL 502s: the loop is on the origin side, independent of how you reach the edge.

Fix: the origin hostname must differ from the name you point at CloudFront

  1. In Bluehost/Route53, create a separate hostname for the origin, e.g. origin.mihaiadam.com (A record → 74.220.219.204, the Bluehost IP), not aliased to CloudFront.
  2. Issue/extend the Bluehost SSL cert to cover that origin hostname (SAN), so CloudFront→origin HTTPS still matches.
  3. Set CloudFront Origin domain = origin.mihaiadam.com.
  4. Keep Alternate domain name = pfa.mihaiadam.com, and keep the Route53 alias pfa.mihaiadam.com → CloudFront.
  5. Set Origin Protocol Policy = HTTPS only, and forward the Host header — on Bluehost shared hosting the vhost routing needs the right Host, so use the managed origin request policy AllViewer or a custom policy that forwards Host.

Note: right now pfa.mihaiadam.com resolves to the Bluehost IP (not CloudFront), so either you reverted the alias to keep the site up, or DNS is mid-propagation. Confirm the current state — the loop occurs whenever that alias is actually pointing at CloudFront while it's also the origin.

Your direct question — "which AWS IP connects to the origin?"

CloudFront does not use a single IP. Origin-facing edge servers come from a published, rotating range. Get them from the official list:

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
  | jq -r '.prefixes[] | select(.service=="CLOUDFRONT_ORIGIN_FACING") | .ip_prefix'

Then grep your Bluehost/Apache access + error logs and any ModSecurity/firewall logs for those ranges around the failure timestamp — that tells you whether the request even reached Bluehost.

If the origin hostname is already distinct (no loop)

Then the next suspect is Bluehost blocking CloudFront. Shared hosting frequently has ModSecurity, a WAF, rate limiting, or geo/UA rules that drop non-browser or datacenter-sourced requests. That also surfaces as OriginCommError. Ask Bluehost to check their security logs for blocks from the CloudFront origin-facing ranges, and to allow them.

Quick way to disambiguate the two causes

Temporarily change the CloudFront Origin domain to a distinct origin. name (or the raw Bluehost host) and test the *.cloudfront.net URL:

  • If it starts working → it was the self-reference loop.
  • If it still 502s with the origin healthy → it's Bluehost-side blocking.
AWS

answered a month ago

0

Based on the error log showing "OriginCommError" with a 502 status, CloudFront is unable to establish a connection with your Bluehost origin server. Here are the key areas to investigate and potential solutions:

SSL/TLS Certificate Validation: When CloudFront connects to your origin over HTTPS, it validates the origin's SSL/TLS certificate against several conditions:

  • The certificate must match the requested domain name (either in the Common Name or Subject Alternative Name fields)
  • The certificate must be issued by a trusted certificate authority
  • The certificate chain must be complete and in the correct order
  • The certificate must not be expired

If any of these conditions aren't met, CloudFront will drop the connection and return a 502 error. Since you mentioned the origin domain exactly matches the certificate, verify that the complete certificate chain (including all intermediate certificates) is properly installed on your Bluehost server.

Cipher Suite and Protocol Compatibility: CloudFront must be able to negotiate a secure connection using ciphers and protocols supported by both CloudFront and your origin. If your origin doesn't respond with supported ciphers or protocols, the connection will fail. You can verify your origin's SSL/TLS configuration supports the required protocols and ciphers that CloudFront uses.

Firewall and Port Configuration: Ensure that your Bluehost hosting allows incoming HTTPS connections on port 443 from CloudFront's IP ranges. CloudFront uses a large set of IP addresses that can change, so rather than allowlisting specific IPs, you should ensure your origin accepts HTTPS traffic from any source, or configure your firewall to allow CloudFront's published IP ranges.

Debugging Steps:

  1. Test your origin directly via HTTPS from a browser to confirm it's accessible
  2. Use OpenSSL to test the SSL/TLS connection: openssl s_client -connect pfa.mihaiadam.com:443 -servername pfa.mihaiadam.com
  3. Verify the complete certificate chain is present and in the correct order
  4. Check with Bluehost to ensure there are no firewall rules blocking incoming connections
  5. Confirm your origin responds on port 443 for HTTPS requests

Important Note About Certificate Manager: You mentioned using the origin's SSL certificate in Certificate Manager and CloudFront. To clarify: the certificate you associate with your CloudFront distribution (for viewer-to-CloudFront communication) is separate from the certificate on your origin server (for CloudFront-to-origin communication). The origin server must have its own valid certificate installed by your hosting provider.

The most common cause of this error with custom origins is an incomplete certificate chain or firewall restrictions at the origin. I recommend working with Bluehost support to verify the SSL certificate installation is complete and that their firewall allows incoming HTTPS connections from CloudFront.
Sources
HTTP 502 status code (Bad Gateway) - Amazon CloudFront
Require HTTPS for communication between CloudFront and your custom origin - Amazon CloudFront
Requirements for using SSL/TLS certificates with CloudFront - Amazon CloudFront
Origin HTTPS configuration - Secure Content Delivery with Amazon CloudFront

answered 2 months ago

EXPERT

reviewed 2 months ago

0

Hello.

Please verify whether CloudFront is forwarding the Host header to the origin, in addition to the information provided in the re:Post Agent's automated AI response.
If CloudFront does not forward the Host header to the origin, a certificate error will occur even if the origin's SSL certificate matches the CloudFront domain.
https://repost.aws/knowledge-center/cloudfront-502-errors

The host header's domain name for incoming viewer host headers that the request forwards to the origin in the CloudFront distribution.

Regarding host header forwarding, as described in the documentation below, please try either creating a custom cache policy or changing the origin request policy to "AllViewer".
https://repost.aws/knowledge-center/configure-cloudfront-to-forward-headers
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html

EXPERT

answered 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content