什么是二级域名，入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /816e7cbf9c0e.html
📄
什么是二级域名，入口页面正常但深层链路失效时怎样定位断点
二级域名是挂在主域名左侧的一层名称，例如 shop.example.com 中的 shop。它常被分配独立站点、独立目录或独立应用。入口页面能打开，只说明这条二级域名至少有一条可达路径；深层页面打不开，通常不是整个二级域名失效，而是某个环节只覆盖了入口。定位断点时，先别急着改配置，先把“谁认为它正常”拆成可核对的证据。
先分清两种解释：解析与证书正常，还是应用路由正常
当入口正常、深层失效时，最常见的两种解释是：
- 解释一：网络与证书层正常，应用路由层有断点。入口可能被单独指向一个静态页、默认首页或健康检查页，而深层路径依赖应用内部的路由、重写规则或后端服务。
- 解释二：入口命中了缓存或旧版本，深层命中了新版本或源站。入口返回的是缓存副本，深层请求绕过缓存后暴露了真实配置差异。
这两种解释都成立，但证据不同。前者要看应用日志和路由规则，后者要看响应头、缓存命中和源站回源记录。把两者混在一起，容易得出“二级域名坏了”这种无法执行的结论。
用一组可区分证据判断断点在哪一层
可以按下面顺序做一次最小核对，每一步都记录结果，再决定下一步：
- 对入口和深层路径分别请求一次，记录状态码、响应头和最终响应体大小。若入口返回 200 且内容明显是默认页，而深层返回 404 或 502，说明入口没有验证深层路由。
- 把深层路径换成同一目录下的另一个已知页面。若同样失效，断点更可能在目录级重写或应用挂载点；若只有个别路径失效，断点更可能在单条规则或参数处理。
- 临时绕开缓存请求源站，比较两者响应。若源站正常而带缓存请求异常，断点在缓存层；若两者都异常，断点在源站或应用层。
- 检查二级域名的解析记录是否指向了与主站不同的源站。若指向不同源站，深层链路的规则、证书和目录结构都需要单独核对，不能拿主站的表现推断二级域名。
这里有一个假设例子：入口页由静态托管返回，深层路径由另一台应用服务器处理，而 DNS 只把入口路径指向静态托管。此时入口正常，深层 404。把 DNS 记录改成指向应用服务器后，入口和深层都正常，说明断点在解析指向与路径分流的组合，而不是应用代码本身。这个例子只用于说明比较方法，不代表任何真实项目。
把分歧转成项目可核对项
多个角色对“二级域名是否正常”有不同理解时，通常是因为各自只看了自己负责的一段。开发看本地环境，运维看负载均衡，SEO 看入口页面。把分歧转成核对项，可以写成一张最小清单：
- 入口路径与深层路径分别由哪个组件返回；
- DNS 记录指向哪个源站，是否与主站共用；
- 重写规则、反向代理规则和证书覆盖范围是否包含深层路径；
- 缓存策略是按路径、按目录还是按整个二级域名生效；
- robots.txt 是否限制了深层路径的抓取。注意，robots.txt 的抓取限制不等于可靠的索引移除，它只约束合规抓取行为，不能替代对页面本身的处理。
这张清单的作用不是一次性修完，而是让每个角色指出自己能看到的那一段。谁无法指出自己负责的那一段，断点就更可能落在那里。
修复后要验证深层链路，而不是只验证入口
完成一次调整后，至少做两个动作：第一，重新请求原先失效的深层路径，记录状态码和响应内容是否与预期一致；第二，再请求入口路径，确认调整没有把入口一起改坏。若站点地图中列入了深层路径，站点地图本身不保证收录，它只是提交候选地址；验证时仍以实际响应和可访问内容为准。
如果调整涉及 HTTPS，也要单独核对证书覆盖的域名和路径。HTTPS 不保证安全无漏洞，也不保证排名，它只说明传输层加密成立。把证书正常当成深层链路正常的证据，会漏掉应用路由和缓存层的断点。
什么时候该停止排查并回到需求本身
如果入口和深层路径都能返回预期内容，但某些角色仍认为“二级域名有问题”，先确认分歧是否来自对二级域名的定义不同：有人把它当成一个独立站点，有人把它当成主站的一个目录。定义不同，验收标准就不同。此时继续查 DNS 或证书不会产生新证据，应该回到需求，明确这个二级域名要承载哪些路径、由谁维护、以什么响应作为通过标准。把标准写下来之后，再决定是否需要继续调整解析、路由或缓存。
