nginx是如何匹配过来的请求,然后做处理的呢?这个匹配的过程可以分为两步:
1.选择server
2.选择location 
 
选择server
仅仅匹配server name
加入Nginx的配置文件有这么几项:
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;
    ...
}
 
在上面配置文件中,Nginx仅仅匹配server_name指令。根据Request请求头的"Host"参数,去匹配server_name的指令参数,从而决定路由到哪个虚拟服务器。如果HOST 请求头参数找不到对应的server,或者压根没有这个请求头,那么nginx将会选择默认的——往往是第一个,这里是 server_name example.org www.example.org;   但是你也可以直接指定:
server {
    listen      80 default_server;
    server_name example.net www.example.net;
    ...
}
在listen指令的后面,使用default_server参数就指定了默认的server。注意,这里指令参数default_server是放在指令listen后面,不是server_name后面,是指定一个具体的端口,不是指定一个虚拟机名称,后面会说明原因。
如果请求头Header没有HOST参数,在0.8.48之后的版本,此请求会被丢弃。在之前的版本中,你可以用下面的指令来完成丢弃的功能:
server {
    listen      80;
    server_name "";
    return      444;
}
指令server_name 的参数设为空数组将匹配不带Host请求头的请求。
 
同时匹配server name和IP
来看看同时带有IP和server name的server的配置情况:
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;
    ...
}
在这种情况下,Ngxin首先根据请求的IP和Port匹配listen指令,然后再根据请求的Host头匹配server_name 指令。比如本机的ip是192.168.1.1,那么所有过来的请求都不会到192.168.1.2上去。如果Host没有匹配上,再用默认的server来处理。
例如: 发往192.168.1.1:80端口的www.example.com请求,只会从前面两个server中去找对应的server_name,发现没有匹配上,那么采用默认的(第一个)server。
我看来看看在多个IP的配置文件下,如何指定默认的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;
    ...
}
所以,server是针对某个IP,某个端口的,并不是针对某个域名,因此default_server也是针对某个IP,某个端口的,是listen的属性而不是server_name 的属性。
 
选择 location 
location指令都是针对请求的uri部分进行匹配,不是整个url,也不包含任何请求参数,比如:
/index.php
/user/index/get
 
Nginx的locating指令可以分为两种,即"prefix location"和"regular expression location",即“前缀location”和“正则location”。
前缀location形如下面:
location / {
       ....
}
location /path/to {
        .....
 }
location /index.php {
       .....
 }
 

正则location location后面需要匹配正则表达式,比如:

  location ~* \.(gif|jpg|png)$ {
        expires 30d;
   }
 
以一个PHP网站的配置为例,看看Nginx如果选择location来处理请求的。
server {
    listen      80;
    server_name example.org www.example.org;
    root        /data/www;
 
    location / {
        index  index.html index.php;
    }
 
    location /comment {
        rewrite /comment/(.*) /$1 break;
    }
 
    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首先在前缀location中进行匹配,而且首先搜寻匹配的最为"精确"的那一项:比如请求/comment,即匹配location /comment 和location / 但是location /comment 更为“精确”因此被匹配上。location / 因为是匹配所有的请求所以被“最后考虑”。这一步匹配是无关前缀location的罗列顺序的。
接着,nginx继续匹配正则location,这一步跟正则location的顺序就有关系了。nginx是依次匹配,第一个匹配的到location时。nginx会终止匹配,然后用这个location来处理请求。如果正则location部分没有匹配到任何一项,则采用上一步前缀location匹配到的来处理请求。
在匹配到location,处理Request时,还需要加上root指令,即root   /data/www;
 
举例说明下:
"/logo.gif"——首先被前缀location的location /匹配上了,然后也被正则location的location ~* \.(gif|jpg|png)$ 匹配上了,因此会被后面的location处理。此外,在处理请求是还要加上root   /data/www ,最为请求就被定为到了 /data/www/logo.gif,最后次文件会被发送到浏览器
 
"/index.php"——同样首先被前缀location的location /匹配上,但后面正则location也匹配上了location ~ \.php$,因此由后者来处理:交给运行在localhost:9000的FASTCGI程序来处理,
fastcgi_param 指令用来设定FASTCGI的参数SCRIPT_FILENAME,$document_root和$fastcgi_script_name是nginx参数,分别为root指令参数(/data/www)和URI(/index.php)
 
"/about.html"——仅仅能被location /匹配,因此便由它处理,最后请求定位到/data/www/about.html
 
"/"——这种情况稍微复杂点。它仅能被前缀location"location /"匹配上,因此它将被这个location处理。然后location中的指令index将被执行,nginx会依次尝试index文件(俗称入口文件)是否存在,在此例中就是/data/www/index.html /data/www/index.php,如果前者不存在就继续往后找。此例中,/data/www/index.html不存在因此由/data/www/index.php处理。然后nginx会做个内部跳转到/index.php,然后,就处理好像一个从浏览器反过来的全新请求一样,重新搜寻location,就像前面分析的一样,最终交由FASTCGI程序来处理。