为什么浏览器缓存 http://example.com 的 301 重定向并将其用于 http://example.com:8080?

Why browsers caches 301 redirect for http://example.com and use it for http://example.com:8080?

我在 CentOS 服务器上的两个不同的 Web 服务器(NGINX 和 nodejs)上有两个站点。
在我的 NGINX 配置中,我已永久设置 http://example.com to be redirected to https://example.com
另一方面,URL http://example.com:8080nodejs 处理并且不会重定向到任何地方。

场景

当我在浏览器中请求 http://example.comChrome、firefox 或 safari),它被重定向到 https://example.com 这样就可以了。当我输入 http://example.com:8080 时,它也被重定向到 https: //example.com:8080 这是不正确的。

当我清除浏览器缓存时,URL http://example.com:8080 正常工作,但在输入 http://example.com,URLhttp://example.com:8080 再次重定向到 HTTPS。谁能帮我解决这个问题?

您可能体验过 HTTP Strict Transport Security (HSTS) 规范定义的内容。

您需要检查 https://example.com 请求的响应。它可能包含 Strict-Transport-Security header 指示浏览器重写 example.com domain 请求的所有 URI 以使用安全方案。 HTTP 严格传输安全 (HSTS) 规范 8.3. URI Loading and Port Mapping section 的相关摘录:

The UA MUST replace the URI scheme with "https" [RFC2818], and if the URI contains an explicit port component of "80", then the UA MUST convert the port component to be "443", or

if the URI contains an explicit port component that is not equal to "80", the port component value MUST be preserved; otherwise,

if the URI does not contain an explicit port component, the UA MUST NOT add one.

NOTE: These steps ensure that the HSTS Policy applies to HTTP over any TCP port of an HSTS Host.

NOTE: In the case where an explicit port is provided (and to a lesser extent with subdomains), it is reasonably likely that there is actually an HTTP (i.e., non-secure) server running on the specified port and that an HTTPS request will thus fail (see item 6 in Appendix A ("Design Decision Notes")).

有关详细信息,请查看 Strict-Transport-Security MDN page