Why your HTTP to HTTPS redirect isn't working

2026-06-22 · redirects · https · hsts · tls · http

redirectshttpshststlshttp

If an http:// URL doesn't end up on https://, the cause is almost always one of a few concrete misconfigurations: the redirect covers only the apex or only www (not both), nothing is listening on port 80, a CDN or proxy in "Flexible SSL" mode creates a loop, HSTS isn't set yet so the first plaintext hit is unprotected, or a browser/CDN cached an old response. Each has a distinct fix, and the fastest way to tell them apart is to follow the full redirect chain rather than just loading the page.

Coverage gaps: apex vs www

A redirect rule frequently covers only one hostname. If you redirect http://example.com to https://example.com but never handle www, then http://www.example.com either fails outright or lands on a plain-HTTP www page. You need both hostnames covered, ideally collapsing to one canonical host:

http://example.com/      → https://www.example.com/   (301)
http://www.example.com/  → https://www.example.com/   (301)
https://example.com/     → https://www.example.com/   (301)

Test all four entry points (http/https × apex/www), not just the one you usually type.

No listener on port 80

HTTPS lives on port 443, but the first request from a browser typing a bare hostname is plaintext HTTP on port 80. If your server or load balancer only listens on 443, the port-80 request is refused or times out and there is nothing to issue the redirect — so the browser shows a connection error instead of upgrading. You need a listener on port 80 whose only job is to 301 everything to https://. Confirm with curl -I http://example.com; a connection refused or hang points here.

Flexible SSL redirect loops

A CDN or proxy in "Flexible SSL" mode terminates TLS at the edge and speaks plain HTTP to your origin. Your origin sees an HTTP request, "helpfully" redirects it to HTTPS, the edge re-serves it as HTTPS to the browser, the browser comes back, the edge again forwards plain HTTP to the origin — and you get ERR_TOO_MANY_REDIRECTS. The fix is to make the origin trust the edge's TLS: switch the CDN to "Full" (or "Full strict") mode so it talks HTTPS to the origin, or have the origin honor the forwarded protocol header (e.g. X-Forwarded-Proto: https) instead of redirecting.

edge → origin:  X-Forwarded-Proto: https   # origin must NOT redirect this

HSTS isn't doing the upgrade yet

HSTS does not replace the redirect — it makes the browser skip plaintext on subsequent visits. The very first time a browser sees your domain it still tries HTTP, so you always need a real port-80 redirect. HSTS is the belt-and-suspenders layer that closes the first-hit window on return visits; add it only after the HTTPS redirect is verified working end to end.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Cached redirects and how to verify

A previous 302 or a missing redirect can be cached by the browser or the CDN, so you keep seeing old behavior after fixing the config. Test in a fresh private window, purge the CDN cache, and prefer a 301 only once the rule is correct (it caches hard). The reliable check is to trace the whole chain: walk from the plaintext entry point through every hop to the final 200, watching the status code and Location at each step. The redirect checker does exactly this.

Trace your full redirect chain →