HTTP 与 SOCKS5 代理：握手过程与传输规范
从字节层面比较 HTTP CONNECT 和 SOCKS5：发送第一个字节前的往返次数、socks5h 协议中滞后的 ATYP 字节、两者的身份验证方式，以及为何两者均未对到代理服务器的跳转进行加密。
- OSI层差异 —— 第7层HTTP解析与第5层SOCKS5会话中继。
- 握手机制 —— HTTP CONNECT 文本管道与 RFC 1928 二进制状态机。
- DNS泄漏防护 —— 为何socks5h://远程DNS（ATYP 0x03）能保护您的真实IP地址。
- 传输协议 —— TCP 字节流隧道与 SOCKS5 UDP ASSOCIATE 的对比。
所有浏览器和 HTTP 库均可识别；非常适合 Web 自动化。
以中立方式中继任意的 TCP 和 UDP 有效载荷，而不解析报头。
几乎所有对这两种协议的比较都会从速度和安全性两方面进行评分，而这些评分几乎全都是凭空捏造的。这两种协议都只用几字节的数据来商定如何建立连接，之后便完全不再干预。真正的区别在于这几字节数据传输期间发生的事情——其中有三个后果值得了解。
HTTP 代理实际上包含两种不同的概念
“HTTP 代理”这一术语指代两种行为，而比较类文章通常会将这两种行为混为一谈。 第一种情况下，客户端发送一个普通请求，其请求行中携带的是绝对 URI 而非路径，而代理会全程参与处理：它会解析请求头，可能缓存响应，可能对响应进行过滤，还可能添加自己的请求头——例如包含自身名称的 Via 头，以及携带你地址的 X-Forwarded-For 头。 这就是转发代理，它会读取所有内容。
在第二种情况下，客户端发送的 CONNECT 请求中使用主机名和端口号代替 URL，并要求代理不再作为 HTTP 参与方。 RFC 9110 用异常通俗的语言定义了接下来的流程：在收到 2xx 响应后，代理将转变为隧道，在两个连接之间充当“盲中继”，且不修改消息内容；一旦激活，该隧道将完全不被视为 HTTP 通信的参与方。 该规范甚至明确指出，通过共享防火墙代理传输 TLS 就是该机制的核心所在。
> CONNECT example.com:443 HTTP/1.1 > Host: example.com:443 > < HTTP/1.1 200 Connection established < ... every byte after this line is relayed untouched ...
这一区别决定了标准比较中还有多少内容仍然适用。 由于如今几乎所有流量都是HTTPS，你实际使用的HTTP代理就是隧道，而非转发代理——这意味着大多数比较HTTP与SOCKS5的文章中归因于HTTP一侧的缓存、标头重写和内容过滤等功能，根本不适用于你实际建立的连接。 这些才是传输明文的转发代理的实际功能，而根据其设计原理，隧道连接本身无法实现这些功能。
一个名称，两种行为：转发型 HTTP 代理会读取并可重写您的请求；而 CONNECT 隧道仅读取主机名和端口，除此之外绝不会读取任何其他信息。 如果你是为了比较协议并从中选择一种，那么隧道才是与 SOCKS5 进行比较的对象。至于“代理是什么”以及“代理位于何处”这类普遍问题，请从以下内容开始了解： 什么是代理服务器 而是。
SOCKS5 握手过程，逐字节解析
RFC 1928 中定义的 SOCKS5 协议永远不会识别其所承载的具体协议。通信以问候开始：客户端发送一个版本字节、其支持的认证方法数量以及认证方法代码本身。 服务器以两个字节进行应答——版本号以及其选定的唯一一种方法。如果应答为 0xFF，则表示没有可接受的方法，客户端必须关闭连接。
随后，客户端发送一个指定命令的请求：0x01 CONNECT 用于建立出站 TCP 连接，0x02 BIND 用于建立入站 TCP 连接，或 0x03 UDP ASSOCIATE。 同一请求中还包含一个地址类型字节（ATYP），其值可以是 0x01（表示 4 个八位组的 IPv4 地址）、0x03（表示域名，其第一个八位组表示域名长度）或 0x04（表示 16 个八位组的 IPv6 地址）。 服务器进行应答，从该应答开始，连接双方的通信均以原始字节形式进行。
> 05 02 00 02 VER=5, 2 methods offered: none, user/pass < 05 02 server chose 02 (username/password) > 05 01 00 03 0b 65 78 61 VER=5, CMD=01 CONNECT, RSV=00, 6d 70 6c 65 2e 63 6f 6d ATYP=03 domain, LEN=11 "example.com" 01 bb port 443 < 05 00 00 01 ... REP=00 succeeded, then raw bytes
这种协议无关性正是SOCKS5的全部优势，而且确实是一大优势。 上述通信中未提及HTTP，因此同一个端点既可承载SSH会话、SMTP通信、游戏客户端，也可承载HTTP代理无法识别的内部二进制协议。HTTP代理需要能够解析的请求或能够响应的CONNECT请求，而SOCKS5只需一个地址和一个端口。
第三个命令 UDP ASSOCIATE 是“原始 TCP 字节”的唯一例外，RFC 1928 将其部分内容设为可选——不支持分片功能的实现必须直接丢弃无法处理的数据报。 特定服务器是否实现了该命令，规范中并未说明，因此 代理检测工具 这是针对特定终点进行处理的地方。除了这一句之外，它不会出现在本页中。
1 在第一个有效载荷字节之前所需的往返次数——当需要响应 407 挑战时为 2。
2 在第一个有效载荷字节之前所需的往返次数——当协商用户名/密码身份验证时为 3 次。
脚注：CMD 0x03 UDP ASSOCIATE 是完全脱离本图的分支——它建立的是独立的数据报中继，而非 TCP 流，且 RFC 1928 将其部分内容设为可选，因此特定服务器是否对此作出响应，则取决于 代理检测工具，而不是用于规格说明。
同样的两段对话
HTTP CONNECT
- 客户端向代理服务器发送：CONNECT example.com:443
请求目标是一个权威实体——即主机和端口——而非带有路径的 URL。该名称在设计上会传递给代理，因此由代理来解析它。
- 可选：代理到客户端：407，然后客户端到代理：Proxy-Authorization
需要凭证的代理会返回一个挑战，客户端则携带凭证进行重试。除非客户端预先发送凭证，否则这将多消耗一次往返通信。
- 代理服务器发给客户端：HTTP/1.1 200 连接已建立
从这一行开始，隧道便已建立。代理不再参与此次通信。
- 客户端到源服务器，通过代理：TLS，然后是有效载荷
字节在两个方向上均以原样转发。代理仅掌握您的主机名和端口，除此之外一无所知。
SOCKS5
- 客户端到代理：第 5 版及方法列表
一种问候消息，其中列出了客户端愿意使用的所有身份验证方法，最常见的是 0x00（无）和 0x02（用户名/密码）。
- 代理服务器对客户端：其选定的方法
两个字节。如果响应为 0xFF，则表示所提供的内容均不可接受，客户端必须关闭连接。
- 可选地，RFC 1929 子协商
如果选择了用户名/密码认证方式，客户端会发送其凭据，服务器则返回一个状态字节。这需要多一次往返通信。
- 客户端到代理：请求及其 ATYP 字节
该命令后跟一个地址类型：0x01 携带四个已解析的八位字节，0x03 携带域名本身。这一字节是 SOCKS5 和 SOCKS5H 的分岔点。
- 代理到客户端：先是响应，然后是原始字节
响应码 0x00 表示操作成功。其后的内容均属于您的协议，系统不会对其进行检查。
谁将主机名转换为IP地址
关于 Socks5 与 Socks5h 的区别，在 HTTP 中根本不存在类似的情况，而这种不对称性正是这两种协议之间最显著的实质性差异。根据设计，HTTP 代理接收的是主机名：CONNECT 请求的目标是一个权威服务器，而转发请求行是一个绝对 URI。 无论哪种情况，代理都会收到一个名称，并且必须先解析该名称才能建立连接。在 HTTP 代理交互中，不存在客户端已经完成名称解析并直接传递地址的情况。
在这两种协议中，只有 SOCKS5 提供了这一选项，而且它以单字节的形式提供，而非通过设置实现。 ATYP 0x01 表示后续的四个八位组是客户端已经解析过的地址。ATYP 0x03 表示后续的字节是一个名称，代理应对其进行解析。大多数客户端库默认采用本地解析，因此通常需要有意识地做出选择。
这实际上改变的是由哪个解析器来响应，而不同的解析器给出的响应并不完全相同。 CDN会将您引导至离请求者较近的边缘节点；而“分时域”配置则会根据查询来源的不同返回完全不同的记录。若在本地进行解析，您将获得自身所在位置的响应，而流量却从其他地方流出——这正是请求最终到达与出口IP不匹配的边缘节点的原因。 若在代理服务器上进行解析，则响应将与出口IP一致。这也会改变您自身网络所能观察到的情况，因为本地解析的域名无论后续流量流向何处，都会被您的网络记录为一次查询。
本节主要讨论哪个字节承载地址，以及由哪个解析器来响应该请求。关于该方案如何实际向客户端发送数据，请参阅 设置移动代理 或者 Linux 配置指南; 若要查看某个特定的代理在处理您的查询时究竟做了什么，请将其通过 代理检测工具.
同一个字节中还隐藏着另一个后果。ATYP 0x04 携带一个 16 个八位的 IPv6 地址，因此，一个已在本地解析为 IPv6 记录的 SOCKS5 客户端可以直接将其传递出去——如果你正在处理 IPv6 移动代理 并想知道连接的哪一端选择了地址族。
身份验证，以及这两种协议均未加密的跳点
这两种协议的身份验证机制截然不同。需要凭据的 HTTP 代理会对未经身份验证的请求返回 407 Proxy Authentication Required 状态码，并附带描述身份验证挑战的 Proxy-Authenticate 头；客户端则会携带 Proxy-Authorization 头进行重试。 这是一种先拒绝后重试的机制，因此除非客户端主动提前提供凭据，否则每次请求都需要消耗一次往返通信。
SOCKS5 绝不会拒绝请求并重试。 在执行任何其他操作之前，双方会先协商协议方法：客户端列出其支持的方法，服务器指定一种，如果该方法为 0x02，则双方将进行 RFC 1929 子协商——先发送版本字节 0x01，接着是用户名长度及用户名，然后是密码长度及密码， 每项长度均在 1 至 255 个八位字节之间，服务器以一个两字节的状态值进行响应，其中 0x00 表示成功。RFC 1928 还为 GSSAPI 定义了 0x01，该协议在 RFC 1961 中另有说明，但商业代理极少提供此功能。
机制不同，安全状况却如出一辙：这两种协议均未对您与代理服务器之间的传输段进行加密。RFC 1929 对其自身的方法也直言不讳地指出这一点，并警告称，由于请求中以明文形式携带密码，因此不建议在可能发生且实际存在嗅探风险的环境中使用该子协商机制。 HTTP 也同样存在问题——采用 Basic 方案的 Proxy-Authorization 使用的是 Base64 编码，这是一种为传输安全而选择的编码方式，而非加密算法，传输路径上的任何实体都能轻松将其还原。
出于隐私考虑而选择 SOCKS5，其实等于什么都没选。 无论使用哪种协议，其保密性都源于隧道内端到端运行的 TLS 会话，而代理无论如何都无法读取该会话内容。如果您的担忧具体在于凭证以明文形式传输，那么解决之道并非更换代理协议——而是在客户端拥有固定 IP 地址的情况下，改用 IP 白名单认证而非密码认证。
这也是最清晰地说明为何协议问题与隐私问题并非同一问题的途径。如果你真正想了解的是代理隐藏了什么、向谁隐藏，以及这与设计上对第一跳进行加密的隧道有何不同，那么这种比较依然成立 代理与VPN的对比 而不是在这里。
速度：哪些是可以测量的，哪些只是民间传说
通常的说法是，SOCKS5 速度更快，因为它不会解析你的流量。这种说法经不起握手过程的检验。这两种协议都在完全相同的时刻——即建立过程完成的瞬间——停止解析，此后两者都成为“盲中继”，通过同一条 TCP 连接将完全相同的字节传输到同一源服务器。 由于双方均未进行按字节的处理，因此无法测量任何按字节的处理差异。
在建立连接的延迟方面，实际情况与普遍说法恰恰相反。HTTP CONNECT 在发送第一个有效载荷字节之前需要一次往返：发送 CONNECT 请求，接收 200 响应。SOCKS5 则需要两次：先进行问候，接收方法，再发送请求，最后接收回复。 若加入用户名/密码认证，SOCKS5 需要三个往返，而 HTTP 仅需两个往返——前提是客户端等待认证挑战而非预先发送凭据。这一计算结果出自我们之手，而非 RFC 规范，但它直接源于各规范所要求的消息数量。
这意味着真正决定吞吐量的变量，恰恰是这两种协议都无法控制的：代理与源服务器之间的路由、出口网络的状况——移动出口网络的无线信号质量和对等连接情况，以及任何出口网络的拥塞情况——还有客户端重用连接的效率。 在长期会话中，建立连接的成本只需支付一次，且可视为统计噪声。而在每次请求都会建立新连接的爬取工作负载中，每条连接的成本占据主导地位，其解决方案在于连接复用，而非采用不同的协议。
一个为每个请求都建立新连接的基准测试，实际上是在测量握手过程，而非吞吐量——它会将建立连接耗时较短的协议报告为“更快”的协议，但这并不能反映任何一种协议在传输数据时的实际性能。如果你想获得吞吐量数据，就应测量持续传输速率；如果你关注的是连接建立过程，则应单独测量该过程。
对于真正影响收集工作负载性能的关键因素——每台主机的并发数、重试行为以及请求本身的结构—— Python 数据抓取指南 比任何协议对比页面都更有用。
客户真正想要的是哪一个
协议的选择取决于两个因素：您的流量实际情况，以及客户端在无人协助的情况下所做的配置。这并非由一个笼统的结论来决定，因为对于最常见的情况而言，两者之间并无值得斟酌的实质性差异。
| 属性 | HTTP 转发代理 | HTTP CONNECT 隧道 | SOCKS5 |
|---|---|---|---|
| 代理可以读取什么 | 整个请求：方法、路径、请求头、请求体 | CONNECT 行中的主机名和端口号，其后没有其他内容 | 请求中的地址和端口，后面没有其他内容 |
| 设置交易所 | 无——第一个请求即为该请求 | CONNECT，随后返回 2xx 状态码 | 问候、方法选择、请求、响应 |
| 第一个有效载荷字节之前的往返次数 | 0 — 请求本身就是第一个有效载荷 | 1，或在接听407时按2 | 2，或 3（需输入用户名/密码） |
| 地址格式，以及由谁负责 | 绝对 URI — 代理服务器进行解析 | 主机和端口权限——由代理服务器进行解析 | ATYP 0x01 IPv4、0x03 名称、0x04 IPv6 — 由客户端选择 |
| 运输量 | TCP，且仅在其上运行HTTP | TCP，隧道内的任何协议 | TCP，以及在服务器实现 UDP ASSOCIATE 时使用的 UDP |
| 资质证书 | 407 挑战，然后是代理授权 | 407 挑战，然后是代理授权 | 协商方法代码，随后进行 RFC 1929 子协商 |
| 代理可能添加或移除的内容 | Via、X-Forwarded-For、标头重写、缓存、过滤 | 隧道一开通，就什么都没有了 | 回复发送后就什么都没有了 |
| 传统港口 | 按惯例为 3128 或 8080 | 按惯例为 3128 或 8080 | 按惯例为1080 |
| 无需助手即可提供客户支持 | 通用，但仅可通过明文HTTP访问 | 浏览器、curl 以及所有 HTTP 客户端库 | 浏览器和 curl 支持原生功能；某些库需要额外的包 |
仔细阅读最后两列的内容，不难得出这样的结论：对于 HTTPS 流量，这两款产品实际上是相同的。无论您的流量是来自浏览器、爬虫框架还是 HTTP 库的 HTTPS 流量，它们的隧道传输方式都完全一致，因此正确的选择就是您所使用的工具原生支持的那一款。
何时应选择 SOCKS5
- 这些流量根本不是 HTTP —— 可能是 SSH、SMTP、数据库客户端、游戏客户端，或是内部二进制协议。从技术上讲，CONNECT 隧道可以承载上述任何一种流量，但前提是客户端知道如何请求建立该隧道，而大多数非 HTTP 客户端并不具备这一能力。
- 你需要一个全系统范围的统一入口点，让机器上的所有内容都能指向它，而不是为每个应用程序单独设置HTTP代理——因为许多应用程序会悄悄忽略这些设置。
- 你需要客户端进行代理端域名解析，而该客户端仅在 SOCKS 路径上提供此功能，这是一种常见的情况——该设置存在于 SOCKS 端，且没有对应的 HTTP 选项可供切换。
- 你需要 UDP 中继功能，而没有任何 HTTP 代理提供此功能。特定的 SOCKS5 服务器是否实现了该功能则是另一个问题，只有通过实际测试才能得到答案。
除了这些情况之外，选择更便宜或更简单的方案确实没问题，而且选择客户端已经支持的那种方案也不会给你带来任何可衡量的成本。PXM2 同时提供了这两种方案（分别在不同的端口上），因此选择权在于客户端，而非购买决策。 如果你仍在代理类别而非协议之间犹豫不决——这属于另一个会产生实际成本影响的问题——请从 代理类型的说明 或者 代理类型中心.
部署 HTTP 和 SOCKS5 移动代理
每台 PXM2 移动代理都在专用端口上同时提供 HTTP 和 SOCKS5 端点：
法国
新加坡
印度
常见问题解答
SOCKS5 和 SOCKS5h 之间最关键的区别是什么？
唯一的区别在于域名DNS解析发生的位置。标准的SOCKS5（socks5://）会在将目标IP发送给代理之前，在客户端机器上本地解析目标主机名，从而导致您的DNS查询被泄露给本地ISP。 SOCKS5h (socks5h://) 则指示客户端应用程序跳过本地 DNS 解析，直接将原始域名字符串发送至代理（使用 RFC 1928 地址类型 0x03），从而防止 DNS 泄露。
HTTP 代理能否处理 WebRTC 或 DNS 这样的 UDP 流量？
不。HTTP 代理（包括 HTTPS CONNECT 隧道）严格限制为流式 TCP 连接。 SOCKS5 通过 UDP ASSOCIATE 命令（命令字节 0x03）明确支持 UDP 数据报转发，因此适用于依赖 UDP 的协议，例如 WebRTC、在线游戏和实时媒体。
SOCKS5 会加密您的互联网连接吗？
不。SOCKS5 是一种代理传输协议，而非加密隧道。虽然 SOCKS5 会以中立方式隧道传输您的数据而不对其进行检查，但默认情况下，您的计算机与 SOCKS5 代理服务器之间的连接并未加密。 如果您通过 SOCKS5 传输 HTTPS 流量，您的数据将由 TLS 加密；但通过 SOCKS5 传输的普通 HTTP 或 FTP 流量可能会被本地网络中的任何人查看。
在网页爬取方面，SOCKS5 比 HTTP 代理更快吗？
SOCKS5 在代理服务器上的 CPU 开销略低，因为它执行的是轻量级的二进制套接字切换，无需解析 HTTP 头部。 然而，在现代网页抓取中，一旦 TCP 连接建立，HTTPS CONNECT 代理提供的吞吐量几乎与 SOCKS5 相同，并且通常能更好地与 HTTP 客户端连接池（keep-alive）和浏览器自动化工具集成。
如何配置 cURL 以使用 SOCKS5 并启用远程 DNS 解析？
在 cURL 中，请使用 --socks5-hostname 选项（或 socks5h:// URL 前缀）：curl --socks5-hostname user:pass@proxy_host:port https://ipinfo.io。 这可确保 cURL 将主机名“ipinfo.io”传输给代理，而非查询您的本地 DNS 解析器。