HTTP 与 SOCKS5 代理:该用哪个、什么时候用

HTTP 代理和 SOCKS5 代理解决的是不同的问题。一份实战指南,讲清楚两者各自怎么工作、各自在哪里更合适、以及如何为你的工作负载选对。

“我该用 HTTP 还是 SOCKS5?”是新客户最常问的问题之一,而诚实的答案是:取决于你要连接什么。大多数时候,对日常的网页抓取来说,这两者可以互换。差异只在边缘情况里才开始重要,而那些边缘情况,恰恰是人们选错、然后花一整天去排查一个其实和代码无关的问题的地方。

这是一份关于这个差异的实战指南。HTTP 代理到底做什么、SOCKS5 代理又有什么不同、各自在哪里更合适,以及一条简单的选择规则。不讲协议历史课,只讲那些会改变你该怎么做的部分。

如果你只想记住一件事:HTTP 代理理解网页请求,并能对它做处理;SOCKS5 代理只搬运字节,不在乎里面是什么。前者更聪明,后者更通用。

一句话讲清差异

HTTP 代理工作在应用层。它会说 HTTP,所以能读请求行、看到目标 URL、检查并修改请求头,并根据它看到的内容做决定。它知道自己在代理网页流量。

SOCKS5 代理工作在更底层,靠近传输层。它在你的客户端和目标之间打开一条隧道,在两个方向上转发原始字节。它不解析流经它的东西。它能用于 HTTP,但用于任何其它跑在 TCP 或 UDP 上的东西也一样好用。

这一个架构上的差异,驱动了下面每一条实际区别。

HTTP 代理如何处理你的请求

当你的客户端通过 HTTP 代理发出请求时,代理能看到全部内容。对一个普通的 http:// 请求,它读完整 URL,可以重写请求头、缓存响应、注入或删除字段,并转发一个它能理解的请求。对一个 https:// 请求,客户端先向代理发一个 CONNECT,代理向目标打开一条隧道,从那之后加密流量原样通过,代理不读载荷。所以即便是 HTTP 代理,对 HTTPS 最终也是在做隧道,但它仍然从 CONNECT 知道目标主机和端口,仍然在 HTTP 层处理认证和路由。

结论是:HTTP 代理懂网页。当你希望代理对请求做点什么时,这很有用;当你只是想让它别挡道时,这无关紧要。

SOCKS5 代理如何处理你的连接

SOCKS5 代理做一次简短的握手(可选的用户名/密码认证,然后一个指明目标主机和端口的连接请求),从那以后就是一根”哑”管道。你的字节出去,目标的字节回来,代理不解读其中任何内容。它没有 HTTP 请求头的概念,因为它根本没有 HTTP 的概念。

这是特性,不是限制。因为它不解析协议,SOCKS5 能承载任何东西:HTTP、HTTPS、WebSocket、原始 TCP、数据库连接、SSH、自定义协议,以及(SOCKS5 特有的)UDP。这个代理在设计上就是协议无关的。

HTTP 代理在哪里更合适

网页抓取以及大多数浏览器自动化。 对绝大多数”取这个 URL”的负载来说,HTTP 代理是天然之选,在每一个 HTTP 客户端和库里都有良好支持,零意外。如果你的活儿就是对网站发请求,HTTP 是默认值是有道理的。

当你想要请求头级别的控制或可见性时。 因为 HTTP 代理理解请求,围绕它的工具可以在请求级别做日志、路由或转换。对普通 HTTP 这是直接的;对 HTTPS,代理仍然能从 CONNECT 看到目标。

最大的工具兼容性。 每个抓取框架、每个浏览器、每个 HTTP 库,都对 HTTP 代理有一等支持。有些对 SOCKS5 的支持很别扭或只是部分支持。如果你想走阻力最小的路,HTTP 几乎从不跟你作对。

SOCKS5 代理在哪里更合适

非 HTTP 流量。 一旦你的自动化要做的事情不是网页请求,SOCKS5 就成了答案。连接邮件服务器、数据库、IRC 或聊天协议、游戏服务器、自定义 TCP 服务——任何不是 HTTP 的东西,HTTP 代理帮不上忙,SOCKS5 可以。

基于 UDP 的协议。 SOCKS5 支持 UDP,而 HTTP 代理从根本上做不到。如果你要处理任何跑在 UDP 上的东西,SOCKS5 不只是更可取,而是唯一能用的代理选项。

代理侧更低的开销。 因为它不解析、不推理 HTTP,SOCKS5 代理每个连接做的工作更少。在非常高的连接量下,这可能意味着略低的延迟和更少的每请求开销。对典型抓取来说效果不大,但在规模上是真实的,这也是为什么高吞吐的自动化流水线常常倚重 SOCKS5。

期待一个 SOCKS 端点的工具。 一些软件(某些 torrent 客户端、SSH 的 -D 动态转发、一些隐私工具)原生说 SOCKS。如果你的工具想要一个 SOCKS5 代理,就直接给它,而不是用一层 HTTP 把它包起来。

两者之间不会有差别的部分

大部分迷思都活在这里,所以值得直白地说:

匿名性和封禁率是一样的。 你用来到达代理的协议,不会改变目标看到的 IP、IP 的信誉、或反爬系统给它打的分。一个住宅 IP走 HTTP 时和走 SOCKS5 时一样可信。如果有人告诉你 SOCKS5”更匿名”或”更难检测”,他是在卖一个迷思。目标看到的是你的出口 IP 和你的流量指纹,而不是你的代理协议。

对正常负载来说速度大致相同。 SOCKS5 的开销优势是真实的,但很小。对一个发几千个请求的抓取器,你测不出有意义的差别。到出口 IP 的网络距离、目标服务器速度、以及你的并发设置,远比 HTTP-还是-SOCKS5 更主导。

地理定位和会话控制是一样的。 在 Shifter 网关上,按国家、州、城市、ASN 以及 sticky 会话的定位,无论你用哪种协议连接都完全一致。定位住在用户名里,不在协议里。

换句话说,协议选择关乎你在连接什么、你的工具期望什么,而不关乎少被封一点或藏得更好一点。

在 Shifter 网关上是什么样子

Shifter 住宅网关在同一个端点、同一个主机、同一个端口、同一套凭证上,同时说 HTTP、HTTPS、SOCKS5 和 SOCKS5h。你在客户端一侧选择协议;服务端一侧什么都不变。

用 curl 走 HTTP/HTTPS:

curl -x http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://api.ipify.org

完全相同的请求走 SOCKS5h(h 表示 DNS 在代理侧解析,这几乎总是你想要的,这样你本地的解析器永远看不到目标主机名):

curl -x socks5h://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://api.ipify.org

注意唯一的改动是协议方案:http:// 变成 socks5h://。用户名(连同你所有的定位 flag)、密码、主机、端口都一样。这就是全部的切换。

在 Python 里用 requests,模式是同一个意思:

import requests

# HTTP/HTTPS
proxies = {
    "http": "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443",
    "https": "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443",
}

# SOCKS5(需要: pip install requests[socks])
proxies_socks = {
    "http": "socks5h://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443",
    "https": "socks5h://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443",
}

r = requests.get("https://api.ipify.org", proxies=proxies)
print(r.text)

有一点值得知道:用 requests 时,SOCKS 支持需要额外的 requests[socks](它会装上 PySocks)。HTTP 什么都不用额外装。这点打包上的摩擦,是 HTTP 在快速脚本里仍然是默认值的一个小但真实的原因。

SOCKS5 与 SOCKS5h:在哪里解析 DNS?

一个让人栽跟头的小脚注。普通的 socks5:// 在你的机器上解析目标主机名,然后把得到的 IP 发给代理。socks5h:// 把主机名发给代理,让代理去解析。对代理使用来说,你几乎总是想要 socks5h,因为:

它把 DNS 查询挡在你的本地网络之外,这对隐私、以及拿到来自出口区域的地理正确的 DNS 结果都重要。
它避免了一类微妙的 bug:你本地的解析器返回的 IP,和目标期望从代理所在区域提供服务的 IP 不一致。

如果你在 SOCKS5 上看到地理不一致的结果,检查一下你用的是 socks5h 而不是 socks5。这是一个一字之改,能解决数量惊人的”地理定位不起作用”工单。

一条简单的决策规则

你不需要流程图。三个问题,按顺序问:

流量是 HTTP/HTTPS(一个网页请求)吗? 如果是,而且你没有特别的相反理由,用 HTTP。它是默认值、被普遍支持、不需要额外的包。这覆盖了大多数抓取、比价监测、SERP 采集和浏览器自动化。
流量是 HTTP 之外的东西,或者用了 UDP 吗? 用 SOCKS5。邮件、数据库、自定义 TCP/UDP 服务、原生说 SOCKS 的工具、任何非网页的东西。SOCKS5 是两者里唯一能承载它的。
你在跑一个非常高吞吐的流水线,想削减每连接开销吗? SOCKS5 给你一点小优势。在假设这个差异重要之前,先拿你的真实负载测一测;对大多数团队来说,它不重要。

这就是全部的决策。拿不准时,HTTP。当它不是网页请求时,SOCKS5。

常见问题

SOCKS5 抓网页比 HTTP 快吗? 顶多是微乎其微,而且通常测不出来。SOCKS5 做的协议解析更少,所以每连接开销略低,但对典型抓取来说,你的延迟由网络距离和目标服务器响应时间主导,而不是代理协议。别指望换成 SOCKS5 能让网页流量提速。

SOCKS5 比 HTTP 更匿名、更难被检测吗? 不会。目标看到的是你的出口 IP 和流量指纹,不是你怎么到达代理的。检测和封禁率取决于 IP 的质量(住宅 vs 数据中心)、你的请求模式、以及你的指纹,从来不取决于 HTTP-还是-SOCKS5。这是关于代理协议最常见的误解。

我能用 SOCKS5 配无头浏览器吗? 可以,大多数无头浏览器和自动化框架都支持 SOCKS5,只是配置各有差别,有些对 HTTP 的支持更干净。对直白的网页自动化,HTTP 通常更省事。需要时再为浏览器选用 SOCKS5。

Shifter 对 HTTP 和 SOCKS5 收费不同吗? 不。两种协议都跑在同一个住宅网关上,按同样的每 GB 价格。协议选择纯粹是技术问题;它不影响计费、定位或池子访问。

socks5 和 socks5h 有什么区别? socks5h 在代理侧解析 DNS;普通 socks5 先在你的机器上解析。对代理工作,你几乎总是想要 socks5h,这样 DNS 发生在出口区域,你本地的解析器永远看不到目标主机名。

HTTP 代理能看到我的 HTTPS 流量吗? 不能。对 HTTPS,HTTP 代理通过 CONNECT 打开一条隧道,加密流量原样通过、不被读取。代理知道目标主机和端口(来自 CONNECT),但不知道载荷。无论哪种方式,你的 HTTPS 都是端到端加密的。

结论

对你在网上做的几乎所有事情,HTTP 和 SOCKS5 都能用,而 HTTP 是摩擦更小的默认值。SOCKS5 在你走出网页请求、或需要 UDP、或你的工具原生说 SOCKS 的那一刻,才真正赢得它的位置。两者谁都不是”更好”,它们是为不同的活儿造的。

而且关键是,两者都不会改变你被封的频率。那取决于 IP 质量和行为,而不是协议。如果封禁是你的问题,答案是一个更好的住宅网络和更聪明的请求模式,而不是把方案从 http:// 改成 socks5h://。

在 Shifter 上,两种协议住在同一个网关里,有同样的定位和同样的价格,所以你可以为每一个活儿用合适的那个,并通过改连接串里的一个词来切换。从住宅计划开始,按你技术栈喜欢的方式连接就行。