代理返回 404 怎么排查：URL、重定向、地区版本、Host 和缓存

代理请求返回 404 时，先不要把问题直接归因于代理失效。按照 HTTP 语义，404 表示当前服务器没有找到目标资源的现有表示，或者不愿说明该资源是否存在。它既可能来自错误 URL、重定向后的路径、地区版本或 Host 路由，也可能来自边缘缓存、目标站权限策略，甚至代理入口前后的不同服务节点。

排查前固定请求方法、完整 URL、查询参数、代理协议、认证方式、出口线路和时间窗口。记录最终 URL、每一跳状态码、响应头、响应体摘要、Host、出口 IP、DNS 结果、地区识别、缓存字段和请求标识。不要在来源未明时连续换线路或批量重试。

先把 404 和 403、405、410 分开

403 表示服务器理解请求但拒绝执行；404 表示当前表示未找到或服务器不愿披露其存在；405 表示目标资源知道请求方法但不支持该方法；410 更明确地说明资源预计已永久移除。404 本身不能证明资源从未存在，也不能证明只要更换 IP 就能恢复。

如果响应是 403，应转入权限、地区和请求条件排查；如果是 405，应先核对方法与 Allow 响应头；如果是 410，应向资源所有者确认迁移或下线记录。只有确认状态码确实为 404，才继续下面的路径。

第一步：保存完整 URL 和重定向链

把原始 URL、大小写、路径末尾斜杠、查询参数、编码形式和片段来源一起保存。关闭自动重定向后记录每一跳的 Location、状态码、域名、路径和协议，再开启重定向得到最终落点。很多“代理返回 404”实际发生在 301、302、307 或 308 之后，而不是原始地址。

• 通过条件：本地直连与代理路径进入相同重定向链，并落到同一最终 URL。
• 失败条件：某一跳在代理路径下进入不同域名、语言目录、地区目录或旧路径。
• 停止条件：继续测试需要提交表单、修改账号数据或访问未获批准的资源。

需要统一证据字段时，可以沿用出口 IP、状态码和请求阶段日志模板，把每一跳响应与出口信息放在同一条记录中。

第二步：确认 404 由哪一跳生成

比较响应头、错误页结构、服务器标识、缓存字段、请求标识和时间特征。目标站、内容分发节点、应用网关、地区站点、代理入口或上游服务都可能生成看起来相似的 404 页面。只有先确认响应来源，后续的 URL、缓存和路由检查才有意义。

第三步：逐字符核对 URL、路径和参数

检查域名、路径大小写、末尾斜杠、文件扩展名、百分号编码、重复斜杠、查询参数名称与顺序，以及参数值是否被客户端二次编码。某些站点在不同操作系统或框架中对大小写和规范化规则不同，复制出来的可见地址也可能隐藏不可见字符。

用一个已知可访问的低风险页面做基线，再只改变一个路径字段。不要猜测资源编号，也不要遍历未获批准的目录。若原地址来自业务系统，应回到正式入口重新获取，而不是拼接可能已经失效的深层链接。

第四步：检查 Host、SNI 和目标域名是否一致

HTTPS 连接中的 SNI、HTTP Host、URL 域名和证书目标应指向同一套预期服务。若客户端经过代理后改写 Host、连接到错误域名、复用了旧连接，或把备用域名与主站路径混用，服务器可能把请求送入默认站点并返回 404。

记录解析后的目标地址、TLS 证书域名、请求 Host、最终 URL 和响应服务器标识。不要通过手工替换 Host 去尝试访问未公开资源；排查目标只是确认正式配置是否一致。

第五步：核对 DNS、IPv4 和 IPv6 落点

本地解析与代理侧远程解析可能得到不同地址，IPv4 和 IPv6 也可能进入不同边缘节点。如果某一地址族或解析路径指向旧节点、测试环境或尚未同步的站点，就可能出现稳定 404。应按本地解析、远程解析和 IPv4/IPv6 对照顺序记录解析器、答案、有效时间和最终连接地址。

通过条件是不同解析路径虽然地址不同，但都进入正确站点并返回一致资源；失败条件是某一解析路径稳定进入错误站点或旧版本；结果随时间波动时，应暂停业务请求并扩大观察窗口。

第六步：比较地区版本、语言目录和站点映射

部分站点会根据出口地区、域名、语言、登录状态或入口页面，把请求重定向到不同站点版本。原路径在主站存在，不代表在地区子站或语言目录中也存在。记录出口国家或城市、最终域名、语言目录、地区参数和目标站实际返回的版本。

地区识别不一致时，按GeoIP、DNS、缓存和出口复测顺序做受控对照。第三方定位结果只能提供线索，最终判断要以目标站的实际重定向和响应为准。

第七步：排除缓存中的旧 404

404 响应可能被缓存。检查 Age、Cache-Control、Expires、ETag、Via 和边缘节点标识，比较首次请求与受控复测的缓存命中情况。不要只靠强制刷新判断，也不要用大量随机参数制造新缓存键。

如果源站已恢复但某个边缘节点仍返回旧 404，应由站点或缓存管理方处理失效规则。客户端侧只需保存节点、时间、缓存年龄和响应差异，不应高频轮换出口去放大问题。

第八步：考虑权限隐藏和资源生命周期

有些站点会用 404 隐藏受保护资源是否存在，因此“登录后可见、未登录 404”不一定是路径错误。核对当前账号是否通过正式入口获得访问权限、会话是否有效、资源是否已迁移、下线或更名。不要复制其他账号的登录状态，也不要导入来源不明的浏览器数据。

若资源所有者明确说明资源已永久移除，更适合按迁移或下线流程处理；若权限与资源状态不清，应停止测试并由业务负责人确认。

404 排查决策表

重试边界和恢复顺序

404 通常不是靠立即重复就会消失的临时网络错误。只有在 URL、跳转、Host、解析、地区映射、缓存或权限中的一个已确认问题被正式修复后，才进行少量复测。重试次数、等待时间和停止阈值应提前定义，可参考超时、限流、连接重置和会话保持的重试边界，但不要把临时网络错误的策略直接套到资源不存在问题上。

恢复时先验证一个不修改业务数据的低风险请求，再核对最终 URL、状态码、出口 IP、地区、DNS、缓存字段和请求标识。连续结果稳定后，才恢复需要登录状态或会改变业务数据的任务。

团队交接需要记录什么

至少记录目标资源、原始 URL、最终 URL、重定向链、请求方法、代理入口、出口 IP、DNS 答案、地址族、Host、证书域名、地区版本、缓存字段、首次异常时间、对照结果、修复项、复测结果、负责人和下一次复核时间。

如果本次异常发生在线路变更之后，把结果补入代理路线变更记录字段。需要选择其他已批准线路时，先确认代理资源与服务范围，再按相同字段完成验收。

最终判断

代理返回 404 的排查重点不是立刻换 IP，而是确定请求最终到达了哪里、服务器按哪个 Host 和地区版本处理、路径是否经过重定向、解析和缓存是否一致，以及资源是否仍存在并允许当前访问。证据不足、跳转不明、权限不清、结果波动或需要猜测路径时，都应暂停批量任务并转人工确认。