Redirects and HTTPS: fixing loops, chains, and http://

How to make http:// switch to https, point www and the bare domain to one address, and fix redirect loops and long redirect chains.

People reach a site by several addresses: with or without www, with http:// or https://, or through an old link. Redirects send all of them to one address, so everyone ends up on the same secure page.

This page covers the ways they go wrong: an address that doesn’t redirect, one that doesn’t work, a loop, or a chain long enough to slow visitors down.

What SignalDNS checks

We follow the address you enter through every redirect, up to 10, including HTML meta refresh. The redirect tracer shows each step.

In the report, we also request the other addresses people type for the same site:

  • The http:// version, which should end on https://.
  • The www or bare version. For example.com we try www.example.com, and the other way round. It should exist and end at the same address.

These only count once the address itself loads. Other subdomains, such as blog.example.com, aren’t paired with anything. A version we couldn’t check, because of a timeout or a block aimed at our server, is skipped.

What a good setup looks like

Pick one address for the site. Every other version redirects there in one step, keeping the path:

Address                         Status  Location
http://example.com/pricing      301     https://www.example.com/pricing
http://www.example.com/pricing  301     https://www.example.com/pricing
https://example.com/pricing     301     https://www.example.com/pricing
https://www.example.com/pricing 200

Use a permanent redirect, 301 or 308, so search engines show the target address; 302 and 307 are temporary. It doesn’t matter whether you choose www or the bare domain. Google’s advice is to pick one and redirect the others to it.

http:// doesn’t switch to https

The http:// version shows the site over plain HTTP instead of redirecting to https://. Anyone who types the name without https://, or follows an old link, gets an unencrypted page that anyone on the network path can read or change. This needs attention.

How to fix it: if a CDN or host serves the site, turn on its “Always use HTTPS” or “HTTPS only” setting. On your own server, answer port 80 with a redirect. For nginx:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

For Apache, a Redirect in the port 80 virtual host, as Apache’s docs recommend:

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com
    Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

http:// doesn’t load

The http:// version fails: nothing answers on port 80, the connection is refused, or it returns an error. Anyone whose browser or app asks for http:// gets an error instead of your site. This needs attention.

Port 80 matters for certificates too. The ACME HTTP-01 check, which Let’s Encrypt and others use to confirm you control the name, connects on port 80.

How to fix it: allow incoming TCP on port 80 in your firewall or security group, and make the server answer there with the redirect above. If port 80 answers with an error, the redirect rule may be missing for that name.

The www or bare version doesn’t exist or doesn’t load

The other name has no DNS record, so it doesn’t exist, or it exists but fails: the connection or certificate is rejected, or it returns an error. People type both, so anyone who uses the other one gets an error. This needs attention.

How to fix it:

  1. Add a DNS record if it’s missing. www is usually a CNAME to your host. A bare domain can’t be a CNAME; use A or AAAA records, or your DNS provider’s alias feature. See The name has no address.
  2. Cover both names in the certificate. A certificate for example.com alone fails on www.example.com. See The certificate doesn’t match the name.
  3. Add the redirect to your main address, keeping the path.

Both versions load without redirecting

example.com and www.example.com both load, but each stays on its own address, or they end at different pages. The site then has two addresses: links, bookmarks, and shares are split between them, and search engines have to choose one. This needs attention.

We compare the final addresses exactly, so https://example.com/ and https://www.example.com/ count as different even when they show the same page.

How to fix it: choose one and redirect the other to it with a 301, keeping the path, so example.com/pricing goes to www.example.com/pricing, not the home page. In nginx, give the other name its own HTTPS server block:

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and ssl_certificate_key for example.com
    return 301 https://www.example.com$request_uri;
}

Redirect loop

A redirect leads back to an address already visited, so the page never loads. Browsers stop with an error such as ERR_TOO_MANY_REDIRECTS. This is a problem.

The usual causes:

  • A CDN and your server disagree about HTTPS. With Cloudflare’s Flexible mode, Cloudflare connects to your server over plain HTTP. If the server redirects HTTP to HTTPS, every request goes round in a circle. Cloudflare’s fix is to use Full or Full (strict), or remove the server’s redirect.
  • The server can’t see that the visitor used HTTPS. When a load balancer handles HTTPS, the server behind it sees plain HTTP and redirects again. Check the X-Forwarded-Proto header the load balancer adds instead, as Apache’s docs show.
  • Two rules undo each other, such as the host sending www to the bare domain while the CDN sends the bare domain to www.

How to fix it: follow the chain in the redirect tracer to see which addresses repeat and what sends each redirect. Then remove one of the conflicting rules.

The site sets a cookie and redirects back to the same address, expecting the cookie on the next request. Browsers keep it and usually get through. Our server doesn’t keep cookies, so it sees the same redirect again. This is “Couldn’t check”, not a problem.

How to fix it: usually there’s nothing to fix. Open the address in a private browser window to confirm it loads. If scripts and monitoring tools that don’t keep cookies need to reach the page, serve it without requiring the cookie first.

Too many redirects

We follow up to 10 redirects. The site was still redirecting after that, each time to a new address, so we stopped. Google’s crawlers also follow up to 10 redirects by default. This is a problem.

It usually comes from a rule that changes the address a little each time, such as adding a slash or a parameter, or from old moves stacked on top of each other.

How to fix it: look at the chain in the redirect tracer, and point each old address straight at the final one.

Three or more redirects

The address loads, but only after three or more redirects, such as http://example.com to https://example.com to https://www.example.com to https://www.example.com/en/. Each redirect is another request before the page starts loading. This needs attention.

How to fix it: link straight to the final address in your own pages, ads, and profiles. Then change each redirect to go to the final address in one step.

If you plan to join the HSTS preload list, it asks that http:// first redirects to https:// on the same name. That makes two redirects for the other name, which is fine.

HSTS

HTTP Strict Transport Security (HSTS) is a response header that tells browsers to use HTTPS for your site for a set time, even when someone types http://.

Strict-Transport-Security: max-age=31536000; includeSubDomains
  • max-age is how long browsers remember it, in seconds. 31536000 is a year.
  • includeSubDomains covers every subdomain too, so only add it when they all work over HTTPS.
  • Browsers ignore the header over plain http://, so it only works on HTTPS responses.
  • preload asks to be built into browsers. It needs a max-age of at least a year and includeSubDomains, and removal takes months.

Start with a short max-age, such as 300, and raise it in stages. HSTS doesn’t replace the http:// redirect: a browser that hasn’t seen the header yet still needs it.

We show HSTS and other security headers as the site sends them, without a grade, since not every site needs every header.

Your provider’s guides

What we can’t tell from outside

We check from one server without cookies or JavaScript, so a redirect made by a script in the page doesn’t show up. A site that redirects by country or device may send us somewhere different from your visitors. We only pair the bare domain with www. And we can’t see whether a visitor’s browser already has your HSTS policy saved.

Sources

Last reviewed .