☰

Chrome 将我的本地托管网站加载为 https 而不是 http，从而导致错误（在 ubuntu 更新后开始发生）

tag-icon • tag-icon networking google-chrome webserver
Chrome 将我的本地托管网站加载为 https 而不是 http，从而导致错误（在 ubuntu 更新后开始发生）

我有一个正在进行的本地 wordpress 项目，通常通过example.dev在 URL 栏中输入来打开我的网站，并且我正在处理的网站可以正常显示。

我apt-get update和apt-get upgrade我的 ubuntu 电脑，它要求重新启动。重新启动后 - 我尝试打开我的本地网站，但收到错误：

无法访问此站点 example.dev 拒绝连接。请尝试：

检查连接 检查代理和防火墙 ERR_CONNECTION_REFUSED 重新加载隐藏详细信息 检查您的互联网连接 检查所有电缆并重新启动您可能正在使用的所有路由器、调制解调器或其他网络设备。 允许 Chrome 在您的防火墙或防病毒设置中访问网络。如果它已被列为允许访问网络的程序，请尝试将其从列表中删除并重新添加。 如果您使用代理服务器… 请检查您的代理设置或联系您的网络管理员以确保代理服务器正常工作。 如果您认为您不应该使用代理服务器：转到 Chrome 菜单 > 设置 > 显示高级设置… > 更改代理设置… 并确保您的配置设置为“无代理”或“直接”。

并注意到它以“https”而不是“http”为我的网站提供服务，每当我将“https”编辑为“http”时，按下回车键后它仍然将其加载为 https。

我不太确定这是不是问题所在 - 所以我打开了 Firefox 并做了同样的事情 - 并得到了我的网站的正确输出，开头是“http”而不是“https”。

什么原因导致 Chrome 中出现这种情况？

我的网站在 apache2 服务器上运行。更新之前没有发生过这种情况。

编辑：我偶然发现了这篇文章 -https://superuser.com/a/1251483/414388 而且真的不明白为什么我需要更改我的域名——我真的不想遵循这种方法。这不是解决方案。

答案1

如果您导航至文章发布在超级用户帖子中，tl;dr 解释道：

tl;dr：Chrome 63（于 2017 年 12 月推出）将强制所有以 .dev（和 .foo）结尾的域名通过预加载的 HTTP 严格传输安全 (HSTS) 标头重定向到 HTTPS。

因此，您唯一的解决方案是更改为.devTLD 以外的其他内容，或者创建证书并在您的虚拟主机配置以促进当地发展。

为了解释为什么这是唯一的解决方案，我需要从 HSTS 的含义以及它如何工作开始。

HSTS 概述

HSTS 是相对地新的 HTTP 标头，设置后会告诉浏览器，下次有人导航到该域时，只能使用 HTTPS 访问它，而无需任何服务器端重定向。

例如，假设您导航到http://example.com。在响应标头中，您会收到以下内容：

Strict-Transport-Security: max-age=31536000

此标头告知浏览器，在接下来的一年（31536000 秒）内，当用户访问 时http://example.com，将该 URL 重定向到https://example.com本地，而无需任何服务器重定向。然后，才使用 访问网站https://example.com。

子域名的 HSTS

前者仅对单个域名有效。例如，如果您尝试访问http://subdomain.example.com，则该网站无需任何重定向即可运行。

为了解决这个问题，以前的标题应该改为：

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

现在，即使您从未访问过的任何子域example.com，浏览器也会在发出请求之前将子域重定向到 https。

HSTS 预加载

最后一步是解决最后一个问题。第一次访问网站时，您仍将使用 HTTP 访问它，这会将您重定向到 HTTPS 并向您发送 HSTS 标头。这并不安全，仍然是一个安全问题。

为了解决这个问题，主流浏览器使用 Chrome 的 HTTP 严格传输安全 (HSTS) 预加载列表来硬编码只能通过 HTTPS 访问的域。您可以在此处找到提交表单：https://hstspreload.org/

提交域名之前您需要做的唯一修改是修改标头，以便它在浏览器中缓存至少 2 年，并向preload其中添加选项。

Strict-Transport-Security: max-age=63072000; includeSubdomains; preload

在您提交域名后，一旦发布了新版本的 Chrome（或任何其他实现 Chrome 的 HSTS 预加载列表的浏览器，而不一定是下一个版本），您的域名将被硬编码到 Chrome 中作为仅 HTTPS。

TLD 的 HSTS 预加载

顶级域名的所有者被允许（并被鼓励）提交整个 TLD 进行 HSTS 预加载。

欢迎 gTLD、ccTLD 或任何其他公共后缀域名的所有者在其所有可注册域名上预加载 HSTS。这可确保整个 TLD 的强大安全性，并且比预加载每个单独的域名要简单得多。

由于 Google 拥有该.dev顶级域名，他们就这么做了。因此现在所有*.dev域名都只能在 Chrome 下以 HTTPS 方式工作。而且由于大多数浏览器使用相同的预加载列表，这些浏览器也将停止工作。

如果你搜索预加载域列表（警告：页面大小超过 40MB并需要一段时间才能渲染。因此，如果您的计算机性能不够强大，它可能会冻结！），您会发现 TLD已预加载：google，，，，，，。devfoopageappchrome

// eTLDs
// At the moment, this only includes Google-owned gTLDs,
// but other gTLDs and eTLDs are welcome to preload if they are interested.
{ "name": "google", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true, "pins": "google" },
{ "name": "dev", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "foo", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "page", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "app", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "chrome", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },

答案2

如果你无法更改当前.dev域名，你可以将 Chrome 降级到版本 61（我已成功完成 =>这里）

相关内容