文末更有Nginx进阶技能文章、Nginx源码视频详解，对Nginx已有初步理解的朋友可以跳到文章底部学习！
须要Nginx及后台架构方向更多学习资料，可往后台私信【Nginx】获取
准备第三方支持库源码：
nginx-1.13.7.tar.gz
openssl-1.1.0g.tar.gz
pcre-8.41.tar.gz
zlib-1.2.11.tar.gz
解压每个包
$ tar xzvf nginx-1.13.7.tar.gz
$ tar xzvf openssl-1.1.0g.tar.gz
$ tar xzvf pcre-8.41.tar.gz
$ tar xzvf zlib-1.2.11.tar.gz
$ cd nginx-1.13.7
$ ./configure --prefix=/usr/local/nginx --with-http_realip_module --
with-http_addition_module --with-http_gzip_static_module --with
http_secure_link_module --with-http_stub_status_module --with-stream --
with-pcre=/home/wangbojing/share/nginx/pcre-8.41
--with
zlib=/home/wangbojing/share/nginx/zlib-1.2.11
--with
openssl=/home/wangbojing/share/nginx/openssl-1.1.0g
$ make
$ sudo make install
在/usr/local/目录下面，产生了 nginx 的目录
$ ./sbin/nginx –c ./conf/nginx.conf
Nginx 快速入门
紧张先容 nginx 的基本配置和操作，并先容了一些可以完成的大略任务。假设您已经学
习过并已经安装好了 nginx 做事器。 如果没有，请参阅安装 nginx 页面。 本指南先容如何
启动和停滞 nginx，并重新加载其配置，阐明配置文件的构造，并先容如何设置 nginx 以供应
静态内容，如何配置 nginx 作为代理做事器，以及如何将其连接到 一个 FastCGI 运用程序。
nginx 有一个主进程和几个事情进程。 主进程的紧张目的是读取和评估配置，并掩护工
作进程。 事情进程对要求进行实际处理。 nginx 采取基于事宜的模型和依赖于操作系统的
机制来有效地在事情进程之间分配要求。 事情进程的数量可在配置文件中定义，并且可以
针对给定的配置进行修正，或者自动调度到可用 CPU 内核的数量
在配置文件中确定 nginx 及其模块的事情办法。默认情形下，配置文件名为 nginx.conf，
并放在目录：/usr/local/nginx/conf, /etc/nginx, 或 /usr/local/etc/nginx 中。
在前面安装文章配置中，利用的安装配置目录是：/usr/local/nginx/conf 。以是可以在这
个目录下找到这个配置文件。
1. 启动，停滞和重新加载 Nginx 配置
要启动 nginx，请运行可实行文件。 当 nginx 启动后，可以通过利用-s 参数调用可实行文件
来掌握它。 利用以下语法：
$ nginx -s signal
旗子暗记(signal)的值可能因此下之一：
stop - 快速关闭做事
quit - 正常关闭做事
reload - 重新加载配置文件
reopen - 重新打开日志文件
例如，要通过等待事情进程完成做事当前要求来停滞 nginx 进程，可以实行以下命令：
$ nginx -s quit
注：该命令该当在启动 nginx 的同一用户下实行。
在将重新配置命令的命令发送到 nginx 或重新启动之前，配置文件中的变动将不会被运用。
要重新加载配置文件，请实行：
$ nginx -s reload
当主进程收到要重新加载配置的旗子暗记，它将检讨新配置文件的语法有效性，并考试测验运用个中
供应的配置。 如果这是成功的，主进程将启动新的事情进程，并向旧的事情进程发送，
要求它们关闭。 否则，主进程回滚变动，并连续利用旧配置。 老事情进程，吸收关闭命令，
停滞接管新连接，并连续掩护当前要求，直到所有这些要求得到掩护。 之后，旧的事情进
程退出。
还可以借助 Unix 工具(如 kill utility)将旗子暗记发送到 nginx 进程。 在这种情形下，旗子暗记
直接发送到具有给定进程 ID 的进程。 默认情形下，nginx 主进程的进程 ID 写入目录
/usr/local/nginx/logs 或/var/run 中的 nginx.pid。 例如，如果主进程 ID 为 1628，则发
送 QUIT 旗子暗记导致 nginx 的正常关闭，请实行：
$ kill -s QUIT 1628
要获取所有运行的 nginx 进程的列表，可以利用 ps 命令，例如，以下列办法：
$ ps -ax | grep nginx
2. 配置文件的构造
Nginx 由配置文件中指定的指令掌握的模块组成。 指令分为大略指令和块指令。 一个
大略的指令由空格分隔的名称和参数组成，并以分号(;)结尾。 块指令具有与大略指令相同
的构造，但不因此分号结尾，而因此大括号({和})包围的一组附加指令结束。 如果块指令可
以在大括号内部有其他指令，则称为高下文(例如：events，http，server 和 location)。
配置文件中放置在任何高下文之外的伪指令都被认为是主高下文。
events 和 http 指令驻留
在主高下文中，server 在 http 中的，而 location 在 http 块中。
#号之后的一行的部分被视为注释。
3. 供应静态内容做事(静态网站)
一个主要的 Web 做事器任务是供应文件(如图像或静态 HTML 页面)。这里我们来学习如何实
现一个示例，根据要求，文件将从不同确当地目录供应： /usr/local/nginx/html/www(包含
HTML 文件)和/usr/local/nginx/html/images(包含图像)。这将须要编辑配置文件，并利用两个
位置块在 http 块内设置做事器块。
首先，创建/usr/local/nginx/html/www 目录，并将一个包含任何文本内容的 exmaple.html 文
件放入个中，并创建/usr/local/nginx/html/images 目录并在个中放置一些图像。
root@ubuntu:/usr/local/nginx# mkdir -p /data/images
root@ubuntu:/usr/local/nginx#
分别在上面创建的两个目录中放入两个文件：/usr/local/nginx/html/www/exmaple.html 和 /
usr/local/nginx/html/1.png, 2.png, 3.png，/usr/local/nginx/html/ww 文件的内容就一行，如下
<h2> 0voice Demo.</h2>
接下来，打开配置文件(/usr/local/nginx/conf/nginx.conf)。 默认的配置文件已经包含了做事
器块的几个示例，大部分是注释掉的。 现在注释掉所有这样的块，并启动一个新的做事器
块：
http {
server {
}
}
常日，配置文件可以包括做事器监听的端口和做事器名称区分的几个 server 块。当 nginx 决
定哪个做事器处理要求后，它会根据做事器块内部定义的 location 指令的参数测试要求头中
指定的 URI。
将以下 location 块添加到做事器(server)块：
http {
server {
location / {
root /usr/local/nginx/html/www;
}
}
}
该 location 块指定与要求中的 URI 比较较的“/”前缀。 对付匹配要求，URI 将被添加到 root
指令中指定的路径(即/data/www)，以形成本地文件系统上所要求文件的路径。 如果有几个
匹配的 location 块，nginx 将选择具有最长前缀来匹配 location 块。 上面的 location 块供应
最短的前缀长度为 1，因此只有当所有其他 location 块不能供应匹配时，才会利用该块。
接下来，添加第二个 location 块：
http {
server {
location / {
root /usr/local/nginx/html/www;
}
location /images/ {
root /usr/local/nginx/html;
}
}
}
它将因此/images/(位置/也匹配这样的要求，但具有较短前缀，也便是“/images/”比“/”长)的
要求来匹配。
server 块的终极配置应如下所示：
server {
location / {
root /usr/local/nginx/html/www;
}
location /images/ {
root /usr/local/nginx/html;
}
}
这已经是一个在标准端口 80 上侦听并且可以在本地机器上访问的做事器( http://localhost/ )
的事情配置。 相应以/images/开头的 URI 的要求，做事器将从/data/images 目录发送文件。
例如，相应 http://192.168.199.133:8080/images/logo.jpg 要求，nginx 将发送做事上的
/usr/local/nginx/html/images/logo.jpg 文件。 如果文件不存在，nginx 将发送一个指示 404 错
误的相应。 不以/images/开头的 URI 的要求将映射到/usr/local/nginx/html/www 目录。 例
如，相应http://192.168.199.133:8080/example.html要求时， nginx 将发送
/usr/local/nginx/html/www /example.html 文件。
要运用新配置，如果尚未启动 nginx 或者通过实行以下命令将重载旗子暗记发送到 nginx 的主进
程：
root@ubuntu:/usr/local/nginx# /usr/local/nginx/sbin/nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is
ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is
successful
root@ubuntu:/usr/local/nginx# /usr/local/nginx/sbin/nginx -s reload
如果缺点或非常导致无法正常事情，可以考试测验查看目录/usr/local/nginx/logs 或/var/log/nginx
中的 access.log 和 error.log 文件中查找缘故原由。
打开浏览器或利用 CURL 访问 Nginx 做事器如下所示:
完全的 nginx.conf 文件配置内容如下：
events {
worker_connections 1024;
}
http {
server {
listen 8080;
server_name localhost;
location / {
root /usr/local/nginx/html/www;
}
location /images/ {
root /usr/local/nginx/html;
}
}
}
4. 设置大略的代理做事器
nginx 的一个常见用场是将其设置为代理做事器，这意味着它可作为一个吸收
要求的做事器，将其通报给代理做事器，从代理做事器中检索相应，并将其发
送给客户端。
我们将配置一个基本的代理做事器，它为来自本地目录的文件供应图像要求，
并将所有其他要求发送到代理的做事器。 在此示例中，两个做事器将在单个
nginx 实例上定义。
首先，通过向 nginx 配置文件添加一个 server 块来定义代理做事器，个中包含
以下内容：
server {
listen 8080;
root /data/up1;
location / {
}
}
这将是一个监听端口 8080 的大略做事器(以前，由于利用了标准端口 80，以是
没有指定 listen 指令)，并将所有要求映射到本地文件系统上的/data/up1 目
录。 创建此目录并将 index.html 文件放入个中。 请把稳，root 指令位于
server 块高下文中。 当选择用于做事要求的 location 块不包含自己的 root
指令时，将利用此 root 指令。
在上面创建的目录/data/up1 中放入一个文件：/data/www/demo.html，文件的
内容就一行，如下 -
<h2>About proxy_pass Page at port 8080</h2>
接下来，利用上一节中的做事器配置进行修正，使其成为代理做事器配置。 在
第一个位置块中，将 proxy_pass 指令与参数中指定的代理做事器的协议，名称
和端口(在本例中为 http://localhost:8080)：
server {
location / {
proxy_pass http://localhost:8080;
}
location /images/ {
root /data;
}
}
我们将修合法前利用/images/prefix 将要求映射到/data/images 目录下的文件
的第二个 location 块，使其与范例文件扩展名的图像要求相匹配。 修正后的
位置块如下所示：
location ~ \.(gif|jpg|png)$ {
root /data/images;
}
该参数是一个正则表达式，匹配所有以.gif，.jpg 或.png 结尾的 URI。正则表
达式之前该当是~字符。 相应的要求将映射到/data/images 目录。
当 nginx 选择一个 location 块来供应要求时，它首先检讨指定前缀的
location 指令，记住具有最长前缀的 location，然后检讨正则表达式。 如果
与正则表达式匹配，nginx 会选择此 location，否则选择之前记住的那一个。
代理做事器的终极配置将如下所示：
server {
location / {
proxy_pass http://192.168.199.128:8080/;
}
location ~ \.(gif|jpg|png)$ {
root /data/images;
}
}
此做事器将过滤以.gif，.jpg 或.png 结尾的要求，并将它们映射到/data/images 目录(通过向
root 指令的参数添加 URI)，并将所有其他要求通报到上面配置的代理做事器。
要运用新配置，如果尚未启动 nginx 或者通过实行以下命令将重载旗子暗记发送到 nginx 的主进
程：
root@ubuntu:/usr/local/nginx# ./sbin/nginx -c ./conf/demo.conf
首先测试上面配置的 8080 端口的做事，访问做事的 8080 端口，得到以下结果：
再次访问 80 端口(这里只是一个代理，它会把要求转发给 8080 的做事，由 8080 端口这这
个做事处理并返回结果到客户端)，得到以下结果 -
完全的配置 nginx.conf 文件内容如下：
events {
worker_connections 1024;
}
http {
server {
listen 8080;
server_name localhost;
location / {
root /usr/local/nginx/html/www;
# proxy_pass http://192.168.199.128;
}
location /images/ {
root /usr/local/nginx/html;
}
}
}
5. 设置 FastCGI 代理
nginx 可用于将要求路由到运行利用各种框架和 PHP 等编程措辞构建的运用程序的
FastCGI 做事器。利用 FastCGI 做事器的最基本 nginx 配置包括利用 fastcgi_pass 指令(而不是
proxy_pass 指令)，以及 fastcgi_param 指令来设置通报给 FastCGI 做事器的参数。
假设 FastCGI
做事器可以在 localhost:9000 上访问。 以上一节的代理配置为根本，用 fastcgi_pass 指令替
换 proxy_pass 指令，并将参数变动为 localhost:9000。 在 PHP 中，SCRIPT_FILENAME 参数用
于确定脚本名称，QUERY_STRING 参数用于通报要求参数。 终极的配置将是：
server {
location / {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;
}
location ~ \.(gif|jpg|png)$ {
root /data/images;
}
}
这将设置一个做事器，将除静态图像要求之外的所有要求路由到通过 FastCGI 协议在
localhost:9000 上运行的代理做事器。
Nginx 进程和运行时掌握
先容 NGINX 在运行时启动的过程以及如何掌握它们。
在这个部分中，紧张涉及两个部分的内容：
主进程和事情进程
掌握 NGINX
1. 主进程和事情进程
NGINX 有一个主进程和一个或多个事情进程。 如果启用缓存，缓存加载程序和缓存管
理器进程也将在启动时运行。
主程序的紧张目的是读取和评估配置文件以及掩护事情进程。 事情进程实行要求的实
际处理。 NGINX 依赖于操作系统的机制来有效地在事情进程之间分配要求。 事情进程的数
量可在 nginx.conf 配置文件中定义，可以针对给定的配置进行修复，或者自动调度为可用 CPU
内核数。
2. 掌握 Nginx
要重新加载配置文件，可以停滞或重新启动 NGINX，或者发送旗子暗记到主进程。
可以利用-s 参
数运行 nginx 命令(调用 NGINX 可实行文件)来发送旗子暗记。
$ nginx -s signal
旗子暗记的值可以是以下之一：
quit – 正常地关闭
reload – 重新加载配置文件
reopen – 重新打开日志文件
stop – 立即关闭(快速关闭)
杀去世实用程序也可以利用，将旗子暗记直接发送到主进程。 默认情形下，主进程的进程 ID 被写
入位于/usr/local/nginx/logs 或/var/run 目录中的 nginx.pid 文件。
nginx 可以用旗子暗记掌握。 默 认 情 况 下 ， 主 进 程 的 进 程 ID 将 写 入 文 件
/usr/local/nginx/logs/nginx.pid。 该名称可能在配置时变动，或利用 pid 指令在 nginx.conf 文
件中进行变动。主程序支持以下旗子暗记：
TERM, INT - 快速关闭
QUIT - 正常关闭
HUP - 改变配置，跟上改变的时区(仅适用于 FreeBSD 和 Linux)，利用新配置启动新的工
作进程，正常关闭旧的事情进程
USR1 - 重新打开日志文件
USR2 - 升级可实行文件
WINCH - 正常关闭事情进程
个别事情进程可以用旗子暗记来掌握，只管这不是必需的。 支持的旗子暗记有：
TERM, INT - 快速关闭
QUIT - 正常关闭
USR1 - 重新打开日志文件
WINCH - 调试非常终止(须要启用 debug_points)
变动配置
为了使 nginx 重新读取配置文件，应将 HUP 旗子暗记发送到主进程。 主进程首先检讨语法有效
性，然后考试测验运用新配置，即打开日志文件和新的监听套接字。
如果失落败，它会回滚变动，
并连续利用旧配置。 如果此操作成功，它将启动新的事情进程，并向旧的事情进程发送消
息，要求它们正常关闭。 旧事情进程密切监听套接字，并连续为旧客户端做事。 在所有客
户端被做事之后，旧的事情进程被关闭。
我们来举例解释一下。 想象一下，nginx 是在 ubuntu14.04 上运行，实行以下命令：
$ ps axw -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'
产生以下输出：
PID PPID USER %CPU VSZ WCHAN COMMAND
33126 1 root 0.0 1148 pause nginx: master process
/usr/local/nginx/sbin/nginx
33127 33126 nobody 0.0 1380 kqread nginx: worker process (nginx)
33128 33126 nobody 0.0 1364 kqread nginx: worker process (nginx)
33129 33126 nobody 0.0 1364 kqread nginx: worker process (nginx)
如果将 HUP 发送到主进程，则输出变为：
PID PPID USER %CPU VSZ WCHAN COMMAND
33126 1 root 0.0 1164 pause nginx: master process
/usr/local/nginx/sbin/nginx
33129 33126 nobody 0.0 1380 kqread nginx: worker process is shutting
down (nginx)
33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
PID 33129 的老事情流程仍旧连续运行。 一段韶光后，它退出：
PID PPID USER %CPU VSZ WCHAN COMMAND
33126 1 root 0.0 1164 pause nginx: master process
/usr/local/nginx/sbin/nginx
33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
循环日志文件
要循环日志文件，须要首先重命名。 之后，USR1 旗子暗记应发送到主进程。 然后，主进
程将重新打开所有当前打开的日志文件，并将其分配给正在运行的事情进程的非特权用户作
为所有者。 成功重新打开后，主程序关闭所有打开的文件，并将发送到事情进程，要
求他们重新打开文件。 事情进程也会打开新文件并立即关闭旧文件。 因此，旧文件险些立
即可用于后处理，如压缩。
Nginx 配置文件
NGINX 与其他做事类似，由于它具有以特定格式编写的基于文本的配置文件。 默认情
况下，文件名为 nginx.conf 并放在/etc/nginx 目录中(对付开源 NGINX 产品，位置取决于用于
安装 NGINX 和操作系统的软件包系统，它常日位于/usr/local/nginx/conf/etc/nginx 或
/usr/local/etc/nginx。)
配置文件由指令及其参数组成。 大略(单行)指令各自以分号结尾。 其他指令作为“容器”，
将干系指令组合在一起，将其包围在花括号({})中。 以下是大略指令的一些示例。
user nobody;
error_log logs/error.log notice;
worker_processes 1;
为了使配置更易于掩护，建议您将其拆分为存储在/etc/nginx/conf.d 目录中的一组功能特定
文件，并在主 nginx.conf 文件中利用 include 指令引用(包函)指定文件的内容。如下所示 -
include conf.d/http;
include conf.d/stream;
include conf.d/exchange-enhanced;
几个顶级指令(称为高下文)将适用于不同流量类型的指令组合在一起：
events – 一样平常连接处理
http – HTTP 协议流量
mail – Mail 协议流量
stream – TCP 协议流量
指定在这些高下文之外的指令是在主高下文中。
在每个流量处理高下文中，可包括一个或多个做事器高下文来定义掌握要求处理的虚拟做事
器。 您可以在做事器环境中包含的指令根据流量类型而有所不同。
对付 HTTP 流量(http 高下文)，每个做事器指令掌握对特定域或 IP 地址上的资源要求的处理。
做事器高下文中的一个或多个位置高下定亲义了如何处理特定的 URI 凑集。
对付邮件和 TCP 流量(mail 和 stream 高下文)，做事器指令各自掌握到达特定 TCP 端口或
UNIX 套接字的流量处理。
以下配置解释了高下文的利用情形。
user nobody; # a directive in the 'main' context
events {
# configuration of connection processing
}
http {
# Configuration specific to HTTP and affecting all virtual servers
server {
# configuration of HTTP virtual server 1
location /one {
# configuration for processing URIs with '/one'
}
location /two {
# configuration for processing URIs with '/two'
}
}
server {
# configuration of HTTP virtual server 2
}
}
stream {
# Configuration specific to TCP and affecting all virtual servers
server {
# configuration of TCP virtual server 1
}
}
对付大多数指令，在另一个高下文(子高下文)中定义的高下文将继续父级中包含的伪指令的
值。 要覆盖从父进程继续的值，请在子高下文中包含该指令。
要变动配置文件才能生效，NGINX 必须重新加载该文件。可以重新启动 nginx 进程或发送
reload 旗子暗记来升级配置，而不会中断当前要求的处理。
Nginx 配置 Web 做事器
先容如何将 NGINX 配置作为 Web 做事器，并包括以下部分：
设置虚拟做事器
配置位置
利用变量
返回特定状态码
重写要求中的 URI
重写 HTTP 相应
处理缺点
在高层次上，将 NGINX 配置作为 Web 做事器有一些问题须要理解，定义它处理哪些 URL
以及如何处理这些 URL 上的资源的 HTTP 要求。 在较低层次上，配置定义了一组掌握对特
定域或 IP 地址的要求的处理的虚拟做事器。
用于 HTTP 流量的每个虚拟做事器定义了称为位置的分外配置实例，它们掌握特定 URI
凑集的处理。 每个位置定义了自己的映射到此位置的要求发生的情形。 NGINX 可以完备控
制这个过程。 每个位置都可以代理要求或返回一个文件。 此外，可以修正 URI，以便将请
求重定向到另一个位置或虚拟做事器。 此外，可以返回特定的缺点代码，也可以配置特定
的页面以对应于每个缺点代码。
1. 虚拟做事器
NGINX 配置文件必须至少包含一个做事器指令来定义虚拟做事器。 当 NGINX 处理要求时，
它首先选择供应要求的虚拟做事器。
虚拟做事器由 http 高下文中的做事器指令定义，例如：
http {
server {
# Server configuration
}
}
可以将多个 server 指令添加到 http 高下文中以定义多个虚拟做事器。
server 配置块常日包括一个 listen 指令，用于指定做事器侦听要求的 IP 地址和端口(或
Unix 域套接字和路径)。IPv4 和 IPv6 地址均被接管; 将方括号(。
下面的示例显示了监听 IP 地址 127.0.0.1 和端口 8080 的做事器的配置：
server {
listen 127.0.0.1:8080;
# The rest of server configuration
}
如果省略端口，则利用标准端口。 同样地，如果省略一个地址，做事器将侦听所有地址。
如果没有包含 listen 指令，则“标准”端口为 80/tcp，“default”端口为 8000/tcp，详细取决
于超级用户权限。
如果有多个做事器与要求的 IP 地址和端口相匹配，则 NGINX 将根据做事器块中的
server_name 指令测试要求的主机头域。 server_name 的参数可以是完全(精确)名称，
通配符或正则表达式。 通配符是一个字符串，其开头，结尾或两者都包含星号(); 星号匹
配任何字符序列。 NGINX 将 Perl 语法用于正则表达式; 在它们之前利用波浪号(〜)。 此示
例解释了一个确切的名称。
server {
listen 80;
server_name example.org www.example.org;
...
}
如果匹配主机头几个名称，则 NGINX 通过按以下顺序搜索名称并利用其找到的第一个匹配
来选择一个：
确切的名字(完全准确的名称)
以星号开头的最长通配符，例如:.example.org
以星号结尾的最长通配符，如：mail.
第一个匹配正则表达式(按照涌如今配置文件中的顺序)
如果主机头字段与做事器名称不匹配，则 NGINX 会将要求路由到要求到达端口的默认做事
器。 默认做事器是 nginx.conf 文件中列出的第一个做事器，除非您将 listen_server
参数包含在 listen 指令中以明确指定做事器为默认值。
server {
listen 80 default_server;
...
}
一个完全的 Nginx 虚拟机配置示例，这里我们演示配置两个虚拟机，对应域名分别为：
vhost1.com 和 vhost2.com，vhost1.com 网站的主目录在 html/www/vhost1，
vhost2.com 网站的主目录在/usr/local/nginx/html/www/vhost1：
events {
worker_connections 1024;
}
http {
server {
listen 8888;
server_name vhost1.com www.vhost1.com;
index example.html;
root /usr/local/nginx/html/www/vhost1/;
access_log /usr/local/nginx/logs/vhost1.com.log;
}
server {
listen 8889;
server_name vhost2.com www.vhost2.com;
index example.html;
root /usr/local/nginx/html/www/vhost2/;
access_log /usr/local/nginx/logs/vhost2.com.log;
}
2. 配置位置
NGINX 可以根据要求 URI 向不同的代理发送流量或供应不同的文件。 这些块是利用放置在
server 指令中的 location 指令来定义的。
例如，您可以定义三个 location 块，以指示虚拟做事器向一个代理做事器发送一些要求，
将其他要求发送到不同的代理做事器，并通过从本地文件系统通报文件来供应别的要求。
NGINX 测试根据所有 location 指令的参数要求 URI，并运用匹配 location 中定义的指
令。 在每个 location 块内，常日可能(除了一些例外)放置更多的 location 指令以进一
步细化特定组要求的处理。
把稳：在本教程文章中，单词 location 是指单个 location 高下文。
location 指令有两种类型的参数：前缀字符串(路径名)和正则表达式。
对付要匹配前缀字
符串的要求 URI，必须以前缀字符串开头。
具有 pathname 参数的以下示例位置匹配以 /some/path/开头的要求 URI，例如
/some/path/document.html，它不匹配/my-site/some/path，由于/some/path 不在
该 URI 的开头涌现。
location /some/path/ {
...
}
正则表达式之前是区分大小写匹配的波形符号(~)，或者不区分大小写匹配的波形符号(~)。
以下示例将包含字符串.html 或.html 的 URI 与任何位置相匹配。
location ~ \.html? {
...
}
要找到最符合 URI 的位置，NGINX 首先将 URI 与前缀字符串的位置进行比较。然后用正则表
达式搜索位置。
除非利用^~润色符对正则表达式给予更高的优先级。在前缀字符串中，NGINX 选择最详细的
字符串(也便是最长和最完全的字符串)。 下面给出了选择处理要求的位置的确切逻辑：
测试所有 URI 的前缀字符串。
=(等号)润色符定义了 URI 和前缀字符串完备匹配。如果找到完备匹配，则搜索停滞。
如果^~(插入符号)润色符预先添加最长匹配前缀字符串，则不会检讨正则表达式。
存储最长匹配的前缀字符串。
根据正则表达式测试 URI。
断开第一个匹配的正则表达式并利用相应的位置。
如果没有正则表达式匹配，则利用与存储的前缀字符串相对应的位置。
=润色符的范例用例是/(正斜杠)的要求。
如果要求/是频繁的，则指定=/作为 location 指
令的参数加速处理，由于搜索匹配在第一次比较之后停滞。
location = / {
...
}
location 高下文可以包含定义如何解析要求的指令 - 供应静态文件或将要求通报给代理
的做事器。 在以下示例中，匹配第一个 location 高下文的要求将从/data/images 目录
中供应文件，并将匹配第二个位置的要求通报给承载 www.example.com 域内容的代理服
务器。
server {
location /images/ {
root /data;
}
location / {
proxy_pass http://www.example.com;
}
}
root 指令指定要在个中搜索要供应的静态文件的文件系统路径。 与该位置干系联的要求
URI 将附加到路径，以获取要供应的静态文件的全名。 在上面的示例中，要相应
/images/logo.png 的 请 求 ， NGINX 提 供 服 务 器 本 地 实 际 对 应 文 件 是 ：
/data/images/logo.png。
proxy_pass 指令将要求通报给利用配置的 URL 访问代理做事器。然后将代理做事器的响
应传回客户端。在上面的示例中，所有不以/images/开头的 URI 的要求都将被通报给代理
的做事器(也便是：www.example.com)。
3. 利用变量
可以利用配置文件中的变量，使 NGINX 进程的要求根据定义的情形而有所不同。 变量是在
运行时打算的命名值，用作指令的参数。 一个变量由它的名字开头的$(美元)符号表示。
变
量根据 NGINX 的状态定义信息，例如正在处理的要求的属性。
有许多预定义的变量，如核心 HTTP 变量，您可以利用 set，map 和 geo 指令定义自定义变
量。 大多数变量在运行时打算的，并包含与特定要求干系的信息。 例如，$remote_addr
包含客户端 IP 地址，$uri 保存当前的 URI 值。
4. 返回特定状态码
一些网站 URI 须要立即返回具有特定缺点或重定向代码的相应，例如当页面被暂时移动或永
久移动时。 最大略的方法是利用 return 指令。 例如返回未找到的 404 状态码：
location /wrong/url {
return 404;
}
返回的第一个参数是相应代码。可选的第二个参数可以是重定向的 URL(代码 301,302,303
和 307)或在相应体中返回文本。 例如：
location /permanently/moved/url {
return 301 http://www.example.com/moved/here;
}
返回指令可以包含在 location 和 server 高下文中。
5. 重写 URI 要求
可以通过利用 rewrite 指令在要求处理期间多次修正要求 URI，该指令具有一个可选参数
和两个必需参数。 第一个(必需)参数是要求 URI 必须匹配的正则表达式。 第二个参数是用
于更换匹配 URI 的 URI。 可选的第三个参数是可以停滞进一步重写指令的处理或发送重定
向(代码 301 或 302)的标志。例如：
location /users/ {
rewrite ^/users/(.)$ /show?user=$1 break;
}
如该示例所示，用户通过匹配正则表达式捕获第二个参数。
您可以在 location 和 server 高下文中包含多个 rewrite 指令。 NGINX 按照它们发生
的顺序逐个实行指令。 当选择该高下文时，server 高下文中的 rewrite 指令将被实行一
次。
在 NGINX 处理一组 rewrite 指令之后，它根据新的 URI 选择一个 location 高下文。 如
果所选 location 块包含 rewrite 指令，则依次实行它们。 如果 URI 与个中任何一个匹
配，则在处理所有定义的 rewrite 指令之后，将搜索新 location 块。
以下示例显示了与返回指令相结合的 rewrite 指令。
server {
...
rewrite ^(/download/.)/media/(.)\..$ $1/mp3/$2.mp3 last;
rewrite ^(/download/.)/audio/(.)\..$ $1/mp3/$2.ra last;
return 403;
...
}
此示例配置区分两组 URI。 诸如/download/some/media/file 之类的 URI 变动为
/download/some/mp3/file.mp3。由于末了一个标志，以是跳过后续指令(第二次
rewrite 和 return 指令)，但 NGINX 连续处理该要求，该要求现在具有不同的 URI。类似
地，诸如/download/some/audio/file 的URI被更换为/download/some/mp3/file.ra。
如果 URI 与 rewrite 指令不匹配，则 NGINX 将 403 缺点代码返回给客户端。
有两个中断处理重写指令的参数：
last - 停滞实行当前做事器或位置高下文中的重写指令，但是 NGINX 会搜索与重写的
URI 匹配的位置，并且运用新位置中的任何重写指令(URI 可以再次变动，往下连续匹配)。
break - 像 break 指令一样，在当前高下文中停滞处理重写指令，并取消搜索与新 URI
匹配的位置。新位置(location)块中的 rewrite 指令不实行。
6. 重写 HTTP 相应
有时您须要重写或变动 HTTP 相应中的内容，将一个字符串更换为另一个字符串。 您可以
利用 sub_filter 指令来定义要运用的重写。 该指令支持变量和替代链，使更繁芜的变动
成为可能。
例如，您可以变动引用除代理做事器之外的绝对链接：
location / {
sub_filter /blog/ /blog-staging/;
sub_filter_once off;
}
另一个示例将方法从 http://变动为 http://，并从要求头域更换本地主机地址到主机名。
sub_filter_once 指令见告 NGINX 在一个位置(location)内连续运用 sub_filter 伪指
令：
location / {
sub_filter 'href="http://127.0.0.1:8080/'
'href="http://$host/';
sub_filter 'img src="http://127.0.0.1:8080/' 'img
src="http://$host/';
sub_filter_once on;
}
请把稳，如果发生另一个 sub_filter 匹配，则利用 sub_filter 修正的相应部分将不再
被更换。
7. 处理缺点
利用 error_page 指令，您可以配置 NGINX 返回自定义页面以及缺点代码，更换相应中的
其他缺点代码，或将浏览看重定向到其他 URI。
在以下示例中，error_page 指令指定要返
回 404 页面缺点代码的页面(/404.html)。
error_page 404 /404.html;
请把稳，此伪指令并不立即返回该缺点(返回指令实行该操作)，而仅仅是指定发生时如何处
理缺点。 缺点代码可以来自代理做事器，或者在 NGINX 处理期间发生(例如，当 NGINX 找
不到客户端要求的文件时，显示 404 对应的结果)。
在以下示例中，当 NGINX 找不到页面时，它会将代码 301 更换为代码 404，并将客户端重
定向到http:/example.com/new/path.html。当客户端仍考试测验访问其旧URI的页面时，
此配置非常有用。 301 代码关照浏览器页面已经永久移动，并且须要在返回时自动更换旧
地址。
location /old/path.html {
error_page 404 =301 http:/example.com/new/path.html;
}
以下配置是在未找到文件时将要求通报给后真个示例。 由于在 error_page 指令的等号之
后没有指定状态代码，以是对客户机的相应具有代理做事器返回的状态代码(不一定是 404)。
server {
...
location /images/ {
# Set the root directory to search for the file
root /data/www;
# Disable logging of errors related to file existence
open_file_cache_errors off;
# Make an internal redirect if the file is not found
error_page 404 = /fetch$uri;
}
location /fetch/ {
proxy_pass http://backend/;
}
}
当没有找到文件时，error_page 指令指示 NGINX 进行内部重定向。 error_page 指令的
终极参数中的$uri 变量保存当前要求的 URI，该 URI 在重定向中被通报。
例如，如果没有找到/images/some/file，它将被更换为/fetch/images/some/file，
并且新的搜索位置(location)开始。末了要求终极在第二个 location 高下文中，并被代
理到 http://backend/。
如果没有找到文件，则 open_file_cache_errors 指令可防止写入缺点。 由于丢失的文件
可被精确地处理，但这不是必需的。
Nginx 配置静态内容做事器先容如何利用 NGINX 来供应静态内容做事，定义搜索路径以查找要求的文件的方法，以及
如何设置索引文件。
在这个部分，我们紧张涉及以下几个方面的内容：
根目录和索引文件
考试测验几个选项
优化 NGINX 做事内容的速率
1. 根目录和索引文件
root 指令指定将用于搜索文件的根目录。 要获取要求文件的路径，NGINX 将要求 URI
附加到 root 指令指定的路径。 该指令可以放置在 http，server 或 location 高下文中
的任何级别上。
不才面的示例中，为虚拟做事器定义了 root 指令。
它适用于不包括 root
指令的所有 location 块以显式重新定义根：
server {
root /www/data;
location / {
}
location /images/ {
}
location ~ \.(mp3|mp4) {
root /www/media;
}
}
这里，NGINX 在文件系统的/www/data/images/目录中搜索以/images/开头的 URI。 但
是，如果 URI 以.mp3 或.mp4 扩展名结尾，则 NGINX 会在/www/media/目录中搜索.mp3
或.mp4 文件，由于它在匹配的 location 块中定义。
如果要求以斜杠结尾，则 NGINX 将其视为对目录的要求，并考试测验在目录中找到索引文件。
index 指令定义索引文件的名称(默认值为 index.html)。
如果要求 URI 为/images/some/path/，则 NGINX 会通报文件/www/data/images/
/index.html(如果存在)。
如果不存在文件，NGINX 默认返回 HTTP 代码 404(未找到)。 要配置 NGINX 以返回自动天生
的目录列表，请将 on 参数添加到 autoindex 指令中：
location /images/ {
autoindex on;
}
可以在索引指令中列出多个文件名。 NGINX 以指定的顺序搜索文件，并返回它找到的第一
个文件。
location / {
index index.$geo.html index.html index.html;
}
这里利用的$geo 变量是通过 geo 指令设置的自定义变量。 变量的值取决于客户真个 IP 地
址。
要返回索引文件，NGINX 检讨其是否存在，然后通过将索引文件的名称附加到基本 URI 来对
通过 URI 获取的内部重定向。内部重定向会导致对某个位置(location)的新搜索，并且可
能会在另一个位置(location)中结束，如以下示例所示：
location / {
root /data;
index index.html index.php;
}
location ~ \.php {
fastcgi_pass localhost:8000;
...
}
在这里，如果要求中的 URI 是/path/，并且/data/path/index.html 不存在，但是
/data/path/index.php 存在，则将/path/index.php 内部重定向映射到第二个位置
(location)。 因此，要求被代理。
2. 考试测验几个选项
try_files 指令可用于检讨指定的文件或目录是否存在并进行内部重定向，如果没有指定的文
件或目录，则返回特定的状态代码。 例如，要检讨与要求 URI 相对应的文件的存在，请使
用 try_files 指令和$uri 变量，如下所示：
server {
root /www/data;
location /images/ {
try_files $uri /images/default.gif;
}
}
该文件以 URI 的形式指定，它利用在当前位置或虚拟做事器的高下文中设置的 root 或
alias 伪指令进行处理。 在这种情形下，如果与原始 URI 相对应的文件不存在，则 NGINX
将内部重定向到末了一个参数中指定的 URI，也便是返回 default.gif。
末了一个参数也可以是一个状态代码(直接在前面的等号)或位置的名称。
在以下示例中，如
果 try_files 指令的任何参数都不会解析为现有文件或目录，则会返回 404 缺点。
location / {
try_files $uri $uri/ $uri.html =404;
}
不才一个示例中，如果原始 URI 和带有附加尾部斜线的 URI 都不能解析为现有文件或目录，
则将要求重定向到将其通报给代理做事器的命名位置(location)。
location / {
try_files $uri $uri/ @backend;
}
location @backend {
proxy_pass http://backend.example.com;
}
3. 优化 NGINX 做事内容的速率
加载速率是做事任何内容的关键成分。 对您的 NGINX 配置进行小幅优化可能会提高生产力
并帮助实现最佳性能。
启用 sendfile
默认情形下，NGINX 会自动处理文件传输，并在发送文件之前将其复制到缓冲区中。 启用
sendfile 指令将肃清将数据复制到缓冲区中的步骤，并许可将数据从一个文件描述符直接复
制到另一个文件描述符。 或者，为了防止一个快速连接完备占用事情进程，您可以通过定
义 sendfile_max_chunk 指令来限定在单个 sendfile()调用中传输的数据量：
location /mp3 {
sendfile on;
sendfile_max_chunk 1m;
...
}
启用 tcp_nopush
将 tcp_nopush 选项与 sendfile 一起利用。 该选项将使 NGINX 能够通过 sendfile 获取
数据块之后，在一个数据包中发送 HTTP 相应头
location /mp3 {
sendfile on;
tcp_nopush on;
...
}
启用 tcp_nodelay
tcp_nodelay 选项可以覆盖 Nagle 的算法，最初是为理解决慢网络中的小数据包问题而设计
的。 该算法将大量小数据包整合到较大的数据包中，并以 200 ms 的延迟发送数据包。
如今，当做事大型静态文件时，无论数据包大小如何，都可以立即发送数据。 延迟也会影
响在线运用程序(ssh，在线游戏，网上交易)。
默认情形下，tcp_nodelay 指令设置为 on，
表示 Nagle 的算法被禁用。 该选项仅用于 Keepalive 连接：
location /mp3 {
tcp_nodelay on;
keepalive_timeout 65;
...
}
优化积压行列步队
个中一个主要成分是 NGINX 可以处理传入连接的速率。 一样平常规则是建立连接时，将其放入
监听套接字的“侦听”行列步队中。 在正常负载下，有一个低行列步队，或根本没有行列步队。 但是在高
负载下，行列步队可能会急剧增长，这可能会导致性能不屈衡，连接丢失和延迟。
丈量侦听行列步队
让我们来查看当前的侦听行列步队。 运行命令：
netstat -Lan
命令输出可能如下所示：
Current listen queue sizes (qlen/incqlen/maxqlen)
Listen Local Address
0/0/128 .12345
10/0/128 .80
0/0/128 .8080
命令输出显示端口 80 的监听行列步队中有 10 个不接管的连接，而连接限定为 128 个连接，这
种情形是正常的。
但是，命令输出可能如下所示：
Current listen queue sizes (qlen/incqlen/maxqlen)
Listen Local Address
0/0/128 .12345
192/0/128 .80
0/0/128 .8080
命令输出显示超过 128 个连接限定的 192 个不可接管的连接。 当网站的流量很大时，这是
很常见的。 为了达到最佳性能，您须要增加 NGINX 在操作系统和 NGINX 配置中排队等待接
收的最大连接数。
调度操作系统
将 net.core.somaxconn 键的值从其默认值(128)增加到足够高的值以能够处理高突发流
量：
打开文件：/etc/sysctl.conf，将下面一行添加到文件并保存文件：
net.core.somaxconn = 4096
调度 NGINX
如果将 somaxconn 键设置为大于 512 的值，请变动 NGINX listen 指令的 backlog 参数以
匹配：
server {
listen 80 backlog 4096;
# The rest of server configuration
}
Nginx 反向代理
先容代理做事器的基本配置。 您将学习如何通过不同协议将 NGINX 要求通报给代理的做事
器，修正发送到代理做事器的客户端要求标头，以及配置来自代理做事器的相应缓冲。
代理做事器的基本配置目录
代理做事器先容
将要求通报给代理的做事器
通报要求标头
配置缓冲区
选择传出 IP 地址
1. 代理做事器先容
代理常日用于在多个做事器之间分配负载，无缝地显示来自不同网站的内容，或者通过 HTTP
以外的协议将要求通报给运用做事器。
2. 将要求通报给代理的做事器
当 NGINX 代理要求时，它将要求发送到指定的代理做事器，获取相应，并将其发送回客户
端。 可以利用指定的协议将要求代理到 HTTP 做事器(另一个 NGINX 做事器或任何其他做事
器)或非 HTTP 做事器(可以运行利用特定框架开拓的运用程序，如 PHP 或 Python)。 支持的
协议包括 FastCGI，uwsgi，SCGI 和 memcached。
要将要求通报给 HTTP 代理做事器，则在一个 location 块内指定 proxy_pass 指令。 例如：
location /some/path/ {
proxy_pass http://www.example.com/link/;
}
此 示 例 配 置 将 在 此 location 处 理 的 所 有 请 求 传 递 到 指 定 地 址
(www.example.com/link/)处的代理做事器。该地址可以指定为域名或 IP 地址。 该
地址还可能包括一个端口：
location ~ \.php {
proxy_pass http://127.0.0.1:8000;
}
请把稳，在上述第一个示例中，代理做事器的地址后面是 URI 为 /link/。 如果 URI 与地
址一起指定，它将更换与 location 参数匹配要求 URI 的部分。 例如，这里利用
/some/path/page.html 的 URI 要求将被代理到 www.example.com/link/page.html。
如果地址被指定为没有 URI，或者不可能确定要更换的 URI 部分，则会通报完全的要求 URI(可
能是修正)。
要将要求通报给非 HTTP 代理做事器，应利用适当的_ pass 指令：
fastcgi_pass 将要求通报给 FastCGI 做事器
uwsgi_pass 将要求通报给 uwsgi 做事器
scgi_pass 将要求通报给 SCGI 做事器
memcached_pass 将要求通报给 memcached 做事器
请把稳，在这些情形下，指定地址的规则可能不同。
您可能还须要向做事器通报其他参数。
proxy_pass 指令也可以指向一组命名的做事器。 在这种情形下，根据指定的方法在组中
的做事器之间分配要求。
3. 通报要求标头
默认情形下，NGINX 在代理要求“Host” 和 “Connection”中重新定义了两个头字段，
并肃清了其值为空字符串的头字段。 “Host”设置为$proxy_host 变量，“Connection”
设置为关闭(close)。
要变动这些设置，以及修正其他 header 字段，请利用 proxy_set_header 指令。 该指
令可以在一个或多个位置(location)指定。 它也可以在特定的 server 高下文或 http 块
中指定。 例如：
location /some/path/ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://localhost:8000;
}
在此配置中，“Host”字段设置为 $host 变量。
为了防止头域被通报给代理做事器，请将其设置为空字符串，如下所示：
location /some/path/ {
proxy_set_header Accept-Encoding "";
proxy_pass http://localhost:8000;
}
4. 配置缓冲区
默认情形下，NGINX 缓存来自代理做事器的相应。 相应存储在内部缓冲区中，并且不
会发送到客户端，直到收到全体相应。 缓冲有助于通过慢客户端优化性能，如果相应从
NGINX 同步通报到客户端，这可能会摧残浪费蹂躏代理做事器韶光。
然而，当启用缓冲时，NGINX 允
许代理做事器快速处理相应，而 NGINX 存储相应韶光与客户端须要下载的韶光一样长。
卖力启用和禁用缓冲的指令是 proxy_buffering。 默认情形下，它被设置为开启且缓冲
已启用。
proxy_buffers 指令掌握分配给要求的缓冲区的大小和数量。 来自代理做事器的响
应的第一部分存储在单独的缓冲区中，其大小由 proxy_buffer_size 指令设置。 这部分常日
包含一个比较小的相应头，并且可以比别的的相应的缓冲区小。
在以下示例中，缓冲区的默认数量增加，并且相应的第一部分的缓冲区的大小小于默认
值。
location /some/path/ {
proxy_buffers 16 4k;
proxy_buffer_size 2k;
proxy_pass http://localhost:8000;
}
如果缓存被禁用，则在从代理做事器吸收缓冲时，相应将同步发送到客户端。 对付须要尽
快开始吸收相应的快速交互式客户端，此行为可能是可取的。
要禁用特定位置的缓冲，请在 location 块中将 proxy_buffering 伪指令设置为 off，
如下所示：
location /some/path/ {
proxy_buffering off;
proxy_pass http://localhost:8000;
}
在这种情形下，NGINX 只利用由 proxy_buffer_size 配置的缓冲区来存储相应确当前部
分。
5. 选择传出 IP 地址
如果您的代理做事器有多个网络接口，有时您可能须要选择特定的源 IP 地址才能连接到代
理做事器或上游。 如果 NGINX 后真个代理做事器只配置为接管来自特定 IP 网络或 IP 地址
范围的连接，在这种情形下，这个配置选项就很有用。
指定 proxy_bind 指令和必要网络接口的 IP 地址：
location /app1/ {
proxy_bind 127.0.0.1;
proxy_pass http://example.com/app1/;
}
location /app2/ {
proxy_bind 127.0.0.2;
proxy_pass http://example.com/app2/;
}
IP 地址也可以用变量指定。 例如，$server_addr 变量通报接管要求的网络接口的 IP 地址：
location /app3/ {
proxy_bind $server_addr;
proxy_pass http://example.com/app3/;
}
Nginx 压缩和解压先容如何配置相应的压缩或解压缩以及发送压缩文件。涉及内容如下：
压缩和解压缩先容
启用压缩
启用解压缩
发送压缩文件
1. 压缩和解压缩先容
压缩相应常日会显著减少传输数据的大小。 然而，由于压缩在运行时发生，它还可以增加
相称大的处理开销，这会对性能产生负面影响 在向客户端发送相应之前，NGINX 会实行压
缩，但不会“压缩”已压缩的相应(例如，由代理的做事器)。
2. 启用压缩
要启用压缩，请利用包含 gzip 指令并指定 on 值。
gzip on;
默认情形下，NGINX 仅利用 MIME 类型 text/html 压缩相应。要利用其他 MIME 类型压缩
相应，请包含 gzip_types 指令并列出其他类型。
gzip_types text/plain application/xml;
要指定要压缩的相应的最小长度，请利用 gzip_min_length 指令。 默认值为 20 字节(可将此
处调度为 1000)：
gzip_min_length 1000;
默认情形下，NGINX 不会压缩对代理要求的相应(来自代理做事器的要求)。
要求来自代理服
务器的事实由要求中 Via 头字段的存在确定。 要配置这些相应的压缩，请利用 gzip_proxied
指令。 该指令具有多个参数，指定 NGINX 应压缩哪种代理要求。例如，仅对不会在代理服
务器上缓存的要求压缩相应是合理的。 为此，gzip_proxied 指令具有指示 NGINX 在相应
中检讨 Cache-Control 头字段的参数，如果值为 no-cache, no-store 或 private，则
压缩相应。 其余，您必须包括 Expires 参数以用来检讨 Expires 头域的值。 这些参数
在以下示例中与 auth 参数一起设置，该参数检讨 Authorization 头字段的存在(授权响
应特定于终极用户，并且常日不被缓存)：
gzip_proxied no-cache no-store private expired auth;
与大多数其他指令一样，配置压缩的指令可以包含在http 高下文中，也可以包含在 server
或 location 配置块中。
gzip 压缩的整体配置可能如下所示。
server {
gzip on;
gzip_types text/plain application/xml;
gzip_proxied no-cache no-store private expired auth;
gzip_min_length 1000;
...
}
3. 启用解压缩
某些客户端不支持利用 gzip 编码方法的相应。 同时，可能须要存储压缩数据，或者即时
压缩相应并将它们存储在缓存中。 为了成功地做事于不接管压缩数据的客户端，NGINX 可
以在将数据发送到后一种类型的客户端时即时解压缩数据。
要启用运行时解压缩，请利用 gunzip 指令。
location /storage/ {
gunzip on;
...
}
gunzip 指令可以在与 gzip 指令相同的高下文中指定：
server {
gzip on;
gzip_min_length 1000;
gunzip on;
...
}
请把稳，此指令在单独的模块中定义，默认情形下可能不包含在开源 NGINX 构建中。
4. 发送压缩文件
要将文件的压缩版本发送到客户端而不是常规文件，请在适当的高下文中将 gzip_static
指令设置为 on。
location / {
gzip_static on;
}
在 这 种 情 况 下 ， 为 了 服 务 /path/to/file 的 请 求 ， NGINX 尝 试 查 找 并 发 送 文 件
/path/to/file.gz。 如果文件不存在，或客户端不支持 gzip，则 NGINX 将发送未压缩
版本的文件。
请把稳，gzip_static 指令不启用即时压缩。它只是利用压缩工具预先压缩的文件。要在
运行时即时压缩内容(而不仅仅是静态内容)，请利用 gzip 指令。
该指令在单独的模块中定义，默认情形下可能不包含在开源 NGINX 构建中。
Nginx 内容缓存先容如何启用和配置从代理做事器吸收的相应的缓存。紧张涉及以下内容:
缓存先容
启用相应缓存
涉及缓存的 NGINX 进程
指定要缓存的要求
限定或绕过缓存
从缓存中打消内容配置缓存打消发送打消命令限定访问打消命令从缓存中完备删除文件 缓存打消配置示例
字节缓存
组合配置示例
1. 先容
当启用缓存时，NGINX 将相应保存在磁盘缓存中，并利用它们来相应客户端，而不必每次都
为同一内容代理要求。
2. 启用相应缓存
要启用缓存，请在顶层的 http 高下文中包含 proxy_cache_path 指令。 逼迫的第一个参数
是缓存内容确当地文件系统路径，逼迫 keys_zone 参数定义用于存储有关缓存项目的元数
据的共享内存区域的名称和大小：
http {
...
proxy_cache_path /data/nginx/cache keys_zone=one:10m;
}
然后在要缓存做事器相应的高下文(协议类型，虚拟做事器或位置)中包含 proxy_cache 指
令，将由 keys_zone 参数定义的区域名称指定为 proxy_cache_path 指令(在本例中为
一)：
http {
...
proxy_cache_path /data/nginx/cache keys_zone=one:10m;
server {
proxy_cache one;
location / {
proxy_pass http://localhost:8000;
}
}
}
请把稳，由 keys_zone 参数定义的大小不会限定缓存的相应数据的总量。 缓存相应本身
存储在文件系统上的特定文件中的元数据副本。
要限定缓存的相应数据量，请将 max_size
参数包含到 proxy_cache_path 指令中(但请把稳，缓存数据的数量可能会临时超出此限
制，如以下部分所述。)
3. 涉及缓存的 NGINX 进程
缓存中还有两个额外的 NGINX 进程：
缓存管理器周期性地被激活以检讨缓存的状态。 如果缓存大小超过了由 max_cize_path
指令设置的 max_size 参数，缓存管理器将删除最近访问的数据。如前所述，高速缓存管理
器激活之间的缓存数据量可以临时超过限定。
NGINX 启动后，缓存加载程序只运行一次。 它将有关以前缓存的数据的元数据加载到共享
内存区域。一次加载全体缓存可能会在启动后的最初几分钟内花费足够的资源来减慢 NGINX
的性能。 为了避免这种情形，请通过将以下参数包含到 proxy_cache_path 伪指令来配
置缓存的迭代加载：
loader_threshold - 迭代的持续韶光，以毫秒为单位(默认为 200)
loader_files - 在一次迭代期间加载的最大项目数(默认为 100)
loader_sleeps - 迭代之间的延迟(以毫秒为单位)(默认为 50)
在以下示例中，迭代持续 300 毫秒或直到加载了 200 个项目：
proxy_cache_path /data/nginx/cache keys_zone=one:10m
loader_threshold=300 loader_files=200;
4. 指定要缓存的要求
默认情形下，NGINX 首次从代理做事器吸收到这样的相应后，缓存对 HTTP GET 和 HEAD 方
法的要求的所有相应。 作为要求的密钥(标识符)，NGINX 利用要求字符串。 如果要求具有
与缓存相应相同的密钥，则 NGINX 将缓存的相应发送给客户端。 您可以在 http, server,
或 location 高下文中包含各种指令，以掌握哪些相应被缓存。
要变动在打算密钥时利用的要求字符，请包括 proxy_cache_key 伪指令：
proxy_cache_key "$host$request_uri$cookie_user";
要 定 义 在 缓 存 响 应 之 前 必 须 进 行 具 有 相 同 密 钥 的 请 求 的 最 小 次 数 ， 请 包 括
proxy_cache_min_uses 指令：
proxy_cache_min_uses 5;
要利用除 GET 和 HEAD 之外的方法来缓存对要求的相应，请将它们与 GET 和 HEAD 一起列为
proxy_cache_methods 伪指令的参数：
proxy_cache_methods GET HEAD POST;
5. 限定或绕过缓存
默认情形下，相应将无限期地保留在缓存中。 只有缓存超过最大配置大小，然后按照末了
一次要求的韶光长度，它们才被删除。
您可以通过在 http, server, 或 location 高下文
中包含指令来设置缓存相应被认为有效的韶光长度，乃至是否利用它们。
要限定缓存相应与特定状态代码被认为有效的韶光，请包括 proxy_cache_valid 指令：
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
在此示例中，利用代码 200 或 302 的相应有效韶光为 10 分钟，并且代码 404 的相应有效
1 分钟。 要定义具有所有状态代码的相应的有效韶光，请指定 any 作为第一个参数：
proxy_cache_valid any 5m;
要定义 NGINX 不会向客户端发送缓存相应的条件，请包括 proxy_cache_bypass 指令。
每个参数定义一个条件并由多个变量组成。
如果至少有一个参数不为空，并且不即是“0”(零)，
则 NGINX 不会在缓存中查找相应，而是将要求立即转发到后端做事器。
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
要定义 NGINX 根 本 不 缓 存 响 应 的 条 件 ， 请 包 括 proxy_no_cache 指 令 ， 以 与
proxy_cache_bypass 伪指令相同的办法定义参数。
proxy_no_cache $http_pragma $http_authorization;
6. 从缓存中打消内容
NGINX 可以从缓存中删除过期的缓存文件。删除过期的缓存内容以防止同时供应旧版本和新
版本的网页。
在吸收到包含自定义 HTTP 头或“PURGE” HTTP 方法的分外“purge”要求时，缓
存被打消。
6.1 配置缓存打消
我们设置一个配置来标识利用“PURGE” HTTP 方法的要求并删除匹配的 URL。
在 http 块 层 级 上 ， 创 建 一 个 新 变 量 ， 例 如 ： $purge_method ，这将取决于
$request_method 变量：
http {
...
map $request_method $purge_method {
PURGE 1;
default 0;
}
}
在 location 中配置高速缓存，包括指定缓存打消要求的条件的 proxy_cache_purge 指令。
在我们的例子中，它是在上一步配置的$purge_method：
server {
listen 80;
server_name www.example.com;
location / {
proxy_pass http://localhost:8002;
proxy_cache mycache;
proxy_cache_purge $purge_method;
}
}
6.3 发送打消命令
配置 proxy_cache_purge 指令后，您须要发送一个分外的缓存打消要求来打消缓存。 您
可以利用一系列工具发出打消要求，例如 curl 命令：
$ curl -X PURGE -D – "http://www.example.com/"
HTTP/1.1 204 No Content
Server: nginx/1.5.7
Date: Sat, 01 Dec 2015 16:33:04 GMT
Connection: keep-alive
在该示例中，具有公共 URL 部分(由星号通配符指定)的资源将被删除。 但是，这些高速缓零声学院 版权所有存条款将不会从缓存中完备删除：它们将保留在磁盘上，直到它们被删除为非活动状态
(proxy_cache_path 的非活动参数)，或由缓存打消程序进程处理，或客户端考试测验访问它们 。
6.4 限定访问打消命令
建议您配置许可发送缓存打消要求的有限数量的 IP 地址：
geo $purge_allowed {
default 0; # deny from other
10.0.0.1 1; # allow from localhost
192.168.0.0/24 1; # allow from 10.0.0.0/24
}
map $request_method $purge_method {
PURGE $purge_allowed;
default 0;
}
在这个例子中，NGINX 检讨要求中是否利用“PURGE”方法，如果是，剖析客户端 IP 地址。
如果 IP 地址被列入白名单，那么$purge_method 设置为$purge_allowed：“1”许可打消，“0”表示打消。
6.5 从缓存中完备删除文件
要完备删除与星号相匹配的缓存文件，您将须要激活一个分外的缓存打消程序，该过程将永
久地遍历所有缓存条款，并删除与通配符相匹配的条款。
在 http 块级别上，将 purger 参
数添加到 proxy_cache_path 指令中：
proxy_cache_path /data/nginx/cache levels=1:2
keys_zone=mycache:10m purger=on;
6.6 缓存打消配置示例
http {
...
proxy_cache_path /data/nginx/cache levels=1:2
keys_zone=mycache:10m purger=on;
map $request_method $purge_method {
PURGE 1;
default 0;
}
server {
listen 80;
server_name www.example.com;
location / {
proxy_pass http://localhost:8002;
proxy_cache mycache;
proxy_cache_purge $purge_method;
}
}
geo $purge_allowed {
default 0;
10.0.0.1 1;
192.168.0.0/24 1;
}
map $request_method $purge_method {
PURGE $purge_allowed;
default 0;
}
}
7. 字节缓存
有时，初始缓存添补操作可能须要一些韶光，特殊是对付大文件。 当第一个要求开始
下载视频文件的一部分时，下一个要求将不得不等待全体文件被下载并放入高速缓存。
NGINX 使缓存这样的范围要求成为可能，并逐渐用缓存片模块添补高速缓存。 该文件
分为较小的“切片”。 每个范围要求选择将覆盖所要求范围的特定切片，并且如果此范围仍
未缓存，请将其放入缓存中。 对这些切片的所有其他要求将从缓存中获取相应。
要启用字节范围缓存：
确保您的 NGINX 是利用 slice 模块编译的。
利用 slice 指令指定切片的大小：
location / {
slice 1m;
}
slice 的大小应适当调度，使切片快速下载。 在处理要求时，太小的大小可能会导致内存
利用量过多和大量打开的文件描述符，太大的值可能会导致延迟。
将$slice_range 变量包含到缓存键中：
proxy_cache_key $uri$is_args$args$slice_range;
启用利用 206 状态代码缓存相应：
proxy_cache_valid 200 206 1h;
通过在 Range 头字段中通报$slice_range 变量来将通报范围要求设置为代理做事器：
proxy_set_header Range $slice_range;
字节范围缓存示例：
location / {
slice 1m;
proxy_cache cache;
proxy_cache_key $uri$is_args$args$slice_range;
proxy_set_header Range $slice_range;
proxy_cache_valid 200 206 1h;
proxy_pass http://localhost:8000;
}
请把稳，如果切片(slice)缓存打开，则不应变动初始文件。
8. 组合配置示例
以下示例配置组合了上述某些缓存选项。
http {
...
proxy_cache_path /data/nginx/cache keys_zone=one:10m
loader_threshold=300
loader_files=200 max_size=200m;
server {
listen 8080;
proxy_cache one;
location / {
proxy_pass http://backend1;
}
location /some/path {
proxy_pass http://backend2;
proxy_cache_valid any 1m;
proxy_cache_min_uses 3;
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
}
}
}
在这个例子中，两个位置利用相同的缓存，但是以不同的办法。
由于 backend1 做事器的相应很少变动，因此不包括缓存掌握指令。 首次要求相应缓存，
并无限期保持有效。
比较之下，对 backend2 做事的要求的相应频繁变革，因此它们被认为只有 1 分钟有效，
并且在相同要求 3 次之前不被缓存。 此外，如果要求符合 proxy_cache_bypass 指令定
义的条件，则 NGINX 会立即将要求通报给 backend2，而不在缓存中查找。
Nginx 配置日志如何在 NGINX 中配置日志记录缺点和处理的要求。将涉及以下内容
设置缺点日志
设置访问日志
启用条件日志记录
日志记录到 Syslog
1. 设置缺点日志
NGINX 将碰着的不同严重性级别问题的信息写入缺点日志。
error_log 指令将日志记录设
置为特定文件，stderr 或 syslog，并指定要记录的的最低级别。 默认情形下，缺点
日志位于{NGING_INSTALL_PATH}/logs/error.log(绝对路径取决于操作系统和安装)，
并记录来自所指定的所有严重级别的。
以下配置将缺点的最小严重性级别变动为从缺点记录到警告：
error_log logs/error.log warn;
## 或者可写为： error_log /var/logs/nginx/error.log warn;
在这种情形下，将记录 warn, error crit, alert 和 emerg 级别的。
缺点日志的默认设置全局事情。 要覆盖它，将 error_log 指令放在 main (顶级)配置高下
文中。main 高下文中的设置始终由其他配置级别继续。 还可以在 http, stream, server
和 location 级别指定error_log 指令，并覆盖从较高等别继续的设置。如果发生缺点，则该
只写入一个缺点日志，最靠近发生缺点的级别的缺点日志。 但是，如果在同一级
别指定了多个 error_log 伪指令，则会将写入所有指定的日志。
把稳：在开源 NGINX 版本 1.5.2 中添加了在同一配置级别指定多个 error_log 伪指令的功
能。
2. 设置访问日志
在处理要求之后，NGINX 在访问日志中写入有关客户端要求的信息。 默认情形下，访
问日志位于{NGING_INSTALL_PATH}logs/access.log 中，{NGING_INSTALL_PATH}为
安装 nginx 的目录，信息以预定义的组合格式写入日志。要覆盖这个默认设置，请利用
log_format 指令变动记录的格式，以及 access_log 指令，以指定日志的位置及其格式。
日志格式利用变量定义。
以下示例定义扩展预定义组合格式的日志格式，其值指示相应 gzip 的压缩比。 然后
将格式运用于启用压缩的虚拟做事器。
http {
log_format compression '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"
"$gzip_ratio"';
server {
gzip on;
access_log /spool/logs/nginx-access.log compression;
...
}
}
以下是一些如何读取天生韶光值的规则：
当通过多个做事器处理要求时，变量包含由逗号分隔的多个值。
当从一个上游组到另一个上游组有内部重定向时，这些值以分号分隔。
当要求无法到达上游做事器或无法吸收到完全报头时，变量包含“0”(零)。
在连接到上游或从缓存中获取回答时涌现内部缺点的情形下，该变量包含“ - ”(连字符)。
可以通过启用缓冲区的日志和名称包含变量的常用日志文件的描述符缓存来优化
日志记录。 要启用缓冲，请利用 access_log 指令的缓冲区参数来指定缓冲区的大小。 当下
一个日志不适宜缓冲区以及其他情形时，缓冲的将被写入日志文件。
要启用日志文件描述符的缓存，请利用 open_log_file_cache 指令。与 error_log 指令
类似，在特定配置级别定义的 access_log 伪指令将覆盖以前级别的设置。 当要求的处理
完成时，将被写入到当前级别上配置的日志中，或者从先前的级别继续。 如果一个级
别定义了多个访问日志，则会将写入所有的访问日志。
3. 启用条件日志记录
条件记录许可从访问日志中打消噜苏或不主要的日志条款。在 NGINX 中，条件日志记录由
access_log 伪指令的 if 参数启用。
此示例不包括利用 HTTP 状态代码 2xx(成功)和 3xx(重定向)的要求：
map $status $loggable {
~^[23] 0;
default 1;
}
access_log /path/to/access.log combined if=$loggable;
4. 日志记录到 Syslog
syslog 实用程序是打算机记录的标准，并许可从单个 syslog 做事器上的不同设
备网络日志。 在 NGINX 中，对 syslog 的日志记录利用 error_log 和 access_log
伪指令中的 syslog：前缀进行配置。
Syslog 可以发送到做事器=可以是域名，IP 地址或 UNIX 域的套接字路径。 可以使
用端口指定域名或 IP 地址来覆盖默认端口 514. 可以在 unix：prefix 之后指定 UNIX 域套
接字路径：
error_log server=unix:/var/log/nginx.sock debug;
access_log
syslog:server=[2001:db8::1]:1234,facility=local7,tag=nginx,sev
erity=info;
在该示例中，NGINX 缺点日志将在调试日志记录级别写入 UNIX 域套接字，并将访问日志写入具有 IPv6 地址和端口 1234 的 syslog 做事器。
facility =参数指定正在记录的程序类型。 默认值为 local7。 其他可能的值
是：auth，authpriv，daemon，cron，ftp，lpr，kern，mail，news，syslog，user，
uucp，local0 … local7。
tag =参数将自定义标签运用于 syslog (在我们的示例中为 nginx)。
severity =参数设置访问日志的 syslog 的严重性级别。 严重性越来越高的可能
值为：debug，info，notice，warn，error(default)，crit，alert 和 emerg。 消
息记录在指定的级别和更严重的级别。
在我们的示例中，严重性级别缺点还使得可以 crit,
alert 和 emerg 级别。
Nginx 紧张运用处景只针对 Nginx 在不加载第三方模块的情形能处理哪些事情，由于第三方模块太多以是也先容
不完，当然本文本身也可能先容的不完全，这里是根据个人利用过和理解到过总结出来的。
从以下四个方面：
反向代理
负载均衡
HTTP 做事器(包含动静分离)
正向代理
以上便是我理解到的 Nginx 在不依赖第三方模块能处理的事情，下面详细解释每种功能怎么
做
1. 反向代理
反向代理该当是 Nginx 做的最多的一件事了，什么是反向代理呢，反向代理(Reverse Proxy)方
式是指以代理做事器来接管internet上的连接要求，然后将要求转发给内部网络上的做事器，
并将从做事器上得到的结果返回给 internet 上要求连接的客户端，此时期理做事器对外就表
现为一个反向代理做事器。大略来说便是真实的做事器不能直接被外部网络访问，以是须要
一台代理做事器，而代理做事器能被外部网络访问的同时又跟真实做事器在同一个网络环
境，当然也可能是同一台做事器，端口不同而已。
下面贴上一段大略的实现反向代理的代码：
server {
listen 80;
server_name localhost;
client_max_body_size 1024M;
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host:$server_port;
}
}
保存配置文件后启动 Nginx，这样当我们访问 localhost 的时候，就相称于访问 localhost:8080
了。
2. 负载均衡
负载均衡也是 Nginx 常用的一个功能，负载均衡其意思便是分摊到多个操作单元上进行
实行，例如 Web 做事器、FTP 做事器、企业关键运用做事器和其它关键任务做事器等，从而
共同完成事情任务。大略而言便是当有 2 台或以上做事器时，根据规则随机的将要求分发到
指定的做事器上处理，负载均衡配置一样平常都须要同时配置反向代理，通过反向代理跳转到负
载均衡。而 Nginx 目前支持自带 3 种负载均衡策略，还有 2 种常用的第三方策略。
1、RR(默认)
每个要求按韶光顺序逐一分配到不同的后端做事器，如果后端做事器 down 掉，能自动剔除。
upstream test {
server localhost:8080;
server localhost:8081;
}
server {
listen 81;
server_name localhost;
client_max_body_size 1024M;
location / {
proxy_pass http://test;
proxy_set_header Host $host:$server_port;
}
}
负载均衡的核心代码为
upstream test {
server localhost:8080;
server localhost:8081;
}
这里配置了 2 台做事器，当然实际上是一台，只是端口不一样而已，而 8081 的做事器是不
存在的,也便是说访问不到，但是我们访问 http://localhost 的时候,也不会有问题，会默认跳
转到 http://localhost:8080 详细是由于 Nginx 会自动判断做事器的状态，如果做事器处于不
能访问(做事器挂了)，就不会跳转到这台做事器，以是也避免了一台做事器挂了影相应用的
情形，由于 Nginx 默认是 RR 策略，以是我们不须要其他更多的设置。
2、权重
指定轮询几率，weight 和访问比率成正比，用于后端做事器性能不均的情形。 例如
upstream test {
server localhost:8080 weight=9;
server localhost:8081 weight=1;
}
那么 10 次一样平常只会有 1 次会访问到 8081，而有 9 次会访问到 8080
3、ip_hash
上面的 2 种办法都有一个问题，那便是下一个要求来的时候要求可能分发到其余一个
做事器，当我们的程序不是无状态的时候(采取了 session 保存数据)，这时候就有一个很大的
很问题了，比如把登录信息保存到了 session 中，那么跳转到其余一台做事器的时候就须要
重新登录了，以是很多时候我们须要一个客户只访问一个做事器，那么就须要用 iphash 了，
iphash 的每个要求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端做事器，可
以办理 session 的问题。
upstream test {
ip_hash;
server localhost:8080;
server localhost:8081;
}
4、fair(第三方)
按后端做事器的相应韶光来分配要求，相应韶光短的优先分配。
upstream backend {
fair;
server localhost:8080;
server localhost:8081;
}
5、url_hash(第三方)
按访问 url 的 hash 结果来分配要求，使每个 url 定向到同一个后端做事器，后端做事器为缓
存时比较有效。 在 upstream 中加入 hash 语句，server 语句中不能写入 weight 等其他的参
数，hash_method 是利用的 hash 算法
upstream backend {
hash $request_uri;
hash_method crc32;
server localhost:8080;
server localhost:8081;
}
以上 5 种负载均衡各自适用不同情形下利用，以是可以根据实际情形选择利用哪种策
略模式,不过 fair 和 url_hash 须要安装第三方模块才能利用，由于本文紧张先容 Nginx 能做的
事情，以是 Nginx 安装第三方模块不会再本文先容
3. HTTP 做事器
Nginx 本身也是一个静态资源的做事器，当只有静态资源的时候，就可以利用 Nginx 来做服
务器，同时现在也很盛行动静分离，就可以通过 Nginx 来实现，首先看看 Nginx 做静态资源
做事器
server {
listen 80;
server_name localhost;
client_max_body_size 1024M;
location / {
root E:/wwwroot;
index index.html;
}
}
这样如果访问 http://localhost 就会默认访问到 E 盘 wwwroot 目录下面的 index.html，
如果一个网站只是静态页面的话，那么就可以通过这种办法来实现支配。
4. 动静分离
动静分离是让动态网站里的动态网页根据一定规则把不变的资源和常常变的资源区分开来，
动静资源做好了拆分往后，我们就可以根据静态资源的特点将其做缓存操作，这便是网站静
态化处理的核心思路。
upstream test{
server localhost:8080;
server localhost:8081;
}
server {
listen 80;
server_name localhost;
location / {
root e:/wwwroot;
index index.html;
}
# 所有静态要求都由 nginx 处理，存放目录为 html
location ~ .(gif|jpg|jpeg|png|bmp|swf|css|js)$ {
root /var/www;
}
# 所有动态要求都转发给 tomcat 处理
location ~ .(jsp|do)$ {
proxy_pass http://test;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/www;
}
}
这样我们就可以吧 HTML 以及图片和 css 以及 js 放到 wwwroot 目录下，而 tomcat 只卖力处
理 jsp 和要求，例如当我们后缀为 gif 的时候，Nginx 默认会从 wwwroot 获取到当前要求的
动态图文件返回，当然这里的静态文件跟 Nginx 是同一台做事器，我们也可以在其余一台服
务器，然后通过反向代理和负载均衡配置过去就好了，只要搞清楚了最基本的流程，很多配
置就很大略了，其余 localtion 后面实在是一个正则表达式，以是非常灵巧
5. 正向代理
正向代理，意思是一个位于客户端和原始做事器(origin server)之间的做事器，为了从原始服
务器取得内容，客户端向代理发送一个要求并指定目标(原始做事器)，然后代理向原始做事
器转交要求并将得到的内容返回给客户端。客户端才能利用正向代理。
resolver 114.114.114.114 8.8.8.8;
server {
resolver_timeout 5s;
listen 81;
access_log /var/www/access.log;
error_log /var/www/error.log;
location / {
proxy_pass http://$host$request_uri;
}
}
resolver 是配置正向代理的 DNS 做事器，listen 是正向代理的端口，配置好了就可以在 ie 上
面或者其他代理插件上面利用做事器 ip+端口号进行代理了。
Nginx 是支持热启动的，也便是说当我们修正配置文件后，不用关闭 Nginx，就可以实现让配
置生效，当然我并不知道多少人知道这个，反正我一开始并不知道，导致常常杀去世了 Nginx
线程再来启动。。。Nginx 重新读取配置的命令是 -
$ nginx -s reload
windows 下面便是
$ nginx.exe -s reload
Nginx进阶教程Nginx进阶教程
Nginx源码解析视频教程16w行nginx源码，该这样读
