Chrome 154 Warns Before HTTP in October — Your Redirect Chain Is the Real Exposure

In October 2026, with the release of Chrome 154, Chrome will enable the "Always Use Secure Connections" setting by default for every user. When Chrome cannot reach a public site over HTTPS but thinks it can reach it over plaintext HTTP, it will stop and ask the user for permission first — a full-page interstitial, not a URL bar icon.

Google announced this a year in advance, which is unusually generous notice for a default change of this size. Most teams read the announcement, checked that their site loads over HTTPS, and moved on.

That check is not sufficient. The warning does not fire on your final destination URL. It fires on any hop along the way.

The part everyone skips

Here is the scenario straight out of Chrome's adoption guide:

You serve your site at https://www.example.com. Someone types example.com in the omnibox. Your apex domain redirects http://example.com to http://www.example.com, which in turn redirects to HTTPS. The apex is not configured to answer on port 443 at all.

Chrome tries https://example.com first, fails to connect, and shows the warning — even though clicking through lands the user on a perfectly valid HTTPS page. As the Chrome team puts it, "this exposure to insecure HTTP during redirects is a key risk that Chrome is trying to address."

This pattern is everywhere, and it is invisible in normal testing because the address bar shows the padlock by the time you look at it. Common sources:

• Apex domains that only listen on port 80 and hand off to www over HTTP.
• Vanity and campaign domains — getourapp.com, try-example.com — registered years ago through a domain forwarding service that never got a certificate.
• Link tracking redirectors in email and ad platforms. Multiple insecure hops in one chain means the user can see the warning more than once on a single navigation.
• Legacy acquisitions and rebrands where the old hostname still forwards traffic.

If any of these are in your inbound path, some fraction of your users hits an interstitial before your homepage renders. That is a conversion problem before it is a security problem.

Audit it in five minutes

Do not reason about your redirect chains. Trace them. curl will print every hop:

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

You are looking for any location: header whose value starts with http://. Run it against every hostname that can send you traffic — apex, www, old brand domains, regional variants, short links:

for host in example.com www.example.com getexample.com blog.example.com; do
  echo "== $host"
  curl -sIL "http://$host" | grep -Ei '^(HTTP/|location:)'
done

The second, equally important check is whether the hostname answers on HTTPS at all. A domain that only listens on port 80 is exactly the case Chrome warns about:

curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com \
  || echo "no HTTPS listener on example.com"

You can also turn the warning on for yourself right now. Chrome's own recommendation is to enable "Always Use Secure Connections" for public sites at chrome://settings/security and then use your product normally — including the paths your users take, not just the ones you bookmark. Every time the interstitial appears, note the hostname in the URL bar. That list is your work queue.

For deeper inspection, the Network panel in DevTools shows each redirect hop with its scheme, which is useful when the chain runs through a third-party redirector you cannot curl directly.

Fixing the apex

The fix is almost always the same shape: give the hostname a certificate and a 443 listener, then redirect from HTTPS to HTTPS.

# Apex: answer on HTTPS, then redirect to canonical www
server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

# Port 80 stays, but only to upgrade the scheme in place
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

The key detail is that the apex now has its own certificate and its own 443 block. Redirecting on port 80 is still worth keeping for clients that arrive there, but it is not what saves you — Chrome tries HTTPS first, and if nothing answers, the warning fires before your redirect ever runs.

If you run your own servers, the Mozilla SSL Configuration Generator produces sane TLS settings for most stacks, and Apache, nginx, and Caddy all now support ACME natively for automatic certificate issuance. If you use a managed host, domain forwarder, or CDN, this is usually a checkbox — but it is a checkbox someone has to find. Ask the provider explicitly whether the forwarding hostname terminates TLS, not whether your site "supports HTTPS."

Once every hop is clean, HSTS makes the guarantee durable. With Strict-Transport-Security set, Chrome will not attempt an HTTP fallback at all, and the setting takes precedence over both the automatic upgrade and the warning:

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

Add includeSubDomains only once you are certain every subdomain — including internal tools and staging hosts on that domain — can serve HTTPS. It is a promise that is awkward to walk back.

What is not affected

A few cases that generate needless panic:

Local development is fine. http://localhost is treated as secure and never warns. Non-unique hostnames, single-label hostnames like intranet/, and local IP addresses such as 192.168.0.1 are excluded from the default configuration — Chrome is shipping the public sites only variant, not the strict one.

Certificate errors are unchanged. Expired or misconfigured certificates produce the same warnings they always have. Chrome is not adding new certificate interstitials here.

Explicit HTTPS navigations do not silently downgrade. If a link specifies https:// and the connection fails, the user sees a standard network error page — no HTTP fallback is attempted.

Users are not warned repeatedly. Chrome remembers a bypass for 15 days and renews it on each revisit, so a regularly-visited HTTP site typically prompts once. In Google's Chrome 141 experiment, the median user saw fewer than one warning per week and the 95th percentile user fewer than three.

CI and enterprise fleets

Two operational details worth putting in a ticket now.

If your end-to-end suite drives Chrome against HTTP hosts, allowlist them explicitly rather than letting tests fail mysteriously in whichever release picks up the change:

chrome --unsafely-treat-insecure-origin-as-secure=http://insecure.test,*.example.com

And if you manage a Chrome fleet, the HttpAllowlist policy suppresses the warning for specific hostname patterns, while HttpsOnlyMode lets you pin the setting — force_balanced_enabled matches the upcoming default, force_enabled extends warnings to private sites too. Rolling force_balanced_enabled out to a pilot group ahead of October is the cheapest way to discover which internal HTTP dependency nobody documented.

Takeaways

The web is somewhere between 95% and 99% HTTPS depending on platform, and that number has been flat for years. Chrome 154 is the nudge intended to close the remainder — and the remainder is disproportionately made of redirect infrastructure rather than actual HTTP content.

Three things worth doing this month:

1. Trace every inbound hostname with curl -sIL and fix any location: http:// hop. Start with your apex domain; it is the most common offender.
2. Enable "Always Use Secure Connections" in your own browser and browse your product for a week. The interstitials will find the paths your test suite does not cover.
3. Set HSTS once the chain is clean, and allowlist known-HTTP hosts in CI and enterprise policy before October rather than after.

None of this is difficult work. It is just work that lives in DNS records and forwarding rules that nobody owns — which is exactly why it is still outstanding a decade into the HTTPS migration.

---

Sources: HTTPS by default — Google Security Blog · Adapting your website for Chrome's "Ask-before-HTTP" warning — Chromium Docs · Mozilla SSL Configuration Generator · Strict-Transport-Security — MDN