极安代理 - 动态IP连接不稳定怎么排查？从鉴权、线路到IP切换逐项定位

> **结论先说：**动态IP连接不稳定，不一定是IP节点本身有问题。更有效的排查顺序是先看错误码，再检查鉴权、代理入口和网络线路，最后才处理IP切换、连接复用与并发策略。还没有定位故障层级就反复换IP，容易暂时掩盖问题，却很难找到真正原因。

动态IP偶尔连不上、响应忽快忽慢时，很多人的第一反应是重新提取IP。这种处理有时能让请求恢复，但不能证明原来的IP一定失效了。

白名单未生效、代理密码解析错误、客户端复用旧连接、跨地区线路波动，甚至目标站点响应变慢，最终都可能表现为“代理不稳定”。排查时应把一次请求拆成完整链路：

**业务程序发起请求 → 代理鉴权 → 连接代理入口 → 代理转发 → 出口IP访问目标站点 → 返回响应。**

先判断请求停在哪一段，再决定是改配置、换线路，还是切换IP。

## 先看错误码，不要一上来就换IP

同样是连接失败，背后的原因可能完全不同。排查时至少要记录错误码、异常类型、请求时间和总耗时。

| 连接表现                 | 优先检查方向                       |
| ------------------------ | ---------------------------------- |
| 持续返回 `407`           | 白名单、用户名、密码和鉴权方式     |
| 连接代理入口超时         | 本地网络、域名解析、端口或入口线路 |
| TLS握手失败              | 代理协议、证书和中间链路           |
| 部分出口正常、部分失败   | 节点状态、出口地区或资源差异       |
| 运行一段时间后出现 `429` | 请求频率、并发和目标站点规则       |
| 切换后仍显示原出口       | 长连接或连接池复用                 |
| 同一任务时快时慢         | 线路、出口节点和目标站点共同影响   |

`407`通常指向代理鉴权；`429`更接近访问频率问题；`5xx`则要继续确认响应来自代理环节还是目标站点。`403`也不能直接等同于IP不可用，应结合响应头、请求内容和对照测试判断。

如果请求连代理入口都没有成功，就没有必要先调整IP池。只有入口连接正常、不同出口的结果却存在明显差异时，才更值得检查IP调度和节点状态。

## 鉴权为什么容易被误判成线路故障

动态IP常见的鉴权方式是IP白名单和用户名密码。鉴权失败有时会直接返回 `407`，有时会在客户端多次重试后表现为连接超时，因此经常被误认为线路波动。

使用白名单时，首先应确认加入的是实际公网出口地址。办公网络、云服务器、容器和多出口网络中看到的本地地址，不一定是代理服务识别到的公网地址。家庭宽带或弹性公网地址发生变化后，原有白名单也可能随之失效。

还要注意配置同步时间。刚修改白名单就立即测试，如果配置尚未生效，很容易把鉴权失败误判为节点问题。

使用用户名密码时，应确认代理账号、密码、入口地址和端口属于同一个产品或接入区域。如果密码包含 `@`、`:`、`#` 等特殊字符，写入代理地址前需要进行编码，否则客户端可能错误解析凭据。

可以先使用最小请求排除业务代码干扰：

```bash
curl -v \
  -x "http://代理用户名:代理密码@代理入口:端口" \
  --connect-timeout 5 \
  --max-time 15 \
  "https://用于连通性测试的地址"
```

测试后重点看三个结果：

- 尚未连接代理入口就超时，应检查网络、端口和入口线路。
- 已连接入口但返回 `407`，应继续处理鉴权。
- 鉴权通过后才出现握手或业务错误，应转向协议、目标站点和请求策略。

正式日志中不要记录完整密码或带有鉴权信息的代理地址，保留脱敏账号、时间和请求标识即可。

## 怎么判断是本地网络、代理线路还是目标站点异常

只看总耗时，很难判断请求慢在哪里。一次代理请求通常包含域名解析、TCP连接、TLS握手、代理转发、目标站点处理和响应传输等阶段。

建议至少记录以下几类数据：

- 域名解析耗时；
- TCP连接耗时；
- TLS握手耗时；
- 首字节等待时间；
- 请求总耗时与最终状态码。

如果TCP连接阶段已经很慢，问题更可能发生在客户端到代理入口之间；如果连接和握手都正常，首字节却长时间没有返回，则需要继续检查出口线路和目标站点。

实际排查中可以做两组对照。第一组是在同一设备、同一时间访问同一个公开测试地址，分别比较直连与代理结果。两者都慢时，本地网络或目标站点更值得怀疑；只有代理请求慢时，再拆分入口和出口线路。

第二组是比较命令行与业务程序。命令行稳定、业务程序频繁超时时，通常要检查程序中的代理协议、连接池、环境变量、证书、超时和重试配置。如果只有容器或某台云服务器出现问题，则应进一步检查容器网络、云安全组和公网出口。

不要根据一两次请求下结论。可以在低频条件下连续测试一段时间，保留状态码、各阶段耗时和出口地区，观察异常是否集中在某个时段、某条线路或某类节点。

## IP已经切换，为什么看到的还是原出口

这种情况经常不是服务端没有切换，而是客户端仍在复用旧连接。

HTTP连接池会尽量复用已经建立的TCP连接。即使程序更新了代理参数，后续请求也可能继续使用原有连接，因此出口看起来没有变化。排查时可以临时关闭长连接，或在切换IP后销毁旧连接池并重新建立会话。

如果重建连接后出口随之变化，问题基本可以定位到连接复用。但不建议长期为每个请求重新建连，因为频繁进行TCP连接和TLS握手会增加延迟。确认原因后，应根据实际切换周期调整连接存活时间。

还要区分请求级切换与会话保持。连续分页或需要维持上下文的任务，通常需要一段时间内保持相同出口；广告监测、公开信息抽样等任务，则可能更关注按请求或按批次切换。业务需要连续会话时频繁换IP，容易造成前后请求状态不一致；任务需要轮换时一直复用同一会话标识，又会产生“IP没有切换”的误判。

对于不希望自行维护IP列表的持续请求任务，可以评估由服务端完成节点调度的隧道模式。极安代理公开资料显示，其国内隧道代理支持异常IP自动切换，但这项能力主要用于降低单个异常节点造成的影响，实际连接效果仍需结合目标地址、请求频率和客户端连接方式测试。

## 并发提高后频繁超时，该怎么定位

单请求正常、批量任务频繁超时，往往与并发、连接数、请求频率或本地资源有关，不能直接归因于IP质量。

比较稳妥的做法是先把并发降到1，确认基础链路稳定，再逐步增加到2、5或10。每次只调整一个变量，同时观察连接超时率、读取超时率、中位响应时间和P95响应时间。

如果并发提高后，连接代理入口的耗时明显增加，应检查本地连接池、可用端口、入口线路和套餐边界。如果入口耗时变化不大，但目标站点开始集中返回 `429`，则更应该降低请求频率。

连接超时与读取超时也要分开设置。连接超时代表客户端没有及时建立连接，读取超时则表示连接已经建立，但响应没有按时返回。把两者合并成一个总超时，会让日志失去定位价值。

重试同样不能一刀切。`407`应修复鉴权，`429`应降低请求频率，连接超时可以有限重试，`5xx`则要结合响应来源判断。无限重试不仅不能解决问题，还可能造成任务堆积和线路压力上升。

## 如何做一次能复现问题的测试

测试时应固定目标地址、请求内容、鉴权方式、代理入口和运行环境，再逐项改变连接复用、出口IP、线路或并发。一次同时修改多个条件，即使问题消失，也无法知道是哪项调整真正起作用。

建议按照下面的顺序进行：

1. 在并发为1、不复用旧连接的条件下建立基线。
2. 保持其他条件不变，开启连接复用并比较结果。
3. 固定代理入口，只更换出口IP或出口地区。
4. 固定出口条件，逐档提高并发。
5. 最后更换运行网络，检查入口线路差异。

向技术支持反馈时，应附上测试时间、运行地区、产品类型、代理入口、鉴权方式、协议端口、并发参数、超时设置、各阶段耗时和脱敏后的请求编号。相比“代理偶尔不稳定”，这些信息更容易支持进一步定位。

## FAQ

**Q：出现 `407` 后，更换IP有用吗？**

通常没有。`407`主要指向代理鉴权，应先检查白名单、用户名、密码和鉴权方式。只有鉴权通过后，才有必要继续判断出口IP状态。

**Q：返回 `403` 是否说明IP已经不可用？**

不能直接这样判断。`403`可能来自目标站点，也可能与请求条件、访问频率或会话状态有关，需要结合响应来源和对照请求分析。

**Q：为什么命令行正常，业务程序仍然超时？**

这种情况通常说明代理入口和鉴权在当前测试条件下可以工作，问题更可能出在业务程序的连接池、代理协议、环境变量、证书或超时设置中。

**Q：动态IP多久切换一次比较合适？**

没有统一周期。需要连续会话的任务应减少切换，公开信息抽样等任务可以按请求或批次切换。切换频率应服从业务会话要求，而不是越快越好。

**Q：自动切换IP后还需要配置重试吗？**

可以保留有限重试，但应根据错误类型处理。自动切换只能减少单个异常节点的影响，不能代替鉴权修复、请求频率控制和目标站点状态判断。

**Q：为什么低并发正常，高并发就频繁失败？**

优先检查连接池、可用端口、请求频率和套餐边界。如果代理入口连接正常，而目标站点开始集中返回 `429`，应先降低访问频率，不要继续增加换IP次数。