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

死链接怎样排除缓存造成的假象

要排除缓存造成的假象，核心做法是让检查请求绕开本地浏览器、CDN和中间代理的缓存，直接观察源站返回的状态码。如果绕开缓存后死链接仍然返回404或410，它就是真实死链接；如果变成200，之前看到的只是缓存副本或缓存策略造成的假象。多人协作时，把请求URL、请求时间、响应头中的缓存字段和最终状态码一起记录，才能交付清楚、减少返工。

一个假设例子：同一URL两个人看到不同结果

假设某内容站把一篇旧文章从/old-guide/迁移到/new-guide/，旧地址配置了301跳转。协作中，A在浏览器里打开旧地址，看到正常页面，认为链接有效；B用命令行请求同一地址，得到404，认为它是死链接。两人各执一词，返工就发生了。

这个分歧最常见的解释是：A的浏览器或中间缓存保存了旧地址跳转前的200响应，或者保存了跳转后的页面；B的请求命中了另一台源站服务器，而该服务器上的跳转规则尚未同步。注意，这里只是可能原因，不能凭一次请求就断定谁对谁错。要定位，必须把“谁在什么条件下请求”“响应头写了什么”分开记录。

检查时先绕开缓存，再判断状态码

可以按下面步骤执行，每一步都保留输出：

1. 用命令行工具请求目标URL，并强制不使用本地缓存。例如curl -I -H "Cache-Control: no-cache" https://example.com/old-guide/。加-I只看响应头，速度快，适合批量核对。
2. 查看响应头里的Cache-Control、Age、X-Cache、CF-Cache-Status等字段。出现Age大于0，说明响应来自缓存；出现HIT一类标记，说明命中了CDN缓存。
3. 如果怀疑CDN缓存，追加一个随机查询参数再请求，例如https://example.com/old-guide/?check=20240101。查询参数不同，缓存键通常也不同，更容易打到源站。这只是排查手段，不要把它当成正式链接对外发布。
4. 对比源站直连结果。如果条件允许，用源站IP加Host头请求，或在回源日志中查同一时间的记录。源站返回404，才是真实死链接的有力证据。
5. 把两次结果并排记录：带缓存请求的状态码、绕缓存请求的状态码、响应头中的缓存标记、请求时间。交付时附上这些字段，比只写“我这边是好的”有效得多。

哪些现象容易被误判成死链接

下面几种情况经常被当成死链接，但成因不同，处理方式也不同：

• 缓存了旧的404：页面早已恢复，但CDN或浏览器仍返回之前缓存的404。判断依据是绕开缓存后返回200，且响应头显示缓存命中。
• 缓存了旧的301：跳转规则已改，缓存仍返回旧的目标地址或旧状态码。判断依据是直接请求源站时状态码与缓存请求不一致。
• 多台源站配置不一致：部分节点有跳转规则，部分没有。判断依据是多次请求落到不同节点时状态码摇摆。
• robots.txt限制抓取：这只影响爬虫抓取，不等于页面被移除，也不能用来可靠地移除索引。看到抓取被限制就断定链接已死，是常见错误。
• 站点地图里没有该URL：站点地图不保证收录，也不代表URL失效，不能作为死链接的判断依据。

多人协作时的交付清单

要让结论可复核，交付内容至少包含以下检查项：

• 原始URL和最终URL，以及中间发生的跳转。
• 请求方式：是否带no-cache、是否带随机参数、是否直连源站。
• 响应状态码，以及Cache-Control、Age、缓存命中标记等关键响应头。
• 请求时间与执行人，便于和回源日志对齐。
• 结论限定条件：例如“绕开缓存后返回200，判断为缓存假象；源站日志中同一时间无404记录”。

如果只写“已确认是死链接”，没有请求条件和响应头，接手的人无法判断这是源站问题还是缓存问题，只能重新查一遍。把判断依据写清楚，才是减少返工的关键。

确认之后怎么处理

确认是缓存假象时，下一步是刷新相关缓存并复测同一URL，确认绕缓存与带缓存请求返回一致。确认是真实死链接时，再决定返回410、配置301到最相关的新地址，或更新内链和站点地图。两种结论对应的动作不同，先分清再动手，能避免把有效页面误删或误改。