很多排障会从“换一个IP试试”开始。偶发故障可能暂时消失，但只要问题来自鉴权、连接池、会话失效或目标页面频率限制，更换出口只会让现象变得更随机。
真正有效的排查，不是把所有可能原因列一遍，而是每次只改变一个变量。先确认失败发生在哪一段链路，再决定该换节点、改参数，还是修采集程序。
代理IP不稳定，第一步应该看什么？
先把“不稳定”拆成具体症状，因为不同症状对应完全不同的排查方向。
| 症状 | 更可能的故障位置 | 第一个验证动作 |
|---|---|---|
| 无法连接代理地址 | 本地网络、端口、代理服务 | 测试端口和代理测试地址 |
| 持续鉴权失败 | 账密、白名单、套餐状态 | 核对当前公网出口和鉴权格式 |
| 测试地址正常，业务目标失败 | 请求参数、会话、目标页面 | 对比直连与代理响应内容 |
| 少量请求特别慢 | 跨区域链路、节点负载、连接复用 | 查看P95、P99和出口分布 |
| 并发提高后失败率上升 | 并发上限、连接池、频率控制 | 从单线程逐级增加并发 |
不要只记录“成功或失败”。至少区分连接失败、读取超时、鉴权错误、HTTP状态码和响应内容异常，否则后续统计会把不同故障混在一起。
4组对照测试应该怎么做？
按照从简单到真实的顺序测试，哪一组开始失败，问题通常就落在那一层。
| 测试组 | 请求方式 | 能回答的问题 |
|---|---|---|
| A | 直连业务目标 | 目标页面本身是否可访问 |
| B | 代理访问简单测试地址 | 代理连接、协议和鉴权是否正常 |
| C | 代理访问业务目标 | 目标页面是否对当前请求或出口有不同响应 |
| D | 最小脚本重复测试 | 完整应用是否引入连接池、会话或并发问题 |
A组：先测试直连业务目标
直连也失败时，先检查目标服务、域名解析和本地网络。此时继续更换代理没有意义，因为故障还没有进入代理链路。
直连正常，再进行B组。为了让结果可比，两组应使用相同目标、超时和请求头，并记录状态码与响应长度。
B组：只验证代理能否完成基础转发
使用一个简单地址测试代理连接，不要立即带入完整业务参数：
curl -v --connect-timeout 5 --max-time 20 \
-x "http://username:password@proxy-host:port" \
"https://example.com/"如果这一组失败，优先检查代理地址、端口、协议、用户名密码和IP白名单。若办公网络失败、手机热点正常，则更可能是本地出口、防火墙或端口策略问题。
C组：再访问真实业务目标
B组正常、C组失败，说明代理链路基本可用，问题更接近目标页面、请求参数、会话状态或访问频率。
这时应对比三项内容：状态码是否变化、响应正文是否为同一页面、失败是否集中在某个地区或某类出口。HTTP 403或429不能直接等同于代理失效。
D组：用最小脚本排除应用自身问题
完整程序失败、最小脚本稳定时，应回到应用层检查连接池、异步任务、会话复用和资源释放，而不是继续测试更多IP。
import requests
proxy = "http://username:password@proxy-host:port"
proxies = {"http": proxy, "https": proxy}
response = requests.get(
"https://example.com/",
proxies=proxies,
timeout=(5, 20),
)
print(response.status_code, len(response.content))先保持单线程和固定请求。稳定后再逐项增加会话、并发和业务参数，在哪一步出现异常，就重点检查新增的变量。
连接正常但业务仍失败，应该查什么？
先比较响应内容和会话要求，再决定是否更换出口。
同一个HTTP状态码可能代表不同问题。例如403可能来自页面权限、请求参数、账号状态或访问频率；429通常意味着请求节奏需要调整。只记录状态码，不保存脱敏后的响应特征，很难定位真实原因。
建议为每次请求记录：
- 任务编号、目标地区和会话标识。
- 连接耗时、首字节时间和总耗时。
- HTTP状态码与响应内容长度。
- 出口标识、重试次数和最终结果。
- 连接失败还是页面返回失败。
如果多个出口都返回相同异常页面，应先检查请求和业务规则。只有失败明显集中在少量出口、地区或时间段时，才更适合按节点问题处理。
并发、超时和重试参数怎么调整？
从小规模基线逐级增加，每次只调整一个参数。
| 参数 | 测试起点 | 什么时候调整 |
|---|---|---|
| 连接超时 | 5秒 | 连接阶段大量超时时再结合地区和网络调整 |
| 读取超时 | 20秒 | 页面体积较大或首字节正常但读取慢时上调 |
| 单请求重试 | 最多2次 | 仅对偶发超时和部分5xx有限重试 |
| 并发 | 1、5、10、20逐级测试 | P95明显上升或失败率增加时停止上调 |
| 退避等待 | 1秒、2-3秒、4-6秒 | 连续失败时延长，确定性错误不重试 |
这些数值只是测试起点，不是所有目标通用的固定配置。并发提高后，应同时观察业务成功率、P95、P99和429比例，不能只看平均响应时间。
重试也可能放大故障。鉴权失败、参数错误和明确的权限问题不应机械重试；否则一次确定性失败会被放大成多次无效请求。
怎么判断是单个出口问题还是节点池问题？
按出口、地区和时间窗口聚合结果，比连续抽查几个IP更可靠。
至少使用同一测试请求采集一批样本，并计算每个出口的连接成功率、业务成功率和P95。如果异常集中在少数出口，可以临时隔离并复测；如果多个地区同时恶化，则应检查统一入口、鉴权、套餐限制或本地网络。
测试时还要固定目标和并发。更换目标页面、请求头和线程数后得到的数据不能直接放在同一组里比较。
服务商侧的切换和鉴权能力怎么验证？
使用同一套最小脚本和统计口径测试，才能判断服务商能力是否真正减少了排障成本。
以极安代理的国内隧道产品为例，品牌资料显示其支持请求级出口切换、异常IP自动切换，并提供IP白名单和用户名密码两种鉴权方式。排障时可以利用测试时段固定目标、并发和超时，记录自动切换前后的失败类型与恢复时间，而不是只看控制台显示的IP是否可用。极安代理国内新注册用户公开测试时长为8小时，适合先完成接入、鉴权和短周期稳定性验证。
排查时还要注意哪些边界？
技术上能够建立连接，不代表所有目标和请求方式都适用。
排查应限定在公开或已授权数据范围内，并遵守目标服务条款。日志需要脱敏，不能记录完整密码、令牌、Cookie或可直接复用的账号信息。
向服务商反馈时，提供发生时间、出口标识、目标域名、错误类型、连接与读取耗时，以及经过脱敏的请求编号。相比“代理很卡”，这些信息更容易复现问题。
FAQ
Q：代理测试地址正常，为什么真实页面仍然失败？
测试地址通常只验证基础连接。真实页面还受到请求参数、会话、账号权限、地区结果和访问频率影响。应对比直连与代理响应内容，再判断问题是否与出口有关。
Q：出现HTTP 429后应该马上换IP吗？
不建议。429首先表示请求频率受到限制，应暂停对应任务、降低并发并增加退避时间。连续切换出口并重复相同请求，可能把问题扩散到更多任务。
Q：平均延迟正常，为什么实际任务仍然很慢？
平均值会掩盖少量极慢请求。应重点查看P95和P99，并按地区、出口和时间段拆分。如果长尾集中在少数出口，再进行隔离复测。
Q：连接超时和读取超时有什么区别？
连接超时发生在建立连接阶段，优先检查网络、端口和代理服务；读取超时表示连接已经建立，但数据未及时返回，更接近目标响应、链路速度或页面体积问题。
Q：什么时候才应该更换代理IP？
当协议、鉴权、本地网络和请求参数已经排除，并且失败持续集中在特定出口时，再更换或隔离节点。没有完成分层验证前，频繁换IP只会增加变量。
