HTTPS 经过 HTTP 代理时发生了什么？看懂 CONNECT 隧道

在浏览器或系统里填写 HTTP 代理后，访问 HTTPS 网站并不是把加密网页内容直接交给代理改写。常见做法是先向代理发送 CONNECT 请求，请它建立到目标主机和端口的 TCP 隧道，再由客户端与目标站点完成 TLS 握手。

CONNECT 请求解决什么问题

RFC 9110 的 CONNECT 章节规定，客户端用请求目标中的主机名和端口，请代理建立隧道。代理返回 2xx 后，后续数据进入盲转发阶段；客户端发送的 TLS 握手和加密内容通过这条隧道传输。

因此，“HTTP 代理端口”描述的是客户端如何与本地或上游代理交互，不等于目标 HTTPS 网站退化成明文 HTTP。是否安全仍取决于客户端对目标证书的校验，以及中间是否存在用户明确安装并信任的解密证书。

为什么错误常出现在 TLS 之前

访问 HTTPS 网站通常经历：解析代理地址、连接代理、发送 CONNECT、代理连接目标、建立隧道、执行 TLS 握手、发送 HTTP 请求。任一阶段失败，表面上都可能只显示“代理连接失败”。

常见区分方法：

1. 连接代理端口就被拒绝，先查本地客户端是否监听、端口类型是否填对。
2. 收到 407，表示代理要求认证，应核对代理凭据，而不是网站账号。
3. CONNECT 返回非 2xx，查看代理响应与目标端口限制。
4. 隧道成功后出现证书错误，继续核对系统时间、目标主机名和证书链。

用 curl 观察隧道阶段

在确认本地 HTTP 代理端口后，可用详细输出观察连接流程。不要在要分享的截图中暴露代理用户名、密码、订阅地址或令牌。

curl.exe --verbose --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com/

输出中若出现 CONNECT example.com:443 与成功的 2xx 响应，说明隧道建立阶段通过；之后的 TLS 和目标响应仍需分别判断。--head只请求响应头，不代表所有网站都支持，也不能代替实际业务测试。

端口名称不能代替实际验证

许多机场客户端同时提供 HTTP、SOCKS5 和 mixed 端口。把 SOCKS5 端口误填成 HTTP 代理，客户端与代理的首个报文格式就不匹配。反过来也一样。应以客户端界面或配置中的实际端口类型为准。

CONNECT 解释了 HTTPS 经过 HTTP 代理时的基础通道，但不直接证明流量最终走哪个机场节点、DNS 在哪里解析或 UDP 是否受支持。要判断这些问题，还需结合客户端规则、连接日志与实际出口做独立验收。