极安代理 - 隧道代理技术详解：每次请求自动换IP，云端是怎么做到的？

> **摘要**：隧道代理的核心，是把"换IP"这件事从客户端挪到云端：程序固定连一个入口地址，网关在转发层给每次请求分配不同的出口IP，客户端不用维护IP池，也不用写调度逻辑。本文从转发原理讲到接入代码，再到并发调优和排障，目标是让你一小时内跑通。

做采集的工程师大都写过这么一套东西：调API拉IP列表，起个定时任务测活，失败的剔除，不够了再拉。逻辑本身不难，真正消耗精力的是维护：目标网站策略一升级，池子的淘汰率就变，检测频率、重试策略都得跟着调。

时间长了，花在这个模块上的精力甚至超过业务代码本身。隧道代理要解决的，就是这部分成本。

## 隧道代理和API提取模式的差别在哪？

**一句话：差别在"谁来管IP的生命周期"。** API提取模式（也就是常说的短效代理），IP列表交到客户端手里，获取、测活、轮换、剔除全在程序侧完成；隧道代理把这些环节整体收到云端，客户端面对的只有一个固定入口。

| 环节       | API提取（短效代理）  | 隧道代理             |
| ---------- | -------------------- | -------------------- |
| 获取IP     | 客户端调API拉列表    | 不需要，入口地址固定 |
| 可用性检测 | 客户端自建测活逻辑   | 云端网关完成         |
| 轮换调度   | 客户端自己写         | 网关按请求自动换     |
| 失效处理   | 客户端剔除、重拉     | 异常IP自动切换       |
| 代码改动量 | 需要独立的池管理模块 | 改一段proxies配置    |

两种模式并不存在替代关系。手里有研发资源、想精细控制换IP节奏的团队，短效的可控性更强；

希望免维护、让程序专注业务的团队，隧道的综合成本更低。从我们平时接触的用户看，这两类团队的画像也确实不太重叠。

## 每次请求换IP，在转发层是怎么发生的？

**换IP的动作发生在网关选出口那一步，客户端全程无感。** 先看链路：

```
采集程序 → 隧道入口（固定域名:端口） → 调度网关 → 出口IP池 → 目标网站
```

程序和入口建立代理连接之后，网关每收到一次请求，就从出口池里按策略选一个IP把流量发出去。请求和请求之间，出口互相独立，"每次请求换IP"指的就是这个粒度。

接入前用户问得最多的两个问题，正好都出在这一层。

一个是"HTTPS会不会被解密"。不会。TLS握手在客户端和目标网站之间完成，网关只做TCP层透传，既看不到、也不需要看请求内容。

另一个是"要不要禁用keep-alive"。不用。即便客户端复用了到入口的那条TCP连接，出口的分配依然按请求进行，代码里不需要做任何特殊处理。

倒是有个相反方向的需求值得提一句：登录态、连续翻页这类场景，要的不是每次都换，而是一段时间内不换。这就是"按时间粘性"模式，同一会话在若干秒到几分钟内保持同一出口。有这类需求的话，接入前确认服务商是否提供这个选项。

## 代码里怎么接入？

**基本就是一段proxies配置的事，主流语言都原生支持。** requests的写法：

```python
import requests

tunnel = "隧道入口域名:端口"
auth = "用户名:密码"

proxies = {
    "http":  f"http://{auth}@{tunnel}",
    "https": f"http://{auth}@{tunnel}",
}

resp = requests.get(
    "https://目标网站/页面",
    proxies=proxies,
    timeout=(5, 10),   # 连接超时和读取超时分开设，排障时好定位
)
print(resp.status_code)
```

Scrapy更简单，全局配置不用动，Request上带个meta即可：

```python
yield scrapy.Request(
    url,
    meta={"proxy": "http://用户名:密码@隧道入口域名:端口"},
)
```

重试策略上，隧道有个天然的便利：连接超时、读超时、5xx这类网络型失败，直接重试就行——下一次请求走的是新出口，重试本身就等于换了IP。但403和验证码页不建议直接重试，那说明请求特征已经暴露，该做的是补请求头、降低频率，继续重试只会白白消耗出口。requests侧的重试封装：

```python
from requests.adapters import HTTPAdapter, Retry

s = requests.Session()
s.mount("https://", HTTPAdapter(max_retries=Retry(
    total=3, backoff_factor=0.5,
    status_forcelist=[500, 502, 503, 504],
)))
```

## 并发和QPS怎么设才合理？

**上限看两头：套餐给的并发额度，和目标网站的容忍度——十有八九是后者先到顶。** 不少用户拿到账号就把并发打满，结果正式运行的成功率反而不如测试阶段。思路其实应该反过来：从5-10这样的低并发起步，盯着成功率曲线逐步往上加，曲线开始抖动就停。

另外两条经验：并发按目标域名分桶，避免单个域名吃掉全部在途请求；监控里给响应时间的标准差单独留一条曲线，它变大往往比成功率下跌来得早，是很实用的前置预警。

## 请求失败了，怎么判断是代理问题还是目标站问题？

**看失败的形态，多数问题十分钟内能定位。** 这是我们技术支持处理得最多的几类，可以对照着查：

| 现象                  | 大概率原因                 | 处理方式                           |
| --------------------- | -------------------------- | ---------------------------------- |
| 连接超时、完全无响应  | 入口地址、端口或白名单配置 | 核对配置，先用curl通一遍           |
| 返回407               | 代理认证失败               | 检查用户名密码或IP白名单设置       |
| 403、验证码页集中出现 | 请求特征被目标站识别       | 补请求头、降低频率、检查浏览器指纹 |
| 成功率缓慢下滑        | 目标站策略升级             | 换出口对比测试，调整请求节奏       |
| 特定地区目标访问偏慢  | 出口到目标的路由质量       | 试省市定向出口                     |

连通性验证用curl，一行命令就够：

```bash
curl -x http://用户名:密码@隧道入口域名:端口 https://httpbin.org/ip
# 连跑几次，返回的origin在变，说明换IP机制正常
```

顺带提醒：httpbin只能验证"通不通"和"换没换"，IP质量还是要拿真实目标跑，把成功率、响应时间、返回内容质量分开记录，数据才有参考价值。

## 什么场景适合隧道，什么场景该用短效？

**看两点：会话形态，以及愿意在运维上投入多少。**

高频、无会话的抓取，加上免维护的诉求，选隧道基本不会错；要精细控制换IP批次、自己有调度体系的，短效更合适。

落到具体业务上：舆情监测7×24、招投标定时任务这类长期任务，隧道加异常IP自动切换的组合最省心；活动期突增、平时低量的弹性用量，短效按天更划算。

极安代理的两条产品线正好对应这两种模式：隧道代理每次请求换IP，月付299元起，云端自带异常IP自动切换，官网公示可用率99.9%；短效代理1000IP低至3.6元/天起，按天弹性计费。常见的搭配是前期用短效按天摸清用量，稳定后切隧道包月。拿不准的话，可以先申请免费测试，拿真实目标跑一轮数据再定方案。

## FAQ

**Q：隧道代理会解密我的HTTPS流量吗？**

不会。TLS握手在客户端和目标站之间完成，网关只做TCP层透传。在意数据合规的，选服务商时可以关注增值电信业务经营许可证、ISO 27001这类资质，官网有公示的更放心。

**Q：用了隧道代理，还需要自己设置请求头吗？**

需要。换IP只解决"来源地址"这一个维度，User-Agent、Accept-Language、Referer这些请求特征仍然要自己补全。IP再干净，请求头不完整，同样会被识别。

**Q：隧道代理支持指定城市出口吗？**

部分产品支持省市定向。广告监测这类按城市采集的需求，接入前先核对城市覆盖清单，再用免费测试验证指定地区的实际表现，两步都不建议省。

**Q：并发额度和QPS是一回事吗？**

不是。并发是同一时刻在途的请求数，QPS是每秒发起的请求数。请求耗时越短，同样的并发能跑出越高的QPS。套餐限制的一般是并发，压测时两个指标都要看。