带www与不带www的URL差异及访问流程、DNS配置问题咨询

两类域名访问的全链路处理流程 #

不管输入的是google.com还是www.google.com，链路上三个核心节点的处理逻辑如下：

• 浏览器端
  首先自动补全访问协议（未手动输入协议时，现代浏览器默认优先尝试HTTPS连接，连接失败才会回退HTTP），先查询本地DNS缓存，命中记录就直接取对应IP建连；无缓存则向配置的DNS递归服务器发起解析请求。拿到IP后完成TCP握手、TLS握手，发起HTTP请求时会将当前访问的域名写入Host请求头，TLS握手阶段也会通过SNI字段携带域名信息。如果收到服务器返回的3xx重定向状态码（常见为301永久重定向、302临时重定向），就自动按照响应头Location字段的地址跳转，你观察到的统一跳到https://www.google.com的行为，就是这一步触发的。
• DNS服务器端
  收到解析请求后先查本地缓存，命中直接返回结果；未命中则走标准迭代查询流程，从根域名服务器、.com顶级域名服务器到谷歌的权威域名服务器，逐级查询对应域名的解析记录：如果是A/AAAA记录就直接返回IP地址，如果是CNAME记录就继续查询目标域名的解析，直到拿到最终可访问的IP返回给客户端。注意DNS只负责域名到记录值的映射解析，完全不涉及HTTP跳转逻辑，跳转行为和DNS配置没有直接关系。
• 托管服务器/CDN节点端
  收到请求后先通过SNI、Host字段识别用户访问的具体域名，匹配预先配置的站点规则：如果当前访问域名不是站点设定的首选域名，就返回3xx重定向响应，将用户引导到配置好的首选地址；如果匹配到首选域名规则，就直接返回对应站点的页面资源。

谷歌的统一跳转是因为CNAME配置吗？ #

不是。首先你搞反了配置逻辑，也搞错了CNAME的作用边界：
谷歌的解析配置里，google.com本身直接配置了A/AAAA记录指向自家服务集群IP，www.google.com要么直接配A/AAAA记录指向同集群，要么通过CNAME指向内部的负载均衡域名。CNAME仅做域名层面的别名映射，根本感知不到HTTP层的请求，不可能触发跳转。你看到的统一跳转，是谷歌在web服务、CDN边缘节点上手动配置的重定向规则，和CNAME没有任何关联。哪怕两个域名配置完全相同的A记录指向同一台服务器，服务器也可以根据Host头给两个域名返回完全不同的内容，或者配置单向跳转。

sld.tld和www.sld.tld的访问结果必须一致吗？ #

完全不需要。这两个是完全独立的域名，解析规则、响应逻辑完全由域名所有者自主配置，没有任何国际规范强制二者必须指向相同内容。

实际访问结果不一致的常见案例 #

• 大量个人站点、小型站点只配置了根域名的解析，根本没给www子域名加任何解析记录，访问www.xxx.com会直接触发DNS解析失败，根本打不开网站。
• 部分企业站点会把根域名配置成单独的品牌宣传页、活动落地页，www子域名指向实际的业务主站，二者内容完全不同。
• 早年DNS规范不允许根域名（区域顶点）配置CNAME记录，否则会干扰同域名下MX邮件记录、TXT验证记录的正常解析，而CDN服务普遍要求用CNAME接入，因此很多站点会把根域名直接跳转到接入了CDN的www子域名，两个域名实际指向的服务集群完全不同。
• 很多用户忘记配置www子域名解析时，域名注册商默认会把未配置的子域名、根域名解析到自己的广告停放页，和用户自己部署在另一个域名下的站点内容完全无关。

为什么很多站点选择跳转到www而非直接用根域名？ #

注意这个跳转不是浏览器主动触发的，是站点配置的重定向规则，浏览器只是被动执行服务器的响应指令而已。选择www作为主站域名主要是历史习惯加技术考量：

• 早期互联网服务分工明确，www前缀专门用来指代万维网服务，根域名往往用来承载邮件、FTP等其他服务，这个配置习惯一直延续至今。
• 前面提到的DNS历史限制：根域名不能配CNAME的规则，导致早年接入CDN、全球负载均衡时，www子域名的配置灵活度远高于根域名。
• Cookie隔离更灵活：如果在根域名下设置Cookie，默认会被该域名下所有子域名继承，会带来不必要的流量开销和安全风险。用www作为主站域名，可以更灵活控制Cookie的作用范围，静态资源还可以部署在其他无Cookie的子域名下，提升页面加载速度。

当然现在DNS已经支持ALIAS/ANAME等虚拟记录解决根域名CNAME的限制，也有大量站点选择把根域名作为主站，将www跳转到根域名，具体选哪个完全是站点所有者的自主选择，没有统一标准。

内容的提问来源于stack exchange，提问作者Aayush Neupane