基本配置格式
Nginx全局配置参数
使用include文件
HTTP的server部分
虚拟服务器部分
location —— where，when，how。
mail的server部分。
完整的示例配置文件。
基本配置格式：
Nginx的配置文件由若干部分组成，每一个部分都是通过下列方法定义的。
<section> {
<directive> <parameters>
}
每一个指令行都由分号结束，这标记着一行的结束。大括号实际上表示一个新配置的上下文，但是在大多数情况下，将他们作为“节、部分（section）”来读。
Nginx全局配置参数
全局配置部分包含配置指令，例如：user和worker_processes，也包括“节，部分（section）”。例如：events，
使用include文件
在Nginx配置文件中，include文件可以在任何地方，以便增强配置文件的可读性。
在路径中出现通配符，表示可以配置多个问价。
include /opt/local/etc/nginx/vhost/*.conf
如果没有给定全路径，Nginx将会依据它的主配置文件路径进行搜索。Nginx测试配置文件很容易，通过下面的命令来完成。
Nginx -t -c <path-to-nginx.conf>
该命令将测试Nginx的配置文件，包括include文件，但是它只检查语法错误。
HTTP的server部分
在HTTP中，server部分或者HTTP配置context是可用的，除非在编译安装Nginx时没有包含HTTP模块（也就是使用了--without-http）。
1、客户端指令
2、文件I/O指令
这些指令用于控制Nginx如何投递静态文件以及如何管理文件描述符。
3、Hash指令
这组hash指令控制Nginx分配给某些变量多大的静态内存。在启动和重新配置时，Nginx会计算需要的最小值。在Nginx发出警告时，只需要调整一个*_hash_max_size指令的参数值就可以达到效果。*_hash_bucket_size变量被设置了默认值，以便满足多处理器缓存行降低检索所需要的检索查找，因此基本不需要改变，额外更详细的内容参考http://nginx.org/en/docs/hash.html。
4、socket指令
socket指令描述了Nginx如何设置创建TCP套接字的变量选项。
虚拟服务器部分
任何有关键字server开始的部分都被称作“虚拟服务器”部分。它描述的是一组根据不同的server_name指令逻辑分割的资源，这些虚拟服务器响应HTTP请求，因此他们都包含在http部分中。
一个虚拟服务器有listen和server_name指令组合定义，listen指令定义了一个IP地址/端口组合或者是UNIX域套接字路径。
listen address [:port);
listen port;
listen unix:path;
如图，listen指令唯一地标识了在Nginx下的套接字绑定，此外还有一些其他的可选参数。
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等）指令中使用。
对于一个特定的请求，确定哪些虚拟服务器提供该请求的服务时，Nginx应该遵循下面的逻辑。
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指令，以满足第一步。
这个逻辑体现在图2-1中。
参数default_server被用于处理其他没有被处理的请求。因此，总是明确的推荐设置default_server，以便这些没有被处理的请求通过这种定义的方式处理。
除了这个用法外，default_server也可以使用同样的listen指令配置若干个虚拟服务器。
这里设置的任何指令都将会在匹配的server区段有效。
Locations——where，when，how
location指令可以用在虚拟服务器server部分，并且意味着提供来自客户端的URI或者内部重定向访问。除少数情况外，location也可以被嵌套使用，他们被作为特定的配置尽可能的处理请求。
location定义如下。
location [modifier] uri {...}
或者是命名location。
location @name {...}
命名location仅对内部访问重定向，在进入一个location之前，他会保留被请求的URI部分。命名location只能在server级别定义。
当一个请求进入时，URI将会被检测匹配一个最佳的location。
- 没有正则表达式的location被作为最佳的匹配，独立于含有正则表达式的location顺序。
- 在配置文件中按照查找顺序进行正则表达式匹配。在查找到第一个正则表达式匹配之后结束查找。由这个最佳的location提供请求处理。
这里比较匹配描述的是解码URI，例如，在URI中的“%20”，将会匹配location中的“ ”（空格）。
命名location仅可以在内部重定向的请求中使用。表2-8中的指令仅在location中使用。
另外，http部分的其他指令也可以在location中指定，附录A指令参考有完整列表。
指令try_files在这里也值得一提，它也可以用在server部分，但是最常见的还是在location部分中。try_file指令将会按照给定它的参数列出顺序进行尝试，第一个被匹配的将会被使用。它经常被用于从一个变量去匹配一个可能的文件，然后将处理传递到一个命名location，如下面的示例所示。
location I { try _ files $uri $uri @mongrel; } location @mongrel { proxy _ pass http://appserver; }
在这里有一个隐含的目录索引，如果给定的URI作为一个文件没有被找到，那么处理将会通过代理被传递到APPserver。我们将会在本书的其他部分讨论如何最好地使用location、try_files和proxy_pass来解决特定的问题。
除以下前缀外，location可以被嵌套。
- 具有“=”前缀。
- 命名location。
最佳实践表明正则表达式location被嵌套在基于字符串的location内，如下面的示例所示。
#first, we enter through the root
location / {
# then we find a most-specific substring
# note that this is not a regular expression
location A ~/ css {
# here is the regular expression that then gets matched
location ~* /css/ . *.css$ {
}
}
}
小结
server来定义每一个请求如何被处理，以便请求被路由到特定的IP地址和端口上；
使用locations来匹配URI请求，这些location可以被嵌套使用，或者按其它顺序使用。