Mark's Backyard
封面图：Tim Berners-Lee（蒂姆·伯纳斯-李）在2009年万维网诞生20周年的庆祝活动上，于欧洲核子研究中心（CERN）与那台具有历史意义的NeXT计算机重逢。他曾使用这台计算机开发并运行了世界上第一个Web服务器、多媒体浏览器以及网页编辑器。图片来源：CERN
上一篇讲了 www 是怎么来的——它是 Tim Berners-Lee 建议的命名惯例，也是早期区分服务的必要手段。
但是到了今天，Web 从“一台机器跑一个服务”变成“一个 IP 承载无数网站”之后，www 为什么不再是必需品？部署网站时那些让人头疼的 DNS 细节又该怎么处理？我打算在这篇讲一讲。
为什么后来很多网站又不用www了？
因为互联网的使用方式变了。
当网站还是一台机器提供一个服务的时候，www 很有用，可以把 Web 服务和邮件服务区分开，方便管理。
后来随着机器的性能进步，管理也逐渐变得简单和容易维护，尤其是虚拟主机、HTTP 的 Host 请求头（RFC 9110）、反向代理、CDN 和云平台逐渐普及，同一个 IP 地址可以根据域名把请求转给不同的网站，域名本身也不再需要承担那么多“这台机器是什么用途”的说明工作。
与此同时，阿巴阿巴.com 比 www.阿巴阿巴.com 短四个字符。这也就意味着出现在海报、名片、视频口播、广告牌和用户手动输入的每一个地方都更简短。品牌希望人们记住的是自己的名字，而不是一个历史上留下来的服务前缀，于是越来越多网站选择把裸域，也就是不带子域名的 阿巴阿巴.com，作为对外展示的地址。
这也与上文Tim在回答Why www？中最后的想法一致。
这不代表 www 技术上落伍了。它只是从「服务名称」变成了「地址风格」的选择。
而且保留 www 其实也有一些现实好处。它明确告诉网络基础设施：这是 Web 站点；以后如果要把 api.阿巴阿巴.com、static.阿巴阿巴.com 或其他服务拆出去，边界会比较清楚。Cookie 的作用范围RFC 6265）也可以更谨慎地控制：放在 www.阿巴阿巴.com 的站点，不会天然把只属于站点的主机级 Cookie 发给 api.阿巴阿巴.com。
所以「有没有 www 更现代」只是审美和品牌话术，不是工程结论。很多新网站不用它，是因为裸域更短、更符合产品习惯；很多成熟网站继续用它，是因为原来的链接、基础设施和服务边界已经很稳定。
真正麻烦的地方：裸域和 CNAME
讲到这里，可能会觉得既然 www 只是一个子域名，那不用就好了。事情在部署网站时会稍微复杂一点，尤其是你把网站交给 CDN、托管平台或云服务商的时候。
DNS 里最常见的两种记录，可以先这样理解：
A 阿巴阿巴.com -> 203.0.113.10
CNAME www.阿巴阿巴.com -> my-site.hosting-provider.com
A 记录直接把名字指向 IP 地址。CNAME（RFC 1034 §3.6.2、RFC 1035）则说：这个名字请按照另一个名字继续查。
CNAME 很适合接入托管平台。平台换了服务器 IP，你不需要每天改自己的 DNS，只要继续指向平台提供的域名即可。但按照传统 DNS 模型，一个名字如果设了 CNAME，就不能同时拥有其他类型的记录——RFC 2181 §10.1 对此做了明确说明。
问题在于，裸域 阿巴阿巴.com 不是一个普通的子域名。这个名字本身需要承载整个域的 NS、SOA 等基础记录；很多时候还会放邮件用的 MX、域名验证用的 TXT。按照传统规则，裸域不能简单地变成一个 CNAME，否则这些记录就没地方共存了。
这也是为什么过去很多托管平台会告诉你：请把 www.阿巴阿巴.com 配成 CNAME，然后让裸域做一次跳转。www 作为普通子域名，可以很自然地指向平台；裸域则因为 DNS 的历史结构，处理起来没有那么直接。
现代 DNS 服务商怎么解决这个问题？
后来 DNS 服务商提供了不同名字的解决方案，例如 ALIAS、ANAME 或 CNAME flattening。它们的具体实现并不完全一样，但思路接近：你在后台写下一个类似 CNAME 的目标，服务商替你把目标解析成 IP，再以裸域可以使用的形式返回给查询者。例如 Cloudflare CNAME Flattening、DNSimple ANAME、AWS Route 53 Alias。IETF 曾有 draft-ietf-dnsop-aname 草案，但尚未成为正式标准。
服务商在 DNS 边缘做了额外的解析工作,随着这些功能普及，裸域接入 CDN 和托管平台不再像以前那么别扭，于是「不带 www」又变得更容易了。
所以我应该选哪一个？
如果只是个人博客或小项目，其实没有必要把这个选择想得特别神秘。
喜欢短一点的地址，就用裸域；希望保留传统习惯，或者以后可能把站点和其他子域服务拆得更清楚，就用 www。两种方案都可以做好，也都可以做得很糟。
真正重要的是选定一个主地址之后，把另一个地址认真配置好：DNS 能解析，服务器认识它，HTTPS 证书覆盖它，然后用 301 统一跳转。就拿我的网站例子来说，我把两个都配置好了。Google Search Central 建议选一个规范地址并用 301 重定向，这样链接分享、缓存、统计和搜索引擎收录都更容易保持一致。
为什么有时候加上 www 反而打不开？
如果一个网站的裸域能打开，但手动加上 www 就报错，通常不是 www 有什么魔咒，而是管理员只配置了其中一个地址。
一次完整的访问，大概会依次经过这些地方：
text 浏览器 -> DNS：www.example.com 有没有记录？ -> 服务器：我是否接收 www.阿巴阿巴.com？ -> HTTPS：证书是否覆盖 www.阿巴阿巴.com？ -> Web 应用：返回页面，或重定向到规范地址
其中有一步没配好，就会出问题。
最简单的情况是 DNS 根本没有 www 的记录。查询结果是 NXDOMAIN，浏览器连服务器都找不到。
也可能 DNS 已经把 www.阿巴阿巴.com 指到了正确的 IP，但 Nginx、Apache 或托管平台没有配置这个 Host，于是服务器返回默认页、404，或者干脆拒绝请求。
还有一个经常被忽略的顺序问题：如果用户访问的是 https://www.阿巴阿巴.com，TLS 证书检查发生在 HTTP 重定向之前（RFC 9110 §4.2.2）。证书只覆盖 阿巴.com 的话，浏览器会先在 HTTPS 这一步拦住请求，服务器还没有机会告诉它「请改去不带 www 的地址」。所以证书通常需要同时覆盖两个名字，或者使用包含它们的通配符证书。
一个配置完整的网站，往往会让两个地址都能找到它，然后选一个作为规范地址：
text https://www.阿巴阿巴.com -> 301 -> https://阿巴阿巴.com https://阿巴阿巴.com -> 200
当然，你也可以反过来，把裸域重定向到 www。
参考资料
- RFC 1034：Domain Names - Concepts and Facilities
- RFC 1035：Domain Names - Implementation and Specification
- RFC 2181：Clarifications to DNS Specification §10.1
- RFC 6265：HTTP State Management Mechanism
- RFC 9110：HTTP Semantics
- Cloudflare：DNS CNAME record
- Cloudflare：CNAME Flattening
- Google Search Central：Consolidate duplicate URLs
- Author:Mark Xu
- Copyright:All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating otherwise.