死链查询：同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9fcd8b148538.html
📄
死链查询：同一地址因设备或登录状态返回不同内容怎样对照
先给结论：把“地址相同”拆成“请求条件相同”再查。用匿名会话、固定User-Agent、不带Cookie的请求各取一次响应，记录状态码、最终URL和正文关键片段；如果三次结果不一致，不要急着判定死链，而应先确认差异来自服务端分流，还是来自客户端渲染。下面用一个假设情境说明怎么一步步做。
假设情境：手机端404、桌面端200的同一URL
假设你有一个商品页 /item/1001，在桌面浏览器登录状态下打开正常，在手机浏览器未登录状态下返回404。直觉会认为这个地址已经死掉，但更可能的解释有三种：
- 服务端按User-Agent或设备类型返回不同模板，移动端模板缺少该路由。
- 登录态下接口返回数据，未登录时后端直接判定资源不可见并返回404。
- 页面本身存在，但移动端渲染依赖的接口失败，前端把错误状态渲染成“404”外观。
这三种解释对应的修复动作完全不同，所以对照的目的不是找“哪个结果是真的”，而是找“哪个条件改变了响应”。
第一步：固定请求条件，做三组对照
用同一台机器、同一时间窗口，分别发三次请求，只改变一个变量：
- 匿名桌面请求：不带Cookie，User-Agent设为常见桌面浏览器，记录状态码、响应头中的Location、Content-Type和正文前若干字符。
- 匿名移动请求：其他不变，只把User-Agent换成移动端，再记录同样字段。
- 带登录态请求：使用一个测试账号的Cookie，仍用移动端User-Agent，记录同样字段。
如果第1组200、第2组404、第3组200，说明分流条件在“是否登录”或“移动端模板”上，而不是URL失效。如果第1组和第2组都404、第3组200，则更可能是权限控制把未登录访问当作资源不存在处理。如果三组状态码都200但正文不同，问题就从“死链”转向“内容可见性差异”。
第二步：区分服务端返回与客户端渲染
状态码和正文不一致时，要判断404是服务端发的，还是前端脚本渲染出来的。动作很简单：查看响应头里是否有服务端返回的404状态，还是先返回200、再由JavaScript把页面替换成错误提示。
- 服务端404：响应头第一行就是404，正文通常由服务端模板输出。此时应检查路由、权限和移动端模板配置。
- 客户端渲染的404：响应头是200，但正文初始为空或只有壳，脚本执行后才显示错误。此时要检查接口返回和前端路由，而不是直接改服务端路由。
这个区分会直接影响下一步：前者需要看服务端日志和路由规则，后者需要看接口响应和前端错误处理。把两者混在一起，容易把接口失败误判成页面死链。
第三步：用日志和状态码交叉验证，而不是只看一次结果
假设你在三次对照中发现移动端匿名请求返回404，但服务端访问日志里没有这条记录，那么可能是请求根本没到达应用层，被CDN、WAF或反向代理拦截。反过来，如果日志里有记录且状态码是404，说明应用层确实做出了这个判断。
可核对的证据包括：
- 请求时间、User-Agent、是否带Cookie、来源IP段。
- 响应状态码、最终URL、重定向链。
- 服务端访问日志中是否出现该请求，以及对应的上游状态。
注意：请求量或抓取量归零不能单独证明处理正确。它也可能是采集工具被限流、日志采样、缓存命中或统计口径变化造成的。必须结合状态码和日志一起看。
第四步：根据对照结果决定改哪里
如果差异来自登录态，修复方向是让未登录访问返回明确的403或引导页，而不是404；如果差异来自移动端模板缺失，应补齐移动端路由或统一模板；如果差异来自客户端渲染，应修正前端错误处理，让接口失败不伪装成页面不存在。
假设你确认是移动端模板缺失，动作是给移动端补上同一路由并重新用三组条件各请求一次。如果补完后匿名移动请求从404变为200，且正文关键片段与桌面端一致，才说明这个地址在移动端不再被当作死链。若补完后仍返回404，则要继续查权限或CDN规则，而不是重复改模板。
最后提醒一点：robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。对照设备与登录状态时，先把请求条件固定下来，再用状态码、最终URL和日志交叉验证，才能把“看起来像死链”与“确实是死链”分开。
