307 Internal Redirect (HSTS Upgrade)

What’s actually happening

You type or click an http:// link and DevTools shows a 307 to the https:// version at the top of the Network tab. There's no Location header you control and no matching rule in nginx, Apache, or your CDN. The status reads "307 Internal Redirect" rather than plain "307 Temporary Redirect." People hunting a redirect-loop or a stray rewrite rule waste an hour looking for a server config that was never there.

Common causes

• The site previously sent a Strict-Transport-Security header and the max-age window hasn't expired, so Chrome upgrades every request to the host
• The domain (or its parent, with includeSubDomains) is on the HSTS preload list baked into the browser binary
• A prior HTTPS visit registered the policy; the browser remembers it per-host in its HSTS state
• A meta upgrade or upgrade-insecure-requests CSP directive forced the scheme rewrite before the request left the browser

How to fix it

1. Recognize it as expected behaviorThis is the browser doing its job. The http:// request never hits the network; it's swapped for https:// locally. Stop searching server logs for a 307 you won't find there.
2. Confirm the source in chrome://net-export or the HSTS UIOpen chrome://net-internals/#hsts and query the domain. If static_sts_domain or dynamic_sts_domain comes back populated, the upgrade is HSTS, not a server rule.
3. Clear the policy only when you're testing http:// on purposeIn chrome://net-internals/#hsts use "Delete domain security policies," enter the host, and the next http:// request goes out unupgraded — until the site resends the header. Use a fresh incognito window or curl to avoid the cached state entirely.
4. Check the real chain with curl, not the browsercurl -sIL http://example.com/ shows what the server actually returns (often a real 301 to HTTPS). The browser's 307 sits in front of that and hides the first network hop from you.