Name-based virtual servers
nginx first decides which server should process the request.
Let’s start with a simple configuration
where all three virtual servers listen on port *:80:
server {
listen 80;
server_name nginx.org www.nginx.org;
...
}
server {
listen 80;
server_name nginx.net www.nginx.net;
...
}
server {
listen 80;
server_name nginx.com www.nginx.com;
...
}
In this configuration nginx tests only the request’s header line
“Host” to determine which server the request should be routed to.
If the “Host” header line does not match any server name,
or the request does not contain this line at all,
then nginx will route the request to the default server.
In the configuration above, the default server is the first
one — which is nginx’s standard default behaviour.
If you do not want the first server listed to be the default server,
you may set it explicitly with the default_server parameter
in the listen directive:
server {
listen 80 default_server;
server_name nginx.net www.nginx.net;
...
}
The default_server parameter has been available since
version 0.8.21.
In earlier versions the default parameter should be used
instead.
Note that the default server is a property of the listen port
and not of the server name. More about this later.
How to prevent processing requests with undefined server names
If you do not want to process requests without the “Host”
header line, you may define a server that just drops the requests:
server {
listen 80;
server_name "";
return 444;
}
Here, the server name is set to an empty string which will match
requests without the “Host” header line,
and a special nginx’s non-standard code 444
is returned that closes the connection.
Since version 0.8.48, this is the default setting for the
server name, so the server_name "" can be omitted.
In earlier versions, the machine's hostname was used as
a default server name.
Mixed name-based and IP-based virtual servers
Let’s look at a more complex configuration
where some virtual servers listen on different addresses:
server {
listen 192.168.1.1:80;
server_name nginx.org www.nginx.org;
...
}
server {
listen 192.168.1.1:80;
server_name nginx.net www.nginx.net;
...
}
server {
listen 192.168.1.2:80;
server_name nginx.com www.nginx.com;
...
}
In this configuration, nginx first tests the IP address and port
of the request against the
listen directives
of the
server blocks.
It then tests the “Host”
header line of the request against the
server_name
entries of the
server
blocks that matched
the IP address and port.
If the server name is not found, the request will be processed by
the default server.
For example, a request for www.nginx.com received on
the 192.168.1.1:80 port will be handled by the default server
of the 192.168.1.1:80 port, i.e., by the first server,
since there is no www.nginx.com defined for this port.
As already stated, a default server is a property of the listen port
and different default servers may be defined for different listen ports:
server {
listen 192.168.1.1:80;
server_name nginx.org www.nginx.org;
...
}
server {
listen 192.168.1.1:80 default_server;
server_name nginx.net www.nginx.net;
...
}
server {
listen 192.168.1.2:80 default_server;
server_name nginx.com www.nginx.com;
...
}
A simple PHP site configuration
Now let’s look at how nginx chooses a location to process a request
for a typical, simple PHP site:
server {
listen 80;
server_name nginx.org www.nginx.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 searches for the most specific location given by literal strings
regardless of the listed order. In the configuration above
the only literal location is “/” and since it matches
any request it will be used as a last resort.
Then nginx checks locations given by
regular expression in the order listed in the configuration file.
The first matching expression stops the search and nginx will use this
location. If no regular expression matches a request, then nginx uses
the most specific literal location found earlier.
Note that locations of all types test only a request URI part without a query
string. This is done because arguments in the query string may be given in
several ways, for example:
/index.php?user=john&page=1
/index.php?page=1&user=john
Besides, anyone may request anything in the query string:
/index.php?page=1&something+else&user=john
Now let’s look at how requests would be processed
in the configuration above:
-
A request “/logo.gif” is matched by the literal location
“/” first and then by the regular expression
“\.(gif|jpg|png)$”,
therefore, it is handled by the latter location.
Using the directive “root /data/www” the request
is mapped to a file /data/www/logo.gif, and the file
is sent to the client.
-
A request “/index.php” is also matched by the literal location
“/” first and then by the regular expression
“\.(php)$”. Therefore, it is handled by the latter location
and the request is passed to a FastCGI server listening on localhost:9000.
The
fastcgi_param
directive sets the FastCGI parameter
SCRIPT_FILENAME to “/data/www/index.php”,
and the FastCGI server executes the file.
The variable $document_root is equal to
the value of the
root
directive and
the variable $fastcgi_script_name is equal to the request URI,
i.e. “/index.php”.
-
A request “/about.html” is matched by the literal location
“/” only, therefore, it is handled in this location.
Using the directive “root /data/www” the request is mapped
to the file /data/www/about.html, and the file is sent
to the client.
-
Handling a request “/” is more complex.
It is matched by the literal location “/” only,
therefore, it is handled by this location.
Then the
index
directive tests for the existence
of an index file according to its parameters and
the “root /data/www” directive.
If a file /data/www/index.php exists,
then the directive does an internal redirect to “/index.php”,
and nginx searches the locations again
as if the request had been sent by a client.
As we saw before, the redirected request will eventually be handled
by the FastCGI server.
written by Igor Sysoev edited by Brian Mercer
|
|