Skip to content
dnsdon

HTTP to HTTPS Redirects, HSTS & Too Many Redirects

Redirect HTTP to HTTPS correctly, fix ERR_TOO_MANY_REDIRECTS loops from Cloudflare Flexible SSL or proxies, and roll out HSTS and preload safely.

8 min read · Updated

Having a valid certificate is only half the job. Visitors still arrive on http://—from old links, bookmarks, or typing the domain without a prefix—and that first unencrypted request can be intercepted. Two settings close the gap: a redirect from HTTP to HTTPS, and HSTS.

Redirect HTTP to HTTPS

Keep port 80 open, but use it for one thing only: a redirect to the same address on HTTPS.

GET http://example.com/pricing
→ 301 Moved Permanently
  Location: https://example.com/pricing

A few details matter:

  • Use a permanent redirect (301 or 308). Temporary codes (302, 307) work, but browsers and search engines won't remember the HTTPS address.
  • Keep the path and query string, so deep links still land on the right page.
  • Go straight to the final address. http://example.com → https://example.com → https://www.example.com works, but each extra hop adds a round trip. Redirect directly to the canonical HTTPS address where you can.

Closing port 80 entirely is an option, but visitors on browsers that don't try HTTPS first will see a connection error rather than your site.

Fixing ERR_TOO_MANY_REDIRECTS after enabling HTTPS

A redirect loop means two parts of your setup each believe the other is wrong and keep sending the visitor back. Browsers give up after about twenty hops and show ERR_TOO_MANY_REDIRECTS. The usual causes:

  • A CDN connecting to your origin over plain HTTP. With Cloudflare's "Flexible" SSL mode, visitors reach Cloudflare over HTTPS but Cloudflare reaches your server over HTTP. If the server redirects HTTP to HTTPS, Cloudflare passes the redirect on, the browser requests HTTPS again, and the cycle repeats. Install a certificate on the origin and switch to "Full (strict)".
  • An application behind a proxy that can't tell the request was HTTPS. The load balancer ends TLS and forwards plain HTTP, so the application keeps redirecting. Configure it to trust the X-Forwarded-Proto header from the proxy.
  • Rules that disagree about the canonical address. One rule sends www to the bare domain and another sends it back. Pick one canonical hostname and make every rule point there.

To see the loop, list each hop:

curl -sIL http://example.com | grep -iE '^(HTTP|location)'

A Location header that repeats a URL you've already seen is the loop.

What is HSTS?

A redirect still involves one plain-HTTP request. Someone on the same network (a public Wi-Fi hotspot, for example) can intercept that request and keep the visitor on an unencrypted copy of the site—an attack known as SSL stripping.

HTTP Strict Transport Security (HSTS, RFC 6797) tells the browser: "for this domain, never use plain HTTP." Once it has seen the header over HTTPS, the browser rewrites every future http:// request to https:// before it leaves the device. It also stops visitors clicking through certificate warnings for that domain.

Strict-Transport-Security: max-age=31536000; includeSubDomains
  • max-age is how long, in seconds, the browser remembers the rule. One year (31536000) is the common choice.
  • includeSubDomains applies the rule to every subdomain too.
  • preload signals that you want the domain built into browsers' HSTS lists (see below).

Rolling out HSTS safely

HSTS is easy to switch on and hard to switch off: browsers remember it for the whole max-age. If HTTPS then breaks, visitors can't bypass the warning. Roll it out in steps:

  1. Make sure every page and resource works over HTTPS, with automated certificate renewal in place.
  2. Start with a short max-age, such as 300 seconds, and check nothing breaks.
  3. Increase to a week, then a month, then a year.
  4. Add includeSubDomains only once you're sure every subdomain supports HTTPS—including internal tools, old marketing sites and mail web interfaces.

If you're testing and need a browser to forget a domain's HSTS rule, Chrome lets you remove it at chrome://net-internals/#hsts under "Delete domain security policies". It only affects your own browser; visitors keep the rule until it expires.

HSTS preload list and requirements

Even with HSTS, the very first visit happens before the browser has seen the header. The HSTS preload list, built into major browsers, removes that gap: listed domains are HTTPS-only from the first request. Requirements include a valid certificate, a redirect from HTTP, and a header with max-age of at least one year plus includeSubDomains and preload.

Preloading is a long-term commitment: removal takes months to reach users' browsers. Only submit domains that will serve HTTPS everywhere, permanently.

Check your setup

The SSL Certificate Checker follows the redirect from http:// step by step, shows each status code, reads the HSTS header and reports common security headers. If you're new to certificates, start with how SSL/TLS certificates work.

Frequently asked questions

Should an HTTP to HTTPS redirect be a 301?
Yes, use a permanent redirect (301 or 308) so browsers and search engines remember the HTTPS address, and keep the path and query string.
Why do I get "too many redirects" after enabling HTTPS?
Two parts of the setup keep redirecting to each other. The most common case is Cloudflare's Flexible SSL mode connecting to an origin that redirects HTTP to HTTPS; switch to Full (strict) with a certificate on the origin.
What is HSTS?
A response header that tells browsers to use only HTTPS for a domain for a set time, which prevents SSL-stripping attacks and stops visitors clicking past certificate warnings.
How do I clear HSTS for a site in Chrome?
Open chrome://net-internals/#hsts and use "Delete domain security policies". It only affects your own browser.