同ip网站：入口页面正常但深层链路失效时怎样定位断点，先判断是“发现不了”还是“打不开”

📍 WDQWDWQD987AAAAA:216.73.217.120
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7ae36a6bc823.html
📄

同ip网站：入口页面正常但深层链路失效时怎样定位断点，先判断是“发现不了”还是“打不开”

先别急着改全站配置，把入口页当成对照组：入口页正常只能说明域名解析、Web 服务进程和首页模板这条最短路径没断。深层链路失效通常断在三个位置之一——链接发现、中间跳转、末端渲染。用同一浏览器、同一网络环境，从入口页出发手动走一遍目标路径，每经过一个跳转就记录状态码和最终 URL，断点会落在第一次出现异常的那一跳，而不是整条链路。

先判断是“发现不了”还是“打不开”

这两类问题的处置方向完全不同，判断依据是看请求有没有发出去。

动作：从入口页复制目标深层链接，直接在新标签页打开。能打开，问题偏发现层；打不开，问题偏响应层。这一步的结果决定你接下来查日志还是查链接。

两种排查顺序的取舍条件

面对同 IP 下的多个站点，常见两种做法：先横向对比所有站点，或先纵向深挖单个站点。

先横向对比成立的条件：多个站点共用同一套模板、同一反向代理或同一跳转规则，且失效现象在时间上同时出现。此时逐个站点改配置代价高，先找一个所有站点都经过的公共环节（如统一的重写规则、共用的中间件）更快。代价是：如果各站点其实是独立部署，横向对比会浪费大量时间，还会把无关差异误判成共性原因。

先纵向深挖成立的条件：只有一个站点出现深层链路失效，或各站点失效路径不同。此时把该站点的入口页到深层页拆成逐跳，比横向比较更省事。代价是：如果根因确实在共享层，纵向排查会在每个站点重复一遍相同结论。

一个可用的判据：先看失效是否跨站点同时发生。同时发生优先查共享面；只有单站发生，优先纵向拆链路。

把一条链路拆成可验证的逐跳清单

假设入口页是 /index.html，目标是三级深层页 /a/b/c.html，中间经过一次 302 跳转。按下面顺序验证，每步只回答“通或不通”：

  1. 入口页 HTML 源码里是否存在指向 /a/ 的链接。不存在，断点在链接生成。
  2. 打开 /a/，看是否返回 200 且包含指向 /b/ 的链接。返回 200 但无链接，断点在该层模板或数据查询。
  3. 打开 /b/，记录它是否跳转到带参数的 URL。跳转后的最终地址若丢失路径层级，断点在重写规则。
  4. 打开最终 /a/b/c.html，对比直接访问与经跳转访问的响应差异。

这里要区分两种结果：直接访问 200、经跳转 404，说明跳转规则把路径改错了；两者都 404，说明该深层路径本身不存在或未部署。这一步的结论直接决定你是改重写规则还是补内容。

日志与抓取信号只能当线索，不能当结论

访问日志里深层 URL 请求量为零，可能是爬虫没发现链接，也可能是日志采样、日志轮转、CDN 回源不记录，或该路径只被前端异步加载。请求量归零不能单独证明链接结构有问题。

同理，robots.txt 里的 Disallow 只约束抓取，不等于可靠的索引移除；站点地图提交也不保证收录。要确认深层页对搜索引擎是否可达，应分别核查目标搜索引擎的实际抓取与索引状态，不同引擎的支持和表现要分开看。

如果站点已启用 HTTPS，也不要把它当作链路正常的证据——HTTPS 不保证安全无漏洞，也不保证排名。它只影响传输层，与深层路由是否可达无关。

给一个可复用的短例子

假设某站点入口页正常，/products/ 列表页正常，但点进任一商品详情页都回到列表页。逐跳检查发现：详情页 URL 被重写规则匹配成了列表页规则，返回 302 回列表。动作是把重写规则的匹配顺序调整为先精确匹配详情页路径。调整后详情页返回 200，此时再检查该详情页是否出现在站点地图和列表页链接中——这一步确认的是发现层，与刚才的路由修复是两件事，不能因为路由修好了就默认收录会恢复。

定位断点的核心不是一次改对所有配置，而是让每一次修改只针对已经证实的那一跳，并用修改后的响应结果决定下一步查哪里。

图1 图2
nginx