Difference between revisions of "Webservers/nginx"
Jump to navigation
Jump to search
(6 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= Nginx = | |||
== Features == | |||
* conditionals - <code>if</code> | |||
* Go-To's - <code>rewrite</code> | |||
* Case statements - <code>map</code> and <code>geo</code> | |||
* inheritance of context configurations - inherit if there is nothing else, otherwise override | |||
== Operations == | |||
<source lang=bash> | |||
nginx -v | |||
sudo nginx -t | |||
sudo systemctl status nginx | |||
sudo systemctl reload nginx | |||
sudo nginx -s reload # 0.7.53+ | |||
</source> | |||
== Variables == | |||
;Buildin | |||
* <code>$host</code> - in this order of precedence: host name from the request line, host name from the 'Host' request header field, or the server name matching a request. This is why this can be influenced by a incoming client | |||
* <code>$http_host</code> just host name from the 'Host' request header field. | |||
* <code>$http_<name></code> - any request header field; name is the field name converted to lower case with dashes replaced by underscores | |||
== [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> | |||
= Config analyzers = | |||
;[https://github.com/nginxinc/crossplane Crossplane] - configuration file parser and builder | |||
<source lang=bash> | |||
pip install crossplane | |||
# Analyse | |||
crossplane parse nginx.conf | jq # turn config into json, will contain results if errors found | |||
# Format and compare differences | |||
vimdiff nginx.conf <(crossplane format nginx.conf) | |||
# Minify, remove comments then format | |||
crossplane format <(crossplane minify nginx.conf) | |||
</source> | |||
;[https://github.com/yandex/gixy gixy] | |||
<source lang=bash> | |||
# Analyse | |||
ls -1 *conf | xargs gixy | tee gixy.log | |||
</source> | |||
= Log analyzes = | |||
; [https://github.com/lebinh/ngxtop ngxtop] | |||
<source lang=bash> | |||
$ ngxtop | |||
running for 411 seconds, 64332 records processed: 156.60 req/sec | |||
Summary: | |||
| count | avg_bytes_sent | 2xx | 3xx | 4xx | 5xx | | |||
|---------+------------------+-------+-------+-------+-------| | |||
| 64332 | 2775.251 | 61262 | 2994 | 71 | 5 | | |||
Detailed: | |||
| request_path | count | avg_bytes_sent | 2xx | 3xx | 4xx | 5xx | | |||
|------------------------------------------+---------+------------------+-------+-------+-------+-------| | |||
| /abc/xyz/xxxx | 20946 | 434.693 | 20935 | 0 | 11 | 0 | | |||
| /xxxxx.json | 5633 | 1483.723 | 5633 | 0 | | |||
</source> | |||
; Status module [https://wiki.nginx.org/NginxHttpStubStatusModule NginxHttpStubStatusModule] | |||
=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>. |
Latest revision as of 17:12, 12 January 2021
Nginx
Features
- conditionals -
if
- Go-To's -
rewrite
- Case statements -
map
andgeo
- inheritance of context configurations - inherit if there is nothing else, otherwise override
Operations
nginx -v sudo nginx -t sudo systemctl status nginx sudo systemctl reload nginx sudo nginx -s reload # 0.7.53+
Variables
- Buildin
$host
- in this order of precedence: host name from the request line, host name from the 'Host' request header field, or the server name matching a request. This is why this can be influenced by a incoming client$http_host
just host name from the 'Host' request header field.$http_<name>
- any request header field; name is the field name converted to lower case with dashes replaced by underscores
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
listen
directive
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_name
directive
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_server
block for that IP address and port part of listen directive. There can be only onedefault_server
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).
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; . . . }
Config analyzers
- Crossplane - configuration file parser and builder
pip install crossplane # Analyse crossplane parse nginx.conf | jq # turn config into json, will contain results if errors found # Format and compare differences vimdiff nginx.conf <(crossplane format nginx.conf) # Minify, remove comments then format crossplane format <(crossplane minify nginx.conf)
# Analyse ls -1 *conf | xargs gixy | tee gixy.log
Log analyzes
$ ngxtop running for 411 seconds, 64332 records processed: 156.60 req/sec Summary: | count | avg_bytes_sent | 2xx | 3xx | 4xx | 5xx | |---------+------------------+-------+-------+-------+-------| | 64332 | 2775.251 | 61262 | 2994 | 71 | 5 | Detailed: | request_path | count | avg_bytes_sent | 2xx | 3xx | 4xx | 5xx | |------------------------------------------+---------+------------------+-------+-------+-------+-------| | /abc/xyz/xxxx | 20946 | 434.693 | 20935 | 0 | 11 | 0 | | /xxxxx.json | 5633 | 1483.723 | 5633 | 0 |
- Status module NginxHttpStubStatusModule
References
- Sites-enabled vs conf.d Explanation of standards and Debian-ism of sites-enabled.