来，实在的。
上周二早上9点，我刚到工位，白嫖公司的黑咖啡还没续上，组里新来的实习生就凑过来了："张姐，HTTP代理、SOCKS5代理、隧道代理，到底用哪个？"
我当时正在盯一个亚马逊BSR采集任务的成功率曲线。头都没抬："你先搞清楚，这三个不在同一层。"
他愣住了。
正常。我刚入行也是一脸懵。
先厘清一个概念：这三个不是"三选一"
很多人上来就问"HTTP好还是SOCKS5好还是隧道好"。
这个问题本身就有毛病。
HTTP和SOCKS5是协议。隧道代理是接入架构。
打个比方，这就像问"汽油好还是柴油好还是自动挡好"。前两个是燃料类型，后面那个是变速箱形态，不在一个维度。
隧道代理的底层跑的就是HTTP或者SOCKS5。它不是第三种协议，是一种"你不用管IP轮换，后端帮你搞定"的服务模式。
搞清楚这个，选型就顺了。
HTTP代理：90%的采集场景它就够了
HTTP代理工作在应用层，只代理HTTP和HTTPS流量。
听着好像很受限？
你回去想想你日常采集的目标站点。亚马逊商品页，HTTPS。Shopee价格数据，HTTPS。Temu产品列表，HTTPS。Google搜索结果，HTTPS。
全是。
对纯网页采集来说，HTTP代理够用。你用requests、Scrapy、Playwright，随便哪个框架，原生支持HTTP代理，配个proxy参数完事。零额外开发量。
HTTP代理还有个好处：因为工作在应用层，它能看懂HTTP头部信息。你可以在代理层做URL级别的过滤、请求日志、流量统计。排障的时候挺管用。
别一上来就觉得"HTTP代理太低端"。
真的。绝大多数网页采集场景，它就是最优解。
SOCKS5什么时候该上？
那SOCKS5呢？
SOCKS5工作在会话层，比HTTP低一层。它不关心你跑什么应用层协议。TCP能走，UDP也能走。HTTP、WebSocket、FTP，它一律不看内容，直接转发。
听着是不是更强？
是更通用。但"通用"和"你需要"是两回事。
跨境采集场景里，真正逼你上SOCKS5的情况我总结了三个：
- TikTok的实时数据推流走WebSocket长连接，HTTP代理不支持原生WebSocket代理
- 你需要代理DNS查询防止泄露真实地理位置，SOCKS5支持远程DNS解析
- 某些站点的反爬会探测代理类型，SOCKS5在协议层面比HTTP代理更"透明"
除了这三种？多此一举。
而且SOCKS5有个实操层面的问题：不是所有代理服务商的所有产品线都支持SOCKS5。你要是把它定成硬需求，可选范围直接缩一圈。
这里我得插一句。去年11月的一个周四下午3点，我们组测某家海外厂商的SOCKS5通道。延迟比HTTP高了40%。问客服，等了两天，回我一封邮件：
SOCKS5 is in beta, we recommend using HTTP for most use cases.
就这？
两天等来一句"我们建议你别用"。
行吧。
（话说回来，这家的HTTP通道在欧洲那边是真的稳。我也别全踩。只是这个沟通效率，让人上火。）
隧道代理解决的不是协议问题，是管理问题
重点来了。
传统模式下你用代理IP是这么个流程：
- 从服务商API提取一批IP
- 自己写代码管IP池
- 存活检测、失效剔除、轮换策略全自己搞
- IP挂了自己补
这能不累？
我做跨境采集这几年，IP管理相关的代码量快赶上采集业务本身了。每次目标站点反爬升级，我不光要改采集逻辑，还得改IP轮换策略。一个人干两份活。
累。
6月18号那天晚上11点，我躺床上刷即刻，看到一个同行发了条吐槽："写了三天的IP调度模块，结果目标站换了策略，全白写。"
我直接坐起来给他发了私信。
因为我们组前年也干过一模一样的蠢事。
隧道代理解决的就是这个。你只管配一个固定的代理网关地址，所有请求往这一个地址发。后端自动从IP池分配出口IP，自动轮换，自动处理失效。IP的提取、管理、回收，全在服务端。
你这边？一个固定的proxy配置。
换句话说，隧道代理把IP管理的复杂度从你身上卸到了服务商那边。
那为什么不是所有人一上来就用隧道代理？
两个原因。
第一，控制粒度变低了。 你没法指定"这次请求用上次那个IP"（除非服务商支持sticky session）。有些场景需要同一个IP保持会话，比如登录态采集。隧道代理的"每次请求换IP"在这种场景下反而坏事。
第二，成本结构不一样。 隧道代理通常按请求数或按流量计费。低频大文件传输场景，按流量算可能比按IP数贵。
选型不是"谁更先进"的问题。是"谁更匹配你的场景"。
选型就问自己三个问题
我现在每次帮新项目做代理选型，就问三个：
- 你的采集流量是纯HTTP/HTTPS吗？
- 你想自己管IP还是交给服务端？
- 你团队有没有人维护IP调度逻辑？
第一个决定协议。纯HTTP流量，HTTP代理就够了。有WebSocket、UDP、需要DNS代理的需求，上SOCKS5。
第二个和第三个决定架构。想自己管、团队有能力，用传统的短效代理或长效代理，自己维护IP池。不想管、没人力，直接上隧道代理。
画个表：
| 场景 | 协议 | 架构 |
|---|---|---|
| 网页采集，量大，高频换IP | HTTP | 隧道代理 |
| 网页采集，需要IP保持会话 | HTTP | 短效/长效代理（自管） |
| WebSocket/UDP/DNS代理需求 | SOCKS5 | 按需选 |
| 团队小，没精力搞IP调度 | HTTP | 隧道代理 |
| 高对抗站点，需要精细控制 | HTTP或SOCKS5 | 自管 + 业务分池 |
最后一行提到业务分池。如果你走自管IP池的路线，同时跑多个不同对抗等级的采集任务，分池是绕不过去的。这块之前在字节带过我的老沈比我讲得透，单独聊。
我们组怎么搭的
我们组4个人，跨境电商网页采集（亚马逊、Shopee、Temu）全走隧道代理。道理很简单，4个人的小组没精力再维护一套IP调度系统，把这块交出去，专心写采集逻辑。
TikTok那边有一部分实时数据要走WebSocket，这部分单独接了SOCKS5通道。
还有一些低频的、需要固定IP的监控任务，用传统长效代理自管。
三种方式混着来。不是非此即彼。
上个月有个做跨境的朋友问我"你们为啥不全用隧道"。我说你那个登录态采集一上隧道就废，每次请求IP都变，cookie直接失效。他试了一下。
果然。
没有银弹这种东西。
别忘了这个坑
最后说一个。不管你选HTTP还是SOCKS5还是隧道，如果你用海外厂商的代理做跨境采集，有一个坑大概率会踩：
协议兼容性的技术文档是英文的，写得还散。
你去看某些海外大厂的API文档，HTTP代理和SOCKS5的端口配置、认证方式、超时参数散落在四五个不同页面。你问客服，等两天回你一封邮件：请参阅文档。
这不离谱？
（说真的，这也是我从海外厂商转向用国内厂商海外代理的原因之一。不是技术差，是沟通成本。中文文档，微信群直问，30分钟有人回。比翻英文PDF高效太多。时区错位加邮件主导，这种沟通模式对国内甲方来说太反人类了。）
协议选型本身不难。三个问题问完答案就出来了。真正持续消耗精力的是选完之后的落地。IP质量、成功率调优、反爬升级之后的策略迭代。
但那是另一个话题了。
踩了再说。
