先分清 404 发生在哪一环节

遇到 404 时，首要动作不是立即处理，而是判断它出现在请求链路的哪一段。RFC 9110 对 404 的定义是「目标资源没有当前表示，或服务器不愿披露其存在」，该响应本身也可被缓存。因此，404 既不能证明资源被永久删除，也不能证明某一方被封禁。

  • 若正常收到带正文的 HTTP 404 响应，说明请求已抵达目标或中间层，此时应对比正常请求的最终 URL、路径、参数与重定向链是否一致。
  • 若出现 Tunnel connection failed: 404，说明 CONNECT 阶段即被拒绝、隧道未建立，应核对代理端点、协议与认证方式，这与目标页面返回 404 是两回事。
  • 若请求的是 API 却返回网关样式错误页，可能实际打到了代理服务商入口而非目标，需区分「获取 IP 列表的接口」与「真正建立连接的代理网关」。

定位的意义在于：目标侧改 URL、转发侧改配置、客户端改代码，若混在一起修，只会越改越乱。

目标侧：核对 URL、编码与资源生命周期

确认请求已到达正确目标后，再逐项检查 URL 本身：

  • 路径与大小写：API 版本号、路径前缀、结尾斜杠需与当前官方接口文档逐字核对。
  • 编码：检查 URL 中的 %20、%23 是否合法，可修正错误编码，但不能全局删除以 % 开头的片段。
  • 查询参数：必填参数是否缺失，签名类参数是否已过期。
  • 重定向：最终落地 URL 与原始发出 URL 是否一致，中间是否被改写。

资源生命周期同样需要确认：接口可能下线、资源可能被移除，这类情况换任何网络方案都无法恢复，正确做法是记录缺失、停止无界重试。另有一个常见误判：首页返回 200 并不代表 API 有效，两者是完全不同的资源。将正常请求与失败请求的完整 URL 逐字符对比，许多「诡异 404」在这一步即可显形。

转发侧：代理端点、路径改写与 Host

转发侧涉及两种角色：使用代理访问他人，以及自行维护反向代理。

前向代理端点接错

把「获取 IP 列表的 API 地址」误当成「真正建立连接的代理网关」填写，响应自然异常。应按服务商当前文档逐项核对协议、网关地址与端口、认证方式，并对照异常链。

自建反向代理路径改写不当

Nginx 的 proxy_pass 带不带路径，结果完全不同：

  • proxy_pass 带路径（含尾斜杠）时，location 前缀被替换。例如 location /api/ 配 proxy_pass http://backend/，请求 /api/items 时上游收到 /items。
  • proxy_pass 不带路径时，完整 URI 原样转发。例如 location /api/ 配 proxy_pass http://backend，请求 /api/items 时上游收到 /api/items。

应先确定上游需要的路径再选择配置，「一律加尾斜杠」反而会破坏正确路由。

Host 与上游虚拟主机不匹配

上游按 Host 分流时，转发请求的 Host 不对就会落到错误站点。node-http-proxy 的 changeOrigin 选项处理的正是此事，它修改的是转发请求的 Host，而非浏览器中的 Origin 请求头；Nginx 侧对应的是 proxy_set_header Host。另需注意，HTTP 的 Host 与 TLS 的 SNI 是两个不同概念。

客户端：解析缺陷、负缓存与对照实验

部分 404 由客户端自身造成。近期案例是 Scrapy 2.19.0 在处理 robots.txt 带行尾注释的 sitemap 声明时，会把 URL 拼成 /sitemap.xml%20 从而收到 404。临时处理方式是核对实际发出的 URL，显式提供已核实的正确 sitemap_urls，而不应通过关闭 robots 遵从来回避。

负缓存也需留意：404 可以被缓存，Nginx 官方示例中即有 proxy_cache_valid 404。若源站已修复却仍看到 404，应检查缓存 key 与 TTL 设置。

客户端对照的做法是：同一 URL 用不同库（如两个常见 HTTP 客户端）各请求一次，其余条件保持一致。结果不同说明问题在请求构造而非资源本身；但任何单个「换了就好了」的反馈都不能当作通用解法，根因仍需靠对照定位，其价值在于把猜测变成硬证据。

动态 IP 在 404 中的角色与验收标准

404 属于资源层语义，基本与出口 IP 无关：URL 错误、资源消失、转发配置错误，换多少 IP 都仍是 404。盲目轮换不仅无效，还会掩盖真实原因。

只有当证据指向「目标按出口做差异化响应」，例如不同出口对同一路径返回不同结果且对照实验已排除其他变量时，出口质量才进入视野。此类场景下，稳定且地域可选的出口池才有价值，可按国家与城市筛选出口做对照验证，相关服务可参考 https://www.ipxss.com/ 。它不解决 URL 错误与资源缺失，也不用于绕过站点访问限制。

验收标准是：同一资源返回预期数据、字段完整、时效正确。首页 200 不算数，错误页变好看不算数，「换了个库就好了」而未找到根因也不算数。验收结论应写入任务记录，便于下次同类问题直接对照。

常见问题解答

  • 404 一定是页面被删除吗？不是。404 只表示没有当前资源表示或不愿披露，URL、编码、转发、客户端缺陷都可能返回它。
  • 换 IP 能解决 404 吗？通常不能。404 与出口基本无关，只有对照证据指向出口差异化响应时，更换出口才有意义。
  • Nginx proxy_pass 尾斜杠如何影响转发？带路径时 location 前缀被替换，不带路径时完整 URI 原样转发，应按上游需要选择。
  • changeOrigin 改的是什么？改的是转发请求的 Host 头，而非浏览器 Origin 头，用于上游按 Host 分流。

总结

处理 proxy error 404 的顺序是：先分清 CONNECT 失败与目标响应，再按目标侧、转发侧、客户端三个分支分别核对 URL 与编码、端点与路径改写、解析缺陷与缓存。动态住宅 IP 这类出口资源仅在差异化响应有据时才有用。验收只看预期数据是否真正回来，不应把「不报错」当成「修好了」，更不应把盲目轮换当作排查手段。