第四节：Nginx负载均衡配置(含各种重试)、限流配置、Https配置详解

一. 负载均衡

1. 用法

　通过proxy_pass 可以把请求代理至后端服务，但是为了实现更高的负载及性能， 我们的后端服务通常是多个， 这个是时候可以通过upstream 模块实现负载均衡。

使用的模块为：【ngx_http_upstream_module】，具体配置可以根据模块名去查找文档。

负载均衡的算法有：

• ll：轮询

• ll+weight： 轮询加权重 

• ip_hash : 基于Hash 计算，用于保持session 一至性 （在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight））

• least_conn ：最小链接数

• url_hash: 静态资源缓存，节约存储，加快速度（第三方）  该算法下权重配置失效

• least_time  ：最小的响应时间，计算节点平均响应时间，然后取响应最快的那个，分配更高权重

2. 参数

upstream 相关参数如下：

• server  反向服务地址加端口

• weight  权重，默认是1，越大权重就越大

• max_fails  失败多少次认为主机已挂掉则，踢出 （默认配置10s，即服务器宕掉，会自动剔除）

• fail_timeout  踢出后重新探测时间 

• backup  备用服务，当其他非backup的机器全部宕机或者繁忙的时候，才会启动这台机器。

• down  表示当前Server不参与负载

• max_conns 允许最大连接数

• slow_start 当节点恢复，不立即加入,而是等待 slow_start 后加入服务对列。

upstream myApiTest {
          server localhost:9001 weight=10;
          server localhost:9002 weight=5;
          server localhost:9003  max_fails=3 fail_timeout=30s;
          server localhost:9004 backup;
          server localhost:9005 down;
    }

3. 案例

事先准备：

　 有三个同样的api服务，分别部署在9001、9002、9003端口下，比如：访问 http://localhost:9001/Home/GetMsg，会返回 【 获取成功，当前端口为：9001】，其它端口类似。

要求：

　Nginx监听8080端口，接收到8080端口的请求，按照响应的算法进行转发到9001-9003端口。　

(1). 轮询

　访问地址：http://localhost:8080/Home/GetMsg ，会依次转发到9001、9002、9003端口上。【最新版本测试，轮询的时候一个服务器连续沦陷两次，才到下一个服务器，继续连续两次】？？

配置如下：

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream myApiTest {
          server localhost:9001;
          server localhost:9002;
          server localhost:9003;
    }
    server {
        listen       8080;
        server_name   localhost;    #监听地址
        location / {
            proxy_pass http://myApiTest;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

补充其他参数说明：

　下面配置，当请求 http://localhost:8080/Home/GetMsg 时候，只会被转发到9003端口上，此时把9003端口的服务关掉，再次请求，则会被转发到9001端口上，其中9002端口，全程不参与负载。

upstream myApiTest {
    server localhost:9001 backup;
    server localhost:9002 down;
    server localhost:9003;
}

(2).轮询+权重

　 下面配置，被转发到9001 9002端口的概率要大于9003端口。

配置如下：

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream myApiTest {
          server localhost:9001 weight=10;
          server localhost:9002 weight=5;
          server localhost:9003;
    }
    server {
        listen       8080;
        server_name   localhost;    #监听地址
        location / {
            proxy_pass http://myApiTest;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

(3). ip_hash

　同一个ip永远会被分配到同一个Server上，主要用来解决Session不一致的问题，但该策略也有弊端，weight权重无效，所以该方案会导致某个Server压力可能过大，请求分配不均匀问题。

• 在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）。
• ip_hash不能与backup同时使用
• 此策略适合有状态服务，比如session。
• 当有服务器需要剔除，必须手动down掉。

配置如下：

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream myApiTest {
          ip_hash;   #开启ip_hash策略
          server localhost:9001;
          server localhost:9002;
          server localhost:9003;
    }
    server {
        listen       8080;
        server_name   localhost;    #监听地址
        location / {
            proxy_pass http://myApiTest;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

(4). least_con

  把请求转发给连接数较少的后端服务器，轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高，这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。

核心配置文件

upstream myApiTest {
  least_conn;  #把请求转发给连接数较少的后端服务器
  server 192.168.64.1:9001  weight=2;                   
  server 192.168.64.1:9002;                             
  server 192.168.64.1:9003;                        
  server 192.168.64.1:9004;
}

(5). url_hash

　主要用于节省空间，比如我有9G的图片资源，服务器集群有三台，因为不确定请求会被转发到哪一台上，所以每台服务器都存放9G，显然这样是不合理的。

　我们可以在存储的时候，将图片进行urlhash算法，分别存放到三台服务器上，这样请求的时候也是用urlhash，去指定服务器请求即可，节省了服务器空间，也就是3台服务器总共用了9G。

PS：上面只是举例方便理解，生产中，大量图片资源存放cdn第三方，然后在自己的服务器上做一层临时缓存，为了提高缓存的命中率，通常用urlhash算法。

4. 重试策略

(1). 基础失败重试

 为了方便理解，使用了以下配置进行分析（proxy_next_upstream 没有特殊配置）

重试配置

upstream dynamicserver {
      server 192.168.64.1:9001 fail_timeout=60s max_fails=3; #Server A
      server 192.168.64.1:9002 fail_timeout=60s max_fails=3; #Server B
}

配置说明

max_fails=3 fail_timeout=60s代表在60秒内请求某一应用失败3次，认为该应用宕机，后等待60秒，这期间内不会再把新请求发送到宕机应用，而是直接发到正常的那一台，时间到后再有请求进来继续尝试连接宕机应用且仅尝试1次，如果还是失败，则继续等待60秒...以此循环，直到恢复

模拟异常

模拟后端异常的方式是直接将对应服务关闭，造成 connect refused 的情况，对应 error 错误。

在最初始阶段，所有服务器都正常，请求会按照轮询方式依次转发给 AB 两个 Server 处理。假设这时 A 节点服务崩溃，端口不通，则会出现这种情况：

1. 请求 1 转到 A 异常，再重试到 B 正常处理，A fails +1
2. 请求 2 转到 B 正常处理
3. 请求 3 转到 A 异常，再重试到 B 正常处理，A fails +1 达到 max_fails 将被屏蔽 60s
4. 屏蔽 A 的期间请求都只转给 B 处理，直到屏蔽到期后将 A 恢复重新加入存活列表，再按照这个逻辑执行

如果在 A 的屏蔽期还没结束时，B 节点的服务也崩溃，端口不通，则会出现：

1. 请求 1 转到 B 异常，此时所有线上节点异常，会出现：

   • AB 节点一次性恢复，都重新加入存活列表
   • 请求转到 A 处理异常，再转到 B 处理异常
   • 触发 no live upstreams 报错，返回 502 错误
   • 所有节点再次一次性恢复，加入存活列表

2. 请求 2 依次经过 AB 均无法正常处理， 触发 no live upstreams 报错，返回 502 错误

 

(2). 错误重试

有时候我们系统出现500等异常的情况下，希望nginx能够到其他的服务器进行重试，我们可以配置那些错误码才进行重试

配置说明

在nginx的配置文件中，proxy_next_upstream项定义了什么情况下进行重试，官网文档中给出的说明如下

Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | off ...;
Default:    proxy_next_upstream error timeout;
Context:    http, server, location

默认情况下，当请求服务器发生错误或超时时，会尝试到下一台服务器，还有一些其他的配置项如下：

配置说明

这里面我们配置了500等错误的时候会进行重试

upstream dynamicserver {
  server 192.168.64.1:9001 fail_timeout=60s max_fails=3; #tomcat 1
  server 192.168.64.1:9002 fail_timeout=60s max_fails=3; #tomcat 2
}

server {
        server_name www.whales.com;
        default_type text/html;
        charset   utf-8;

        location ~ .*$ {
            index index.jsp index.html;
            proxy_pass http://dynamicserver;
            #下一节点重试的错误状态
            proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
       }
}

模拟异常

在正常的情况下如果500错误会直接出现异常页面，现在我们加入了以上500重试策略，重试错误的流程和上面流程是一样的

 

(3). backup服务器

Nginx 支持设置备用节点，当所有线上节点都异常时启用备用节点，同时备用节点也会影响到失败重试的逻辑，因此单独列出来介绍。

backup 处理逻辑

upstream 的配置中，可以通过 backup 指令来定义备用服务器，其含义如下

1. 正常情况下，请求不会转到到 backup 服务器，包括失败重试的场景
2. 当所有正常节点全部不可用时，backup 服务器生效，开始处理请求
3. 一旦有正常节点恢复，就使用已经恢复的正常节点
4. backup 服务器生效期间，不会存在所有正常节点一次性恢复的逻辑
5. 如果全部 backup 服务器也异常，则会将所有节点一次性恢复，加入存活列表
6. 如果全部节点（包括 backup）都异常了，则 Nginx 返回 502 错误

配置说明

upstream dynamicserver {
  server 192.168.64.1:9001 fail_timeout=60s max_fails=3; #Service A
  server 192.168.64.1:9002 fail_timeout=60s max_fails=3; #Server B
  server 192.168.64.1:9003 backup; #backup
}

server {
        server_name www.whales.com;
        default_type text/html;
        charset   utf-8;

        location ~ .*$ {
            index index.jsp index.html;
            proxy_pass http://dynamicserver;
            #下一节点重试的错误状态
            proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
       }
}

在最初始阶段，所有服务器都正常，请求会按照轮询方式依次转发给 AB 两个节点处理。当只有 A 异常的情况下，与上文没有 backup 服务器场景处理方式一致，这里就不重复介绍了。

假设在 A 的屏蔽期还没结束时，B 节点的服务也崩溃，端口不通，则会出现：

1. 请求 1 转到 B 处理，异常，此时所有线上节点异常，会出现：

   • AB 节点一次性恢复，都重新加入存活列表
   • 请求转到 A 处理异常，再重试到 B 处理异常，两者 fails 都 +1
   • 因 AB 都异常，启用 backup 节点正常处理，并且 AB 节点一次性恢复，加入存活列表

2. 请求 2 再依次经过 A、B 节点异常，转到 backup 处理，两者 fails 都达到 max_fails：

   • AB 节点都将会被屏蔽 60s，并且不会一次性恢复
   • backup 节点正式生效，接下来所有请求直接转到 backup 处理
   • 直到 AB 节点的屏蔽到期后，重新加入存活列表

假设 AB 的屏蔽期都还没结束时，C 节点的服务也崩溃，端口不通，则会出现

1. 请求 1 转到 C 异常，此时所有节点（包括 backup）都异常，会出现：

   • ABC 三个节点一次性恢复，加入存活列表
   • 请求转到 A 处理异常，重试到 B 处理异常，最后重试到 C 处理异常
   • 触发 no live upstreams 报错，返回 502 错误
   • 所有节点再次一次性恢复，加入存活列表

2. 请求 2 依次经过 AB 节点异常，重试到 C 异常，最终结果如上个步骤，返回 502 错误

 

(4). 限制重试方式

默认配置是没有做重试机制进行限制的，也就是会尽可能去重试直至失败，Nginx 提供了以下两个参数来控制重试次数以及重试超时时间

• proxy_next_upstream_tries：设置重试次数，默认 0 表示无限制，该参数包含所有请求 upstream server 的次数，包括第一次后之后所有重试之和；
• proxy_next_upstream_timeout：设置重试最大超时时间，默认 0 表示不限制，该参数指的是第一次连接时间加上后续重试连接时间，不包含连接上节点之后的处理时间

upstream dynamicserver {
      server 192.168.64.1:9001 fail_timeout=60s max_fails=3; #Server A
      server 192.168.64.1:9002 fail_timeout=60s max_fails=3; #Server B
}

server {
        server_name www.whales.com;
        default_type text/html;
        charset   utf-8;

        location ~ .*$ {
            index index.jsp index.html;
            proxy_pass http://dynamicserver;
            # 表示重试超时时间是3s
            proxy_connect_timeout 3s;
            #表示在 6 秒内允许重试 3 次，只要超过其中任意一个设置，Nginx 会结束重试并返回客户端响应
            proxy_next_upstream_timeout 6s;
            proxy_next_upstream_tries 3;
       }
}

 

 

二. 限流配置

(限流算法和实操详见： https://www.cnblogs.com/yaopengfei/p/17719273.html)

1.  说明

(1). 限流的作用

  限流主要用作安全目的，比如可以减慢暴力密码破解的速率。

  通过将传入请求的速率限制为真实用户的典型值，并标识目标URL地址(通过日志)，

  还可以用来抵御DDOS攻击。更常见的情况，该功能被用来保护上游应用服务器不被同时太多用户请求所压垮。

(2). 原理 

   令牌桶算法

    漏桶算法

(3). 涉及到的模块

  A.  用来限制同一时间连接数，即并发限制  【不常用】

【ngx_http_limit_conn_module】  对应文档：http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html

  B.  用来限制单位时间内的请求数，即速率限制，采用的漏桶算法   【推荐使用】

【ngx_http_limit_req_module】    对应文档：http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

 

2. 环境准备

(1). Api接口

  启动指令如下：

【dotnet NginxTest.dll --urls="http://*:7061" --ip="127.0.0.1" --port=7061】

【dotnet NginxTest.dll --urls="http://*:7062" --ip="127.0.0.1" --port=7062】

 接口地址为： http://localhost:7061/api/Home/GetNowTime      【Post请求】

 接口代码如下： 

注意：接口的代码中要休眠一下，模拟实际操作，否则速度太快，测试不出来结果。

[Route("api/[controller]/[action]")]
    [ApiController]
    public class HomeController : ControllerBase
    {
        [HttpPost]
        public string GetNowTime()
        {
            string nowTime = DateTime.Now.ToString();
            Thread.Sleep(1000);
            Console.WriteLine($"当前时间为:{nowTime}");
            return $"当前时间为:{nowTime}";
        }
    }

(2). nginx服务

 使用到的指令

   启动服务：【start nginx】   

　强制关闭服务：【nginx -s stop】

　重载服务：【nginx -s reload】　

nginx监听7000端口，然后进行代理配置，这里重点测试的是限流，只用7061一个api端口即可。 

worker_processes  1;
events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    
    server {
        listen       7000;        #监听端口
        server_name  xxx;         #随意配置一个地址即可，优先走代理
        location / {
             proxy_pass http://localhost:7061;   #代理地址
        }
    
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }  
    }
}

通过post请求访问：http://localhost:7000/api/Home/GetNowTime ，返回当前时间，表示配置成功。

(3). jmeter测试工具 

    添加线程组，然后在线程组的基础上添加：http请求、察看结果树、聚合报告、用表格查结果。

    配置请求的并发数、请求地址。

 测试结果：10个请求全部成功。

 

3. 限流-限制并发连接数【不常用】

声明格式：

limit_conn_zone $server_name zone=myLimit0:10m;
limit_conn_zone $binary_remote_addr zone=myLimit1:10m;

(1). $server_name：表示虚拟主机(server) 同时能处理并发连接的总数。 (数量在启用时配置)

(2). $binary_remote_addr：表示限制每个客户端IP(单个ip)连接到服务器的链接数量。  (数量在启用时配置)

(3).  zone=myLimit1:10m ：表示内存区域名称 和 空间大小。

调用格式：

limit_conn myLimit1 2;	 #启用限流

(1).  myLimit1 :表示用上述声明的哪个配置进行限制，myLimit1与上述声明的名称相对应。

(2).  2：  表示配置的数量限制。

(1). 限制-虚拟主机同时能处理的并发链接总数

分析：

    虚拟主机(server) 同时能处理并发连接的总数为8.

测试条件：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    
    # 限流配置声明
    limit_conn_zone $server_name zone=myLimit0:10m;
    server {
        listen       7000;        #监听端口
        server_name  xxx;         #随意配置一个地址即可，优先走代理
        location / {
             limit_conn myLimit0 8;  #启用限流
             proxy_pass http://localhost:7061;   #代理地址
        }
    
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }  
    }
}

测试结果：

  20个请求，成功8个，失败12个

(2). 限制-单个ip链接到服务器的数量

剖析：

     单个IP同时最多能持有2个连接

测试条件：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    # 限流配置声明
    limit_conn_zone $binary_remote_addr zone=myLimit1:10m;
    server {
        listen       7000;        #监听端口
        server_name  xxx;         #随意配置一个地址即可，优先走代理
        location / {
             limit_conn myLimit1 2;	 #启用限流
             proxy_pass http://localhost:7061;   #代理地址
        }
    
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }  
    }
}

测试结果：20个请求，成功2个，失败18个

4. 限流-限制速率【推荐使用】

声明格式：

limit_req_zone $binary_remote_addr zone=myLimit2:10m rate=5r/s;

(1). $binary_remote_addr :  表示限制同一客户端ip地址，即限制速率是以ip为分类的，限制每个ip的速度。

(2). zone=myLimit2:10m：  myLimit2表示内存区域的名称，10m表示内存空间的大小。

(3).  rate=5r/s ： 表示1s允许5个请求， 注意这里需要拆分理解，即200ms允许1个请求，当第一个请求处理完成，如果200ms内又进来一个请求，该请求将被拒绝处理，只有过了200ms后，才会处理第2个请求，一次类推。

调用格式 ：

limit_req zone=myLimit2 burst=5 nodelay;

(1). zone=myLimit2：表示用上述声明的哪个配置进行限制，myLimit2与上述声明的名称相对应。

(2). burst=5 ：设置一个大小为5的缓冲区，当有大量请求（瞬间爆发）过来时，超过了上述配置的访问频次限制的请求，可以先放到这个缓冲区内。

注：burst的作用是让多余的请求可以先放到队列里，慢慢处理。如果不加nodelay参数，队列里的请求不会立即处理，而是按照rate设置的速度，以毫秒级精确的速度慢慢处理。

(3). nodelay ： 设置后，burst缓冲区中排队的请求立即被处理，超过频次限制 并且 缓冲区满了的情况下，直接返回503状态码；如不设置，那么额外的请求将进入等待排队的状态

注：通过设置burst参数，我们可以允许Nginx缓存处理一定程度的突发，多余的请求可以先放到队列里，慢慢处理，不报错，这起到了平滑流量的作用。

       但是如果队列设置的比较大，请求排队的时间就会比较长，从用户角度看来就是响应变长了，这对用户很不友好，所以引入nodelay参数。

  nodelay参数允许请求在排队的时候就立即被处理，也就是说只要请求能够进入burst队列，就会立即被后台处理，请注意，这意味着burst设置了nodelay时，系统瞬间的QPS可能会超过rate设置的阈值。

       所以：nodelay参数要跟burst一起使用才有作用。

(1). 实操1-限制速率

分析：

  使用jmeter发送10个请求进行测试，nginx的限制速率设置为 2r/s，意味着第1个请求处理完后，500ms内接收的请求都将拒绝，过了500ms后，才能处理下一个请求。 详见下面的测试结果。

测试条件：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    # 限流配置声明
    limit_req_zone $binary_remote_addr zone=myLimit2:10m rate=2r/s;
    server {
        listen       7000;        #监听端口
        server_name  xxx;         #随意配置一个地址即可，优先走代理
        location / {
             limit_req zone=myLimit2;	 #启用限流	 
             proxy_pass http://localhost:7061;   #代理地址
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }  
    }
}

测试结果：

    第1个成功的请求的是008ms，接下来第 2-6个请求，由于是在500ms内，所有都请求失败；  第2个成功的请求为608ms，正好过了500ms了，所以成功了。

 

(2). 限制速率+设置缓冲区

分析：

   使用jmeter发送10个请求进行测试，nginx的限制速率设置为 2r/s，burst=5，意味着第1个请求处理完后，接下来的5个请求都是存放到缓存中，第7个请求如果在第1个的500ms后，则请求成功，反之失败。

测试条件：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    # 限流配置声明
    limit_req_zone $binary_remote_addr zone=myLimit2:10m rate=2r/s;
    server {
        listen       7000;        #监听端口
        server_name  xxx;         #随意配置一个地址即可，优先走代理
        location / {
             limit_req zone=myLimit2 burst=5;	  #启用限流
             proxy_pass http://localhost:7061;   #代理地址
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }  
    }
}

测试结果：

  第1个成功的请求为343ms，接下来第2-6个加入到缓存区，依次执行成功； 第7个请求为944，与第一个成功的请求相比，已经超过了500ms，所以执行成功，接下来的8-10个请求，均在第7个成功后的500ms内，所以均失败。

(3). 限制速率+设置缓冲区+立即处理

分析：

   使用jmeter发送10个请求进行测试，nginx的限制速率设置为 2r/s，burst=5  nodelay，意味着第1个请求处理完后，接下来的5个请求立即执行，第7个请求如果在第1个的500ms后，则请求成功，反之失败。

测试条件：

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    # 限流配置声明
    limit_req_zone $binary_remote_addr zone=myLimit2:10m rate=1r/s;
    server {
        listen       7000;        #监听端口
        server_name  xxx;         #随意配置一个地址即可，优先走代理
        location / {
             limit_req zone=myLimit2 burst=5 nodelay;	#启用限流	 
             proxy_pass http://localhost:7061;   #代理地址
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }  
    }
}

测试结果：

  第1个成功的请求为278ms，接下来2-6个立即执行，第7个请求为879，距离第一个成功的已经超过500ms，所以执行成功，接下来的8-10个请求，均在500ms内，所以执行失败。

 

 

 

 

 

三. Https配置

1. 准备

(1). 生成证书

   OpenSSL工具下载地址：http://slproweb.com/products/Win32OpenSSL.html      【这里以3.0.5为例】

   

   OpenSSL生成证书步骤：https://jingyan.baidu.com/article/6c67b1d6be538c2787bb1e06.html

(2). 相关模块

【ngx_http_rewrite_module】     参考文档：http://nginx.org/en/docs/http/ngx_http_rewrite_module.html

 

2. 实操

(1). 配置https的Server

    开启一个新的虚拟主机，用来配置https监听8000端口，配置证书的物理地址即可，就可以通过 https://localhost:8000/api/Home/GetNowTime ，访问代理地址下7061的api了。

 （PS：下面配置同时开启了 http的主机，所以通过 http://localhost:7000/api/Home/GetNowTime，也可以访问）

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    #http主机
    server {
        listen       7000;          #监听端口
        server_name  test1;         #随意配置一个地址即可，优先走代理
        location / {	 
            proxy_pass http://localhost:7061;   #代理地址
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }  
    }
	
    #https主机
    server {
        listen       8000 ssl;
        server_name  test2;
        #证书目录
        ssl_certificate      D:/cert/server-cert.pem;
        ssl_certificate_key  D:/cert/server-key.pem;

        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;
        location / {
            proxy_pass http://localhost:7061;
        }
    }
}

(2). 将http跳转到https

   上述http监听的7000端口，https监听的8000端口，如何让http请求自动跳转到https请求上呢？

    加个 return 301 xxxxx  跳转即可。

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
	#http主机
    server {
        listen       7000;          #监听端口
        server_name  test1;         #随意配置一个地址即可，优先走代理
        location / {	 
            proxy_pass http://localhost:7061;   #代理地址
			
			#跳转到https （test2是https主机的server_name）
			return 301 https://test2$request_uri;
			
			#或者
			#return 301 https://$host:8000$request_uri;
        }
    
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }  
    }
	
	#https主机
	server {
        listen       8000 ssl;
        server_name  test2;

		#证书目录
		ssl_certificate      D:/cert/server-cert.pem;
        ssl_certificate_key  D:/cert/server-key.pem;
        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;
        location / {
            proxy_pass http://localhost:7061;
        }
    }
}

 

 

 

 

!

• 作       者 : Yaopengfei(姚鹏飞)
• 博客地址 : http://www.cnblogs.com/yaopengfei/
• 声     明1 : 如有错误，欢迎讨论，请勿谩骂^_^。
• 声     明2 : 原创博客请在转载时保留原文链接或在文章开头加上本人博客地址，否则保留追究法律责任的权利。