隧道代理到底跟直连HTTP代理有什么不一样？
隧道代理和直连HTTP代理最大的差别，是换IP的责任方不同。
直连HTTP代理里，业务侧从代理服务拿到一批IP列表，自己维护本地IP池，自己决定什么时候换。隧道代理里，业务侧只连一个固定入口（隧道端点），换IP由代理服务端在网关层自动完成——每次请求或每N秒就在网关背后换一个出口IP。
两种模式的差异对参数设置影响很直接：
| 维度 | 直连HTTP代理 | 隧道代理 |
|---|---|---|
| 业务侧连接目标 | 多个不同IP:端口 | 固定入口域名:端口 |
| 换IP触发方 | 业务侧本地代码 | 代理服务端网关 |
| 需要维护IP池 | 是 | 否 |
| IP切换频率参数配在哪 | 业务侧 | 代理服务端 |
| 鉴权方式 | 通常账密或白名单 | 通常账密+隧道通道号 |
| 适配的技术栈 | 单语言、有IP池管理经验 | 多语言、脚本类采集 |
理解这个差异之后，参数设置的逻辑就顺了：隧道代理的配置里，业务侧不用管换IP，只需要把入口配对。剩下的参数分成三类：鉴权类（进得来）、性能类（跑得动）、业务约束类（拿到对的数据）。
端口、账密、白名单，鉴权类参数怎么选？
鉴权是第一道门。三种常见方式：账密鉴权、白名单鉴权、账密+白名单双验。
账密鉴权。用户名+密码放在请求里，最常见的方式。适合业务出口IP不固定的场景，比如从多台服务器、容器化环境、云函数发起请求。账号密码通常通过HTTP Basic Auth传递，写法是：
http://username:password@tunnel.example.com:8000用户名里通常还会带上通道参数或会话参数，比如：
http://user-region-us:password@tunnel.example.com:8000具体的用户名格式看代理服务商的文档。
白名单鉴权。业务出口IP提前在代理服务后台加白，请求时不需要账密。适合业务出口IP固定的场景，比如自建机房、固定公网IP的服务器。白名单的好处是账号密码不用在代码里明文出现；坏处是IP变了要手动去后台改。
双验。账密+白名单同时启用。适合企业级采集里对访问安全有明确要求的场景。上线前需要确认代理服务商是否支持双验模式。
端口。隧道代理的端口通常按协议分：8000/8080/8888 常用于HTTP/HTTPS，1080 常用于SOCKS5。不同代理服务商的端口分配不同，用之前要看文档。
鉴权类参数的取值建议：
| 参数 | 常见取值 | 什么时候用 |
|---|---|---|
| 鉴权模式 | 账密 | 出口IP不固定、多机部署 |
| 鉴权模式 | 白名单 | 出口IP固定、单机或少数机器 |
| 鉴权模式 | 双验 | 企业级采集、有安全审计要求 |
| 端口 | HTTP/HTTPS端口 | HTTP/HTTPS采集，占绝大多数场景 |
| 端口 | SOCKS5端口 | 需要TCP/UDP转发、非HTTP协议采集 |
IP切换频率、并发数、超时，性能类参数怎么设？
性能类参数决定了隧道代理跑不跑得动业务量。
IP切换频率。隧道代理里IP切换由服务端控制，但业务侧通常能通过两种方式影响：
- 通过用户名参数指定会话号（Session ID），同一Session ID内保持同一出口IP
- 通过HTTP Header里的会话标识指定切换粒度
常见的切换频率设定：
| 场景 | 切换频率 | 会话粘性 |
|---|---|---|
| 拓客数据采集（列表页翻页） | 每5-10次请求换IP | 需要（保证列表连贯） |
| 广告监测（不同广告位独立） | 每次请求换IP | 不需要 |
| 需要登录态的采集 | 会话结束才换IP | 强粘性 |
并发数。并发数是同一隧道端点同时保持的连接数。隧道代理的并发上限通常由代理服务商的套餐决定，常见档位是10、50、100、500、1000并发。业务侧的实际并发不应该跑满上限——留20%-30%的余量给瞬时抖动。
判断并发数够不够的经验公式：
所需并发 = 目标QPS × 单请求平均响应时间（秒）举例：目标50 QPS、单请求平均响应时间2秒，所需并发大约是100。
超时。三层超时要分开设：
| 超时类型 | 常见取值 | 作用 |
|---|---|---|
| 连接超时（Connect Timeout） | 3-5秒 | 到隧道端点的连接建立时间 |
| 隧道切换等待（Session Switch Wait） | 200-500毫秒 | 隧道服务端换IP的处理时间 |
| 读取超时（Read Timeout） | 15-30秒 | 目标站点的响应时间 |
连接超时超过5秒还没建连接，一般是隧道服务端有问题或本地网络异常。读取超时是最经常需要调的——目标站点响应慢，读取超时设短了，会把大量本可以成功的请求算成失败。
协议、地域、目标URL白名单，业务约束类参数怎么设？
业务约束类参数决定了拿到的数据是不是业务想要的。
协议选择。三种主流协议的适配场景：
- HTTP：绝大多数网页采集。简单、兼容性最好。
- HTTPS：所有HTTPS站点采集。现在几乎所有主流站点都要求HTTPS。
- SOCKS5：需要TCP/UDP层转发的场景，比如某些非HTTP协议的采集、需要保持长连接的采集。
一般的建议是三协议都支持的隧道优先，避免后期业务扩展时改协议。有些代理服务只支持HTTP/HTTPS不支持SOCKS5，选型时要看清。
地域选择。地域参数决定出口IP的归属地。国内业务里，地域参数常见的粒度有：
- 全国随机（默认）
- 按省份指定（如浙江/广东/北京）
- 按城市指定（如杭州/深圳）
- 按运营商指定（电信/联通/移动）
拓客数据采集里，如果目标是本地生活服务类站点（比如本地商户信息），按城市指定出口IP能显著提升采集成功率——因为这类站点会做地域访问频率控制。
广告监测里，如果要拿到本地化的广告投放数据，按省份或城市指定出口IP是必需的。
目标URL白名单。有些代理服务商允许在隧道端配置目标URL白名单——只有请求特定域名时隧道才转发，其他域名请求会被拒绝。这个参数不是必须，但在企业级采集里能作为安全兜底，防止业务侧代码bug导致代理被错误用途消耗。
业务约束类参数的常见取值：
| 参数 | 取值 | 什么时候必设 |
|---|---|---|
| 协议 | HTTP/HTTPS | 默认，绝大多数场景 |
| 协议 | HTTPS-only | 敏感采集，避免明文传输 |
| 协议 | SOCKS5 | 非HTTP协议或长连接采集 |
| 地域 | 全国随机 | 目标站点无地域访问频率控制 |
| 地域 | 按城市指定 | 目标站点做了地域访问频率控制 |
| 地域 | 按运营商指定 | 目标站点对特定运营商有识别 |
| URL白名单 | 关闭 | 采集目标不固定 |
| URL白名单 | 开启 | 采集目标域名清单固定 |
配置完先跑什么测试？
参数配好之后，别急着上业务，先跑四轮测试验证配置对不对。
第一轮，连通性测试。用最简单的HTTP请求验证隧道通不通：
curl -x http://username:password@tunnel.example.com:8000 http://httpbin.org/ip返回的IP应该是隧道出口IP，不是本机IP。返回失败要先查鉴权、端口、协议是否配对。
第二轮，IP切换测试。连续发10次请求，观察返回的出口IP：
- 每次请求换IP → 说明切换频率是默认「每次换」
- 若干次请求内是同一IP → 说明有会话粘性
- 全部相同IP → 检查是否误配了会话粘性、是否代理服务端异常
第二轮测试要在业务真实需要的切换频率下跑，验证配置和期望一致。
第三轮，并发压测。用简单的并发工具（比如 wrk、ab、或自制脚本），按目标并发的80%压5分钟，观察：
- 平均响应时间
- 失败率
- 隧道端点是否有连接被拒绝的情况
失败率高于5% → 减并发、加超时、检查目标站点是否被压垮。
第四轮，业务级验证。用一小批真实业务请求跑10-30分钟，观察：
- 拿到的数据字段是否完整
- 是否触发验证码
- 目标站点是否有异常状态码
前三轮跑的是隧道本身，第四轮跑的是隧道+业务+目标站点的联合链路。四轮都过，才能上生产流量。
一个能直接用的上线前检查清单：
| 序号 | 检查项 | 通过标准 |
|---|---|---|
| 1 | 鉴权模式与业务出口IP是否匹配 | 出口IP不固定→账密；固定→白名单 |
| 2 | 端口与协议是否对齐 | HTTP/HTTPS用8000/8080类端口，SOCKS5用1080类 |
| 3 | 切换频率是否符合业务节奏 | 按业务QPS和会话粘性需要选 |
| 4 | 并发数是否留了余量 | 实际并发 ≤ 套餐上限×80% |
| 5 | 三层超时是否分开设置 | 连接3-5秒、切换等待200-500毫秒、读取15-30秒 |
| 6 | 地域参数是否符合业务需要 | 有地域访问频率控制的目标→指定城市/省份 |
| 7 | 连通性测试是否通过 | curl返回隧道出口IP |
| 8 | 并发压测失败率是否低于5% | 高于5%需要调整 |
清单过完，隧道代理的初始配置就基本稳了。业务跑起来之后，还需要按失败率的实时曲线做微调，那属于运行时优化的范畴，不在初始配置阶段。
FAQ
Q：隧道代理和普通HTTP代理，实现同一个采集任务，哪个更省成本？
看业务规模和工程能力。小规模、单机、脚本类采集，隧道代理省的是工程时间——不用写IP池管理代码，直接连隧道就行。中大规模、多机、需要精细IP复用控制的采集，直连HTTP代理灵活性更高，但需要投入工程资源去写IP池。多数团队在起步阶段用隧道代理，业务量起来之后按需切换到直连模式。
Q：隧道代理的会话粘性怎么保证不出错？
会话粘性通常通过用户名里的Session ID参数控制。同一个Session ID内的请求，隧道服务端会尽量分配同一个出口IP。要注意两点：一是Session ID的生命周期通常有上限（比如10分钟或1小时），超过会自动换IP；二是同一Session ID的请求要在时间上连续，间隔太久会话会被服务端回收。业务上线前要看清代理服务的Session规则。
Q：并发数不够用了，直接开高会不会伤业务？
会。超过套餐并发上限的请求，通常会被隧道服务端直接拒绝，业务侧看到的是连接建立失败或握手失败。这种失败无法通过重试解决，只能减并发或升级套餐。合理做法是在业务侧加并发控制（比如信号量），让本地实际并发始终低于套餐上限的80%。
Q：隧道代理的读取超时为什么要设15-30秒，不是更短？
因为超时的钟点是从隧道端点到目标站点，链路更长。直连HTTP代理里，读取超时可以设短一点（5-10秒），因为链路是本机到目标站点。隧道代理多一跳，加上有些目标站点响应慢，超时设短了会把很多本可以成功的请求算成失败。跨境采集里读取超时甚至需要设到45秒以上。
