404 not found：入口页面正常但深层链路失效时怎样定位断点，先区分两类断点：请求根本没到应用，还是到了应用但没匹配到路由
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1122c3948b54.html
📄
404 not found：入口页面正常但深层链路失效时怎样定位断点，先区分两类断点：请求根本没到应用，还是到了应用但没匹配到路由
入口页面返回 200 而深层页面返回 404，最常见的解释不是“整站坏了”，而是某一段路径在服务器、应用路由或链接生成环节被改写或截断。先不要批量改链接，应该抓取一条完整链路上的每一步响应，找到第一个从 200 变成 404 的位置，再决定修服务器规则还是修页面链接。
先区分两类断点：请求根本没到应用，还是到了应用但没匹配到路由
这两类原因的修复动作完全不同。判断依据是看服务器访问日志和响应头，而不是只看浏览器里的 404 页面。
- 请求没到应用：访问日志里看不到这条深层路径，或者只看到重写后的路径；响应可能由 Web 服务器直接给出。常见于重写规则把多级路径吃掉、反向代理只转发了入口路径、或子目录部署时前缀被剥离。
- 请求到了应用但没匹配：访问日志里有完整路径，应用日志里出现路由未命中或参数校验失败。常见于动态路由只注册了入口，深层参数被当成非法值，或大小写、尾斜杠、编码方式与路由定义不一致。
可执行动作：从入口页出发，用命令行工具逐跳请求，保留每跳的状态码、Location 和最终 URL。结果会直接告诉你断点发生在第几跳；如果中间出现 301 或 302，下一步就应检查重写目标是否保留了完整路径，而不是继续怀疑内容本身。
两种条件下选择不同的排查顺序
条件一：入口页是静态文件，深层页由应用生成
此时优先检查 Web 服务器到应用服务器的转发规则。假设入口页为 /docs/，深层页为 /docs/guide/setup/，若规则写成只匹配一级目录并转发到应用根路径，深层路径就可能被截成 /guide/setup/，应用自然返回 404。动作是临时在转发规则中保留原始 URI，再请求同一条深层链接；如果状态码恢复为 200，断点就在转发层，后续应修正规则而不是逐页补链接。
条件二：入口页和深层页都由同一应用渲染
此时优先检查路由注册和链接生成。把入口页源码中的深层链接复制出来，与路由定义逐段比对，重点看尾斜杠、大小写、百分号编码和参数占位符。动作是手工构造一个只差一个字符的 URL 分别请求；如果仅某一形式返回 404，说明是匹配规则问题，修复应落在路由或链接生成函数，而不是服务器重写。
用可核对的证据排除“看起来像 404”的假象
有些深层链路失效并非真的资源不存在，而是中间层返回了错误状态或缓存了旧结果。需要核对三类证据：
- 响应头中的缓存标记和年龄字段，判断是否命中了旧缓存。
- 同一条路径带与不带查询参数时的状态码差异，判断是否被参数化规则误伤。
- 直接请求源站与经过 CDN 或反向代理时的状态码差异，判断断点是否在边缘层。
如果只有经过边缘层才出现 404，而源站返回 200，下一步应检查边缘层的路径改写和缓存键，而不是修改源站路由。反过来，如果源站本身就返回 404，边缘层只是如实转发，就应回到应用路由排查。
一个注明假设的短例子
假设站点把帮助中心从 /help/ 迁到 /support/，入口页 /support/ 正常，但 /support/billing/invoice/ 返回 404。逐跳请求后发现：/support/ 返回 200，/support/billing/ 返回 301 到 /billing/，最终 /billing/invoice/ 返回 404。这说明重写规则在二级目录处丢掉了 /support 前缀。修复动作是让重写保留完整前缀，再复测同一条链路；若复测通过，下一步才是批量检查其他二级路径是否受同一规则影响，而不是直接提交所有旧链接的替换。
例外与适用条件
上述方法适用于入口可达、深层不可达且状态码可观测的场景。如果服务器对深层路径直接断开连接、返回 403 或超时，就不属于 404 断点定位，应先解决连通性和权限问题。另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；定位断点时不要用“已提交站点地图”当作深层页面可访问的证据，仍应以实际请求的状态码和响应内容为准。不同搜索引擎和中间层对重写、编码的处理可能不同，涉及具体平台时应分别核查其文档和实际响应。
