通常，当通过代理完成 HTTPS 时，这是通过CONNECT机制完成的：客户端与代理对话并要求它为与目标系统的字节提供双向隧道。在这种情况下，客户端看到的证书实际上来自服务器，而不是来自代理。在这种情况下，代理保留在 SSL/TLS 会话之外——它可以看到一些 SSL/TLS 正在发生，但它无法访问加密密钥。

一些组织通过动态为目标服务器生成假证书来实施完整的中间人。他们这样做是为了让代理可以看到明文数据并对其进行扫描以符合组织策略（例如自动防病毒扫描）。这只有在客户端（您的浏览器）接受假证书为真时才有效，这反过来又需要在客户端计算机上推送一个特殊的组织控制的根 CA（在 Windows / Active Directory 世界中，GPO 可以做到那）。

大约所有主要的防火墙/代理设备供应商都提供该机制作为选项。

并非所有组织都部署了这样的中间人系统，原因有几个，包括：

• 自动中间人可能很昂贵。如果有很多用户，代理设备可能必须具有强大的计算能力；并且产品许可证可以很高。

• MitM 破坏了基于证书的客户端身份验证。

• 仅当您实际检查数据时才有意义，这再次增加了计算成本。

• 根 CA 的自动推送不适用于BYOD。

• 通常，用户真的不喜欢这样的 MitM。

从 1.1 版开始，HTTP 支持一种特殊的方法，CONNECT。这会通过代理设置 TLS 隧道，即使您的计算机仅直接连接到代理。即使通过代理，HTTPS 也知道如何通过隧道传输 TLS 握手。

参见维基百科：

CONNECT 方法将请求连接转换为透明的 TCP/IP 隧道，通常是为了通过未加密的 HTTP 代理促进 SSL 加密通信 (HTTPS)。

更多细节在这里：

在 HTTP 代理服务器后面时，HTTP 隧道的一种变体是使用“CONNECT”HTTP 方法。
在这种机制中，客户端要求 HTTP 代理服务器将 TCP 连接转发到所需的目的地。然后服务器继续代表客户端建立连接。一旦服务器建立了连接，代理服务器将继续代理与客户端之间的 TCP 流。请注意，只有初始连接请求是 HTTP - 之后，服务器只是代理已建立的 TCP 连接。
这种机制是 HTTP 代理后面的客户端如何使用 SSL（即 HTTPS）访问网站。

但请注意这个警告：

并非所有 HTTP 代理服务器都支持此功能，甚至那些支持此功能的服务器也可能会限制该行为（例如，仅允许连接到默认 HTTPS 端口 443，或阻止似乎不是 SSL 的流量）。