摘要：
2.事件块事件块中涉及的指令主要影响Nginx服务器与用户之间的网络连接。这部分指令对nginx服务器的性能影响很大，应在实际配置中根据实际情况灵活调整。3.http块是Nginx服务器配置的重要部分。大多数功能，如代理、缓存和日志定义以及第三方模块的配置都可以放在这个模块中。
2.4.1 nginx.conf文件的结构
2.4.2配置运行Nginx服务器用户（组）
2.4.3配置允许生成的worker process数
2.4.4 配置Nginx进程PID存放路径
2.4.5配置错误日志的存放路径
2.4.6 配置文件的引入
2.4.7 设置网络连接的序列化
2.4.8设置是否允许同时接收多个网络连接
2.4.9事件驱动模型选择
2.4.10配置最大连接数
2.4.11 定义MIME-Type
2.4.12自定义服务日志
2.4.13配置允许sendfile方式传输文件
2.4.14配置连接超时时间
2.4.15 单连接请求数上限
2.4.16 配置网络监听
2.4.17基于名称的虚拟主机配置
2.4.18 基于IP的虚拟主机配置
2.4.19配置location块
2.4.20配置请求的根目录
2.4.21 更改location的URI
2.4.22 设置网站的默认首页
2.4.23 设置网站的错误页面
2.4.24 基于IP配置Nginx的访问权限
2.4.25基于密码配置Nginx的访问权限
2.4.1 nginx.conf文件的结构
默认的Nginx服务器配置文件都存放在安装目录conf中，主配置文件名为 nginx.conf。
nginx.conf默认配置如下：
worker_processes 1；
#全局生效
events {
worker_connections 1024;
#在 events部分中生效
}
http {
include mime.types;
#以下指令在http部分中生效
default_type application/octet-stream;
sendfile on；
keepalive_timeout 65;
server {
#以下指令在http的 server 部分中生效
listen 80;
server_name localhost;
location / {
#以下指令在http/server的location中生效
root html;
index index.html index.htm；
}
error_page 500 502 503 504 /50x.html;
location = /50x.html{
root html;
}
}
}
nginx.conf 文件结构
nginx.conf 文件的基本结构
...
#全局块
events
#events块
{
...
}
http
#http块
{
...
#http全局块
server
#server块
{
...
#server全局快
location [PATTERN]
#location块
{
...
location [PATTERN]
#location块
{
...
}
}
server
#server块
{
...
}
... #http全局块
}
nginx.conf 一共由三部分组成，分别为：全局块、events块 和 http块。
在http块中又包含：http全局块、多个server块、每个server块中可以包含 server全局块和多个 location 块。
在同一配置块中嵌套的配置块，多个之间不存在次序关系
配置文件支持大量可配置的指令，绝大多数指令不是特定属于某一个块的。同一个指令放在不同层级的块中，其作用域也不同，一般情况下，高一级块中的指令可以作用于自身所在的块和此块包含的所有低层级块。如果某个指令在两个不同层级的块中同时出现，则采用“就近原则”，即以较低层级块中的配置为准。比如，某指令同时出现在 http 全局块中和server块中，并且配置不同，则应该以 server 块中的配置为准。}
各个块的作用：
1.全局块
全局块是默认配置文件从开始到 events块之间的一部分内容，主要设置一些影响Nginx服务器整体运行的配置指令，因此，这些指令的作用域是 Nginx 服务器全局。
通常包括配置运行Nginx服务器的用户（组）、允许生成的 worker process数、Nginx进程PID存放路径、日志的存放路径和类型以及配置文件引入等。
2.events块
events块涉及的指令主要影响Nginx服务器与用户的网络连接。常用的设置包括是否开启对多worker process下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型处理连接请求，每个 worker process可以同时支持的最大连接数等。
这一部分指令对nginx服务器的性能影响较大，在实际配置中应该根据实际情况灵活调整。
3.http块
http块是Nginx服务器配置中的重要部分，代理、缓存和日志定义等绝大多数的功能和第三方模块的配置都可以放在这个模块中。
http块中可以包含自己的全局块，也可以包含server块，server块中又可以进一步包含location块，在本文中使用“http全局块”来表示http中自己的全局块，即http块中不包含在server块中的部分。
可以在http全局块中配置的指令包括文件引入、MIME-Type定义、日志自定义、是否使用sendfile传输文件、连接超时时间、单连接请求数上限等。
4.server块
server块和“虚拟主机”的概念有密切联系。
虚拟主机：又称为虚拟服务器、主机空间或网页空间，是一种技术。该技术是为了节省互联网服务器硬件成本出现的。这里的'主机'或'空间'是由实体的服务器延伸而来，硬件系统可以基于服务器群，或者单个服务器等。虚拟主机技术主要应用于HTTP、FTP及EMAIL等多项服务，将一台服务器的某项或者全部服务内容逻辑划分为多个服务单位，对外表现为多个服务器，从而充分利用服务器硬件资源。一台虚拟机和一台独立的硬件主机是完全一样的。
在使用Nginx服务器提供Web服务时，利用虚拟主机的技术就可以避免为每一个要运行的网站提供单独的Nginx服务器，也无需为每个网站对应运行一组Nginx进程。虚拟主机技术使得Nginx服务器可以在同一台服务器上只运行一组Nginx进程，就可以运行多个网站。
对server块进行配置就可以完成这个功能
每一个http块都可以包含多个server块，每个server块就相当于一台虚拟主机，它内部可以有多台主机联合提供服务，一起对外提供在逻辑上关系密切的一组服务（或网站）。
server全局块中常见的指令及其配置。server全局块指令的作用域为本server块，其不会影响到其他的server块。
注意：在http全局块中介绍过的部分指令可以在server块中和location块中使用。
和http块相同，server块也可以包含自己的全局块，同时可以包含多个location块。在server全局块中，最常见的两个配置项时本虚拟主机的监听配置和本虚拟主机的名称或IP配置。
5.location块
每个server块中可以包含多个 location块。location其实是server块的一个指令，至少由于其在整个Nginx配置文档中起着重要的作用，而且Nginx服务器在许多功能上的灵活性往往在location指令的配置中体现出来。
这些location块的主要作用是，基于Nginx服务器接收到的请求字符串（例如，server_name/ uri-string)，对除虚拟主机名称（也可以是IP别名）之外的字符串（“uri-string”部分）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能都是在这部分实现。许多第三方模块的配置也是在location块中提供功能。
2.4.2 配置运行Nginx服务器用户（组）
用于配置运行Nginx服务器用户（组）的指令是 user，其语法格式为：
user user[group]；
user，指定可以运行Nginx服务器的用户。
group，可选项，指定可以运行Nginx服务器的用户组。
只有被设置的用户或用户组成员才有权限启动Nginx进程，如果是其他用户（test_user)尝试启动Nginx进程，将会报错：
可以从错误信息中看到，Nginx无法运行的原因是查找test_user失败，引起错误的原因是 nginx.conf 的第二行内容，即配置Nginx
服务器用户（组）的内容。
如果希望所有的用户都可以启动Nginx进程，有两种办法：
1⃣️将此指令行注释掉：
#user [user] [group]
2⃣️将用户（和用户组）设置为 nobody：
user nobody nobody； 这也是user指令的默认配置。user指令只能在全局块中配置
注意：在Nginx配置文件中，每一条指令配置都不许以分号结束，请不要忘记。
2.4.3 配置允许生成的worker process数
work process是 Nginx 服务器实现并发处理服务的关键。从理论上来说，work process的值越大，可以支持的并发处理量也越多，但实际上它还要收到来自软件本身、操作系统本身资源和能力、硬件设备（cpu和磁盘驱动器）等的制约。
配置允许生成的 work process 数的指令是 worker_processes,其语法格式为：
worker_processes number| auto；
number：指定Nginx进程最多可以产生的 worker process数
auto：设置此值，Nginx进程将自动检测。
在默认的配置文件中 number=1.启动Nginx服务器以后使用以下命令可以看到Nginx服务器除了主进程 master process.../sbin/nginx 之外，还生成了worker process
如果将number改为3，重新运行Nginx进程，再次使用以上命令，则可以看到此时的 Nginx 服务器除了主进程master process.../sbin/nginx
之外已经生成了三个 worker process
此指令只能在全局块中设置
2.4.4 配置Nginx进程PID存放路径
Nginx进程作为系统的守护进程运行，我们需要在某文件中保存当前运行程序的主进程号。Nginx支持对它的存放路径进行自定义配置，指令是pid，其语法格式为：
pid file;
其中，file指定存放路径和文件名称
配置文件默认将此文件存放在Nginx安装目录logs下，名字为 nginx.pid。path可以是绝对路径，也可以是以Nginx安装目录为根目录的相对路径。
例如要把nginx.pid放置到Nginx安装目录sbin下，文件名为 web_nginx,则可以使用以下配置：
pid sbin/web_nginx
注意：在指定 [path] 的时候，一定要包括文件名，如果只设置了路径，没有设置文件名，则会报以下错误：
此指令只能在全局块中进行配置
2.4.5 配置错误日志的存放路径
在全局块、http块和server块中都可以对Nginx服务器的日志进行相关配置。
先介绍全局块下日志的存放配置，后两种情况的配置基本相同，只是作用域不同。使用指令：error_log
语法结构：
error_log file| stderr [debug | info | notice | warn | error | crit | alert | emerg];
例如充值前台：error_log /data/www/logs/nginx/error.log error ;
从语法结构可以看到，Nginx服务器的日志支持输出到某一固定的文件 file 或者输出到标准错误输出 stderr；
日志的级别是可选项，由低到高分为debug、info、notice、warn、error、crit、alert、emerg等。
需要注意的是，设置某一级别后，比这一级别高的日志也会被记录。
比如设置warn 级别后，级别为 warn以及error、crit、alert和emerg的日志都会被记录下来。
Nginx默认的日志存放和级别设置：
error_log logs/error.log error;
注意：指定的文件对于运行Nginx进程的用户具有写权限，否则在启动Nginx进程的时候会出现以下报错信息：
此指令可以在全局块、http块、server块以及location块中配置
2.4.6 配置文件的引入
在一些情况下，我们可能需要将其他的Nginx配置或者第三方模块的配置引用到当前的主配置文件中。
Nginx提供了include指令来完成配置文件的引入，语法如下：
include file；
file 是要引入的配置文件，支持相对路径
注意：新引用进来的文件同样要求运行Nginx进程的用户对其具有写权限，并且符合Nginx配置文件规定的相关语法和结构
此指令可以放在配置文件的任意地方
2.4.7 设置网络连接的序列化
惊群：当某一时刻只有一个网络连接到来时，多个睡眠进程会被同时叫醒，但只有一个进程可获得可连接。
如果每次唤醒的进程数目太多，会影响一部分系统性能。在Nginx服务器的多进程下就可能出现这样的问题。
为解决这个问题，Nginx配置中包含指令 accept_mutex ，设置为开启的时候，将会对多个Nginx进程接收连接进行序列化，防止多个进程对连接的争抢。
accept_mutex on | off；
此指令默认为开启（on）状态，其只能在 events 块中进行配置
2.4.8 设置是否允许同时接收多个网络连接
每个Nginx服务器的 worker_process 都有能力同时接收多个新到达的网络连接，但是这需要在配置文件中进行设置，指令为 multi_accept
multi_accept on | off；
此指令默认为关闭（off）状态，即每个 worker process 一次只能接收一个新到达的网络连接。
此指令只能在 events 块中进行配置
2.4.9 时间驱动模型的选择
Nginx服务器提供了多种事件驱动模型来处理网络消息。配置文件中为我们提供了相关的指令来强制Nginx服务器选择哪种事件驱动模型进行消息处理，指令为 use，语法结构为：
use method；
其中，method可选择的内容有：select、poll、kqueue、epoll、rtsig、/dev/poll 以及 eventport。
注意：
可以在编译时使用 -with-select_module 和 -without-select_module 设置是否强制编译 select模块到Nginx内核；
使用 -with-poll_module 和 -without-poll_module 设置是否强制编译 poll 模块到Nginx内核；
此指令只能在 events 块中进行配置
2.4.10 配置最大连接数
指令 worker_connections 用来设置允许每一个 worker process同时开启的最大连接数。
语法结构：worker_connections number；
指令的默认设置为512
注意：这里的number不仅仅包括和前端用户建立的连接数，而是包括所有可能的连接数。
另外，number值不能大于操作系统支持打开的最大文件句柄数量。
此指令只能在 events 块总共进行配置
2.4.11 定义 MIME-Type
常用的浏览器中可以显示的内容有 HTML、XML、GIF及 Flash等种类繁多的文本、媒体等资源，浏览器为区分这些资源，需要使用 MIME Type。
MIME Type是网络资源的媒体类型。Nginx服务器作为 Web的服务器，必须能够识别前端请求的资源类型
在默认的Nginx配置文件中，在http全局块中有以下两行配置：
include mime.types；
default_type application/octet-stream；
第一行从外部引用了 mime_types 文件，内容片段如下：
从mime_types文件的内容片段可以看到，其定义了一个 types结构，结构中包含了浏览器能够识别的 MIME类型以及对应于相关类型的文件后缀名。
由于 mime_types 文件是主配置文件应用的第三方文件，因此，types 也是Nginx配置文件中的一个配置块，我们可以称之为 types块，其用于定义 MIME类型。
第二行指令 default_type application/octet-stream； 配置了用于处理前端请求的 MIME类型
语法结构为：
default_type mime-type；
其中， mime-type 为 types 块中定义的 MIME-type，如果不加此指令，默认值为 text/plain 。
此指令还可以在 http块、server块或者 location块中进行配置。
2.4.12 自定义服务日志
在全局块中，error_log指令，用于配置Nginx进程运行时的日志存放和级别。
此处所指的日志与常规的不同，它是指记录Nginx服务器提供服务过程应答前端请求的日志，将其称为服务日志以示区分。
Nginx服务器支持对服务日志的格式、大小、输出等进行配置，需要使用两个指令，分别是 access_log和 log_format
access_log指令的语法结构：
access_log path [format [buffer=size]]；
path，配置服务日志的文件存放的路径和名称
format，可选项，自定义服务日志的格式字符串，也可以通过“格式串的名称“使用 log_format 指令定义好的格式。
“格式串的名称”在 log_format 指令中定义
size：配置临时存放日志的内存缓存区大小
此指令可以在http块、server块或者lication块中进行设置。默认的配置为：
access_log logs/access.log combined；
其中，combined 为 log_format 指令默认定义的日志格式字符串的名称
如果要取消记录服务日志的功能，使用：
access_log off；
和 access_log 联合使用的另一个指令是 log_format，它专门用于定义服务日志的格式，并且可以为格式字符串定义一个名字，便于 access_log指令可以直接调用。
语法格式为：
log_format name string...；
name，格式字符串的额名字，默认的名字为 combined
string，服务日志的格式字符串。在定义过程中，可以使用Nginx配置预设的一些变量获取相关内容，变量的名称使用双引号括起来，string整体使用单引号括起来。
在string中可以使用的变量参见“附录A”
这条配置定义了服务日志文件的名称为 access
access.log日志截图：
分析日志：
$remote_addr 获取到用户机的 IP地址为 192.168.41.12
$time_local 获取到本地时间为：[29/Jun/2017:16:21:52 +0800]
$request获取到请求为："POST /disburse/checkMemberName.htm HTTP/1.1"
$status：获取到请求状态为 200
$body_bytes_sent 获取到请求体的大小为 ：306B等
$http_referer获取到用户访问的网页：https://recharge.kedou.com/front/pay/disbursePage.htm
$http_user_agent获取到用户使用的浏览器：Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36"
$http_x_forwarded_for 未获取到内容
正常情况下，对于绝大多数的内置变量，Nginx服务器都能够获取到相关内容，但也会出现空值的情况
此指令只能在http块中进行配置
2.4.13 配置允许 sendfile 方式传输文件
在Apache、lighttd等 Web服务器配置中，都有和sendfile相关的配置
配置sendfile传输方式的相关指令 sendfile 和send-file_max_chunk 以及它们的语法结构：
sendfile on | off；
用于开启或关闭使用sendfile（）传输文件，默认值为 off，可以在http块、server块或者location块中进行配置
sendfile_max_chunk_size；
size值如果大于0，Nginx进程的每个 worker process每次调用 sendfile（）传输的数据量最大不能超过这个值；
如果设置为0，则无限制。默认值为0
此指令可以在 http 块、server块 或 location块中配置。
如下是第二个指令的配置示例：
sendfile_max_chunk 128K；
2.4.14 配置连接超时时间
与用户建立会话连接后，Nginx服务器可以保持这些连接打开一段时间，指令 keepalive_timeout 就是用来设置此时间的
语法结构：
keepalive_timeout timeout [header_timeout]；
timeout：服务器端对连接的保持时间。默认为75s
header_timeout：可选项，在应答报文头部的 keep-Alive 域设置超时时间：“keep-Alive：timeout=header_timeout"
报文中的这个指令可以被 Mozilla 或者 Konqueror 识别
此指令还可以出现在 server块和location块中，如下配置示例：
keepalive_timeout 120s 100s； 在服务器端保持连接的时间设置为 120s，发给用户端的应答报文头部中 Keep_Alive 域的超时时间设置为 100s
此指令可以在http块、server块或location块中配置
2.4.15 单连接请求数上线
Nginx服务器端和用户端建立会话连接后，用户端用过此连接发送请求。
指令 keepalive_requests 用于限制用户通过某一连接向 Nginx 服务器发送请求的次数
语法结构为：
keepalive_requests number；
此指令还可以出现在 server 块和 location块中，默认设置为 100
2.4.16 配置网络监听
配置监听使用指令 listen，其配置方法有三种
第一种配置监听的IP地址，语法结构为：
第二种配置监听端口，语法结构为：
第三种配置NUIX Domain Socket（一种在原有Socket框架上发展起来的 IPC 机制，用于在单个主机上执行客户/服务器通信）
语法结构为:
listen 指令默认设置为：
listen * :80| * :8000； 监听所有80端口和8000端口
listen用法：
listen 192.168.1.10:8000；
#监听具体的IP和具体的端口上的连接 listen 192.168.1.10；
#监听具体IP的所有端口上的连接 listen 8000；
#监听具体端口上的所有 IP 连接，等同于 listen * :8000；
listen 192.168.1.10 default_server backlog=1024；
#设置192.168.1.10 的连接请求默认由此虚拟主机处理
#并且允许最多 1024 网络连接同时处于挂起状态
2.4.17 基于名称的主机配置
这里’主机'指 server块对外提供的虚拟主机。设置了主机的名称并配置好 DNS，用户就可以使用这个名称向此虚拟主机发送请求。
配置主机名称的指令为 server_name，语法结构为：
server_name name ...；
name可以有一个名称，也可以有多个名称并列，用空格隔开。每个名字就是一个域名。
示例：
此虚拟主机的名称设置为 myserver.com 或 www.myserver.com
Nginx服务器规定，第一个名称作为此虚拟主机的主要名称
在name中可以使用通配符 “*”，但通配符只能用在 由三段字符串组成的名称的首段或尾段，或者由两端字符组成的名称的尾段
如：
在name中使用正则表达式，并使用波浪号“~”作为正则表达式字符串的开始标记，如：
正则表达式配置的虚拟主机可以接收的域名的请求。
比如：www1.myserver.com 访问Nginx服务器的请求就可以使用此主机处理，通过 www.myserver.com 的就不可以。
因为'www‘字符串之后必须有一个或多个 0~9 的数字才能被正则表达式成功匹配
注意：从Nginx-0.7.40 开始，name中的正则表达式支持字符串捕获功能，即可以将正则表达式匹配成功的名称中的一部分字符串取出来，
放在固定的变量中供下文使用。拾取的标识为一对完整的小括号“（）”且后面不紧跟其他的正则表达式字符，括号中的内容就是被拾取的内容。
一个正则表达式中可以存在多对不嵌套的小括号，这些内容会从左到右依次存放在变量 $1、$2、$3......中。下文使用时，直接使用这些变量即可。
这些变量的有效区域不超出本server块
例如，虚拟主机的名称设置如下：
当请求通过 www.myserver.com 到达Nginx服务器时，其将会被上面的正则表达式配置成功，其中的“myserver”将会被捕获，
并记录到 $1 中。在本 server 块的下文配置中，当需要“myserver”时，就可以使用 $1代替“myserver”了。
由于 server_name 指令支持使用通配符和正则表达式两种配置名称的方式，因此在包含有多个虚拟主机的配置文件中，可能会出现一个名称被多个虚拟主机的server_name匹配成功。那么，来自这个名称的请求到底交给哪个虚拟主机处理，Nginx服务器做了如下规定：
a.对于匹配方式不同的，按照以下的优先级选择虚拟主机，排在前面的优先处理请求。
①准确匹配 server_name
②通配符在开始时匹配 server_name 成功
③通配符在结尾时匹配 serve_name 成功
④正则表达式匹配 server_name 成功
b.在以上四种匹配方式中，如果 server_name被处于同一优先级的匹配方式多次匹配成功，则首次匹配成功的虚拟主机处理请求
2.4.18 基于IP的虚拟主机配置
Linux操作系统支持IP别名的添加。配置基于 IP 的虚拟主机，即为 Nginx服务器提供的每台虚拟主机配置一个不同的 IP，
因此需要将网卡设置为同时能够监听多个 IP地址。在Liunx平台中可以使用 ifconfig 工具为同一块网卡添加多个 IP别名
recharge当前的网络配置为：
eth0 为使用中的网卡，其 IP值为 192.168.4.58
为 eth0 添加两个 IP别名 192.168.4.59、192.168.4.60 分别用于Nginx服务器提供的两个虚拟主机，执行以下操作：
ifconfig eth0:0 192.168.4.59 netmask 255.255.255.0 up
ifconfig eth0:1 192.168.4.60 netmask 255.255.255.0 up
命令中 up 表示立即启用此别名
启用后Linux平台的网络配置为
启用后，eth0增加了两个别名，分别为 eth0:0 和 eth0:1 ,IP也分别是我们希望得到的结果。
按照如上方法为 eth0 设置的别名在系统重启后将不予保存，需要重新设置。
将以上两条命令添加到 Linux 系统的启动脚本 rc.local 中，可以做到一劳永逸。
# echo "ifconfig eth0:0 192.168.4.59 netmask 255.255.255.0 up" > > /etc/rc.local
# echo "ifconfig eth0:0 192.168.4.60 netmask 255.255.255.0 up" > > /etc/rc.local
在系统重启后，eth0的别名就自动设置好了
为网卡设置好别名后，就可以为Nginx服务器配置基于 IP 的虚拟主机了。
使用的指令和配置基于名称的虚拟主机的指令是相同的，即 server_name，语法结构也相同。
不需要考虑通配符或者正则表达式的问题
基于IP的虚拟主机相关配置片段：
以上配置好后，来自 192.168.1.31 的前端请求将由第一台虚拟主机接收和处理
来自192.168.1.32的前端请求将由第二台虚拟主机接收和处理
删除虚拟ip主机：
ip addr del 192.168.4.60 dev eth0
2.4.19 配置 location 块
location 语法结构为：
其中，uri变量是待匹配的请求字符串，可以是不含正则表达的字符串，如 /myserver.php 等；
也可以是包含有正则表达的字符串，如 .php$(表示以 .php 结尾的 URL）等。
不含正则表达的 uri称为“标准 uri"，使用正则表达式的 uri 称为“正则 uri”
方括号中的部分是可选项，用来改变请求字符串与 uri 的匹配方式
了解不添加此选项时，Nginx服务器是如何在 server 块中搜索并使用 location块的 uri 和 请求字符串匹配的
不添加此选项时，Nginx服务器首先在server块的多个location块中搜索是否有标准 uri 和请求字符串匹配，如果有多个可以匹配，
就记录匹配度最高的一个。然后，服务器再用location块中的正则 uri 和请求字符串匹配，当第一个正则 uri 匹配成功，结束搜索，
并使用这个 location块处理此请求；如果正则匹配全部失败，就使用刚才记录的匹配度最高的 location块处理此请求
可选项各个表示的含义：
"=" : 用于标准 uri 前，要求请求字符串与 uri 严格匹配。如果已经匹配成功，就停止继续向下搜索并立即处理此请求
“~”：用于表示 uri 包含正则表达式，并且区分大小写
“~*”：用于表示 uri 包含正则表达式，并且不区分大小写
注意：如果 uri 包含正则表达式，就必须要使用“~”或者“~*”标识
"^~"，用于标准 uri 前，要求Nginx服务器找到标识 uri 和 请求字符串 匹配度最高的 location 后，立即使用此 location 处理请求，
而不再使用 location块中的正则 uri 和请求字符串做匹配。
注意：在浏览器传送 URI 时对一部分字符进行 URL 编码，比如空格被编码为 “%20"，问号被编码为 “%3f"等。
”^~"有一个特点，它对 uri 中的这些符号将会进行编码处理。
比如：如果 location 块收到的 URI为 "/html/%20/data”，则当Nginx服务器搜索到配置为 “^~/html/data" 的 location 时，可以匹配成功。
2.4.20 配置请求的根目录
Web服务器接收到网络请求之后，首先要在服务器端指定目录中寻找请求资源。在Nginx服务器中，指令 root 就是用来配置这个根目录的，其语法结构为：
root path；
其中，path为Nginx服务器接收到请求以后查找资源的根目录路径。path变量汇总可以包含 Nginx服务器预设的大多数变量，见附录A，
只有 $document_root 和 $realpath_root 不可以使用。
此指令可以在 http块、server块或者location块中配置。由于使用Nginx服务器多数情况下要配置多个 location块对不同的请求分别做出处理，因此该指令通常在 location块中进行设置。
这个指令的一个示例为：
当 location 块接收到 “data/index.htm"的请求时，将在 /locationtest1/data / 目录下找到index.htm 响应请求
2.4.21 更改 location 的URI
在 location 块中，除了使用 root 指令指明请求处理根目录，还可以使用 alise 指令改变 location 接收到的 URI 的请求路径，其语法结构为：
alise path；
其中，path即为修改后的根路径。同样，此变量中也可以包含除了 $document_root 和 $realpath_root 之外的其他Nginx服务器预设变量。
示例：
当此 location 块接收到 "/data/index.htm" 的请求时，匹配成功，之后根据 alises 指令的配置，Nginx服务器将到 /locationtest1/other 目录下找到 index.htm 并响应请求。
可以看到，通过 alias 指令的配置，根路径已经从 /data 更改为 /locationtest1/other 了。
2.4.22 设置网站的默认首页
index 指令用于设置网站的默认首页，有两个作用：
一是用户在发出请求访问网站时，请求地址可以不写首页名称；
二是可以对一个请求，根据其请求内容而设置不同的首页。
该指令的语法结构为：
index file...；
其中 file变量可以包括多个文件名，其间使用空格分隔，也可以包含其他变量。此变量默认为“index.html"
2.4.23 设置网站的错误页面
如果用户端尝试查看网页时遇到问题，服务器会将 HTTP错误从网站发送到 Web浏览器。如果无法显示网页，Web浏览器会显示网站发送的实际错误网页或 Web浏览器内置的友好错误消息。Nginx服务器支持自定义错误网页的显示内容。可以通过这一功能在网站发生错误时为用户提供人性化的错误显示页面。
一般来说，HTTP 2XX代表请求正常完成，HTTP 3XX代表网站重定向，HTTP 4XX代表客户端出现错误， HTTP 5XX代表服务器端出现错误。
常见的HTTP错误
Nginx服务器设置网站错误页面的指令为 error_page，语法结构为：
error_page code ...[=[response]] uri
#code，要处理的HTTP错误代码，见上表
#response，可选项，将 code 指定的错误代码转换为新的错误代码 response
#uri，错误页面的路径或者网站地址。如果设置为路径，则是以 Nginx 服务器安装路径下的 html 目录为根路径的相对路径；如果设置为网址，则Nginx服务器会直接访问该网址获取错误页面，并返回给用户端。
error_page 指令的示例：
error_page 404/404.html
设置Nginx服务器使用 “Nginx安装路径 /html/404.htnl" 页面响应404错误（“无法找到网页”错误）。再如：
error_page 403 http://somewebsite.com/forbidden.html；
设置Nginx服务器使用 "http://somewebsite.com/forbidden.html" 页面响应 403错误（"拒绝显示网页"错误).
再如：
error_page 410 = 301/empty.gif
设置Nginx服务器产生 410的HTTP消息时，使用"Nginx安装路径 /html/empty.gif"返回给用户端 301消息（"已移动"消息）
前面对error_page 指令的分析中可以看到，变量 uri 实际上是对一个相对于Nngix服务器安装路径的相对路径。如果不想将错误页面放到Nginx服务器的安装路径下管理，怎么做？
只需要另外使用一个 location 指令定向错误页面到新的路径下面就可以了。比如对于上面的第一个示例，我们希望 Nginx服务器使用"/myserver/errorpages/404.html"页面响应 404错误，那么在设置完：
error_page 404/404.html
之后，在添加这样一个 location 块：
首先捕获 “/404.html" 请求，然后将请求定向到新的路径下面即可,
error_page 指令可以在http块、server块和location块中配置
2.4.24 基于IP配置Nginx的访问权限
Nginx配置通过两种途径支持基本访问权限的控制，其中一种是由HTTP标准模块 ngx_http_access_module 支持的，
其通过IP来判断客户端是否拥有对Nginx的访问权限，这里有两个指令
allow：用于设置允许访问Nginx的客户端IP，语法结构如下：
allow address| CIDR| all;
address 允许访问的客户端的 IP，不支持同时设置多个。如果有多个IP需要设置，重新重复使用 allow指令
CIDR：允许访问的客户端的CIDR地址
例如 202.80.18.23/25 ，前面是32位IP地址，后面"/25"代表该 IP 地址中前25位是网络部分，其余位代表主机部分
all：代表允许所有客户端访问
从Nginx 0.8.22版本以后，该命令也支持 IPV6地址，比如：
allow 2620:100：e000：：8001；
另一个指令是 deny，作用刚好和 allow指令相反，它用于设置禁止访问 Nginx的客户端 IP,语法结构为：
deny address | CIDR | all；
address，禁止访问的客户端的IP，不支持同时设置多个。如果有多个 IP需要设置，需要重复使用 deny指令
CIDR，禁止访问的客户端的 CIDR地址
all，代表禁止所有客户端访问。
这两个指令可以在 http块、server块或者 location块中配置。
在使用这两个指令时，要注意设置为 all的用法。如下例子：
location / {
deny 192.168.1.1;
allow 192.168.1.0/24;
deny all;
}
如上配置含义：首先配置禁止 192.168.1.1 访问Nginx
然后配置允许 192.168.1.0/24 访问Nginx
最后使用 all 配置禁止所有 IP的访问
192.168.1.0/24 客户端是可以访问的。Nginx配置在解析的过程中，遇到deny指令或者allow指令时按照顺序对当前客户端的连接进行访问权限检查的。如果遇到匹配的配置时，则停止继续向下搜索相关配置。因此，当 192.168.1.0/24 客户端访问时，Nginx在第3行解析配置发现允许该客户端访问，就不会继续向下解析第4行了。
2.4.25 基于密码配置Nginx的访问权限
Nginx 还支持基于 HTTP Basic Authentication 协议的认证。
该协议是一种 HTTP 性质的认证办法，需要识别用户名和密码，认证失败的客户端不拥有访问Nginx服务器的权限。
该功能由 HTTP 标准模块 ngx_http_auth_basic_module 支持，有两个指令需要了解：
auth_basic指令，用于开启或者关闭该认证功能，语法结构为：
auth_basic string| off；
string，开启该认证功能，并配置验证时的指示信息
off,关闭该认证功能
auth_basic_user_file 指令，用于设置包含用户名和密码信息的文件路径，语法结构为：
auth_basic_user_file file；
file为密码文件的绝对路径
这里的密码文件支持明文或者密码加密后的文件。明文的格式如下：
name1:passpord1
name2:passpord2:comment
name3:passpord3
加密密码可以使用 crypt() 函数进行密码加密的格式，在Linux平台上可以使用 htpasswd 命令生成。
在PHP和Perl等语言中，也提供 crypt() 函数。使用 htpasswd 命令的一个示例为：
htpasswd -c -d /nginx/conf/pass_file username
运行后输入密码即可