隧道代理到底怎么换 IP？我把一次请求拆给你看

做跨境数据采集，隧道代理基本绕不开。尤其是那种请求量大、目标站点不止一个、又不想在业务代码里自己维护代理池的任务。

但很多人第一次接触隧道代理，理解会停在一句话：

“把请求发给一个代理地址，它就会自动换 IP。”

没错。

但这句话太粗了。

真正的问题是：这个请求到底经过了哪些步骤？代理 IP 是什么时候选的？是每次请求都换，还是连上之后一直不变？请求失败了，谁来决定换节点？

今天不讲宣传页那套。我把一次请求从头到尾拆给你看。

一次请求，先经过哪个入口？

假设我们要请求一个海外站点。

业务代码里通常不会直接写某个具体出口 IP，而是把请求发到隧道代理提供的固定入口：

 业务程序
    ↓
 隧道代理入口
    ↓
 代理网关
    ↓
 出口节点
    ↓
 目标站点

对业务程序来说，它只需要知道三样东西：

• 代理地址
• 端口
• 鉴权信息

至于后面到底从哪个国家、哪个城市、哪个 IP 出口，业务程序一般不用自己处理。

这就是隧道代理和“手动提取一批 IP 再自己轮换”的区别。

前者把代理池管理放在服务端。

后者要自己维护。

维护过的人都知道，后者看起来灵活，实际上很快就会开始掉头发。

第一步：网关先确认你是谁

请求到达代理入口后，第一步不是马上找出口 IP，而是做鉴权。

最常见的是两类：

• 用户名和密码
• IP 白名单

鉴权通过之后，网关才会继续处理请求。

如果鉴权失败，请求根本不会进入后面的节点选择阶段。很多人看到请求失败，第一反应是“这个 IP 不行”，其实可能连 IP 都还没选上。

很尴尬。

所以排查隧道代理时，别一上来就换套餐。先看最基础的几件事：

• 用户名和密码有没有写错
• 白名单出口 IP 有没有变化
• 端口是不是对应产品
• HTTP 代理和 SOCKS5 代理有没有配反
• 请求是不是从允许的网络环境发出

尤其是海外代理。

配置没问题，但网络环境不符合要求，请求照样会失败。

第二步：网关判断这次请求该去哪儿

鉴权通过后，网关要做的事情是“选路”。

它通常会结合这些信息：

• 目标域名
• 目标国家或地区
• 资源类型
• 当前节点是否可用
• 节点负载
• IP 是否近期出现过异常
• 当前套餐支持的并发和带宽
• 是否要求保持会话

这里有个误区。

很多人以为隧道代理就是从 IP 池里随机抽一个。

实际上，随机只是最简单的一种方式。

真正可用的调度，至少要先满足基本条件。比如你请求的是英国站点，系统不能随便给你一个巴西出口；你要住宅 IP，系统也不能直接拿数据中心 IP 顶上来。

否则“换了 IP”不等于“请求能用”。

你跟站点说自己来自英国，结果出口 IP 的 ASN、时区和 DNS 都像另一个国家，这种请求能不出问题？

第三步：系统给这次请求分配出口 IP

节点选好之后，网关会把请求转发到某个出口节点。

这时候，一次请求大概是这样走的：

 1. 业务程序发起请求
 2. 请求到达隧道代理入口
 3. 网关校验鉴权信息
 4. 网关识别目标域名和地区要求
 5. 从可用资源池中选择出口节点
 6. 节点向目标站点发起连接
 7. 目标站点返回响应
 8. 响应沿原路径返回业务程序

注意，业务程序看到的不是“代理池里有多少个 IP”，而是一个固定的代理入口。

真正变化的是入口后面的出口。

这也是“隧道”这个词的由来。你把请求交给入口，后面那段路由、转发和节点切换由服务端完成。

那 IP 到底什么时候换？

重点来了。

隧道代理换 IP，通常有三种触发方式。

1. 每次请求换 IP

这是最容易理解的一种。

请求 A 使用出口 IP 1。

请求 B 到来时，网关重新选择出口 IP 2。

 请求 A → IP 1 → 目标站点
 请求 B → IP 2 → 目标站点
 请求 C → IP 3 → 目标站点

这类模式适合请求之间不需要保持同一个出口的任务，比如：

• 大量公开页面采集
• 舆情监测
• 广告监测
• 高频短请求
• 对单个 IP 依赖较低的任务

青果网络的隧道代理就把“每次请求换 IP”作为常见产品模式。具体能不能每次切换、切换频率是多少，还是要看产品配置和目标站点测试结果，不能看到“自动换 IP”四个字就默认所有请求都会立刻换。

2. 按时间或会话保持

有些业务不能每次请求都换 IP。

比如：

• 登录后连续访问多个页面
• 分页读取同一个账号的数据
• 需要维持购物车状态
• 目标站点会校验会话来源

这时如果请求 1 用 IP 1，请求 2 突然跳到 IP 2，目标站点可能直接把会话判定为异常。

所以有些隧道代理会提供会话保持能力。只要你带上固定的会话标识，系统就在一段时间内尽量让请求从同一个出口出去。

这里的“固定”也不是永久固定。

可能是固定几分钟、几十分钟，或者直到节点失效。

具体时长必须看产品规则。

别把“会话保持”理解成“永远不换 IP”。那是两码事。

3. 节点异常时切换

还有一种情况，不是时间到了，也不是请求结束了，而是当前节点出问题了。

比如：

• 节点连接超时
• 目标站点连续返回错误
• IP 被目标站点限制
• 出口网络突然中断
• 节点负载超过阈值

这时网关可能会把请求重新转发到其他节点。

注意，是“可能”。

有的产品会自动重试，有的产品只负责返回失败；有的会在同一个请求内重试，有的要等下一次请求再换。

这也是为什么同样叫隧道代理，实际体验差别会很大。

你只看“IP 数量”没用。真正要看的是异常时怎么处理。

一次请求失败后，系统会不会自动换 IP？

这个问题经常被问。

答案是：不一定。

因为“请求失败”有很多种。

网络层失败

比如连接超时、DNS 失败、TCP 建连失败。

这种情况下，代理服务更容易判断是节点或网络问题，有些产品会自动换节点重试。

代理鉴权失败

用户名、密码、白名单不对。

这种失败换一百个 IP 也没用。先修配置。

目标站点返回 403

这可能是 IP 风控，也可能是请求频率、Cookie、TLS 指纹、浏览器行为出了问题。

如果只是换 IP，未必能解决。

返回验证码或挑战页

这更不能简单归因于代理 IP。

目标站点可能同时在看：

• IP 信誉
• 请求频率
• Cookie
• User-Agent
• TLS 指纹
• JavaScript 执行情况
• 访问路径
• 账号行为

代理只是其中一个变量。

所以我一直不太喜欢“自动换 IP 就能解决反爬”这句话。太满了。

能不能解决，要看具体站点。

真的。

长连接会影响换 IP 吗？

会。

这是很多人第一次调隧道代理时最容易忽略的地方。

如果业务使用 HTTP Keep-Alive，或者底层复用了同一条 TCP 连接，那么后续请求可能继续走原来的出口连接。

你以为自己发了三个请求，实际上代理服务看到的可能是同一条长连接里的三个请求。

这时候，“每次请求换 IP”不一定等于“每个业务请求都换 IP”。

同样，HTTP CONNECT、HTTPS 隧道和 SOCKS5 的行为也不完全一样。不同协议下，连接建立和复用方式不同，产品侧的切换规则也可能不同。

我之前调一个采集任务时，就因为默认打开连接复用，盯着日志看了半天，发现 IP 怎么都不变。

最后一看，是连接没断。

我当时的反应是：

“啊？”

配置没错，节点没错，代理也没挂。

是我自己把连接复用了。

服了。

业务代码应该怎么配？

如果任务是“每个请求尽量独立”，可以重点检查：

• 是否启用了连接复用
• 是否需要每次请求重新建立代理连接
• 是否有固定会话参数
• 请求失败后是否由客户端重试
• 重试时是否真的更换了出口
• 是否记录了每次请求对应的出口 IP

如果任务需要“同一会话保持”，就不要盲目追求每次换 IP。

更稳妥的做法是先把业务分成两类：

适合频繁切换

• 独立页面请求
• 公开信息抓取
• 舆情关键词监测
• 广告素材检查
• 不依赖登录态的任务

适合会话保持

• 登录后分页
• 账号相关操作
• 购物车和订单流程
• 需要连续 Cookie 的页面
• 目标站点对 IP 变化敏感的任务

你看，隧道代理不是“换得越勤越好”。

换太勤，会把正常会话换没。

不换，又可能让单个出口承受太多请求。

这才是选型时真正要看的地方。

我们组一般怎么验证？

我做跨境采集时，不会只跑一个“能不能访问”的测试。

最少会拆成四组：

1. 单请求测试：看入口是否能正常转发。
2. 连续请求测试：看 IP 是否按预期切换。
3. 会话测试：看 Cookie 和登录态能不能保持。
4. 异常测试：人为提高请求频率，观察失败后怎么处理。

测试日志里至少记录这些字段：

 request_id
 target_url
 response_status
 proxy_session
 exit_ip
 exit_country
 connect_time
 total_time
 retry_count

没有这些字段，最后很容易变成一句：

“感觉这家代理不太稳定。”

感觉不算结论。

我有时候也想这么写，但老板不会给我报销。

隧道代理最适合什么场景？

如果你的业务有下面几个特点，隧道代理通常比较省事：

• 请求量比较大
• 需要频繁更换出口
• 不想自己维护 IP 池
• 业务代码希望保持一个固定代理入口
• 需要按地区、协议或资源类型筛选节点
• 能接受服务端替你做部分调度

青果网络的隧道代理基础参数里，5 个请求数对应 5Mbps 带宽和每秒 5 次请求；增加请求数后，带宽与最大请求频率同步增加，具体以官网当前配置为准（来源：官网）。

这个参数的好处是比较直观：业务并发上来之后，不需要重新设计一套代理接入方式，而是按实际请求量调整请求数。

最后，别把隧道代理想成一个“换 IP 开关”

隧道代理真正做的，不是简单地从 IP 池里随机拿一个地址。

它至少要处理几件事：

1. 接收业务请求。
2. 校验鉴权信息。
3. 判断目标站点和地区要求。
4. 选择合适的出口节点。
5. 建立连接并完成转发。
6. 根据时间、会话或异常状态决定是否切换。
7. 把响应返回给业务程序。

所以你看，一次请求看着只有一行代码，后面其实有一整套调度过程。

这也是为什么我选隧道代理时，第一眼不会只看“IP 池有多大”。

我更关心：

• 节点怎么选
• IP 什么时候换
• 失败后怎么处理
• 会话能不能保持
• 日志能不能查
• 客服能不能及时说清楚问题

尤其是最后一个。

代理跑崩了，客服只回一句“请参考文档”，谁受得了？

隧道代理不是万能的。

但如果你的业务确实需要大规模请求、频繁切换出口，又不想把代理池维护也扛在自己身上，它确实能省掉不少麻烦。

前提是你得先搞清楚：自己到底需要“每次换 IP”，还是需要“同一会话保持 IP”。

这两个需求没分清，买什么产品都可能拉胯。

反正你们老板看的是采集结果。别只看入口地址，先把一次请求跑明白。