代理协议IETF RFC 9110 标准本地 http_proxy 基石

HTTP CONNECT 代理

应用层通用 Web 隧道 · 200 Connection Established · 系统全局与终端代理基石

基于 IETF RFC 2817 与 RFC 9110 标准化的 HTTP CONNECT 隧道代理机制[1]。 允许客户端指示代理服务器与目标服务器建立一条端到端的不透明双向 TCP 通道, 是整个现代万维网安全访问 HTTPS 资源的核心基础,也是操作系统全局代理与开发终端环境变量(http_proxy)的最通用承载者[2]。

标准化组织IETF HTTP 工作组
核心标准2000.05.01
核心动词CONNECT authority HTTP/1.1
生态定位系统全局代理与终端 http_proxy 环境变量基石

日期辨析:1999 年 6 月 RFC 2616 记录 CONNECT vs 2000 年 5 月 RFC 2817 成为标准

RFC 2616 首次记录 CONNECT 动词1999.06.01

IETF 在 HTTP/1.1 规范中正式定义 CONNECT 方法,用于请求网关切换为盲目双向透明 TCP 管道。

RFC 2817 标准化 TLS 隧道机制2000.05.01

发布 RFC 2817,正式规范客户端如何利用 CONNECT 穿透企业代理并建立安全的端到端 HTTPS 会话。

RFC 9110 现代 HTTP 语义定稿2022.06.01

发布最新的核心标准 RFC 9110,在第 9.3.6 节系统性重构和标准化 CONNECT 隧道的生命周期与响应行为。

编写口径:所有时间节点严格以 IETF 官方 RFC 文档发布日期为权威依据。

词条概览与核心定位

01

在 Web 诞生的最初几年,HTTP 代理服务器充当的是内容缓存与明文请求转发的角色(如针对 GET、POST 请求做就近缓存)。 然而随着全网对数据安全与端到端加密的诉求提升,HTTPS(HTTP over TLS)迅速普及。 由于代理服务器无法、也不应该解密用户的加密会话,传统的明文代理模式遭遇了根本性失效。

为了在保护加密完整性的同时允许企业与个人跨越网关, IETF 在 RFC 2616 与 RFC 2817 中正式确立了 CONNECT 方法[2]: 客户端向代理服务器发出一条纯文本的指令 CONNECT example.com:443 HTTP/1.1, 代理服务器连接目标后,返回 HTTP/1.1 200 Connection Established 状态码。 从那一刻起,该 TCP 连接退化为一个盲目的、不透明的原始字节流管道, 客户端与目标服务器在管道内直接展开 TLS 握手并传输加密数据[1]。

定位结论

HTTP CONNECT 代理是现代计算机网络中兼容性最高、渗透最深的基础设施机制。 尽管因其握手头部包含明文 ASCII 域名而绝对不能在跨境公网裸跑, 但它与 SOCKS5 共同构成了现代所有翻墙客户端在本机向系统暴露的不可或缺的双重入站接口。

握手流程与隧道透传架构

02
1. CONNECT 动词请求与身份鉴权客户端向代理服务器发送 CONNECT authority HTTP/1.1, 可选携带 Proxy-Authorization: Basic [Base64] 头进行代理鉴权[1]。
2. 200 Connection Established 管道确立代理服务器在后台与目标主机完成 TCP 三次握手后,向客户端回写标准的 HTTP 200 状态行与空行。 此后代理服务器停止解析后续数据,转为全双工零拷贝字节搬运。
3. 端到端 TLS 握手与数据流穿透客户端立即在已建立的透明 TCP 通道内发送真正的 TLS ClientHello, 与目标服务器直接进行证书核验与会话密钥协商,代理服务器完全无法读取明文载荷[3]。

HTTP CONNECT 握手全状态流转

  1. 客户端发起隧道建立:发送明文请求 CONNECT api.github.com:443 HTTP/1.1\r\nHost: api.github.com:443\r\n\r\n。
  2. 代理建连与确认返回:代理完成对目标 IP 的 DNS 解析并成功连接目标 443 端口,回写 HTTP/1.1 200 Connection Established\r\n\r\n。
  3. 切换为透明流管道:双方正式进入不透明流传输状态,直到任一方发送 TCP FIN 关闭连接,代理释放套接字资源。

GFW 审查机制与公网裸奔红线

HTTP CONNECT 握手首行包含了纯文本的目标主机名与端口。 如果将未加密的 HTTP 代理直接部署在海外服务器并供国内访问,GFW 的深度包检测设备可以在几微秒内读取 CONNECT 首行, 对未备案域名或受阻断目标直接注入虚假 TCP RST 并将服务端 IP 列入临时黑名单。

版本演进时间线(共 6 个关键节点)

03

以下时间线记录了 HTTP CONNECT 机制从 1999 年 HTTP/1.1 提出、TLS 隧道标准化、HTTP/2 多路复用扩展到现代 RFC 9110 的历史全景:

纪事

1999 年 - 2000 年:从普通缓存代理到端到端加密穿透

  • IETF 发布 RFC 2616,记录 CONNECT 动词

    在 HTTP/1.1 规范中正式收录 CONNECT 方法,允许客户端向代理服务器发起端到端 TCP 隧道请求。

    IETF RFC 2616 §9.9 CONNECT
  • IETF 发布 RFC 2817,确立 TLS 隧道规范

    规范了客户端通过 CONNECT 与远端服务器协商 TLS 的完整生命周期,使 HTTPS 能够穿透任何企业防火墙与代理。

    IETF RFC 2817 规范文件
纪事

2015 年 - 2018 年:多路复用扩展与科学上网混合入站

  • IETF 发布 RFC 7540,HTTP/2 引入多路复用隧道

    在二进制分帧的 HTTP/2 中扩展 CONNECT,允许在单一 TCP 连接上并发开辟多个独立的隧道流。

    IETF RFC 7540: HTTP/2 规范
  • 翻墙客户端(Clash / Surge)普及 Mixed Port 混合代理

    通过在本地同一端口兼顾 SOCKS5 与 HTTP CONNECT,终端用户仅需配置一次 http_proxy 即可接管所有开发环境。

    Clash 项目历史架构演进
纪事

2022 年 - 2026 年:语义重构与 MASQUE UDP 演进

  • IETF 正式发布 RFC 9110 (HTTP Semantics)

    替代历史 RFC 7231,在第 9.3.6 节系统性重写 CONNECT 隧道的权威语义规范与错误处理准则。

    IETF RFC 9110 官方规范
  • IETF 发布 RFC 9298,CONNECT-UDP 延伸至数据报中继

    MASQUE 工作组将 CONNECT 语义从纯 TCP 字节流正式推广到 UDP 数据报中继,开启下一代现代代理新纪元。

    IETF RFC 9298 (CONNECT-UDP)

生态实现与客户端兼容性

04

HTTP CONNECT 享有现代 Web 体系最高级别的通用性,所有命令行工具与浏览器皆原生内置支持。

软件 / 内核类型支持平台支持级别起始版本发布日期特性说明
全平台主流浏览器 (Chrome / Safari / Firefox)客户端Windows, macOS, Linux, iOS, Android官方原生支持全版本内置1999.06.01操作系统网络设置中的“HTTP / HTTPS 代理”均无一例外采用标准的 CONNECT 隧道。
cURL / Git / Wget客户端全平台开发环境官方原生支持全版本内置1998.03.20通过 http_proxy / https_proxy 环境变量天然继承并使用 HTTP CONNECT 隧道发起请求。
Mihomo (Clash Meta)核心内核全平台官方参考入站v1.0.0+2022.01.15本地混合端口同时支持 HTTP CONNECT 与 SOCKS5,智能识别首包并按规则分流。
sing-box核心内核全平台官方参考入站v1.0.0+2022.07.18极低内存占用的原生 HTTP 代理入站实现,支持 Basic 鉴权与精准流量嗅探。
Squid Caching Proxy核心内核Linux, Unix, BSD经典企业级代理2.0+1998.07.28全球部署最广泛的企业前置代理服务器,具备详尽的 CONNECT 访问控制列表(ACL)控制。

适用场景、网络边界与部署建议

05

最佳适用场景

终端开发环境变量:在终端中执行 export http_proxy=http://127.0.0.1:7890,令 Git、npm、pip、Homebrew 一键翻墙; 操作系统全局网络代理:Windows、macOS 与 GNOME 的图形化代理设置主要依赖 HTTP / HTTPS 代理标准; 老旧系统与轻量脚本:很多极简嵌入式环境或 Python 脚本原生不包含 SOCKS5 库,但 100% 支持 HTTP CONNECT。

网络边界与安全注意事项

原生不支持 UDP 数据报:传统 HTTP CONNECT 只能承载 TCP 流,无法中继在线语音、FPS 电竞加速等 UDP 流量; 明文 ASCII 严禁公网直连:绝对不可在海外云服务器上裸跑开放 8080 端口给境内直连,会在数秒内被深度包检测拦截; 代理泄露与鉴权安全:明文 HTTP 代理如果开放公网且缺乏复杂强密码鉴权,会迅速被全网扫描器发现并沦为肉鸡爬虫中继。

第一手文献与官方参考资料

06

词条事实与技术定义均以 IETF RFC 官方文献与 W3C 规范为准:

  1. [1]RFC 9110: HTTP Semantics (Section 9.3.6 CONNECT)IETF 最权威的现代 HTTP 语义规范,详细阐释了 CONNECT 隧道建立、首部清理与双向字节管道行为。https://www.rfc-editor.org/rfc/rfc9110
  2. [2]RFC 2817: Upgrading to TLS Within HTTP/1.1确立了代理隧道内进行端到端 TLS 握手的历史经典标准。https://www.rfc-editor.org/rfc/rfc2817
  3. [3]MDN Web Docs: HTTP 代理服务器与 CONNECT 隧道工作机制Mozilla 官方开发者网络对正向代理、反向代理与隧道代理差异的图文解析。https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling
  4. [4]RFC 9298: Proxying UDP in HTTP (CONNECT-UDP)MASQUE 工作组标准,展现了 CONNECT 方法从传统 TCP 代理向现代 UDP/QUIC 代理的技术演进。https://www.rfc-editor.org/rfc/rfc9298