Fixing HTTP to HTTPS Redirects

What a good HTTPS upgrade looks like

A healthy upgrade is boring. Any request to an http:// address gets one response: a 301 (or 308) whose Location is the final https:// address of the same page, on your preferred hostname, with the path and query string unchanged. The next request returns 200.

curl -sI "http://example.co.uk/menu/?table=4" | grep -iE "^HTTP|^location"
HTTP/1.1 301 Moved Permanently
Location: https://www.example.co.uk/menu/?table=4

The Redirect Checker's HTTPS findings usually fall into one of these patterns:

Pages that load over HTTPS but still pull images or scripts over HTTP are a separate problem, covered in fixing mixed content during redirects.

The four addresses to test

A domain usually answers on four combinations of scheme and host. All four should end at one address, and three of them should get there in one hop:

for u in http://example.co.uk/ http://www.example.co.uk/ \
         https://example.co.uk/ https://www.example.co.uk/; do
  echo "== $u"; curl -sIL --max-redirs 5 "$u" | grep -iE "^HTTP|^location"
done

Repeat the test with a deep path such as /contact/?ref=card, because some rules only cover the homepage. If you run subdomains such as shop. or book., test those too, since each needs its own rule and its own certificate coverage.

The one that most often breaks is https:// on the non-preferred host. The browser has to complete a secure connection before the server can say anything, including "go elsewhere". If the certificate only names www.example.co.uk, a visitor typing https://example.co.uk sees a full-page security warning and never reaches your redirect.

The fix, step by step

Example rules

These examples assume the preferred address is https://www.example.co.uk. Swap the host if you prefer the bare domain. Use only one of them, in the layer you chose.

nginx

server {
    listen 80;
    listen [::]:80;
    server_name example.co.uk www.example.co.uk;
    return 301 https://www.example.co.uk$request_uri;
}
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.co.uk;
    # certificate lines here, covering both names
    return 301 https://www.example.co.uk$request_uri;
}

Apache (.htaccess or virtual host)

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.co\.uk$ [NC]
RewriteRule ^ https://www.example.co.uk%{REQUEST_URI} [R=301,L]

The [OR] joins the two conditions, so a request that is insecure, on the wrong host, or both, is sent to the final address in one go. %{REQUEST_URI} keeps the path, and Apache keeps the query string by default.

Application code behind a proxy

// Node.js with Express, behind one trusted proxy
app.set('trust proxy', 1);
app.use((req, res, next) => {
  if (req.secure) return next();
  res.redirect(301, 'https://www.example.co.uk' + req.originalUrl);
});

With trust proxy set, Express reads X-Forwarded-Proto from the proxy to decide whether the request was secure. Without it, every request looks insecure and the redirect loops. Configuration by panel and server is covered in more depth in the Apache and nginx guide and the Plesk and cPanel guide.

HSTS: what it adds and how to avoid a lock-out

A redirect only works after the insecure request has been sent, which means the first request travels unencrypted and could be tampered with. HSTS closes that gap for returning visitors. When a browser sees this header on an HTTPS response, it upgrades every future request for that host itself, before anything leaves the machine:

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

In Chrome's Network panel the browser's own upgrade shows as 307 Internal Redirect. That is not your server, and it will not appear in the Redirect Checker's server-side results. It also means your server rule must stay in place: first-time visitors, crawlers and many tools never see the HSTS header before their first request.

The risk is that HSTS is remembered for the whole max-age. If you set a year with includeSubDomains and an old subdomain has no certificate, that subdomain becomes unreachable in browsers that have seen the header, and lowering the value later only helps once those browsers come back and see the new header. That is why the steps above raise the value gradually.

Edge cases

• The upgrade sends everything to the homepage. A rule that redirects to a fixed address without the path, or a hosting panel's "redirect domain" option pointed at the root, throws away deep links. Rewrite it to append the path.
• Forms that post to http addresses. An old form whose action is http:// gets a 301, and some browsers resend it as a GET, losing the submitted data. Update the form action; for API endpoints, a 308 keeps the method.
• Non-standard ports. A rule built from the Host header can carry a port such as :8080 into the https address. Build the target from a fixed hostname instead.
• Health checks and certificate renewal. Load balancer health checks and certificate validation requests to /.well-known/acme-challenge/ may need to be served over HTTP. Most renewal tools follow a redirect to HTTPS, but some setups exclude that path from the upgrade rule.
• Old domains. A second domain you own that forwards to the main site needs its own certificate if people might type it with https, and should go straight to the final address rather than through the main domain's upgrade.

Keeping the upgrade clean

• Keep the four-address curl loop in your deployment checklist and run it after any server, CDN or certificate change.
• Set up certificate renewal alerts, so an expired certificate on one hostname is caught before visitors see it.
• When you add a subdomain, add it to the certificate and the upgrade rule on day one.
• Store the site's own address with https in the CMS, environment variables and templates, so the site stops generating http links that rely on the redirect.
• Re-run the Redirect Checker on your key URLs every few months, and after any hosting move.