распространенные ошибки веб-сервера Nginx

Thank you for reading this post, don't forget to subscribe!

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, кото­рая пока­жет вам отла­доч­ную инфор­ма­цию в логах.