name-based virtual host
Nginx will first decide which server should handle this request. Let's start with a simple configuration, where three virtual hosts are listening to port *:80:
server {
listen ;
server_name example.org www.example.org;
...
}
server {
listen ;
server_name example.net www.example.net;
...
}
server {
listen ;
server_name example.com www.example.com;
...
}
In this configuration, Nginx only determines which server the current request will be routed to, based on the "Host" attribute in the request header. If the value of the property does not match any host name, or if the current request does not contain this attribute at all, Nginx will route the current request to the default server at that port. In the above configuration, the default server is the first-this is the standard default behavior of Nginx. Of course, you can also use the Default_server parameter in the Listen directive to explicitly specify the default server:
server {
listen default_server;
server_name example.net www.example.net;
...
}
The Default_server parameter has been in effect since the 0.8.21 version. The default parameter should be used in earlier versions.
how to prevent processing of requests that do not have a host name defined
If you do not allow a request with a "Host" attribute in the header, you can define the server to discard the requests:
server {
listen ;
Server_Name "";
return 444;
}
Here, the server name is set to an empty string, which will match the request without the "Host" header, after which a special non-standard HTTP code of 444 is returned at the same time that the connection is closed.
Since version 0.8.48, this is the default setting for the server name, so you can ignore the server_name "" notation. In earlier versions, the host name of the machine was used as the default server name. name-based and IP-based hybrid virtual host
Let's continue to look at some of the more complex configurations where the virtual host listens to different addresses:
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;
...
}
In this configuration, Nginx first detects whether the IP address and port number of the current request match the listen instruction of the server block. Nginx then continues to detect whether the "Host" property of the current request matches the server_name entry of the server block. If the server name is not found, the current request is processed by the default server. For example, a port 192.168.1.1:80 received a request for www.example.com will be processed by the default 192.168.1.1:80 port server, for example, the first server, because no www.example.com is found for that port definition.
As explained above, the default server parameter is a property of the listening port, and you can define a different default server for different ports:
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;
...
}
a simple PHP site configuration
Let's take a look at how Nginx chooses to locate the request for a typical and simple PHP site:
server {
listen ;
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 first finds the location of the most matched prefixes, regardless of the order in which they appear. In the above configuration, the only match prefix location is "/" because it can match any request and it will be used as the last selection. The Nginx then checks the regular expressions listed in the configuration file. The first matching expression stops finding and using this location. If no regular expression matches this request, Nginx uses the most accurate prefix expression location found earlier.
Note All location matching tests use only the requested URI portion, not the Parameters section. This is because the parameters in the request string can be given in a number of ways, for example:
/index.php?user=john&page=1
/index.php?page=1&user=john
In addition, some people will add anything using the following request string:
/index.php?page=1&something+else&user=john
Now let's look at how the requests in the above configuration are handled:
A "/logo.gif" request is first matched by a "/" and then the regular expression "\". (gif|jpg|png) $ "match, so that it will be processed by the latter location. With the instruction "root/data/www", this request is mapped to the file/data/www/logo.gif, and then the file is sent to the client. A "/index.php" request is also preceded by a "/" match, followed by the regular expression "\". (PHP) $ "match. Therefore, it will be processed by the latter location, and this request will be passed to a FastCGI server that hears the localhost:9000. The fastcgi_param instruction sets the fastcgi parameter script_filename to "/data/www/index.php" and fastcgi executes the file. $document the _root variable equals the value of the root instruction, $fastcgi _script_name variable is equivalent to the request URI, for example, "/index.php". A "/about.html" request will be matched only by location "/", so it will be processed by this location. With the instruction "root/data/www", this request is mapped to the/data/www/about.html file, which is sent to the client. Processing a "/" request is somewhat complex. It will only be matched by the prefix location "/", so it will be handled by this location. The index command then detects the existence of the index file according to the "root/data/www" directive. If the/data/www/index.html file does not exist and the/data/www/index.php file exists, then this instruction will be internally redirected to "/index.php", and Nginx will again look for the location to match it , just as the request was requested by a client. As we saw above, this redirect request will eventually be processed by the FastCGI server. Original link: http://nginx.org/en/docs/http/request_processing.html.
