编译自:
request_processing
目录:
- name-based 虚拟主机
- 对于未定义 server name 的访问请求,如何防止其被处理
- 混合使用 name-based 虚拟主机和 IP-based 虚拟主机
- 一个简单的 PHP 站点配置示例
name-based 虚拟主机
当一个访问请求到达 nginx,nginx 会考虑选择某一个 server 处理访问请求。
我们以一个包含三个 server 区块的配置来讲解:
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80;
server_name example.net www.example.net;
...
}
server {
listen 80;
server_name example.com www.example.com;
...
}
这三个虚拟主机均监听于 *:80 端口。根据上面的配置,nginx 仅通过检查请求首部中的 “HOST” 字段来决定让哪个虚拟主机处理访问请求。如果该字段的值没有匹配任何虚拟主机,或者请求首部中没有 “HOST” 字段,nginx 会将该请求路由到 *:80 端口的默认 server。
在上面的配置中,默认 server 是第一个 server —— 这是 nginx 的标准默认行为。我们也可以显式指定一个默认 server,使用 listen 指令的 default_server 参数来指定,
例如:
server {
listen 80 default_server;
server_name example.net www.example.net;
...
}
*Note*:
default_server 参数从 0.8.21 之后开始使用,之前是 default 参数。
要注意,默认 server 是监听端口的一个属性,不是 server name 的属性。稍后将进一步描述这个问题。
对于未定义 server name 的访问请求,如何防止其被处理
如果希望禁止未定义 “Host” 请求首部字段的访问请求,可设置一个 server 用于丢弃这样的请求:
server {
listen 80;
server_name "";
return 444;
}
我们在这里将 server name 设置为一个空字符串,它能匹配未携带 “Host” 请求首部字段的访问请求,并且返回一个特殊的状态码 444 以关闭连接,444 不是标准的 nginx 状态码。
Note:
从 0.8.48 版开始,这个设置变成了 nginx 的默认设置,所以 server_name "" 可被删去。
在更早的版本中,物理主机的主机名被设置为 default server name。
混合使用 name-based 虚拟主机和 IP-based 虚拟主机
现在我们看一个更复杂的配置案例,这里有多个虚拟主机监听于不同的地址:
server {
listen 192.168.1.1:80;
server_name example.org www.example.org;
...
}
server {
listen 192.168.1.1:80;
server_name example.net www.example.net;
...
}
server {
listen 192.168.1.2:80;
server_name example.com www.example.com;
...
}
根据这份配置,nginx 首先检查访问请求的 IP 地址和端口号,将它与 server 区块的 listen 指令的参数进行对比,过滤掉不匹配的 server。然后 nginx 检查访问请求的 “Host” 请求首部字段,将它与剩下的 server 区块中的 server_name 进行对比,看能否匹配。如果没有匹配的 server,该请求将交给 default server 处理。
例如,nginx 在 192.168.1.1:80 端口接收到对于 www.example.com 的访问请求,因为在 192.168.1.1:80 端口没有匹配的 server name,这个请求最后将被交给 192.168.1.1:80 端口的 default server 处理,也就是第一个server。
正如前面提到过,default server 是监听端口的属性,所以对于不同的监听端口,可以分别为其定义不同的 default server。
server {
listen 192.168.1.1:80;
server_name example.org www.example.org;
...
}
server {
listen 192.168.1.1:80 default_server;
server_name example.net www.example.net;
...
}
server {
listen 192.168.1.2:80 default_server;
server_name example.com www.example.com;
...
}
192.168.1.1:80 端口的默认 server 是第二个 server;
192.168.1.2:80 端口的默认 server 是第三个 server。
一个简单的 PHP 站点配置示例
最后我们来看一个 PHP 站点的例子,看看 nginx 是如何选择 location 处理请求的:
server {
listen 80;
server_name example.org www.example.org;
root /data/www;
location / {
index index.html index.php;
}
location ~* \.(gif|jpg|png)$ {
expires 30d;
}
location ~ \.php$ {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
nginx 首先根据访问请求的 URI 查找匹配的定义了 prefix 前缀的 location,并记住其中匹配的最长的前缀。在上面的例子中,定义了前缀的 location 只有一个,而且前缀为 “/”,它是最短的前缀,能匹配所有请求。因为 “/” 前缀最短,所以这个 location 总是被作为最后的备选。
然后 nginx 开始检查指定了正则表达式的 location,依照配置文件中的顺序依次检查是否与访问请求的 URI 匹配,当找到第一个匹配的正则表达式,nginx 不再继续检查后面的 location,nginx 将使用找到的第一个匹配正则表达式所对应的 location。如果没有匹配的 正则表达式,nginx 将使用之前记住的拥有最长匹配前缀的 location。
要注意的是,所有类型的 location 仅测试请求的 URI 部分,不带参数。因为在查询字符串中的参数,可能以
几种方式提供:
/index.php?user=john&page=1
/index.php?page=1&user=john
除此之外,在查询字符串中,任何人可以请求任何事情:
/index.php?page=1&something+else&user=john
现在我们仔细研究一下根据上面的配置,nginx 将会如何处理访问请求:
访问请求为 “/logo.gif”
对于 “/logo.gif” 的请求首先被 prefix location “/” 所匹配,然后被正则表达式 “.(gif|jpg|png)$” 所匹配,因此,这个请求将被交给后者处理。使用 “root /data/www” 指令,该请求被映射为 /data/www/logo.gif,这个文件被发送给客户端。访问请求为 “/index.php”
对于 “/index.php” 的请求同样首先被 prefix location “/” 所匹配,然后被正则表达式 “.(php)$” 所匹配。因此这个请求将被交给后者处理。该请求被转发给一个 FastCGI 服务器,该服务器监听于: localhost:9000。fastcgi_param 指令用于设置 FastCGI 参数 SCRIPT_FILENAME,这里设置为:“/data/www/index.php”,之后 FastCGI 服务器会执行该文件。$document_root 变量的值等同于 root 指令的参数值,$fastcgi_script_name 变量的值等于请求 URI,即 “/index.php”。访问请求为 “/about.html”
对于 “/about.html” 的请求只能被 prefix location “/” 所匹配。因此该 location 会处理这个 请求。使用 “root /data/www” 指令,这个请求被映射到 /data/www/about.html 文件,该文件将被发送给客户端。访问请求为 “/”
对于 “/” 的访问请求的处理更为复杂。它只能被 prefix location “/” 所匹配,因此该 location 会处理这个请求。然后 index 指令根据自己的参数以及 “root /data/www” 指令,开始测试是否存在 index 文件。如果 /data/www/index.html 文件不存在,而 /data/www/index.php 文件存在,index 指令会将请求通过内部重定向,重定向至 “/index.php”,然后 nginx 如同接收到客户端发来对 “/index.php” 的请求开始进行处理。这个处理过程刚才已经讲解过,被重定向的请求最后会被转发给 FastCGI 服务器进行处理。
版权信息:
本文编译自 nginx.org 的部分,遵循其原来的 licence 声明: 2-clause BSD-like license