Redirect HTTP to HTTPS the Right Way
301 vs 308, the redirect-then-HSTS order, and the loop mistakes that take sites down. Copy-paste configs for Nginx, Apache and Cloudflare.
Short answer
Serve a permanent redirect from every HTTP URL to the HTTPS equivalent, then enable HSTS on HTTPS responses. Pick one canonical host (www or apex) to avoid loops.
Order matters
The redirect catches first-time and legacy links. HSTS stops the browser from speaking HTTP after the first good HTTPS visit.
You want both. Redirect alone leaves a first-request downgrade window; HSTS alone does not help visitors who never arrived on HTTPS.
Readers skimming redirect http to https often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.
Loop traps
CDN forcing HTTPS while origin redirects back to HTTP, or www fighting apex, will create redirect loops.
Fix one layer at a time and test with curl -I, following redirects carefully until you see a single clean chain.
Common failure mode for redirect http to https: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.
Platform notes
Cloudflare Always Use HTTPS helps when traffic is proxied. Still fix origin for direct access and for services that bypass the CDN.
Document the canonical host so every app, sitemap, and email link agrees.
If this section on redirect http to https becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.
What to do this week
- Choose apex or www as the only canonical host.
- 301/308 all HTTP to HTTPS on that host.
- Enable HSTS on the HTTPS responses.
- curl -I http://... and confirm a clean redirect chain.
Redirect first. HSTS second. One canonical host always.
Update log (1)
2026-05-17Editorial form rewrite for length and uniqueness.
Sources + verification
Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.
