AWS CloudFront 502 Bad Gateway: Fix Origin TLS, DNS, and Connection Errors

CloudFront returning 502 Bad Gateway usually calls for a different investigation from a 403 permission failure. Start with the connection between CloudFront and its origin, then check edge-function failures if the origin checks pass.

Quick Fix

Request one known failing path, record its response headers, and inspect the CloudFront detailed result in logs. Verify that the configured origin resolves, accepts connections on the configured port, and presents a valid TLS certificate for the hostname CloudFront validates.

Do not disable certificate validation or change the origin to HTTP as a permanent fix.

Capture a Reproducible Request

Use a real GET request so a server with different HEAD behavior does not confuse the investigation:

curl -sS -D - -o /dev/null https://cdn.example.com/health

Replace the example hostname and path. Record the timestamp and CloudFront request ID. The X-Cache error header is a clue that an error was served, not conclusive proof of the failing component.

Compare this request with a direct origin request from an authorized environment. If direct access is intentionally restricted to CloudFront, a denied request from your laptop does not prove the origin is broken.

Check the Origin Certificate

CloudFront terminates viewer HTTPS and may create a separate HTTPS connection to the origin. The certificate seen in your browser therefore does not prove the origin certificate is valid.

Inspect the origin handshake with the hostname expected by the origin configuration:

openssl s_client \
  -connect origin.example.com:443 \
  -servername origin.example.com \
  -verify_hostname origin.example.com \
  -verify_return_error </dev/null

Check expiration, the certificate chain, and hostname coverage. If you forward the viewer Host header, review AWS's matching rules for that configuration instead of assuming the origin domain alone is the intended name.

For an ALB origin, the origin certificate belongs in the ALB's Region. The separate CloudFront viewer ACM certificate uses us-east-1.

Check DNS and Reachability

For an ordinary public custom origin, confirm its configured DNS name resolves publicly:

nslookup origin.example.com

Review recent DNS changes, deleted load balancers, and records that accidentally point back to the same CloudFront distribution. VPC origins use a different connectivity model, so apply their specific configuration requirements.

Confirm the origin protocol policy and port agree with the actual listener. Then inspect security groups, network ACLs, firewall rules, and origin health. Increasing timeouts does not repair a certificate mismatch or nonexistent DNS name.

Check Edge Functions

If the connection checks are clean, inspect associated functions and their logs. Lambda@Edge validation errors and invalid function responses can produce errors even when the origin is healthy.

Review recent code changes and the event association. A function that produces malformed headers or an invalid response needs a code correction, not an S3 bucket-policy change.

Verify the Correction

Wait for the relevant distribution change to deploy. Repeat the exact failing request and a second known-good request. Check detailed logs and error rates rather than relying on one successful browser refresh.

If CloudFront is serving a cached error, wait for its error cache lifetime or invalidate the affected path. Avoid broad invalidations as a substitute for finding the root cause.

Related Guide

If your response is actually a 403, use the CloudFront permission troubleshooting guide.

Sources

• AWS: CloudFront 502 troubleshooting
• AWS: Origin settings
• AWS: CloudFront certificate requirements