Nginx: Difference between revisions
(Undo revision 624933 by Krathalan (talk) - the certbot-nginx plugin itself (re)executes nginx so using it with unprivileged nginx does not make sense) Tag: Undo |
(Remove dead syslog.target from unit examples) |
||
(89 intermediate revisions by 37 users not shown) | |||
Line 5: | Line 5: | ||
[[ru:Nginx]] | [[ru:Nginx]] | ||
[[zh-hans:Nginx]] | [[zh-hans:Nginx]] | ||
[[Wikipedia:nginx|nginx]] (pronounced "engine X"), is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server, written by Igor Sysoev in 2005. nginx is well known for its stability, rich feature set, simple configuration, and low resource consumption. | [[Wikipedia:nginx|nginx]] (pronounced "engine X"), is a free, open-source, high-performance HTTP [[web server]] and reverse proxy, as well as an IMAP/POP3 proxy server, written by Igor Sysoev in 2005. nginx is well known for its stability, rich feature set, simple configuration, and low resource consumption. | ||
This article describes how to set up nginx and how to optionally integrate it with [[PHP]] via [[#FastCGI]]. | This article describes how to set up nginx and how to optionally integrate it with [[PHP]] via [[#FastCGI]]. | ||
Line 11: | Line 11: | ||
== Installation == | == Installation == | ||
[[Install]] the | [[Install]] one of the following packages: | ||
* {{Pkg|nginx-mainline}} - mainline branch: new features, updates, bugfixes. | |||
* {{Pkg|nginx}} - stable branch: major bugfixes only. | |||
* {{AUR|angie}} - fork and drop-in replacement for nginx with more features. | |||
Using the mainline branch is recommended. The main reason to use the stable branch is that you are concerned about possible impacts of new features, such as incompatibility with third-party modules or the inadvertent introduction of bugs in [https://nginx.org/en/download.html new features]. | Using the mainline branch is recommended. The main reason to use the stable branch is that you are concerned about possible impacts of new features, such as incompatibility with third-party modules or the inadvertent introduction of bugs in [https://nginx.org/en/download.html new features]. | ||
Line 21: | Line 25: | ||
== Running == | == Running == | ||
[[Start/enable]] {{ic|nginx.service}}. | [[Start/enable]] {{ic|nginx.service}} or {{ic|angie.service}} if you use Angie. | ||
The default page served at http://127.0.0.1 is {{ic|/usr/share/nginx/html/index.html}}. | The default page served at http://127.0.0.1 is {{ic|/usr/share/nginx/html/index.html}}. | ||
Line 27: | Line 31: | ||
== Configuration == | == Configuration == | ||
First steps with nginx are described in the [ | First steps with nginx are described in the [https://nginx.org/en/docs/beginners_guide.html Beginner’s Guide]. You can modify the configuration by editing the files in {{ic|/etc/nginx/}} The main configuration file is located at {{ic|/etc/nginx/nginx.conf}}. | ||
More details and examples can be found in | More details and examples can be found in https://wiki.nginx.org/Configuration and the [https://nginx.org/en/docs/ official documentation]. | ||
The examples below cover the most common use cases. It is assumed that you use the default location for documents ({{ic|/usr/share/nginx/html}}). If that is not the case, substitute your path instead. | The examples below cover the most common use cases. It is assumed that you use the default location for documents ({{ic|/usr/share/nginx/html}}). If that is not the case, substitute your path instead. | ||
{{Tip|A [https:// | {{Tip|A [https://www.digitalocean.com/community/tools/nginx/ Nginx configuration tool] has been provided by DigitalOcean.}} | ||
=== Configuration example === | === Configuration example === | ||
{{hc|/etc/nginx/nginx.conf| | |||
{{hc|/etc/nginx/nginx.conf| | |||
user http; | user http; | ||
worker_processes auto; | worker_processes auto; | ||
Line 68: | Line 73: | ||
include /etc/nginx/sites-enabled/*; | include /etc/nginx/sites-enabled/*; | ||
} | } | ||
}} | |||
=== General configuration === | === General configuration === | ||
Line 74: | Line 79: | ||
==== Processes and connections ==== | ==== Processes and connections ==== | ||
You should choose a fitting value for {{ic|worker_processes}}. This setting ultimately defines how many connections nginx will accept and how many processors it will be able to make use of. Generally, making it the number of hardware threads in your system is a good start. Alternatively, {{ic|worker_processes}} accepts the {{ic|auto}} value since versions 1.3.8 and 1.2.5, which will try to autodetect the optimal value ([ | You should choose a fitting value for {{ic|worker_processes}}. This setting ultimately defines how many connections nginx will accept and how many processors it will be able to make use of. Generally, making it the number of hardware threads in your system is a good start. Alternatively, {{ic|worker_processes}} accepts the {{ic|auto}} value since versions 1.3.8 and 1.2.5, which will try to autodetect the optimal value ([https://nginx.org/en/docs/ngx_core_module.html#worker_processes source]). | ||
The maximum connections nginx will accept is given by {{ic|1=max_clients = worker_processes * worker_connections}}. | The maximum connections nginx will accept is given by {{ic|1=max_clients = worker_processes * worker_connections}}. | ||
Line 88: | Line 93: | ||
If the group is omitted, a group whose name equals that of ''user'' is used. | If the group is omitted, a group whose name equals that of ''user'' is used. | ||
{{Tip|1=It is also possible to run nginx without anything running as {{ic|root}} using [[systemd]]. See [[#Running unprivileged using systemd]].}} | {{Tip|1=It is also possible to run nginx without anything running as {{ic|root}} using [[systemd]]. See [[#Running unprivileged using systemd]] and [[#Running user service using systemd]].}} | ||
==== Server blocks ==== | ==== Server blocks ==== | ||
Line 94: | Line 99: | ||
It is possible to serve multiple domains using {{ic|server}} blocks. These are comparable to "VirtualHosts" in [[Apache HTTP Server]]. Also see the [https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/ upstream examples]. | It is possible to serve multiple domains using {{ic|server}} blocks. These are comparable to "VirtualHosts" in [[Apache HTTP Server]]. Also see the [https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/ upstream examples]. | ||
In the example below the server listens for incoming connections on IPv4 and IPv6 ports 80 for two domains, {{ic|domainname1. | In the example below the server listens for incoming connections on IPv4 and IPv6 ports 80 for two domains, {{ic|domainname1.tld}} and {{ic|domainname2.tld}}: | ||
{{hc|/etc/nginx/nginx.conf| | {{hc|/etc/nginx/nginx.conf| | ||
... | ... | ||
server { | server { | ||
listen 80; | listen 80; | ||
listen [::]:80; | listen [::]:80; | ||
server_name domainname1. | server_name domainname1.tld; | ||
root /usr/share/nginx/domainname1. | root /usr/share/nginx/domainname1.tld/html; | ||
location / { | location / { | ||
index index.php index.html index.htm; | index index.php index.html index.htm; | ||
Line 111: | Line 116: | ||
listen 80; | listen 80; | ||
listen [::]:80; | listen [::]:80; | ||
server_name domainname2. | server_name domainname2.tld; | ||
root /usr/share/nginx/domainname2. | root /usr/share/nginx/domainname2.tld/html; | ||
... | ... | ||
} | } | ||
}} | |||
[[Restart]] {{ic|nginx.service}} to apply any changes. | [[Restart]] {{ic|nginx.service}} to apply any changes. | ||
Line 125: | Line 130: | ||
It is possible to put different {{ic|server}} blocks in different files. This allows you to easily enable or disable certain sites. | It is possible to put different {{ic|server}} blocks in different files. This allows you to easily enable or disable certain sites. | ||
{{Accuracy|It is contested if the below approach using {{ic|sites-enabled}} and {{ic|sites-available}} is still useful and doesn't create more problems, see [https://serverfault.com/questions/527630/difference-in-sites-available-vs-sites-enabled-vs-conf-d-directories-nginx comparing the two approaches] and [https://stackoverflow.com/questions/45660042/nginx-proxy-pass-leads-to-404-not-found-page/45789055 example of problems arising through sites-enabled and sites-available approach]. | |||
Instead, one can just create files inside {{ic|etc/nginx/conf.d/}} which adheres to the standard of drop in configuration files. Then, include {{ic|include /etc/nginx/conf.d/*.conf}} in the main config file, similar to including other file patterns in other directories as shown below. This way, sites can be disabled just be renaming them to e.g. {{ic|original_name.conf.disabled}}, since only files ending in ''.conf'' are included. | |||
}} | |||
For using the {{ic|sites-enabled}} and {{ic|sites-available}} approach, create the following directories: | |||
# mkdir /etc/nginx/sites-available | # mkdir /etc/nginx/sites-available | ||
Line 132: | Line 142: | ||
Create a file inside the {{ic|sites-available}} directory that contains one or more server blocks: | Create a file inside the {{ic|sites-available}} directory that contains one or more server blocks: | ||
{{hc|/etc/nginx/sites-available/example.conf| | {{hc|/etc/nginx/sites-available/example.conf| | ||
server { | server { | ||
listen 443 ssl | listen 443 ssl; | ||
listen [::]:443 ssl http2; | listen [::]:443 ssl; | ||
http2 on; | |||
... | ... | ||
} | } | ||
}} | |||
Append | Append {{ic|include sites-enabled/*;}} to the end of the {{ic|http}} block: | ||
{{hc|/etc/nginx/nginx.conf| | {{hc|/etc/nginx/nginx.conf| | ||
http { | http { | ||
... | ... | ||
include sites-enabled/*; | include sites-enabled/*; | ||
} | } | ||
}} | |||
To enable a site, | To enable a site, simply create a symlink: | ||
# ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/example.conf | # ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/example.conf | ||
Line 158: | Line 169: | ||
# unlink /etc/nginx/sites-enabled/example.conf | # unlink /etc/nginx/sites-enabled/example.conf | ||
[[Reload]]/[[restart]] {{ic|nginx.service}} to enable changes to the | [[Reload]]/[[restart]] {{ic|nginx.service}} to enable changes to the site's configuration. | ||
==== TLS ==== | ==== TLS ==== | ||
{{Style|Do not duplicate [[OpenSSL# | {{Style|Do not duplicate [[OpenSSL#Usage]].}} | ||
[[OpenSSL]] provides TLS support and is installed by default on Arch installations. | [[OpenSSL]] provides TLS support and is installed by default on Arch installations. | ||
{{Tip| | {{Tip| | ||
* You may want to read the [ | * You may want to read the [https://nginx.org/en/docs/http/ngx_http_ssl_module.html ngx_http_ssl_module] documentation first before configuring SSL. | ||
* [[Let’s Encrypt]] is a free, automated, and open certificate authority. A plugin is available to request valid SSL certificates straight from the command line and automatic configuration. | * [[Let’s Encrypt]] is a free, automated, and open certificate authority. A plugin is available to request valid SSL certificates straight from the command line and automatic configuration. | ||
* Mozilla has a useful [[MozillaWiki:Security/Server Side TLS|TLS article]] as well as an [https://mozilla.github.io/server-side-tls/ssl-config-generator/ automated tool] to help create a more secure configuration. | * Mozilla has a useful [[MozillaWiki:Security/Server Side TLS|TLS article]] as well as an [https://mozilla.github.io/server-side-tls/ssl-config-generator/ automated tool] to help create a more secure configuration. | ||
}} | }} | ||
Line 196: | Line 206: | ||
{{Note|For more ''openssl'' options, read its man page {{man|1ssl|openssl}} or peruse its [https://www.openssl.org/docs/ extensive documentation].}} | {{Note|For more ''openssl'' options, read its man page {{man|1ssl|openssl}} or peruse its [https://www.openssl.org/docs/ extensive documentation].}} | ||
A starting point for a {{ic|/etc/nginx/nginx.conf}} with TLS is [https://ssl-config.mozilla.org/#server=nginx Mozilla's SSL Configuration Generator]. | |||
[[Restart]] {{ic|nginx.service}} to apply any changes. | [[Restart]] {{ic|nginx.service}} to apply any changes. | ||
Line 259: | Line 239: | ||
See [[#PHP implementation]] for more information on PHP configuration with {{ic|nginx}}. | See [[#PHP implementation]] for more information on PHP configuration with {{ic|nginx}}. | ||
Restart {{ic|nginx.service}} to enable the new configuration. | [[Restart]] {{ic|nginx.service}} to enable the new configuration. | ||
=== FastCGI === | === FastCGI === | ||
Line 273: | Line 253: | ||
[[Install]] {{Pkg|php-fpm}} and make sure [[PHP]] has been installed and configured correctly. The main configuration file of PHP-FPM is {{ic|/etc/php/php-fpm.conf}}. For basic usage the default configuration should be sufficient. | [[Install]] {{Pkg|php-fpm}} and make sure [[PHP]] has been installed and configured correctly. The main configuration file of PHP-FPM is {{ic|/etc/php/php-fpm.conf}}. For basic usage the default configuration should be sufficient. | ||
Finally, [[enable | Finally, [[start/enable]] {{ic|php-fpm.service}}. | ||
You can also use {{Pkg|php-legacy-fpm}} instead, see [[#Using php-legacy]]. | |||
{{Note| | {{Note| | ||
* If you [[#Running under different user|run nginx under a different user]], make sure that the PHP-FPM socket file is accessible by this user, or use a TCP socket. | * If you [[#Running under different user|run nginx under a different user]], make sure that the PHP-FPM socket file is accessible by this user, or use a TCP socket. | ||
* If you run nginx in chrooted environment (chroot is {{ic|/srv/nginx-jail}}, web pages are served at {{ic|/srv/nginx-jail/www}}), you must modify the file {{ic|/etc/php/php-fpm.conf}} to include the {{ic|chroot /srv/nginx-jail}} and {{ic|1=listen = /srv/nginx-jail/run/php-fpm/php-fpm.sock}} directives within the pool section (a default one is {{ic|[www]}}). Create the directory for the socket file, if missing. Moreover, for modules that are dynamically linked to dependencies, you will need to copy those dependencies to the chroot (e.g. for php-imagick, you will need to copy the ImageMagick libraries to the chroot, but not imagick.so itself). | * If you run nginx in chrooted environment (chroot is {{ic|/srv/nginx-jail}}, web pages are served at {{ic|/srv/nginx-jail/www}}), you must modify the file {{ic|/etc/php/php-fpm.conf}} to include the {{ic|1=chroot = /srv/nginx-jail}} and {{ic|1=listen = /srv/nginx-jail/run/php-fpm/php-fpm.sock}} directives within the pool section (a default one is {{ic|[www]}}). Create the directory for the socket file, if missing. Moreover, for modules that are dynamically linked to dependencies, you will need to copy those dependencies to the chroot (e.g. for php-imagick, you will need to copy the ImageMagick libraries to the chroot, but not imagick.so itself). | ||
}} | }} | ||
Line 285: | Line 266: | ||
When serving a PHP web-application, a {{ic|location}} for PHP-FPM should to be included in each [[#Server blocks|server block]] [https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/], e.g.: | When serving a PHP web-application, a {{ic|location}} for PHP-FPM should to be included in each [[#Server blocks|server block]] [https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/], e.g.: | ||
{{hc|/etc/nginx/sites-available/example.conf| | {{hc|/etc/nginx/sites-available/example.conf|2= | ||
server { | server { | ||
root /usr/share/nginx/html; | root /usr/share/nginx/html; | ||
location / { | location / { | ||
index index.html index.htm; | index index.html index.htm index.php; | ||
} | } | ||
Line 312: | Line 293: | ||
} | } | ||
} | } | ||
}} | |||
If it is needed to process other extensions with PHP (e.g. ''.html'' and ''.htm''): | If it is needed to process other extensions with PHP (e.g. ''.html'' and ''.htm''): | ||
Line 324: | Line 305: | ||
security.limit_extensions = .php .html .htm | security.limit_extensions = .php .html .htm | ||
{{Note|Pay attention to the {{ic|fastcgi_pass}} argument, as it must be the TCP or Unix socket defined by the chosen FastCGI server in its | {{Note|Pay attention to the {{ic|fastcgi_pass}} argument, as it must be the TCP or Unix socket defined by the chosen FastCGI server in its configuration file. The '''default''' (Unix) socket for {{ic|php-fpm}} is: | ||
fastcgi_pass unix:/run/php-fpm/php-fpm.sock; | fastcgi_pass unix:/run/php-fpm/php-fpm.sock; | ||
Line 335: | Line 316: | ||
{{Tip|To allow multiple {{ic|server}} blocks using the same PHP-FPM configuration, a {{ic|php_fastcgi.conf}} configuration file may be used to ease management: | {{Tip|To allow multiple {{ic|server}} blocks using the same PHP-FPM configuration, a {{ic|php_fastcgi.conf}} configuration file may be used to ease management: | ||
{{hc|/etc/nginx/php_fastcgi.conf| | |||
{{hc|/etc/nginx/php_fastcgi.conf|2= | |||
location ~ \.php$ { | location ~ \.php$ { | ||
# 404 | # 404 | ||
Line 346: | Line 328: | ||
... | ... | ||
} | } | ||
}} | |||
To enable PHP support for a particular server, simply include the {{ic|php_fastcgi.conf}} configuration file: | To enable PHP support for a particular server, simply include the {{ic|php_fastcgi.conf}} configuration file: | ||
{{hc|/etc/nginx/sites-available/example.conf| | {{hc|/etc/nginx/sites-available/example.conf| | ||
server { | server { | ||
server_name example.com; | server_name example.com; | ||
Line 357: | Line 339: | ||
include /etc/nginx/php_fastcgi.conf; | include /etc/nginx/php_fastcgi.conf; | ||
} | } | ||
}} | |||
}} | }} | ||
Line 376: | Line 359: | ||
===== fcgiwrap ===== | ===== fcgiwrap ===== | ||
[[Install]] {{Pkg|fcgiwrap}}. The configuration | [[Install]] {{Pkg|fcgiwrap}}. The configuration is done by [[edit]]ing {{ic|fcgiwrap.socket}}. [[Enable]] and [[start]] {{ic|fcgiwrap.socket}}. | ||
====== Multiple worker threads ====== | ====== Multiple worker threads ====== | ||
If you want to spawn multiple worker threads, it is recommended that you use {{AUR|multiwatch}}, which will take care of restarting crashed children. You will need to use {{ic|spawn-fcgi}} to create the | If you want to spawn multiple worker threads, it is recommended that you use {{AUR|multiwatch}}, which will take care of restarting crashed children. You will need to use {{ic|spawn-fcgi}} to create the Unix socket, as multiwatch seems unable to handle the systemd-created socket, even though fcgiwrap itself does not have any trouble if invoked directly in the unit file. | ||
[[Override the unit]] {{ic|fcgiwrap.service}} (and the {{ic|fcgiwrap.socket}} unit, if present), and modify the {{ic|ExecStart}} line to suit your needs. Here is a unit file that uses {{AUR|multiwatch}}. Make sure {{ic|fcgiwrap.socket}} is not started or enabled, because it will conflict with this unit: | |||
{{hc|/etc/systemd/system/fcgiwrap.service|2= | {{hc|/etc/systemd/system/fcgiwrap.service|2= | ||
Line 423: | Line 406: | ||
{{Warning|If SCRIPT_NAME and DOCUMENT_ROOT are used, fcgiwrap will ''discard'' any other fastcgi_params set in nginx. You must use SCRIPT_FILENAME in order for other params (like PATH_INFO) to be settable through the Nginx configuration. See [https://github.com/gnosek/fcgiwrap/issues/3 this] GitHub issue.}} | {{Warning|If SCRIPT_NAME and DOCUMENT_ROOT are used, fcgiwrap will ''discard'' any other fastcgi_params set in nginx. You must use SCRIPT_FILENAME in order for other params (like PATH_INFO) to be settable through the Nginx configuration. See [https://github.com/gnosek/fcgiwrap/issues/3 this] GitHub issue.}} | ||
If you keep getting a {{ic|502 - bad Gateway}} error, you should check if your CGI-application first announces the mime-type of the following content. For | If you keep getting a {{ic|502 - bad Gateway}} error, you should check if your CGI-application first announces the mime-type of the following content. For HTML this needs to be {{ic|Content-type: text/html}}. | ||
If you get 403 errors, make sure that the CGI executable is readable and executable by the {{ic|http}} user and that every parent folder is readable by the {{ic|http}} user. | If you get 403 errors, make sure that the CGI executable is readable and executable by the {{ic|http}} user and that every parent folder is readable by the {{ic|http}} user. | ||
Line 429: | Line 412: | ||
== Installation in a chroot == | == Installation in a chroot == | ||
Installing nginx in a [[chroot]] adds an additional layer of security. For maximum security the chroot should include only the files needed to run the nginx server and all files should have the most restrictive permissions possible, e.g., as much as possible should be owned by root, directories such as {{ic|/usr/bin}} should be unreadable and | {{Accuracy|This section is from 2013. systemd has since been introduced and can be used instead, at much greater efficiency and without much hassle.}} | ||
Installing nginx in a [[chroot]] adds an additional layer of security. For maximum security the chroot should include only the files needed to run the nginx server and all files should have the most restrictive permissions possible, e.g., as much as possible should be owned by root, directories such as {{ic|/usr/bin}} should be unreadable and unwritable, etc. | |||
Arch comes with an {{ic|http}} user and group by default which will run the server. The chroot will be in {{ic|/srv/http}}. | Arch comes with an {{ic|http}} user and group by default which will run the server. The chroot will be in {{ic|/srv/http}}. | ||
A | A PERL script to create this jail is available at [https://gist.github.com/4365696 jail.pl gist]. You can either use that or follow the instructions in this article. It expects to be run as root. You will need to uncomment a line before it makes any changes. | ||
=== Create necessary devices === | === Create necessary devices === | ||
Line 439: | Line 424: | ||
nginx needs {{ic|/dev/null}}, {{ic|/dev/random}}, and {{ic|/dev/urandom}}. To install these in the chroot create the {{ic|/dev/}} directory and add the devices with ''mknod''. Avoid mounting all of {{ic|/dev/}} to ensure that, even if the chroot is compromised, an attacker must break out of the chroot to access important devices like {{ic|/dev/sda1}}. | nginx needs {{ic|/dev/null}}, {{ic|/dev/random}}, and {{ic|/dev/urandom}}. To install these in the chroot create the {{ic|/dev/}} directory and add the devices with ''mknod''. Avoid mounting all of {{ic|/dev/}} to ensure that, even if the chroot is compromised, an attacker must break out of the chroot to access important devices like {{ic|/dev/sda1}}. | ||
{{Tip|Be sure that {{ic|/srv/http}} is mounted without nodev option | {{Tip| | ||
* Be sure that {{ic|/srv/http}} is mounted without the nodev option | |||
* See {{man|1|mknod}} and {{ic|ls -l /dev/{null,random,urandom}<nowiki/>}} to better understand the ''mknod'' options. | |||
}} | |||
# export JAIL=/srv/http | # export JAIL=/srv/http | ||
Line 469: | Line 456: | ||
In order to preserve the mounts across reboots, the following entries should be added to {{ic|/etc/fstab}}: | In order to preserve the mounts across reboots, the following entries should be added to {{ic|/etc/fstab}}: | ||
{{hc|/etc/fstab| | {{hc|/etc/fstab|2= | ||
tmpfs /srv/http/run tmpfs rw,noexec,relatime,size=1024k 0 0 | |||
tmpfs /srv/http/tmp tmpfs rw,noexec,relatime,size=102400k 0 0 | |||
}} | |||
=== Populate the chroot === | === Populate the chroot === | ||
Line 485: | Line 472: | ||
Now copy over required libraries. Use ''ldd'' to list them and then copy them all to the correct location. Copying is preferred over hardlinks to ensure that even if an attacker gains write access to the files they cannot destroy or alter the true system files. | Now copy over required libraries. Use ''ldd'' to list them and then copy them all to the correct location. Copying is preferred over hardlinks to ensure that even if an attacker gains write access to the files they cannot destroy or alter the true system files. | ||
{{hc|$ ldd /usr/bin/nginx| | {{hc|$ ldd /usr/bin/nginx|2= | ||
linux-vdso.so.1 (0x00007fffc41fe000) | linux-vdso.so.1 (0x00007fffc41fe000) | ||
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57ec3e8000) | libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57ec3e8000) | ||
Line 499: | Line 486: | ||
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57eaa77000) | libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57eaa77000) | ||
libc.so.6 => /usr/lib/libc.so.6 (0x00007f57ea6ca000) | libc.so.6 => /usr/lib/libc.so.6 (0x00007f57ea6ca000) | ||
/lib64/ld-linux-x86-64.so.2 (0x00007f57ec604000) | /lib64/ld-linux-x86-64.so.2 (0x00007f57ec604000) | ||
}} | |||
For files residing in {{ic|/usr/lib}} you may try the following one-liner: | For files residing in {{ic|/usr/lib}} you may try the following one-liner: | ||
Line 541: | Line 529: | ||
# touch $JAIL/run/nginx.pid | # touch $JAIL/run/nginx.pid | ||
Finally make set very restrictive permissions. As much as possible should be owned by root and set unwritable. | Finally, make set very restrictive permissions. As much as possible should be owned by root and set unwritable. | ||
# chown -R root:root $JAIL/ | # chown -R root:root $JAIL/ | ||
Line 564: | Line 552: | ||
=== Modify nginx.service to start chroot === | === Modify nginx.service to start chroot === | ||
[[Override the unit]] {{ic|nginx.service}}. Upgrading nginx will not modify your custom ''.service'' file. | |||
The systemd unit must be changed to start up nginx in the chroot, as the http user, and store the PID file in the chroot. | |||
{{Note|I'm not sure if the pid file needs to be stored in the chroot jail.}} | |||
{{hc|/etc/systemd/system/nginx.service|2= | |||
[Unit] | |||
Description=A high performance web server and a reverse proxy server | |||
After=network.target | |||
[Service] | |||
Type=forking | |||
PIDFile=/srv/http/run/nginx.pid | |||
ExecStartPre=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -t -q -g 'pid /run/nginx.pid; daemon on; master_process on;' | |||
ExecStart=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' | |||
ExecReload=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' -s reload | |||
ExecStop=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid;' -s quit | |||
[Install] | |||
WantedBy=multi-user.target | |||
}} | |||
{{Note|Upgrading nginx with pacman will not upgrade the chrooted nginx installation. You have to take care of the updates manually by repeating some of the steps above. Do not forget to also update the libraries it links against.}} | {{Note|Upgrading nginx with pacman will not upgrade the chrooted nginx installation. You have to take care of the updates manually by repeating some of the steps above. Do not forget to also update the libraries it links against.}} | ||
Line 594: | Line 581: | ||
# pacman -Rsc nginx | # pacman -Rsc nginx | ||
If you do not remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where {{ic|/proc/''PID''/root}} | If you do not remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where {{ic|/proc/''PID''/root}} symlinks to. It should link to {{ic|/srv/http}} instead of {{ic|/}}. | ||
# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done | # ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done | ||
Line 600: | Line 587: | ||
== Tips and tricks == | == Tips and tricks == | ||
=== Running unprivileged using [[ | === Running unprivileged using systemd === | ||
Use a [[drop-in unit file]] for {{ic|nginx.service}} and set the {{ic|User}} and optionally {{ic|Group}} options under {{ic|[Service]}}: | |||
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | {{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | ||
[Service] | [Service] | ||
Line 610: | Line 598: | ||
We can harden the service against ever elevating privileges: | We can harden the service against ever elevating privileges: | ||
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | {{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | ||
[Service] | [Service] | ||
Line 616: | Line 605: | ||
}} | }} | ||
{{Tip| | {{Tip|See {{man|5|systemd.exec}} for more options of confinement.}} | ||
Then we need to ensure that {{ic|''user''}} has access to everything it needs. Follow the subsections below and then [[start]] nginx. | |||
{{Tip|The same setup may be desirable for your [[#FastCGI|FastCGI server]] as well.}} | |||
==== Port ==== | |||
Linux does not permit non-{{ic|root}} processes to bind to ports below 1024 by default. A port above 1024 can be used: | Linux does not permit non-{{ic|root}} processes to bind to ports below 1024 by default. A port above 1024 can be used: | ||
Line 633: | Line 623: | ||
{{Tip|1=If you want nginx accessible on port 80 or 443, configure your [[firewall]] to redirect requests from 80 or 443 to the ports nginx listens to.}} | {{Tip|1=If you want nginx accessible on port 80 or 443, configure your [[firewall]] to redirect requests from 80 or 443 to the ports nginx listens to.}} | ||
Or you may grant the nginx process the CAP_NET_BIND_SERVICE capability which | Or you may grant the nginx process the CAP_NET_BIND_SERVICE capability which allows it to bind to ports below 1024: | ||
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | {{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | ||
Line 643: | Line 633: | ||
AmbientCapabilities=CAP_NET_BIND_SERVICE | AmbientCapabilities=CAP_NET_BIND_SERVICE | ||
}} | }} | ||
Alternatively, you can use systemd socket activation. In this case, systemd will listen on the ports and, when a connection is made, spawn nginx passing the socket as a file descriptor. This means nginx requires no special capabilities as the socket already exists when it is started. This relies on an internal environment variable that nginx uses for passing sockets [https://trac.nginx.org/nginx/ticket/237] and is therefore not officially supported. Instead of setting {{ic|CapabilityBoundingSet}} and {{ic|AmbientCapabilities}}, edit the service override to set the {{ic|NGINX}} environment variable to tell nginx which file descriptors the sockets will be passed as: | |||
{{ | |||
{{hc|/etc/ | {{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | ||
[Service] | |||
... | |||
Environment=NGINX=3:4; | |||
}} | }} | ||
There will be one socket per listening port starting at file descriptor 3, so in this example we are telling nginx to expect two sockets. Now create a {{ic|nginx.socket}} unit specifying what ports to listen on: | |||
{{hc|/etc/systemd/system/nginx.socket|2= | |||
[Socket] | |||
ListenStream=0.0.0.0:80 | |||
ListenStream=0.0.0.0:443 | |||
After=network.target | |||
Requires=network.target | |||
[[ | [Install] | ||
WantedBy=sockets.target | |||
}} | |||
The sockets will be passed in the order defined in this unit, so port 80 will be file descriptor 3 and port 443 will be file descriptor 4. If you previously enabled or started the service, you should now [[stop]] it, and [[enable]] {{ic|nginx.socket}} instead. When your system starts, nginx will not be running, but will be started when you access the website in a browser. With this you can harden the service further; for example, in many cases you can now set {{ic|1=PrivateNetwork=True}} in the service file, blocking nginx from the external network, since the socket created by systemd is sufficient to serve the website over. Note that this will print a warning in the logs of the nginx service: {{ic|2020/08/29 19:33:20 [notice] 254#254: using inherited sockets from "3:4;"}} | |||
==== PID file ==== | |||
{{Pkg|nginx}} is compiled to use {{ic|/run/nginx.pid}} by default, which ''user'' cannot write to. We can create a directory that ''user'' can write to and place the PID file there. This can for example be done with {{ic|RuntimeDirectory}} ({{man|5|systemd.exec}}). | |||
[[Edit]] {{ic|nginx.service}} to configure the PID file: | |||
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | {{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | ||
[Service] | [Service] | ||
... | ... | ||
RuntimeDirectory=nginx | |||
PIDFile=/run/nginx/nginx.pid | PIDFile=/run/nginx/nginx.pid | ||
ExecStart= | ExecStart= | ||
ExecStart=/usr/bin/nginx -g 'pid /run/nginx/nginx.pid; error_log stderr;' | ExecStart=/usr/bin/nginx -g 'pid /run/nginx/nginx.pid; error_log stderr;' | ||
ExecReload= | ExecReload= | ||
ExecReload=/usr/bin/nginx -s reload -g 'pid /run/nginx/nginx.pid;' | ExecReload=/usr/bin/nginx -s reload -g 'pid /run/nginx/nginx.pid; error_log stderr;' | ||
}} | }} | ||
==== /var/lib/nginx ==== | |||
{{Pkg|nginx}} is compiled to store temp files in {{ic|/var/lib/nginx}} by default. | |||
{{Tip|See all compiled-in options by running {{ic|$ nginx -V}}}} | |||
You can give ''user'' write access to this directory by for example using {{ic|StateDirectory}} ({{man|5|systemd.exec}}): | |||
{{ | {{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | ||
[Service] | |||
... | |||
StateDirectory=nginx | |||
}} | |||
==== /var/log/nginx ==== | |||
{{Pkg|nginx}} is compiled to store access logs in {{ic|/var/log/nginx}} by default. | |||
You can give ''user'' write access to this directory by for example using {{ic|LogsDirectory}} ({{man|5|systemd.exec}}): | |||
{{hc|/etc/systemd/system/nginx.service.d/user.conf|2= | |||
[Service] | |||
... | |||
LogsDirectory=nginx | |||
}} | |||
=== Running user service using systemd === | |||
If you want to run a server instance fully controlled and configurable by unprivileged user, consider using {{AUR|nginx-user-service}}. | |||
=== Alternative script for systemd === | === Alternative script for systemd === | ||
On pure systemd you can get advantages of chroot + systemd. [http://0pointer.de/blog/projects/changing-roots.html] Based on set [ | On pure systemd you can get advantages of chroot + systemd. [http://0pointer.de/blog/projects/changing-roots.html] Based on set [https://wiki.nginx.org/CoreModule#user user group] and pid with: | ||
{{hc|/etc/nginx/nginx.conf|2= | {{hc|/etc/nginx/nginx.conf|2= | ||
Line 695: | Line 713: | ||
}} | }} | ||
the absolute path of file is {{ic|/srv/http/etc/nginx/nginx.conf}}. | the absolute path of the file is {{ic|/srv/http/etc/nginx/nginx.conf}}. | ||
{{hc|/etc/systemd/system/nginx.service|2= | {{hc|/etc/systemd/system/nginx.service|2= | ||
[Unit] | [Unit] | ||
Description=nginx (Chroot) | Description=nginx (Chroot) | ||
After= | After=network.target | ||
[Service] | [Service] | ||
Line 706: | Line 724: | ||
PIDFile=/srv/http/run/nginx.pid | PIDFile=/srv/http/run/nginx.pid | ||
RootDirectory=/srv/http | RootDirectory=/srv/http | ||
ExecStartPre=/usr/ | ExecStartPre=/usr/bin/nginx -t -c /etc/nginx/nginx.conf | ||
ExecStart=/usr/ | ExecStart=/usr/bin/nginx -c /etc/nginx/nginx.conf | ||
ExecReload=/usr/ | ExecReload=/usr/bin/nginx -c /etc/nginx/nginx.conf -s reload | ||
ExecStop=/usr/ | ExecStop=/usr/bin/nginx -c /etc/nginx/nginx.conf -s stop | ||
[Install] | [Install] | ||
Line 715: | Line 733: | ||
}} | }} | ||
It is not | It is not necessary to set the default location, nginx loads at default {{ic| -c /etc/nginx/nginx.conf}}, but it is a good idea. | ||
Alternatively you can run '''only''' {{ic|ExecStart}} as chroot with parameter {{ic|RootDirectoryStartOnly}} set as {{ic|yes}} (see {{man|5|systemd.service}}) or start it before mount point as effective or a systemd path (see {{man|5|systemd.path}}) is available. | Alternatively you can run '''only''' {{ic|ExecStart}} as chroot with parameter {{ic|RootDirectoryStartOnly}} set as {{ic|yes}} (see {{man|5|systemd.service}}) or start it before mount point as effective or a systemd path (see {{man|5|systemd.path}}) is available. | ||
Line 748: | Line 766: | ||
... | ... | ||
}} | }} | ||
=== Basic Authentication === | |||
Basic authentication requires creation of a password file. The password file can be managed using {{ic|htpasswd}} program provided by the {{Pkg|apache}} package or using {{AUR|nginx_passwd}} which provides {{ic|nginx-passwd}} - details available on [https://github.com/gene-git/nginx_passwd GitHub source] | |||
=== Using php-legacy === | |||
[[Install]] {{Pkg|php-legacy-fpm}} instead of {{Pkg|php-fpm}} and make sure [[PHP]] has been installed and configured correctly. | |||
The main configuration file of PHP-LEGACY-FPM is {{ic|/etc/php-legacy/php-fpm.conf}}. For basic usage the default configuration should be sufficient. | |||
The Unix socket for the {{ic|fastcgi_pass}} argument also needs to be adjusted, usually it is: | |||
fastcgi_pass unix:/run/php-fpm-legacy/php-fpm.sock; | |||
Then [[start/enable]] {{ic|php-legacy-fpm.service}}. | |||
== Troubleshooting == | == Troubleshooting == | ||
Line 757: | Line 791: | ||
nginx: configuration file /etc/nginx/nginx.conf test is successful | nginx: configuration file /etc/nginx/nginx.conf test is successful | ||
}} | }} | ||
=== Error: The page you are looking for is temporarily unavailable. Please try again later. (502 Bad Gateway) === | === Error: The page you are looking for is temporarily unavailable. Please try again later. (502 Bad Gateway) === | ||
Line 774: | Line 798: | ||
Try [https://stackoverflow.com/questions/4252368/nginx-502-bad-gateway/16497957#16497957 out this answer] to fix the 502 error. | Try [https://stackoverflow.com/questions/4252368/nginx-502-bad-gateway/16497957#16497957 out this answer] to fix the 502 error. | ||
In | In Arch Linux, the configuration file mentioned in above link is {{ic|/etc/php/php-fpm.conf}}. | ||
=== Error: No input file specified === | === Error: No input file specified === | ||
1. Verify that variable {{ic|open_basedir}} in {{ic|/etc/php/php.ini}} contains the correct path specified as {{ic|root}} argument in {{ic|nginx.conf}} (usually {{ic|/usr/share/nginx/}}). When using [ | 1. Verify that variable {{ic|open_basedir}} in {{ic|/etc/php/php.ini}} contains the correct path specified as {{ic|root}} argument in {{ic|nginx.conf}} (usually {{ic|/usr/share/nginx/}}). When using [https://php-fpm.org/ PHP-FPM] as FastCGI server for PHP, you may add {{ic|fastcgi_param PHP_ADMIN_VALUE "open_basedir{{=}}$document_root/:/tmp/:/proc/";}} in the {{ic|location}} block which aims for processing PHP file in {{ic|nginx.conf}}. | ||
2. Another occasion is that, wrong {{ic|root}} argument in the {{ic|location ~ \.php$}} section in {{ic|nginx.conf}}. Make sure the {{ic|root}} points to the same directory as it in {{ic|location /}} in the same server. Or you may just set root as global, do not define it in any location section. | 2. Another occasion is that, wrong {{ic|root}} argument in the {{ic|location ~ \.php$}} section in {{ic|nginx.conf}}. Make sure the {{ic|root}} points to the same directory as it in {{ic|location /}} in the same server. Or you may just set root as global, do not define it in any location section. | ||
3. Check permissions: e.g. {{ic|http}} for user/group, | 3. Check permissions: e.g. {{ic|http}} for user/group, {{ic|755}} for directories and {{ic|644}} for files. Remember the entire path to the {{ic|html}} directory should have the correct permissions. See [[File permissions and attributes#Bulk chmod]] to bulk modify a directory tree. | ||
4. You do not have the {{ic|SCRIPT_FILENAME}} containing the full path to your scripts. If the configuration of nginx ({{ic|fastcgi_param SCRIPT_FILENAME}}) is correct, this kind of error means | 4. You do not have the {{ic|SCRIPT_FILENAME}} containing the full path to your scripts. If the configuration of nginx ({{ic|fastcgi_param SCRIPT_FILENAME}}) is correct, this kind of error means PHP failed to load the requested script. Usually it is simply a permissions issue, you can just run php-cgi as root: | ||
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi | # spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi | ||
Line 804: | Line 828: | ||
[warn] 18872#18872: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size | [warn] 18872#18872: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size | ||
To fix this warning, increase the values for these keys inside the {{ic|http}} block [ | To fix this warning, increase the values for these keys inside the {{ic|http}} block [https://nginx.org/en/docs/http/ngx_http_core_module.html#types_hash_max_size] [https://nginx.org/en/docs/http/server_names.html]: | ||
{{hc|/etc/nginx/nginx.conf| | {{hc|/etc/nginx/nginx.conf| | ||
Line 816: | Line 840: | ||
=== Cannot assign requested address === | === Cannot assign requested address === | ||
The full error from {{ic| | The full error from {{ic|nginx.service}} [[unit status]] is | ||
[emerg] 460#460: bind() to A.B.C.D:443 failed (99: Cannot assign requested address) | [emerg] 460#460: bind() to A.B.C.D:443 failed (99: Cannot assign requested address) | ||
Even | Even if your nginx unit-file is configured to run after {{ic|network.target}} with systemd, nginx may attempt to listen at an address that is configured but not added to any interface yet. Verify that this the case by manually running [[start]] for nginx (thereby showing the IP address is configured properly). Configuring nginx to listen to any address will resolve this issue. Now if your use case requires listening to a specific address, one possible solution is to reconfigure systemd. | ||
To start nginx after all configured network devices are up and assigned an IP address, append {{ic|network-online.target}} to {{ic|After | To start nginx after all configured network devices are up and assigned an IP address, append {{ic|network-online.target}} to {{ic|After{{=}}}} within {{ic|nginx.service}} and [[start/enable]] {{ic|systemd-networkd-wait-online.service}}. | ||
== See also == | == See also == | ||
* [[WebDAV# | * [[WebDAV#nginx|WebDAV with nginx]] | ||
* [https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/ nginx configuration pitfalls] | * [https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/ nginx configuration pitfalls] | ||
* [https://calomel.org/nginx.html Very good in-depth 2014 look at nginx security and Reverse Proxying] | * [https://calomel.org/nginx.html Very good in-depth 2014 look at nginx security and Reverse Proxying] | ||
* [ | * [https://www.tecmint.com/install-nginx-php-mysql-with-mariadb-engine-and-phpmyadmin-in-arch-linux/ Installing LEMP (nginx, PHP, MySQL with MariaDB engine and PhpMyAdmin) in Arch Linux] | ||
* [[Let’s Encrypt|Using SSL certificates generated with Let's Encrypt]] | * [[Let’s Encrypt|Using SSL certificates generated with Let's Encrypt]] |
Latest revision as of 00:02, 3 March 2024
nginx (pronounced "engine X"), is a free, open-source, high-performance HTTP web server and reverse proxy, as well as an IMAP/POP3 proxy server, written by Igor Sysoev in 2005. nginx is well known for its stability, rich feature set, simple configuration, and low resource consumption.
This article describes how to set up nginx and how to optionally integrate it with PHP via #FastCGI.
Installation
Install one of the following packages:
- nginx-mainline - mainline branch: new features, updates, bugfixes.
- nginx - stable branch: major bugfixes only.
- angieAUR - fork and drop-in replacement for nginx with more features.
Using the mainline branch is recommended. The main reason to use the stable branch is that you are concerned about possible impacts of new features, such as incompatibility with third-party modules or the inadvertent introduction of bugs in new features.
For a chroot-based installation for additional security, see #Installation in a chroot.
Running
Start/enable nginx.service
or angie.service
if you use Angie.
The default page served at http://127.0.0.1 is /usr/share/nginx/html/index.html
.
Configuration
First steps with nginx are described in the Beginner’s Guide. You can modify the configuration by editing the files in /etc/nginx/
The main configuration file is located at /etc/nginx/nginx.conf
.
More details and examples can be found in https://wiki.nginx.org/Configuration and the official documentation.
The examples below cover the most common use cases. It is assumed that you use the default location for documents (/usr/share/nginx/html
). If that is not the case, substitute your path instead.
Configuration example
/etc/nginx/nginx.conf
user http; worker_processes auto; worker_cpu_affinity auto; events { multi_accept on; worker_connections 1024; } http { charset utf-8; sendfile on; tcp_nopush on; tcp_nodelay on; server_tokens off; log_not_found off; types_hash_max_size 4096; client_max_body_size 16M; # MIME include mime.types; default_type application/octet-stream; # logging access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log warn; # load configs include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; }
General configuration
Processes and connections
You should choose a fitting value for worker_processes
. This setting ultimately defines how many connections nginx will accept and how many processors it will be able to make use of. Generally, making it the number of hardware threads in your system is a good start. Alternatively, worker_processes
accepts the auto
value since versions 1.3.8 and 1.2.5, which will try to autodetect the optimal value (source).
The maximum connections nginx will accept is given by max_clients = worker_processes * worker_connections
.
Running under different user
By default, nginx runs the master process as root
and worker processes as user http
. To run worker processes as another user, change the user
directive in nginx.conf
:
/etc/nginx/nginx.conf
user user [group];
If the group is omitted, a group whose name equals that of user is used.
root
using systemd. See #Running unprivileged using systemd and #Running user service using systemd.Server blocks
It is possible to serve multiple domains using server
blocks. These are comparable to "VirtualHosts" in Apache HTTP Server. Also see the upstream examples.
In the example below the server listens for incoming connections on IPv4 and IPv6 ports 80 for two domains, domainname1.tld
and domainname2.tld
:
/etc/nginx/nginx.conf
... server { listen 80; listen [::]:80; server_name domainname1.tld; root /usr/share/nginx/domainname1.tld/html; location / { index index.php index.html index.htm; } } server { listen 80; listen [::]:80; server_name domainname2.tld; root /usr/share/nginx/domainname2.tld/html; ... }
Restart nginx.service
to apply any changes.
Managing server entries
It is possible to put different server
blocks in different files. This allows you to easily enable or disable certain sites.
For using the sites-enabled
and sites-available
approach, create the following directories:
# mkdir /etc/nginx/sites-available # mkdir /etc/nginx/sites-enabled
Create a file inside the sites-available
directory that contains one or more server blocks:
/etc/nginx/sites-available/example.conf
server { listen 443 ssl; listen [::]:443 ssl; http2 on; ... }
Append include sites-enabled/*;
to the end of the http
block:
/etc/nginx/nginx.conf
http { ... include sites-enabled/*; }
To enable a site, simply create a symlink:
# ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/example.conf
To disable a site, unlink the active symlink:
# unlink /etc/nginx/sites-enabled/example.conf
Reload/restart nginx.service
to enable changes to the site's configuration.
TLS
OpenSSL provides TLS support and is installed by default on Arch installations.
- You may want to read the ngx_http_ssl_module documentation first before configuring SSL.
- Let’s Encrypt is a free, automated, and open certificate authority. A plugin is available to request valid SSL certificates straight from the command line and automatic configuration.
- Mozilla has a useful TLS article as well as an automated tool to help create a more secure configuration.
Create a private key and self-signed certificate. This is adequate for most installations that do not require a CSR:
# mkdir /etc/nginx/ssl # cd /etc/nginx/ssl # openssl req -new -x509 -nodes -newkey rsa:4096 -keyout server.key -out server.crt -days 1095 # chmod 400 server.key # chmod 444 server.crt
-days
switch is optional and RSA keysize can be as low as 2048 (default).If you need to create a CSR, follow these instructions instead of the above:
# mkdir /etc/nginx/ssl # cd /etc/nginx/ssl # openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out server.key # chmod 400 server.key # openssl req -new -sha256 -key server.key -out server.csr # openssl x509 -req -days 1095 -in server.csr -signkey server.key -out server.crt
A starting point for a /etc/nginx/nginx.conf
with TLS is Mozilla's SSL Configuration Generator.
Restart nginx.service
to apply any changes.
Per-user directories
To replicate Apache-style ~user
URLs to users' ~/public_html
directories, try the following. (Note: if both rules are used, below, the more-specific PHP rule must come first.)
/etc/nginx/nginx.conf
... server { ... # PHP in user directories, e.g. http://example.com/~user/test.php location ~ ^/~(.+?)(/.+\.php)$ { alias /home/$1/public_html$2; fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; include fastcgi.conf; } # User directories, e.g. http://example.com/~user/ location ~ ^/~(.+?)(/.*)?$ { alias /home/$1/public_html$2; index index.html index.htm; autoindex on; } ... } ...
See #PHP implementation for more information on PHP configuration with nginx
.
Restart nginx.service
to enable the new configuration.
FastCGI
FastCGI, also FCGI, is a protocol for interfacing interactive programs with a web server. FastCGI is a variation on the earlier Common Gateway Interface (CGI); FastCGI's main aim is to reduce the overhead associated with interfacing the web server and CGI programs, allowing servers to handle more web page requests at once.
FastCGI technology is introduced into nginx to work with many external tools, e.g. Perl, PHP and Python.
PHP implementation
PHP-FPM is the recommended solution to run as FastCGI server for PHP.
Install php-fpm and make sure PHP has been installed and configured correctly. The main configuration file of PHP-FPM is /etc/php/php-fpm.conf
. For basic usage the default configuration should be sufficient.
Finally, start/enable php-fpm.service
.
You can also use php-legacy-fpm instead, see #Using php-legacy.
- If you run nginx under a different user, make sure that the PHP-FPM socket file is accessible by this user, or use a TCP socket.
- If you run nginx in chrooted environment (chroot is
/srv/nginx-jail
, web pages are served at/srv/nginx-jail/www
), you must modify the file/etc/php/php-fpm.conf
to include thechroot = /srv/nginx-jail
andlisten = /srv/nginx-jail/run/php-fpm/php-fpm.sock
directives within the pool section (a default one is[www]
). Create the directory for the socket file, if missing. Moreover, for modules that are dynamically linked to dependencies, you will need to copy those dependencies to the chroot (e.g. for php-imagick, you will need to copy the ImageMagick libraries to the chroot, but not imagick.so itself).
nginx configuration
When serving a PHP web-application, a location
for PHP-FPM should to be included in each server block [2], e.g.:
/etc/nginx/sites-available/example.conf
server { root /usr/share/nginx/html; location / { index index.html index.htm index.php; } location ~ \.php$ { # 404 try_files $fastcgi_script_name =404; # default fastcgi_params include fastcgi_params; # fastcgi settings fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_buffers 8 16k; fastcgi_buffer_size 32k; # fastcgi params fastcgi_param DOCUMENT_ROOT $realpath_root; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; #fastcgi_param PHP_ADMIN_VALUE "open_basedir=$base/:/usr/lib/php/:/tmp/"; } }
If it is needed to process other extensions with PHP (e.g. .html and .htm):
location ~ [^/]\.(php|html|htm)(/|$) { ... }
Non .php extension processing in PHP-FPM should also be explicitly added in /etc/php/php-fpm.d/www.conf
:
security.limit_extensions = .php .html .htm
fastcgi_pass
argument, as it must be the TCP or Unix socket defined by the chosen FastCGI server in its configuration file. The default (Unix) socket for php-fpm
is:
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
You might use the common TCP socket, not default,
fastcgi_pass 127.0.0.1:9000;Unix domain sockets should however be faster.
server
blocks using the same PHP-FPM configuration, a php_fastcgi.conf
configuration file may be used to ease management:
/etc/nginx/php_fastcgi.conf
location ~ \.php$ { # 404 try_files $fastcgi_script_name =404; # default fastcgi_params include fastcgi_params; # fastcgi settings ... }
To enable PHP support for a particular server, simply include the php_fastcgi.conf
configuration file:
/etc/nginx/sites-available/example.conf
server { server_name example.com; ... include /etc/nginx/php_fastcgi.conf; }
Test configuration
You need to restart the php-fpm.service
and nginx.service
units if the configuration has been changed in order to apply changes.
To test the FastCGI implementation, create a new PHP file inside the root
folder containing:
<?php phpinfo(); ?>
Navigate this file inside a browser and you should see the informational page with the current PHP configuration.
CGI implementation
This implementation is needed for CGI applications.
fcgiwrap
Install fcgiwrap. The configuration is done by editing fcgiwrap.socket
. Enable and start fcgiwrap.socket
.
Multiple worker threads
If you want to spawn multiple worker threads, it is recommended that you use multiwatchAUR, which will take care of restarting crashed children. You will need to use spawn-fcgi
to create the Unix socket, as multiwatch seems unable to handle the systemd-created socket, even though fcgiwrap itself does not have any trouble if invoked directly in the unit file.
Override the unit fcgiwrap.service
(and the fcgiwrap.socket
unit, if present), and modify the ExecStart
line to suit your needs. Here is a unit file that uses multiwatchAUR. Make sure fcgiwrap.socket
is not started or enabled, because it will conflict with this unit:
/etc/systemd/system/fcgiwrap.service
[Unit] Description=Simple CGI Server After=nss-user-lookup.target [Service] ExecStartPre=/bin/rm -f /run/fcgiwrap.socket ExecStart=/usr/bin/spawn-fcgi -u http -g http -s /run/fcgiwrap.sock -n -- /usr/bin/multiwatch -f 10 -- /usr/sbin/fcgiwrap ExecStartPost=/usr/bin/chmod 660 /run/fcgiwrap.sock PrivateTmp=true Restart=on-failure [Install] WantedBy=multi-user.target
Tweak -f 10
to change the number of children that are spawned.
ExecStartPost
line is required because of strange behaviour I'm seeing when I use the -M 660
option for spawn-fcgi
. The wrong mode is set. This may be a bug?nginx configuration
In /etc/nginx
, copy the file fastcgi_params
to fcgiwrap_params
. In fcgiwrap_params
, comment or delete the lines which set SCRIPT_NAME
and DOCUMENT_ROOT
.
Inside each server
block serving a CGI web application should appear a location
block similar to:
location ~ \.cgi$ { include fcgiwrap_params; fastcgi_param DOCUMENT_ROOT /srv/www/cgi-bin/; fastcgi_param SCRIPT_NAME myscript.cgi; fastcgi_pass unix:/run/fcgiwrap.sock; }
The default socket file for fcgiwrap
is /run/fcgiwrap.sock
.
Using fastcgi_param SCRIPT_FILENAME /srv/www/cgi-bin/myscript.cgi
is a shortcut alternative to setting DOCUMENT_ROOT
and SCRIPT_NAME
. If you use SCRIPT_FILENAME
, you also will not need to copy fastcgi_params
to fcgiwrap_params
and comment out the DOCUMENT_ROOT
and SCRIPT_NAME
lines.
If you keep getting a 502 - bad Gateway
error, you should check if your CGI-application first announces the mime-type of the following content. For HTML this needs to be Content-type: text/html
.
If you get 403 errors, make sure that the CGI executable is readable and executable by the http
user and that every parent folder is readable by the http
user.
Installation in a chroot
Installing nginx in a chroot adds an additional layer of security. For maximum security the chroot should include only the files needed to run the nginx server and all files should have the most restrictive permissions possible, e.g., as much as possible should be owned by root, directories such as /usr/bin
should be unreadable and unwritable, etc.
Arch comes with an http
user and group by default which will run the server. The chroot will be in /srv/http
.
A PERL script to create this jail is available at jail.pl gist. You can either use that or follow the instructions in this article. It expects to be run as root. You will need to uncomment a line before it makes any changes.
Create necessary devices
nginx needs /dev/null
, /dev/random
, and /dev/urandom
. To install these in the chroot create the /dev/
directory and add the devices with mknod. Avoid mounting all of /dev/
to ensure that, even if the chroot is compromised, an attacker must break out of the chroot to access important devices like /dev/sda1
.
- Be sure that
/srv/http
is mounted without the nodev option - See mknod(1) and
ls -l /dev/{null,random,urandom}
to better understand the mknod options.
# export JAIL=/srv/http # mkdir $JAIL/dev # mknod -m 0666 $JAIL/dev/null c 1 3 # mknod -m 0666 $JAIL/dev/random c 1 8 # mknod -m 0444 $JAIL/dev/urandom c 1 9
Create necessary directories
nginx requires a bunch of files to run properly. Before copying them over, create the folders to store them. This assumes your nginx document root will be /srv/http/www
.
# mkdir -p $JAIL/etc/nginx/logs # mkdir -p $JAIL/usr/{lib,bin} # mkdir -p $JAIL/usr/share/nginx # mkdir -p $JAIL/var/{log,lib}/nginx # mkdir -p $JAIL/www/cgi-bin # mkdir -p $JAIL/{run,tmp} # cd $JAIL; ln -s usr/lib lib # cd $JAIL; ln -s usr/lib lib64 # cd $JAIL/usr; ln -s lib lib64
Then mount $JAIL/tmp
and $JAIL/run
as tmpfs's. The size should be limited to ensure an attacker cannot eat all the RAM.
# mount -t tmpfs none $JAIL/run -o 'noexec,size=1M' # mount -t tmpfs none $JAIL/tmp -o 'noexec,size=100M'
In order to preserve the mounts across reboots, the following entries should be added to /etc/fstab
:
/etc/fstab
tmpfs /srv/http/run tmpfs rw,noexec,relatime,size=1024k 0 0 tmpfs /srv/http/tmp tmpfs rw,noexec,relatime,size=102400k 0 0
Populate the chroot
First copy over the easy files.
# cp -r /usr/share/nginx/* $JAIL/usr/share/nginx # cp -r /usr/share/nginx/html/* $JAIL/www # cp /usr/bin/nginx $JAIL/usr/bin/ # cp -r /var/lib/nginx $JAIL/var/lib/nginx
Now copy over required libraries. Use ldd to list them and then copy them all to the correct location. Copying is preferred over hardlinks to ensure that even if an attacker gains write access to the files they cannot destroy or alter the true system files.
$ ldd /usr/bin/nginx
linux-vdso.so.1 (0x00007fffc41fe000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57ec3e8000) libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f57ec1b1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f57ebead000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f57ebbaf000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f57eb94c000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f57eb6e0000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f57eb2d6000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f57eb0d2000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f57eaebc000) libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0x00007f57eac8d000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57eaa77000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f57ea6ca000) /lib64/ld-linux-x86-64.so.2 (0x00007f57ec604000)
For files residing in /usr/lib
you may try the following one-liner:
# cp $(ldd /usr/bin/nginx | grep /usr/lib/ | sed -sre 's/(.+)(\/usr\/lib\/\S+).+/\2/g') $JAIL/usr/lib
And the following for ld-linux-x86-64.so
:
# cp /lib64/ld-linux-x86-64.so.2 $JAIL/lib
linux-vdso.so
: it is not a real library and does not exist in /usr/lib
.Copy over some miscellaneous but necessary libraries and system files.
# cp /usr/lib/libnss_* $JAIL/usr/lib # cp -rfvL /etc/{services,localtime,nsswitch.conf,nscd.conf,protocols,hosts,ld.so.cache,ld.so.conf,resolv.conf,host.conf,nginx} $JAIL/etc
Create restricted user/group files for the chroot. This way only the users needed for the chroot to function exist as far as the chroot knows, and none of the system users/groups are leaked to attackers should they gain access to the chroot.
$JAIL/etc/group
http:x:33: nobody:x:99:
$JAIL/etc/passwd
http:x:33:33:http:/:/bin/false nobody:x:99:99:nobody:/:/bin/false
$JAIL/etc/shadow
http:x:14871:::::: nobody:x:14871::::::
$JAIL/etc/gshadow
http::: nobody:::
# touch $JAIL/etc/shells # touch $JAIL/run/nginx.pid
Finally, make set very restrictive permissions. As much as possible should be owned by root and set unwritable.
# chown -R root:root $JAIL/ # chown -R http:http $JAIL/www # chown -R http:http $JAIL/etc/nginx # chown -R http:http $JAIL/var/{log,lib}/nginx # chown http:http $JAIL/run/nginx.pid # find $JAIL/ -gid 0 -uid 0 -type d -print | xargs chmod -rw # find $JAIL/ -gid 0 -uid 0 -type d -print | xargs chmod +x # find $JAIL/etc -gid 0 -uid 0 -type f -print | xargs chmod -x # find $JAIL/usr/bin -type f -print | xargs chmod ug+rx # find $JAIL/ -group http -user http -print | xargs chmod o-rwx # chmod +rw $JAIL/tmp # chmod +rw $JAIL/run
If your server will bind port 80 (or any other port in range [1-1023]), give the chrooted executable permission to bind these ports without root.
# setcap 'cap_net_bind_service=+ep' $JAIL/usr/bin/nginx
Modify nginx.service to start chroot
Override the unit nginx.service
. Upgrading nginx will not modify your custom .service file.
The systemd unit must be changed to start up nginx in the chroot, as the http user, and store the PID file in the chroot.
/etc/systemd/system/nginx.service
[Unit] Description=A high performance web server and a reverse proxy server After=network.target [Service] Type=forking PIDFile=/srv/http/run/nginx.pid ExecStartPre=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -t -q -g 'pid /run/nginx.pid; daemon on; master_process on;' ExecStart=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' ExecReload=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' -s reload ExecStop=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid;' -s quit [Install] WantedBy=multi-user.target
You can now safely get rid of the non-chrooted nginx installation.
# pacman -Rsc nginx
If you do not remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where /proc/PID/root
symlinks to. It should link to /srv/http
instead of /
.
# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done
Tips and tricks
Running unprivileged using systemd
Use a drop-in unit file for nginx.service
and set the User
and optionally Group
options under [Service]
:
/etc/systemd/system/nginx.service.d/user.conf
[Service] User=user Group=group
We can harden the service against ever elevating privileges:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... NoNewPrivileges=yes
Then we need to ensure that user
has access to everything it needs. Follow the subsections below and then start nginx.
Port
Linux does not permit non-root
processes to bind to ports below 1024 by default. A port above 1024 can be used:
/etc/nginx/nginx.conf
server { listen 8080; }
Or you may grant the nginx process the CAP_NET_BIND_SERVICE capability which allows it to bind to ports below 1024:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... CapabilityBoundingSet= CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities= AmbientCapabilities=CAP_NET_BIND_SERVICE
Alternatively, you can use systemd socket activation. In this case, systemd will listen on the ports and, when a connection is made, spawn nginx passing the socket as a file descriptor. This means nginx requires no special capabilities as the socket already exists when it is started. This relies on an internal environment variable that nginx uses for passing sockets [3] and is therefore not officially supported. Instead of setting CapabilityBoundingSet
and AmbientCapabilities
, edit the service override to set the NGINX
environment variable to tell nginx which file descriptors the sockets will be passed as:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... Environment=NGINX=3:4;
There will be one socket per listening port starting at file descriptor 3, so in this example we are telling nginx to expect two sockets. Now create a nginx.socket
unit specifying what ports to listen on:
/etc/systemd/system/nginx.socket
[Socket] ListenStream=0.0.0.0:80 ListenStream=0.0.0.0:443 After=network.target Requires=network.target [Install] WantedBy=sockets.target
The sockets will be passed in the order defined in this unit, so port 80 will be file descriptor 3 and port 443 will be file descriptor 4. If you previously enabled or started the service, you should now stop it, and enable nginx.socket
instead. When your system starts, nginx will not be running, but will be started when you access the website in a browser. With this you can harden the service further; for example, in many cases you can now set PrivateNetwork=True
in the service file, blocking nginx from the external network, since the socket created by systemd is sufficient to serve the website over. Note that this will print a warning in the logs of the nginx service: 2020/08/29 19:33:20 [notice] 254#254: using inherited sockets from "3:4;"
PID file
nginx is compiled to use /run/nginx.pid
by default, which user cannot write to. We can create a directory that user can write to and place the PID file there. This can for example be done with RuntimeDirectory
(systemd.exec(5)).
Edit nginx.service
to configure the PID file:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... RuntimeDirectory=nginx PIDFile=/run/nginx/nginx.pid ExecStart= ExecStart=/usr/bin/nginx -g 'pid /run/nginx/nginx.pid; error_log stderr;' ExecReload= ExecReload=/usr/bin/nginx -s reload -g 'pid /run/nginx/nginx.pid; error_log stderr;'
/var/lib/nginx
nginx is compiled to store temp files in /var/lib/nginx
by default.
$ nginx -V
You can give user write access to this directory by for example using StateDirectory
(systemd.exec(5)):
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... StateDirectory=nginx
/var/log/nginx
nginx is compiled to store access logs in /var/log/nginx
by default.
You can give user write access to this directory by for example using LogsDirectory
(systemd.exec(5)):
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... LogsDirectory=nginx
Running user service using systemd
If you want to run a server instance fully controlled and configurable by unprivileged user, consider using nginx-user-serviceAUR.
Alternative script for systemd
On pure systemd you can get advantages of chroot + systemd. [4] Based on set user group and pid with:
/etc/nginx/nginx.conf
user http; pid /run/nginx.pid;
the absolute path of the file is /srv/http/etc/nginx/nginx.conf
.
/etc/systemd/system/nginx.service
[Unit] Description=nginx (Chroot) After=network.target [Service] Type=forking PIDFile=/srv/http/run/nginx.pid RootDirectory=/srv/http ExecStartPre=/usr/bin/nginx -t -c /etc/nginx/nginx.conf ExecStart=/usr/bin/nginx -c /etc/nginx/nginx.conf ExecReload=/usr/bin/nginx -c /etc/nginx/nginx.conf -s reload ExecStop=/usr/bin/nginx -c /etc/nginx/nginx.conf -s stop [Install] WantedBy=multi-user.target
It is not necessary to set the default location, nginx loads at default -c /etc/nginx/nginx.conf
, but it is a good idea.
Alternatively you can run only ExecStart
as chroot with parameter RootDirectoryStartOnly
set as yes
(see systemd.service(5)) or start it before mount point as effective or a systemd path (see systemd.path(5)) is available.
/etc/systemd/system/nginx.path
[Unit] Description=nginx (Chroot) path [Path] PathExists=/srv/http/site/Public_html [Install] WantedBy=default.target
Enable the created nginx.path
and change the WantedBy=default.target
to WantedBy=nginx.path
in /etc/systemd/system/nginx.service
.
The PIDFile
in unit file allows systemd to monitor process (absolute path required). If it is undesired, you can change to default one-shot type, and delete the reference from the unit file.
Nginx beautifier
nginxbeautifierAUR is a commandline tool used to beautify and format nginx configuration files.
Better headers management
Nginx has a rather unintuitive header management system where headers can only be defined in one context, any other headers are ignored. To remedy this we can install the headers-more-nginx module.
Install the package nginx-mod-headers-more package. This will install the module to /usr/lib/nginx/modules
directory.
To load the module add the following to the top of your main nginx configuration file.
/etc/nginx/nginx.conf
load_module "/usr/lib/nginx/modules/ngx_http_headers_more_filter_module.so"; ...
Basic Authentication
Basic authentication requires creation of a password file. The password file can be managed using htpasswd
program provided by the apache package or using nginx_passwdAUR which provides nginx-passwd
- details available on GitHub source
Using php-legacy
Install php-legacy-fpm instead of php-fpm and make sure PHP has been installed and configured correctly.
The main configuration file of PHP-LEGACY-FPM is /etc/php-legacy/php-fpm.conf
. For basic usage the default configuration should be sufficient.
The Unix socket for the fastcgi_pass
argument also needs to be adjusted, usually it is:
fastcgi_pass unix:/run/php-fpm-legacy/php-fpm.sock;
Then start/enable php-legacy-fpm.service
.
Troubleshooting
Configuration validation
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
This is because the FastCGI server has not been started, or the socket used has wrong permissions.
Try out this answer to fix the 502 error.
In Arch Linux, the configuration file mentioned in above link is /etc/php/php-fpm.conf
.
Error: No input file specified
1. Verify that variable open_basedir
in /etc/php/php.ini
contains the correct path specified as root
argument in nginx.conf
(usually /usr/share/nginx/
). When using PHP-FPM as FastCGI server for PHP, you may add fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root/:/tmp/:/proc/";
in the location
block which aims for processing PHP file in nginx.conf
.
2. Another occasion is that, wrong root
argument in the location ~ \.php$
section in nginx.conf
. Make sure the root
points to the same directory as it in location /
in the same server. Or you may just set root as global, do not define it in any location section.
3. Check permissions: e.g. http
for user/group, 755
for directories and 644
for files. Remember the entire path to the html
directory should have the correct permissions. See File permissions and attributes#Bulk chmod to bulk modify a directory tree.
4. You do not have the SCRIPT_FILENAME
containing the full path to your scripts. If the configuration of nginx (fastcgi_param SCRIPT_FILENAME
) is correct, this kind of error means PHP failed to load the requested script. Usually it is simply a permissions issue, you can just run php-cgi as root:
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi
or you should create a group and user to start the php-cgi:
# groupadd www # useradd -g www www # chmod +w /srv/www/nginx/html # chown -R www:www /srv/www/nginx/html # spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi
5. If you are running php-fpm with chrooted nginx ensure chroot
is set correctly within /etc/php-fpm/php-fpm.d/www.conf
(or /etc/php-fpm/php-fpm.conf
if working on older version)
Warning: Could not build optimal types_hash
When starting the nginx.service
, the process might log the message:
[warn] 18872#18872: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
To fix this warning, increase the values for these keys inside the http
block [5] [6]:
/etc/nginx/nginx.conf
http { types_hash_max_size 4096; server_names_hash_bucket_size 128; ... }
Cannot assign requested address
The full error from nginx.service
unit status is
[emerg] 460#460: bind() to A.B.C.D:443 failed (99: Cannot assign requested address)
Even if your nginx unit-file is configured to run after network.target
with systemd, nginx may attempt to listen at an address that is configured but not added to any interface yet. Verify that this the case by manually running start for nginx (thereby showing the IP address is configured properly). Configuring nginx to listen to any address will resolve this issue. Now if your use case requires listening to a specific address, one possible solution is to reconfigure systemd.
To start nginx after all configured network devices are up and assigned an IP address, append network-online.target
to After=
within nginx.service
and start/enable systemd-networkd-wait-online.service
.