多年来，一场关于地址栏的小争论一直在持续。一方是像 Google、Instagram 和 Facebook 这样的品牌。这组人选择将 example.com 重定向到 www.example.com。另一方则是：GitHub、DuckDuckGo 和 Discord。这组人选择相反的做法，将 www.example.com 重定向到 example.com。
URL 中是否应该包含“WWW”？一些开发者对这个问题持有强烈的观点。在了解一些历史背景之后，我们将探讨支持和反对它的论点。
为什么会有 Ws？
三个 Ws 代表着 “万维网”，这是 20 世纪 80 年代末的发明，它向世界介绍了浏览器和网站。使用“WWW”的做法源于一种传统，即根据服务类型为子域名命名
- 位于 www.example.com 的 Web 服务器
- 位于 ftp.example.com 的 FTP 服务器
- 位于 irc.example.com 的 IRC 服务器
无 WWW 域名问题 1：将 Cookie 泄漏给子域名
“无 WWW”域名的批评者指出，在某些情况下，subdomain.example.com 将能够读取由 example.com 设置的 Cookie。例如，如果您是 Web 托管提供商，允许客户在您的域名上运行子域名，这可能是不可取的。虽然此问题是有效的，但此行为特定于 Internet Explorer。
RFC 6265 标准化了浏览器处理 Cookie 的方式，并明确指出此行为不正确。
另一个潜在的泄漏来源是 example.com 设置的任何 Cookie 的 Domain 值。如果 Domain 值显式设置为 example.com，则 Cookie 也将暴露给其子域名。
| Cookie 值 | 暴露给 example.com | 暴露给 subdomain.example.com |
|---|---|---|
secret=data | ✅ | ❌ |
secret=data; Domain=example.com | ✅ | ✅ |
总之，只要您不显式设置 Domain 值并且您的用户不使用 Internet Explorer，就不会发生 Cookie 泄漏。
无 WWW 域名问题 2：DNS 问题
有时，“无 WWW”域名可能会使您的域名系统 (DNS) 设置复杂化。
当用户在浏览器的地址栏中输入 example.com 时，浏览器需要知道他们尝试访问的 Web 服务器的互联网协议 (IP) 地址。浏览器会向您域名的域名服务器请求此 IP 地址——通常是通过用户的互联网服务提供商 (ISP) 的 DNS 服务器间接请求。如果您的域名服务器配置为使用包含 IP 地址的 A 记录 进行响应，“无 WWW”域名将正常工作。
在某些情况下，您可能希望改为使用网站的 规范名称 (CNAME) 记录。此类记录可以声明 www.example.com 是 example123.somecdnprovider.com 的别名，这告诉用户的浏览器改为查找 example123.somecdnprovider.com 的 IP 地址并将 HTTP 请求发送到那里。
请注意，上面的示例使用了 WWW 子域名。无法为 example.com 定义 CNAME 记录。根据 RFC 1912，CNAME 记录不能与其他记录共存。如果您尝试为 example.com 定义 CNAME 记录，则不允许 example.com 的 MX（邮件交换器）记录存在。因此，将无法接收 @example.com 上的邮件。
一些 DNS 提供商将允许您解决此限制。Cloudflare 将其解决方案称为 CNAME 展平。使用此技术，域名管理员配置 CNAME 记录，但其域名服务器将公开 A 记录。
例如，如果管理员配置了指向 example123.somecdnprovider.com 的 example.com 的 CNAME 记录，并且存在指向 1.2.3.4 的 example123.somecdnprovider.com 的 A 记录，则 Cloudflare 将公开指向 1.2.3.4 的 example.com 的 A 记录。
总之，虽然对于希望使用 CNAME 记录的域名所有者而言，此问题是有效的，但某些 DNS 提供商现在提供了合适的解决方法。
无 WWW 的优势
大多数 反对 WWW 的论点 都是实用性或美观性的。 “无 WWW”的支持者认为，说和打 example.com 比 www.example.com 更容易（这可能对技术水平较低的用户来说不太混乱）。
WWW 子域名的反对者还指出，删除它会带来微不足道的性能优势。网站所有者可以通过这样做，从每个 HTTP 请求中减少 4 个字节。虽然对于 Facebook 这样流量很大的网站来说，这些节省可能会累积起来，但带宽通常不是稀缺资源。
WWW 的优势
支持 WWW 的一个实用论点是在使用较新的顶级域名的情况下。例如，当 example.miami 不是时，www.example.miami 立即可以识别为 Web 地址。对于使用 .com 等可识别顶级域名的网站来说，这不太令人担忧。
对搜索引擎排名的影响
目前的共识是，您的选择不会影响您的搜索引擎性能。如果您希望从一个迁移到另一个，您需要配置永久重定向 (HTTP 301) 而不是临时重定向 (HTTP 302)。永久重定向可确保旧 URL 的 SEO 值转移到新 URL。
同时支持两种方案的技巧
网站通常会选择 example.com 或 www.example.com 作为其官方网站，并为另一个配置 HTTP 301 重定向。理论上，可以同时支持 www.example.com 和 example.com。在实践中，成本可能大于收益。
从技术角度来看，您需要验证您的技术栈是否能够处理它。您的内容管理系统 (CMS) 或静态生成的网站必须将内部链接输出为相对 URL，以保留访问者首选的主机名。除非您可以将主机名配置为别名，否则您的分析工具可能会分别记录到两个主机名的流量。
最后，您需要采取额外步骤来保护您的搜索引擎性能。Google 会将 URL 的“WWW”和“非 WWW”版本视为 重复内容。为了在其搜索索引中删除重复内容，Google 将显示它认为用户会更喜欢的版本——无论好坏。
为了控制您在 Google 中的显示方式，建议插入规范链接标签。首先，确定哪个主机名将是官方（规范）主机名。
例如，如果您选择 www.example.com，则必须在 https://example.com/my-article 的 <head> 标签中插入以下代码片段
<link href="https://www.example.com/my-article" rel="canonical">此代码片段指示 Google“无 WWW”变体表示相同的内容。通常，Google 会在搜索结果中首选您标记为规范的版本，在本例中为“WWW”变体。
结论
尽管双方进行了激烈的宣传，但只要您了解其优势和局限性，这两种方法仍然有效。为了覆盖所有方面，请务必设置从一个到另一个的永久重定向，然后您就完成了。
作者选择 开放互联网/言论自由基金 作为捐赠对象，作为 为捐赠写作 计划的一部分。
我发现这部分有点令人困惑
在这种情况下，CNAME 记录将由 example.com 的名称服务器提供服务，而 NS 记录将由 .com 名称服务器提供服务，我相信是这样吗？
我认为一个更清晰的例子可能是，如果 example.com 的名称服务器为根提供 CNAME 记录以及 MX 记录，这将违反 DNS 规范。
本杰明，你说得对。感谢你的建议！
实际上，无论如何您都不能为基础域名设置 CNAME 记录，因为基础域名始终具有 SOA 记录。因此，即使没有 MX 记录，也永远不可能为基础域名设置 CNAME。
虽然这仍然正确，但您可以使用新的 SVCB 和 HTTPS DNS 记录类型有效地“别名”您的根域名。当然，这依赖于浏览器的支持，但幸运的是，这似乎正在迅速普及。截至撰写本文时，该草案已获批准，目前正在等待 RFC 编号。
您还可以使用 HTTPS DNS 记录来宣传您的 Web 服务器使用 HTTP/3 和 HSTS，以便客户端无需通过 HTTP/2 发出第一个请求并查找
Alt-Svc标头。我也有同样的想法，它有一些好处，但这个想法在几年前就消失了，对于子域名，我认为像 en、de 这样的语言环境是最好的。
很棒的文章，谢谢。
几年前，推动 WWW 的保罗是否后悔将其强加于标准？ （我很有可能错了！）
很明显，公众（互联网的主要用户）并不关心或理解 WWW，而对 Subdomain.XZY.com 有稍微多一点的了解，但不多。
一个小小的疑问，考虑到第一个 Web 服务器和浏览器是在 1991 年发布的，“20 世纪 80 年代末的发明”是不是有点早了？
我想这取决于你何时认为一项技术被发明了。确实，公众直到 1991 年才体验到网络。文章使用伯纳斯-李的第一个提议作为参考点，该提议可以追溯到 1989 年。
“www”有助于表明它实际上是一个 URL。我猜祖父母或不太懂技术的用户会对 .co、.biz、.hotdog、.etc 域名感到困惑，保留 www 可以使非 .com 域名更清晰。
我选择不使用它纯粹是为了美观