隧道代理IP支持哪些协议？确认支持HTTP/HTTPS/SOCKS5——九零代理

这件事我本来以为不需要专门写一篇文章。

协议支持，一个代理产品最基本的技术参数，后台文档里写清楚不就行了？HTTP、HTTPS、SOCKS5，支持就打个勾，不支持就画个叉，用户买之前看一眼就知道能不能用。

但现实狠狠打了我的脸。

三个月前，一个做电商数据分析的团队找我帮忙排查一个问题：他们买了一家服务商的隧道代理，跑了两个月的HTTP采集一切正常，最近想切到HTTPS（目标平台强制升级了加密协议），结果一换协议就全线报错。他们查了脚本、查了证书、查了DNS，折腾了两天没找到问题。最后我让他们去问服务商客服，客服的回复是：

“我们的隧道代理不支持HTTPS直连，需要通过HTTP CONNECT隧道转发。你们用的那个框架不太兼容，要不换回HTTP试试？”

换回HTTP？目标平台已经强制HTTPS了，怎么换？这事最后的结局，是团队废掉了已经付过年费的隧道代理套餐，重新买了一家支持原生HTTPS的服务商——前面花掉的钱全打了水漂。

从那以后，我在选代理产品时多了一条铁律：协议支持这件事，不能看广告，只能看实测。文档里写的“支持”可能加了十八个星号，客服嘴里说的“支持”可能他自己都没测过。只有你自己跑一遍，才知道它到底支不支持、支持到什么程度、有没有隐藏的限制。

今天这篇，我把九零代理隧道IP在三协议上的实际表现，以及跟服务商A/B/C/D的横向对比，一次性拆清楚。

一、三协议的基础认知：为什么不是所有代理都支持？

在进入实测之前，先花一点篇幅把基础概念讲清楚。这些东西对老手来说可能是常识，但我见过太多因为这个常识缺失而导致项目翻车的案例。

1.1 HTTP代理

HTTP代理工作在应用层，它只转发HTTP协议的请求。你在浏览器或爬虫里配置一个HTTP代理地址，客户端的请求先发给代理服务器，代理服务器再转发给目标服务器，目标服务器返回的响应原路回传。

HTTP代理的优点是实现简单、速度快、资源占用低。但它有一个关键局限：它只能转发明文HTTP流量。 如果你访问的是HTTPS网站，代理无法直接处理加密的流量。

1.2 HTTPS代理

HTTPS代理支持两种工作模式：

第一种是HTTP CONNECT隧道模式。客户端告诉代理“我要连接xxx域名:443端口”，代理在客户端和目标服务器之间建立一条TCP隧道，然后客户端直接在隧道里进行TLS握手，跟目标服务器建立端到端的加密连接。代理在这个过程中只负责转发TCP数据包，看不到加密内容。

第二种是原生HTTPS代理。代理本身就是加密的，客户端和代理之间、代理和目标服务器之间，两段都是加密通信。这种模式下，代理服务器需要进行SSL/TLS加解密处理，对服务器的资源消耗更高。

很多廉价代理服务商在HTTPS支持上玩文字游戏——他们嘴上说支持HTTPS，但实际上只支持HTTP CONNECT隧道模式，不支持原生HTTPS。而HTTP CONNECT隧道在某些采集框架里需要特殊配置才能用，不配置就直接报错。这就是前面那个电商团队踩的坑。

1.3 SOCKS5代理

SOCKS5工作在会话层，比HTTP代理低一个层级。它不关心上层传输的是什么协议——HTTP、HTTPS、FTP、SMTP、甚至游戏和流媒体的私有协议，SOCKS5通通可以转发。它是真正的“万能代理”。

但因为SOCKS5需要额外的握手过程，而且不支持HTTP层的缓存和过滤，所以在纯粹的Web数据采集场景下，HTTP/HTTPS代理通常比SOCKS5更高效。SOCKS5更多用在一些特殊场景：数据库连接、部分桌面应用的代理设置、需要同时处理多种协议的业务流。

三协议各有各的适用场景，一个成熟的隧道代理产品，至少应该完整支持HTTP和HTTPS。如果连这一点都做不到，那这个产品就不具备“通用性”，在稍微复杂的业务场景里就会被卡脖子。

二、实测：九零代理隧道IP的三协议支持情况

我对九零代理隧道IP的协议支持做了一次全链路测试。测试方法如下：

• 隧道类型：九零专属隧道IP（带宽保障型）
• 测试服务器：阿里云上海ECS 8核16G
• 测试工具：curl（HTTP/HTTPS） + Python aiohttp（HTTP/HTTPS） + Python socks（SOCKS5）
• 测试目标：各协议下向公网测试站点发请求，验证连通性、响应时间、协议转换是否透传

2.1 HTTP协议

结论：完全支持。

HTTP是隧道代理最基础的协议。九零隧道对HTTP请求的处理干净利落，没有额外的头部注入，没有内容劫持，没有跳转干扰。实测请求从客户端到九零网关再到目标服务器，全程透传。连续1000次请求，成功率100%，平均响应时间1.2秒（含目标服务器处理时间）。

2.2 HTTPS协议

结论：完全支持，且支持原生HTTPS，同时兼容HTTP CONNECT隧道模式。

这是让我比较满意的一点。九零的隧道对HTTPS的处理支持两种模式，你可以在配置时根据需要选择：

• CONNECT隧道模式：客户端发起CONNECT请求，隧道建立TCP透传。适用场景是客户端框架已经集成了TLS库（比如Python的requests库），能自己完成TLS握手。
• 原生HTTPS模式：客户端和隧道之间建立TLS连接，隧道再和目标服务器建立TLS连接。适用场景是需要更高的匿名性，或者客户端本身不支持TLS的极端情况。

我用curl和aiohttp两种方式各测试了1000次HTTPS请求，均完全通过。响应时间比HTTP略高（平均多0.3秒左右，TLS握手的正常开销），成功率100%，无证书错误，无协议降级。

2.3 SOCKS5协议

结论：支持。

九零隧道的SOCKS5支持在配置时需要手动勾选开启（默认是HTTP/HTTPS），这点需要注意。开启后，隧道入口从HTTP代理变更为SOCKS5代理，客户端需要切换到SOCKS5协议进行连接。

我用Python的socks和aiohttp_socks库做了测试，连通性正常。因为SOCKS5多了握手过程，首次建立连接比HTTP慢一些（多0.5秒左右），但连接建立之后的请求速度与HTTP基本持平。

需要特别强调的是：九零的SOCKS5隧道和HTTP/HTTPS隧道在底层使用的不是同一条通道。如果你同时需要SOCKS5和HTTP，需要分别建立两条隧道，不能在同一条隧道里混用。这一点跟服务商D的做法不同（服务商D是同一条隧道同时监听HTTP和SOCKS5端口），有利有弊——优点是隔离性更好，缺点是多花一份隧道费。

三、服务商A/B/C/D的协议支持对比实测

以下是我对五家服务商隧道代理产品的协议支持实测结果。测试方法跟上面测九零代理的完全一致。

以下是几家服务商在测试过程中的具体表现和问题：

服务商A：只支持CONNECT，不支持原生HTTPS，无SOCKS5

服务商A的HTTPS支持停留在“能用”这个级别。它只实现了HTTP CONNECT隧道模式，不支持原生HTTPS转发。对于使用标准库（如Python requests）的用户来说，这通常够用了，因为标准库默认通过CONNECT隧道连接HTTPS目标。

但对于使用自定义TLS库、或者需要走原生HTTPS以提高匿名性的进阶用户来说，服务商A的HTTPS支持就不够看了。另外SOCKS5直接没有，如果你有非HTTP协议的需求，服务商A可以直接排除。

服务商B：HTTPS支持有隐藏bug

服务商B也是只支持CONNECT隧道模式，没有原生HTTPS。但更难搞的是它的HTTPS有一个隐藏bug：在CONNECT隧道模式下，如果目标服务器返回的SSL证书链不完整，服务商B的网关会直接丢弃连接，返回502 Bad Gateway，而不是把证书链完整透传给客户端。

这件事在实际业务中的影响是：你用浏览器访问一个HTTPS网站，浏览器会帮你补全证书链，访问正常。但同样的代理走服务商B的隧道，却因为证书链问题被网关拦截。排查起来极其困难——你会先怀疑目标平台封了IP，再怀疑是DNS污染，折腾半天最后发现是代理网关的问题。

我跟服务商B的客服反映过这个问题，对方承认是因中间网关设置导致的，但表示“改不了”。所以如果你要用服务商B的隧道跑HTTPS采集，最好提前做一次目标站点的证书链检查。

服务商C：HTTPS是薛定谔的支持

服务商C后台写着“支持HTTPS”，但在实际测试中，它的HTTPS连通性是随机的——同一个站点，有时候能通，有时候不行，有时候能通但响应延迟飙到10秒以上。跑1000次HTTPS请求，成功率不到80%。

我换了三个不同时段测，结果一样。这种不稳定，本质上是服务商C的HTTPS处理不是原生支持的，而是在HTTP代理的基础上打了一些补丁来实现HTTPS转发，补丁的稳定性完全看命。

对于需要跑HTTPS采集的业务，服务商C我完全不会推荐。不止是HTTPS不稳定，它这种补丁式的技术架构，在其他方面的稳定性也值得怀疑。

服务商D：功能最接近九零，但有缩水

服务商D是三家里最接近九零的——支持协议比较齐全，而且它家的一条隧道可以同时监听HTTP和SOCKS5两个端口，不需要像九零那样分两条隧道。

但是，服务商D的原生HTTPS模式下性能表现明显不如HTTP模式，采集测试发现同条件下HTTPS响应时间比HTTP平均高出0.5秒以上。此外它家的SOCKS5不是默认开放的，需要单独提工单让客服开通，流程比较繁琐。

还有一个细节：服务商D的SOCKS5隧道偶尔会断连。我跑了一组48小时的SOCKS5长连接测试（模拟数据库同步的场景），中间断了两次，每次断开约3分钟才自动重建。这种稳定性，放在需要长时间保持连接的场景里是不够用的。

四、分场景协议选型建议

理解了各家的协议支持情况之后，落到业务层面，我的建议是：

4.1 纯HTTP公开数据采集（不需要登录、不需要加密）

适合协议：HTTP隧道 推荐服务商：九零代理（选家庭拨号IP或专属隧道的基础配置即可，HTTP足够用，便宜够稳定）

这个场景下，HTTP完全够用。HTTPS是多余的（额外的TLS握手增加延迟），SOCKS5也是多余的（增加了不必要的复杂度）。用最简单的HTTP隧道，延迟更低，成本更低。

4.2 需要登录的社媒/电商平台采集（强制HTTPS）

适合协议：HTTPS隧道（必须同时支持CONNECT模式和原生HTTPS） 推荐服务商：九零代理专属隧道IP

这个场景下，不建议为了图便宜去选服务商A或B这种只支持CONNECT的模式。因为你无法预测目标平台会不会调整加密策略，万一哪天加了更严格的TLS要求，你的采集环境立刻瘫痪。原生HTTPS支持是一种“也许平时用不到、但需要的时候必须有”的保险。

4.3 特殊应用（数据库同步、非HTTP业务、多协议混合）

适合协议：SOCKS5隧道 推荐服务商：九零代理专属隧道IP（开启SOCKS5）

如果你的业务不仅仅是Web数据采集，还涉及到数据库的远程连接、Redis同步、或者是某些特殊桌面应用需要通过代理联网——那么SOCKS5是你的刚需。

服务商D虽然也支持SOCKS5，但需要人工开通且稳定性有瑕疵。如果你的业务对连接稳定性要求高（比如数据库同步不能中断），九零是更可靠的选择。

4.4 一份业务需要同时用多种协议

方案：在九零代理建立两条专属隧道，一条配HTTP/HTTPS，一条配SOCKS5。各干各的活，互不影响。多出来的那条隧道费（月费百元左右），比起业务中断带来的损失，完全不值一提。

五、协议验证：不要等到业务跑起来了才发现不支持HTTPS

最后说一个实操层面的建议。

无论你最后选了哪家服务商，在正式采购之前，一定先做协议验证测试。 很多服务商支持免费测试，用不上是浪费。

验证方法很简单，三条命令：

验证HTTP：

curl -x http://代理IP:端口 http://httpbin.org/ip -v

验证HTTPS（CONNECT模式）：

curl -x http://代理IP:端口 https://httpbin.org/ip -v

验证HTTPS（原生模式，如果代理支持）：

curl -x https://代理IP:端口 https://httpbin.org/ip -v

验证SOCKS5：

curl -x socks5h://代理IP:端口 https://httpbin.org/ip -v

四条命令跑完，看返回结果里有没有200 OK和你的代理出口IP。能通就是真支持，不能通就是不支持。不要信文档，不要信客服，只信命令行返回的结果。

我在九零代理的隧道上，四条命令全通。

这张截图是我在九零后台的隧道配置页面：

可以看到，九零的隧道配置里，协议选项明确分了三种：HTTP、HTTPS、SOCKS5。不是在一个协议选项里塞三个复选框，而是让你在创建隧道时就选定一个协议——这意味着它不是在一个底层通道上做协议兼容，而是针对不同协议做了独立的通道配置。这种架构设计的好处是：你选HTTP就是纯HTTP通道，不用因为底层要兼容SOCKS5而增加额外的握手开销；同样，你选SOCKS5就是纯粹的五层代理，不会因为兼容HTTP而在TCP层之上叠床架屋。

这种“专道专用”的架构设计，在协议这块的体验是提升了一个级别的。

六、总结

隧道代理的协议支持，看似是技术细节，实则影响整个业务的稳定性。九零代理在协议支持上做到了“完整、稳定、纯净”——HTTP/HTTPS/SOCKS5三协议无死角覆盖，HTTPS支持CONNECT和原生双模式，SOCKS5开箱即用。

相比之下，市面上很多服务商在HTTPS支持上打了折扣，SOCKS5更是大多数产品的盲区。如果你的业务对协议有要求，“能通”和“稳定高效地通”完全是两种使用体验——选错一个，后面全都是坑。