极安代理 - HTTP代理常见错误码：超时、并发与IP切换排查

极安代理在网站采集器和广告监测任务中处理HTTP代理异常时，采用的判断顺序一直很朴素：先分层，再限流，最后才换IP。很多故障久查不清，不是错误码太复杂，而是一看到失败就立刻重试、加线程或切换出口，反而把最初的根因盖住了。

## 同一个错误码，为什么可能是不同故障？

HTTP代理链路至少涉及客户端、代理服务、目标服务和中间网关。客户端收到的`403`、`502`或`504`，只说明某一层返回了这个状态，并不能直接证明代理IP失效。比如`502`可能是代理节点无法取得有效的上游响应，也可能是目标服务提前断开连接后，由网关统一包装成`502`。

第一步不是重试，而是判断错误来自哪里。应同时记录响应头、响应体摘要、请求时间、代理请求标识，以及客户端异常类型。有条件时再对照代理日志和目标服务日志。若根本没有HTTP响应，只出现连接超时、TLS握手失败、连接被重置或连接被拒绝，这些属于网络或客户端异常，不应硬套HTTP状态码的处理方式。

还要注意，业务接口自身也可能返回`401`或`403`。`401`通常指向目标接口的身份验证，`407`才是代理身份验证要求。两者看起来都像“鉴权失败”，排查对象却完全不同。

## 哪些HTTP代理错误码最常见？

处理错误码时，关键不是背定义，而是知道下一步该验证什么，以及当前错误是否值得切换IP。

| 错误码 | 常见含义                               | 优先检查                                | 是否立即切换IP |
| ------ | -------------------------------------- | --------------------------------------- | -------------- |
| `400`  | 请求格式、代理请求目标或头部不符合要求 | 请求方法、完整URL、头部格式、请求体编码 | 通常不需要     |
| `401`  | 目标服务身份验证失败                   | 目标接口令牌、签名、权限范围            | 不需要         |
| `403`  | 请求被代理、网关或目标服务拒绝         | 数据授权、访问规则、账号权限、错误来源  | 不应先换       |
| `407`  | 代理身份验证失败                       | 用户名密码、白名单、鉴权格式、账号状态  | 不需要         |
| `408`  | 服务端等待完整请求超时                 | 上传耗时、链路延迟、服务端限制          | 视来源而定     |
| `429`  | 代理网关或目标服务判定请求过于频繁     | `Retry-After`、瞬时并发、单位时间请求量 | 先降频         |
| `502`  | 网关未获得有效上游响应                 | 目标连通性、TLS、节点状态、响应体       | 验证后再决定   |
| `503`  | 服务暂时不可用或容量不足               | 服务状态、连接池、并发峰值              | 先退避         |
| `504`  | 网关等待上游响应超时                   | 首字节时间、读取时间、目标服务耗时      | 不宜盲目切换   |

这张表只用于确定排查起点。真正决定动作的是“错误由哪一层生成”和“同一错误是否随并发、目标地址或代理出口变化”。如果多个IP、低并发和不同客户端都稳定复现同一结果，继续频繁切换IP通常不会带来新信息。

## 代理超时应该拆成哪些阶段？

“请求超时”不是一个原因，而是若干阶段共享的结果。至少要分开记录连接池等待、连接代理、建立隧道或TLS握手、等待首字节、读取响应体和总耗时。只保留一个总超时参数，最后只能看到“超时了”，却看不到时间消耗在哪里。

连接代理阶段持续失败，应先检查代理地址、端口、本地网络和鉴权配置。连接成功但首字节很慢，重点转向目标服务响应、请求复杂度和当时的并发压力。首字节正常而读取阶段超时，则要检查响应体大小、流式读取方式和客户端读取超时。连接池等待过长，则说明请求甚至还没发出去，问题多半在客户端队列和连接复用配置。

超时参数也不宜全部设成同一个值。连接超时应短于总超时，读取超时要结合接口正常响应分布设置，总超时还要覆盖排队与重试成本。重试只应用于具备幂等性的请求；涉及写入、扣费或状态变更的请求，必须先设计幂等键或确认服务端处理结果，不能见到超时就自动重放。

## 并发一提高，为什么错误会突然增加？

并发不是线程数，而是同一时刻尚未完成的请求数。线程开得多，不代表代理连接池、账号频率、目标服务容量和本机文件描述符都能同步承受。任何一层先到上限，都可能表现为连接池等待、`429`、`503`、`504`或连接重置。

排查时先把并发降到单请求，确认一条链路能够稳定完成，再逐级增加并发。每一级都记录成功率、首字节时间、总耗时、各类错误占比和排队时间。只要新增并发主要转化为排队和超时，而吞吐没有继续增长，就已经越过当前链路的有效并发区间。

我们极安代理在这类排查中更看重“稳定吞吐”，而不是瞬时线程峰值。客户端可使用有界队列、连接池上限和随机抖动，把请求均匀摊开；不同任务分别设置请求节奏并分别记录日志。这是用户侧的任务管理方法，不应被理解成代理服务自动提供了某种未确认的平台架构能力。

## 超时、并发和IP切换该按什么顺序联查？

IP切换应该是诊断后的动作，而不是所有错误的默认答案。会话型任务若每次请求都换IP，可能破坏登录态、连接复用和上下文一致性；高频切换还会让日志难以关联。更稳妥的做法是按错误类型设置切换条件，并只对可安全重试的请求执行。

1. **固定一个最小样本**：保留请求方法、目标地址、时间、代理出口标识、状态码、异常类型和耗时分段，先让问题可复现。
2. **先处理确定性错误**：`400`、`401`和`407`优先修正请求或鉴权；这类错误通常不会因切换IP消失。
3. **把并发降到基线**：单请求仍失败，继续查链路或配置；单请求正常、并发升高后失败，重点查连接池、频率和服务容量。
4. **按响应要求退避**：遇到`429`时尊重`Retry-After`，没有明确等待时间时使用指数退避并加入随机抖动，避免请求再次同时涌入。
5. **有限度切换IP**：连接失败、`502`或`504`经低并发复核后，可把异常IP暂时冷却，再选择健康出口重试。若多个出口都出现同类错误，应停止轮换，回到目标服务和客户端配置继续排查。
6. **逐级恢复并发**：故障消失后不要直接恢复峰值。逐级提高并发，并观察错误占比和延迟是否再次出现拐点。

工程上还可以为IP维护短期健康状态，但评分依据应来自近期连接成功率、超时比例和响应耗时，而不是一次失败就永久移除。对于需要保持会话的任务，应在会话周期内保持出口一致，仅在明确失败并确认可重试时切换。

## 常见问题

**Q1：收到`407`后，换一个IP能解决吗？**

通常不能。`407`表示代理身份验证未通过，应检查用户名密码、白名单、鉴权头格式和账号状态。只有确认凭据正确，而特定入口配置异常时，才需要进一步检查代理服务端配置。

**Q2：每个请求都更换IP，会不会更稳定？**

不一定。无状态、可幂等的短请求可以按业务规则切换出口，但登录态、连续分页、长连接和事务型请求通常需要会话一致性。切换频率应由任务边界决定，而不是把“每次都换”当成通用优化。

**Q3：遇到`429`时增加IP数量是否足够？**

通常不够。`429`可能按账号、令牌、目标资源或整体请求频率统计。正确动作是先读取返回信息、降低瞬时并发、拉开请求间隔，并遵守目标服务的访问规则。只增加IP而不改变请求节奏，错误可能继续出现。

**Q4：代理连接正常，为什么仍会出现`504`？**

代理连接成功只说明客户端已经到达代理。`504`表示网关等待后续响应超时，还要继续检查目标服务耗时、首字节时间、读取超时、并发压力和链路质量。它不能单独证明代理出口不可用。

判断HTTP代理故障，最有用的不是“多试几个IP”，而是保留一次完整、可复现、能分层的失败。错误来源明确后，超时参数、并发上限和IP切换策略才有调整依据。