Ошибка при запуске nginx

The cause of the issue is this, I already had Apache web server installed and actively listening on port 80 on my local machine.

Apache and Nginx are the two major open-source high-performance web servers capable of handling diverse workloads to satisfy the needs of modern web demands. However, Apache serves primarily as a HTTP server whereas Nginx is a high-performance asynchronous web server and reverse proxy server.

The inability of Nginx to start was because Apache was already listening on port 80 as its default port, which is also the default port for Nginx.

One quick workaround would be to stop Apache server by running the command below

systemctl stop apache2
systemctl status apache2

And then starting up Nginx server by running the command below

systemctl stop nginx
systemctl status nginx

However, this same issue will arise again when we try to start Apache server again, since they both use port 80 as their default port.

Here’s how I fixed it:

Run the command below to open the default configuration file of Nginx in Nano editor

sudo nano /etc/nginx/sites-available/default

When the file opens in Nano editor, scroll down and change the default server port to any port of your choice. For me, I chose to change it to port 85

# Default server configuration
#
server {
       listen 85 default_server;
       listen [::]:85 default_server;

Also, scroll down and change the virtual host port to any port of your choice. For me, I also chose to change it to port 85

# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
# server {
#        listen 85;
#        listen [::]:85;

Then save and exit the file by pressing on your keyboard:

Ctrl + S
Ctrl + X

You may still be prompted to press Y on your keyboard to save your changes.

Finally, confirm that your configuration is correct and restart the Nginx server:

sudo nginx -t
sudo systemctl restart nginx

You can now navigate to localhost:nginx-port (localhost:85) on your browser to confirm the changes.

Displaying the default Nginx start page

If you want the default Nginx start page to show when you navigate to localhost:nginx-port (localhost:85) on your browser, then follow these steps:

Examine the directory /var/www/html/ which is the default root directory for both Apache and Nginx by listing its contents:

cd ~
ls /var/www/html/

You will 2 files listed in the directory:

index.html                # Apache default start page
index.nginx-debian.html   # Nginx default start page

Run the command below to open the default configuration file of Nginx in Nano editor:

cd ~
sudo nano /etc/nginx/sites-available/default

Change the order of the index files in the root directory from this:

root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

to this (putting the default Nginx start page — index.nginx-debian.html in the 2nd position immediately after index):

root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.nginx-debian.html index.html index.htm;

Then save and exit the file by pressing on your keyboard:

Ctrl + S
Ctrl + X

You may still be prompted to press Y on your keyboard to save your changes.

Finally, confirm that your configuration is correct and restart the Nginx server:

sudo nginx -t
sudo systemctl restart nginx

You can now navigate to localhost:nginx-port (localhost:85) on your browser to confirm the changes.

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

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

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

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

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

1. Вы настроили Nginx на перенаправление HTTP-запросов на HTTPS, но в Nginx нет блока сервера, обслуживающего HTTPS-запросы.
2. Может быть, Nginx не запущен?
3. Иногда основной бинарник 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 сервере

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 не может най­ти ресур­сы, кото­рые запра­ши­ва­ет ваш веб-браузер.

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

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

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

sudo systemctl restart mariadb

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

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

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

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

Затем пере­за­гру­зи­те 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

1. Вы настро­и­ли Nginx на пере­на­прав­ле­ние HTTP-запро­сов на HTTPS, но в Nginx нет бло­ка сер­ве­ра, обслу­жи­ва­ю­ще­го HTTPS-запросы.
2. Может быть, Nginx не запущен?
3. Ино­гда основ­ной бинар­ник 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

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

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

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

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

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

Затем пере­за­пу­сти­те 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-адре­са из “бело­го спис­ка” могут полу­чить доступ к стра­ни­це состояния.

Сохра­ни­те и закрой­те файл. Затем про­те­сти­руй­те кон­фи­гу­ра­цию 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 и уви­ди­те сле­ду­ю­щее предупреждение.

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

Вы може­те пере­за­пу­стить ОС, что­бы решить эту проблему.

Если это не помо­га­ет, вам нуж­но ском­пи­ли­ро­вать отла­доч­ную вер­сию Nginx, кото­рая пока­жет вам отла­доч­ную инфор­ма­цию в логах.