当死链检测工具报告某个URL返回200,而真实用户仍然看到404或连接失败时,先不要急着改链接或删页面。更可能的解释是:工具与用户走的不是同一条请求路径。复现的目标,是让测试请求尽量带上用户侧的关键条件——DNS解析结果、出口IP、请求头、协议版本、重定向链路和缓存状态。只有先分清“工具能访问”和“用户能访问”差在哪,才能决定是保留原链接、改写跳转,还是退出该路径。
工具显示200,用户却失败,通常落在两种情形。第一种是请求根本没到达你的源站,失败发生在DNS、CDN边缘、负载均衡或TLS握手阶段;第二种是请求到了源站,但源站根据用户侧条件返回了不同状态。两者的复现动作完全不同。
判断方法:让用户在浏览器开发者工具的Network面板里看这条请求的Status和Remote Address。如果状态是(failed)或net::ERR_开头,偏向前者;如果是4xx/5xx,偏向后者。这个区分直接决定下一步是查解析还是查服务端逻辑。
死链检测工具默认发的是“干净请求”,而真实用户请求带着环境。要让复现有意义,至少补齐以下条件中的相关项。
用用户所在网络执行nslookup或dig,对比工具侧解析到的IP。如果两者不同,说明DNS或CDN调度把用户指向了另一个节点,问题可能只存在于那个节点。此时保留原链接是合理的,真正要处理的是节点配置,而不是链接本身。
登录态、地域、设备类型常触发不同的路由规则。用浏览器的“复制为cURL”拿到用户实际请求,再在测试端原样发出,比工具默认请求更接近真相。如果带Cookie后失败、不带则成功,问题在鉴权或会话逻辑,不在链接地址。
工具可能直接请求最终URL,跳过了用户经历的多跳重定向。用curl -IL跟完整条链,看每一跳的状态码。若中间某一跳对特定UA返回404,而工具因为只测了终点而漏掉,就会造成“工具正常、用户失败”。
CDN或浏览器缓存可能让工具命中旧副本。加一个随机查询参数或发Cache-Control: no-cache再测一次。如果去掉缓存后失败复现,说明缓存掩盖了源站问题。
复现清楚后,处理方式取决于失败是否可控、是否只影响部分用户。
假设一个例子:某栏目页在工具里返回200,但部分移动用户报告404。复现后发现这些用户走的是另一个CDN节点,该节点缓存了一份旧的规则配置。此时正确决策是保留链接、刷新该节点,而不是改写或删除页面——因为源站和多数节点都正常。若把这种情况误判为“页面已失效”而删除,反而会扩大故障范围。
复现条件补齐后,需要确认失败能被稳定重现,否则无法判断修复是否有效。至少做两件事:一是用同一组条件重复请求多次,看失败是否规律出现;二是换一个已知正常的条件对照,看差异是否只来自你怀疑的那个变量。
要注意,请求量下降或某工具显示“0条死链”都不能单独证明问题已解决。抓取量归零也可能因为工具被限流、规则变更或测试范围缩小,而非故障消失。同理,robots.txt里的抓取限制不等于可靠的索引移除,站点地图也不保证收录,这些都不能替代对用户侧失败的实际复现。HTTPS同样不保证安全无漏洞或排名,它只是传输层的一环。
不同搜索引擎和平台对重定向、状态码的处理存在差异,涉及多端时需分别核查。把复现条件、观察到的状态码和对照结果记录下来,才能让下一次判断有据可依,也才能决定是继续保留、改写还是退出这条路径。