和大多数软件一样，Nginx也有自己的配置文件，但它又有很多与众不同的地方，本帖就来揭开Nginx基础配置的面纱。

1、Nginx指令和指令块

了解指令和指令块有助于大家了解配置的上下文，下面是一个配置模板示例：

在这个配置模板中主要包含两种指令：

• 简单指令：由名称和参数组成，以空格分隔，以分号结尾。上述示例中的Main 1、Main 2、Main 3就是简单指令。
• 指令块：由名称和大括号{}内的附加指令组成，不以分号结尾。

在前面的配置示例中，http块是全局参数，对整体产生影响；server块是虚拟主机，主要对指定的主机和端口进行配置；location块在虚拟主机下根据请求URI（Uniform Resource Identifier，统一资源标识符）进行配置，URI即去掉参数后的URL。

简单指令在指令块中的配置存在一定的区段。有些简单指令不能在某些指令块中使用；而有些简单指令既可以在http块也可以在server块中配置，甚至可以在location块中配置。当某个变量同时出现在多个指令块中时，最终会以在最小指令块中的赋值为准。

例如，如果在location中设置expires为1m，那么expires就会使用location中的设置；如果没有在location中设置expires，那么expires的值则会使用http块中的1d。这有点类似于编程语言里的变量。

2、Nginx基本配置说明

对指令和指令块有了初步了解之后，下面将根据前面的配置示例，对Nginx的指令块进行逐一说明，以帮助大家理解每个指令块的作用。

2.1、main配置

在http块之前的配置是全局参数，如前面配置示例中的Main 1，全局参数对整个Nginx块都产生作用。下面是一个简单示例：

2.2、与客户端有关的配置

与客户端有关的配置主要在http块中设置，如前面配置中的指令Main 1和server块之间的Main 2就是对客户端进行的配置，其作用是处理与客户端相关的信息。客户端配置常用的指令见下表：

很多指令都可以在多个Main中配置，但不是所有的指令都可以出现在2.1节的配置中的Main 1、Main 2和Main 3里面。例如client_body_timeout可以在http、server、location块中设置，但server_names_hash_bucket_size却只能出现在http块中。

上表中的指令和客户端的请求操作有直接关系，熟悉这些指令对配置和优化Nginx有很大的帮助。

2.3、server块

server块即虚拟主机部分，如果请求中的Host头和server_name相匹配，则将请求指向对应的server块，示例如下：

server_name支持使用通配符正则表达式，支持配置多域名、服务名称。当有多个server块时，会存在匹配的优先级问题，优先级顺序如下：
1.精确的名字；
2.以开头的最长通配符名称，如.testnginx.com；
3.以结尾的最长通配符名称，如testnginx.；
4.按照文件顺序，第1个匹配到的正则表达式；
5.如果没有匹配到对应的server_name，则会访问default_server。

2.4、location块

location块在server块中使用，它的作用是根据客户端请求URL去定位不同的应用。即当服务器接收到客户端请求之后，需要在服务器端指定目录中去寻找客户端所请求的资源，这就需要使用请求URL匹配对应的location指令。下表是URL在location块中的匹配规则说明：

上表中匹配的优先级顺序为如下：
“=”优先级最高，如果“=”匹配不到，会和“^～”进行匹配；继而是“～”，如果有多个“～”，则按照在文件里的先后顺序进行匹配；如果还匹配不到，则与“/uri”进行匹配；通用匹配“/”的优先级最低，如果找不到其他配置，就会进行通用匹配；“@”表示命名空间的位置，通常在重定向时进行匹配，且不会改变URL的原始请求。

建议：打开Debug模式并观察日志，会看到每个请求的执行过程，包括匹配到对应location的操作。

location块也支持嵌套配置：

有些指令只能在location块中执行，主要有如下3个：

• internal：表示该location块只支持Nginx内部的请求访问，如支持rewrite、error_page等重定向，但不能通过外部的HTTP直接访问。
• limit_except：限定该location块可以执行的HTTP方法，如GET。
• alias：定义指定位置的替换，如可以使用以下配置。
  
  上述配置表示如果匹配到/a/test.json的请求，在进入 location块后，会将请求变成/c/x/a/test.json。

3、include的使用

include用来指定主配置文件包含的其他扩展配置文件。扩展文件的内容也要符合Nginx的格式规范。include可以简化主配置文件，使之更易于读取。include可以出现在全局参数、location块、server块等任何一个位置。

include支持通配符，例如下面的配置会将后缀是.conf的所有文件都加载到Nginx配置中：

因此，可以将Nginx配置成多个文件，并提取出相同的数据，从而精简配置，方便管理。

4、常见配置

前面的介绍了Nginx中的main指令、server块、location块、include，以及与客户端相关的一些配置知识，本节将进一步介绍Nginx常见的配置及其实战技巧。

4.1、常见配置注解

4.2、常见配置实战技巧

学完常见配置的注解，相信大家已经对Nginx配置有了基本的认识。但在实际应用中，Nginx配置可以通过巧妙的变化实现不同的功能，下面将会讲解在实战中应如何进行合理的配置。

• user：默认是nobody，但如果使用nobody，会导致没有权限执行写硬盘等操作。所以一般会选择低于root级别的用户，如www，并在Linux系统下禁止用户通过SSH（Secure Shell，远程连接工具）登录服务器，以提高安全性。
• worker_processes：代表worker的进程数，一般情况下建议和服务器的CPU（Central Processing Unit，中央处理器）核数相同；也可以配置worker_processes auto（用于Nginx 1.2.5版本之后），它会自动根据CPU核数启动进程。但在实际应用中，可能除Nginx外服务器还会同时运行其他多个服务，所以需要考虑服务器资源在不同服务上的分配，避免因进程启动过多导致过多的上下文切换。
• worker_cpu_affinity auto：这是在Nginx 1.9.10版本中添加的功能，表示可以根据服务器的CPU核数自动设置CPU亲缘性，以提升Nginx的性能。
• error_log & access_log：关于日志记录的配置。如果将error_log配置为error级别，可以减少不必要的日志记录；如果是测试环境可以设置为info级别。配置日志记录需要考虑硬盘的独立性，不要使用Linux的根分区，以避免出现大量的I/O影响Linux服务器的吞吐能力；要单独挂载到一个磁盘上，使用独立的I/O。另外，需要注意硬盘的使用寿命，关注message的日志，定期检查硬盘（Nginx在记录日志时是异步处理的，因此不会因为硬盘问题导致请求异常，但会影响日志的记录）。
• worker_priority：配置Nginx在Linux服务器上使用资源的优先级，作为反向代理服务，Nginx应该拥有极高的优先级，因此建议配置为-10。
• gzip_comp_level：配置压缩等级，等级最高为9，等级越高压缩后的文件越小，但是消耗的CPU资源，也会越多。经测试，文件压缩等级为7和等级为9时，在文件大小上只有细微的差别，一般用5～7的等级就可以了。
• upstream块：配置后端服务器，可以结合 proxy_next_upstream等指令进行大量的优化。
• error_page：对错误进行重定向，在捕获后端服务器错误的状态码后，将请求重定向到其他位置，如友好提示页面。
• location & root：通过root路径可以读取静态文件，在Nginx 1.7.11版本之前，当Nginx读取硬盘文件时，都是进行阻塞型操作；后来引入了线程池，为读取硬盘文件提供了非阻塞型的操作，极大地提升了硬盘I/O的读/写速度，也提升了proxy_cache的缓存能力。

Nginx的常见配置在使用中有着不同的变化，熟悉Nginx的官方Wiki是发挥其巨大作用的前提。

5、内置变量

在客户端请求过程中，Nginx提供了内置变量来获取HTTP或TCP的信息。充分了解这些内置变量，才能够对应用场景中的业务进行合理的配置，下面先来熟悉一下常见的内置变量。

注意：Nginx 1.9之后的版本开始支持TCP代理，这使Nginx的功能更为丰富（后面会有单独的介绍和案例示范）。本书默认以HTTP代理为例进行讲解，中间涉及TCP的地方会有特别说明。

5.1、常见内置变量

注意：随着Nginx版本的不断更新，会出现更多新的指令，更多与Nginx内置变量有关的解释可参考Nginx 官方Wiki。

5.2、常见内置变量实战技巧

Nginx的内置变量主要用于日志记录和分析，以及业务逻辑的处理。下面将介绍一些常用内置变量的配置方式。
1、$arg_name：

上述代码的请求默认路径是http://a，如果URL中的参数是at=5，则路径变为http://b。

2、　$body_bytes_sent和$bytes_sent：

这两个变量的值之差就是HTTP 响应头的大小。如果两个值相差悬殊，那么响应头就很大，需要确保proxy_buffer设置了合适的大小，因为如果超过proxy_buffer设置的值，error.log就会显示如下内容：

3、$realip_remote_addr：
在Nginx 1.9.7版本以后加入ngx_http_realip_module的变量，此变量可以获取用户的IP地址（如常见的代理或CDN的节点IP地址）。
4、$request_time和$upstream_response_time：
$upstream_response_time指的是在Nginx启用了upstream的情况下，从Nginx与后端建立连接开始到接收完数据然后关闭连接为止的时间。$request_time指从接收到用户请求到发送完响应数据的时间，包括接收请求数据的时间、程序响应的时间和输出响应数据的时间。如果要检查后端服务的性能，需要使用$upstream_response_time的值。
5、$uri和$request_uri：
$uri记录的是执行一系列内部重定向操作后最终传递到后端服务器的URL（不包含参数$args的值）。

$request_uri记录的是当前请求的原始URL（包含参数），如果没有执行内部重定向操作，$request_uri去掉参数后的值和$uri的值是一样的。在线上环境中排查问题时，如果在后端服务中看到的请求和在Nginx中存放的$request_uri无法匹配，可以考虑去 $uri里面进行查找。

6、$scheme：
近几年来，HTTPS非常流行，很多互联网企业都把HTTP切换成了HTTPS，但是当用户手动输入网站地址时，很少会主动加上https://。为了让用户的请求能够顺利跳转到HTTPS，首先需要判断用户输入的是HTTP还是HTTPS。$scheme就具有此功能，如果用户输入的是HTTP可以通过重定向跳转到HTTPS，示例代码如下：