Nginx выдает ошибку 404 - Исправление ошибок и поиск оптимальных решений проблем

Веб-серверы Nginx и Apache мало похожи друг на друга, и их отличия касаются не только особенностей подключения пользователей, но и обработки URL на сервере. Очень часто новые пользователи Nginx получают ошибку 404 для URL, которые, по сути, должны были бы работать.

В этой статье рассмотрим, почему возникает ошибка «404 not found Nginx», а также способы её устранения и отладки.Мы не будем разбираться с ситуацией, когда файла действительно нет на сервере — это решение, не требующее пояснений. Мы рассмотрим проблему обработки location в Nginx.

Давайте сначала разберёмся, как обрабатываются URL в Nginx. Когда веб-сервер определил, к какому блоку server (сайту) нужно передать запрос пользователя, просматриваются все префиксные блоки location и выбирается тот, который подходит лучше всего. Например, рассмотрим стандартную конфигурацию для WordPress. Здесь префиксные location отмечены зелёным, а с регулярным выражением — оранжевым:

location / {
index index.html index.php;
}
location /favicon.ico {
access_log off;
}
location ~* .(gif|jpg|png)$ {
expires 30d;
}
location ~ .php$ {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}

Префиксные локейшены всегда начинаются с символа /. Регулярные же содержат символы регулярных выражений: ~ $ ^ * и так далее. Если пользователь запрашивает favicon.ico, то будет выбран второй location, так как он лучше всего соответствует запросу, при любом другом запросе будет выбран location /, так как он соответствует всем запросам, а других префиксных location у нас нет. Это просто, а дальше начинается магия. После того, как был найден нужный location, Nginx начинает проверять все регулярные выражения в порядке их следования в конфигурационном файле.

При первом же совпадении Nginx останавливает поиск и передаёт управление этому location. Или, если совпадений не было найдено, используется ранее обнаруженный префиксный location. Например, если запрос заканчивается на .php, то первый location будет проигнорирован, а управление передастся четвёртому (~ .php$)

Таким образом, любое неверно составленное регулярное выражение в любой части конфигурационного файла может полностью всё сломать. Поэтому разработчики рекомендуют по минимум использовать регулярные выражения. Что касается вложенных location, то обрабатываются они так же как и основные, только уже после передачи управления в нужный location. Путём чтения конфигурационного файла понять, какой location вызывает 404 сложно, поэтому, чтобы исправить ошибку, нам понадобиться режим отладки Nginx.

Как включить режим отладки Nginx?

Сначала нам необходимо установить версию Nginx с поддержкой отладки. Чтобы проверить, поддерживает ли ваша текущая версия этот режим, наберите:

nginx -V

В выводе должна быть строчка «—with-debug». Если её нет, значит отладка не поддерживается, и надо установить версию с поддержкой. В CentOS такой пакет называется nginx-debug. Для его установки наберите:

sudo yum install nginx-debug

Теперь появился ещё один исполняемый файл, и он собран уже с поддержкой отладки:

nginx-debug -V

Откройте конфигурационный файл вашего сайта или глобальный конфигурационный файл, если вы не задавали настройки логов отдельно для каждого сайта, и в конце стоки error_log замените error на debug:

error_log /var/log/nginx/domains/test.losst.pro.error.log debug

Останавливаем обычную версию и запускаем версию с отладкой:

systemctl stop nginx
systemctl start nginx-debug

Как исправить «404 Not Found Nginx»?

1. Регулярные выражения

Как я уже сказал выше, самой частой проблемой, которая вызывает 404, являются регулярные выражения. Смотрим, что происходит в лог файле:

tail -f /var/log/nginx/domains/test.losst.pro.error.log

Видим, что серверу пришёл запрос /vstats. Дальше он проверяет location: /, /robots.txt, /vatsts/, /site-control/. Здесь уже можем понять, в чём проблема — промазали на один слеш. Дальше проверяются все регулярные выражения, и, так как в них ничего найдено не было, выбирается location /.

Далее директива try_files пытается найти файл /vstats, не находит и ищет index.php, который, в свою очередь, возвращает 404.

Если мы наберём, то что ожидает видеть Nginx — /vstats/, то откроется наша страница статистики.

Если мы добавим к конфигурационному файлу ещё один location с регулярным выражением, например:

location ~* { try_files $uri $uri/ =404; }

То абсолютно все запросы будут обрабатываться именно этим регулярным выражением и, естественно, что ничего работать не будет. Видим, что приходит запрос /vstats/:

Он совпадает с префиксным location, но потом Nginx видит наше регулярное выражение и передаёт управление ему.

Поэтому будьте очень осторожны с регулярными выражениями, если они вам нужны, то размещайте их только внутри префиксных location, чтобы ограничить их область действия этим location, иначе может возникнуть ошибка 404 nginx.

2. Недостаточно памяти

Если php-скрипту не хватило оперативной памяти для выполнения, и его процесс был убит операционной системой, то Nginx тоже может вернуть ошибку 404. Такое поведение вы будете наблюдать, когда скрипт очень долго выполняется, а потом появляется «404 Not Found» или страница ошибки вашего движка. Обычно эта неисправность тоже видна в отладочном логе.

Решить такую проблему можно, освободив память на сервере, часто такое может возникать из-за утечек памяти в php, когда процессы php-fpm занимают почти всю память на сервере. Поэтому перезапуск php-fpm решает проблему:

systemctl restart php-fpm

Чтобы избежать этой проблемы в будущем, можно настроить автоматический перезапуск процессов после обработки определённого количества запросов. Например каждые 200 запросов:

vi /etc/php-fpm.d/www.conf

pm.max_requests = 200

3. Не найден index

Если вы запрашиваете URL вида /vstats/, но в настройках Nginx не указан файл index, который нужно использовать для этой ссылки, то у вас ничего не выйдет, и вы получите 404. Вы можете добавить директиву index в ваш location:

location / { index index.php index.html index.htm; }

Или сразу в server, в Nginx все location наследуют директивы, установленные в server.

4. Другие проблемы

Подобных проблем, вызывающих 404 в Nginx, может быть очень много, но все они решаемы, и всё, что нужно для их решения, есть в отладочном логе Nginx. Просто анализируйте лог и на основе этого вносите исправления.

Выводы

В этой статье мы рассмотрели основные причины, из-за которых может возникнуть ошибка 404 not found Nginx. Как видите, может быть много проблем, но всё достаточно просто решается. А с какими проблемами, вызывающими эту ошибку, вы сталкивались? Как их решали? Напишите в комментариях!

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Источник

Содержание

Ошибка 404 not found Nginx
Почему возникает ошибка 404 в Nginx
Как включить режим отладки Nginx?
Как исправить «404 Not Found Nginx»?
1. Регулярные выражения
2. Недостаточно памяти
3. Не найден index
4. Другие проблемы
Выводы
Module ngx_http_core_module
Directives
Embedded Variables

Ошибка 404 not found Nginx

Почему возникает ошибка 404 в Nginx

location / <
index index.html index.php;
>
location /favicon.ico <
access_log off;
>
location

* .(gif|jpg|png)$ <
expires 30d;
>
location

.php$ <
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
>

Префиксные локейшены всегда начинаются с символа /. Регулярные же содержат символы регулярных выражений:

$ ^ * и так далее. Если пользователь запрашивает favicon.ico, то будет выбран второй location, так как он лучше всего соответствует запросу, при любом другом запросе будет выбран location /, так как он соответствует всем запросам, а других префиксных location у нас нет. Это просто, а дальше начинается магия. После того, как был найден нужный location, Nginx начинает проверять все регулярные выражения в порядке их следования в конфигурационном файле.

Как включить режим отладки Nginx?

sudo yum install nginx-debug

Теперь появился ещё один исполняемый файл, и он собран уже с поддержкой отладки:

error_log /var/log/nginx/domains/test.losst.pro.error.log debug

Останавливаем обычную версию и запускаем версию с отладкой:

systemctl stop nginx
systemctl start nginx-debug

Как исправить «404 Not Found Nginx»?

1. Регулярные выражения

tail -f /var/log/nginx/domains/test.losst.pro.error.log

Далее директива try_files пытается найти файл /vstats, не находит и ищет index.php, который, в свою очередь, возвращает 404.

Если мы наберём, то что ожидает видеть Nginx — /vstats/, то откроется наша страница статистики.

Если мы добавим к конфигурационному файлу ещё один location с регулярным выражением, например:

Он совпадает с префиксным location, но потом Nginx видит наше регулярное выражение и передаёт управление ему.

2. Недостаточно памяти

systemctl restart php-fpm

3. Не найден index

location / <
index index.php index.html index.htm;
>

Или сразу в server, в Nginx все location наследуют директивы, установленные в server.

4. Другие проблемы

Выводы

Источник

Module ngx_http_core_module

Directives

Default:
Syntax:	absolute_redirect on \| off ;
Context:	http , server , location

This directive appeared in version 1.11.8.

If disabled, redirects issued by nginx will be relative.

Default:
Syntax:	aio on \| off \| threads [ = pool ];
Context:	http , server , location

This directive appeared in version 0.8.11.

Enables or disables the use of asynchronous file I/O (AIO) on FreeBSD and Linux:

On FreeBSD, AIO can be used starting from FreeBSD 4.3. Prior to FreeBSD 11.0, AIO can either be linked statically into a kernel:

or loaded dynamically as a kernel loadable module:

On Linux, AIO can be used starting from kernel version 2.6.22. Also, it is necessary to enable directio, or otherwise reading will be blocking:

On Linux, directio can only be used for reading blocks that are aligned on 512-byte boundaries (or 4K for XFS). File’s unaligned end is read in blocking mode. The same holds true for byte range requests and for FLV requests not from the beginning of a file: reading of unaligned data at the beginning and end of a file will be blocking.

When both AIO and sendfile are enabled on Linux, AIO is used for files that are larger than or equal to the size specified in the directio directive, while sendfile is used for files of smaller sizes or when directio is disabled.

Finally, files can be read and sent using multi-threading (1.7.11), without blocking a worker process:

Read and send file operations are offloaded to threads of the specified pool. If the pool name is omitted, the pool with the name “ default ” is used. The pool name can also be set with variables:

By default, multi-threading is disabled, it should be enabled with the —with-threads configuration parameter. Currently, multi-threading is compatible only with the epoll, kqueue, and eventport methods. Multi-threaded sending of files is only supported on Linux.

Syntax:	aio_write on \| off ;
Default:
Context:	http , server , location

Syntax:	alias path ;
Default:	—
Context:	location

Syntax:	auth_delay time ;
Default:
Context:	http , server , location

Syntax:	chunked_transfer_encoding on \| off ;
Default:
Context:	http , server , location

Syntax:	client_body_buffer_size size ;
Default:
Context:	http , server , location

Syntax:	client_body_in_file_only on \| clean \| off ;
Default:
Context:	http , server , location

Syntax:	client_body_in_single_buffer on \| off ;
Default:
Context:	http , server , location

Syntax:	client_body_temp_path path [ level1 [ level2 [ level3 ]]];
Default:
Context:	http , server , location

Syntax:	client_body_timeout time ;
Default:
Context:	http , server , location

Syntax:	client_header_buffer_size size ;
Default:
Context:	http , server

Syntax:	client_header_timeout time ;
Default:
Context:	http , server

Syntax:	client_max_body_size size ;
Default:
Context:	http , server , location

Syntax:	connection_pool_size size ;
Default:
Context:	http , server

Syntax:	default_type mime-type ;
Default:
Context:	http , server , location

Syntax:	directio size \| off ;
Default:
Context:	http , server , location

Syntax:	directio_alignment size ;
Default:
Context:	http , server , location

Syntax:	disable_symlinks off ; disable_symlinks on \| if_not_owner [ from = part ];
Default:
Context:	http , server , location

Syntax:	error_page code . [ = [ response ]] uri ;
Default:	—
Context:	http , server , location , if in location

Syntax:	etag on \| off ;
Default:
Context:	http , server , location

Syntax:	http < . >
Default:	—
Context:	main

Syntax:	if_modified_since off \| exact \| before ;
Default:
Context:	http , server , location

Syntax:	ignore_invalid_headers on \| off ;
Default:
Context:	http , server

Syntax:	internal;
Default:	—
Context:	location

Syntax:	keepalive_disable none \| browser . ;
Default:
Context:	http , server , location

Syntax:	keepalive_requests number ;
Default:
Context:	http , server , location

Syntax:	keepalive_time time ;
Default:
Context:	http , server , location

Syntax:	keepalive_timeout timeout [ header_timeout ];
Default:
Context:	http , server , location

Syntax:	large_client_header_buffers number size ;
Default:
Context:	http , server

Syntax:	limit_except method . < . >
Default:	—
Context:	location

Syntax:	limit_rate rate ;
Default:
Context:	http , server , location , if in location

Syntax:	limit_rate_after size ;
Default:
Context:	http , server , location , if in location

Syntax:	lingering_close off \| on \| always ;
Default:
Context:	http , server , location

Syntax:	lingering_time time ;
Default:
Context:	http , server , location

Syntax:	lingering_timeout time ;
Default:
Context:	http , server , location

Syntax:	listen address [: port ] [ default_server ] [ ssl ] [ http2 \| spdy ] [ proxy_protocol ] [ setfib = number ] [ fastopen = number ] [ backlog = number ] [ rcvbuf = size ] [ sndbuf = size ] [ accept_filter = filter ] [ deferred ] [ bind ] [ ipv6only = on \| off ] [ reuseport ] [ so_keepalive = on \| off \|[ keepidle ]:[ keepintvl ]:[ keepcnt ]]; listen port [ default_server ] [ ssl ] [ http2 \| spdy ] [ proxy_protocol ] [ setfib = number ] [ fastopen = number ] [ backlog = number ] [ rcvbuf = size ] [ sndbuf = size ] [ accept_filter = filter ] [ deferred ] [ bind ] [ ipv6only = on \| off ] [ reuseport ] [ so_keepalive = on \| off \|[ keepidle ]:[ keepintvl ]:[ keepcnt ]]; listen unix: path [ default_server ] [ ssl ] [ http2 \| spdy ] [ proxy_protocol ] [ backlog = number ] [ rcvbuf = size ] [ sndbuf = size ] [ accept_filter = filter ] [ deferred ] [ bind ] [ so_keepalive = on \| off \|[ keepidle ]:[ keepintvl ]:[ keepcnt ]];
Default:
Context:	server

Syntax:	location [ = \|

Syntax:	log_not_found on \| off ;
Default:
Context:	http , server , location

Syntax:	log_subrequest on \| off ;
Default:
Context:	http , server , location

Syntax:	max_ranges number ;
Default:	—
Context:	http , server , location

Syntax:	merge_slashes on \| off ;
Default:
Context:	http , server

Syntax:	msie_padding on \| off ;
Default:
Context:	http , server , location

Syntax:	msie_refresh on \| off ;
Default:
Context:	http , server , location

Syntax:	open_file_cache off ; open_file_cache max = N [ inactive = time ];
Default:
Context:	http , server , location

Syntax:	open_file_cache_errors on \| off ;
Default:
Context:	http , server , location

Syntax:	open_file_cache_min_uses number ;
Default:
Context:	http , server , location

Syntax:	open_file_cache_valid time ;
Default:
Context:	http , server , location

Syntax:	output_buffers number size ;
Default:
Context:	http , server , location

Syntax:	port_in_redirect on \| off ;
Default:
Context:	http , server , location

Embedded Variables

The ngx_http_core_module module supports embedded variables with names matching the Apache Server variables. First of all, these are variables representing client request header fields, such as $http_user_agent , $http_cookie , and so on. Also there are other variables:

$arg_ name argument name in the request line $args arguments in the request line $binary_remote_addr client address in a binary form, value’s length is always 4 bytes for IPv4 addresses or 16 bytes for IPv6 addresses $body_bytes_sent number of bytes sent to a client, not counting the response header; this variable is compatible with the “ %B ” parameter of the mod_log_config Apache module $bytes_sent number of bytes sent to a client (1.3.8, 1.2.5) $connection connection serial number (1.3.8, 1.2.5) $connection_requests current number of requests made through a connection (1.3.8, 1.2.5) $connection_time connection time in seconds with a milliseconds resolution (1.19.10) $content_length “Content-Length” request header field $content_type “Content-Type” request header field $cookie_ name the name cookie $document_root root or alias directive’s value for the current request $document_uri same as $uri $host in this order of precedence: host name from the request line, or host name from the “Host” request header field, or the server name matching a request $hostname host name $http_ name arbitrary request header field; the last part of a variable name is the field name converted to lower case with dashes replaced by underscores $https “ on ” if connection operates in SSL mode, or an empty string otherwise $is_args “ ? ” if a request line has arguments, or an empty string otherwise $limit_rate setting this variable enables response rate limiting; see limit_rate $msec current time in seconds with the milliseconds resolution (1.3.9, 1.2.6) $nginx_version nginx version $pid PID of the worker process $pipe “ p ” if request was pipelined, “ . ” otherwise (1.3.12, 1.2.7) $proxy_protocol_addr client address from the PROXY protocol header (1.5.12)

The PROXY protocol must be previously enabled by setting the proxy_protocol parameter in the listen directive.

$proxy_protocol_port client port from the PROXY protocol header (1.11.0)

The PROXY protocol must be previously enabled by setting the proxy_protocol parameter in the listen directive.

$proxy_protocol_server_addr server address from the PROXY protocol header (1.17.6)

The PROXY protocol must be previously enabled by setting the proxy_protocol parameter in the listen directive.

$proxy_protocol_server_port server port from the PROXY protocol header (1.17.6)

The PROXY protocol must be previously enabled by setting the proxy_protocol parameter in the listen directive.

$proxy_protocol_tlv_ name TLV from the PROXY Protocol header (1.23.2). The name can be a TLV type name or its numeric value. In the latter case, the value is hexadecimal and should be prefixed with 0x :

The following TLV type names are supported:

alpn ( 0x01 ) — upper layer protocol used over the connection
authority ( 0x02 ) — host name value passed by the client
unique_id ( 0x05 ) — unique connection id
netns ( 0x30 ) — name of the namespace
ssl ( 0x20 ) — binary SSL TLV structure

The following SSL TLV type names are supported:

ssl_version ( 0x21 ) — SSL version used in client connection
ssl_cn ( 0x22 ) — SSL certificate Common Name
ssl_cipher ( 0x23 ) — name of the used cipher
ssl_sig_alg ( 0x24 ) — algorithm used to sign the certificate
ssl_key_alg ( 0x25 ) — public-key algorithm

Also, the following special SSL TLV type name is supported:

ssl_verify — client SSL certificate verification result, 0 if the client presented a certificate and it was successfully verified, non-zero otherwise.

The PROXY protocol must be previously enabled by setting the proxy_protocol parameter in the listen directive.

$query_string same as $args $realpath_root an absolute pathname corresponding to the root or alias directive’s value for the current request, with all symbolic links resolved to real paths $remote_addr client address $remote_port client port $remote_user user name supplied with the Basic authentication $request full original request line $request_body request body

The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer.

$request_body_file name of a temporary file with the request body

At the end of processing, the file needs to be removed. To always write the request body to a file, client_body_in_file_only needs to be enabled. When the name of a temporary file is passed in a proxied request or in a request to a FastCGI/uwsgi/SCGI server, passing the request body should be disabled by the proxy_pass_request_body off, fastcgi_pass_request_body off, uwsgi_pass_request_body off, or scgi_pass_request_body off directives, respectively.

$request_completion “ OK ” if a request has completed, or an empty string otherwise $request_filename file path for the current request, based on the root or alias directives, and the request URI $request_id unique request identifier generated from 16 random bytes, in hexadecimal (1.11.0) $request_length request length (including request line, header, and request body) (1.3.12, 1.2.7) $request_method request method, usually “ GET ” or “ POST ” $request_time request processing time in seconds with a milliseconds resolution (1.3.9, 1.2.6); time elapsed since the first bytes were read from the client $request_uri full original request URI (with arguments) $scheme request scheme, “ http ” or “ https ” $sent_http_ name arbitrary response header field; the last part of a variable name is the field name converted to lower case with dashes replaced by underscores $sent_trailer_ name arbitrary field sent at the end of the response (1.13.2); the last part of a variable name is the field name converted to lower case with dashes replaced by underscores $server_addr an address of the server which accepted a request

Computing a value of this variable usually requires one system call. To avoid a system call, the listen directives must specify addresses and use the bind parameter.

$server_name name of the server which accepted a request $server_port port of the server which accepted a request $server_protocol request protocol, usually “ HTTP/1.0 ”, “ HTTP/1.1 ”, or “HTTP/2.0” $status response status (1.3.2, 1.2.2) $tcpinfo_rtt , $tcpinfo_rttvar , $tcpinfo_snd_cwnd , $tcpinfo_rcv_space information about the client TCP connection; available on systems that support the TCP_INFO socket option $time_iso8601 local time in the ISO 8601 standard format (1.3.12, 1.2.7) $time_local local time in the Common Log Format (1.3.12, 1.2.7) $uri current URI in request, normalized

Источник

Директивы

Синтаксис:	`absolute_redirect on \| off;`
Умолчание:	absolute_redirect on;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 1.11.8.

Если запрещено, то перенаправления, выдаваемые nginx’ом, будут относительными.

См. также директивы server_name_in_redirect
и port_in_redirect.

Синтаксис:	`aio on \| off \| threads[=pool];`
Умолчание:	aio off;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 0.8.11.

Разрешает или запрещает использование файлового асинхронного ввода-вывода (AIO)
во FreeBSD и Linux:

location /video/ {
    aio            on;
    output_buffers 1 64k;
}

Во FreeBSD AIO можно использовать, начиная с FreeBSD 4.3.
До FreeBSD 11.0
AIO можно либо собрать в ядре статически:

options VFS_AIO

либо загрузить динамически через загружаемый модуль ядра:

kldload aio

В Linux AIO можно использовать только начиная с версии ядра 2.6.22.
Кроме того, необходимо также дополнительно включить
directio,
иначе чтение будет блокирующимся:

location /video/ {
    aio            on;
    directio       512;
    output_buffers 1 128k;
}

В Linux
directio
можно использовать только для чтения блоков, выравненных
на границу 512 байт (или 4К для XFS).
Невыравненный конец файла будет читаться блокированно.
То же относится к запросам с указанием диапазона запрашиваемых байт
(byte-range requests) и к запросам FLV не с начала файла: чтение
невыравненных начала и конца ответа будет блокирующимся.

При одновременном включении AIO и sendfile в Linux
для файлов, размер которых больше либо равен указанному
в директиве directio, будет использоваться AIO,
а для файлов меньшего размера
или при выключенном directio — sendfile:

location /video/ {
    sendfile       on;
    aio            on;
    directio       8m;
}

Кроме того, читать и отправлять
файлы можно в многопоточном режиме (1.7.11),
не блокируя при этом рабочий процесс:

location /video/ {
    sendfile       on;
    aio            threads;
}

Операции чтения или отправки файлов будут обрабатываться потоками из указанного
пула.
Если пул потоков не задан явно,
используется пул с именем “default”.
Имя пула может быть задано при помощи переменных:

aio threads=pool$disk;

По умолчанию поддержка многопоточности выключена, её сборку следует
разрешить с помощью конфигурационного параметра
--with-threads.
В настоящий момент многопоточность совместима только с методами
epoll,
kqueue
и
eventport.
Отправка файлов в многопоточном режиме поддерживается только на Linux.

См. также директиву sendfile.

Синтаксис:	`aio_write on \| off;`
Умолчание:	aio_write off;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 1.9.13.

При включённом aio разрешает его использование для записи файлов.
В настоящий момент это работает только при использовании
aio threads
и ограничено записью временных файлов с данными,
полученными от проксируемых серверов.

Синтаксис:	`alias путь;`
Умолчание:	—
Контекст:	`location`

Задаёт замену для указанного location’а.
Например, при такой конфигурации

location /i/ {
    alias /data/w3/images/;
}

на запрос
“/i/top.gif” будет отдан файл
/data/w3/images/top.gif.

В значении параметра путь можно использовать переменные,
кроме $document_root и $realpath_root.

Если alias используется внутри location’а, заданного
регулярным выражением, то регулярное выражение должно содержать
выделения, а сам alias — ссылки на эти выделения
(0.7.40), например:

location ~ ^/users/(.+.(?:gif|jpe?g|png))$ {
    alias /data/w3/images/$1;
}

Если location и последняя часть значения директивы совпадают:

location /images/ {
    alias /data/w3/images/;
}

то лучше воспользоваться директивой
root:

location /images/ {
    root /data/w3;
}

Синтаксис:	`auth_delay время;`
Умолчание:	auth_delay 0s;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 1.17.10.

Задерживает обработку неавторизованных запросов с кодом ответа 401
для предотвращения атак по времени в случае ограничения доступа по
паролю, по
результату подзапроса
или по JWT.

Синтаксис:	`chunked_transfer_encoding on \| off;`
Умолчание:	chunked_transfer_encoding on;
Контекст:	`http`, `server`, `location`

Позволяет запретить формат передачи данных частями (chunked transfer
encoding) в HTTP/1.1.
Это может понадобиться при использовании программ, не поддерживающих
chunked encoding, несмотря на требования стандарта.

Синтаксис:	`client_body_buffer_size размер;`
Умолчание:	client_body_buffer_size 8k\|16k;
Контекст:	`http`, `server`, `location`

Задаёт размер буфера для чтения тела запроса клиента.
Если тело запроса больше заданного буфера,
то всё тело запроса или только его часть записывается во
временный файл.
По умолчанию размер одного буфера равен двум размерам страницы.
На x86, других 32-битных платформах и x86-64 это 8K.
На других 64-битных платформах это обычно 16K.

Синтаксис:	`client_body_in_file_only on \| clean \| off;`
Умолчание:	client_body_in_file_only off;
Контекст:	`http`, `server`, `location`

Определяет, сохранять ли всё тело запроса клиента в файл.
Директиву можно использовать для отладки и при использовании переменной
$request_body_file
или метода
$r->request_body_file
модуля
ngx_http_perl_module.

При установке значения on временные файлы
по окончании обработки запроса не удаляются.

Значение clean разрешает удалять временные файлы,
оставшиеся по окончании обработки запроса.

Синтаксис:	`client_body_in_single_buffer on \| off;`
Умолчание:	client_body_in_single_buffer off;
Контекст:	`http`, `server`, `location`

Определяет, сохранять ли всё тело запроса клиента в одном буфере.
Директива рекомендуется при использовании переменной
$request_body
для уменьшения требуемого числа операций копирования.

Синтаксис:	`client_body_temp_path путь [уровень1 [уровень2 [уровень3]]];`
Умолчание:	client_body_temp_path client_body_temp;
Контекст:	`http`, `server`, `location`

Задаёт каталог для хранения временных файлов с телами запросов клиентов.
В каталоге может использоваться иерархия подкаталогов до трёх уровней.
Например, при такой конфигурации

client_body_temp_path /spool/nginx/client_temp 1 2;

путь к временному файлу будет следующего вида:

/spool/nginx/client_temp/7/45/00000123457

Синтаксис:	`client_body_timeout время;`
Умолчание:	client_body_timeout 60s;
Контекст:	`http`, `server`, `location`

Задаёт таймаут при чтении тела запроса клиента.
Таймаут устанавливается не на всю передачу тела запроса,
а только между двумя последовательными операциями чтения.
Если по истечении этого времени клиент ничего не передаст,
обработка запроса прекращается с ошибкой
408 (Request Time-out).

Синтаксис:	`client_header_buffer_size размер;`
Умолчание:	client_header_buffer_size 1k;
Контекст:	`http`, `server`

Задаёт размер буфера для чтения заголовка запроса клиента.
Для большинства запросов достаточно буфера размером в 1K байт.
Однако если в запросе есть длинные cookies, или же запрос
пришёл от WAP-клиента, то он может не поместиться в 1K.
Поэтому, если строка запроса или поле заголовка запроса
не помещаются полностью в этот буфер, то выделяются буферы
большего размера, задаваемые директивой
large_client_header_buffers.

Если директива указана на уровне server,
то может использоваться значение из сервера по умолчанию.
Подробнее см. в разделе
“Выбор
виртуального сервера”.

Синтаксис:	`client_header_timeout время;`
Умолчание:	client_header_timeout 60s;
Контекст:	`http`, `server`

Задаёт таймаут при чтении заголовка запроса клиента.
Если по истечении этого времени клиент не передаст полностью заголовок,
обработка запроса прекращается с ошибкой
408 (Request Time-out).

Синтаксис:	`client_max_body_size размер;`
Умолчание:	client_max_body_size 1m;
Контекст:	`http`, `server`, `location`

Задаёт максимально допустимый размер тела запроса клиента.
Если размер больше заданного, то клиенту возвращается ошибка
413 (Request Entity Too Large).
Следует иметь в виду, что
браузеры не умеют корректно показывать
эту ошибку.
Установка параметра размер в 0 отключает
проверку размера тела запроса клиента.

Синтаксис:	`connection_pool_size размер;`
Умолчание:	connection_pool_size 256\|512;
Контекст:	`http`, `server`

Позволяет производить точную настройку выделения памяти
под конкретные соединения.
Эта директива не оказывает существенного влияния на
производительность, и её не следует использовать.
По умолчанию размер равен
256 байт на 32-битных платформах и 512 байт на 64-битных платформах.

До версии 1.9.8 по умолчанию использовалось значение 256 на всех платформах.

Синтаксис:	`default_type mime-тип;`
Умолчание:	default_type text/plain;
Контекст:	`http`, `server`, `location`

Задаёт MIME-тип ответов по умолчанию.
Соответствие расширений имён файлов MIME-типу ответов задаётся
с помощью директивы types.

Синтаксис:	`directio размер \| off;`
Умолчание:	directio off;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 0.7.7.

Разрешает использовать флаги
O_DIRECT (FreeBSD, Linux),
F_NOCACHE (macOS)
или функцию directio() (Solaris)
при чтении файлов, размер которых больше либо равен указанному.
Директива автоматически запрещает (0.7.15) использование
sendfile
для данного запроса.
Рекомендуется использовать для больших файлов:

directio 4m;

или при использовании aio в Linux.

Синтаксис:	`directio_alignment размер;`
Умолчание:	directio_alignment 512;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 0.8.11.

Устанавливает выравнивание для
directio.
В большинстве случаев достаточно 512-байтового выравнивания, однако
при использовании XFS под Linux его нужно увеличить до 4K.

Синтаксис:	`disable_symlinks off;` `disable_symlinks on \| if_not_owner [from=часть];`
Умолчание:	disable_symlinks off;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 1.1.15.

Определяет, как следует поступать с символическими ссылками
при открытии файлов:

off: Символические ссылки в пути допускаются и не проверяются.
Это стандартное поведение.
on: Если любой компонент пути является символической ссылкой,
доступ к файлу запрещается.
if_not_owner: Доступ к файлу запрещается, если любой компонент пути
является символической ссылкой, а ссылка и объект, на
который она ссылается, имеют разных владельцев.
from=часть: При проверке символических ссылок
(параметры on и if_not_owner)
обычно проверяются все компоненты пути.
Можно не проверять символические ссылки в начальной части пути,
указав дополнительно параметр
from=часть.
В этом случае символические ссылки проверяются лишь начиная
с компонента пути, который следует за заданной начальной частью.
Если значение не является начальной частью проверяемого пути,
путь проверяется целиком, как если бы этот параметр не был указан вовсе.
Если значение целиком совпадает с именем файла,
символические ссылки не проверяются.
В значении параметра можно использовать переменные.

Пример:

disable_symlinks on from=$document_root;

Эта директива доступна только на системах, в которых есть
интерфейсы openat() и fstatat().
К таким системам относятся современные версии FreeBSD, Linux и Solaris.

Параметры on и if_not_owner
требуют дополнительных затрат на обработку.

На системах, не поддерживающих операцию открытия каталогов только для поиска,
для использования этих параметров требуется, чтобы рабочие процессы
имели право читать все проверяемые каталоги.

Модули
ngx_http_autoindex_module,
ngx_http_random_index_module
и ngx_http_dav_module
в настоящий момент игнорируют эту директиву.

Синтаксис:	`error_page код ... [=[ответ]] uri;`
Умолчание:	—
Контекст:	`http`, `server`, `location`, `if в location`

Задаёт URI, который будет показываться для указанных ошибок.
В значении uri можно использовать переменные.

Пример:

error_page 404             /404.html;
error_page 500 502 503 504 /50x.html;

При этом делается внутреннее перенаправление на указанный uri,
а метод запроса клиента меняется на “GET”
(для всех методов, отличных от
“GET” и “HEAD”).

Кроме того, можно поменять код ответа на другой,
используя синтаксис вида “=ответ”, например:

error_page 404 =200 /empty.gif;

Если ошибочный ответ обрабатывается проксированным сервером или
FastCGI/uwsgi/SCGI/gRPC-сервером,
и этот сервер может вернуть разные коды ответов,
например, 200, 302, 401 или 404, то можно выдавать возвращаемый им код:

error_page 404 = /404.php;

Если при внутреннем перенаправлении не нужно менять URI и метод,
то можно передать обработку ошибки в именованный location:

location / {
    error_page 404 = @fallback;
}

location @fallback {
    proxy_pass http://backend;
}

Если при обработке uri происходит ошибка,
клиенту возвращается ответ с кодом последней случившейся ошибки.

Также существует возможность использовать перенаправления URL для обработки
ошибок:

error_page 403      http://example.com/forbidden.html;
error_page 404 =301 http://example.com/notfound.html;

В этом случае по умолчанию клиенту возвращается код ответа 302.
Его можно изменить только на один из кодов ответа, относящихся к
перенаправлениям (301, 302, 303, 307 и 308).

До версий 1.1.16 и 1.0.13 код 307 не обрабатывался как перенаправление.

До версии 1.13.0 код 308 не обрабатывался как перенаправление.

Директивы наследуются с предыдущего уровня конфигурации при условии, что
на данном уровне не описаны свои директивы error_page.

Синтаксис:	`etag on \| off;`
Умолчание:	etag on;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 1.3.3.

Разрешает или запрещает автоматическую генерацию поля “ETag”
заголовка ответа для статических ресурсов.

Синтаксис:	`http { ... }`
Умолчание:	—
Контекст:	`main`

Предоставляет контекст конфигурационного файла, в котором указываются
директивы HTTP-сервера.

Синтаксис:	`if_modified_since off \| exact \| before;`
Умолчание:	if_modified_since exact;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 0.7.24.

Определяет, как сравнивать время модификации ответа с
временем в поле
“If-Modified-Since”
заголовка запроса:

off: ответ всегда считается изменившимся (0.7.34);
exact: точное совпадение;
before: время модификации ответа меньше или равно времени, заданному в поле
“If-Modified-Since” заголовка запроса.

Синтаксис:	`ignore_invalid_headers on \| off;`
Умолчание:	ignore_invalid_headers on;
Контекст:	`http`, `server`

Если включено, nginx игнорирует поля заголовка с недопустимыми именами.
Допустимыми считаются имена, состоящие из английских букв, цифр, дефисов
и возможно знаков подчёркивания (последнее контролируется директивой
underscores_in_headers).

Синтаксис:	`internal;`
Умолчание:	—
Контекст:	`location`

Указывает, что location может использоваться только для внутренних запросов.
Для внешних запросов клиенту будет возвращаться ошибка
404 (Not Found).
Внутренними запросами являются:

запросы, перенаправленные директивами
error_page,
index,
random_index и
try_files;
запросы, перенаправленные с помощью поля
“X-Accel-Redirect” заголовка ответа вышестоящего сервера;
подзапросы, формируемые командой
“include virtual”
модуля
ngx_http_ssi_module,
директивами модуля
ngx_http_addition_module,
а также директивами
auth_request и
mirror;
запросы, изменённые директивой
rewrite.

Пример:

error_page 404 /404.html;

location = /404.html {
    internal;
}

Для предотвращения зацикливания, которое может возникнуть при
использовании некорректных конфигураций, количество внутренних
перенаправлений ограничено десятью.
По достижении этого ограничения будет возвращена ошибка
500 (Internal Server Error).
В таком случае в лог-файле ошибок можно увидеть сообщение
“rewrite or internal redirection cycle”.

Синтаксис:	`keepalive_disable none \| браузер ...;`
Умолчание:	keepalive_disable msie6;
Контекст:	`http`, `server`, `location`

Запрещает keep-alive соединения с некорректно ведущими себя браузерами.
Параметры браузер указывают, на какие браузеры это
распространяется.
Значение msie6 запрещает keep-alive соединения
со старыми версиями MSIE после получения запроса POST.
Значение safari запрещает keep-alive соединения
с Safari и подобными им браузерами на macOS и подобных ей ОС.
Значение none разрешает keep-alive соединения
со всеми браузерами.

До версии 1.1.18 под значение safari подпадали
все Safari и подобные им браузеры на всех ОС, и keep-alive
соединения с ними были по умолчанию запрещены.

Синтаксис:	`keepalive_requests число;`
Умолчание:	keepalive_requests 1000;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 0.8.0.

Задаёт максимальное число запросов, которые можно
сделать по одному keep-alive соединению.
После того, как сделано максимальное число запросов,
соединение закрывается.

Периодическое закрытие соединений необходимо для освобождения
памяти, выделенной под конкретные соединения.
Поэтому использование слишком большого максимального числа запросов
может приводить к чрезмерному потреблению памяти и не рекомендуется.

До версии 1.19.10 по умолчанию использовалось значение 100.

Синтаксис:	`keepalive_time время;`
Умолчание:	keepalive_time 1h;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 1.19.10.

Ограничивает максимальное время, в течение которого
могут обрабатываться запросы в рамках keep-alive соединения.
По достижении заданного времени соединение закрывается
после обработки очередного запроса.

Синтаксис:	`keepalive_timeout таймаут [заголовок_таймаута];`
Умолчание:	keepalive_timeout 75s;
Контекст:	`http`, `server`, `location`

Первый параметр задаёт таймаут, в течение которого keep-alive
соединение с клиентом не будет закрыто со стороны сервера.
Значение 0 запрещает keep-alive соединения с клиентами.
Второй необязательный параметр задаёт значение в поле
“Keep-Alive: timeout=время”
заголовка ответа.
Два параметра могут отличаться друг от друга.

Поле
“Keep-Alive: timeout=время”
заголовка понимают Mozilla и Konqueror.
MSIE сам закрывает keep-alive соединение примерно через 60 секунд.

Синтаксис:	`large_client_header_buffers число размер;`
Умолчание:	large_client_header_buffers 4 8k;
Контекст:	`http`, `server`

Задаёт максимальное число и размер
буферов для чтения большого заголовка запроса клиента.
Строка запроса не должна превышать размера одного буфера, иначе клиенту
возвращается ошибка
414 (Request-URI Too Large).
Поле заголовка запроса также не должно превышать размера одного буфера,
иначе клиенту возвращается ошибка
400 (Bad Request).
Буферы выделяются только по мере необходимости.
По умолчанию размер одного буфера равен 8K байт.
Если по окончании обработки запроса соединение переходит в состояние
keep-alive, эти буферы освобождаются.

Синтаксис:	`limit_except метод ... { ... }`
Умолчание:	—
Контекст:	`location`

Ограничивает HTTP-методы, доступные внутри location.
Параметр метод может быть одним из
GET,
HEAD,
POST,
PUT,
DELETE,
MKCOL,
COPY,
MOVE,
OPTIONS,
PROPFIND,
PROPPATCH,
LOCK,
UNLOCK
или
PATCH.
Если разрешён метод GET, то метод
HEAD также будет разрешён.
Доступ к остальным методам может быть ограничен при помощи директив модулей
ngx_http_access_module,
ngx_http_auth_basic_module
и
ngx_http_auth_jwt_module
(1.13.10):

limit_except GET {
    allow 192.168.1.0/32;
    deny  all;
}

Обратите внимание, что данное ограничение действует для всех методов,
кроме GET и HEAD.

Синтаксис:	`limit_rate скорость;`
Умолчание:	limit_rate 0;
Контекст:	`http`, `server`, `location`, `if в location`

Ограничивает скорость передачи ответа клиенту.
Скорость задаётся в байтах в секунду.
Значение 0 отключает ограничение скорости.

Ограничение устанавливается на запрос, поэтому, если клиент одновременно
откроет два соединения, суммарная скорость будет вдвое выше
заданного ограничения.

В значении параметра можно использовать переменные (1.17.0).
Это может быть полезно в случаях, когда скорость нужно ограничивать
в зависимости от какого-либо условия:

map $slow $rate {
    1     4k;
    2     8k;
}

limit_rate $rate;

Ограничение скорости можно также задать в переменной
$limit_rate,
однако начиная с 1.17.0 использовать данный метод не рекомендуется:

server {

    if ($slow) {
        set $limit_rate 4k;
    }

    ...
}

Кроме того, ограничение скорости может быть задано в поле
“X-Accel-Limit-Rate” заголовка ответа проксированного сервера.
Эту возможность можно запретить с помощью директив
proxy_ignore_headers,
fastcgi_ignore_headers,
uwsgi_ignore_headers
и
scgi_ignore_headers.

Синтаксис:	`limit_rate_after размер;`
Умолчание:	limit_rate_after 0;
Контекст:	`http`, `server`, `location`, `if в location`

Эта директива появилась в версии 0.8.0.

Задаёт начальный объём данных, после передачи которого начинает
ограничиваться скорость передачи ответа клиенту.
В значении параметра можно использовать переменные (1.17.0).

Пример:

location /flv/ {
    flv;
    limit_rate_after 500k;
    limit_rate       50k;
}

Синтаксис:	`lingering_close off \| on \| always;`
Умолчание:	lingering_close on;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версиях 1.1.0 и 1.0.6.

Управляет закрытием соединений с клиентами.

Со значением по умолчанию “on” nginx будет
ждать и
обрабатывать дополнительные данные,
поступающие от клиента, перед полным закрытием соединения, но только
если эвристика указывает на то, что клиент может ещё послать данные.

Со значением “always” nginx всегда будет
ждать и обрабатывать дополнительные данные, поступающие от клиента.

Со значением “off” nginx не будет ждать поступления
дополнительных данных и сразу же закроет соединение.
Это поведение нарушает протокол и поэтому не должно использоваться без
необходимости.

Для управления закрытием
HTTP/2-соединений
директива должна быть задана на уровне server (1.19.1).

Синтаксис:	`lingering_time время;`
Умолчание:	lingering_time 30s;
Контекст:	`http`, `server`, `location`

Если действует lingering_close,
эта директива задаёт максимальное время, в течение которого nginx
будет обрабатывать (читать и игнорировать) дополнительные данные,
поступающие от клиента.
По прошествии этого времени соединение будет закрыто, даже если
будут ещё данные.

Синтаксис:	`lingering_timeout время;`
Умолчание:	lingering_timeout 5s;
Контекст:	`http`, `server`, `location`

Если действует lingering_close, эта директива задаёт
максимальное время ожидания поступления дополнительных данных от клиента.
Если в течение этого времени данные не были получены, соединение закрывается.
В противном случае данные читаются и игнорируются, и nginx снова
ждёт поступления данных.
Цикл “ждать-читать-игнорировать” повторяется, но не дольше чем задано
директивой lingering_time.

Синтаксис:	`listen адрес[:порт] [default_server] [ssl] [http2 \| spdy] [proxy_protocol] [setfib=число] [fastopen=число] [backlog=число] [rcvbuf=размер] [sndbuf=размер] [accept_filter=фильтр] [deferred] [bind] [ipv6only=on\|off] [reuseport] [so_keepalive=on\|off\|[keepidle]:[keepintvl]:[keepcnt]];` `listen порт [default_server] [ssl] [http2 \| spdy] [proxy_protocol] [setfib=число] [fastopen=число] [backlog=число] [rcvbuf=размер] [sndbuf=размер] [accept_filter=фильтр] [deferred] [bind] [ipv6only=on\|off] [reuseport] [so_keepalive=on\|off\|[keepidle]:[keepintvl]:[keepcnt]];` `listen unix:путь [default_server] [ssl] [http2 \| spdy] [proxy_protocol] [backlog=число] [rcvbuf=размер] [sndbuf=размер] [accept_filter=фильтр] [deferred] [bind] [so_keepalive=on\|off\|[keepidle]:[keepintvl]:[keepcnt]];`
Умолчание:	listen :80 \| :8000;
Контекст:	`server`

Задаёт адрес и порт для IP
или путь для UNIX-сокета,
на которых сервер будет принимать запросы.
Можно указать адрес и порт,
либо только адрес или только порт.
Кроме того, адрес может быть именем хоста, например:

listen 127.0.0.1:8000;
listen 127.0.0.1;
listen 8000;
listen *:8000;
listen localhost:8000;

IPv6-адреса (0.7.36) задаются в квадратных скобках:

listen [::]:8000;
listen [::1];

UNIX-сокеты (0.8.21) задаются при помощи префикса “unix:”:

listen unix:/var/run/nginx.sock;

Если указан только адрес, то используется порт 80.

Если директива не указана, то используется либо *:80,
если nginx работает с привилегиями суперпользователя,
либо *:8000.

Если у директивы есть параметр default_server, то сервер,
в котором описана эта директива, будет сервером по умолчанию для указанной пары
адрес:порт.
Если же директив с параметром default_server нет, то
сервером по умолчанию будет первый сервер, в котором описана пара
адрес:порт.

До версии 0.8.21 этот параметр назывался просто
default.

Параметр ssl (0.7.14) указывает на то, что все соединения,
принимаемые на данном порту, должны работать в режиме SSL.
Это позволяет задать компактную конфигурацию для сервера,
работающего сразу в двух режимах — HTTP и HTTPS.

Параметр http2 (1.9.5) позволяет принимать на этом порту
HTTP/2-соединения.
Обычно, чтобы это работало, следует также указать параметр
ssl, однако nginx можно также настроить и на приём
HTTP/2-соединений без SSL.

Параметр spdy (1.3.15-1.9.4) позволяет принимать на этом порту
SPDY-соединения.
Обычно, чтобы это работало, следует также указать параметр
ssl, однако nginx можно также настроить и на приём
SPDY-соединений без SSL.

Параметр proxy_protocol (1.5.12)
указывает на то, что все соединения, принимаемые на данном порту,
должны использовать
протокол
PROXY.

Протокол PROXY версии 2 поддерживается начиная с версии 1.13.11.

В директиве listen можно также указать несколько
дополнительных параметров, специфичных для связанных с сокетами
системных вызовов.
Эти параметры можно задать в любой директиве listen,
но только один раз для указанной пары
адрес:порт.

До версии 0.8.21 их можно было указывать лишь в директиве
listen совместно с параметром default.

setfib=число

этот параметр (0.8.44) задаёт таблицу маршрутизации, FIB
(параметр SO_SETFIB) для слушающего сокета.
В настоящий момент это работает только на FreeBSD.

fastopen=число

включает
“TCP Fast Open”
для слушающего сокета (1.5.8) и
ограничивает
максимальную длину очереди соединений, которые ещё не завершили процесс
three-way handshake.

Не включайте “TCP Fast Open”, не убедившись, что сервер может адекватно
обрабатывать многократное получение

одного и того же SYN-пакета с данными.

backlog=число

задаёт параметр backlog в вызове
listen(), который ограничивает
максимальный размер очереди ожидающих приёма соединений.
По умолчанию backlog устанавливается равным -1 для
FreeBSD, DragonFly BSD и macOS, и 511 для других платформ.

rcvbuf=размер

задаёт размер буфера приёма
(параметр SO_RCVBUF) для слушающего сокета.

sndbuf=размер

задаёт размер буфера передачи
(параметр SO_SNDBUF) для слушающего сокета.

accept_filter=фильтр

задаёт название accept-фильтра
(параметр SO_ACCEPTFILTER) для слушающего сокета,
который включается для фильтрации входящих соединений
перед передачей их в accept().
Работает только на FreeBSD и NetBSD 5.0+.
Можно использовать два фильтра:
dataready
и
httpready.

deferred

указывает использовать отложенный accept()
(параметр TCP_DEFER_ACCEPT сокета) на Linux.

bind

указывает, что для данной пары
адрес:порт нужно делать
bind() отдельно.
Это нужно потому, что если описаны несколько директив listen
с одинаковым портом, но разными адресами, и одна из директив
listen слушает на всех адресах для данного порта
(*:порт), то nginx сделает
bind() только на *:порт.
Необходимо заметить, что в этом случае для определения адреса, на который
пришло соединение, делается системный вызов getsockname().
Если же используются параметры setfib,
fastopen,
backlog, rcvbuf,
sndbuf, accept_filter,
deferred, ipv6only,
reuseport
или so_keepalive,
то для данной пары
адрес:порт всегда делается
отдельный вызов bind().

ipv6only=on|off

этот параметр (0.7.42) определяет
(через параметр сокета IPV6_V6ONLY),
будет ли слушающий на wildcard-адресе [::] IPv6-сокет
принимать только IPv6-соединения, или же одновременно IPv6- и IPv4-соединения.
По умолчанию параметр включён.
Установить его можно только один раз на старте.

До версии 1.3.4,
если этот параметр не был задан явно, то для сокета действовали
настройки операционной системы.

reuseport

этот параметр (1.9.1) указывает, что нужно создавать отдельный слушающий сокет
для каждого рабочего процесса
(через параметр сокета
SO_REUSEPORT для Linux 3.9+ и DragonFly BSD
или SO_REUSEPORT_LB для FreeBSD 12+), позволяя ядру
распределять входящие соединения между рабочими процессами.
В настоящий момент это работает только на Linux 3.9+, DragonFly BSD
и FreeBSD 12+ (1.15.1).

Ненадлежащее использование параметра может быть
небезопасно.

so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]

этот параметр (1.1.11) конфигурирует для слушающего сокета
поведение “TCP keepalive”.
Если этот параметр опущен, то для сокета будут действовать
настройки операционной системы.
Если он установлен в значение “on”, то для сокета
включается параметр SO_KEEPALIVE.
Если он установлен в значение “off”, то для сокета
параметр SO_KEEPALIVE выключается.
Некоторые операционные системы поддерживают настройку параметров
“TCP keepalive” на уровне сокета посредством параметров
TCP_KEEPIDLE, TCP_KEEPINTVL и
TCP_KEEPCNT.
На таких системах (в настоящий момент это Linux 2.4+, NetBSD 5+ и
FreeBSD 9.0-STABLE)
их можно сконфигурировать с помощью параметров keepidle,
keepintvl и keepcnt.
Один или два параметра могут быть опущены, в таком случае для
соответствующего параметра сокета будут действовать стандартные
системные настройки.
Например,

so_keepalive=30m::10

установит таймаут бездействия (TCP_KEEPIDLE) в 30 минут,
для интервала проб (TCP_KEEPINTVL) будет действовать
стандартная системная настройка, а счётчик проб (TCP_KEEPCNT)
будет равен 10.

Пример:

listen 127.0.0.1 default_server accept_filter=dataready backlog=1024;

Синтаксис:	`location [ = \| ~ \| ~* \| ^~ ] uri { ... }` `location @имя { ... }`
Умолчание:	—
Контекст:	`server`, `location`

Устанавливает конфигурацию в зависимости от URI запроса.

Для сопоставления используется URI запроса в нормализованном виде,
после декодирования текста, заданного в виде “%XX”,
преобразования относительных элементов пути “.” и
“..” в реальные и возможной
замены двух и более подряд идущих
слэшей на один.

location можно задать префиксной строкой или регулярным выражением.
Регулярные выражения задаются либо с модификатором “~*”
(для поиска совпадения без учёта регистра символов),
либо с модификатором “~” (с учётом регистра).
Чтобы найти location, соответствующий запросу, вначале проверяются
location’ы, заданные префиксными строками (префиксные location’ы).
Среди них ищется location с совпадающим префиксом
максимальной длины и запоминается.
Затем проверяются регулярные выражения, в порядке их следования
в конфигурационном файле.
Проверка регулярных выражений прекращается после первого же совпадения,
и используется соответствующая конфигурация.
Если совпадение с регулярным выражением не найдено, то используется
конфигурация запомненного ранее префиксного location’а.

Блоки location могут быть вложенными,
с некоторыми исключениями, о которых говорится ниже.

Для операционных систем, нечувствительных к регистру символов, таких
как macOS и Cygwin, сравнение с префиксными строками производится
без учёта регистра (0.7.7).
Однако сравнение ограничено только однобайтными locale’ями.

Регулярные выражения могут содержать выделения (0.7.40), которые могут
затем использоваться в других директивах.

Если у совпавшего префиксного location’а максимальной длины указан модификатор
“^~”, то регулярные выражения не проверяются.

Кроме того, с помощью модификатора “=” можно задать точное
совпадение URI и location.
При точном совпадении поиск сразу же прекращается.
Например, если запрос “/” случается часто, то
указав “location = /”, можно ускорить обработку
этих запросов, так как поиск прекратится после первого же сравнения.
Очевидно, что такой location не может иметь вложенные location’ы.

В версиях с 0.7.1 по 0.8.41, если запрос точно совпал с префиксным
location’ом без модификаторов “=” и “^~”,
то поиск тоже сразу же прекращается и регулярные выражения также
не проверяются.

Проиллюстрируем вышесказанное примером:

location = / {
    [ конфигурация А ]
}

location / {
    [ конфигурация Б ]
}

location /documents/ {
    [ конфигурация В ]
}

location ^~ /images/ {
    [ конфигурация Г ]
}

location ~* .(gif|jpg|jpeg)$ {
    [ конфигурация Д ]
}

Для запроса “/” будет выбрана конфигурация А,
для запроса “/index.html” — конфигурация Б,
для запроса “/documents/document.html” — конфигурация В,
для запроса “/images/1.gif” — конфигурация Г,
а для запроса “/documents/1.jpg” — конфигурация Д.

Префикс “@” задаёт именованный location.
Такой location не используется при обычной обработке запросов, а
предназначен только для перенаправления в него запросов.
Такие location’ы не могут быть вложенными и не могут содержать
вложенные location’ы.

Если location задан префиксной строкой со слэшом в конце
и запросы обрабатываются при помощи
proxy_pass,
fastcgi_pass,
uwsgi_pass,
scgi_pass,
memcached_pass или
grpc_pass,
происходит специальная обработка.
В ответ на запрос с URI равным этой строке, но без завершающего слэша,
будет возвращено постоянное перенаправление с кодом 301
на URI с добавленным в конец слэшом.
Если такое поведение нежелательно, можно задать точное совпадение
URI и location, например:

location /user/ {
    proxy_pass http://user.example.com;
}

location = /user {
    proxy_pass http://login.example.com;
}

Синтаксис:	`log_not_found on \| off;`
Умолчание:	log_not_found on;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает записывать в
error_log
ошибки о том, что файл не найден.

Синтаксис:	`log_subrequest on \| off;`
Умолчание:	log_subrequest off;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает записывать в
access_log
подзапросы.

Синтаксис:	`max_ranges число;`
Умолчание:	—
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 1.1.2.

Ограничивает максимальное допустимое число диапазонов в запросах с
указанием диапазона запрашиваемых байт (byte-range requests).
Запросы, превышающие указанное ограничение, обрабатываются как
если бы они не содержали указания диапазонов.
По умолчанию число диапазонов не ограничено.
Значение 0 полностью запрещает поддержку диапазонов.

Синтаксис:	`merge_slashes on \| off;`
Умолчание:	merge_slashes on;
Контекст:	`http`, `server`

Разрешает или запрещает преобразование URI путём замены двух и более подряд
идущих слэшей (“/”) на один.

Необходимо иметь в виду, что это преобразование необходимо для корректной
проверки префиксных строк и регулярных выражений.
Если его не делать, то запрос “//scripts/one.php”
не попадёт в

location /scripts/ {
    ...
}

и может быть обслужен как статический файл.
Поэтому он преобразуется к виду “/scripts/one.php”.

Запрет преобразования может понадобиться, если в URI используются имена,
закодированные методом base64, в котором задействован символ
“/”.
Однако из соображений безопасности лучше избегать отключения преобразования.

Синтаксис:	`msie_padding on \| off;`
Умолчание:	msie_padding on;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает добавлять в ответы для MSIE со статусом больше 400
комментарий для увеличения размера ответа до 512 байт.

Синтаксис:	`msie_refresh on \| off;`
Умолчание:	msie_refresh off;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает выдавать для MSIE клиентов refresh’ы вместо
перенаправлений.

Синтаксис:	`open_file_cache off;` `open_file_cache max=N [inactive=время];`
Умолчание:	open_file_cache off;
Контекст:	`http`, `server`, `location`

Задаёт кэш, в котором могут храниться:

дескрипторы открытых файлов, информация об их размерах и времени модификации;
информация о существовании каталогов;
информация об ошибках поиска файла — “нет файла”, “нет прав на чтение”
и тому подобное.

Кэширование ошибок нужно разрешить отдельно директивой
open_file_cache_errors.

У директивы есть следующие параметры:

max: задаёт максимальное число элементов в кэше;
при переполнении кэша удаляются наименее востребованные элементы (LRU);
inactive: задаёт время, после которого элемент кэша удаляется, если к нему
не было обращений в течение этого времени; по умолчанию 60 секунд;
off: запрещает кэш.

Пример:

open_file_cache          max=1000 inactive=20s;
open_file_cache_valid    30s;
open_file_cache_min_uses 2;
open_file_cache_errors   on;

Синтаксис:	`open_file_cache_errors on \| off;`
Умолчание:	open_file_cache_errors off;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает кэширование ошибок поиска файлов в
open_file_cache.

Синтаксис:	`open_file_cache_min_uses число;`
Умолчание:	open_file_cache_min_uses 1;
Контекст:	`http`, `server`, `location`

Задаёт минимальное число обращений к файлу
в течение времени, заданного параметром inactive
директивы open_file_cache, необходимых для того, чтобы дескриптор
файла оставался открытым в кэше.

Синтаксис:	`open_file_cache_valid время;`
Умолчание:	open_file_cache_valid 60s;
Контекст:	`http`, `server`, `location`

Определяет время, через которое следует проверять актуальность информации
об элементе в
open_file_cache.

Синтаксис:	`output_buffers number size;`
Умолчание:	output_buffers 2 32k;
Контекст:	`http`, `server`, `location`

Задаёт число и размер буферов,
используемых при чтении ответа с диска.

До версии 1.9.5 по умолчанию использовалось значение 1 32k.

Синтаксис:	`port_in_redirect on \| off;`
Умолчание:	port_in_redirect on;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает указывать порт в
абсолютных
перенаправлениях, выдаваемых nginx’ом.

Использование в перенаправлениях основного имени сервера управляется
директивой server_name_in_redirect.

Синтаксис:	`postpone_output размер;`
Умолчание:	postpone_output 1460;
Контекст:	`http`, `server`, `location`

Если это возможно, то отправка данных клиенту будет отложена пока nginx не
накопит по крайней мере указанное количество байт для отправки.
Значение 0 запрещает отложенную отправку данных.

Синтаксис:	`read_ahead размер;`
Умолчание:	read_ahead 0;
Контекст:	`http`, `server`, `location`

Задаёт ядру размер предчтения при работе с файлами.

На Linux используется системный вызов
posix_fadvise(0, 0, 0, POSIX_FADV_SEQUENTIAL),
поэтому параметр размер там игнорируется.

На FreeBSD используется системный вызов
fcntl(O_READAHEAD,размер),
появившийся во FreeBSD 9.0-CURRENT.
Для FreeBSD 7 необходимо установить
патч.

Синтаксис:	`recursive_error_pages on \| off;`
Умолчание:	recursive_error_pages off;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает делать несколько перенаправлений через директиву
error_page.
Число таких перенаправлений ограничено.

Синтаксис:	`request_pool_size размер;`
Умолчание:	request_pool_size 4k;
Контекст:	`http`, `server`

Позволяет производить точную настройку выделений памяти
под конкретные запросы.
Эта директива не оказывает существенного влияния на
производительность, и её не следует использовать.

Синтаксис:	`reset_timedout_connection on \| off;`
Умолчание:	reset_timedout_connection off;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает сброс соединений по таймауту,
а также при
закрытии
соединений с помощью нестандартного кода 444 (1.15.2).
Сброс делается следующим образом.
Перед закрытием сокета для него задаётся параметр
SO_LINGER
с таймаутом 0.
После этого при закрытии сокета клиенту отсылается TCP RST, а вся память,
связанная с этим сокетом, освобождается.
Это позволяет избежать длительного нахождения уже закрытого сокета в
состоянии FIN_WAIT1 с заполненными буферами.

Необходимо отметить, что keep-alive соединения по истечении таймаута
закрываются обычным образом.

Синтаксис:	`resolver адрес ... [valid=время] [ipv4=on\|off] [ipv6=on\|off] [status_zone=зона];`
Умолчание:	—
Контекст:	`http`, `server`, `location`

Задаёт серверы DNS, используемые для преобразования имён вышестоящих серверов
в адреса, например:

resolver 127.0.0.1 [::1]:5353;

Адрес может быть указан в виде доменного имени или IP-адреса,
и необязательного порта (1.3.1, 1.2.2).
Если порт не указан, используется порт 53.
Серверы DNS опрашиваются циклически.

До версии 1.1.7 можно было задать лишь один DNS-сервер.
Задание DNS-серверов с помощью IPv6-адресов поддерживается
начиная с версий 1.3.1 и 1.2.2.

По умолчанию nginx будет искать как IPv4-, так и IPv6-адреса
при преобразовании имён в адреса.
Если поиск IPv4- или IPv6-адресов нежелателен,
можно указать параметр ipv4=off (1.23.1) или
ipv6=off.

Преобразование имён в IPv6-адреса поддерживается
начиная с версии 1.5.8.

По умолчанию nginx кэширует ответы, используя значение TTL из ответа.
Необязательный параметр valid позволяет это
переопределить:

resolver 127.0.0.1 [::1]:5353 valid=30s;

До версии 1.1.9 настройка времени кэширования была невозможна
и nginx всегда кэшировал ответы на срок в 5 минут.

Для предотвращения DNS-спуфинга рекомендуется
использовать DNS-серверы в защищённой доверенной локальной сети.

Необязательный параметр status_zone (1.17.1)
включает
сбор информации
о запросах и ответах сервера DNS
в указанной зоне.
Параметр доступен как часть
коммерческой подписки.

Синтаксис:	`resolver_timeout время;`
Умолчание:	resolver_timeout 30s;
Контекст:	`http`, `server`, `location`

Задаёт таймаут для преобразования имени в адрес, например:

resolver_timeout 5s;

Синтаксис:	`root путь;`
Умолчание:	root html;
Контекст:	`http`, `server`, `location`, `if в location`

Задаёт корневой каталог для запросов.
Например, при такой конфигурации

location /i/ {
    root /data/w3;
}

в ответ на запрос “/i/top.gif” будет отдан файл
/data/w3/i/top.gif.

В значении параметра путь можно использовать переменные,
кроме $document_root и $realpath_root.

Путь к файлу формируется путём простого добавления URI к значению директивы
root.
Если же URI необходимо поменять, следует воспользоваться директивой
alias.

Синтаксис:	`satisfy all \| any;`
Умолчание:	satisfy all;
Контекст:	`http`, `server`, `location`

Разрешает доступ, если все (all)
или хотя бы один (any) из модулей
ngx_http_access_module,
ngx_http_auth_basic_module,
ngx_http_auth_request_module
или
ngx_http_auth_jwt_module
разрешают доступ.

Пример:

location / {
    satisfy any;

    allow 192.168.1.0/32;
    deny  all;

    auth_basic           "closed site";
    auth_basic_user_file conf/htpasswd;
}

Синтаксис:	`send_lowat размер;`
Умолчание:	send_lowat 0;
Контекст:	`http`, `server`, `location`

При установке этой директивы в ненулевое значение nginx будет пытаться
минимизировать число операций отправки на клиентских сокетах либо при
помощи флага NOTE_LOWAT метода
kqueue,
либо при помощи параметра сокета SO_SNDLOWAT.
В обоих случаях будет использован указанный размер.

Эта директива игнорируется на Linux, Solaris и Windows.

Синтаксис:	`send_timeout время;`
Умолчание:	send_timeout 60s;
Контекст:	`http`, `server`, `location`

Задаёт таймаут при передаче ответа клиенту.
Таймаут устанавливается не на всю передачу ответа,
а только между двумя операциями записями.
Если по истечении этого времени клиент ничего не примет,
соединение будет закрыто.

Синтаксис:	`sendfile on \| off;`
Умолчание:	sendfile off;
Контекст:	`http`, `server`, `location`, `if в location`

Разрешает или запрещает использовать
sendfile().

Начиная с nginx 0.8.12 и FreeBSD 5.2.1,
можно использовать aio для подгрузки данных
для sendfile():

location /video/ {
    sendfile       on;
    tcp_nopush     on;
    aio            on;
}

В такой конфигурации функция sendfile() вызывается с флагом
SF_NODISKIO, в результате чего она не блокируется на диске, а
сообщает об отсутствии данных в памяти.
После этого nginx инициирует асинхронную подгрузку данных, читая один байт.
При этом ядро FreeBSD подгружает в память первые 128K байт файла, однако
при последующих чтениях файл подгружается частями только по 16K.
Изменить это можно с помощью директивы
read_ahead.

До версии 1.7.11 подгрузка данных включалась с помощью
aio sendfile;.

Синтаксис:	`sendfile_max_chunk размер;`
Умолчание:	sendfile_max_chunk 2m;
Контекст:	`http`, `server`, `location`

Ограничивает объём данных,
который может передан за один вызов sendfile().
Без этого ограничения одно быстрое соединение может целиком
захватить рабочий процесс.

До версии 1.21.4 по умолчанию ограничения не было.

Синтаксис:	`server { ... }`
Умолчание:	—
Контекст:	`http`

Задаёт конфигурацию для виртуального сервера.
Чёткого разделения виртуальных серверов на IP-based (на основании IP-адреса)
и name-based (на основании поля “Host” заголовка запроса) нет.
Вместо этого директивами listen описываются все
адреса и порты, на которых нужно принимать соединения для этого сервера,
а в директиве server_name указываются все имена серверов.
Примеры конфигураций описаны в документе
“Как nginx обрабатывает запросы”.

Синтаксис:	`server_name имя ...;`
Умолчание:	server_name "";
Контекст:	`server`

Задаёт имена виртуального сервера, например:

server {
    server_name example.com www.example.com;
}

Первое имя становится основным именем сервера.

В именах серверов можно использовать звёздочку (“*”)
для замены первой или последней части имени:

server {
    server_name example.com *.example.com www.example.*;
}

Такие имена называются именами с маской.

Два первых вышеприведённых имени можно объединить в одно:

server {
    server_name .example.com;
}

В качестве имени сервера можно также использовать регулярное выражение,
указав перед ним тильду (“~”):

server {
    server_name www.example.com ~^wwwd+.example.com$;
}

Регулярное выражение может содержать выделения (0.7.40),
которые могут затем использоваться в других директивах:

server {
    server_name ~^(www.)?(.+)$;

    location / {
        root /sites/$2;
    }
}

server {
    server_name _;

    location / {
        root /sites/default;
    }
}

Именованные выделения в регулярном выражении создают переменные (0.8.25),
которые могут затем использоваться в других директивах:

server {
    server_name ~^(www.)?(?<domain>.+)$;

    location / {
        root /sites/$domain;
    }
}

server {
    server_name _;

    location / {
        root /sites/default;
    }
}

Если параметр директивы установлен в “$hostname” (0.9.4), то
подставляется имя хоста (hostname) машины.

Возможно также указать пустое имя сервера (0.7.11):

server {
    server_name www.example.com "";
}

Это позволяет обрабатывать запросы без поля “Host” заголовка
запроса в этом сервере, а не в сервере по умолчанию для данной пары адрес:порт.
Это настройка по умолчанию.

До 0.8.48 по умолчанию использовалось имя хоста (hostname) машины.

При поиске виртуального сервера по имени,
если имени соответствует несколько из указанных вариантов,
например, одновременно подходят и имя с маской, и регулярное выражение,
будет выбран первый подходящий вариант в следующем порядке приоритета:

точное имя
самое длинное имя с маской в начале,
например “*.example.com”
самое длинное имя с маской в конце,
например “mail.*”
первое подходящее регулярное выражение
(в порядке следования в конфигурационном файле)

Подробнее имена серверов обсуждаются в отдельном
документе.

Синтаксис:	`server_name_in_redirect on \| off;`
Умолчание:	server_name_in_redirect off;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает использовать в
абсолютных перенаправлениях,
выдаваемых nginx’ом, основное имя сервера, задаваемое директивой
server_name.
Если использование основного имени сервера запрещено, то используется имя,
указанное в поле “Host” заголовка запроса.
Если же этого поля нет, то используется IP-адрес сервера.

Использование в перенаправлениях порта управляется
директивой port_in_redirect.

Синтаксис:	`server_names_hash_bucket_size размер;`
Умолчание:	server_names_hash_bucket_size 32\|64\|128;
Контекст:	`http`

Задаёт размер корзины в хэш-таблицах имён серверов.
Значение по умолчанию зависит от размера строки кэша процессора.
Подробнее настройка хэш-таблиц обсуждается в отдельном
документе.

Синтаксис:	`server_names_hash_max_size размер;`
Умолчание:	server_names_hash_max_size 512;
Контекст:	`http`

Задаёт максимальный размер хэш-таблиц имён серверов.
Подробнее настройка хэш-таблиц обсуждается в отдельном
документе.

Синтаксис:	`server_tokens on \| off \| build \| строка;`
Умолчание:	server_tokens on;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает выдавать версию nginx’а на страницах ошибок и
в поле “Server” заголовка ответа.

Если указан параметр build (1.11.10),
то наряду с версией nginx’а будет также выдаваться
имя сборки.

Дополнительно, как часть
коммерческой подписки,
начиная с версии 1.9.13
подписи на страницах ошибок и
значение поля “Server” заголовка ответа
можно задать явно с помощью строки с переменными.
Пустая строка запрещает выдачу поля “Server”.

Синтаксис:	`subrequest_output_buffer_size размер;`
Умолчание:	subrequest_output_buffer_size 4k\|8k;
Контекст:	`http`, `server`, `location`

Эта директива появилась в версии 1.13.10.

Задаёт размер буфера, используемого для
хранения тела ответа подзапроса.
По умолчанию размер одного буфера равен размеру страницы памяти.
В зависимости от платформы это или 4K, или 8K,
однако его можно сделать меньше.

Директива применима только для подзапросов,
тело ответа которых сохраняется в памяти.
Например, подобные подзапросы создаются при помощи
SSI.

Синтаксис:	`tcp_nodelay on \| off;`
Умолчание:	tcp_nodelay on;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает использование параметра TCP_NODELAY.
Параметр включается при переходе соединения в состояние keep-alive.
Также, он включается на SSL-соединениях,
при небуферизованном проксировании
и при проксировании WebSocket.

Синтаксис:	`tcp_nopush on \| off;`
Умолчание:	tcp_nopush off;
Контекст:	`http`, `server`, `location`

Разрешает или запрещает использование параметра сокета
TCP_NOPUSH во FreeBSD или
TCP_CORK в Linux.
Параметр включаются только при использовании sendfile.
Включение параметра позволяет

передавать заголовок ответа и начало файла в одном пакете
в Linux и во FreeBSD 4.*;
передавать файл полными пакетами.

Синтаксис:	`try_files файл ... uri;` `try_files файл ... =код;`
Умолчание:	—
Контекст:	`server`, `location`

Проверяет существование файлов в заданном порядке и использует
для обработки запроса первый найденный файл, причём обработка
делается в контексте этого же location’а.
Путь к файлу строится из параметра файл
в соответствии с директивами
root и alias.
С помощью слэша в конце имени можно проверить существование каталога,
например, “$uri/”.
В случае, если ни один файл не найден, то делается внутреннее
перенаправление на uri, заданный последним параметром.
Например:

location /images/ {
    try_files $uri /images/default.gif;
}

location = /images/default.gif {
    expires 30s;
}

Последний параметр может также указывать на именованный location,
как в примерах ниже.
С версии 0.7.51 последний параметр может также быть кодом:

location / {
    try_files $uri $uri/index.html $uri.html =404;
}

Пример использования при проксировании Mongrel:

location / {
    try_files /system/maintenance.html
              $uri $uri/index.html $uri.html
              @mongrel;
}

location @mongrel {
    proxy_pass http://mongrel;
}

Пример использования вместе с Drupal/FastCGI:

location / {
    try_files $uri $uri/ @drupal;
}

location ~ .php$ {
    try_files $uri @drupal;

    fastcgi_pass ...;

    fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name;
    fastcgi_param SCRIPT_NAME     $fastcgi_script_name;
    fastcgi_param QUERY_STRING    $args;

    ... прочие fastcgi_param
}

location @drupal {
    fastcgi_pass ...;

    fastcgi_param SCRIPT_FILENAME /path/to/index.php;
    fastcgi_param SCRIPT_NAME     /index.php;
    fastcgi_param QUERY_STRING    q=$uri&$args;

    ... прочие fastcgi_param
}

В следующем примере директива try_files

location / {
    try_files $uri $uri/ @drupal;
}

аналогична директивам

location / {
    error_page 404 = @drupal;
    log_not_found off;
}

А здесь

location ~ .php$ {
    try_files $uri @drupal;

    fastcgi_pass ...;

    fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name;

    ...
}

try_files проверяет существование PHP-файла,
прежде чем передать запрос FastCGI-серверу.

Пример использования вместе с WordPress и Joomla:

location / {
    try_files $uri $uri/ @wordpress;
}

location ~ .php$ {
    try_files $uri @wordpress;

    fastcgi_pass ...;

    fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name;
    ... прочие fastcgi_param
}

location @wordpress {
    fastcgi_pass ...;

    fastcgi_param SCRIPT_FILENAME /path/to/index.php;
    ... прочие fastcgi_param
}

Синтаксис:	`types { ... }`
Умолчание:	types { text/html html; image/gif gif; image/jpeg jpg; }
Контекст:	`http`, `server`, `location`

Задаёт соответствие расширений имён файлов и MIME-типов ответов.
Расширения нечувствительны к регистру символов.
Одному MIME-типу может соответствовать несколько расширений, например:

types {
    application/octet-stream bin exe dll;
    application/octet-stream deb;
    application/octet-stream dmg;
}

Достаточно полная таблица соответствий входит в дистрибутив nginx
и находится в файле conf/mime.types.

Для того чтобы для определённого location’а для всех ответов
выдавался MIME-тип “application/octet-stream”,
можно использовать следующее:

location /download/ {
    types        { }
    default_type application/octet-stream;
}

Синтаксис:	`types_hash_bucket_size размер;`
Умолчание:	types_hash_bucket_size 64;
Контекст:	`http`, `server`, `location`

Задаёт размер корзины в хэш-таблицах типов.
Подробнее настройка хэш-таблиц обсуждается в отдельном
документе.

До версии 1.5.13
значение по умолчанию зависело от размера строки кэша процессора.

Синтаксис:	`types_hash_max_size размер;`
Умолчание:	types_hash_max_size 1024;
Контекст:	`http`, `server`, `location`

Задаёт максимальный размер хэш-таблиц типов.
Подробнее настройка хэш-таблиц обсуждается в отдельном
документе.

Синтаксис:	`underscores_in_headers on \| off;`
Умолчание:	underscores_in_headers off;
Контекст:	`http`, `server`

Разрешает или запрещает использование символов подчёркивания в
полях заголовка запроса клиента.
Если использование символов подчёркивания запрещено, поля заголовка запроса, в
именах которых есть подчёркивания,
помечаются как недопустимые и подпадают под действие директивы
ignore_invalid_headers.

Синтаксис:	`variables_hash_bucket_size размер;`
Умолчание:	variables_hash_bucket_size 64;
Контекст:	`http`

Задаёт размер корзины в хэш-таблице переменных.
Подробнее настройка хэш-таблиц обсуждается в отдельном
документе.

Синтаксис:	`variables_hash_max_size размер;`
Умолчание:	variables_hash_max_size 1024;
Контекст:	`http`

Задаёт максимальный размер хэш-таблицы переменных.
Подробнее настройка хэш-таблиц обсуждается в отдельном
документе.

До версии 1.5.13 по умолчанию использовалось значение 512.

Встроенные переменные

Модуль ngx_http_core_module поддерживает встроенные
переменные, имена которых совпадают с именами переменных веб-сервера Apache.
Прежде всего, это переменные, представляющие из себя поля заголовка
запроса клиента, такие как $http_user_agent, $http_cookie
и тому подобное.
Кроме того, есть и другие переменные:

$arg_имя

аргумент имя в строке запроса

$args

аргументы в строке запроса

$binary_remote_addr

адрес клиента в бинарном виде, длина значения всегда 4 байта
для IPv4-адресов или 16 байт для IPv6-адресов

$body_bytes_sent

число байт, переданное клиенту, без учёта заголовка ответа;
переменная совместима с параметром “%B” модуля Apache
mod_log_config

$bytes_sent

число байт, переданных клиенту (1.3.8, 1.2.5)

$connection

порядковый номер соединения (1.3.8, 1.2.5)

$connection_requests

текущее число запросов в соединении (1.3.8, 1.2.5)

$connection_time

время соединения в секундах с точностью до миллисекунд (1.19.10)

$content_length

поле “Content-Length” заголовка запроса

$content_type

поле “Content-Type” заголовка запроса

$cookie_имя

cookie имя

$document_root

значение директивы root или alias
для текущего запроса

$document_uri

то же, что и $uri

$host

в порядке приоритета:
имя хоста из строки запроса, или
имя хоста из поля “Host” заголовка запроса, или
имя сервера, соответствующего запросу

$hostname

имя хоста

$http_имя

произвольное поле заголовка запроса;
последняя часть имени переменной соответствует имени поля, приведённому
к нижнему регистру, с заменой символов тире на символы подчёркивания

$https

“on”
если соединение работает в режиме SSL,
либо пустая строка

$is_args

“?”, если в строке запроса есть аргументы,
и пустая строка, если их нет

$limit_rate

установка этой переменной позволяет ограничивать скорость
передачи ответа, см. limit_rate

$msec

текущее время в секундах с точностью до миллисекунд (1.3.9, 1.2.6)

$nginx_version

версия nginx

$pid

номер (PID) рабочего процесса

$pipe

“p” если запрос был pipelined, иначе “.”
(1.3.12, 1.2.7)

$proxy_protocol_addr

адрес клиента, полученный из заголовка протокола PROXY (1.5.12)

Протокол PROXY должен быть предварительно включён при помощи установки
параметра proxy_protocol в директиве listen.

$proxy_protocol_port

порт клиента, полученный из заголовка протокола PROXY (1.11.0)

Протокол PROXY должен быть предварительно включён при помощи установки
параметра proxy_protocol в директиве listen.

$proxy_protocol_server_addr

адрес сервера, полученный из заголовка протокола PROXY (1.17.6)

Протокол PROXY должен быть предварительно включён при помощи установки
параметра proxy_protocol в директиве listen.

$proxy_protocol_server_port

порт сервера, полученный из заголовка протокола PROXY (1.17.6)

Протокол PROXY должен быть предварительно включён при помощи установки
параметра proxy_protocol в директиве listen.

$proxy_protocol_tlv_имя

TLV, полученный из заголовка протокола PROXY (1.23.2).
Имя может быть именем типа TLV или его числовым значением.
В последнем случае значение задаётся в шестнадцатеричном виде
и должно начинаться с 0x:

$proxy_protocol_tlv_alpn
$proxy_protocol_tlv_0x01

SSL TLV могут также быть доступны как по имени типа TLV,
так и по его числовому значению,
оба должны начинаться с ssl_:

$proxy_protocol_tlv_ssl_version
$proxy_protocol_tlv_ssl_0x21

Поддерживаются следующие имена типов TLV:

alpn (0x01) —
протокол более высокого уровня, используемый поверх соединения
authority (0x02) —
значение имени хоста, передаваемое клиентом
unique_id (0x05) —
уникальный идентификатор соединения
netns (0x30) —
имя пространства имён
ssl (0x20) —
структура SSL TLV в бинарном виде

Поддерживаются следующие имена типов SSL TLV:

ssl_version (0x21) —
версия SSL, используемая в клиентском соединении
ssl_cn (0x22) —
Common Name сертификата
ssl_cipher (0x23) —
имя используемого шифра
ssl_sig_alg (0x24) —
алгоритм, используемый для подписи сертификата
ssl_key_alg (0x25) —
алгоритм публичного ключа

Также поддерживается следующее специальное имя типа SSL TLV:

ssl_verify —
результат проверки клиентского сертификата:
0, если клиент предоставил сертификат
и он был успешно верифицирован,
либо ненулевое значение

Протокол PROXY должен быть предварительно включён при помощи установки
параметра proxy_protocol в директиве listen.

$query_string

то же, что и $args

$realpath_root

абсолютный путь, соответствующий
значению директивы root или alias
для текущего запроса,
в котором все символические ссылки преобразованы в реальные пути

$remote_addr

адрес клиента

$remote_port

порт клиента

$remote_user

имя пользователя, использованное в Basic аутентификации

$request

первоначальная строка запроса целиком

$request_body

тело запроса

Значение переменной появляется в location’ах, обрабатываемых
директивами
proxy_pass,
fastcgi_pass,
uwsgi_pass
и
scgi_pass,
когда тело было прочитано в
буфер в памяти.

$request_body_file

имя временного файла, в котором хранится тело запроса

По завершении обработки файл необходимо удалить.
Для того чтобы тело запроса всегда записывалось в файл,
следует включить client_body_in_file_only.
При передаче имени временного файла в проксированном запросе
или в запросе к FastCGI/uwsgi/SCGI-серверу следует запретить передачу самого
тела директивами

proxy_pass_request_body off,

fastcgi_pass_request_body off,

uwsgi_pass_request_body off
или

scgi_pass_request_body off
соответственно.

$request_completion

“OK” если запрос завершился,
либо пустая строка

$request_filename

путь к файлу для текущего запроса, формируемый из директив
root или alias и URI запроса

$request_id

уникальный идентификатор запроса,
сформированный из 16 случайных байт, в шестнадцатеричном виде (1.11.0)

$request_length

длина запроса (включая строку запроса, заголовок и тело запроса)
(1.3.12, 1.2.7)

$request_method

метод запроса, обычно
“GET” или “POST”

$request_time

время обработки запроса в секундах с точностью до миллисекунд
(1.3.9, 1.2.6);
время, прошедшее с момента чтения первых байт от клиента

$request_uri

первоначальный URI запроса целиком (с аргументами)

$scheme

схема запроса, “http” или “https”

$sent_http_имя

произвольное поле заголовка ответа;
последняя часть имени переменной соответствует имени поля, приведённому
к нижнему регистру, с заменой символов тире на символы подчёркивания

$sent_trailer_имя

произвольное поле, отправленное в конце ответа (1.13.2);
последняя часть имени переменной соответствует имени поля, приведённому
к нижнему регистру, с заменой символов тире на символы подчёркивания

$server_addr

адрес сервера, принявшего запрос

Получение значения этой переменной обычно требует одного системного вызова.
Чтобы избежать системного вызова, в директивах listen
следует указывать адреса и использовать параметр bind.

$server_name

имя сервера, принявшего запрос

$server_port

порт сервера, принявшего запрос

$server_protocol

протокол запроса, обычно
“HTTP/1.0”,
“HTTP/1.1”
или
“HTTP/2.0”

$status

статус ответа (1.3.2, 1.2.2)

$time_iso8601

локальное время в формате по стандарту ISO 8601 (1.3.12, 1.2.7)

$time_local

локальное время в Common Log Format (1.3.12, 1.2.7)

$tcpinfo_rtt, $tcpinfo_rttvar, $tcpinfo_snd_cwnd, $tcpinfo_rcv_space

информация о клиентском TCP-соединении; доступна на системах,
поддерживающих параметр сокета TCP_INFO

$uri

текущий URI запроса в нормализованном виде

Значение $uri может изменяться в процессе обработки запроса,
например, при внутренних перенаправлениях
или при использовании индексных файлов.

Источник

На чтение 4 мин Просмотров 7к. Опубликовано 14.10.2021

Когда вы посещаете веб-сайт, настроенный для Nginx, ваш браузер отправляет запрос на веб-сервер. После этого ваш веб-сервер отвечает данными, имеющими заголовок HTTP. Коды состояния HTTP включены в этот HTTP-заголовок, чтобы объяснить, как выполняется ответ на запрос.

Когда ваши запросы обрабатываются успешно, код состояния HTTP не отображается в вашем браузере. Однако, если что-то пойдет не так, ваш веб-браузер обычно отображает сообщение с кодом состояния HTTP, чтобы сообщить вам о проблеме с запросом. Сообщения об ошибках, такие как 504, 500, 503, 502, включая сообщение » Ошибка 404 не найдена «, являются частью этого процесса.

Содержание

Что означает ошибка 404 в Nginx
Как исправить ошибку 404 в Nginx
Как исправить ошибку 404 Nginx с помощью онлайн-инструментов
W3C Проверить ссылку
Check My Links
Broken Link Checker
Заключение

Что означает ошибка 404 в Nginx

По сути, » ошибка 404 ″ означает, что ваш веб-браузер или веб-браузер вашего посетителя был успешно подключен к серверу веб-сайта или хосту. Однако ему не удалось найти запрошенный ресурс, например имя файла или какой-либо конкретный URL-адрес.

Например, если кто-то попытается перейти на » yourwebsite.com/anypostname » и не имеет никакого контента, связанного с » anypostname «, в таком случае вы получите ошибку 404 в своем браузере, поскольку запрошенный ресурс не существует. Другими словами, мы можем сказать, что когда запрашиваемый ресурс, такой как файл JavaScript, изображение или CSS, отсутствует, ваш работающий браузер выдаст ошибку „404“.

Как исправить ошибку 404 в Nginx

Если вы получаете сообщение об ошибке Nginx » 404 Not Found » и проверили, что запрошенный актив существует на вашем сервере, то ваш файл конфигурации может вызывать ошибку. Чтобы исправить ошибку » 404 Not Found «, откройте свой терминал, нажав » CTRL + ALT + T «, и выполните приведенную ниже команду для открытия файла конфигурации Nginx:

$ sudo nano /etc/nginx/nginx.conf

Ваш файл конфигурации Nginx будет выглядеть так:

Если путь, добавленный в файл конфигурации Nginx, неверен, это приведет к ошибке Ngnix » 404 Not Found «. Итак, проверьте свой путь, ведущий к каталогу активов:

root /usr/share/nginx/html;

Также будет полезно просмотреть ваши ошибки и получить доступ к журналам в Nginx. Для этого используйте приведенную ниже команду » cat » для извлечения содержимого error_log, присутствующего в файле » /var/log/nginx/error.log «:

$ sudo cat /var/log/nginx/error.log

Чтобы проверить содержимое access_log, запишите эту команду в своем терминале:

$ sudo cat /var/log/nginx/access.log

Как исправить ошибку 404 Nginx с помощью онлайн-инструментов

» Ошибка 404 Nginx » также связана с внешними ресурсами и возникает, когда эти ресурсы удаляются или изменяются. Вот почему так важно часто выполнять проверку ошибок 404, чтобы убедиться, что ссылки на ваш веб-сайт не повреждены. Регулярная проверка и исправление неработающих ссылок поможет вам убедиться, что пользовательский опыт посетителя вашего веб-сайта находится на стабильном уровне. Ниже приведены некоторые инструменты, которые можно использовать для проверки ошибок «404 Not Found»:

W3C Проверить ссылку

В онлайн-инструменте W3C Link Checker вы должны ввести URL-адрес своего веб-сайта, и он просканирует все ваши веб-страницы на предмет 404 Not Found и других проблем. Когда сканирование закончится, оно вернет все неработающие URL-адреса вместе с другими результатами:

Check My Links

Check My Links — это базовый плагин Chrome, который позволяет вам проверять ссылки на текущей веб-странице. Когда этот плагин активирован, расширение определит, действительны ли ссылки на текущей странице или нет:

Broken Link Checker

Broken Link Checker — еще один полезный плагин, который предлагает различные методы проверки неработающих ссылок на вашем сайте. Можно установить период времени, при котором этот плагин будет проверять неработающие ссылки каждые «X» часов. Вы можете выбрать, должен ли плагин отправлять по электронной почте отчет, содержащий все неработающие ссылки или часть сайта, которая успешно просканирована:

Если вы столкнулись с ошибкой Nginx «404 Not Found» или хотите убедиться, что ссылки на ваш сайт не сломаны, или отслеживать ваш сайт, используйте вышеуказанные методы, чтобы исправить это.

Заключение

» Ошибка 404 Not Found » на веб-странице — это код состояния HTTP-ответа, который объявляет, что запрошенный ресурс не найден. Вам может быть сложно выяснить причину » ошибки 404 not found «. В этом посте мы объяснили, что такое «ошибка 404 Not Found». Мы также предоставили вам способы исправить «ошибку 404 Not Found», используя файл конфигурации Nginx и другие онлайн-инструменты, такие как «Проверить мои ссылки», «Проверить ссылку W3C» и «Проверка неработающих ссылок».

Источник

Nginx is a very popular web server these days. This article will show you some common errors when running an Nginx web server and possible solutions. This is not a complete list. If you still can’t fix the error after trying the advised solutions, please check your Nginx server logs under /var/log/nginx/ directory and search on Google to debug the problem.

Unable to connect/Refused to Connect

If you see the following error when trying to access your website:

Firefox can’t establish a connection to the server at www.example.com

www.example.com refused to connect

The site can't be reached, www.example.com unexpectedly closed the connection.

It could be that

Nginx isn’t running. You can check Nginx status with sudo systemctl status nginx. Start Nginx with sudo systemctl start nginx. If Nginx fails to start, run sudo nginx -t to find if there is anything wrong with your configuration file. And check the journal (sudo journalctl -eu nginx) to find out why it fails to start.
Firewall blocking ports 80 and 443. If you use the UFW firewall on Debian/Ubuntu, run sudo ufw allow 80,443/tcp to open TCP ports 80 and 443. If you use Firewalld on RHEL/CentOS/Rocky Linux/AlmaLinux, run sudo firewall-cmd --permanent --add-service={http,https}, then sudo systemctl reload firewalld to open TCP ports 80 and 443.
Fail2ban. If your server uses fail2ban to block malicious requests, it could be that fail2ban banned your IP address. Run sudo journalctl -eu fail2ban to check if your IP address is banned. You can add your IP address to the fail2ban ignoreip list, so it won’t be banned again.
Nginx isn’t listening on the right network interface. For example, Nginx isn’t listening on the server’s public IP address.

If systemctl status nginx shows Nginx is running, but sudo ss -lnpt | grep nginx shows Nginx is not listening on TCP port 80/443, it could be that you deleted the following lines in the /etc/nginx/nginx.conf file.

include /etc/nginx/conf.d/*;

So Nginx doesn’t use the virtual host files in /etc/nginx/conf.d/ directory. Add this line back.

The Connection Has Timed Out

This could mean that your server is offline, or Nginx isn’t working properly. I once had an out-of-memory problem, which caused Nginx to fail to spawn the worker processes. If you can see the following error message in /var/log/nginx/error.log file, your server is short of memory.

fork() failed while spawning "worker process" (12: Cannot allocate memory)

404 Not Found

404 not found means Nginx can’t find the resources your web browser asks for. The reason could be:

The web root directory doesn’t exist on your server. In Nginx, the web roor directory is configured using the root directive, like this: root /usr/share/nginx/linuxbabe.com/;. Make sure your website files (HTML, CSS, JavaScript, PHP) are stored in the correct directory.
PHP-FPM isn’t running. You can check PHP-FPM status with sudo systemctl status php7.4-fpm (Debian/Ubuntu) or sudo systemctl status php-fpm.
You forgot to include the try_files $uri /index.php$is_args$args; directive in your Nginx server config file. This directive is needed to process PHP code.
Your server has no free disk space. Try to free up some disk space. You can use the ncdu utility (sudo apt install ncdu or sudo dnf install ncdu) to find out which directories are taking up huge amount of disk space.

403 Forbidden

This error means that you are not allowed to access the request resources. Possible scenario includes:

The website administrator blocks public access to the requested resources with an IP whitelist or other methods.
The website could be using a web application firewall like ModSecurity, which detected an intrusion attack, so it blocked the request.

Some web applications may show a different error message when 403 forbidden happens. It might tell you that “secure connection failed”, while the cause is the same.

500 Internal Server Error

This means there is some error in the web application. It could be that

The database server is down. Check MySQL/MariaDB status with sudo systemctl status mysql. Start it with sudo systemctl start mysql. Run sudo journalctl -eu mysql to find out why it fails to start. MySQL/MariaDB process could be killed due to out-of-memory issue.
You didn’t configure Nginx to use PHP-FPM, so Nginx doesn’t know how to execute PHP code.
If your web application has a built-in cache, you can try flushing the app cache to fix this error.
Your web application may produce its own error log. Check this log file to debug this error.
Your web application may have a debugging mode. Turn it on and you will see more detailed error messages on the web page. For example, you can turn on debugging mode in the Modoboa mail server hosting platform by setting DEBUG = True in the /srv/modoboa/instance/instance/settings.py file.
PHP-FPM could be overloaded. Check your PHP-FPM log (such as /var/log/php7.4-fpm.log). If you can find the [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers) warning message, you need to allocate more resources to PHP-FPM.
Sometimes reloading PHP-FPM (sudo systemctl reload php7.4-fpm) can fix the error.
It also might be that you didn’t install the database module for PHP, so PHP can’t connect to the database. For MySQL/MariaDB, install it with sudo apt install php7.4-mysql. For PostgreSQL, install it with sudo apt install php7.4-pgsql.

Nginx Shows the default page

If you try to set up an Nginx virtual host and when you type the domain name in your web browser, the default Nginx page shows up, it might be

Your Nginx virtual host file doesn’t have the server_name directive.
You didn’t use a real domain name for the server_name directive in your Nginx virtual host.
You forgot to reload Nginx.
You can try deleting the default virtual host file in Nginx (sudo rm /etc/nginx/sites-enabled/default).

The page isn’t redirecting properly

Firefox displays this error as The page isn’t redirecting properly. Google Chrome shows this error as www.example.com redirected you too many times.

This means you have configured Nginx redirection too many times. For example, you may have added an unnecessary return 301 directive in the https server block to redirect HTTP to HTTPS connection.

If you have set up a page cache such as Nginx FastCGI cache, you need to clear your server page cache.

504 Gateway time-out

This means the upstream like PHP-FPM/MySQL/MariaDB isn’t able to process the request fast enough. You can try restarting PHP-FPM to fix the error temporarily, but it’s better to start tuning PHP-FPM/MySQL/MariaDB for faster performance.

Optimize MySQL/MariaDB Performance

Here is the InnoDB configuration in my /etc/mysql/mariadb.conf.d/50-server.cnf file. This is a very simple performance tunning.

innodb_buffer_pool_size = 1024M
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup  = ON
innodb_log_file_size = 512M
innodb_log_buffer_size = 8M

#Improving disk I/O performance
innodb_file_per_table = 1
innodb_open_files = 400
innodb_io_capacity = 400
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_buffer_pool_instances = 3

Where:

The InnoDB buffer pool size needs to be at least half of your RAM. ( For VPS with small amount of RAM, I recommend setting the buffer pool size to a smaller value, like 400M, or your VPS would run out of RAM.)
InnoDB log file size needs to be 25% of the buffer pool size.
Set the read IO threads and write IO thread to the maximum (64) and
Make MariaDB use 3 instances of InnoDB buffer pool. The number of instances needs to be the same number of CPU cores on your system.

After saving the changes, restart MariaDB.

sudo systemctl restart mariadb

Recommended reading: MySQL/MariaDB Database Performance Monitoring with Percona on Ubuntu Server

Find Out Which PHP Script Caused 504 Error

You can check the web server access log to see if there are any bad requests. For example, some folks might find the following lines in the Nextcloud access log file (/var/log/nginx/nextcloud.access).

"GET /apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.1" 499 0 "-" "Nextcloud Server Crawler"
"GET /apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.1" 499 0 "-" "Nextcloud Server Crawler"
"GET /apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.1" 499 0 "-" "Nextcloud Server Crawler"

Notice the HTTP status code 499, which means the HTTP client quit the connection before the server gives back an answer. Successful HTTP code should be 2xx or 3xx. If you can find HTTP code 4xx, it means there’s a problem with this HTTP request. In this example, the Nextcloud richdocumentscode app isn’t working.

Increase Timeout Settings

You can also set a longer timeout value in Nginx to reduce the chance of gateway timeout. Edit your Nginx virtual host file and add the following lines in the server {...} block.

  proxy_connect_timeout       600;
  proxy_send_timeout          600;
  proxy_read_timeout          600;
  send_timeout                600;

If you use Nginx with PHP-FPM, then set the fastcgi_read_timeout to a bigger value like 300 seconds. Default is 60 seconds.

 location ~ .php$ {
     try_files $uri /index.php$is_args$args;
     include snippets/fastcgi-php.conf;
     fastcgi_split_path_info ^(.+.php)(/.+)$;

     fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     include fastcgi_params;
     fastcgi_read_timeout 300;
 }

Then reload Nginx.

sudo systemctl reload nginx

PHP-FPM also has a max execution time for each script. Edit the php.ini file.

sudo nano /etc/php/7.4/fpm/php.ini

You can increase the value to 300 seconds.

max_execution_time = 300

Then restart PHP-FPM

sudo systemctl restart php7.4-fpm

Memory Size Exhausted

If you see the following line in your Nginx error log, it means PHP reached the 128MB memory limit.

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134520 bytes)

You can edit the php.ini file (/etc/php/7.4/fpm/php.ini) and increase the PHP memory limit.

memory_limit = 512M

Then restart PHP7.4-FPM.

sudo systemctl restart php7.4-fpm

If the error still exists, it’s likely there’s bad PHP code in your web application that eats lots of RAM.

PR_END_OF_FILE_ERROR

You configured Nginx to rediect HTTP request to HTTPS, but there’s no server block in Nginx serving HTTPS request.
Maybe Nginx isn’t running?
Sometimes, the main Nginx binary is running, but a worker process can fail and exit due to various reasons. Check the Nginx error log (/var/log/nginx/error.log) to debug.

PHP-FPM Upstream Time Out

Some folks can find the following error in Nginx error log file ( under /var/log/nginx/).

[error] 7553#7553: *2234677 upstream timed out (110: Connection timed out) while reading response header from upstream

Possible solutions:

Restart PHP-FPM.
Upgrade RAM.
Optimize database performance. Because PHP-FPM needs to fetch data from the database, if the database is slow to process requests, PHP-FPM will time out.

502 Bad Gateway

This error could be caused by:

PHP-FPM isn’t running. Check its status: sudo systemctl status php7.4-fpm.
PHP-FPM is running, but Nginx isn’t able to connect to PHP-FPM (Resource temporarily unavailable), see how to fix this error below.
PHP-FPM is running, but Nginx doesn’t have permission to connect to PHP-FPM socket (Permission denied). It might be that Nginx is running as nginx user, but the socket file /run/php/php7.4-fpm.sock is owned by the www-data user. You should configure Nginx to run as the www-data user.

Resource temporarily unavailable

Some folks can find the following error in Nginx error log file ( under /var/log/nginx/).

connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable)

This usually means your website has lots of visitors and PHP-FPM is unable to process the huge amounts of requests. You can adjust the number of PHP-FPM child process, so it can process more requests.

Edit your PHP-FPM www.conf file. (The file path varies depending on your Linux distribution.)

sudo nano /etc/php/7.4/fpm/pool.d/www.conf

The default child process config is as follows:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

The above configuration means

PHP-FPM dynamically create child processes. No fixed number of child processes.
It creates at most 5 child processes.
Start 2 child processes when PHP-FPM starts.
There’s at least 1 idle process.
There’s at most 3 idle processes.

The defaults are based on a server without much resources, like a server with only 1GB RAM. If you have a high traffic website, you probably want to increase the number of child processes, so it can serve more requests. (Make sure you have enough RAM to run more child processes.)

pm = dynamic
pm.max_children = 20
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12

Save and close the file. Then we also increase the PHP memory limit.

sudo nano /etc/php/7.4/fpm/php.ini

Find the following line.

memory_limit = 128M

By default, a script can use at most 128M memory. It’s recommended to set this number to at lest 512M.

memory_limit = 512M

Save and close the file. Restart PHP-FPM. (You might need to change the version number.)

sudo systemctl restart php7.4-fpm

To monitor the health of PHP-FPM, you can enable the status page. Find the following line in the PHP-FPM www.conf file.

;pm.status_path = /status

Remove the semicolon to enable PHP-FPM status page. Then restart PHP-FPM.

sudo systemctl restart php7.4-fpm

Then edit your Nginx virtual host file. Add the following lines. The allow and deny directives are used to restrict access. Only the whitelisted IP addresses can access the status page.

location ~ ^/(status|ping)$ {
        allow 127.0.0.1;
        allow your_other_IP_Address;
        deny all;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
        include fastcgi_params;
        #fastcgi_pass 127.0.0.1:9000;
        fastcgi_pass   unix:/run/php/php7.4-fpm.sock;
}

Save and close the file. Then test Nginx configurations.

sudo nginx -t

If the test is successful, reload Nginx for the changes to take effect.

sudo systemctl reload nginx

Sample PHP-FPM status page.

The PHP-FPM www.conf file gives you a good explanation of what each parameter means.

If PHP-FPM is very busy and unable to serve a request immediately, it will queue this request. By default, there can be at most 511 pending requests, determined by the listen.backlog parameter.

listen.backlog = 511

If you see the following value on the PHP-FPM status page, it means there has never been a request put in the queue, i.e. your PHP-FPM can process requests quickly.

listen queue:         0
max listen queue:     0

If there are 511 pending requests in the queue, it means your PHP-FPM is very busy, so you should increase the number of child processes.

You may also need to change the Linux kernel net.core.somaxconn setting, which defines max number of connections allowed to a socket file on Linux, such as the PHP-FPM Unix socket file. By default, its value is 128 before kernel 5.4 and 4096 starting with kernel 5.4.

[email protected]:~$ sysctl net.core.somaxconn
net.core.somaxconn = 128

If you run a high traffic website, you can use a big value. Edit /etc/sysctl.conf file.

sudo nano /etc/sysctl.conf

Add the following two lines.

net.core.somaxconn = 20000
net.core.netdev_max_backlog = 65535

Save and close the file. Then apply the settings.

sudo sysctl -p

Note: If your server has enough RAM, you can allocate a fixed number of child processes for PHP-FPM like below. In my experience, this fixed the 500 internal error for a Joomla + Virtuemart website.

pm = static
pm.max_children = 50

Two Virtual Host files For the Same Website

If you run sudo nginx -t and see the following warning.

nginx: [warn] conflicting server name "example.com" on [::]:443, ignored
nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored

It means there are two virtual host files that contain the same server_name configuration. Don’t create two virtual host files for one website.

PHP-FPM Connection reset by peer

Nginx error log file shows the following message.

recv() failed (104: Connection reset by peer) while reading response header from upstream

This may be caused by a restart of PHP-FPM. If it’s retarted manually by yourself, then you can ignore this error.

Nginx Socket Leaks

If you find the following error message in the /var/log/nginx/error.log file, your Nginx has a socket leaks problem.

2021/09/28 13:27:41 [alert] 321#321: *120606 open socket #16 left in connection 163
2021/09/28 13:27:41 [alert] 321#321: *120629 open socket #34 left in connection 188
2021/09/28 13:27:41 [alert] 321#321: *120622 open socket #9 left in connection 213
2021/09/28 13:27:41 [alert] 321#321: *120628 open socket #25 left in connection 217
2021/09/28 13:27:41 [alert] 321#321: *120605 open socket #15 left in connection 244
2021/09/28 13:27:41 [alert] 321#321: *120614 open socket #41 left in connection 245
2021/09/28 13:27:41 [alert] 321#321: *120631 open socket #24 left in connection 255
2021/09/28 13:27:41 [alert] 321#321: *120616 open socket #23 left in connection 258
2021/09/28 13:27:41 [alert] 321#321: *120615 open socket #42 left in connection 269
2021/09/28 13:27:41 [alert] 321#321: aborting

You can restart the OS to solve this problem. If it doesn’t work, you need to compile a debug version of Nginx, which will show you debug info in the log.

invalid PID number “” in “/run/nginx.pid”

You need to restart your web server.

sudo pkill nginx
sudo systemctl restart nginx

Cloudflare Errors

Here are some common errors and solutions if your website runs behind Cloudflare CDN (Content Delivery Network).

521 Web Server is Down

Nginx isn’t running.
You didn’t open TCP ports 80 and 443 in the firewall.
You changed the server IP address, but forgot to update DNS record in Cloudflare.

The page isn’t redirecting properly

If your SSL setting on the SSL/TLS app is set to Flexible, but your origin server is configured to redirect HTTP requests to HTTPS, Your Nginx server sends reponse back to Cloudflare in encrypted connection. Since Cloudflare is expecting HTTP traffic, it keeps resending the same request, resulting in a redirect loop. In this case, you need to use the Full (strict) SSL/TLS option in your Cloudflare settings.

Wrapping Up

I hope this article helped you to fix common Nginx web server errors. As always, if you found this post useful, then subscribe to our free newsletter to get more tips and tricks 🙂

You may want to check out:

How to Fix Common Let’s Encrypt/Certbot Errors

Источник

Nginx – очень популярный веб-сервер в наши дни.

В этой статье мы расскажем вам о некоторых распространенных ошибках при работе веб-сервера Nginx и возможных решениях.

Это не полный список.

Если вы все еще не можете устранить ошибку, попробовав предложенные решения, пожалуйста, проверьте логи сервера Nginx в каталоге /var/log/nginx/ и поищите в Google, чтобы отладить проблему.

Содержание

Unable to connect/Refused to Connect
The Connection Has Timed Out
404 Not Found
403 Forbidden
500 Internal Server Error
Nginx показывает страницу по умолчанию
504 Gateway time-out
Размер памяти исчерпан
PR_END_OF_FILE_ERROR
Resource temporarily unavailable
Два файла виртуального хоста для одного и того же сайта
PHP-FPM Connection reset by peer
Утечки сокетов Nginx
Заключение

Unable to connect/Refused to Connect

Если при попытке получить доступ к вашему сайту вы видите следующую ошибку:

Firefox can’t establish a connection to the server at www.example.com

или

www.example.com refused to connect

или

The site can't be reached, www.example.com unexpectedly closed the connection.

Это может быть потому, что:

Nginx не запущен. Вы можете проверить состояние Nginx с помощью sudo systemctl status nginx. Запустите Nginx с помощью sudo systemctl start nginx. Если Nginx не удается запустить, запустите sudo nginx -t, чтобы выяснить, нет ли ошибок в вашем конфигурационном файле. И проверьте логи (sudo journalctl -eu nginx), чтобы выяснить, почему он не запускается.
Брандмауэр блокирует порты 80 и 443. Если вы используете брандмауэр UFW на Debian/Ubuntu, выполните sudo ufw allow 80,443/tcp, чтобы открыть TCP порты 80 и 443. Если вы используете Firewalld на RHEL/CentOS/Rocky Linux/AlmaLinux, выполните sudo firewall-cmd –permanent –add-service={http,https}, затем sudo systemctl reload firewalld, чтобы открыть TCP порты 80 и 443.
Fail2ban. Если ваш сервер использует fail2ban для блокировки вредоносных запросов, возможно, fail2ban запретил ваш IP-адрес. Выполните команду sudo journalctl -eu fail2ban, чтобы проверить, не заблокирован ли ваш IP-адрес. Вы можете добавить свой IP-адрес в список fail2ban ignoreip, чтобы он больше не был забанен.
Nginx не прослушивает нужный сетевой интерфейс. Например, Nginx не прослушивает публичный IP-адрес сервера.

The Connection Has Timed Out

Это может означать, что ваш сервер находится в автономном режиме или Nginx работает неправильно.

Однажды у меня возникла проблема нехватки памяти, из-за чего Nginx не смог запустить рабочие процессы.

Если вы увидите следующее сообщение об ошибке в файле /var/log/nginx/error.log, вашему серверу не хватает памяти:

fork() failed while spawning "worker process" (12: Cannot allocate memory)

404 Not Found

404 not found означает, что Nginx не может найти ресурсы, которые запрашивает ваш веб-браузер.

🌐 Как создать пользовательскую страницу ошибки 404 в NGINX

Причина может быть следующей:

Корневой каталог web не существует на вашем сервере. В Nginx корневой веб-каталог настраивается с помощью директивы root, например, так: root /usr/share/nginx/linuxbabe.com/;. Убедитесь, что файлы вашего сайта (HTML, CSS, JavaScript, PHP) хранятся в правильном каталоге.
PHP-FPM не запущен. Вы можете проверить статус PHP-FPM с помощью sudo systemctl status php7.4-fpm (Debian/Ubuntu) или sudo systemctl status php-fpm.
Вы забыли включить директиву try_files $uri /index.php$is_args$args; в конфигурационный файл сервера Nginx. Эта директива необходима для обработки PHP-кода.
На вашем сервере нет свободного дискового пространства. Попробуйте освободить немного дискового пространства. Вы можете использовать утилиту ncdu (sudo apt install ncdu или sudo dnf install ncdu), чтобы узнать, какие каталоги занимают огромное количество дискового пространства.

403 Forbidden

Эта ошибка означает, что вам не разрешен доступ к ресурсам запроса.

Возможный сценарий включает:

Администратор сайта блокирует публичный доступ к запрашиваемым ресурсам с помощью белого списка IP-адресов или других методов.
На сайте может использоваться брандмауэр веб-приложения, например ModSecurity, который обнаружил атаку вторжения, поэтому заблокировал запрос.
Некоторые веб-приложения могут показывать другое сообщение об ошибке, когда происходит запрет 403. Оно может сказать вам, что “secure connection failed, хотя причина та же.

500 Internal Server Error

Это означает, что в веб-приложении произошла какая-то ошибка.

Это может быть следующее

Сервер базы данных не работает. Проверьте состояние MySQL/MariaDB с помощью sudo systemctl status mysql. Запустите его с помощью sudo systemctl start mysql. Запустите sudo journalctl -eu mysql, чтобы выяснить, почему он не запускается. Процесс MySQL/MariaDB может быть завершен из-за проблем с нехваткой памяти.
Вы не настроили Nginx на использование PHP-FPM, поэтому Nginx не знает, как выполнять PHP-код.
Если ваше веб-приложение имеет встроенный кэш, вы можете попробовать очистить кэш приложения, чтобы исправить эту ошибку.
Ваше веб-приложение может создавать свой собственный журнал ошибок. Проверьте этот файл журнала, чтобы отладить эту ошибку.
Возможно, в вашем веб-приложении есть режим отладки. Включите его, и вы увидите более подробные сообщения об ошибках на веб-странице. Например, вы можете включить режим отладки в почтовом сервере хостинг-платформы Modoboa, установив DEBUG = True в файле /srv/modoboa/instance/instance/settings.py.
PHP-FPM может быть перегружен. Проверьте журнал PHP-FPM (например, /var/log/php7.4-fpm.log). Если вы обнаружили предупреждение [pool www] seems busy (возможно, вам нужно увеличить pm.start_servers, или pm.min/max_spare_servers), вам нужно выделить больше ресурсов для PHP-FPM.
Иногда перезагрузка PHP-FPM (sudo systemctl reload php7.4-fpm) может исправить ошибку.

Nginx показывает страницу по умолчанию

Если вы пытаетесь настроить виртуальный хост Nginx и при вводе доменного имени в веб-браузере отображается страница Nginx по умолчанию, это может быть следующее

Вы не использовали реальное доменное имя для директивы server_name в виртуальном хосте Nginx.
Вы забыли перезагрузить Nginx.

504 Gateway time-out

Это означает, что апстрим, такой как PHP-FPM/MySQL/MariaDB, не может обработать запрос достаточно быстро.

Вы можете попробовать перезапустить PHP-FPM, чтобы временно исправить ошибку, но лучше начать настраивать PHP-FPM/MySQL/MariaDB для более быстрой работы.

Вот конфигурация InnoDB в моем файле /etc/mysql/mariadb.conf.d/50-server.cnf.

Это очень простая настройка производительности.

innodb_buffer_pool_size = 1024M
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup  = ON
innodb_log_file_size = 512M
innodb_log_buffer_size = 8M

#Improving disk I/O performance
innodb_file_per_table = 1
innodb_open_files = 400
innodb_io_capacity = 400
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_buffer_pool_instances = 3

Где:

InnoDB buffer pool size должен быть не менее половины вашей оперативной памяти. (Для VPS с небольшим объемом оперативной памяти я рекомендую установить размер буферного пула на меньшее значение, например 400M, иначе ваш VPS будет работать без оперативной памяти).
InnoDB log file size должен составлять 25% от размера буферного пула.
Установите потоки ввода-вывода для чтения и записи на максимум (64).
Заставьте MariaDB использовать 3 экземпляра буферного пула InnoDB. Количество экземпляров должно соответствовать количеству ядер процессора в вашей системе.
После сохранения изменений перезапустите MariaDB.

После сохранения изменений перезапустите MariaDB.

sudo systemctl restart mariadb

Вы также можете установить более длительное значение тайм-аута в Nginx, чтобы уменьшить вероятность тайм-аута шлюза.

Отредактируйте файл виртуального хоста Nginx и добавьте следующие строки в блок server {…}.

  proxy_connect_timeout       600;
  proxy_send_timeout          600;
  proxy_read_timeout          600;
  send_timeout                600;

Если вы используете Nginx с PHP-FPM, то установите для параметра fastcgi_read_timeout большее значение, например 300 секунд.

По умолчанию это 60 секунд.

 location ~ .php$ {
     try_files $uri /index.php$is_args$args;
     include snippets/fastcgi-php.conf;
     fastcgi_split_path_info ^(.+.php)(/.+)$;

     fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     include fastcgi_params;
     fastcgi_read_timeout 300;
 }

Затем перезагрузите Nginx.

sudo systemctl reload nginx

PHP-FPM также имеет максимальное время выполнения для каждого скрипта.

Отредактируйте файл php.ini.

sudo nano /etc/php/7.4/fpm/php.ini

Вы можете увеличить это значение до 300 секунд.

max_execution_time = 300

Затем перезапустите PHP-FPM

sudo systemctl restart php7.4-fpm

Размер памяти исчерпан

Если вы видите следующую строку в журнале ошибок Nginx, это означает, что PHP достиг лимита памяти в 128 МБ.

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134520 bytes)

Вы можете отредактировать файл php.ini (/etc/php/7.4/fpm/php.ini) и увеличить лимит памяти PHP.

memory_limit = 512M

Затем перезапустите PHP7.4-FPM.

sudo systemctl restart php7.4-fpm

Если ошибка все еще существует, скорее всего, в вашем веб-приложении плохой PHP-код, который потребляет много оперативной памяти.

PR_END_OF_FILE_ERROR

Вы настроили Nginx на перенаправление HTTP-запросов на HTTPS, но в Nginx нет блока сервера, обслуживающего HTTPS-запросы.
Может быть, Nginx не запущен?
Иногда основной бинарник Nginx запущен, но рабочий процесс может не работать и завершиться по разным причинам. Для отладки проверьте логи ошибок Nginx (/var/log/nginx/error.log).

Resource temporarily unavailable

Некоторые пользователи могут найти следующую ошибку в файле логов ошибок Nginx (в разделе /var/log/nginx/).

connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable)

Обычно это означает, что на вашем сайте много посетителей и PHP-FPM не справляется с обработкой огромного количества запросов.

Вы можете изменить количество дочерних процессов PHP-FPM, чтобы он мог обрабатывать больше запросов.

Отредактируйте файл PHP-FPM www.conf.

(Путь к файлу зависит от дистрибутива Linux).

sudo /etc/php/7.4/fpm/pool.d/www.conf

По умолчанию конфигурация дочернего процесса выглядит следующим образом:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Приведенная выше конфигурация означает.

PHP-FPM динамически создает дочерние процессы. Нет фиксированного количества дочерних процессов.
Создается не более 5 дочерних процессов.
При запуске PHP-FPM запускаются 2 дочерних процесса.
Есть как минимум 1 незанятый процесс.
Максимум 3 неработающих процесса.

pm = dynamic
pm.max_children = 20
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12

Убедитесь, что у вас достаточно оперативной памяти для запуска дополнительных дочерних процессов.

Сохраните и закройте файл.

Затем перезапустите PHP-FPM. (Возможно, вам потребуется изменить номер версии).

sudo systemctl restart php7.4-fpm

Чтобы следить за состоянием PHP-FPM, вы можете включить страницу status .

Найдите следующую строку в файле PHP-FPM www.conf.

Обратите внимание, что

;pm.status_path = /status

Уберите точку с запятой, чтобы включить страницу состояния PHP-FPM.

Затем перезапустите PHP-FPM.

sudo systemctl restart php7.4-fpm

Затем отредактируйте файл виртуального хоста Nginx.

Добавьте следующие строки.

Директивы allow и deny используются для ограничения доступа.

Только IP-адреса из “белого списка” могут получить доступ к странице состояния.

location ~ ^/(status|ping)$ {
        allow 127.0.0.1;
        allow your_other_IP_Address;
        deny all;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
        include fastcgi_params;
        #fastcgi_pass 127.0.0.1:9000;
        fastcgi_pass   unix:/run/php/php7.4-fpm.sock;
}

Сохраните и закройте файл. Затем протестируйте конфигурацию Nginx.

sudo nginx -t

Если проверка прошла успешно, перезагрузите Nginx, чтобы изменения вступили в силу.

sudo systemctl reload nginx

В файле PHP-FPM www.conf дается хорошее объяснение того, что означает каждый параметр.

Если PHP-FPM очень занят и не может обслужить запрос немедленно, он поставит его в очередь.

По умолчанию может быть не более 511 ожидающих запросов, определяемых параметром listen.backlog.

listen.backlog = 511

Если вы видите следующее значение на странице состояния PHP-FPM, это означает, что в очереди еще не было ни одного запроса, т.е. ваш PHP-FPM может быстро обрабатывать запросы.

listen queue:         0
max listen queue:     0

Если в очереди 511 ожидающих запросов, это означает, что ваш PHP-FPM очень загружен, поэтому вам следует увеличить количество дочерних процессов.

Вам также может понадобиться изменить параметр ядра Linux net.core.somaxconn, который определяет максимальное количество соединений, разрешенных к файлу сокетов в Linux, например, к файлу сокетов PHP-FPM Unix.

По умолчанию его значение равно 128 до ядра 5.4 и 4096 начиная с ядра 5.4.

$ sysctl net.core.somaxconn
net.core.somaxconn = 128

Если у вас сайт с высокой посещаемостью, вы можете использовать большое значение.

Отредактируйте файл /etc/sysctl.conf.

sudo nano /etc/sysctl.cnf

Добавьте следующие две строки.

net.core.somaxconn = 20000
net.core.netdev_max_backlog = 65535

Сохраните и закройте файл. Затем примените настройки.

sudo sysctl -p

Примечание: Если ваш сервер имеет достаточно оперативной памяти, вы можете выделить фиксированное количество дочерних процессов для PHP-FPM, как показано ниже.

Два файла виртуального хоста для одного и того же сайта

Если вы запустите sudo nginx -t и увидите следующее предупреждение.

nginx: [warn] conflicting server name "example.com" on [::]:443, ignored
nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored

Это означает, что есть два файла виртуальных хостов, содержащих одну и ту же конфигурацию server_name.

Не создавайте два файла виртуальных хостов для одного сайта.

PHP-FPM Connection reset by peer

В файле логов ошибок Nginx отображается следующее сообщение.

recv() failed (104: Connection reset by peer) while reading response header from upstream

Это может быть вызвано перезапуском PHP-FPM.

Если он перезапущен вручную самостоятельно, то вы можете игнорировать эту ошибку.

Утечки сокетов Nginx

Если вы обнаружили следующее сообщение об ошибке в файле /var/log/nginx/error.log, значит, у вашего Nginx проблема с утечкой сокетов.

2021/09/28 13:27:41 [alert] 321#321: *120606 open socket #16 left in connection 163
2021/09/28 13:27:41 [alert] 321#321: *120629 open socket #34 left in connection 188
2021/09/28 13:27:41 [alert] 321#321: *120622 open socket #9 left in connection 213
2021/09/28 13:27:41 [alert] 321#321: *120628 open socket #25 left in connection 217
2021/09/28 13:27:41 [alert] 321#321: *120605 open socket #15 left in connection 244
2021/09/28 13:27:41 [alert] 321#321: *120614 open socket #41 left in connection 245
2021/09/28 13:27:41 [alert] 321#321: *120631 open socket #24 left in connection 255
2021/09/28 13:27:41 [alert] 321#321: *120616 open socket #23 left in connection 258
2021/09/28 13:27:41 [alert] 321#321: *120615 open socket #42 left in connection 269
2021/09/28 13:27:41 [alert] 321#321: aborting

Вы можете перезапустить ОС, чтобы решить эту проблему.

Если это не помогает, вам нужно скомпилировать отладочную версию Nginx, которая покажет вам отладочную информацию в логах.

Заключение

Надеюсь, эта статья помогла вам исправить распространенные ошибки веб-сервера Nginx.

см. также:

🌐 Как контролировать доступ на основе IP-адреса клиента в NGINX
🐉 Настройка http-сервера Kali Linux
🌐 Как парсить логи доступа nginx
🌐 Ограничение скорости определенных URL-адресов с Nginx
🛡️ Как использовать обратный прокси Nginx для ограничения внешних вызовов внутри веб-браузера
🔏 Как настроить Nginx с Let’s Encrypt с помощью ACME на Ubuntu
🌐 Как собрать NGINX с ModSecurity на Ubuntu сервере

Источник

Default:
Syntax:	postpone_output size ;
Context:	http , server , location

Default:
Syntax:	read_ahead size ;
Context:	http , server , location

Default:
Syntax:	recursive_error_pages on \| off ;
Context:	http , server , location

Default:
Syntax:	reset_timedout_connection on \| off ;
Context:	http , server , location

Syntax:	resolver address . [ valid = time ] [ ipv4 = on \| off ] [ ipv6 = on \| off ] [ status_zone = zone ];
Default:	—
Context:	http , server , location

Default:
Syntax:	resolver_timeout time ;
Context:	http , server , location

Default:
Syntax:	root path ;
Context:	http , server , location , if in location

Default:
Syntax:	satisfy all \| any ;
Context:	http , server , location

Default:
Syntax:	send_lowat size ;
Context:	http , server , location

Default:
Syntax:	send_timeout time ;
Context:	http , server , location

Default:
Syntax:	sendfile on \| off ;
Context:	http , server , location , if in location

Default:
Syntax:	sendfile_max_chunk size ;
Context:	http , server , location

Default:
Syntax:	server_name_in_redirect on \| off ;
Context:	http , server , location

Default:
Syntax:	server_names_hash_bucket_size size ;
Context:	http

Default:
Syntax:	server_tokens on \| off \| build \| string ;
Context:	http , server , location

Default:
Syntax:	subrequest_output_buffer_size size ;
Context:	http , server , location

Default:
Syntax:	tcp_nodelay on \| off ;
Context:	http , server , location

Default:
Syntax:	tcp_nopush on \| off ;
Context:	http , server , location

Syntax:	try_files file . uri ; try_files file . = code ;
Default:	—
Context:	server , location

Default:
Syntax:	types_hash_bucket_size size ;
Context:	http , server , location

Как включить режим отладки Nginx?

Как исправить «404 Not Found Nginx»?

1. Регулярные выражения

2. Недостаточно памяти

3. Не найден index

4. Другие проблемы

Выводы

Ошибка 404 not found Nginx

Почему возникает ошибка 404 в Nginx

Как включить режим отладки Nginx?

Как исправить «404 Not Found Nginx»?

1. Регулярные выражения

2. Недостаточно памяти

3. Не найден index

4. Другие проблемы

Выводы

<img decoding="async" onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" src="http://nginx.org/nginx.png" />

Module ngx_http_core_module

Directives

Embedded Variables

Директивы

Встроенные переменные

Что означает ошибка 404 в Nginx

Как исправить ошибку 404 в Nginx

Как исправить ошибку 404 Nginx с помощью онлайн-инструментов

W3C Проверить ссылку

Check My Links

Broken Link Checker

Заключение

Unable to connect/Refused to Connect

The Connection Has Timed Out

404 Not Found

403 Forbidden

500 Internal Server Error

Nginx Shows the default page

The page isn’t redirecting properly

504 Gateway time-out

Find Out Which PHP Script Caused 504 Error

Memory Size Exhausted

PR_END_OF_FILE_ERROR

PHP-FPM Upstream Time Out

502 Bad Gateway

Resource temporarily unavailable

Two Virtual Host files For the Same Website

PHP-FPM Connection reset by peer

Nginx Socket Leaks

invalid PID number “” in “/run/nginx.pid”

Cloudflare Errors

521 Web Server is Down

The page isn’t redirecting properly

Wrapping Up

Unable to connect/Refused to Connect

The Connection Has Timed Out

404 Not Found

403 Forbidden

500 Internal Server Error

Nginx показывает страницу по умолчанию

504 Gateway time-out

Размер памяти исчерпан

PR_END_OF_FILE_ERROR

Resource temporarily unavailable

Два файла виртуального хоста для одного и того же сайта

PHP-FPM Connection reset by peer

Утечки сокетов Nginx

Заключение

Default:
Syntax:	types_hash_max_size size ;
Context:	http , server , location

Default:
Syntax:	underscores_in_headers on \| off ;
Context:	http , server