【前言】
在讲解nginx正向代理https之前，我们先来解答几个小疑问。
1、nginx是什么？
Java同学肯定知道apache服务器，一个很牛，但是也很庞大的web服务器。能当web服务器的不仅仅只有apache，还有一个小巧轻快，高性能的家伙，它就是nginx。
百度百科的解释是：nginx是一个高性能的http和反向代理服务器，同时也提供了imap/pop3/smtp服务。其特点是占有内存少，并发能力强。在咱们大中华大陆地区，百度、京东、新浪、网易、腾讯、淘宝都用了nginx，可见它有多受大家的欢迎。
大家都知道它是一个反向代理服务器，其实它也可以作为一个正向代理服务器。虽然nginx官方并没有提供http connect方法，但是nginx扩展性特别好，有大佬造出了ngx_http_proxy_connect_module模块（点击可以去到对应的github）来支持http connet方法，如此一来，它就可以正向代理http以及https了。本文着只讲nginx正向代理https，其余的等有时间再更新吧。
2、什么是nginx正反向代理？
正向代理：客户发送请求给代理服务器，代理服务器代替客户把请求发送给服务器，即正向代理是代理的客户端。
反向代理：代理服务器将收集到的请求分发给服务器，服务器处理完请求将结果返回给代理服务器，再由代理服务器将结果返回给客户端，即反向代理是代理的服务端。
详细讲解nginx正反向代理可以看这里：看了这篇你就彻底了解nginx的正方向代理啦~
3、https是什么？
https其实就是http+tls/ssl的简称，tls从某种意义来说就是ssl3.1版本，ssl是在应用层和传输层中间加的一个套接层，即加密在传输层和应用层之间传输的数据。详情请点击这里：看完这篇你就了解HTTPS、TLS、SSL啦~
4、https建立连接过程是怎样的？
客户端发起https连接--->服务端发送证书-->客户端验证服务端发来的证书(验证证书-->生成随机数-->生成握手信息hash值)-->服务端接收随机数加密的信息-->服务端验证握手信息是否被篡改-->客户端验证服务端发送回来的握手信息，完成握手
详细连接过程可以看这里：HTTPS建立连接详细过程
5、为什么需要https代理？
了解完https连接过程后会你可能有一个疑问，我客户端为什么需要一个nginx的代理服务器去正向代理https呢？我输入了域名后，直接去DNS服务器获取服务端IP，然后直接连接它的443端口不就行了吗？对，你说的都对，但是，问题就出在“直接连接它的443端口”，如果我不能直接连接它的443端口呢？甚至，我如果连Ping都Ping不通服务端呢？那怎么办？这时候，你就需要一台能够代替你，去连接服务端的服务器了。
这个代理服务器，目前常见的有用apache搭建的代理服务器、用nginx搭建的代理服务器。今天这篇文章我只讲nginx代理服务器，这俩货到底有什么区别，谁更合适什么场景，之后有时间再进行详细讲解吧。
【正文】
HTTPS/HTTP的正向代理从客户端是否有感知可以分为以下两种：
普通代理：客户端在浏览器自己配置代理的端口和地址。
透明代理：客户端无需做代理设置，于客户而已是无感的，企业中的web网关设备就是如此。
HTTPS/HTTP的正向代理从代理服务器是否需要解密HTTPS可以分为以下两种：
隧道代理（透传）：只在TCP协议之上进行透传HTTPS流量，并不对流量进行解密分析，客户端相当于直接和目的服务器进行TLS/SSL交互。
中间人代理：看到中间人我瞬间联想到了中间人攻击，这个原理也可以说类似吧，代理服务器将客户端发来的HTTPS流量进行解密，对客户端利用自签名证书完成TLS/SSL握手，这个时候代理服务器拿到了客户端访问服务端的HTTPS流量内容，再和服务端完成正常的TLS/SSL交互。
注：这种情况客户端在TLS握手阶段实际上是拿到的代理服务器自己的自签名证书，证书链的验证默认不成功，需要在客户端信任代理自签证书的Root CA证书。所以过程中是客户端有感的。如果要做成无感的透明代理，需要向客户端推送自建的Root CA证书，在企业内部环境下是可实现的。
n ginx代理https的方式都属于透传，也就是透明传输，不对传输的流量（数据包）进行解密。
http connect 隧道
七层解决方案是在应用层来进行解决的，并不存在对数据包进行解密的一个过程。它需要通过http connect来建立一个隧道（通俗理解就是一个指定的用来连接的通道），这里需要在客户端配置https代理服务器的ip和端口。
具体连接过程如下：
1、客户端给代理服务器发送http connect请求，并将要访问的url一并发给代理服务器；
2、代理用客户端发来的url去到dns服务器找到对应的ip，连上443端口；
3、代理连上服务端443端口后，给客户端发送一个HTTP/1.1 200 Connection Established（即http200响应）；
4、此时客户端和代理服务器成功建立一个http connect隧道；
5、客户端发送https流量给到代理服务器，代理服务器直接将此https流量直接发送给到服务器；
至此，整个七层的http connect隧道就建立成功，换句话说就是成功搭建了nginx正向代理https服务。
流程图如下：
【nginx正向代理https七层方案配置】
在前言已跟大家介绍，nginx官方并未提供http connect方法，但是github上已有相关模块，可以自行下载安装ngx_http_proxy_connect_module。
【添加gx_http_proxy_connect_module模块步骤】
对于已经编译安装完的nginx环境，加入此模块步骤如下：
# 确定已安装git应用
[root@hobby ~]# yum install -y git
# 从git上下载此模块
[root@hobby ~]# git clone https://github.com/chobits/ngx_http_proxy_connect_module.git
# 确定模块下载存放的路径
[root@hobby ngx_http_proxy_connect_module]# pwd
/root/ngx_http_proxy_connect_module
# 停止nginx
[root@hobby ~]# systemctl stop nginx.
# 备份原nginx执行
[root@hobby ~]# cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak
# 进到nginx源代码文件夹
[root@hobby ~]# cd /root/nginx-1.16.0
# 然后生成makefile，为编译做准备
[root@hobby nginx-1.16.0]# ./configure --user=www --group=www --prefix=/usr/local/nginx --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-threads --add-module=/root/ngx_http_proxy_connect_module
# 进行编译，切记，不要安装，即不要make install
[root@hobby nginx-1.16.0]# make
# 将生成的nginx可执行文件拷贝到原来的位置，覆盖原来的文件
[root@hobby nginx-1.16.0]# cp objs/nginx /usr/local/nginx/sbin/nginx【七层方案nginx.conf文件配置】
server {
listen 443 ssl;
resolver 114.114.114.114;
proxy_connect;
proxy_connect_allow 443;
proxy_connect_connect_timeout 10s;
proxy_connect_read_timeout 10s;
proxy_connect_send_timeout 10s;
location / {
proxy_pass https://$host;
proxy_set_header Host $host;
}
}【中间人代理】
从传输层透传应用层的流量，那么可不可以不建立http connect，将域名直接dns解析到代理服务器呢？随着时代的变迁，技术的发展，nginx的更新，这一切当然是可以的~
nginx自战斗民族的老铁2004年发布以来，一直在不断的进步，到1.9.0版本开始支持ngx_stream_ssl_module模块了，编译安装并不会默认安装，需要带上--with-stream，yum会默认安装这个模块。
那么这个时候问题来了，没了http connect，要怎么做呢？首先，在内网中，将dns域名解析到代理服务器上，这个时候你会问，解析到代理服务器上？客户端发送的可是https流量，代理没有ca证书，怎么解开？怎么可能读取https里面的信息呢？这个问题问的非常有水平，作为一名还未入流的白帽子，第一想法就是，既然没有，那就造一个噻。代理服务器和客户端商量好，你只要信任我的证书，直接把https流量发送给我，我帮你（假装是你）传达给你想传达但又没法直接传达的人（即服务端）。至于如何自建ca证书，请移步这里：
具体流程请看下图：
【中间人代理https配置】
server {
listen 443 ssl;
server_name scwipe.cn;
ssl_certificate /etc/nginx/ca/scwipe.pem;
ssl_certificate_key /etc/nginx/ca/scwipe.key;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
location / {
proxy_redirect https://scwipe.cn/ /;
proxy_pass https://scwipe.cn;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
