Nginx配置指南
Nginx的配置文件的格式非常合乎逻辑。学习这种格式以及如何使用每个部分是基础，这将有助于你手工创建一个配置文件。通过这一章的下列讨论话题将帮助你达到这个目的。
-
基本配置格式。
-
Nginx全局配置参数。
-
使用include文件。
-
Http的server部分。
-
虚拟服务器部分。
-
location——在哪儿，什么时候，怎么样。
-
mail的server部分。
-
完整的示例配置文件。
2.1 基本配置格式
基本的Nginx配置文件由若干个部分组成。每一个部分都是通过下列方法定义的。
<section> {
<directive> <parameters>;
}
需要注意的是每一个指令行都由分号结束（;），这标记着一行的结束。大括号（{}）实际上表示一个新上下文（context），但是大多数情况下我们将它们作为“节、部分（section）”来读。
2.2 Nginx的全局配置参数
全局配置部分被用于配置对整个server都有效的参数和前一个章节中的例外格式。全局部分可能包含配置指令，例如，user和worker_processes，也包括“节、部分（section）”。例如，events，这里没有大括号（{}）包围全局部分。
在全局部分中，最重要的配置指令都在表2-1中，这些指令将会是你处理的最重要部分。
表2-1 全局配置指令
| 指令 | 说明 |
|---|---|
user |
使用这个参数来配置worker进程的用户和组。如果忽略group，那么group的名字等于该参数指定的用户的用户组 |
worker _ processes |
指定worker进程启动的数量。这些进程用于处理客户的连接。选择一个正确的数量取决于服务器环境、磁盘子系统和网络基础设施。一个好的经验法则是设置该参数的值与CPU绑定的负载处理器核心的数量相同，并用1.5～2之间的数乘以这个数作为I/O密集型负载 |
error _ log |
error _ log是所有错误写入的文件。如果在其他区段中没有设置其他的 error _ log ，那么这个日志文件将会记录所有的错误。该指令的第二个参数指定了被记录错误的级别（debug，info，notice，warn，error，crit，alert，emerg）。注意，debug级别的错误只有在编译时配置了--with-debug选项才可以使用 |
pid |
设置记录主进程ID的文件，这个配置将会覆盖编译时的默认配置 |
use |
该指令用于指示使用什么样的连接方法，这个配置将会覆盖编译时的默认配置，如果配置该指令，那么需要一个events区段。通常不需要覆盖，除非是当编译时的默认值随着时间的推移产生错误时才需要被覆盖设置 |
worker _ connections |
该指令配置一个工作进程能够接受并发连接的最大数。这个连接包括，客户连接和向上游服务器的连接，但并不限于此。这对于反向代理服务器尤为重要，为了达到这个并发性连接数量，需要在操作系统层面进行一些额外调整 |
下面是一个使用这些指令的简短的例子。
we want nginx to run as user www
user www;
the load is CPU-bound and we have 12 cores
worker_processes 12;
explicitly specifying the path to the mandatory error log
error_log /var/log/nginx/error.log;
also explicitly specifying the path to the pid file
pid /var/run/nginx.pid;
sets up a new configuration context for the 'events' module
events {
# we're on a Solaris-based system and have determined that nginx
# will stop responding to new requests over time with the default
# connection-processing mechanism, so we switch to the second-best
use /dev/poll;
# the product of this number and the number of worker_processes
# indicate s how many simultaneous connections per IP:port pair are
# accepted
worker_connections 2048;
}
这一部分应该放置在nginx.conf文件的顶部。
2.3 使用include文件
在Nginx的配置文件中，include文件可以在任何地方，以便增强配置文件的可读性，并且能够使得部分配置文件重新使用。使用include文件，要确保被包含的文件自身有正确的Nginx语法，即配置指令和块（blocks），然后指定这些文件的路径。
include /opt/local/etc/nginx/mime.types;
在路径中出现通配符，表示可以配置多个文件。
include /opt/local/etc/nginx/vhost/*.conf;
如果没有给定全路径，那么Nginx将会依据它的主配置文件路径进行搜索。
Nginx测试配置文件很容易，通过下面的命令来完成。
nginx -t -c <path-to-nginx.conf>
该命令将测试Nginx的配置文件，包括include文件，但是它只检查语法错误。
2.4 Http的server部分
在Http中，server部分或者是Http配置context是可用的，除非在编译安装Nginx时没有包含Http模块（也就是使用了--without-http）。这部分控制了Http模块的方方面面，是使用最多的一个部分。
本部分的指令用于处理Http连接，因此该模块提供了相当数量的指令。为了更容易理解这些指令我们将它们划分为不同的类型来讲述。
2.4.1 客户端指令
如表2-2所示，这一组指令用于处理客户端连接本身的各个方面，以及不同类型的客户端。
表2-2 Http客户端指令
| 指令 | 说明 |
|---|---|
chunked _ transfer _ encoding |
在发送给客户端的响应中允许禁用Http/1.1标准的块传输编码 |
client _ body _ buffer _ size |
为了阻止临时文件写到磁盘，可以通过该指令为客户端请求体设置缓存大小，默认的缓存大小为两个内存页面 |
client _ body _ in _ file _ only |
用于调试或者是进一步处理客户端请求体。该指令能够将客户端请求体强制写入到磁盘文件 |
client _ body _ in _ single _ buffer |
为了减少拷贝的操作，使用该指令强制Nginx将整个客户端请求体保存在单个缓存中 |
client _ body _ temp _ path |
定义一个命令路径用于保存客户端请求体 |
client _ body _ timeout |
指定客户体成功读取的两个操作之间的时间间隔 |
client _ header _ buffer _ size |
为客户端请求头指定一个缓存大小，当请求头大于1kB时会用到这个设置 |
client _ header _ timeout |
该超时是读取整个客户端头的时间长度 |
client _ max _ body _ size |
定义允许最大的客户端请求头，如果大于这个设置，那么客户端将会是413（Request Entity Too Large）错误 |
keepalive _ disable |
对某些类型的客户端禁用keep-alive请求功能 |
keepalive _ requests |
定义在一个keep-alive关闭之前可以接受多少个请求 |
keepalive _ timeout |
指定keep-alive连接持续多久。第二个参数也可以设置，用于在响应头中设置“Keep-Alive”头 |
large _ client _ header _ buffers |
定义最大数量和最大客户端请求头的大小 |
msie _ padding |
为了填充响应的大小至512字节，对于MSIE客户端，大于400的状态代码会被添加注释以便满足512字节，通过启用该命令可以阻止这种行为 |
msie _ refresh |
对于MSIE客户端，可启用发送一个refresh头，而不是重定向 |
2.4.2 文件I/O指令
这些指令用于控制Nginx如何投递静态文件，以及如何管理文件描述符参见表2-3。
表2-3 Http文件I/O指令
| 指令 | 说明 |
|---|---|
aio |
启用异步文件I/O。该指令对于现代版本的FreeBSD和发布的Linux都有效。在FreeBSD系统下，aio可能被用于sendfile预加载数据。在Linux下需要directio指令，自动禁用sendfile
|
directio |
用于启用操作系统特定的标志或者功能提供大于给定参数的文件。在Linux系统下使用 aio时需要使用该指令 |
directio _ alignment |
设置 directio 的算法。默认值为512，通常足够了，但是在Linux的XFS下推荐增加为4K
|
open _ file _ cache |
配置一个缓存用于存放打开的文件描述符、目录查询和文件查询错误 |
open _ file _ cache _ errors |
按照 open _ file _ cache，启用文件查询错误缓存 |
open _ file _ cache _ min _ uses |
open _ file _ cache缓存的文件描述符保留在缓存中，使用该指令配置最少使用文件描述符的次数 |
open _ file _ cache _ valid |
指定对open _ file _ cache缓存有效性检查的时间间隔 |
postpone _ output |
指定Nginx发送给客户端最小的数值，如果可能的话，没有数据会发送，直到达到此值 |
read _ ahead |
如果可能的话，内核将预读文件到设定的参数大小。目前支持FreeBSD和Linux（Linux会忽略大小） |
s endfile |
使用sendfile（2）直接复制数据从一个到另一个文件描述符 |
sendfile _ max _ chunk |
设置在一个 sendfile（2） 拷贝中最大数据的大小，这是为了阻止worker“贪婪” |
2.4.3 Hash指令
如表2-4所示，这组hash指令控制Nginx分配给某些变量多大的静态内存。在启动和重新配置时，Nginx会计算需要的最小值。在Nginx发出警告时，你几乎只需要调整一个_hash_max_size指令的参数值就可以达到效果。_hash_bucket_size变量被设置了默认值，以便满足多处理器缓存行降低检索所需要的检索查找，因此基本不需要改变，额外更详细的内容参考http://nginx.org/en/docs/hash. html。
表2-4 Http hash指令
| 指令 | 说明 |
|---|---|
server _ names _ hash _ bucket _ size |
指定用于保存server_name哈希表大小的“桶” |
server _ names _ hash _ max _ size |
指定的server_name哈希表的最大大小 |
types _ hash _ bucket _ size |
指定用于存放哈希表的“桶”的大小 |
types _ hash _ max _ size |
指定哈希类型表的最大大小 |
variables _ hash _ bucket _ size |
它指定用于存放保留变量“桶”的大小 |
variables _ hash _ max _ size |
指定存放保留变量最大哈希值的大小 |
2.4.4 Socket指令
如表2-5所示，这些指令描述了Nginx如何设置创建TCP套接字的变量选项。
表2-5 Http套接字指令
| 指令 | 说明 |
|---|---|
lingering _ close |
指定如何保持客户端的连接，以便用于更多数据的传输 |
lingering _ time |
在使用 lingering _ close指令的连接中，使用该指令指定客户端连接为了处理更多的数据需要保持打开连接的时间 |
lingering _ timeout |
结合lingering_close，该指令显示Nginx在关闭客户端连接之前，为获得更多数据会等待多久 |
reset _ timedout _ connection |
使用这个指令之后，超时的连接将会被立即关闭，释放相关的内 存。默认的状态是处于FIN _ WAIT1，这种状态将会一直保持连 接 |
send _ lowat |
如果非零，Nginx将会在客户端套接字尝试减少发送操作 |
send _ timeout |
在两次成功的客户端接收响应的写操作之间设置一个超时时间 |
tcp _ nodelay |
启用或者禁用TCP _ NODELAY选项，用于keep-alive连接 |
tcp _ nopush |
仅依赖于 sendfile的使用。它能够使得Nginx在一个数据包中尝试发送响应头，以及在数据包中发送一个完整的文件 |
2.4.5 示例配置文件
下面是一个Http配置部分的例子。
http {
include /opt/local/etc/nginx/mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
server_names_hash_max_size 1024;
}
在nginx.conf文件中上面的这部分内容跟随在全局配置指令之后。
2.5 虚拟server部分
任何由关键字server开始的部分都被称作“虚拟服务器”部分。它描述的是一组根据server_name指令逻辑分割的资源，这些虚拟服务器响应Http请求，因此它们都包含在http部分中。
一个虚拟服务器由listen和server_name指令组合定义，listen指令定义了一个IP地址/端口组合或者是UNIX域套接字路径。
listen address[:port];
listen port;
listen unix:path;
如表2-6所示，listen指令唯一地标识了在Nginx下的套接字绑定，此外还有一些其他的可选参数。
表2-6 listen指令的参数
| 参数 | 说明 | 注解 |
|---|---|---|
default _ server |
定义这样一个组合： address:port默认的请求被绑定在此 |
|
Setfib |
为套接字监听设置相应的FIB | 仅支持FreeBSD，不支持UNIX域套接字 |
backlog |
在listen()的调用中设置backlog参数调用 |
在FreeBSD系统中默认值为 −1，而在其他的系统中为511 |
rcvbuf |
在套接字监听中设置 SO _ RCVBUF 参数 |
|
sndbuf |
在套接字监听中设置 SO _ SNDBUF参数 |
|
accept _ filter |
设置接受的过滤器：dataready或者httpready dataready
|
仅支持FreeBSD |
deferred |
设置 accept()调用的TCP _ DEFER _ ACCEPT
|
仅支持Linux |
bind |
为 address:port套接字对打开一个单独的 bind()调用 |
如果任何其他特定套接字参数被使用，那么一个单独的 bind()将会被隐式地调用 |
| ipv6only | 设置 IPV6 _ V6ONLY参数的值 |
只能在一个全新的开始设置。不支持UNIX域套接字 |
ssl |
表明该端口仅接受HttpS的连接 |
允许更紧凑的配置 |
so _ keepalive |
为TCP监听套接字配置keepalive
|
server_name指令是相当简单的，但可以用来解决一些配置问题。它的默认值为""，这意味着server部分没有server_name指令，对于没有设置Host头字段的请求将会匹配该server处理。这种情况可用于，例如，丢弃这种缺乏Host头的请求。
server {
listen 80;
return 444;
}
在这个例子中使用的Http非标准代码444将会使得Nginx立即关闭一个连接。
除了普通的字符串之外，Nginx也接受通配符作为server_name的参数。
-
通配符可以替代部分子域名：
*.example.com。 -
通配符可以替代顶级域部分：
www.example.*。 -
一种特殊形式将匹配子域或域本身:
.example.com（匹配*.example.com也包括example.com）。
通过在域名前面加上波浪号（〜），正则表达式也可以被作为参数应用于server_name。
server_name～^www\.example\.com$;
server_name～^www(\d+).example\.(com)$;
后一种形式是利用捕获，可以在以后引用中进一步配置（用$1，$2等）指令中使用。
对于一个特定的请求，确定哪些虚拟服务器提供该请求的服务时，应该遵循下面的逻辑。
1．匹配IP地址和listen指令指定的端口。
2．将Host头字段作为一个字符串匹配server_name指令。
3．将Host头字段与server_name指令值字符串的开始部分做匹配。
4．将Host头字段与server_name指令值字符串的尾部分做匹配。
5．将Host头字段与server_name指令值进行正则表达式匹配。
6．如果所有Host头匹配失败，那么将会转向listen指令标记的default_server。
7．如果所有的Host头匹配失败，并且没有default_server，那么将会转向第一个server的listen指令，以满足第1步。
这个逻辑体现在下面的图2-1中。
图2-1 Host头匹配流程图
default_server被用于处理其他方式没有处理的请求。因此推荐总是明确地设置default_server，以便这些没有被处理的请求通过这种定义的方式处理。
除了这个用法外，default_server也可以使用同样的listen指令配置若干个虚拟服务器。这里设置的任何指令都将会在匹配的server区段有效。
2.6 Locations——where，when，how
location指令可以用在虚拟服务器server部分，并且意味着提供来自客户端的URI或者内部重定向访问。除少数情况外，location也可以被嵌套使用，它们被作为特定的配置尽可能地处理请求。
location定义如下。
location [modifier] uri {...}
或者是命名location。
location @name {…}
命名location仅对内部访问重定向，在进入一个location之前它会保留被请求的URI部分。命名location只能够在server级别定义。
表2-7中的修饰符会影响location的处理。
表2-7 location修饰符
| 修饰符 | 处理方式 |
|---|---|
| = | 使用精确匹配并且终止搜索 |
| ～ | 区分大小写的正则表达式匹配 |
| ～* | 不区分大小写的正则表达式匹配 |
| ^～ | 如果该location是最佳的匹配，那么对于匹配这个location的字符串不再进行正则表达式检测。注意这不是一个正则表达式匹配——它的目的是优先于正则表达式的匹配 |
当一个请求进入时，URI将会被检测匹配一个最佳的location。
没有正则表达式的location被作为最佳的匹配，独立于含有正则表达式的location顺序。
在配置文件中按照查找顺序进行正则表达式匹配，在查找到第一个正则表达式匹配之后结束查找，那么就由这个最佳的location提供请求处理。
这里比较匹配描述的是解码URI，例如，在URI中的 "%20"，将会匹配location中的 " " (空格）。
命名location仅可以在内部重定向的请求中使用。
表2-8中的指令仅在location中使用。
表2-8 仅用于location的指令
| 指令 | 说明 |
|---|---|
a lias |
定 义location的其他名字，在文件系统中能够找到。如果location指定了一个正则表达式， alias 将会引用正则表达式中定义的捕获。alias 替代location中匹配的部分，没有匹配的部分将会在文件系统中搜索。当配置改变一点，配置中使用 alias 则会有脆弱的表现，因此推荐使用root，除非是为了找到文件而需要修改 |
internal |
指 定一个仅用于内部请求的location（其他指定定义的重定向、rewrite请求、error请求等） |
limit _ except |
限定一个location可以执行的Http操作（GET也包括HEAD） |
另外，http部分的其他指令也可以在location中指定，参考附录A指令参考有完整列表。
指令try_files在这里也值得一提，它也可以用在server部分，但是最常见的还是在location部分中。try_files指令将会按照给定它的参数列出的顺序进行尝试，一个被匹配的将会被使用。
它经常被用于从一个变量去匹配一个可能的文件，然后将处理传递到一个命名location，看下面的例子。
location / {
try_files $uri $uri/ @mongrel;
}
location @mongrel {
proxy_pass http://appserver;
}
在这里有一个隐含的目录索引，如果给定的URI作为一个文件没有被找到，那么处理将会通过代理被传递到appserver。我们将会在本书的其他部分讨论如何最好地使用location、try_files和proxy_pass来解决特定的问题。
除以下前缀外，locations可以被嵌套。
-
具有 "=" 前缀。
-
命名location。
最佳实践表明正则表达式location被嵌套在基于字符串的location，看下面的例子。
ffirst, we enter through the root
location / {
# then we ffind a most-specific substring
# note that this is not a regular expression
location ^～ /css {
# here is the regular expression that then gets matched
location～* /css/.*\.css$ {
}
}
}
2.7 mail的server部分
mail服务部分，或者是mail的配置内容部分，仅在构建Nginx时使用了mail模块（--with-mail）才有效。这个部分控制了mail模块的所有方面。
作为mail模块允许配置影响代理邮件连接的所有方面，也可以为每个server指定。这个server也可以接受listen和server_name指令，这些指令我们在http server部分已经看过了。
Nginx能够代理IMAP、POP3和SMTP协议，表2-9中列出了该模块有效的指令。
表2-9 Mail模块指令
| 指令 | 说明 |
|---|---|
auth _ http |
指定提供的认证方式，用于POP3/IMAP用户认证使用。这个功能将会在第3章详细讨论 |
imap _ capabilities |
指示后端服务器支持IMAP4功能 |
pop3 _ capabilities |
指示后端服务器支持POP3功能 |
protocol |
指示虚拟server支持的协议 |
proxy |
该指令将会简单地启用或者禁用mail代理 |
proxy _ buffer |
该指令设置用于代理连接缓冲，在高于默认值时需要通过该指令设置 |
proxy _ pass _ error _ message |
在后端认证进程向客户端发出一个有用的错误消息的情况下，这个设置很有用 |
proxy _ timeout |
如果超时需要超过默认的24个小时，那么该指令需要配置 |
xclient |
SMTP协议允许基于IP/HELO/LOGIN参数检查，它们通过XCLIENT命令传递。该指令使Nginx传递这种消息 |
如果Nginx在编译时支持了SSL（--with-mail_ssl_module），那么表2-10所示指令在前面的mail模块中可以使用。
表2-10 Mail模块的SSL指令
| 指令 | 说明 |
|---|---|
ssl |
表明该部分支持SSL处理 |
ssl _ certificate |
为该虚拟server指定PEM编码的SSL证书路径 |
ssl _ certificate _ key |
为该虚拟server指定PEM编码的SSL密码密钥 |
ssl _ ciphers |
指定在该虚拟server中支持密码（OpenSSL格式） |
ssl _ prefer _ server _ ciphers |
表明SSLv3和TLSv1服务器密码是客户端的首选 |
ssl _ protocols |
指示使用的SSL协议 |
ssl _ session _ cache |
指定SSL缓存，以及其是否应该在所有的worker进程中共享 |
ssl _ session _ timeout |
客户端能够使用多久相同的SSL参数，提供的参数被存储在该缓存中 |
2.8 完整的样本配置文件
以下示例是一个样本配置文件，它包括了在本章讨论的各个不同方面。请注意，不要复制粘贴该样本配置文件，因为它很可能不是你需要的配置，而只是显示了一个完整配置文件的架构而已。
user www;
worker_processes 12;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
use /dev/poll;
worker_connections 2048;
}
http {
include /opt/local/etc/nginx/mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
server_names_hash_max_size 1024;
server {
listen 80;
return 444;
}
server {
listen 80;
server_name www.example.com;
location / {
try_files $uri $uri/ @mongrel;
}
location @mongrel {
proxy_pass http://127.0.0.1:8080;
}
}
}
2.9 总结
在本章，我们看到了如何构建Nginx的配置文件。模块化的本质值得思考，从某种意义上讲，Nginx本身也是模块化的。全局的配置区段负责各个方面，对于Nginx来说是一个整体。Nginx负责处理的每一种协议单独成为一个部分。我们还可以通过在这些协议配置内（http或者mail）指定server来定义每一个请求如何被处理，以便请求被路由到特定的IP地址和端口上。在http区段中，使用locations来匹配URI请求，这些locations可以嵌套使用，或者按其他顺序使用，以确保请求被路由到正确的文件系统区域或者应用程序服务器。
本章没有涵盖编译到二进制Nginx命令中各种模块提供的配置选项，这些额外的指令将会遍及本书的始终，因此特定的模块被用于解决一个问题。对于Nginx配置中的变量也没有解释，这些变量也将会在本书后边的内容中讨论。本章的焦点是基于Nginx的基本配置。
本文摘自《精通Nginx》
《精通Nginx》
目录
目录
