nginx之proxy_pass代理后端https请求完全拆解原_proxy_pass https

获取SSL服务端证书

你可以从一个可信证书颁发机构(CA)购买一个服务器证书, 或者你可以使用openssl库创建一个内部CA，并给自己颁发证书。这个服务器端证书和私钥需要部署在后端的每一个服务器上。
获取SSL客户端证书

nignx使用一个SSL客户端证书来对后端服务器组来标识自己。这个客户端证书必须是被一个可信CA签名的，并且和相匹配的私钥一起部署在nginx中。
你还需要在后端服务器上配置好所有的来源SSL连接都需要客户端证书，并信任这个CA颁发的nginx客户端证书。然后当nginx连接后端时，将提供客户端证书，并且后端将会接收这个连接。
配置nginx

首先，改变相应URL到支持SSL连接的后端服务器组。在nginx的配置文件中，指明proxy_pass指令在代理服务器或后端服务器组中使用"https"协议:
location /upstream {
    proxy_pass https://backend.example.com;
增加客户端证书和私钥，用于验证nginx和每个后端服务器。使用proxy_ssl_certificate 和 proxy_ssl_certificate_key指令: 
location /upstream {  
    proxy_pass                https://backend.example.com;  
    proxy_ssl_certificate     /etc/nginx/client.pem;  
    proxy_ssl_certificate_key /etc/nginx/client.key  
如果你在后端服务器使用了自签名证书或者使用了自建CA，你需要配置proxy_ssl_trusted_certificate. 这个文件必须是PEM格式的。另外还可以配置proxy_ssl_verify和proxy_ssl_verfiy_depth指令， 用来验证安全证书： 
location /upstream {
    proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt;
    proxy_ssl_verify       on;
    proxy_ssl_verify_depth 2;
每一个新的SSL连接都需要在服务端和客户端进行一个完整的SSL握手过程，这非常耗费CPU计算资源。为了是nignx代理预先协商连接参数，使用一种简略的握手过程，增加proxy_ssl_session_reuse指令配置: 
location /upstream {
    proxy_ssl_session_reuse on;
可选的，你也可以配置使用的SSL协议和SSL秘钥算法: 
location /upstream {
        proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        proxy_ssl_ciphers   HIGH:!aNULL:!MD5;
配置后端服务器 
每一个后端服务器都必须配置成接受https连接。每一个后端服务器需要使用ssl_certificate和ssl_certificate_key指令来指定服务器证书和私钥的文件路径: 
server {
    listen              443 ssl;
    server_name         backend1.example.com;
    ssl_certificate     /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/certs/server.key;
    location /yourapp {
        proxy_pass http://url_to_app.com;
使用ssl_client_certificat指令来设定客户端证书的文件路径: 
server {
    ssl_client_certificate /etc/ssl/certs/ca.crt;
    ssl_verify_client      off;
http {
    upstream backend.example.com {
        server backend1.example.com:443;
        server backend2.example.com:443;
    server {
        listen      80;
        server_name www.example.com;
        location /upstream {
            proxy_pass                    https://backend.example.com;
            proxy_ssl_certificate         /etc/nginx/client.pem;
            proxy_ssl_certificate_key     /etc/nginx/client.key
            proxy_ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
            proxy_ssl_ciphers             HIGH:!aNULL:!MD5;
            proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt;
            proxy_ssl_verify        on;
            proxy_ssl_verify_depth  2;
            proxy_ssl_session_reuse on;
    server {
        listen      443 ssl;
        server_name backend1.example.com;
        ssl_certificate        /etc/ssl/certs/server.crt;
        ssl_certificate_key    /etc/ssl/certs/server.key;
        ssl_client_certificate /etc/ssl/certs/ca.crt;
        ssl_verify_client      off;
        location /yourapp {
            proxy_pass http://url_to_app.com;
    server {
        listen      443 ssl;
        server_name backend2.example.com;
        ssl_certificate        /etc/ssl/certs/server.crt;
        ssl_certificate_key    /etc/ssl/certs/server.key;
        ssl_client_certificate /etc/ssl/certs/ca.crt;
        ssl_verify_client      off;
        location /yourapp {
            proxy_pass http://url_to_app.com;
在这个示例中， proxy_pass指令设置使用了"https"协议，所以nginx转发到后端服务器的流量是安全的。 
当一个安全的连接第一次从nginx转发到后端服务器，将会实施一次完整的握手过程。proxy_ssl_certificate指令设置了后端服务器需要的PEM格式证书的文件位置。proxy_ssl_certificate_key指令设置了证书的私钥位置。proxy_ssl_protocols和proxy_ssl_ciphers指令控制使用的协议和秘钥算法。 
因为proxy_ssl_session_reuse指令配置，当下一次nginx转发一个连接到后端服务器时，会话参数会被重复使用，从而更快的建立安全连接。 
proxy_ssl_trusted_certificate指令设置的那个可信CA证书文件是用来验证后端服务器的证书。proxy_ssl_verify_depth指令指定了证书链检查的深度。proxy_ssl_verify指令验证证书的有效性。 
本文为翻译，英文原文地址：https://www.nginx.com/resources/admin-guide/nginx-https-upstreams/ ，尽量遵循原文，不准确的地方，还请指正，谢谢。 本文原文地址: https://my.oschina.net/foreverich/blog/1517128 永福翻译，未经授权，不得转载！
                    前言本文解释了怎么对nginx和后端服务器组或代理服务器进行加密http通信。https://my.oschina.net/foreverich/blog/1517128?utm_medium=referral内容提纲前提条件	获取SSL服务端证书	获取SSL客户端证书	配置nginx	配置后端服务器	完整示例前提条件nginx源码或nginx plus源码	一个...
proxy_pass http://www.xxx.com/;
proxy_pass http://192.168.200.101:8080/uri;
proxy_pass unix:/tmp/www.sock;
对于proxy_pass的配置有几种情况需要注意:
假设server_name为www.xxx.com
当请求http://www.xxx.com/aming/a.html的时候，以上示例分别访问的结果是
				当待验证的客户端证书是由intermediate-CA签发，而非有root-CA签发时，需要在proxy_ssl_trusted_certificate中配置intermediate-CA和root-CA组成的证书链文件
也就是说，直接尝试使用中级 CA 来验证客户端是无法通过的，openssl 会自动的去找中级 CA 的签发者一层层验证上去，直到找到根。
因此，在实际使用的时候，需要注意一下两点：
CA 文件中必须同时存在 中级 CA 和 根 CA，必须构成完整证书链，不能少任何一个；
默认的验证深度 SslVerifyDepth ssl_verify_depth 是 1，也就是说只要是中级
之前介绍过Nginx反向代理实现二级域名转发， 不过当时直接用Nginx代理的HTTP。 这次通过Nginx启用SSL， 代理HTTPS， 并实现HTTP强制转HTTPS。
第一步 Nginx代理HTTPS
修改配置： 添加443端口监听， 开启SSL， 配置证书地址， 反向代理HTTPS。
server { 
    listen  443 ssl;
    server_name  ww...
   proxy_pass http://server2/;
但是忘记了server1上有个服务路径是/indexNew，结果就被proxy到了server1，出现404问题，然后紧急修改配置如下：
location /indexNew {
   proxy_pass http://server1/;
				在nginx中配置proxy_pass代理转发时，如果在proxy_pass后面的url加/，表示绝对根路径；如果没有/，表示相对路径，把匹配的路径部分也给代理走。
假设下面四种情况分别用 http://192.168.1.1/proxy/test.html 进行访问。
location /proxy/ {
proxy_pass http://127.0.0.1/;
代理到URL：http://127.0.0.1/test.html
第二种（相对于第一种，最后少一个 / ）
locati
				最近排查一个web服务的问题，webserver使用的nginx，最终发现是踩了nginx中proxy_pass的一个坑，这里记录下来。
一个线上的http服务，示例nginx关键配置如下：
server {
  listen 80;
  server_name ligang.gdemo.com;
  server_tokens off;
  keepalive_timeout 5;
  charset utf-8;
  include /home/ligang/devspace/gobox-demo/conf/http/general/gzip.conf;
  access_lo
  ~      #波浪线表示执行一个正则匹配，区分大小写
  ~*    #表示执行一个正则匹配，不区分大小写
  ^~    #^~表示普通字符匹配，不是正则匹配。如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录
  =      #进行普通字符精确匹配
  @     #”@” 定义一个命名的 location，使用在内部定向时，例如 error_page, try_files
2）location 匹配的优先级(与location在配置文件中的顺序无关)
1.= 精确匹配会第一
1.1、tomcat: http://127.0.0.1:8080
1.2、tomcat:http://127.0.0.1:8081
1.3、nginx:http://127.0.0.1
2、反向代理proxy_pass
2.1、反向代理
2.2、反向代理-使用upstream
2.3、反向代理-负载均衡-轮循模式
2.4、反向代理-负载均衡-权重模式
2.4、反向代理-负载均衡-ip_hash方式
3、网关代理fastcgi_pass（php+nginx配合）
3.1、php安装（本人安装的是php-7.3.1）
3.1.1、php下载
　　代理（proxy），即中间人，它代替客户端发送请求给服务器，收到响应后再转给客户端。通常意义上的代理是从用户的角度讲的，用户通过某个代理可以访问多个网站，这个代理是靠近用户的，比如某些公司可能需要限制员工所访问的网站，就会在网络出口处放置一个代理来做过滤。
　　反向代理（reverse proxy），本质上跟代理是一回事，只不过是从服务器的角度讲的，是靠近服务器的。比如某个网站有多个服务器，提供同样的功能，一般会在网络入口处放一个代理，接收客户端的请求，再基于某种策略（比如轮转）转发给后端
				当使用 `proxy_pass` 代理请求到后端时，如果 URL 中没有指定端口号，则 Nginx 会将请求发送到后端默认的端口号。通常情况下，HTTP 请求会默认使用 80 端口，HTTPS 请求会默认使用 443 端口。
如果你想要指定一个不同的端口号来代理请求，你可以在 `proxy_pass` 指令中指定一个完整的 URL，例如：
location / {
    proxy_pass http://backend.example.com:8080;
这样，Nginx 就会将请求发送到 `http://backend.example.com` 的 8080 端口。如果你只想代理到相同的主机和端口，但是想保留原始的 URL 端口号，可以使用 `proxy_set_header` 指令来设置 `Host` 头部信息，例如：
location / {
    proxy_pass http://backend.example.com;
    proxy_set_header Host $host:$server_port;
这样，Nginx 就会将请求发送到 `http://backend.example.com` 的默认端口上，同时保留原始的 URL 端口号。