带参数的请求怎么配置nginx

1. Nginx Http 模块中 Upstream 的 keepalive 参数配置注意事项

在高并发环境下 keepalive 参数配置不当容易产生大量 TIME_WAIT，导致端口耗尽，服务异常。

keepalive 值应该大于等于 upstream 中 server 的数量。（建议是 server 数的 2 倍）

keepalive 用于设置保留在每个 nginx worker 缓存中‘已经与上游服务器建立的空闲连接’的最大连接数，如果超过这个值，最近最少使用的连接将被关闭。

Nginx 官方建议这个值应该尽可能小，以便让上游服务器也能处理新进入的连接。但是‘尽可能小’有些太模糊，如果配置不当会降低性能以及产生其他问题。

在大量短链接(或者大量分散用户)的请求场景下，同时 upstream 为轮询模式时，因为 keepalive 值小于 upstream server 数，upstream 新的空闲连接会从缓存中挤出老的空闲链接，导致 keepalive 在某种意义上失效。

根据下面配置，以单个 nginx worker 处理请求为例，这里做个更详细的解释：

第一个请求进来，nginx 与 10.0.0.1 建立连接，请求处理完成后，nginx 与 10.0.0.1 的空闲连接被放入空闲连接池；

第二个请求进来，nginx 与 10.0.0.2 建立连接，请求处理完成后，nginx 与 10.0.0.2 的空闲连接被放入空闲连接池；

第三个请求进来，nginx 与 10.0.0.3 建立连接，请求处理完成后，因为最大空闲连接数为 2，连接数已满，所以 nginx 与 10.0.0.1 的空闲连接被 close，nginx 与 10.0.0.3 的空闲连接被放入空闲连接池；

第四个请求进来，nginx 再次与 10.0.0.1 建立连接，请求处理完成后，因为最大空闲连接数为 2，连接数已满，所以 nginx 与 10.0.0.2 的空闲连接被 close，nginx 与 10.0.0.1 的空闲连接被放入空闲连接池

。。。以此类推

这种效果就像没有配置 keepalive

挖个坑：以上内容根据实践经验以及推测而得出，待我用源码来证明 :）

nginx 官方文档: https://nginx.org/en/docs/http/ngx_http_upstream_mole.html#keepalive

2. Nginx转发请求过程解析

How nginx processes a request

这种配置情况下，第一个server就是默认配置。请求通过Header中的"Host"来匹配到对应的服务，如果没有匹配到任何server_name，则路由到默认server（第一个server）处理。

通过给 listen 增加 default_server 参数明确指定哪个server是默认server（ default_server 参数从0.8.21版本开始有效）。 注意： default_server 是用作用于端口的，而不是 server_name 的

可以定义一个 server_name 属性为空的server来处理没有Host的请求（从0.8.48版本开始， server_name 默认是""，之前的版本默认是hostname）。

这个配置标识请求Header中Host为空时，会返回“444”响应码，然后关闭链接。

请求Header中的Host匹配到 server_name 后，会转发到IP+端口上，如果为匹配到 server_name ，如前面所述，会转发到第一个server来处理请求，当然也可以通过 default_server 属性来指定端口的默认server。

如上配置，处理请求流程如下：

请求进来时，nginx会按照如下步骤来匹配请求（匹配请求只用URI不带参数的部分）

spring web service系列1
spring web service系列2
spring web service系列3
maven配置文件settings.xml详解
Nginx中的负载均衡算法
Nginx upstream指令配置说明
Nginx中虚拟服务器server指令配置说明
Nginx中proxy_pass/proxy_redirect/proxy_set_header配置说明
Nginx中ngx_http_core_mole相关指令配置说明
Java自带JVM监控工具jstat使用详细说明
Java自带JVM监控工具jps使用详细说明
Java自带故障分析工具jmap工具使用说明
Java自带故障分析工具jhat工具使用说明

3. Nginx运行原理和配置详解（个人总结笔记）

话不多说，撸起键盘就是干！正所谓知其然知其所以然，个人总结了下Nginx运行原理和配置详解，便于理解和后续复盘。

先来看这一张图。

nginx启动后会有 一个master进程和多个worker进程 。master进程用来管理worker进程， 一个worker进程处理一个请求 ，一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。 worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致 ，这里面的原因与nginx的进程模型以及事件处理模型是分不开的 ，过多的worker数，只会导致进程来竞争cpu资源，从而带来不必要的上下文切换。

php WEB服务器目前最佳方式之一就是： Nginx + FastCGI（解决CGI并发重复fork问题） + PHP-FPM（管理PHP-CGI进程） 。nginx是怎么做到把请求抛给PHP解释来处理的呢？这个过程又是怎么实现的呢？稍后我们来看一下参数配置。

代理，反向代理，负载均衡是Nginx常用功能。

Http代理，反向代理：作为web服务器最常用的功能之一，尤其是反向代理。如果你和小马之前一样还是分不清代理和反向代理的区别，下面这个图对理解会有所帮助。

它们的区别就是，前者知道我要找的人并知道地址在哪，代理服务器按这个地址代为请求一下然后把他说的话返回给我。后者就是，我知道我要找谁问话但不知道地址在哪，我也不想管，代理服务你自己去找，只要帮我返回他要说的话就可以了。

负载均衡：其实也是 反向代理 的一种。负载均衡，热备等等其实都属于高可用范畴，Nginx提供的负载均衡策略有2种：内置策略和扩展策略。内置策略为 轮询，加权轮询，Ip hash 等等。扩展策略，就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他做下实现。思考一个问题，IP hash真的能解决session共享的问题么？

我们来简单看下两个 配置示例 。

这个配置将请求转发转向mysvr 定义的服务器列表。 注意proxy_pass配置。其实这块也是负载均衡的配置 。如下：

在访问网站时，由于配置了proxy_pass地址，所有请求都会先通过nginx反向代理服务器，在服务器将请求转发给目的主机时，读取upstream为 tomcatsever1的地址，读取分发策略，配置tomcat1权重为3，所以nginx会将大部分请求发送给49服务器上的tomcat1，也就是8080端口；较少部分给tomcat2来实现有条件的负载均衡，当然这个条件就是服务器1、2的硬件指数处理请求能力。

负载均衡配置 还有其他的相关参数，这是只是打个样，不赘述。

可以认为fastcgi_pass这个配置非常关键，将Nginx + FastCGI + PHP-FPM串连 。这个配置将PHP请求都交给 fastcgi_pass配置的PHP-FPM处理。 location分别通过正则过滤和转发配置决定了各个请求URL将要转发交与的处理方式 ，location /表示默认请求，location  ~\.php(.*)$ 表示PHP 脚本请求全部转发到 FastCGI处理。 使用FastCGI默认配置.。

以上配置指定了这些 静态文件要nginx自己处理 。

NGINX负载均衡可以用于很多服务负载均衡的实现，比如做Redis服务的负载均衡，配置upstream的IP列表再配置 proxy_pass 代理即可。那要实现负载均衡除了NGINX，还有哪些呢？

根据7层OSI模型可将负载均衡分为 ：

1）二层负载均衡（一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）；

2）三层负载均衡（一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应）；

3）四层负载均衡（在三次负载均衡的基础上，用 ip+port 接收请求，再转发到对应的机器）；

4）七层负载均衡（根据虚拟的url或是IP，主机名接收请求，再转向相应的处理服务器）。

这其中，最常见的是四层和七层负载均衡。思考一下，NGINX的负载均衡是属于哪一种？

关于负载均衡的架构

4. [code.nginx] Nginx服务器高级配置

这里提及的参数是和IPv4网络有关的linux内核参数。我们可以将这些内核参数的值追加到Linux系统的/etc/sysctl.conf文件中，然后使用如下命令使修改生效：

这些常用的参数包括以下这些。
** 1. net.core.netdev_max_backlog参数 **
net.core.netdev_max_backlog，表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。一般默认值为128（可能不同的Linux系统该数值也不同）。Nginx服务器中定义的NGX_LISTEN_BACKLOG默认为511.我们可以将它调整一下：

** 2.net.core.somaxconn参数 **
该参数用于调节系统同时发起的TCP连接数，一般默认值为128。在客户端存在高并发请求的情况下，在默认值较小，可能导致链接超时或者重传问题，我们可以根据实际需要结合并发请求数来调节此值。

** 3.net.ipv4.tcp_max_orphans参数 **
该参数用于设定系统中最多允许存在多少TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，没有与用户文件句柄关联的TCP套接字将立即被复位，同时给出警告信息。这个限制只是为了防止简单的DoS(Denial of Service，拒绝服务)攻击。一般在系统内存比较充足的情况下，可以增大这个参数的赋值：

** 4.net.ipv4.tcp_max_syn_backlog参数 **
该参数用于记录尚未收到客户端确认信息的连接请求的最大值。对于拥有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。一般在系统内存比较充足的情况下，可以增加这个参数的赋值：

** 5.net.ipv4.tcp_timestamps参数 **
该参数用于设置时间戳，这可以避免序列号的卷绕。在一个1Gb/s的链路上，遇到以前用过的序列号的概率很大。当此值赋值为0时，禁用对于TCP时间戳的支持。在默认情况下，TCP协议会让内核接受这种“异常”的数据包。针对Nginx服务器来说，建议将其关闭：

** 6.net.ipv4.tcp_synack_retries参数 **
该参数用于设置内核放弃TCP连接之前向客户端发送SYN+ACK包的数量。为了建立对端的连接服务，服务器和客户端需要进行三次握手，第二次握手期间，内核需要发送SYN并附带一个回应前一个SYN的ACK，这个参数主要影响这个进程，一般赋值为1，即内核放弃连接之前发送一次SYN+ACK包，可以设置其为：

** 7.net.ipv4.tcp_syn_retries参数 **
该参数的作用和上一个参数类似，设置内核放弃建立连接之前发送SYN包的数量，它的赋值和上个参数一样即可：

在Nginx配置文件中，有这样两个指令：worker_processes和worker_cpu_affinity，它们可以针对多核CPU进行配置优化。
** 1.worker_processes指令 **
worker_processes指令用来设置Nginx服务的进程数。官方文档建议此指令一般设置为1即可，赋值太多会影响系统的IO效率，降低Nginx服务器的性能。为了让多核CPU能够很好的并行处理任务，我们可以将worker_processes指令的赋值适当的增大一些，最好是赋值为机器CPU的倍数。当然，这个值并不是越大越好，Nginx进程太多可能增加主进程调度负担，也可能影响系统的IO效率。针对双核CPU，建议设置为2或
4。如果是四核CPU，设置为：

设置好worker_processes指令之后，就很有必要设置worker_cpu_affinity指令。

** 2. worker_cpu_affinity指令 **
worker_cpu_affinity指令用来为每个进程分配CPU的工作内核。这个指令用来为每个进程分配CPU的工作内核。这个指令的设置方法有些麻烦。
如下图所示：

worker_cpu_affinity指令的值是由几组二进制值表示的。其中，每一组代表一个进程，每组中的每一位表示该进程使用CPU的情况，1表示使用，0表示不使用。注意，二进制位排列顺序和CPU的顺序是相反的。建议将不同的进程平均分配到不同的CPU运行内核上。
如果设置的Nginx服务的进程数为4，CPU为4核，因此会有四组值，并且每组有四位，所以，此指令的设置为：

四组二进制数值分别对应4个进程，第一个进程对应0001，表示使用第一个CPU内核。第二个进程对应0010，表示使用第二个CPU内核，以此类推。
如果将worker_processes指令的值赋值为8，即赋值为CPU内核个数的两倍，则worker_cpu_affinity指令的设置可以是：

如果一台机器的CPU是八核CPU，并且worker_processes指令的值赋值为8，那么worker_cpu_affinity指令的设置可以是：

** 1.keepalive_timeout指令 **
该指令用于设置Nginx服务器与客户端保持连接的超时时间。
这个指令支持两个选项，中间用空格隔开。第一个选项指定客户端连接保持活动的超时时间，在这个时间之后，服务器会关闭此连接。第二个选项可选，其指定了使用Keep-Alive消息头保持活动的有效时间，如果不设置它，Nginx服务器不会向客户端发送Keep-Alive消息头以保持与客户端某些浏览器（如Mozilla、Konqueror等）的连接，超过设置的时间后，客户端就可以关闭连接，而不需要服务器关闭了。你可以根据自己的实际情况设置此值，建议从服务器的访问数量、处理速度以及网络状态方面考虑。下面是此指令的设置示例：

该设置表示Nginx服务器与客户端连接保持活动的时间是60s，60s后服务器与客户端断开连接。使用Keep-Alive消息头保持与客户端某些浏览器（如Mozilla、Konqueror等）的连接时间为50s，50s后浏览器主动与服务器断开连接。

** 2.send_timeout指令 **
该指令用于设置Nginx服务器响应客户端的超时时间，这个超时时间仅针对两个客户端和服务器之间建立连接后，某次活动之间的时间。如果这个时间后客户端没有任何活动，Nginx服务器将会关闭连接。此指令的设置需要考虑服务器访问数量和网络状况等方面。下面是此指令的设置示例：

该设置表示Nginx服务器与客户端建立连接后，某次会话中服务器等待客户端响应超时10s，就会自动关闭连接。

** 3.client_header_buffer_size指令 **
该指令用于设置Nginx服务器允许的客户端请求头部的缓冲区大小，默认为1KB。此指令的赋值可以根据系统分页大小来设置。分页大小可以用以下命令取得：

有过Nginx服务器工作经验的可能遇到Nginx服务器返回400错误的情况。查找Nginx服务器的400错误原因比较困难，因为此错误并不是每次都会出现，出现错误的时候，通常在浏览器和日志里也看不到任何有关提示信息。根据实际的经验来看，有很大一部分情况是客户端的请求头部过大造成的。请求头部过大，通常是客户单cookie中写入了较大的值引起的。于是适当增大此指令的赋值，允许Nginx服务器接收较大的请求头部，可以改善服务器对客户端的支持能力。一般将此指令赋值为4KB大小，即：

** 4.multi_accept指令 **
该指令用于配置Nginx服务器是否尽可能多的接收客户端的网络连接请求，默认值为off。

本节涉及的指令与Nginx服务器的事件驱动模型密切相关。

其中，number为设置的最大数量。结合worker_processes指令，我们可以计算出Nginx服务器允许同时连接的客户端最大数量Client = worker_processes * worker_connections / 2;
在使用Nginx服务器的过程中，笔者曾经遇到过无法访问Nginx服务器的情况，查看日志发现一直在报如下错误:

根据报错信息，推测可能是Nginx服务器的最大访问连接数设置小了。此指令设置的就是Nginx服务器能接受的最大访问量，其中包括前端用户连接也包括其他连接，这个值在理论上等于此指令的值与它允许开启的工作进程最大数的乘积。此指令一般设置为65535：

此指令的赋值与linux操作系统中进程可以打开的文件句柄数量有关系。按照以上设置修改此项赋值以后，Nginx服务器报以下错误：

究其原因，Linux系统中有一个系统指令open file resource limit，它设置了进程可以打开的文件句柄数量。worker_connections指令的赋值当然不能超过open file resource limit的赋值。可以使用以下命令查看在你的Linux系统中open file resource limit的赋值。

可以通过一下命令将open file resource limit指令的值设为2390251：

这样，Nginx的worker_connections指令赋值为65535就没问题了。

其中，limit为Linux平台事件信号队列的长度上限值。
该指令主要影响事件驱动模型中rfsig模型可以保存的最大信号数。Nginx服务器的每一个工作进程有自己的事件信号队列用于暂存客户端请求发生信号，如果超过长度上线，Nginx服务器自动转用poll模型处理未处理器的客户端请求。为了保证Nginx服务器对客户端请求的高效处理，请大家根据实际的客户端并发请求数量和服务器运行环境的处理能力设定该值。设置示例为：

其中，number为要设置的数量，默认值均为32。

其中，number为要设置的数量，默认值均为512.
使用kequeue_changes方式，可以设置与内核之间传递事件的数量。

其中，number为要设置的数量，默认值均为512。

7.rtsig_signo指令
该指令用于设置rtsig模式使用的两个信号中的第一个，第二个信号是在第一个信号的编号上加1，语法为：

默认的第一个信号设置为SIGRTMIN+10。

提示
在Linux中可以使用一下命令查看系统支持的SIGRTMIN有哪些。

8.rtsig_overflow_* 指令
该指令代表三个具体的指令，分别为rtsig_overflow_events指令、rtsig_overflow_test指令和rtsig_overflow_threshold指令。这些指令用来控制当rtsig模式中信号队列溢出时Nginx服务器的处理方式，语法结构为：

其中，number是要设定的值。
rtsig_overflow_events指令指定队列溢出时使用poll库处理的事件数，默认值为16。
rtsig_overflow_test指令设定poll库处理完第几件事件后将清空rtsig模型使用的信号队列，默认值为32。

rtsig_overflow_threshold指令指定rtsig模式使用的信号队列中的事件超过多少时就需要清空队列了。

5. 初识Nginx配置文件以及基本命令

配置文件名为 nginx.conf ，Linux放在目录： /usr/local/nginx/conf 、 /etc/nginx , 或 /usr/local/etc/nginx 中；Windows放在 安装目录conf 中。 依据实际安装情况决定

nginx由配置文件中指定的指令控制模块组成。 指令分为 简单指令 和 块指令 ：
简单指令 由空格分隔的名称和参数组成，并以分号 ; 结尾；
块指令 具有与简单指令相同的结构，但是是以大括号 { 和 } 包围的一组附加指令。 如果块指令在大括号内部有其他指令，则称为上下文(例如： events ， http ， server 和 location )；
配置文件中放置在任何上下文之外的伪指令都被认为是主上下文。 events 和 http 指令驻留在主上下文中， server 在 http 中的，而 location 在 server 块中。一个配置文件一个 http ，一个及以上个 server ，一个 server 运行一个工作进程并代表一个虚拟服务器；
# 号所在的一行被视为注释；
几个顶级指令将适用于不同流量类型的指令组合在一起：

对于大多数指令，在子上下文中定义的上下文将继承父级中包含的伪指令的值，要覆盖从父进程继承的值，子上下文中需要包含该指令（即子上下文要显式声明）。

打开配置文件(如 /usr/local/nginx/conf/nginx.conf )，默认的配置文件已经包含了服务器块的几个示例，大部分是注释掉的。 现在注释掉所有这样的块，并启动一个新的服务器块：

每个 server 上下文都可以指定要监听的端口、server_name，当nginx决定哪个服务器处理请求后，它会根据服务器块内部定义的location指令的参数测试请求头中指定的URI， 比如如下配置，系统中创建 /data 目录及其子目录 /www ：

第一个 location 块指定与请求中的URI比较 / 前缀。 对于匹配请求，URI将被添加到 root 指令中指定的路径(即 /data/www )，形成本地文件系统中的请求文件路径。 如果有几个匹配的location块，nginx将选择具有最长前缀来匹配location块。 上面第一个 location 块提供最短的前缀长度为1，因此只有当所有其他location块不能提供匹配时，才会使用该块。第二个 location ,将是以 /images/ 的请求来匹配，位置 / 也匹配这样的请求，但具有较短前缀，也就是 /images/ 比 / 长。

这已经是一个在标准端口 80 上侦听并且可以在本地机器上访问的服务器 http://localhost/ 的工作配置， 端口 80 和 server_name localhost 可以省略，它们为默认值 。 响应以/images/开头的URI的请求，服务器将从 /data/images 目录发送文件。 例如，响应 http://localhost/images/logo.png 请求，nginx将发送服务上的 /data/images/logo.png 文件。 如果文件不存在，nginx将发送一个指示 404 错误的响应。 不以 /images/ 开头的URI的请求将映射到 /data/www 目录。 例如，响应 http://localhost/about/example.html 请求时，nginx将发送 /data/www/about/example.html 文件。

反向代理应该是Nginx做的最多的一件事了，反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。
通过向nginx配置文件添加一个server块来定义代理服务器，其中包含以下内容：

这将是一个监听端口 8080 的简单服务器，并将所有请求映射到本地文件系统上的 /data/up1 目录。 请注意，root指令位于server块上下文中，当选择用于服务请求的 location 块不包含自己的 root 指令时，将使用此root指令。创建 /data/up1 目录然后可以将一个静态网页比如 index.html 文件放入其中，然后访问 http://localhost:8080/ 即可访问该文件。
目前为止，还是配置的静态资源访问，并不是代理服务器，然后增加或修改现有 location 上下文，改为如下：

当用户访问 http://localhost:8080/ 时，会返回 http://localhost:8181 服务器的的资源。
location 上下文后面的参数，可以是正则表达式，如果是正则表达式，前面要加 ~ ，比如：

以上配置表示，nginx接收到所有以.gif，.jpg或.png结尾的URI，相应的请求将映射到/data/images目录。当nginx选择一个location块来提供请求时，它首先检查指定前缀的location指令，记住具有最长前缀的location，然后检查正则表达式。 如果与正则表达式匹配，nginx会选择此location，否则选择之前记住的那一个。

要找到最符合URI的位置，NGINX首先将URI与前缀字符串的位置进行比较。然后用正则表达式搜索位置。除非使用^~修饰符对正则表达式给予更高的优先级。在前缀字符串中，NGINX选择最具体的字符串(也就是最长和最完整的字符串)。 下面给出了选择处理请求的位置的确切逻辑：

测试所有URI的前缀字符串。 = (等号)修饰符定义了URI和前缀字符串完全匹配。如果找到完全匹配，则搜索停止。如果 ^~ (插入符号)修饰符预先添加最长匹配前缀字符串，则不会检查正则表达式。存储最长匹配的前缀字符串。根据正则表达式测试URI。断开第一个匹配的正则表达式并使用相应的位置。如果没有正则表达式匹配，则使用与存储的前缀字符串相对应的位置。

= 修饰符的典型用例是 / (正斜杠)的请求。 如果请求/是频繁的，则指定 = / 作为location指令的参数加速处理，因为搜索匹配在第一次比较之后停止。

要启动nginx，请运行可执行文件。 当nginx启动后，可以通过使用-s参数调用可执行文件来控制它。 使用以下语法：

信号(signal)的值可能是以下之一：

当主进程收到要重新加载配置的信号，它将检查新配置文件的语法有效性，并尝试应用其中提供的配置。 如果这是成功的，主进程将启动新的工作进程，并向旧的工作进程发送消息，请求它们关闭。 否则，主进程回滚更改，并继续使用旧配置。 老工作进程，接收关闭命令，停止接受新连接，并继续维护当前请求，直到所有这些请求得到维护。 之后，旧的工作进程退出。

两者在 location 中，指定一个路径，其中使用 alias 做如下配置：

若按照上述配置的话，则访问/img/目录里面的文件时，ningx会自动去/var/www/image/目录找文件

若按照这种配置的话，则访问/img/目录下的文件时，nginx会去/var/www/image/img/目录下找文件。alias是一个目录别名的定义，root则是最上层目录的定义，指的是 /var/www/image/img/ 。还有一个重要的区别是alias后面必须要 / 结束，否则会找不到文件，而root则可有可无。

另外对于index，含义如下

这样，当用户请求 / 地址时，Nginx 就会自动在 root 配置指令指定的文件系统目录下依次寻找 index.htm 和 index.html 这两个文件。如果 index.htm 文件存在，则直接发起“内部跳转”到 /index.htm 这个新的地址；而如果 index.htm 文件不存在，则继续检查 index.html 是否存在。如果存在，同样发起“内部跳转”到 /index.html ；如果 index.html 文件仍然不存在，则放弃处理权给 content 阶段的下一个模块。

参考地址1
参考地址2:B站

6. 跟我学Nginx，nginx 如何处理请求

基于名称（指 HTTP 请求头 Host 字段）的虚拟服务器指通过 HTTP 请求头的 Host 来决定客户端请求由哪个 server 进行处理。

让我们从一个简单的配置开始，下面配置了三个虚拟服务器，它们均侦听 80 端口 ：

上面配置中，nginx 仅测试请求的头字段“Host”以确定应将请求路由到哪个 server。如果“Host”的值与任何 server 名称都不匹配，或者请求根本不包含“Host”头字段，则 nginx 会将请求路由到此端口的默认 server。

上面的配置中，默认 server 是第一个 —— 这是 nginx 的标准默认行为。还可以使用 listen 指令中的 default_server 参数明确设置哪个 server 应该是默认 server：

如果不允许处理没有“Host”头字段的客户端请求（反过来说，只处理带有 Host 头字段的客户端请求），可以定义一个只丢弃请求的 server：

在这里，server_name 设置为一个空字符串，它将匹配没有“Host”头字段的请求，并返回一个特殊的 nginx 非标准代码 444 来关闭连接。

让我们看一个更复杂的配置，其中一些虚拟服务器侦听不同的地址：

上面配置中，nginx 首先根据 server 块的 listen 指令测试请求的 IP 地址和端口。然后，它根据与 IP 地址和端口匹配的 server 块的 server_name 条目测试请求的“Host”标头字段。如果未找到服务器名称，则请求将由默认服务器处理。例如，在 192.168.1.1:80 端口上收到的 www.example.com 请求将由 192.168.1.1:80 端口的默认服务器处理，即由第一个服务器处理，因为没有 www.example .com 为此端口定义。

如前所述，默认服务器是监听端口的一个属性，可以为不同的端口定义不同的默认服务器：

现在让我们看看 nginx 如何选择一个位置来处理一个典型的、简单的 PHP 站点的请求：

无论列出的顺序如何，nginx 首先搜索由文字字符串给出的最具体的前缀位置。在上面的配置中，唯一的前缀位置是“/”，并且由于它匹配任何请求，因此将用作最后的手段。然后 nginx 按照配置文件中列出的顺序检查正则表达式给出的位置。第一个匹配的表达式停止搜索，nginx 将使用这个位置。如果没有正则表达式匹配请求，则 nginx 使用之前找到的最具体的前缀位置。

注意： 所有类型的位置仅测试不带参数的请求行的 URI 部分。这样做是因为查询字符串中的参数可以通过多种方式给出，例如：

此外，任何人都可以在查询字符串中请求任何内容：

现在让我们看看在上面的配置中如何处理请求：

7. nginx 配置详解是什么

Nginx是lgor Sysoev为俄罗斯访问量第二的rambler.ru站点设计开发的。从2004年发布至今，凭借开源的力量，已经接近成熟与完善。

Nginx功能丰富，可作为HTTP服务器，也可作为反向代理服务器，邮件服务器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。并且支持很多第三方的模块扩展。

Nginx的稳定性、功能集、示例配置文件和低系统资源的消耗让他后来居上，在全球活跃的网站中有12.18%的使用比率，大约为2220万个网站。

1、全局块：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。

2、events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。

3、http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。

4、server块：配置虚拟主机的相关参数，一个http中可以有多个server。

5、location块：配置请求的路由，以及各种页面的处理情况。

Nginx常用功能。

1、Http代理，反向代理：作为web服务器最常用的功能之一，尤其是反向代理。

Nginx在做反向代理时，提供性能稳定，并且能够提供配置灵活的转发功能。Nginx可以根据不同的正则匹配，采取不同的转发策略，比如图片文件结尾的走文件服务器，动态页面走web服务器，只要你正则写的没问题，又有相对应的服务器解决方案。

。并且Nginx对返回结果进行错误页跳转，异常判断等。如果被分发的服务器存在异常，他可以将请求重新转发给另外一台服务器，然后自动去除异常服务器。

2、负载均衡

Nginx提供的负载均衡策略有2种：内置策略和扩展策略。内置策略为轮询，加权轮询，Ip hash。扩展策略，就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他一一找出来做下实现。

8. 13《Nginx 入门教程》Nginx负载均衡(下)

这一小节中，我们将实战 Nginx 的四层和七层负载均衡功能。条件有限，使用一台公网主机，在上面搭建好 Nginx 服务。公网 IP 为 180.76.152.113。

首先会进行简单的四层负载均衡实验，不会涉及多种负载均衡算法，只使用默认的 Round-Robin算法。在后续的七层负载均衡实验中，会重点测试不同的负载均衡策略，完成相关实验。

首先在 nginx.conf 中添加如下 stream 指令块配置:

上述配置用端口3000和3001模拟两个上游服务器，然后在 upstream 指令块中指定这两个上游服务器的地址，同时给第一个设置权重为2。由于默认采用的是加权的 Round-Robin 算法，默认服务器的权重为1。设置为2，表明3次请求中，2次会转发到3000端口，一次会转发到3001端口，下面的测试也验证了这一点。

和四层的配置其实差不多，在七层中除了测试最基本的，我们还将测试前面提到的几种负载均衡策略，进一步熟悉 Nginx 中的负载均衡配置。

在 nginx.conf 中添加如下的 http 指令块:

上述配置中，我们用8000，8001和8002三个端口模拟了3个上游服务器，默认使用轮询负载均衡算法，而且三个的权重均为1。进行如下的 http 请求操作，可以看到 Nginx 转发 http 请求会均匀地分配到3个服务器上。

我们打开 ip_hash 指令的注释，这个时候默认是使用客户端的 ip 地址作为 hash 的 key，然后重启 Nginx 服务并进行如下的命令行操作：

接下来，注释 ip_hash 指令，我们打开 hash user_$arg_username 这行配置的注释， hash 指令可以让我们根据我们设置的 key 进行 hash，然后根据 hash 值选择上游的服务器。具体测试参看下面的 Linux 命令：

这里我们可以看到，在请求中带上 username 参数，Nginx 中配置的 hash 算法会根据请求中带的 username 参数作为 key 去进行 hash，然后在根据 hash 结果映射上游服务器。username 相同时，选择的上游服务器肯定是一样的，只有在 username 的值发生变化时，返回的响应才可能有变化。

今天我们完成了几个测试实验，主要是针对 Nginx 的四层和七层的负载均衡功能进行了测试。这个功能在微服务部署中会有较多的应用。因为高流量企业为保证服务的高可用性，往往会水平扩展多个相同功能的服务，部署在多台主机上，这个时候负载均衡技术就能派上用场了，而 Nginx 提供了完善的负载均衡功能以及多种负载均衡算法，能满足大部分企业的需求，如果还不够，可以通过编写内部开发模块并集成到 Nginx，实现相应的需求。所以说 Nginx 是非常值得学习和深入研究的。

9. Nginx配置文件详解

说到该指令 ，首先得阐述一下什么是所谓的 “惊群问题”，可以参考 WIKI网络的解释。就Nginx的场景来解释的话大致的意思就是：当一个新网络连接来到时，多个worker进程会被同时唤醒，但仅仅只有一个进程可以真正获得连接并处理之。如果每次唤醒的进程数目过多的话，其实是会影响一部分性能的。

所以在这里，如果accept_mutex on，那么多个worker将是以串行方式来处理，其中有一个worker会被唤醒；反之若accept_mutex off，那么所有的worker都会被唤醒，不过只有一个worker能获取新连接，其它的worker会重新进入休眠状态。

用rewrite转发的话，url会发生变化的，那就用proxy_pass吧，于是添加了如下的配置：

在现有环境的nginx里添加这段配置之后，访问却始终转不过去，查看nginx日志也只能看到是404信息，并没有更多定位问题的信息。检查了许久也没找到原因，于是重新装了一台新nginx，里面只加上面这段配置，结果nginx是能够转发成功的，这说明单独来看这条location的配置是没有问题的，很有可能是现有环境nginx里的某些配置影响到了这个转发。

为了定位问题原因，我将aaa.example.com虚拟主机下的其他配置注意注释掉来调试，最后发现当注释掉proxy_set_header Host $http_host ;这条配置之后，就能成功转发了。这才注意到是反向代理配置的问题。现有环境中原有的配置也不能随便删掉，上网查了下原因，找到下面这种解决方案：

即，在location里面添加一条proxy_set_header Host http_host时，则不改变请求头的值，所以当要转发到bbb.example.com的时候，请求头还是aaa.example.com的Host信息，就会有问题；当Host设置为$proxy_host时，则会重新设置请求头为bbb.example.com的Host信息。

另外，关于proxy_pass转发url的参数，可以通过在location中用rewrite来做，所以完善后的配置如下：

在location用rewrite改变了URI之后，proxy_pass将使用改变后的URI。上面例子(.*)是将所有参数传给 1会拼接在 http://bbb.example.com 后面。

先来看下proxy_set_header的语法

允许重新定义或者添加发往后端服务器的请求头。value可以包含文本、变量或者它们的组合。 当且仅当当前配置级别中没有定义proxy_set_header指令时，会从上面的级别继承配置。 默认情况下，只有两个请求头会被重新定义：

当匹配到/customer/straightcustomer/download时，使用crmtest处理，到upstream就匹配到crmtest.aty.sohuno.com，这里直接转换成IP进行转发了。假如crmtest.aty.sohuno.com是在另一台nginx下配置的，ip为10.22.10.116，则$proxy_host则对应为10.22.10.116。此时相当于设置了Host为10.22.10.116。如果想让Host是crmtest.aty.sohuno.com，则进行如下设置：

如果不想改变请求头“Host”的值，可以这样来设置：

但是，如果客户端请求头中没有携带这个头部，那么传递到后端服务器的请求也不含这个头部。 这种情况下，更好的方式是使用$host变量——它的值在请求包含“Host”请求头时为“Host”字段的值，在请求未携带“Host”请求头时为虚拟主机的主域名：

此外，服务器名可以和后端服务器的端口一起传送：

如果某个请求头的值为空，那么这个请求头将不会传送给后端服务器：

nginx配置项，里面的配置项有代理https，http，代理静态文件，H5分发，代理TCP连接，能满足大多数搭建测试环境所要用的nginx的情况，大家碰到要使用nginx的时候可以参考下

10. nginx如何配置代理

nginx源码： https://trac.nginx.org/nginx/browser

nginx官网： http://www.nginx.org/

... #全局块

events { #events块

...

}

http #http块

{

}

1、全局块：全局模块影响nginx的全局指令，一般有运行nginx服务器的用户，nginx进程pid存放路劲，日志存放路径，配置文件引入，允许生成worker，process数。

2、events块：配置影响nginx服务器或与用户的网络连接， ，有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个连接，开启多个网络连接序列化。

3、http块：可以嵌套多个server，配置代理，缓存

4、server块：配置虚拟主机参数，一个http中有多个server

5、location块：配置请求的路由。

########### 每个指令必须有分号结束。#################

error_log log/error.log debug; #制定日志路径，级别。这个设置可以放入全局块，http块，server块，级别以此为：

debug|info|notice|warn|error|crit|alert|emerg

events {

} http {

}

四、nginx的简单命令

五、配置解析

server {

1、location 支持配置项目的绝对路径

2、假设我们的后台API地址是以API开头，location ^~ /user/ 代表nginx将会拦截请求地址中包含"/user/"字样的请求，其实这就是我们的ajax请求路径，拦截到请求之后根据写法会分成两种情况把这个请求转发到 下面 proxy_pass 的地址上。

举个例子:

a、如上图，如果proxy_pass 的URL以 / 结尾 ，那么请求转发的时候 将 不会 带上 匹配到的 /api/ ，也就是说如果 登录请求 URL是 localhost:80/user/login，proxy_pass URL 是 http://a.xx.com:8080/platform/， Nginx将会 把这个请求转发成 http://a.xx.com:8080/platform/user/login

b、如果proxy_pass 的URL不以 / 结尾 ，那么请求转发的时候 将 会带上 匹配到的 /user/ ，也就是说如果 登录请求 URL是 localhost:60001/user/login，proxy_pass URL 是 http://a.xx.com:8080/platform/， Nginx将会 把这个请求转发成 http://a.xx.com:8080/user/login

3、一般我们登录之后服务器会通过Set-Cookie把token写回到我们本地，如果不设置 proxy_cookie_path 的话，服务器Set-Cookie命令会失效，本地存不了cookie，从而导致token丢失。

这里proxy_cookie_path有一点需要注意的是 如果 proxy_pass URL 是 http://a.xx.com:8080/user/ 这种情况 proxy_cookie_path应该设置成 /platform/ / (注意两个斜杠之间有空格)。

如果 proxy_pass URL 是 http://a.xx.com:8080/这种情况 proxy_cookie_path应该设置成 / / (注意两个斜杠之间有空格)

语法规则：location [=| | *|^~] /uri/ { … }