二级域名作用，入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1648155ff047.html
📄
二级域名作用，入口页面正常但深层链路失效时怎样定位断点
先给结论：如果二级域名的入口页能打开、能返回 200，但深层链接出现 404、403、超时或内容错位，优先怀疑的不是服务器整体故障，而是该二级域名下“路径重写、路由映射或权限继承”在某一层断开。这个判断成立的前提是入口页与深层页共用同一套解析和证书；一旦入口页由独立静态文件或独立服务承载，结论就要推翻，断点更可能在两套服务之间的跳转规则上。
先确认入口页和深层页是否真的同源同栈
二级域名的作用是把一个独立业务、语言站或活动站从主域中拆出来，但它不自动保证入口页和深层页走同一套应用。定位断点的第一步，是取入口页和一条失效深层链接的响应头，比较 server、x-powered-by、set-cookie 的域字段以及重定向链。如果入口页返回的是 CDN 缓存的静态首页，而深层页要回源到应用服务器，那么入口正常只说明边缘节点可用，不能说明应用路由可用。
一个可区分的证据是：把同一条深层路径的查询参数去掉、只保留目录层级，再请求一次。若目录返回 200 而带参数的页面失败，断点通常在参数解析或后端路由；若目录也失败，断点更可能在路径映射或权限校验。
用三段式请求把断点缩到一层
不要从浏览器控制台一路猜。按下面顺序发三次请求，每次只改变一个变量：
- 直接请求深层 URL，记录状态码和最终跳转地址。
- 请求该路径的上一级目录，看是否触发目录默认页或 301。
- 请求入口页并带上同一
Cookie，观察会话是否在二级域名下被接受。
如果第 1 步跳到主域、第 3 步会话正常，断点多半是跨二级域名的会话域设置；如果第 2 步就 403，说明权限规则在目录层已经拦截，深层页根本没进入业务逻辑。这个动作的价值在于：它把“链路失效”拆成跳转、权限、路由三种可分别验证的原因，而不是笼统归为服务器问题。
反例：入口页独立部署时，上面的顺序要反过来
假设入口页是一个手工上传的静态页，深层页由另一套应用生成，那么入口页 200 只能证明静态文件存在，完全不能证明应用健康。此时应先查反向代理的 location 匹配：静态页可能命中了更宽泛的规则，而深层路径落到了未配置的上游。判断依据是入口页响应里没有应用特有的 Cookie 或头字段，深层页却出现上游连接错误。出现这个反例时，先修路由规则，再谈内容层。
哪些现象不能单独证明断点位置
抓取量或请求量归零、日志里某条路径消失，都不能单独说明处理正确或错误。它们还可能来自缓存命中、爬虫降频、监控采样变化或该路径本来就没有外部入口。robots.txt 的抓取限制也不等于可靠的索引移除，站点地图不保证收录，HTTPS 不保证安全无漏洞或排名。要定位断点，仍要回到状态码、跳转链和权限继承这三类可复核证据。
下一步动作与结果如何影响决策
完成三段式请求后，如果断点落在跨二级域名的会话域，下一步是把会话 Cookie 的域范围与业务实际需要对齐，再复测深层链接；若复测通过，说明问题在会话层，不必改应用路由。如果断点落在目录权限，下一步是核对权限规则的作用范围，而不是直接放宽整个二级域名。若断点落在反向代理匹配，先补 location 规则并观察深层链接是否恢复，再决定是否需要回退入口页的独立部署。每次只改一层，才能让下一次请求的结果真正指向下一层。
