分阶段看可能更简单。首先，在整个 HTTP 世界（没有 SSL）中，HTTP 请求是标头的集合，指示目标 URL，并通过 TCP 连接（通常在端口 80 上）发送。请求标头以“动词”开头，通常是 GET 或 POST。

当有代理时，将请求发送到代理；然后代理打开到目标服务器（或另一个代理）的连接并通过该新连接转发请求。响应遵循相同的路径，向后。

现在进入 SSL。SSL 与 HTTP 的耦合方式如下：一旦建立 TCP 连接，将执行 SSL 握手，在客户端和服务器之间建立加密隧道。HTTP 请求将在此隧道内发送。

当有代理时，希望与 SSL 驱动的服务器通信的客户端将发送 CONNECT 请求。该请求标识目标服务器名称和端口。然后代理连接到该服务器 (TCP) 并来回转发字节。SSL 握手发生在客户端和服务器之间；代理被保留在“外部”。代理（以及客户端和代理之间以及代理和服务器之间线路上的窃听者）仍然可以看到握手消息，从而知道正在联系哪个服务器（特别是通过Server Name Indication以及由服务器）。

碰巧代理本身也可能是 SSL 服务器。在这种情况下，客户端和代理之间的通信将自己封装在 SSL 隧道中。当客户端到代理的连接受 SSL 保护时，客户端和代理之间线路上的窃听者可以知道客户端正在与代理通信，但看不到请求和响应。特别是，他们无法知道最终目标服务器的身份。

这两个 SSL 不相关。这意味着一些相当大的混乱，因为当人们说“HTTPS代理”时，他们可能意味着两个不同的东西：

• 一个知道“CONNECT”动词并且能够将连接转发到最终的 SSL 驱动的目标服务器的代理；
• 一个代理，它本身就是一个 SSL 服务器，将与客户端进行 SSL，以在请求和响应在客户端和代理之间传输时保护它们。

这两个特征是相互正交的，这意味着你可能会得到一个，另一个，或两者兼而有之。如果两者都有，那么客户端实际上管理两个SSL 连接，一个嵌套在另一个中。

如果您想在客户端和代理之间击败窃听者，并且攻击者的目标是猜测您正在与之交谈的站点的身份，那么您需要一个支持 SSL 的代理，即本身支持 SSL 的代理; 您还需要一个支持 CONNECT 的代理，这样您就可以在 SSL 代理的保护下浏览 HTTP 和 HTTPS 网站。

由于给定的代理可能支持也可能不支持特定协议（至少在概念上，代理可能拒绝理解“CONNECT”请求），因此可以将 Web 浏览器配置为根据他们想要使用的协议类型使用不同的代理。在您的情况下，这只会增加混乱。

另一种方法是使用 SOCKS 代理。这很容易使用SSH进行设置。使用 SSH 驱动的 SOCKS 代理，从浏览器发出的所有通信都将通过客户端计算机和代理服务器之间的 SSH 隧道。