500 внутренняя ошибка сервера nginx

При разработке веб-сайтов и веб-приложений можно столкнуться с ошибкой 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. Как видите проблема вполне решаема и в большинстве случаев вам помогут действия описанные в статье. А если не помогут, напишите свое решение в комментариях!

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!

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.

When I access 127.0.0.1:6789 it works fine, but when i try to access something like 127.0.0.1:6789/busca.html?q=a, I got 500 Internal Server Error

this is my nginx config file

server {

    listen   88;


    root /vagrant/rizqcursosonline/rizqcursosonline/frontend/wwwpublic;
    index index.php index.html index.htm;

    server_name example.com;

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

    error_page 404 /404.html;

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
          root /vagrant/rizqcursosonline/rizqcursosonline/frontend/wwwpublic/;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    location ~ .php$ {
            try_files $uri =404;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include fastcgi_params;

    }

}

nginx log error

2014/04/12 18:16:32 [error] 4165#0: *5 rewrite or internal redirection cycle while internally redirecting to "/index.html", client: 10.0.2.2, server: example.com, request: "GET /busca.html?q=a HTTP/1.1", host: "127.0.0.1:6789", referrer: "http://127.0.0.1:6789/"

2014/04/12 18:16:32 [error] 4165#0: *7 rewrite or internal redirection cycle while internally redirecting to «/index.html», client: 10.0.2.2, server: example.com, request: «GET /favicon.ico HTTP/1.1», host: «127.0.0.1:6789»

Ошибка 500 internal server error Nginx

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

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

Как исправить 500 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:

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. Настройте его правильно или отключите:

Выводы

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

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

Нет похожих записей.

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

Об авторе

Основатель и администратор сайта 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

Директивы

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

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

Эта директива появилась в версии 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задаёт 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 .

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

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

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

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

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

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

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

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

Указывает, что 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”.

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

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

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

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

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

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

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

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

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

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

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

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

Ограничивает 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.

Ограничивает скорость передачи ответа клиенту. Скорость задаётся в байтах в секунду. Значение 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.

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

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

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

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

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

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

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

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

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

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

Задаёт адрес и порт для 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, если этот параметр не был задан явно, то для сокета действовали настройки операционной системы.

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

] 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, например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задаёт серверы 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 в указанной зоне . Параметр доступен как часть коммерческой подписки.

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

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

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

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

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

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

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

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

Разрешает или запрещает использовать 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() . Без этого ограничения одно быстрое соединение может целиком захватить рабочий процесс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Пользователи интернета и владельцы сайтов периодически сталкиваются с различными ошибками на веб-страницах. Одной из самых распространенных ошибок является error 500 (ошибка 500). Поговорим в нашей статье о том, что это за ошибка и как ее исправить.

Где и когда можно встретить ошибку 500

Вы можете увидеть ошибку на любом веб-ресурсе, браузере и устройстве. Она не связана с отсутствием интернет-соединения, устаревшей версией операционной системы или браузера. Кроме того, эта ошибка не указывает на то, что сайта не существует или он больше не работает.

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

Отображаться ошибка может по-разному. Вот пример:

Если вы решили купить что-то в любимом интернет-магазине, но увидели на сайте ошибку 500, не стоит сильно огорчаться – она лишь сообщает о том, что вам нужно подождать, пока она будет исправлена.

Если ошибка появилась на вашем сайте, то нужно скорее ее исправлять. Далее я расскажу, как это можно сделать.

Причины возникновения ошибки

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

Основной причиной ошибки 500 может быть:

1. Неверный синтаксис файла .htaccess. htaccess – это файл, в котором можно задавать настройки для работы с веб-сервером Apache и вносить изменения в работу сайта (управлять различными перенаправлениями, правами доступа к файлам, опциями PHP, задавать собственные страницы ошибок и т.д.). 
   Узнать больше о файле .htaccess можно в статье «Создание и настройка .htaccess».
2. Ошибки в скриптах сайта, то есть сценариях, созданных для автоматического выполнения задач или для расширения функционала сайта.
3. Нехватка оперативной памяти при выполнении скрипта.
4. Ошибки в коде CMS, системы управления содержимым сайта. В 80% случаев виноваты конфликтующие плагины. 

Как получить больше данных о причине ошибки 

Что означает ошибка 500, мы теперь знаем. Когда она перестала быть таким загадочным персонажем, не страшно копнуть глубже — научиться определять причину ошибки. В некоторых случаях это можно сделать самостоятельно, так что обращаться за помощью к профильному специалисту не понадобится.

Отображение ошибки бывает разным. Ее внешний облик зависит от того, чем она вызвана.

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

1. Сообщение Internal Server Error говорит о том, что есть проблемы с файлом .htaccess (например, виновата некорректная настройка файла). Убедиться, что .htaccess является корнем проблемы, поможет следующий прием: переименуйте файл .htaccess, добавив единицу в конце названия. Это можно сделать с помощью FTP-клиента (например, FileZilla) или файлового менеджера на вашем хостинге (в Timeweb такой есть, с ним довольно удобно работать). После изменения проверьте доступность сайта. Если ошибка больше не наблюдается, вы нашли причину.
2. Сообщение HTTP ERROR 500 или пустая страница говорит о проблемах со скриптами сайта. В случае с пустой страницей стоит учесть, что отсутствие содержимого сайта не всегда указывает на внутреннюю ошибку сервера 500.

Давайте узнаем, что скрывается за пустой страницей, обратившись к инструментам разработчика. Эта браузерная панель позволяет получить информацию об ошибках и другие данные (время загрузки страницы, html-элементы и т.д.). 

Как открыть панель разработчика

• Нажмите клавишу F12 (способ актуален для большинства браузеров на Windows). Используйте сочетание клавиш Cmd+Opt+J, если используете Google Chrome на macOS. Или примените комбинацию Cmd+Opt+C в случае Safari на macOS (но перед этим включите «Меню разработки» в разделе «Настройки» -> «Продвинутые»). Открыть инструменты разработчика также можно, если кликнуть правой кнопкой мыши в любом месте веб-страницы и выбрать «Просмотреть код» в контекстном меню. 
• Откройте вкладку «Сеть» (или «Network») и взгляните на число в поле «Статус». Код ответа об ошибке 500 — это соответствующая цифра.

Более детальную диагностику можно провести с помощью логов.

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

Как вы видите, данных в логи записывается немало, поэтому они разделены по типам. За сведениями о нашей ошибке можно обратиться к логам ошибок (error_log). Обычно такие логи предоставляет служба поддержки хостинга, на котором размещен сайт. В Timeweb вы можете включить ведение логов и заказать необходимые данные в панели управления. Разобраться в полученных логах поможет статья «Чтение логов».

Как устранить ошибку

Теперь поговорим о том, как исправить ошибку 500. Вернемся к популярным причинам этой проблемы и рассмотрим наиболее эффективные способы решения.

Ошибки в файле .htaccess

У этого файла довольно строгий синтаксис, поэтому неверно написанные директивы (команды) могут привести к ошибке. Попробуйте поочередно удалить команды, добавленные последними, и проверьте работу сайта. 
Также найти проблемную директиву можно с помощью логов ошибок (через те же инструменты разработчика в браузере). На ошибку в директиве обычно указывает фраза «Invalid command». Информацию о верном написании директивы или способе исправления ошибок в .htaccess вы можете найти в интернете. Не нужно искать, почему сервер выдает ошибку 500, просто введите в строку поиска название нужной команды или текст ошибки из логов.

Ошибки в скриптах сайта

Скрипт не запускается

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

Не хватает оперативной памяти

Если в логах вы видите ошибку «Allowed memory size», для устранения ошибки 500 стоит оптимизировать работу скрипта. Вы можете воспользоваться специальными расширениями для анализа производительности скрипта или обратиться за помощью к специалисту, который поработает над его оптимизацией.

Если ваш сайт размещен на отдельном физическом или виртуальном сервере, можно попробовать увеличить максимальное использование оперативной памяти на процесс (memory_limit). На шаред хостинге этот параметр обычно не изменяется, но есть возможность купить хостинг помощнее.

Ошибки в CMS

Если код CMS содержит неверный синтаксис, это может вывести сайт из строя. В таком случае логи сообщат вам об ошибке 500 текстом «PHP Parse error: syntax error, unexpected». Так происходит, когда некорректно работает плагин (или тема, используемая в CMS, но реже) либо есть ошибки в коде. Ошибка может быть допущена случайно, произойти при обновлении плагина или версии CMS.

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

Также в большинстве случаев подобные проблемы помогает решить поддержка CMS.

Информацию о других распространенных ошибках вы можете найти в статье «6 наиболее часто возникающих ошибок HTTP и способы их устранения».

Удачи! 

В большинстве случаев ошибка Internal Server Error вызвана неверной конфигурацией Nginx. Так что используйте лучшие практики по настройке веб-сервера. И не забудьте включить логирование ошибок – обычно Nginx подсказывает причину ошибку в журнале.

Но есть и не очевидная причина проблемы. Если Nginx работает вместе с PHP-FPM (через модуль FastCGI), то ошибку 500 сервера могут вызывать ошибки выполнения PHP, если отключена директива display_errors.

Для начала проверьте лог php-fpm:

tail -f /var/log/php-fpm/www-error.log
## Выводит 10 последних строчек лога

А затем проверьте файл конфигурации /etc/php-fpm.d/www.conf:

listen = /var/run/php-fpm/php-fpm.sock

listen.owner = nobody

listen.group = nobody

user = nginx

group = nginx

**display_errors = on**
## Уточните указанные параметры и включить отображение ошибок

Еще одна возможная причина ошибки – скрипт пытается использовать больше памяти, чем позволяет директива memory_limit. На ошибку укажет лог PHP-FPM, а увеличить лимит можно все в том же файле конфигурации /etc/php-fpm.d/www.conf.

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

Что такое внутренняя ошибка сервера 500

Код ошибки 5хх говорит о том, что браузер отправил запрос корректно, но сервер не смог его обработать. Что значит ошибка 500? Это проблема сервера, причину которой он не может распознать.

Сообщение об ошибке сопровождается описанием. Самые популярные варианты:

• Внутренняя ошибка сервера 500,
• Ошибка 500 Internal Server Error,
• Временная ошибка (500),
• Внутренняя ошибка сервера,
• 500 ошибка сервера,
• Внутренняя ошибка HTTP 500,
• Произошла непредвиденная ошибка,
• Ошибка 500,
• HTTP status 500 internal server error (перевод ― HTTP статус 500 внутренняя ошибка сервера).

Дизайн и описание ошибки 500 может быть любым, так как каждый владелец сайта может создать свою версию страницы. Например, так выглядит страница с ошибкой на REG.RU:

Как ошибка 500 влияет на SEO-продвижение

Для продвижения сайта в поисковых системах используются поисковые роботы. Они сканируют страницы сайта, проверяя их доступность. Если страница работает корректно, роботы анализируют её содержимое. После этого формируются поисковые запросы, по которым можно найти ресурс в поиске.

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

Проверить, осталась ли страница на прежних позициях, можно с помощью Google Search Console. Если робот исключил страницу из поисковой выдачи, её можно добавить снова.

Код ошибки 500: причины

Если сервер вернул ошибку 500, это могло случиться из-за настроек на web-хостинге или проблем с кодом сайта. Самые распространённые причины:

• ошибки в файле .htaccess,
• неподходящая версия PHP,
• некорректные права на файлы и каталоги,
• большое количество запущенных процессов,
• большие скрипты,
• несовместимые или устаревшие плагины.

Решить проблему с сервером можно только на стороне владельца веб-ресурса. Однако пользователь тоже может выполнить несколько действий, чтобы продолжить работу на сайте.

Что делать, если вы пользователь

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

Перезагрузите страницу

Удаленный сервер возвращает ошибку не только из-за серьёзных проблем на сервере. Иногда 500 ошибка сервера может быть вызвана небольшими перегрузками сайта.

Чтобы устранить ошибку, перезагрузите страницу с помощью сочетания клавиш:

• на ПК — F5,
• на ноутбуке — Fn + F5,
• на устройствах от Apple — Cmd + R.

Обратите внимание! Если вы приобретаете товары в интернет-магазине и при оформлении заказа появляется 500 Internal Server Error (перевод — внутренняя ошибка сервера), при перезагрузке страницы может создаться несколько заказов. Поэтому сначала проверьте, оформился ли ваш предыдущий заказ. Если нет, попробуйте оформить заказ заново.

Очистите кэш и cookies браузера

Кэш и cookies сохраняют данные посещаемых сайтов и данные аутентификаций, чтобы в будущем загружать веб-ресурсы быстрее. Если на ресурсе уже был статус ошибки 500, при повторном входе на сайт может загружаться старая версия страницы с ошибкой из кэша, хотя на самом деле страница уже работает. Очистить кэш и куки браузера вам поможет инструкция.

Если ни одно из этих действий не решило проблему, значит, некорректно работает сам сервер сайта. Вернитесь на страницу позже, как только владелец решит проблему.

Что делать, если вы владелец сайта

В большинстве случаев устранить проблему может только владелец сайта. Как правило, ошибка связана с проблемами в коде. Реже проблемы могут быть на физическом сервере хостинг-провайдера.

Ниже рассмотрим самые популярные причины и способы решения.

Ошибки в файле .htaccess

Неверные правила в файле .htaccess — частая причина возникновения ошибки. Чтобы это проверить, найдите .htaccess в файлах сайта и переименуйте его (например, в test). Так директивы, прописанные в файле, не повлияют на работу сервера. Если сайт заработал, переименуйте файл обратно в .htaccess и найдите ошибку в директивах. Если вы самостоятельно вносили изменения в .htaccess, закомментируйте новые строки и проверьте доступность сайта.Также может помочь замена текущего файла .htaccess на стандартный в зависимости от CMS.

Найти директиву с ошибкой можно с помощью онлайн-тестировщика. Введите содержимое .htaccess и ссылку на сайт, начиная с https://. Затем нажмите Test:

Произошла непредвиденная ошибка

На экране появится отчёт. Если в .htaccess есть ошибки, они будут выделены красным цветом:

500 ошибка nginx

Активирована устаревшая версия PHP

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

Установлены некорректные права на файлы и каталоги сайта

В большинстве случаев корректными правами для каталогов являются «755», для файлов — «644». Проверьте, правильно ли они установлены, и при необходимости измените права на файлы и папки.

Запущено максимальное количество процессов

На тарифах виртуального хостинга REG.RU установлены ограничения на количество одновременно запущенных процессов. Например, на тарифах линейки «Эконом» установлено ограничение в 18 одновременно запущенных процессов, на тарифах «+Мощность» ― 48 процессов. Если лимит превышен, новый процесс не запускается и возникает системная ошибка 500.

Такое большое число одновременных процессов может складываться из CRON-заданий, частых подключений с помощью почтовых клиентов по протоколу IMAP, подключения по FTP или других процессов.

Чтобы проверить количество процессов, подключитесь по SSH. Выполните команду:

ps aux | grep [u]1234567 |wc -l

Вместо u1234567 укажите ваш логин хостинга: Как узнать логин хостинга.

Чтобы посмотреть, какие процессы запущены, введите команду:

Вместо u1234567 укажите логин услуги хостинга.

Командная строка отобразит запущенные процессы:

Код ошибки 500

Где:

• u1234567 — логин услуги хостинга,
• 40522 — PID процесса,
• S — приоритет процесса,
• /usr/libexec/sftp-server — название процесса.

Процесс можно завершить командой kill, например:

Вместо 40522 укажите PID процесса.

Чтобы решить проблему, вы также можете:

• увеличить интервал запуска заданий CRON,
• ограничить количество IMAP-соединений в настройках почтового клиента. Подробнее в статье Ограничение IMAP-соединений,
• проанализировать запущенные процессы самостоятельно или обратившись за помощью к разработчикам сайта.

Если вам не удалось самостоятельно устранить ошибку 500, обратитесь в техподдержку.

Скрипты работают слишком медленно

На каждом виртуальном хостинге есть ограничения на время выполнения скрипта. Если за установленное время скрипт не успевает выполниться, возникает ошибка сервера 500. Для решения проблемы обратитесь к разработчику сайта и оптимизируйте скрипты. Если оптимизировать нельзя, перейдите на более мощный вид сервера.

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

Ошибка 500 на сайте, созданном на WordPress

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

Для начала проверьте, нужно ли обновить плагины. Часто устаревшие плагины перестают работать и вызывают проблемы работы сайта. Если все плагины обновлены, но 500 Internal Server Error остаётся, отключите все плагины, чтобы убедиться, что именно они мешают работе сайта. Как только станет понятно, что виноват один из плагинов, отключайте их по очереди, пока не найдёте тот, который нарушает работу сервера.

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