代理请求失败别急着换IP：从认证、协议到超时的开发排查路径

代理配置出问题时，开发者最不该只记录一行“请求失败”。

因为同样是失败，407、403、502、504、ECONNRESET 指向的是完全不同的链路位置。只有把错误代码、代理出口、目标 URL、响应时间放在一起看，才能判断是认证错、请求错、转发错，还是连接生命周期异常。

先把错误拆成五类

建议先在日志里把代理错误分成五组：

PROXY_AUTH_ERROR
TARGET_ACCESS_ERROR
PROXY_GATEWAY_ERROR
GATEWAY_TIMEOUT
CONNECTION_RESET

这一步很重要。否则所有失败都堆在一个 error 字段里，后面只能靠猜。

407：认证失败类错误

407 对应代理认证失败。它最常见，也最好排。

建议检查：

• 代理 URL 是否包含用户名和密码；
• 账号密码是否过期；
• 特殊字符是否经过 URL 编码；
• 当前 IP、账号或套餐是否有授权限制；
• 代码里是否同时配置了 http 和 https 代理。

推荐日志字段：

proxy_host
proxy_port
auth_type
status_code
error_message

注意不要在日志里明文保存密码。可以只记录账号标识或认证方式。

修复路径：

1. 先用 curl 验证认证；
2. 再检查代码代理配置；
3. 最后排查授权范围。

如果 curl 返回 407，说明问题不在业务代码；如果 curl 正常而程序失败，说明请求库读取代理参数时可能有问题。

403：目标拒绝类错误

403 说明请求到达了目标服务，但目标服务拒绝响应。

它可能和代理有关，也可能和业务请求本身有关。尤其在舆情监测、电商选品、APP大数据分析场景中，不同页面的访问要求不同，不能把所有 403 都归因到代理出口。

建议记录：

request_url
request_method
status_code
user_agent_hash
cookie_exist
referer_exist
response_length

排查重点：

• 请求头是否完整；
• Cookie 或 Token 是否失效；
• 访问频率是否过高；
• 是否只有某一类 URL 返回 403；
• 是否直连也会返回 403。

修复路径：

1. 对比直连和代理访问结果；
2. 补齐必要请求头；
3. 降低访问频率；
4. 区分列表页、详情页、搜索页分别统计。

如果只有某些 URL 类型报 403，说明应优先调整请求策略，而不是简单替换代理。

502：代理网关类错误

502 更接近代理转发层问题。它表示代理层没有拿到正常上游响应。

常见触发点：

• 代理协议写错；
• 端口和代理类型不匹配；
• 代理出口临时不可达；
• 目标站上游响应异常；
• HTTPS 目标请求的代理协议配置不正确。

建议记录：

target_scheme
proxy_scheme
proxy_port
status_code
retry_count

开发中最容易忽略的是 target_scheme 和 proxy_scheme 的区别。访问 HTTPS 目标，不代表代理地址一定要写成 HTTPS 协议。很多场景下，HTTPS 请求仍然通过 HTTP 代理协议发起。

修复路径：

1. 查代理服务文档里的协议格式；
2. 分别测试 HTTP 目标和 HTTPS 目标；
3. 检查端口是否对应当前代理类型；
4. 对 502 做短间隔重试，但不要无限重试。

504：等待超时类错误

504 指代理网关等待目标响应超时。

它经常和并发、响应体大小、目标服务速度有关。单纯增加 timeout 可能缓解现象，但不能解释原因。

建议记录：

connect_time_ms
ttfb_ms
download_time_ms
total_time_ms
concurrency
response_size

其中 ttfb_ms 很关键，它表示首字节响应时间。如果首字节很慢，说明目标服务或代理出口链路慢；如果首字节不慢但下载慢，说明响应体大小或网络吞吐更值得关注。

修复路径：

1. 拆分连接超时和读取超时；
2. 降低并发后对比错误率；
3. 对大页面做分页请求；
4. 给重试增加退避间隔；
5. 单独统计慢接口，不要和普通接口混在一起。

ECONNRESET：连接中断类错误

ECONNRESET 表示连接被中途关闭。它通常不会稳定复现，因此更依赖日志聚合。

建议记录：

connection_reused
pool_size
active_connections
request_duration_ms
error_type

如果连接复用比例很高，同时 ECONNRESET 上升，就要重点检查连接池。旧连接被复用时，服务端可能已经关闭连接，客户端再次写入数据就会触发连接重置。

修复路径：

1. 调小连接池复用时间；
2. 限制单出口并发连接；
3. 对连接重置做有限重试；
4. 避免长时间复用同一会话；
5. 把连接错误从 HTTP 状态码统计中拆出来。

一套可落地的日志模板

建议代理请求日志至少包含这些字段：

task_id
request_url
target_domain
proxy_endpoint
status_code
error_type
connect_time_ms
response_time_ms
retry_count
timestamp

有了这些字段，排查时可以回答：

• 哪些目标域名错误率最高？
• 哪些代理出口更容易失败？
• 哪些错误只在高并发下出现？
• 重试后成功率是否明显提高？
• 403、502、504 是否集中在同一类页面？

这些问题比“这个代理能不能用”更接近真实根因。

结论

代理配置异常的排查重点，不是把所有失败请求重试一遍，而是先把错误代码分类。

407 是认证问题，403 是目标响应问题，502 是代理转发问题，504 是等待超时问题，ECONNRESET 是连接生命周期问题。日志字段越清晰，排查越接近工程诊断；日志越粗糙，处理方式越容易退回到盲目替换代理。