当通过HTTP代理访问HTTPS站点时，客户端无法把请求直接交给代理然后等待转发，因为HTTPS的TLS加密使得代理无法读取请求内容，更不知道要连接的目标主机和端口。为了解决这个问题，HTTP/1.1引入了CONNECT方法。客户端首先向代理发送一个形如CONNECT ippipp.com:443 HTTP/1.1的请求，要求代理在自身和目标服务器之间建立一条原始TCP隧道。一旦代理返回200 Connection Established，这条连接就变成了一条透明的管道，客户端随后可以在上面进行TLS握手和应用数据的传输。在Ruby的HTTPX库中，这一机制被封装在HTTPX::Plugins::Proxy::HTTP模块中，让开发者可以像使用普通请求一样方便地通过代理访问HTTPS资源。
CONNECT 方法在 HTTP 代理中的核心作用
理解CONNECT方法，首先要清楚它和普通代理请求的区别。对于普通的HTTP请求，代理服务器收到后可以解析请求行和头部，根据Host字段将请求转发到目标服务器，然后把响应原路返回。这种模式下代理扮演的是中间人的角色，能够缓存、过滤甚至修改内容。但到了HTTPS场景，如果继续使用传统的GET/POST方式，代理将面对的是一段无法理解的密文，无法知道要发给谁，也就无法工作。CONNECT方法的出现正是为了弥补这一缺口。
CONNECT请求的格式非常简单，它的请求目标不再是路径，而是一个主机名加端口号：CONNECT www.ipipp.com:443 HTTP/1.1。代理接收到这个请求后，会尝试与目标主机建立一个TCP连接。如果连接成功，代理就返回一个200 Connection Established状态码，并在此后的传输中扮演透明转发器的角色，不再对内容进行任何解析。从客户端的角度看，就好像直接与目标服务器建立了TCP连接一样，后续的TLS握手数据会原封不动地通过代理透传。这一特性让CONNECT方法不仅限于HTTPS，任何需要端到端加密或自定义协议的通信（例如WebSocket over TLS）都可以借由HTTP隧道来完成。
从协议层次来看，当CONNECT隧道建立后，客户端与目标服务器之间的所有数据都由这条隧道的两端自行处理，代理只是在中间做二进制拷贝。这就意味着，如果客户端和目标服务器协商使用了HTTP/2或HTTP/3，只要它们能将数据打包进这条TCP连接，代理便无需关心。不过，这也对代理的性能和可靠性提出了要求：代理必须保持长连接，且不能对数据流添加任何额外行为（如分块传输编码修改），否则会破坏TLS握手。HTTPX的代理实现正是严格遵循这一原则，确保隧道建立后完全透明，没有副作用。
HTTPX 中代理插件的加载与基础配置
HTTPX作为Ruby生态中高性能的HTTP客户端库，通过插件系统扩展功能。要使用HTTP代理，需要加载:proxy插件。在构建会话时，可以通过http选项指定一个或一组代理地址：HTTPX.plugin(:proxy).with_proxy(uri: "http://proxy-server:8080")。这样，后续所有通过该会话发出的请求都会经过指定的代理。HTTPX内部会依据请求的scheme自动选择使用普通代理转发还是使用CONNECT隧道：当请求的目标是http://时，直接构造标准的HTTP请求发送给代理；当目标是https://时，则自动触发隧道建立流程。
代理配置可以非常灵活。除了在会话级别全局指定外，还允许按请求单独指定：session.with_proxy(uri: "http://proxy2:3128").get("https://ipipp.com")。此外，HTTPX支持通过环境变量HTTP_PROXY、HTTPS_PROXY、NO_PROXY自动识别系统代理设置，也可以从一个字符串列表或一个复杂的哈希结构加载多个代理并实现故障切换。所有这些配置信息最终都会传递给内部的HTTPX::Options对象，并在建立连接时由代理插件读取。开发者无需关心底层实现，只要正确设置scheme和地址，HTTPX就会处理好后续的协议选择与隧道协商。
下面是一段典型的初始化代码，展示如何创建一个带有HTTP代理的会话并发送HTTPS请求：
require 'httpx'
# 加载proxy插件并指定HTTP代理地址
session = HTTPX.plugin(:proxy).with_proxy(uri: "http://127.0.0.1:8888")
response = session.get("https://ipipp.com")
puts response.status
值得注意的是，这里的代理地址只负责建立隧道，所有发送给ipipp.com的数据仍然是加密的，代理无法解密。如果还需要代理认证（比如Basic认证），可以在URI中附带用户名和密码：http://user:pass@proxy:8888，或者通过no_proxy排除某些域名不走代理。这些配置最终都会由插件解析并应用在CONNECT请求的Proxy-Authorization头部中。
HTTPX::Plugins::Proxy::HTTP 的 CONNECT 实现细节
当HTTPX决定对一个HTTPS请求使用代理时，实际负责建立隧道的是HTTPX::Plugins::Proxy::HTTP模块。该模块重写了连接的建立逻辑。在HTTPX的架构中，每个请求会经过一个连接管理器的调度，当请求需要代理时，连接管理器会尝试获取一个到代理服务器的连接，而不是直接连接目标。接着，代理相关的插件会在该连接上发送一个CONNECT请求。我们来看看源码中的关键流程：首先，模块会检查传入的URI是否包含http代理的配置，然后构造一个CONNECT host:port HTTP/1.1的请求头，并将Proxy-Authorization等必要的头部附加上去。
具体来说，构造CONNECT请求的主要逻辑集中在Proxy::HTTP#connect方法或其等效的底层实现中。它会创建一个符合RFC 7231的请求行，设置Host头为代理服务器的主机（不是目标服务器），而目标信息仅出现在请求行本身。发送请求后，代码会进入一个读取阶段，等待来自代理的响应。如果返回的状态码是200，就表示隧道建立成功，此时该连接的状态会被标记为已建立隧道，后续的读写操作将直接关联到目标服务器的数据流。如果代理返回407（需要代理认证）或其他错误，则会抛出相应的异常。
下面的简化伪代码展示了核心步骤：
# 假定在 Proxy::HTTP 模块内部
def connect(connection, uri, options)
# 建立到代理服务器的 TCP 连接
proxy_conn = establish_tcp_connection(proxy_host, proxy_port)
# 构造 CONNECT 请求
request = "CONNECT #{uri.host}:#{uri.port} HTTP/1.1rn"
request << "Host: #{proxy_host}rn"
if proxy_user && proxy_pass
auth = Base64.strict_encode64("#{proxy_user}:#{proxy_pass}")
request << "Proxy-Authorization: Basic #{auth}rn"
end
request << "rn"
proxy_conn.write(request)
# 读取响应
response = proxy_conn.read_until("rnrn")
status = parse_status(response)
raise "Tunnel establishment failed" unless status == 200
# 从此刻起 proxy_conn 就是目标服务器的隧道
proxy_conn
end
一旦隧道建立，HTTPX就会在这个原始连接上发起TLS握手。对于库的TLS层来说，它看到的只是一个普通的Socket，完全察觉不到中间经过了代理。这种设计使得HTTPX可以在不修改核心HTTP解析逻辑的前提下，无缝支持通过代理访问HTTPS。同时，这套机制也被复用在其他需要建立二进制的场景中，比如当使用h2c通过HTTP代理进行HTTP/2升级时，也会优先建立CONNECT隧道。
隧道生命周期管理与常见问题排查
HTTPX对隧道连接的管理是自动的。当HTTPS请求完成后，这条隧道连接并不会立即关闭，而是会放回连接池中，以便后续对同一个目标主机和端口的请求复用。连接池会根据keep_alive_timeout等设置决定何时真正关闭空闲连接。如果目标主机发生变更，则需要重新建立隧道。这种复用机制显著减少了TLS握手和代理协商的开销。开发者可以通过调整会话的max_concurrent_requests和timeout参数来控制并发和超时行为，但是需要注意，代理服务器本身也可能对隧道连接的数量或持续时间做出限制。
在实际使用中，可能会遇到一些常见问题。例如，代理返回400 Bad Request：这往往是因为CONNECT请求中携带了不符合规范的头部，或者是代理只允许连接特定的端口（如443、563等），其它端口被防火墙拦截。解决方法是检查代理服务配置，或在不必要的时候尝试关闭隧道行为（但HTTPS必须使用隧道）。另一个典型错误是502 Bad Gateway，通常意味着代理能够连接到目标主机，但目标主机拒绝了连接，或者目标主机的端口没有在侦听。
调试这类问题时，可以开启HTTPX的日志功能。在会话创建时传入debug_level: 2或设置全局的HTTPX.debug，就能看到完整的请求/响应头部以及连接建立过程。对于更底层的网络问题，可以使用tcpdump或Wireshark抓包，观察CONNECT请求是否成功发出以及代理的响应内容是否正常。如果代理需要认证，务必确认Proxy-Authorization头部的编码是否正确，有些代理使用NTLM或Digest认证，这时可能需要额外的插件支持。HTTPX目前原生支持Basic代理认证，其他认证方式可以通过自定义中间件或直接扩展Proxy::HTTP模块来实现。
最后，从安全的角度考虑，通过HTTP代理建立的隧道本质上是传输层安全的一个中间环节。如果代理本身不受信任，那么它虽然无法解密TLS流量，但可以观察到客户端与哪些HTTPS站点建立了连接（因为CONNECT请求中的主机名是明文的），同时也可以中断或篡改连接尝试。因此，在生产环境中使用代理时，应该优先选用受控的内部代理，并启用严格的TLS证书校验，防止中间人攻击。HTTPX默认会验证服务器证书，这为端到端安全提供了一层基础保障。
Ruby_HTTPXCONNECT方法HTTP代理隧道修改时间：2026-08-12 09:01:19