子域名解析入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b0e6e0192706.html
📄
子域名解析入口页面正常但深层链路失效时怎样定位断点
先确认一件事：入口页正常只能证明“该 URL 的解析与响应链路”通了，不能证明整条子域名的深层链路都通。断点通常落在两个位置之一——解析层（DNS 记录只对部分主机名生效）或应用层（入口页走了静态缓存，深层路径才真正回源）。区分这两者，靠的不是反复刷新入口页，而是对深层 URL 做一次带解析结果和响应头的对照请求。
两种解释：解析只覆盖了入口，还是入口绕过了后端
第一种解释是解析配置不完整。常见形态是子域名只配了一条指向入口主机或 CDN 的记录，而深层路径依赖另一个主机名（例如接口域名、静态资源域名、区域节点域名），这个主机名没有对应记录或指向了错误目标。此时入口页因为是同域静态页而正常，深层链路在解析阶段就失败。
第二种解释是解析没问题，但入口页没有真正触发后端。入口页可能被 CDN 或反向代理缓存，或者是一个不查数据库的静态壳；深层路径才需要回源、鉴权、读写数据库或调用内部服务。这时解析全部正常，断点出现在应用内部或网络策略上。
两种解释的处置方向完全相反：前者要改记录，后者要查服务。判断错方向，会在 DNS 面板上反复折腾一个本来正确的配置。
用一组对照证据把两种解释分开
对入口 URL 和一个已知失效的深层 URL 分别执行解析与请求，比较下面几项：
- 解析结果：两条 URL 解析到的主机名和 IP 是否一致。若深层 URL 解析为空、指向保留地址或指向与入口不同的目标，倾向解析层问题。
- 连接阶段：深层 URL 是连不上（超时、连接被拒），还是连上了但返回 4xx/5xx。连不上偏解析或网络策略；连上后报错偏应用层。
- 响应来源标记：响应头里的缓存命中、回源、服务标识。若入口页标记为缓存命中而深层页标记为回源失败，说明入口页正常只是因为它没回源。
- 路径深度对照：把深层 URL 逐级截短，看从哪一级开始失效。失效点固定在某个路径段，通常指向路由或权限配置；失效点随主机名变化，指向解析。
一个可用的假设例子：假设入口 www.example.com 解析到 CDN 且命中缓存，深层 api.example.com/v2/order 解析为空。此时入口正常、深层失败，证据指向解析层缺少 api 主机记录，而不是后端服务故障。反之，若 api 解析正常、TCP 可连，但返回 502，且响应头显示回源失败，则应转向应用与上游服务排查。
先做一个动作，再根据结果决定下一步
最省事的起点是对深层 URL 单独做一次解析查询，而不是先动应用配置。动作是：对失效的深层主机名发起解析查询，记录返回的记录类型和目标。
结果如何影响下一步：
- 解析为空或指向明显错误的目标 → 先补齐或修正记录，再复测深层 URL。此时不要改应用代码。
- 解析正常且能建立连接，但返回错误状态 → 保留解析配置，转向应用日志、上游服务与网络策略。
- 解析正常但连接超时 → 检查该主机名对应的目标是否可达、端口是否开放，区分网络策略与目标不可用。
这个顺序的价值在于：解析层的问题用解析层的手段验证最快，成本最低；一旦排除解析，后续排查才有明确边界。
容易误判的几种情况
入口页返回 200 不等于整条链路健康，缓存和静态壳都会掩盖后端问题。深层 URL 返回 404 也不一定是“页面不存在”，可能是路由未匹配、鉴权拦截后统一返回、或请求打到了错误的后端实例。
另外，抓取限制与索引结果要分开看：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。若深层链路失效同时伴随抓取异常，不要仅凭抓取量变化就断定是解析问题，抓取量下降还可能来自内容更新节奏、内链变化或平台自身调度，需要结合解析与响应证据一起判断。
当解析和应用两侧都排查过仍无法定位时，把范围收缩到“哪一级路径开始失效、哪个主机名开始失效”这两个维度，通常比继续扩大检查项更有效。明确断点层级之后，再决定是修改记录、调整路由，还是修复上游服务，才不会在错误的方向上反复试错。
