nginx 第二课

Posted 2020-11-17 linuxws

基本配置格式

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可以被嵌套使用，或者按其它顺序使用。