极安代理 - 数据采集时代理 IP 突然变慢？教你排查延迟、带宽的方法

采集任务跑着跑着，原本几秒返回的页面开始频繁超时。第一反应可能是“代理 IP 变慢了”，但先别急着换 IP：连接代理入口、代理访问目标站、目标站生成响应，以及下载页面内容，任何一段变慢，最后都会表现为采集速度下降。

**最快的排查方法是：固定同一个目标 URL，分别测直连和走代理的耗时，再观察低并发与业务并发下的差异。**这样至少能先判断，是单次请求就慢，还是请求量上来后才慢。

## 先把一次请求拆开看

在运行采集程序的机器上，选一个平时能正常访问、响应内容相对稳定的目标 URL，执行：

```bash
curl -sS -o /dev/null \
  --connect-timeout 5 --max-time 20 \
  -x "http://代理入口:端口" \
  -w '状态码:%{response_code}\n代理CONNECT:%{http_connect}\nDNS累计:%{time_namelookup}s\n建连累计:%{time_connect}s\nTLS累计:%{time_appconnect}s\n首字节累计:%{time_starttransfer}s\n总耗时:%{time_total}s\n下载字节:%{size_download}\n' \
  "https://目标站点/测试页面"
```

使用账密鉴权时，可按实际配置增加 `--proxy-user`；使用白名单鉴权时，先确认采集服务器的**公网出口 IP**已获授权。不要把真实账密写进共享脚本或排障截图。

这些时间是从请求开始计算的**累计时间点**，不能把它们直接相加。对 HTTP 代理访问 HTTPS 目标站而言，`time_connect` 主要反映连接代理入口的阶段；`time_appconnect` 还包含经代理建立到目标站的 TLS 连接。`time_starttransfer` 是收到首字节前的累计耗时，`time_total` 是整个请求完成的时间。它们能帮助定位异常阶段，但不能仅凭某一个数值断定是哪一方故障。[1]

建议连续测多次，记录中位数和较慢的一批请求，而不是只看一次最快结果。接着保持 URL、请求头、采集机器和测试时段尽量一致，去掉 `-x` 再测直连。如果目标站不允许直连，就不要把“直连失败”解释成代理故障，改用另一个允许访问的基线地址辅助判断。

## 建连就慢：先查入口、地区和出口 IP

如果 `time_connect` 明显高于平时，先确认采集机器到代理入口的链路：入口域名和端口是否填对、所在服务器是否更换了公网出口、代理入口是否与业务服务器相距过远。若只有某一台采集机器慢，而其他机器正常，优先查这台机器的网络和运行状态。

如果连接入口很快，但到首字节的时间拉长，则要继续比较：**同一代理访问不同目标站**，以及**不同代理出口访问同一目标站**。只有特定目标站变慢时，目标站处理、访问限制或出口到目标站的线路都值得排查；换出口后恢复，才更有理由继续检查出口线路。别把目标站的 429 限流、403 拒绝访问，也笼统记成“代理延迟高”。

短效代理还要检查 IP 的提取时间和存活期。IP 已临近到期或失效，程序却仍把它放在可用池里，重试和超时会拖慢整批任务。更新 IP 池、剔除异常节点，比单纯延长超时时间更有针对性。

## 首字节不慢，页面却下载很久：再查带宽

若 `time_starttransfer` 基本正常，而 `time_total` 随页面体积明显增加，重点看内容传输阶段。先核对 `size_download`：抓一个很小的接口响应，不能代表下载大页面、图片或附件时的吞吐表现。

这时做两组测试更有用：

- **相同并发，比较小响应和大响应。**只有大响应慢，优先检查实际吞吐、页面体积和带宽占用。
- **相同目标，逐步提高并发。**低并发正常、高并发时整体耗时和超时率一起升高，检查采集服务器出口、代理业务带宽、连接池和请求排队情况。

带宽和请求频率也不是一回事。公开资料介绍的极安隧道代理基础配置为**默认每秒 5 个请求、默认 5M 带宽**；排障时仍应以当前控制台和实际套餐为准，分别核对请求频率与带宽规格，不能只看其中一个数字。[2] 例如页面平均下载量变大，即使每秒请求数没有增加，也可能先遇到吞吐瓶颈；反过来，小页面高频请求则可能先碰到频率限制。

## 低并发快、任务一跑就慢：别漏掉采集程序

线上任务的“慢”，可能包含请求尚未发出前的等待时间。连接池太小、线程排队、解析任务占满 CPU、失败请求反复重试，都会拉长从“任务入队”到“拿到结果”的时间，而单条 `curl` 测试未必能复现。

排查时把日志至少分成三段：**任务排队时间、HTTP 请求时间、解析及落库时间**。再按并发梯度测试，观察哪一档开始出现耗时陡增。若 HTTP 请求时间稳定，只有任务总耗时变长，先优化采集器内部；若请求时间与并发一起上升，再核对代理规格和目标站的响应状态。不要靠无限加线程提速——排队和重试增加后，有效采集量反而可能下降。

极安代理提供短效代理和隧道代理两种接入方式。短效代理适合在程序端管理 IP 池的任务，排障重点是**IP 是否及时更新、是否被重复分配过多请求**；隧道代理使用统一入口，排障重点则是**入口链路、当前请求频率、业务带宽及目标站响应**。两种模式先确认瓶颈位置，再调整 IP 调度、并发或规格，通常比一慢就换套餐更有效。[2]

## 一个可以照着执行的排查顺序

1. **保存故障现场：**记下变慢时间、目标 URL、状态码、超时类型、页面大小和当时并发。
2. **单请求测分段耗时：**在采集机器上连续测试同一 URL，区分建连、首字节和内容传输阶段。
3. **做对照：**条件允许时比较直连与代理；再比较同一代理的不同目标、同一目标的不同出口。
4. **逐档增加并发：**同时看请求耗时、超时率和有效完成量，确认是否存在频率、带宽或客户端排队问题。
5. **只改一个变量再复测：**例如先降低并发，再调整出口地区或连接池。一次改三项，即使速度恢复，也很难知道真正原因。

代理 IP 突然变慢，不必先猜是“IP 质量”还是“带宽不够”。**建连慢查入口链路，首字节慢查目标响应和出口路径，内容传输慢查页面体积与吞吐；只有上并发才慢，就把请求限制和采集程序的排队一起检查。**拿到对应阶段的证据，再决定换出口、调整调度，还是升级资源。

## 常见问题：

**Q：代理 IP 延迟高和带宽不足，有什么区别？**

**延迟高**主要表现为等待响应的时间变长：连接代理入口慢，或迟迟收不到目标站的首字节。**带宽不足**更常表现为首字节来得不慢，但较大的页面或文件下载很久。用同一个 URL 对比 `time_starttransfer`、`time_total` 和 `size_download`，再观察并发增加后的变化，比只看“请求总耗时”更容易区分两者。需要注意，目标站本身响应慢，也会拉长首字节时间，不能仅凭这一项认定代理故障。

**Q：为什么 curl 测试很快，采集程序却越来越慢？**

`curl` 通常只测单次请求，采集程序还要处理任务排队、连接池、失败重试、页面解析和数据落库。先在程序日志里分别记录**排队耗时、HTTP 请求耗时、解析落库耗时**。如果只有排队时间增加，优先检查线程数、连接池和下游处理能力；如果 HTTP 请求时间也随并发上升，再查代理规格、目标站限流及网络链路。

**Q：换了代理 IP 还是慢，是不是代理服务出了问题？**

不一定。若换 IP 后只有同一个目标站慢，先看目标站状态码、响应时间及请求频率；若多个目标站都慢，再检查采集机器到代理入口的连接时间和业务带宽。排查时一次只换一个条件，例如保持目标 URL 和并发不变，只换出口 IP。否则即使速度恢复，也难判断是哪项改动起了作用。

**Q：开得越高，采集速度一定越快吗？**

不一定。并发提高后，请求可能在客户端连接池、代理入口或目标站排队，失败重试也会占用额外资源。建议逐档提高并发，同时记录**每分钟有效完成量、超时率和较慢请求的耗时**。如果有效完成量不再增长，超时率却持续上升，就该先降并发、查瓶颈，而不是继续加线程。

**Q：怀疑带宽不够，可以只测一个 IP 查询接口吗？**

不够。IP 查询接口的响应通常很小，适合确认代理是否生效，却不足以判断大页面采集时的吞吐。应在获得授权的目标上，分别选取小响应和具有代表性的大响应，保持采集机器、时段和并发条件一致进行比较。如果只有大响应明显变慢，再结合实际下载字节数、传输耗时和当前业务带宽检查；不要用单次测速结果代替真实任务表现。