Nginx配置文件使用 | 飙戈的博客

type

status

date

slug

summary

1、配置文件介绍

Nginx 的配置文件在安装目录 conf 文件夹下，名为 nginx.conf。这是 Nginx 的核心文件，服务器的基础配置，默认的配置都放在这个配置文件里面。nginx.conf 的大体结构如下所示：

这个配置文件一共由三部分组成，分别为全局块、events 块和 http 块。

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

events 块：配置影响 nginx 服务器或与用户的网络连接。常用的设置有：是否开启对多 work process 下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 word process 可以同时支持的最大连接数等。

http 块：http 块是 Nginx 服务器配置中的重要部分，代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里。

http 全局块：http 全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。
server 块：配置虚拟主机的相关参数，一个 http 块可以包含多个 server 块。

server 全局块：和http块相同，server块也可以包含自己的全局块。最常见的配置是本虚拟机主机的 listen 监听配置和本虚拟主机的 server_name 名称配置。
location 块：对除虚拟主机 server_name 名称之外的字符串进行匹配。地址定向、数据缓存和应答控制等功能都是在这部分实现。许多第三方模块的配置也是在 location 块中提供功能。一个 server 块可以多个 location 块。

upstream 块：主要配置均衡负载的服务器。

配置文件支持大量可配置的指令，绝大多数指令不是特定属于某一个块的。同一个指令放在不同层级的块中，其作用域也不同，一般情况下，高一级块中的指令可以作用于自身所在的块和此块包含的所有低层级块。如果某个指令在两个不同层级的块中同时出现，则采用“就近原则”，即以较低层级块中的配置为准。比如，某指令同时出现在 http 全局块中和 server 块中，并且配置不同，则应该以 server 块中的配置为准。

1.1 全局块

全局块是默认配置文件从开始到 events 块之间的一部分内容，主要设置一些影响 Nginx 服务器整体运行的配置指令，因此，这些指令的作用域是 Nginx 服务器全局。

通常包括配置运行 Nginx 服务器的用户（组）、允许生成的 worker process 数、Nginx 进程 PID 存放路径、日志的存放路径和类型以及配置文件引入等。

1.2 events块

events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接。常用到的设置包括是否开启对多 worker process 下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型处理连接请求，每个 worker process 可以同时支持的最大连接数等。

这一部分的指令对 Nginx 服务器的性能影响较大，在实际配置中应该根据实际情况灵活调整。

1.3 http块

http 块是Nginx服务器配置中的重要部分，代理、缓存和日志定义等绝大多数的功能和第三方模块的配置都可以放在这个模块中。

前面已经提到，http 块中可以包含自己的全局块，也可以包含 server 块，server 块中又可以进一步包含 location 块。在本文中我们使用“http全局块”来表示 http 中自己的全局块，即 http 块中不包含在 server 块中的部分。

可以在 http 全局块中配置的指令包括文件引入、MIME-Type定义、日志自定义、是否使用sendfile传输文件、连接超时时间、单连接请求数上限等。

1.4 server块

server 块和“虚拟主机”的概念有密切联系。虚拟主机是一种在单一主机或主机群上运行多个网站或服务的技术。每一个 http 块都可以包含多个 server 块，而每个 server 块就相当于一台虚拟主机。

和 http 块相同，server 块也可以包含自己的全局块，同时可以包含多个 location 块。

在 server 全局块中，最常见的两个配置项是本虚拟主机的监听（listen）配置和本虚拟主机的名称或IP（server_name）配置。

1.4.1 listen指令

server 块中最重要的指令就是 listen 指令，这个指令有三种配置语法。这个指令默认的配置值是： listen *:80 | *:8000 ，只能在server块种配置这个指令。

关于上面的一些重要参数做如下说明：

address：监听的 IP 地址（请求来源的IP地址），如果是IPv6的地址，需要使用中括号“[]”括起来，比如[fe80::1]等。

port：端口号，如果只定义了IP地址没有定义端口号，就使用 80 端口。这边需要做个说明：要是你压根没配置 listen 指令，如果 nginx 以超级用户权限运行，则使用 :80 ，否则使用 :8000。多个虚拟主机可以同时监听同一个端口s，但是 server_name 需要设置成不一样；

default_server：假如通过 Host 没匹配到对应的虚拟主机，则通过这台虚拟主机处理。具体的可以参考这篇文章，写的不错。

backlog=number：设置监听函数 listen() 最多允许多少网络连接同时处于挂起状态，在 FreeBSD 中默认为 -1，其他平台默认为 511。

accept_filter=filter：设置监听端口对请求的过滤，被过滤的内容不能被接收和处理。本指令只在 FreeBSD 和 NetBSD 5.0+ 平台下有效。filter 可以设置为 dataready 或 httpready，感兴趣的读者可以参阅 Nginx 的官方文档。

bind：标识符，使用独立的 bind() 处理此 address:port；一般情况下，对于端口相同而 IP 地址不同的多个连接，Nginx 服务器将只使用一个监听命令，并使用 bind() 处理端口相同的所有连接。

ssl：标识符，设置会话连接使用 SSL 模式进行，此标识符和 Nginx 服务器提供的 HTTPS 服务有关。

listen 指令的使用看起来比较复杂，但其实在一般的使用过程中，相对来说比较简单，并不会进行太复杂的配置。

1.4.2 server_name指令

用于配置虚拟主机的名称。语法是：

对于name 来说，可以只有一个名称，也可以由多个名称并列，之间用空格隔开。每个名字就是一个域名，由两段或者三段组成，之间由点号“.”隔开。比如

在该例中，此虚拟主机的名称设置为 myserver.com 或www. myserver.com。Nginx 服务器规定，第一个名称作为此虚拟主机的主要名称。

在 name 中可以使用通配符 *，但通配符只能用在由三段字符串组成的名称的首段或尾段，或者由两段字符串组成的名称的尾段，如：

另外 name 还支持正则表达式的形式。由于 server_name 指令支持使用通配符和正则表达式两种配置名称的方式，因此在包含有多个虚拟主机的配置文件中，可能会出现一个名称被多个虚拟主机的 server_name 匹配成功。那么，来自这个名称的请求到底要交给哪个虚拟主机处理呢？Nginx 服务器做出如下规定：

准确匹配 server_name

通配符在开始时匹配 server_name 成功

通配符在结尾时匹配 server_name 成功

正则表达式匹配 server_name 成功

默认匹配，在 listen 指令中指明了 default_server 的 server 块，若无，为配置文件中第一个声明的 server 块

在以上匹配方式中，如果 server_name 被处于同一优先级的匹配方式多次匹配成功，则首次匹配成功的虚拟主机处理请求。

1.5 location块

每个 server 块中可以包含多个 location 块。在整个 Nginx 配置文档中起着重要的作用，而且 Nginx 服务器在许多功能上的灵活性往往在 location 指令的配置中体现出来。

location 块的主要作用是：基于Nginx服务器接收到的请求字符串（例如 server_name/uri-string），对除虚拟主机名称（也可以是 IP 别名）之外的字符串（前例中 /uri-string部分）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能都是在这部分实现。许多第三方模块的配置也是在 location 块中提供功能。

location 块的语法结构为：

其中，uri 变量是待匹配的请求字符串，可以是不含正则表达的字符串，如 /myserver.php等；也可以是包含有正则表达的字符串，如 .php$（表示以 .php 结尾的URL）等。为了下文叙述方便，我们约定，不含正则表达的uri称为标准uri，使用正则表达式的uri称为正则uri。

方括号里的部分是可选项，用来改变请求字符串与 uri 的匹配方式，匹配规则按优先级排序为：

=：精确匹配，用于标准uri 前，要求请求字符串与 uri 严格匹配。如果已经匹配成功，就停止继续向下搜索并立即处理此请求。

^~：忽略正则表达式的前缀匹配，用于标准 uri 前，Nginx 服务器找到标识 uri 和请求字符串匹配度最高的 location 后，立即使用此 location 处理请求，而不再使用 location 块中的正则 uri 和请求字符串做匹配。

～：正则匹配，大小写敏感

～*，正则匹配，大小写不敏感

!~：正则不匹配，大小写敏感

!~*：正则不匹配，大小写不敏感

没有修饰符：普通最长前缀匹配

uri 和 location 的匹配过程如下：

进行最长前缀匹配查找，这里按顺序进行三种查找：

查找 = 修饰的精确匹配，如果找到就结束查找。
查找 ^~ 修饰的前缀匹配，如果找到就结束查找。
查找没有修饰符的普通前缀匹配，记录一个匹配度最高的最长前缀匹配，作为下面备用。

进行正则匹配查找，按照正则匹配在文件中出现的顺序，如果找到就结束查找。

如果正则匹配全部匹配失败，就使用第 1.3 步的记录的匹配度最高的最长普通前缀匹配。

1.6 upstream块

upstream 块用于设置反向代理及后端服务器的负载均衡。当我们需要把请求转发到多台服务器上时，就需要用到 upstream 的功能：

通过 upstream 来定义一组服务器，并指定负载策略（IPHASH、加权论调、最少连接），健康检查策略（Nginx 可以监控这一组服务器的状态）等。

把 location 块中的 root 替换成 proxy_pass，然后使用 proxy_pass 指向 upstream 块即可。

语法如下：

均衡负载的五种策略：

轮询：默认，每一个请求按时间顺序逐一分配到不同的后端服务器。

加权轮询：按权重指定每个服务器的访问概率，权重越大服务器访问量越高，适用于服务器资源不均衡的场景。

最少连接：遍历后端集群，比较每个后端的 conns/weight，选取该值最小的后端。如果有多个后端的 conns/weight 值同为最小的，那么对它们采用加权轮询算法。

ip_hash：每一个请求按访问 ip 的 hash 结果分配。可以把一个 ip 的请求绑定到同一个服务器上，可以解决 session 的问题。

fair（第三方）：按后端服务器的响应时间来分配请求。响应时间短的优先分配。与 weight 分配策略相似。

url_hash（第三方）：按访问 url 的 hash 结果来分配请求，使每一个 url 定向到同一个后端服务器。

2、多个配置文件设置

Nginx 的配置默认在 /usr/local/etc/nginx/nginx.conf 里，但是如果我们有多个虚拟主机需要配置的话，全部写在 nginx.conf 下会很臃肿，因此 Nginx 提供 include 包含其他配置文件的方式帮助我们解决这个问题。

include 参数一般放在 http 块里面，作用包含其他扩展配置文件。include 文件路径可以是绝对路径，也可以是相对路径，相对路径以 nginx.conf 为基准，还可以使用通配符。

例如我们在 http 块的最后加了一段 include conf.d/*.conf; ，意思就是该配置文件包含 nginx.conf 的同级目录下的 conf.d 文件夹下所有 .conf 结尾的文件。

然后在 nginx.conf 的同级目录下创建一个 conf.d 的文件夹，然后创建自己的 myserver.conf 文件。

myserver.conf 文件填入以下内容并保存。