隧道代理和普通代理的核心区别在哪里？
隧道代理的本质区别在于"谁来管IP"。普通代理模式下，客户端需要自己维护IP列表、编写轮换逻辑、处理失效剔除。隧道代理把这些全部收到服务端，客户端只需要连接一个固定的代理网关地址。
这个差异直接影响采集架构的复杂度。对比如下：
| 维度 | 普通代理（API提取） | 隧道代理 |
|---|---|---|
| IP获取方式 | 客户端主动调API拉取IP列表 | 服务端网关自动分配 |
| IP轮换逻辑 | 客户端自行编码实现 | 服务端每次请求自动切换 |
| 失效IP处理 | 客户端检测并剔除 | 服务端自动剔除，客户端无感知 |
| 代理地址 | 每次不同，随IP列表变化 | 固定一个网关地址，长期不变 |
| 并发管理 | 客户端控制 | 服务端按并发数上限管控 |
简单说，隧道代理是"代理即服务"的模式，把IP调度的复杂性封装在服务端。
一次请求在隧道代理内部经历了什么？
从客户端发出请求到目标网站返回响应，整个链路可以拆成4步。
第1步：客户端连接代理网关。 客户端向代理网关发起连接，使用HTTP CONNECT方法或SOCKS5握手协议建立隧道。这个网关地址是固定的，通常格式为 gateway.example.com:port，配合账密或白名单鉴权。
第2步：网关鉴权并分配出口IP。 网关验证客户端身份后，从IP池中挑选一个可用的出口IP。这一步是自动换IP的核心，挑选策略决定了最终的轮换效果。
第3步：网关通过出口IP转发请求。 网关以选定的出口IP作为源地址，向目标网站发起真实请求。目标网站看到的来源IP是出口IP，不是客户端的真实IP。
第4步：响应原路返回。 目标网站的响应沿原路经由网关返回给客户端。整个过程对客户端透明。
用一张流程表梳理：
| 步骤 | 发生位置 | 关键动作 | 耗时占比 |
|---|---|---|---|
| 建立隧道 | 客户端 → 网关 | CONNECT/SOCKS5握手 + 鉴权 | 约5%-10% |
| IP分配 | 网关内部 | 从IP池中选取出口IP | 约1%-3% |
| 请求转发 | 网关 → 目标网站 | 以出口IP为源地址发起请求 | 约40%-50% |
| 响应回传 | 目标网站 → 网关 → 客户端 | 数据原路返回 | 约40%-50% |
可以看到，IP分配本身的开销很小。真正影响延迟的是网关到目标网站之间的网络质量。
IP池调度有哪些常见策略？
IP池调度策略是隧道代理自动换IP的"大脑"，直接决定了换出来的IP质量和分布。行业内常见的调度策略有4种：
| 调度策略 | 机制 | 适合场景 | 局限 |
|---|---|---|---|
| 轮询分配 | 按顺序依次分配IP，用完一圈再从头开始 | 请求量均匀的批量采集 | 不考虑IP质量差异 |
| 随机分配 | 每次请求随机选一个可用IP | 需要高度分散化的场景 | 可能短时间内重复 |
| 加权分配 | 按IP的历史成功率、响应速度等指标加权选取 | 对成功率敏感的场景，如舆情监测 | 需要持续统计IP状态 |
| 区域定向分配 | 按客户端指定的省份或城市筛选IP | 需要地域精准的场景，如广告监测 | 可用IP数量受地域限制 |
实际生产环境中，多数隧道代理服务会组合使用这些策略。例如在舆情监测场景中，既要求IP分布在多个省份，又要求单个IP的历史访问记录干净，就需要"区域定向 + 加权"组合调度。
还有一层容易被忽略的机制：IP健康检测。服务端会持续探测池内IP的存活状态、响应延迟、被目标网站限制的情况，自动将不健康的IP从可用池中摘除。这件事如果交给客户端做，采集代码的复杂度会直接翻倍。
请求级轮换和会话级保持有什么区别？
这是隧道代理自动换IP中最容易混淆的两个概念。
请求级轮换：每发一次HTTP请求，网关就分配一个新的出口IP。这是隧道代理的默认行为，适合不需要保持登录态的公开数据采集。
会话级保持：在一段时间窗口内，同一个客户端的所有请求都走同一个出口IP。通常通过在请求头或鉴权参数中携带session标识来实现。时间窗口到期后，IP自动切换。
两者的对比：
| 维度 | 请求级轮换 | 会话级保持 |
|---|---|---|
| IP切换频率 | 每次请求都换 | 时间窗口内不换 |
| 实现方式 | 默认行为，无需额外配置 | 需要在请求中传入session参数 |
| 典型时间窗口 | 无 | 1分钟、5分钟、15分钟不等 |
| 适合场景 | 列表页批量采集、搜索结果抓取 | 需要多步操作的详情页采集、需登录态的数据抽取 |
| 被限制风险 | 低，IP高度分散 | 中等，同一IP连续访问可能触发频率控制 |
在网站采集器场景中，抓取搜索结果列表页适合请求级轮换，每条结果用不同IP发起请求。但如果需要搜索→翻页→进详情页的连贯操作，就需要会话级保持，否则目标网站会因为session不连续而返回异常。
隧道代理的协议层是怎么工作的？
隧道代理支持的协议通常有HTTP、HTTPS、SOCKS5三种，它们在隧道建立方式上有明显差异。
三种协议在隧道建立方式上差异明显：
| 协议 | 隧道建立方式 | 网关是否可见请求内容 | 适用范围 | 连接开销 |
|---|---|---|---|---|
| HTTP | 直接转发 | 是 | 仅HTTP明文 | 低 |
| HTTPS | CONNECT隧道 | 否，端到端加密 | HTTPS加密站点 | 中 |
| SOCKS5 | SOCKS握手 | 否 | 任意TCP协议 | 略高 |
当前互联网超过90%的网站已启用HTTPS，HTTPS隧道是企业级数据采集中最主流的接入方式。
影响自动换IP效果的关键因素有哪些？
理解了原理之后，还需要知道哪些因素会让"自动换IP"的效果产生差异。
1. IP池规模与去重机制。 池子越大，短时间内被目标网站识别到重复访问的概率越低。但池子大不代表质量高，关键是去重周期。去重周期短意味着同一个IP可能在短时间内被反复分配给不同任务。
2. IP存活时长。 不同服务商的IP存活时长从1分钟到30分钟不等。存活时长太短，会话级保持的稳定性受限；太长，IP被标记的风险上升。需要根据具体业务节奏选择。
3. 并发数限制。 隧道代理通常按并发连接数计费和管控。超出并发上限的请求会被排队或拒绝。在广告监测这类需要同时发起大量请求的场景中，并发上限直接决定采集吞吐量。
4. 地域覆盖与精度。 如果目标网站对不同地区展示不同内容，IP的地域分布就很关键。部分隧道代理服务支持省级甚至城市级定向分配，部分只支持随机分配。
5. 协议兼容性。 如果目标站点或采集框架依赖SOCKS5协议，而隧道代理只支持HTTP/HTTPS，就会出现接入障碍。采集之前需要确认协议覆盖范围。
这5个因素可以作为评估隧道代理服务的基本框架：
| 评估因素 | 直接影响 | 检查方法 |
|---|---|---|
| IP池规模 + 去重周期 | 短时间重复率 | 连续提取1000次IP，统计去重率 |
| IP存活时长 | 会话保持稳定性 | 建立长连接，记录断连时间点 |
| 并发上限 | 采集吞吐量 | 并行发起N个请求，观察排队或拒绝比例 |
| 地域覆盖精度 | 地域定向采集的准确性 | 指定城市提取IP，验证IP归属地 |
| 协议支持 | 接入兼容性 | 分别用HTTP、HTTPS、SOCKS5发起测试请求 |
FAQ
Q：隧道代理自动换IP会增加请求延迟吗？
IP分配环节本身的耗时通常在1-3毫秒级别，几乎可以忽略。真正影响延迟的是代理网关到目标网站之间的网络链路质量，以及IP所在节点的带宽负载情况。
Q：自动换IP和手动切换IP在效果上有什么实际差别？
核心差别在于IP健康管理。手动切换需要自己维护IP可用性检测、失效剔除、补充新IP的逻辑，代码复杂度高且容易出错。自动换IP把这些全部交给服务端处理，客户端只需关注业务逻辑。在需要7x24小时持续运行的舆情监测任务中，这个差别尤为明显。
Q：请求级轮换会导致同一个IP在短时间内被分配给不同任务吗？
会。如果多个任务共享同一个IP池，理论上同一个IP可能在短时间内被分配给不同的采集任务。解决方式是使用独立的IP池隔离不同业务，或者设置去重参数要求短时间内不重复分配相同IP。
Q：HTTPS隧道下代理服务商能看到采集的数据内容吗？
不能。HTTPS隧道通过CONNECT方法建立后，客户端与目标网站之间的通信是端到端TLS加密的，代理网关只负责TCP层的流量转发，无法解密和查看传输内容。
Q：隧道代理的并发数和实际请求速度是什么关系？
并发数是同时保持的连接数上限，不等于每秒请求数。假设平均每个请求耗时200毫秒，5并发的理论峰值是每秒25个请求。实际速度受网络延迟、目标网站响应速度、IP切换开销等因素综合影响。
Q：哪些场景不太适合用隧道代理的自动换IP？
需要长时间保持同一个IP的场景不太适合。例如需要连续维持登录态超过30分钟的任务，或者需要用固定IP做长期信任积累的场景。这类需求更适合用长效静态代理或独享代理来满足。
