Difference between revisions of "Webservers/nginx"
		
		
		
		
		
		Jump to navigation
		Jump to search
		
				
		
		
	
| Line 1: | Line 1: | ||
= Nginx =  | |||
== [https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms server context] match order ==  | |||
For the <code>server {}</code> context selection nginx algorithm takes only 2 directives into account <code>listen</code> and <code>server_name</code>.  | |||
server {  | |||
    listen 80;  | |||
    server_name *.example.com;  | |||
    . . .  | |||
}  | |||
;Matching <code>listen</code> directive  | |||
At first <code>listen</code> directive is parsed, during this step any "incomplete" directives are added with default values  | |||
* no-ip -> set with <code>0.0.0.0</code>  | |||
* no-port -> set with port <code>:80</code>  | |||
The listen directive can be set to:  | |||
* An IP address/port combo.  | |||
* A lone IP address which will then listen on the default port 80.  | |||
* A lone port which will listen to every interface on that port.  | |||
* The path to a Unix socket  | |||
The most accurate <code>listen</code> directive match gets chosen.  | |||
;Matching <code>server_name</code> directive  | |||
If there are multiple the same listen directives, then <code>server_name</code> is being parsed in this order:  | |||
* exact match host header from the request  | |||
* leading wildcard (indicated by a <code>*</code> at the beginning of the name in the config). If multiple matches are found, the longest match will be used to serve the request.  | |||
* trailing wildcard (indicated by a server name ending with a <code>*</code> in the config). If multiple matches are found, the longest match will be used to serve the request.  | |||
* using regular expressions (indicated by a <code>~</code> before the name). The first server_name with a regular expression that matches the “Host” header will be used to serve the request.  | |||
* selects the <code>default_server</code> block for that IP address and port part of listen directive. There can be only one <code>default_server</code> declaration per each IP address/port combination.  | |||
* First block, for an IP address/port combo, this will either be the first block in the configuration or the block that contains the default_server option as part of the listen directive (which would override the first-found algorithm).   | |||
<source lang=json>  | |||
server {  | |||
    listen 80 default_server;  | |||
    server_name example.com;  | |||
    . . .  | |||
}  | |||
server {  | |||
    listen 80;  | |||
    server_name ~^(subdomain|set|www|host1).*\.example\.com$;  | |||
    . . .  | |||
}  | |||
server {  | |||
    listen 80;  | |||
    server_name www.example.*;  | |||
    . . .  | |||
}  | |||
server {  | |||
    listen 80;  | |||
    server_name *.org;  | |||
    . . .  | |||
}  | |||
</source>  | |||
=References=  | =References=  | ||
*[https://serverfault.com/questions/527630/what-is-the-different-usages-for-sites-available-vs-the-conf-d-directory-for-ngi Sites-enabled vs conf.d] Explanation of standards and Debian-ism of <tt>sites-enabled</tt>.  | *[https://serverfault.com/questions/527630/what-is-the-different-usages-for-sites-available-vs-the-conf-d-directory-for-ngi Sites-enabled vs conf.d] Explanation of standards and Debian-ism of <tt>sites-enabled</tt>.  | ||
Revision as of 09:24, 30 July 2020
Nginx
server context match order
For the server {} context selection nginx algorithm takes only 2 directives into account listen and server_name.
server {
listen 80; server_name *.example.com; . . .
}
- Matching 
listendirective 
At first listen directive is parsed, during this step any "incomplete" directives are added with default values
- no-ip -> set with 
0.0.0.0 - no-port -> set with port 
:80 
The listen directive can be set to:
- An IP address/port combo.
 - A lone IP address which will then listen on the default port 80.
 - A lone port which will listen to every interface on that port.
 - The path to a Unix socket
 
The most accurate listen directive match gets chosen.
- Matching 
server_namedirective 
If there are multiple the same listen directives, then server_name is being parsed in this order:
- exact match host header from the request
 - leading wildcard (indicated by a 
*at the beginning of the name in the config). If multiple matches are found, the longest match will be used to serve the request. - trailing wildcard (indicated by a server name ending with a 
*in the config). If multiple matches are found, the longest match will be used to serve the request. - using regular expressions (indicated by a 
~before the name). The first server_name with a regular expression that matches the “Host” header will be used to serve the request. - selects the 
default_serverblock for that IP address and port part of listen directive. There can be only onedefault_serverdeclaration per each IP address/port combination. - First block, for an IP address/port combo, this will either be the first block in the configuration or the block that contains the default_server option as part of the listen directive (which would override the first-found algorithm).
 
server {
    listen 80 default_server;
    server_name example.com;
    . . .
}
server {
    listen 80;
    server_name ~^(subdomain|set|www|host1).*\.example\.com$;
    . . .
}
server {
    listen 80;
    server_name www.example.*;
    . . .
}
server {
    listen 80;
    server_name *.org;
    . . .
}
References
- Sites-enabled vs conf.d Explanation of standards and Debian-ism of sites-enabled.