CONNECT 让代理开路
CONNECT 请求代理服务器替客户端与目标主机建立一条 TCP 隧道，隧道建好后这条连接上只传输字节流，代理不再解析内容。它最典型的用途是让 HTTPS 流量穿越正向代理：客户端先用 CONNECT 打通到目标 443 的通道，再在这条通道里完成 TLS 握手。正因为代理此时变成了通用转发器，出于安全考虑通常只允许连接白名单端口，绝大多数场景只放行 443。
基本信息
| 方法名 | CONNECT |
|---|---|
| 作用 | 经代理建立到目标主机与端口的字节流隧道 |
| 规范 | RFC 9110 第 9.3.6 节 |
| 响应 | 2xx 表示隧道建立成功，常见 200 Connection Established |
| 版本差异 | HTTP/1.1 使用 CONNECT 方法；HTTP/2 通过扩展 CONNECT 实现，见 RFC 8441 |
| 权限要求 | 由代理决定目标与端口的白名单，属于代理策略而非协议限制 |
隧道请求与客户端用法
隧道请求与客户端用法
# 直接与代理对话：请求打通到目标 443 的隧道
printf 'CONNECT www.example.com:443 HTTP/1.1\r\nHost: www.example.com:443\r\n\r\n' | nc proxy.example.com 3128
# HTTP/1.1 200 Connection Established # 隧道建立成功，之后是纯字节流
curl -v -x http://proxy.example.com:3128 https://www.example.com/ 2>&1 | grep -iE 'CONNECT|established'
curl -v -x http://proxy.example.com:3128 -p --proxytunnel telnet://10.0.0.9:8080 # 非 443 端口的隧道用法应答与排障
| 应答 | 含义 | 排查方向 |
|---|---|---|
| 200 Connection Established | 隧道建立成功 | 之后按 TLS 握手继续看，代理不再参与 |
| 403 Forbidden | 代理拒绝该目标或端口 | 核对代理的白名单与端口策略 |
| 407 Proxy Authentication Required | 代理要求认证 | 按 Proxy-Authenticate 提示补充代理凭据 |
| 502 Bad Gateway | 代理无法连上目标 | 检查目标可达性与代理的出网策略 |
| 无应答或超时 | 连代理本身都不通 | 确认代理地址与端口是否可达 |
典型使用场景
- 企业内网通过正向代理访问外网 HTTPS 站点
- 排查代理环境下的证书与握手问题，确认隧道是否真的建立成功
- 客户端工具配置代理时验证代理是否支持隧道方式
- 识别代理日志里的 CONNECT 记录，判断流量走向与目标分布
- 评估代理策略安全性，检查是否被放开了通配端口
2xx 之后连接上只会传输字节流，代理不再解析内容，因此它无法缓存或改写隧道内的 HTTPS 内容。反过来说，用户与目标之间的加密内容对代理是不可见的，日志里通常只能看到目标域名与端口。
代理如果允许 CONNECT 到任意端口，就等于对外开放了通用 TCP 转发能力，既可能被滥用穿透内网，也会带来合规风险，应严格限制目标与端口。