阿里云国际版如何使用NGINX作为HTTPS转发代理服务器

NGINX最初被设计为反向代理服务器。但是，随着不断发展，NGINX也可以作为实现转发代理的选项之一。转发代理本身并不复杂，它解决的关键问题是如何加密HTTPS流量。本文介绍了使用NGINX作为HTTPS流量转发代理的两种方法，以及它们的应用场景和主要问题。

今天87cloud详谈下阿里云国际如何使用NGINX作为HTTPS转发代理服务器

HTTP/HTTPS 转发代理的分类

首先，让我们仔细看看转发代理的分类。

分类依据：代理对客户是否透明

• 通用代理：在这里，代理地址和端口是在客户端上的浏览器或系统环境变量中手动配置的。例如，当您在客户端上指定 Squid 服务器的 IP 地址和端口 3128 时。
• 透明代理：客户端上不需要代理设置。“代理”角色对客户端是透明的。例如，企业网络上的 Web 网关设备是透明代理。

分类依据：代理是否加密HTTPS

• 隧道代理：这是一个透明传输流量的代理。代理服务器专门通过 TCP 透明地传输 HTTPS 流量。它不会解密或感知其代理流量的特定内容。客户端与目标服务器执行直接 TLS/SSL 交互。本文介绍了与此类型相关的NGINX代理模式。
• 中间人 （MITM） 代理：代理服务器解密 HTTPS 流量，使用自签名证书完成与客户端的 TLS/SSL 握手，并完成与目标服务器的正常 TLS 交互。在客户端-代理-服务器链接上设置了两个 TLS/SSL 会话。

注意：在这种情况下，客户端在TLS握手过程中实际获取了代理服务器的自签名证书，默认情况下证书链的验证不成功。代理自签名证书中的根 CA 证书必须在客户端上受信任。因此，客户端知道此过程中的代理。如果将自签名根 CA 证书推送到客户端（在企业的内部环境中实现），则可实现透明代理。

转发代理处理 HTTPS 流量时需要特殊处理

在充当反向代理时，代理服务器通常会终止 HTTPS 加密流量并将其转发到后端实例。HTTPS 流量的加密、解密和身份验证发生在客户端和反向代理服务器之间。

另一方面，当充当转发代理并处理客户端发送的流量时，代理服务器不会在客户端请求的URL中看到目标域名，因为HTTP流量已加密并封装在TLS / SSL中，如下图所示。因此，与 HTTP 流量不同，HTTPS 流量在代理实现期间需要一些特殊处理。

NGINX解决方案

根据前面几节中的分类，当NGINX用作HTTPS代理时，代理是透明的传输（隧道）代理，既不解密也不感知上层流量。具体来说，有两种NGINX解决方案可用：第7层（L7）和第4层（L4）。以下各节详细介绍了这些解决方案。

HTTP 连接隧道 （L7 解决方案）

历史背景

早在1998年TLS还没有正式上市的时候，推广SSL协议的网景就提出使用Web代理进行SSL流量的隧道。核心思想是使用HTTP CONNECT请求在客户端和代理之间建立HTTP CONNECT隧道。CONNECT 请求必须指定客户端需要访问的目标主机和端口。互联网草案中的原始图表如下：

有关整个过程的详细信息，请参阅 HTTP：权威指南中的图表。以下步骤简要概述了该过程。

1） 客户端向代理服务器发送 HTTP CONNECT 请求。
2） 代理服务器使用 HTTP CONNECT 请求中的主机和端口信息与目标服务器建立 TCP 连接。
3） 代理服务器向客户端返回 HTTP 200 响应。
4） 客户端与代理服务器建立 HTTP CONNECT 隧道。在 HTTPS 流量到达代理服务器后，代理服务器通过 TCP 连接透明地将 HTTPS 流量传输到远程目标服务器。代理服务器仅透明地传输 HTTPS 流量，不解密 HTTPS 流量。