SOCKS 与 HTTP 代理：差异、速度与协议选择
HTTP 和 SOCKS 代理都通过中间服务器，将应用连接到目标。对于浏览器、抓取程序或 API 客户端，支持 CONNECT 的 HTTP 代理是实用的起点。如果应用要求 SOCKS、需要其他 TCP 协议，或支持 UDP 转发，SOCKS5 就很有用。两者都可以承载发往 HTTPS 网站的流量。
协议决定程序如何与代理通信。出口 IP 的来源、轮换方式，以及共享或独享访问，是另外的选择，详见代理类型与配置选择指南。从 HTTP 改为 SOCKS，本身不会改变这些属性。
HTTP 和 SOCKS 如何处理连接
HTTP 转发：代理处理 Web 请求
对于普通未加密 HTTP 请求，客户端将目标 URL、方法和请求头发送给代理。代理处理请求，并从目标取得响应。如果进行了相应配置，它可以应用 HTTP 规则、修改请求头或使用缓存。这些是 HTTP 代理可能具备的功能，服务不一定全部启用。
SOCKS5：代理为应用建立连接
客户端协商身份验证方法，按要求完成验证，并提供目标地址和端口。代理随后建立所请求的 TCP 连接，并转发应用字节。相同机制可以承载 HTTPS、SSH 或其他受支持的 TCP 应用协议。代理无需解析 HTTP 请求即可转发。
通过 CONNECT 访问 HTTPS：两种方式更加接近
通过常规 HTTP 代理打开 HTTPS 网站时，客户端通常发送 CONNECT 请求。代理接受隧道后，客户端在其中与网站建立 TLS。代理转发加密数据。SOCKS5 完成自己的连接建立步骤后，也可以转发相同的 TLS 交互。
比较速度和隐私时，这一点很重要：在隧道中承载 HTTPS 的 HTTP 代理，不会解析每个加密页面请求。两种代理都在转发受保护的流量。具体顺序，以及 HTTP 转发与隧道之间的区别，见HTTP 与 HTTPS 代理。
HTTP 与 SOCKS5 概览
下表比较的是 SOCKS5。较旧的 SOCKS4 和 SOCKS4a 功能较少，主要在现有软件要求使用它们时才相关。
| 功能 | HTTP／HTTPS 代理 | SOCKS5 代理 |
|---|---|---|
| Web 请求 | HTTP 使用转发；HTTPS 通常使用 CONNECT 隧道。 | 应用通过已建立的连接发送 HTTP 或 HTTPS。 |
| 其他 TCP 应用 | 如果客户端支持，且目标端口获准，可以通过 CONNECT 使用。 | 适合原生支持 SOCKS 的应用；仍需遵守服务规则。 |
| 目标 DNS | 代理可以解析请求或 CONNECT 目标中提供的主机名。 | 客户端可以发送主机名交由远端解析，也可以先在本地解析。 |
| 到代理的连接保护 | HTTPS 代理在这条连接上使用 TLS；普通 HTTP 代理则不使用。 | 常规无身份验证和用户名／密码模式，不会加密这条连接。 |
| 访问控制 | HTTP 身份验证方法，以及／或者 IP 白名单等服务访问规则。 | 协商的身份验证方法，以及／或者 IP 白名单等服务访问规则。 |
| UDP | 普通 CONNECT 不够。UDP 需要额外且受支持的隧道机制。 | 协议中有定义，但客户端和服务都必须实现。 |
| 性能 | 对于新的 HTTPS 隧道，建立过程可能需要更少往返。传输速度还取决于实现和路由。 | 有自己的建立连接交互。不解析 HTTP，并不保证 HTTPS 传输更快。 |
HTTP 与 SOCKS5，哪个更快？
通过 HTTP CONNECT 建立新的 HTTPS 连接，可能更快就绪，因为常规建立过程与代理的交互次数更少。下文说明这种差异所基于的假设。隧道一旦打开，长时间下载或后续请求都可以复用它。两种协议在持续传输速度上都没有固定优势。
新连接：统计交互次数
从到代理的 TCP 连接就绪后开始，统计建立过程中的消息，并假设每个请求都等待响应后再继续。本比较不包含到代理的 TLS 层。HTTP 身份验证要么不需要，要么凭据已包含在第一个 CONNECT 请求中并验证成功。
| 连接方式 | 隧道就绪前的交互次数 |
|---|---|
HTTP CONNECT | 1 次：CONNECT 请求及成功响应。 |
| SOCKS5，不使用协议身份验证 | 2 次：方法选择，然后是连接请求及响应。 |
| SOCKS5，使用用户名和密码 | 3 次：方法选择、用户名／密码验证，然后是连接请求及响应。 |
因此，在这些假设下，SOCKS5 无身份验证时多一次客户端与代理之间的往返，使用标准用户名／密码验证时则多两次。往返时间，即 RTT，是消息到达代理并收到回复所需的时间。以示例 RTT 50 ms 计算，这些额外交互约需 50 或 100 ms。这是根据协议顺序作出的估算，并非代理服务的基准测试，也不是请求总耗时。
两条路径都还需要代理连接目标，以及客户端完成网站的 TLS 建立过程。DNS 耗时、处理和拥堵情况可能不同。HTTP 身份验证质询会增加交互；连接 HTTPS 代理所需的 TLS 也有自己的建立步骤。比较实际配置时，都应将这些情况计入。
复用连接：初始差异由多个请求分摊
连接池保留合适连接，供后续请求使用。复用 HTTPS 连接，可以避免每次请求都重复 TCP、代理协商和网站 TLS 握手。如果客户端和目标支持 HTTP/2，多个请求流可以共用一条已建立连接。无论在 HTTP CONNECT 隧道内，还是 SOCKS5 连接内，都可以这样工作；代理无需解析 TLS 内部的 HTTP/2 消息。
每个 URL 都创建新的 HTTP 客户端对象，可能导致连接池被丢弃。这里的复用客户端，是指保留软件对象及其连接，而不是要求代理保持出口 IP。当批量任务反复访问相同主机时，复用连接可能比更换代理协议省下更多建立开销。新的目标、已关闭的连接或改变的代理设置，仍可能需要新隧道。
大规模传输：关注可用带宽
隧道建立后，下载速度取决于路由、丢包、可用带宽、代理负载和服务限制。通过 CONNECT 转发 HTTPS，本身已经是在转发字节。以“不读取 HTTP”为由声称 SOCKS5 更快，忽略了这种情况。
对于未加密 HTTP，配置的缓存或内容处理可能改变结果。使用缓存响应，与从源站下载相同内容，是不同的工作负载。公平比较必须考虑这一差异。
大型 Web 脚本应使用哪种协议？
Web 脚本使用 SOCKS5 时，仍然发送 HTTP 请求；代理选项改变的是它如何到达服务器。对于新编写的网页获取或 HTTPS API 调用脚本，除非有明确要求指向其他方案，可以先使用成熟的 HTTP 客户端和 HTTP CONNECT。把代理选项放在配置中，以便用相同请求逻辑测试 SOCKS5。如果这种比较对项目重要，应选择同时支持两者的库。
| 工作负载 | 实用起点 |
|---|---|
| 大量短请求，且经常访问新主机 | 先尝试 HTTP CONNECT。频繁创建新隧道时，较短的协商过程可能有帮助。应测量完整成功请求。 |
| 向少量 API 或网站发送大量请求 | 使用持久客户端、连接池，以及受支持的 HTTP/2。确认连接复用后，再比较 HTTP 和 SOCKS5。 |
| 大文件或长时间 TCP 会话 | 选择支持完善的协议，测试持续吞吐量和中断情况。建立连接时间只占任务中的较小部分。 |
| 其他 TCP 协议或必要的 UDP 功能 | 如果应用支持所需模式，可考虑 SOCKS5。如果 UDP 必不可少，应确认应用和服务能通过代理交换数据报。 |
HTTP 和 SOCKS5 都可以由异步软件使用。代理协议不决定请求是否并发运行。应检查客户端库能否以所选代理模式发送并发请求、保留连接池，并限制进行中的操作数量。增加并发时，同时观察完成量和错误：代理、网络或目标达到上限后，更多连接可能意味着更长队列和更多重试。
扩大规模前，如何比较速度
- 使用相同程序、目标请求、响应大小和并发量。如果可能，比较具有相同出口 IP 和路由的协议端点；否则，应保持出口区域和服务限制可比，并记录差异。
- 一组测试使用全新连接，另一组在预热后使用正常连接池。保持 DNS 行为、TLS 保护、身份验证、HTTP 版本和重试策略一致，或说明它们不同的原因。
- 测量每秒成功完成的操作数，以及包含重试在内的整批耗时。同时记录完成时间的中位数和第 95 百分位数、超时和失败操作。第 95 百分位数表示 95% 的测量操作能够在这个时间内完成。
- 对于下载，记录每秒收到的有效字节数。对于短请求，分别统计连接建立、首字节时间和完整响应时间。首字节时间也包括等待目标生成响应的时间。
- 交替使用两种配置重复运行，并确认流量经过预期代理路径。如果某次测试使用了不同出口池，或退回到直接连接，其结果就无法单独体现代理协议的影响。
选择能在可接受错误率下更快完成真实工作的配置。快速的身份验证失败或不完整响应，都不是有效吞吐量。如果两者表现相近，应优先选择在所用应用中更容易维护的方案。
为什么应先看应用支持
名为“代理”的输入框，并不保证支持所有协议或身份验证方法。例如，Chrome 内置的 SOCKS5 处理支持 TCP 请求，但没有实现 SOCKS5 用户名／密码验证或 UDP 转发。即使 SOCKS5 服务具备这些功能，也无法让不支持的浏览器模式使用它们。
对于 SSH、文件传输或其他 TCP 应用，原生 SOCKS 支持可能很方便。HTTP CONNECT 也能承载其他 TCP 协议，前提是程序能创建隧道，而且代理允许目标端口。因此，“HTTP 代理”并不总是意味着“只能处理 Web 流量”。
浏览器代理设置，也不会自动覆盖其他程序或浏览器中的所有功能。外部适配工具有各自的覆盖范围和限制。版本差异与协商过程，见SOCKS5 与 SOCKS4 代理。
谁解析目标主机名？
使用 SOCKS5 时，应用可以在本地解析目标并发送 IP 地址，也可以发送主机名，由代理解析。在 curl 中，socks5:// 选择本地目标解析，socks5h:// 请求通过代理解析。多出的字母选择的是客户端行为，并没有创建一种新的 SOCKS 协议。
HTTP 代理同样可以查询 URL 或 CONNECT 请求中收到的目标名称。因此，两种协议都能进行远程目标 DNS 解析。从代理侧查询，可能返回不同的服务器地址，同时避免在本地查询该目标。客户端仍可能需要解析代理自身的主机名，其他应用也保留各自的 DNS 设置。应在客户端中选择 DNS 行为，而不是从代理协议推断。
哪条连接被加密？
应区分网站内容保护与到代理连接的保护。无论哪种隧道，HTTPS 网站通常都会保持客户端与网站之间的应用数据加密。这以正常验证证书、未配置 TLS 拦截为前提。
HTTPS 代理在客户端与代理之间增加 TLS，保护这段路径上的代理请求和凭据。在代理地址中，https:// 通常表示这条受保护连接。仅标为“用于 HTTPS 网站的代理”的设置，也可能指支持 CONNECT 的普通 HTTP 代理。
向普通 HTTP 代理发送的 HTTP Basic 凭据，以及标准 SOCKS5 用户名／密码交互，都可被能够观察这段未受保护网络路径的人读取。之后与网站建立的 TLS 连接，不能追溯保护先前的代理登录。如果需要这层保护，普通 SOCKS5 必须另配安全传输方式。
代理仍是其自身 TLS 连接的端点，也知道被要求连接的目标。如果最终目标使用普通 HTTP，到代理的 TLS 并不会加密后续 HTTP 连接。同样，SOCKS 转发也不会仅仅因为代理无需解析内容，就隐藏明文内容。
UDP 或 HTTP/3 会改变选择吗？
对于真正需要 UDP 的应用，SOCKS5 定义了 UDP ASSOCIATE。客户端和服务都必须实现它，网络路径也必须能够传递数据报。普通 HTTP CONNECT 承载的是 TCP 隧道。HTTP 也可以通过 CONNECT-UDP 等附加机制转发 UDP，但两端都必须实现。
HTTP/3 使用基于 UDP 的 QUIC。通过代理成功加载 HTTPS 页面，并不能证明 HTTP/3 可用：客户端可能使用了基于 TCP 的 HTTP/2 或 HTTP/1.1。对于 Web 脚本，这种回退可能足够；但对于必须使用数据报的功能，它不能替代 UDP。转发路径及其局限，见通过代理传输 UDP 与 QUIC。
SOCKS 更能隐藏客户端吗？
在未加密 HTTP 转发中，代理可以添加 Forwarded 等携带原始客户端信息的请求头。常规 HTTPS CONNECT 隧道如果不终止网站 TLS 连接，就无法将该请求头插入加密请求。SOCKS5 也不会自动添加 HTTP 请求头。
这并不意味着任一协议可以保证匿名，或保证网站接受请求。代理运营者可以观察连接元数据，目标则可以识别账户、Cookie 或应用行为。出口 IP 信誉以及共享人数是另外的因素。在同一服务上从 HTTP 切换到 SOCKS，不会自动解除封禁，也不会重置网站会话。
如何作出最终选择
先看应用支持的协议和访问方法。对于普通 Web 自动化，HTTP CONNECT 是合理的起点；对于围绕 SOCKS 构建的应用，或受支持的 UDP 模式，SOCKS5 可能更合适。然后选择所需 DNS 行为和到代理的连接保护，并用实际工作负载比较性能。
应使用服务为所选协议提供的真实主机名和端口。在配置中将 http:// 替换为 socks5://，不会让原本不提供 SOCKS 的服务器启用它。扩大规模前，应确认请求从预期代理发出，并确认代理故障时不会悄然触发非预期的直接连接。