HTTP CONNECT 隧道是怎么工作的？讲透网络中间层的那根"管道"
上个月我调一个对接接口，对方只接受 HTTPS 直连，但我的脚本部署在内网里，必须经过一个中转服务才能出去。开始我以为这事挺简单——把中转地址配上就行了。
结果跑起来，对面日志里全是"400 Bad Request"。我抓了一下中间那段流量，发现请求没走到对面服务器，在中转那一层就被扔了。翻了好半天文档，才意识到我少配了一个东西：HTTP CONNECT 隧道。
今天把这件事从头到尾讲清楚。
先说清楚一件事：HTTP 本身转发不了任意流量
很多人会有个误解——HTTP 不是能代理所有东西吗？我配一个中转地址，所有请求让它转就行了。
其实不行。
HTTP 协议设计出来的时候，是为了客户端和服务器之间传"半结构化文本"的。它有一套明确的请求方法（GET、POST、PUT、DELETE），有一套明确的首部（Header），还有响应码、响应体。这个设计是给"应用层"用的。
但你要转发一个 HTTPS 请求，问题来了：客户端要和对面的服务器做 TLS 握手，握手的数据是加密的。中转服务看不到里面的内容，怎么知道该转发给谁、转发到哪里？
对中转服务来说，它要解决的问题不是"转发"，而是"建一根透明的管道"。客户端和中转服务建一条 TCP 连接，客户端告诉中转服务"我要去对面"，中转服务就帮客户端和对面的服务器再建一条 TCP 连接，然后中转服务只负责把两边管道里的数据原样搬来搬去，自己不动内容。
这就是"隧道"的概念。
HTTP CONNECT 是干什么的
HTTP CONNECT 就是用来建这根隧道的。
它是一个 HTTP 方法，但用起来不像 GET/POST 那样去"拿数据"。它的语义很简单：
客户端说：“中转服务你好，我要和 target.com:443 建立连接，你帮我搭个桥。”
具体长这样：
CONNECT target.com:443 HTTP/1.1
Host: target.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz
中转服务收到这个请求，做两件事：
隧道一旦建立，中转服务就退化成一根纯字节管道。这个概念很关键。
完整流程：从客户端到对面服务器
把这个流程用一段伪代码串一遍会更清楚：
客户端 中转服务 对面服务器
|— TCP 握手 ——–>| |
|<– TCP 握手 OK ——| |
|— CONNECT 报文 —->| |
| |— TCP 握手 ——–>|
| |<– TCP 握手 OK ——|
|<– HTTP/1.1 200 OK —| |
| |
|<- 隧道建立成功，切换到 TLS 握手 ->| |
|— TLS ClientHello 字节流 —–>| |
| |— TLS ClientHello –>|
| |<- TLS ServerHello —-|
|<– TLS ServerHello 字节流 ——| |
| |
|<- TLS 握手完成，HTTP/2 业务流 ->| |
几个关键节点：
- 第 4 行：客户端发 CONNECT 报文。
- 第 5-7 行：中转服务自己去连对面服务器。这一步中转服务是"客户端"角色。
- 第 8 行：中转服务连上后给客户端回个 200。从这一刻开始，隧道就建好了。
- 第 10 行及之后：客户端和中转服务之间的这条连接，已经不是 HTTP 了。里面跑的是 TLS，中转服务完全看不见。
中转服务看到的是什么
隧道建立之后，中转服务只能看到两个东西：
它看不到：
- TLS 握手的内容（加密了）。
- HTTP/2 帧的内容（在 TLS 之上）。
- 你访问的是哪个 URL、什么路径、什么参数。
这就是为什么 HTTPS 配合 CONNECT 隧道能做到"端到端加密"——中转服务再强大，也只能看到一堆加密字节。
这点很重要，因为它直接关系到安全模型的边界：如果你担心中转服务偷窥你的请求内容，CONNECT 隧道能保证对面服务器的身份认证信息和加密密钥不会泄漏给中转服务。但它不能防止中转服务知道"你访问了哪个域名"——CONNECT 报文里的 Host 首部是明文的。
一个真实的小坑
我那次部署踩的坑，就出在这个地方。
我的脚本是 HTTP 客户端，发到中转服务的请求是 HTTP/1.1，POST 方法，目标是 https://api.example.com/data。代码里我以为配了中转地址就够了，结果对面对我返回 400。
抓包发现：客户端发的请求是明文 HTTP，没做 TLS 握手。原因是客户端以为"反正有中转服务加密"，结果中转服务只负责转发，不做 TLS 终结。TLS 必须由客户端自己和对面的服务器完成，中转服务只在中间搬运加密字节。
正确流程是：
代码层面大致长这样（伪代码）：
connect("proxy.example.com:8080")
send("CONNECT api.target.com:443 HTTP/1.1\\r\\nHost: api.target.com:443\\r\\n\\r\\n")
read_response() # 期待 "HTTP/1.1 200 OK"
# 隧道建好了，现在直接对 socket 做 TLS 握手，目标是对面服务器
tls = wrap_socket(socket, server_hostname="api.target.com")
tls.send(https_request_bytes)
很多 HTTP 客户端库（requests、aiohttp）会帮你做这件事，前提是你把中转地址配对。配错任何一个环节（比如把中转地址当成普通 HTTP 转发、忘了隧道建好再发请求），就会像我那样拿到 400。
还有一类常见场景：HTTPS 通过中转服务访问 HTTP
另一种常见用法：客户端在一个受限环境里，但允许通过中转服务出去。这时候客户端要访问 HTTP（明文）的目标，怎么办？
直接 CONNECT 目标 80 端口。流程是一样的：
CONNECT target.com:80 HTTP/1.1
隧道建好之后，客户端在隧道里发明文 HTTP 请求。中转服务只做字节流搬运，不会去看内容（理论上）。
实际中很多中转服务会做"CONNECT 后强制 HTTPS"的策略，避免被用来转发明文流量。这种情况下，中转服务会主动拒绝 CONNECT 到 80 端口的请求，或者在 200 OK 之后立即关掉连接。
写在最后
把今天说的串一下：
- HTTP 协议本身只能转发结构化的请求-响应，转发不了任意字节流。
- HTTP CONNECT 的作用是"建隧道"，让中转服务变成一根透明的字节管道。
- 隧道建好之后，里面跑什么协议（TLS、HTTP/2、自定义二进制）中转服务都看不见。
- 中转服务能看到 CONNECT 报文里的目标域名，但看不到 TLS 之后的内容。
- HTTPS 配合 CONNECT 是"端到端加密 + 隧道转发"的常见组合。
理解了这套机制，下次再配中转、踩 TLS 握手失败、隧道建立不上的坑，就能比较快地定位到问题在哪一步。
技术这东西，学的时候觉得是抽象的协议名，真出问题了才知道——一个 CONNECT 方法的差别，就是能不能通的区别。
