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

При разработке веб-сайтов и веб-приложений можно столкнуться с ошибкой 500 internal server error. Сначала она может испугать и ввести в заблуждение, поскольку обычно веб-сервер выдает более конкретные ошибки, в которых указана точная причина проблемы, например, превышено время ожидания, неверный запрос или файл не найден, а тут просто сказано что, обнаружена внутренняя ошибка.

Но не все так страшно и в большинстве случаев проблема вполне решаема и очень быстро. В этой статье мы разберем как исправить ошибку Internal server error в Nginx.

Дословно Internal server error означает внутренняя ошибка сервера. И вызвать её могут несколько проблем. Вот основные из них:

Ошибки в скрипте на PHP — одна из самых частых причин;
Превышено время выполнения PHP скрипта или лимит памяти;
Неправильные права на файлы сайта;
Неверная конфигурация Nginx.

А теперь рассмотрим каждую из причин более подробно и разберем варианты решения.

1. Ошибка в скрипте PHP

Мы привыкли к тому, что если в PHP скрипте есть ошибки, то сразу же видим их в браузере. Однако на производственных серверах отображение сообщений об ошибках в PHP отключено, чтобы предотвратить распространение информации о конфигурации сервера для посторонних. Nginx не может отобразить реальную причину ошибки, потому что не знает что за ошибка произошла, а поэтому выдает универсальное сообщение 500 internal server error.

Чтобы исправить эту ошибку, нужно сначала понять где именно проблема. Вы можете включить отображение ошибок в конфигурационном файле php изменив значение строки display_errors с off на on. Рассмотрим на примере Ubuntu и PHP 7.2:

vi /etc/php/7.2/php.ini

display_errors = On

Перезапустите php-fpm:

sudo systemctl restart php-fpm

Затем обновите страницу и вы увидите сообщение об ошибке, из-за которого возникла проблема. Далее его можно исправить и отключить отображение ошибок, тогда все будет работать. Ещё можно посмотреть сообщения об ошибках PHP в логе ошибок Nginx. Обычно он находится по пути /var/log/nginx/error.log, но для виртуальных доменов может настраиваться отдельно. Например, смотрим последние 100 строк в логе:

tail -n 100 -f /var/log/nginx/error.log

Теперь аналогично, исправьте ошибку и страница будет загружаться нормально, без ошибки 500.

2. Превышено время выполнения или лимит памяти

Это продолжение предыдущего пункта, так тоже относится к ошибкам PHP, но так, как проблема встречается довольно часто я решил вынести её в отдельный пункт. В файле php.ini установлены ограничения на время выполнения скрипта и количество оперативной памяти, которую он может потребить. Если скрипт потребляет больше, интерпретатор PHP его убивает и возвращает сообщение об ошибке.

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

Если же отображение ошибок отключено, мы получаем error 500. Обратите внимание, что если время ожидания было ограничено в конфигурационном файле Nginx, то вы получите ошибку 504, а не HTTP ERROR 500, так что проблема именно в php.ini.

Чтобы решить проблему увеличьте значения параметров max_execution_time и memory_limit в php.ini:

sudo vi /etc/php/7.2/php.ini

max_execution_time 300 memory_limit 512M

Также проблема может быть вызвана превышением других лимитов установленных для скрипта php. Смотрите ошибки php, как описано в первом пункте. После внесения изменений в файл перезапустите php-fpm:

sudo systemctl restart php-fpm

3. Неверные права на файлы

Такая ошибка может возникать, если права на файлы, к которым обращается Nginx установлены на правильно. Сервисы Nginx и php-fpm должны быть запущены от имени одного и того же пользователя, а все файлы сайтов должны принадлежать этому же пользователю. Посмотреть от имени какого пользователя запущен Nginx можно командой:

nginx -T | grep user

Чтобы узнать от какого пользователя запущен php-fpm посмотрите содержимое конфигурационного файла используемого пула, например www.conf:

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

В моем случае это пользователь nginx. Теперь надо убедится, что файлы сайта, к которым вы пытаетесь обратиться принадлежат именно этому пользователю. Для этого используйте команду namei:

namei -l /var/www/site

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

sudo chown nginx:nginx -R /var/www/site

Этой командой мы меняем владельца и группу всех файлов в папке на nginx:nginx. Добавить права на чтение для всех пользователей для каталога можно командой chmod. Например:

sudo chmod o+r /var/www/

Далее все должно работать. Также, проблемы с правами может вызывать SELinux. Настройте его правильно или отключите:

setenforce 0

Выводы

В этой статье мы разобрали что делать если на вашем сайте встретилась ошибка 500 internal server error nginx. Как видите проблема вполне решаема и в большинстве случаев вам помогут действия описанные в статье. А если не помогут, напишите свое решение в комментариях!

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

Источник

Sometimes NGINX server may give 500 Internal Server Error due to various reasons. In this article we will look at what does 500 Internal Server Error mean in NGINX and how to fix 500 Internal Server Error in NGINX.

NGINX gives 500 Internal Server Error when there is a server-side error that prevents NGINX from returning a proper response. It can be due to many different reasons such as faulty script, missing files referenced by code, inadequate file permissions, etc. NGINX is typically used as a reverse proxy server, so the most common reason for 500 Internal server is an error in one of its web servers like Apache that has encountered an issue and returned a 500 error response to NGINX, which is then returned to client browsers. There are various ways to fix internal server error in NGINX.

Bonus Read : How To Fix 504 Gateway Timeout Error in NGINX

How to Fix 500 Internal Server Error in NGINX

Here are the steps to fix 500 Internal Server Error in NGINX on localhost, CPanel, PHP, Ubuntu and other platforms.

1. Hard Refresh

Sometimes you may get 500 internal server error in NGINX because your server is being restarted at that moment, or there are too many requests for web server to handle.

So it doesn’t have enough resources to serve your request.

In such cases, you can simply do a hard refresh of your page to force the browser to get latest web page version and fix 500 internal server error in NGINX. You can do this by pressing

Windows: Ctrl + F5
Mac: Apple + R or Cmd + R
Linux: F5

Bonus Read : How to Fix 502 Bad Gateway Error in NGINX

2. Examine Server Logs

Open your server log in a text editor to analyze the most recent requests. Every server log contains information about requested URLs and response code for each request.

Find out which requests result in 500 internal server error. It may be that only one page, or a few pages give this error while others work fine.

Find out which requests cause 500 internal server error. Once you have identified the problematic URLs, open a browser and request them again to confirm that is indeed the case.

Bonus Read : How to Increase Request Timeout in NGINX

3. Examine Your Script

Next, analyze the script to process the problematic requests. Is it actually present at the right location? Are you referencing it properly, in your URL mapping/routing file?

If your script refers to another file, find out if that file path is correct. If you have referenced any program/function, have you called it correctly?

4. Check File/Folder Permission

This can also be due to improper file/folder permissions. Did you add/modify any file/folder recently?

Typically, files need a 644 permission and folders need a 755 permission. You can use FileZilla (Windows) and Chmod (Linux) to modify file permissions.

You can also look at the permissions of other files & folders in your code and update the same for your files/folders accordingly.

Bonus Read : How to Increase File Upload Size in NGINX

5. Check redirections

If you have incorrectly setup any redirections in web server, it can give 500 internal server error. For example, if you use Apache web server, make sure you have properly configured mod_rewrite module and .htaccess file.

Also use a third-party tool to check the syntax of redirection/URL rewrite rules in your server configuration file.

6. Increase Script Timeout

You may also get 500 internal server error in NGINX if your web server (e.g Apache) is timing out on the request. In such cases, increase your web server (not NGINX) timeout value so that it stays connected to NGINX longer, and returns a proper response.

Hopefully, the above tips will help you fix 500 internal server error in NGINX.

Ubiq makes it easy to visualize data in minutes, and monitor in real-time dashboards. Try it Today!

About Author

Источник

To start talking about the 500 internal server error Nginx, let’s clarify some terms.

This is a term applicable to a kind of server, characterized by belonging to the open source classification, additionally, Nginx provides the possibility of very low memory consumption, and allow without problems high concurrences, higher than 10,000 simultaneous connections.

500 internal server error, meaning

They are the acronym used to notify irregularities, inconveniences in a server, and that due to these, it is not possible to carry out the requested action.

The errors like this one, are notified according to the browsers in which one works, to the technical variety, to the functional that exists between the servers, since all are different, as far as structure, architecture, and capacities, also to the websites, these count on characteristics that most of the time are not similar, all these considerations are the cause so that the mentioned errors are shown in a variety of ways.

Although all variations convey the existence of a problem, 500 internal server error Nginx will always be understood, as the message displayed is explicit.

In addition, they are complemented through fragments with text with detailed data of what happens with this server, and why it is not possible to execute the action you want to perform, these details, and the way they are displayed vary depending on the type of server, being able to be completely blank screens, others are displayed customized, as the case of some famous sites, YouTube is one of them, Airbnb, and so each brand uses its customization to identify this message differentiating itself from others.

500 internal server error Nginx, what causes it?

Among the situations that originate the appearance of an error of this type, can be cataloged from various sources, there are a variety that occur very frequently, and the chances that these are the origin of the error are usually high.

Problems that prevent the proper functioning of the browser’s fastest storage layer.
Corruption problems, this occurs when trying to work with databases.
Some corrupted file, this occurs when requesting access to the website.
The server is not able at a given time.
With the login you try to access, this happens when you use it wrongly.
Folders and files with attributes different from the ones they have.
When it is on the PHP side, it happens directly because of trying to make use of a larger memory range than the established one.
Defective Htacces, these files in these conditions prevent the operation of the site.
Plugins, if they fail, the following error will appear

500 internal server error Nginx, Solutions for this error

They can appear in the part of the area corresponding to the user, or the part corresponding to the server, the important thing is to attack the problem quickly, so that the damages are minor, these can be some solutions:

Reload the page

You should start with an action that is recommended, and that in many cases is the fastest eliminating the problem, very simple, load the page again, just wait about 50 to 60 seconds, then proceed to the restart to display the page, just press F5, in some sites Ctrl followed by F5, the error will disappear if it was generated by the server not being protected against overload, after the action is done, it will be restored immediately.

Check where the problem is with a third party service

Downforeveryoneorjustme is an alternative to find an efficient way to eliminate this error, just copy the URL of the site where the error occurred, and you will get the information you need, the information you get will let you know which side is the problem, on yours, or if it is the server out of operation.

You can also check CloudFlare service status, as this very famous Cloud provider is protecting and redirecting most of the Internet traffic, as they act as a security layer between visitors browsers, like yourself experiencing this 500 Internal Server Error and the Web server to which you’ve requested a webpage.

If CloudFlare is actually not working and is experiencing a service issue, it will most likely be reflected by this issue on your browser — all you can do, is request a website that isn’t using CloudFlare, or, if it is your website, you can temporarily bypass CloudFlare with your own server configuration, however you will be exposed to security issues.

Clear cache

A 500 internal server error, can also be solved by eliminating the information that is in the Cache of the browser on which you are working, and additionally in your CDN cache if you are using one – if not, starting using a CDN caching solution would probably spare you from experiencing this issue.

Check server logs

Verification of the Server Logs, there are tools in each host, if you do not find them, there are codes to verify these records.

Increase PHP memory

In the cPanel of the page, you have the alternative of modifying the limit of the PHP memory, increasing the value that you have established.

Deactive plugins

Another option is to deactivate the set of Plugins.

To do it fast, simply change the names of the Plugins folders if you are using the WordPress CMS and your website will directly be accessible without any plugin activated.

Change server host

In last resort, if the issue is related to your webserver, it might be a good solution to switch to a better web hosting that will offer better performances and save you the trouble of finding why you are getting this error.

Conclusion: Solve problems

Errors like these can cause many damaging problems, and it is best to act immediately to eliminate them urgently.

Frequently Asked Questions

What does the server error code mean?: The error code indicates internal problems with the server that need to be diagnosed. A malfunction has occurred or the system configuration has been violated. In case of such an error, it is not necessary to immediately write to technical support. You can try to solve this problem yourself.

Источник

Содержание

Ошибка 500 internal server error Nginx
Как исправить 500 internal server error Nginx
1. Ошибка в скрипте PHP
2. Превышено время выполнения или лимит памяти
3. Неверные права на файлы
Выводы
Похожие записи
Оцените статью
Об авторе
2 комментария к “Ошибка 500 internal server error Nginx”
Модуль ngx_http_core_module
Директивы
Встроенные переменные

Ошибка 500 internal server error Nginx

Как исправить 500 internal server error Nginx

Ошибки в скрипте на PHP — одна из самых частых причин;
Превышено время выполнения PHP скрипта или лимит памяти;
Неправильные права на файлы сайта;
Неверная конфигурация Nginx.

А теперь рассмотрим каждую из причин более подробно и разберем варианты решения.

1. Ошибка в скрипте PHP

sudo systemctl restart php-fpm

tail -n 100 -f /var/log/nginx/error.log

Теперь аналогично, исправьте ошибку и страница будет загружаться нормально, без ошибки 500.

2. Превышено время выполнения или лимит памяти

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

Чтобы решить проблему увеличьте значения параметров max_execution_time и memory_limit в php.ini:

sudo vi /etc/php/7.2/php.ini

max_execution_time 300
memory_limit 512M

sudo systemctl restart php-fpm

3. Неверные права на файлы

nginx -T | grep user

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

namei -l /var/www/site

sudo chown nginx:nginx -R /var/www/site

sudo chmod o+r /var/www/

Выводы

Оцените статью

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

2 комментария к “Ошибка 500 internal server error Nginx”

Чушь.
1. header(«http/1.1 500 Internal Server Error») ;
И логи не помогут.
2. Если скрипт превышает лимиты, то, вероятнее всего, в коде что-то не так. Бесконечный цикл, например. С ним, кстати, и увеличение этих лимитов не спасёт.

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

инициировать такую ошибку можно элементарно. например, отключаем сервис PostgreSQL и вуаля. Welcome home, dear!

Источник

Модуль ngx_http_core_module

Директивы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Синтаксис:	http < . >
Умолчание:	—
Контекст:	main

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

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

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

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

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

Умолчание:
Синтаксис:	ignore_invalid_headers on \| off ;
Контекст:	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.

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

Умолчание:
Синтаксис:	keepalive_disable none \| браузер . ;
Контекст:	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 число ;
Контекст:	http , server , location

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

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

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

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

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

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

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

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

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

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

Умолчание:
Синтаксис:	large_client_header_buffers число размер ;
Контекст:	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):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Умолчание:
Синтаксис:	lingering_timeout время ;
Контекст:	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 ]];
Умолчание:
Контекст:	server

Синтаксис:

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 ]];

Умолчание:

Контекст:

server

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

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

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

Если указан только адрес , то используется порт 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-пакета с данными.

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

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

Синтаксис:	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’ом без модификаторов “ = ” и “ ^

”, то поиск тоже сразу же прекращается и регулярные выражения также не проверяются.

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

Для запроса “ / ” будет выбрана конфигурация А, для запроса “ /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, например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Умолчание:
Синтаксис:	read_ahead размер ;
Контекст:	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 ;
Контекст:	http , server , location

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

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

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

Умолчание:
Синтаксис:	reset_timedout_connection on \| 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, используемые для преобразования имён вышестоящих серверов в адреса, например:

Адрес может быть указан в виде доменного имени или 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 позволяет это переопределить:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Синтаксис:	server < . >
Умолчание:	—
Контекст:	http

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Умолчание:
Синтаксис:	tcp_nopush on \| 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, как в примерах ниже. С версии 0.7.51 последний параметр может также быть кодом :

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

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

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

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

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

Умолчание:
Синтаксис:	types < . >
Контекст:	http , server , location

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

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

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

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

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

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

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

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

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

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

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

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

Умолчание:
Синтаксис:	variables_hash_max_size размер ;
Контекст:	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 :

Поддерживаются следующие имена типов 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 может изменяться в процессе обработки запроса, например, при внутренних перенаправлениях или при использовании индексных файлов.

Источник

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 сервере

Источник

1. Ошибка в скрипте PHP

2. Превышено время выполнения или лимит памяти

3. Неверные права на файлы

Выводы

How to Fix 500 Internal Server Error in NGINX

1. Hard Refresh

2. Examine Server Logs

3. Examine Your Script

4. Check File/Folder Permission

5. Check redirections

6. Increase Script Timeout

Related posts:

500 internal server error, meaning

500 internal server error Nginx, what causes it?

500 internal server error Nginx, Solutions for this error

Reload the page

Check where the problem is with a third party service

Clear cache

Check server logs

Increase PHP memory

Deactive plugins

Change server host

Conclusion: Solve problems

Frequently Asked Questions

Ошибка 500 internal server error Nginx

Как исправить 500 internal server error Nginx

1. Ошибка в скрипте PHP

2. Превышено время выполнения или лимит памяти

3. Неверные права на файлы

Выводы

Похожие записи

Оцените статью

Об авторе

2 комментария к “Ошибка 500 internal server error Nginx”

<img decoding="async" onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" src="http://nginx.org/nginx.png" />

Модуль ngx_http_core_module

Директивы

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

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

Заключение