NGINX 主要设计作为反向代理服务器，但随着 NGINX 的发展，它同样能作为正向代理的选项之一。正向代理本身并不复杂，而如何代理加密的 HTTPS 流量是正向代理需要解决的主要问题。本文将介绍利用 NGINX 来正向代理 HTTPS 流量两种方案，及其使用场景和主要问题。

　　普通代理：在客户端需要在浏览器中或者系统环境变量手动设置代理的地址和端口如鱿鱼，在客户端指定鱿鱼服务器 IP 和端口 3128。

　　透明代理：客户端不需要做任何代理设置，“代理”这个角色对于客户端是透明的。如企业网络链路中的 Web Gateway 设备。

　　隧道代理：。也就是透传代理代理服务器只是在 TCP 协议上透传 HTTPS 流量，对于其代理的流量的具体内容不解密不感知客户端和其访问的目的服务器做直接 TLS / SSL 交互本文中讨论的 NGINX 代理方式属于这种模式。

　　中间人（MITM，Man-in-the-Middle）代理：代理服务器解密 HTTPS 流量，对客户端利用自签名证书完成 TLS / SSL 握手，对目的服务器端完成正常 TLS 交互。在客户端 - 代理 - 服务器的链路中建立两段 TLS / SSL 会话。如Charles，简单原理描述可以参考文章。

　　注：这种情况客户端在 TLS 握手阶段实际上是拿到的代理服务器自己的自签名证书，证书链的验证默认不成功，需要在客户端信任代理自签证书的根 CA 证书。所以过程中是客户端有感的。如果要做成无感的透明代理，需要向客户端推送自建的根 CA 证书，在企业内部环境下是可实现的。

　　作为反向代理时，代理服务器通常终结（终止）HTTPS 加密流量，再转发给后端实例.HTTPS 流量的加解密和认证过程发生在客户端和反向代理服务器之间。

　　而作为正向代理在处理客户端发过来的流量时，HTTP 加密封装在了 TLS / SSL 中，代理服务器无法看到客户端请求的 URL 中想要访问的域名，如下图。所以代理 HTTPS 流量，相比于 HTTP，需要做一些特殊处理。

　　根据前文中的分类方式，NGINX 解决 HTTPS 代理的方式都属于透传（隧道）模式，即不解密不感知上层流量。具体的方式有如下 7 层和 4 层的两类解决方案。

　　代理服务器利用 HTTP CONNECT 请求中的主机和端口与目的服务器建立 TCP 连接。

　　4.客户端和代理服务器建立起 HTTP CONNECT 隧道，HTTPS 流量到达代理服务器后，直接通过 TCP 透传远端目的服务器。代理服务器的角色是透传 HTTPS 流量，并不需要解密 HTTPS。

　　对于新安装的环境，参考正常的安装步骤和安装这个模块的步骤（），把对应版本的补丁打开之后，在 configure 的时候加上参数 - -add 模块= /路径/到/ ngx_http_proxy_connect_module，示例如下：

　　7 层需要通过 HTTP CONNECT 来建立隧道，属于客户端有感知的普通代理方式，需要在客户端手动配置 HTTP（S）代理服务器 IP 和端口。在客户端用 curl 加-x 参数访问如下：

　　既然是使用透传上层流量的方法，那可不可做成“4 层代理”，对 TCP / UDP 以上的协议实现彻底的透传呢？答案是可以的.NGINX 官方从 1.9.0 版本开始支持ngx_stream_core_module模块，模块默认不建立，需要配置时加上–with 流选项来开启。

　　用 NGINX stream 在 TCP 层面上代理 HTTPS 流量肯定会遇到本文一开始提到的那个问题：代理服务器无法获取客户端想要访问的目的域名。因为在 TCP 的层面获取的信息仅限于 IP 和端口层面，没有任何机会拿到域名信息。要拿到目的域名，必须要有拆上层报文获取域名信息的能力，所以 NGINX stream 的方式不是完全严格意义上的 4 层代理，还是要略微借助些上层能力。

　　要在不解密的情况下拿到 HTTPS 流量访问的域名北京代理服务器ip，只有利用 TLS / SSL 握手的第一个客户端 Hello 报文中的扩展地址 SNI（服务器名称指示）来获取.NGINX 官方从 1.11.5 版本开始支持利用ngx_stream_ssl_preread_module模块来获得这个能力，模块主要用于获取客户端 Hello 报文中的 SNI 和 ALPN 信息。对于 4 层正向代理来说，从客户端 Hello 报文中提取 SNI 的能力是至关重要的，否则 NGINX stream 的解决方案无法成立。同时这也带来了一个限制，要求所有客户端都需要在 TLS / SSL 握手中带上 SNI 字段，否则 NGINX stream 代理完全没办法知道客户端需要访问的目的域名。

　　NGINX stream 与 HTTP 不同，需要在流块中进行配置，但是指令参数与 HTTP 块都是类似的，主要配置部分如下：

　　对于 4 层正向代理，NGINX 对上层流量基本上是透传，也不需要 HTTP CONNECT 来建立隧道。适合于透明代理的模式，比如将访问的域名利用 DNS 解定向到代理服务器。我们可以通过在客户端绑定/ etc / hosts 中来模拟。

　　4 层正向代理是透传上层 HTTPS 流量，不需要 HTTP 连接来建立隧道，也就是说不需要客户端设置 HTTP（S）代理。如果我们在客户端手动设置 HTTP（S）代理是否能访问成功呢？我们可以用 curl -x 来设置代理为这个正向服务器访问测试，看看结果：

　　可以看到客户端试图于正向 NGINX 前建立 HTTP CONNECT 隧道，但是由于 NGINX 是透传，所以把 CONNECT 请求直接转发给了目的服务器。目的服务器不接受 CONNECT 方法，所以最终出现“Proxy CONNECT aborted”，导致访问不成功。

　　上文提到用 NGINX 流做正向代理的关键因素之一是利用 ngx_stream_ssl_preread_module 提取出客户端中的 SNI 字段。如果客户端客户端不携带 SNI 字段，会造成代理服务器无法获知目的域名的情况，导致访问不成功。

　　在透明代理模式下（用手动绑定承载的方式模拟），我们可以在客户端用的 OpenSSL 来模拟：

　　openssl s_client 默认不带 SNI，可以看到上面的请求在 TLS / SSL 握手阶段，发出客户端 Hello 后就结束了。因为代理服务器不知道要把客户端 Hello 往哪个目的域名转发。

　　本文总结了 NGINX 利用 HTTP CONNECT 隧道和 NGINX 流两种方式做 HTTPS 正向代理的原理，环境搭建，使用场景和主要问题，希望给大家在做各种场景的正向代理时提供参考。

　　现在，身份验证协议的数量快赶上应用程序协议，这让很多人感到困惑。本文详细阐述了三种不同的身份验证协议类别。

　　在一些大厂中，比如微博、蚂蚁金服，Service Mesh已经开始在实际项目中落地实践，而我建议你持续关注这项技术。

　　配网成功之后，我们还需要组网。零配置组网就是把工作自动化，不需要手动去操作，这个设备就可以与网络内的其他设备配合工作。

　　StackExchange 网站的一名用户 Matt Goforth 提出了一个问题，是否应当在负载均衡设备上将 SSL 进行卸载，他担心应用服务器收到的数据完整性是否会因此受到影响。而回贴的用户都赞成这种做法，并给出了相应的理由。

　　HTTP/2工作组主席Mark Nottingham在最近的一篇博客中，对WEB新标准的9件值得期待的事情发表了他的观点。目前WEB的新版本标准即将完成，新标准的实现也已经开始出现。

　　Kibana 是一种流行的开源可视化工具，专为与 Elasticsearch 结合使用而设计。

　　本文从Nginx的概念出发，分别从反向代理的概念、优势、配置代码3个方面介绍了Nginx的特性之一反向代理。

　　这是nginScript系列文章的第二篇，将介绍如何使用nginScript将客户端循序渐进地重定向到新的服务器。