Как исправить ошибку 502 Bad Gateway в Nginx: пошаговое руководство

Ошибка 502 Bad Gateway в Nginx обычно означает, что Nginx не смог получить корректный ответ от сервера приложения, например PHP-FPM, Node.js или другого серверного приложения.

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

Начните с проверки журналов ошибок Nginx. По ним часто можно точно определить, почему не удалось установить соединение.

В этом руководстве описаны семь практических шагов по поиску и устранению неполадок на серверах Linux с Nginx.

Почему в Nginx возникает ошибка 502 Bad Gateway?

Nginx часто работает как обратный прокси: перенаправляет запросы серверным приложениям и возвращает их ответы посетителям.

Если сервер приложения не отвечает должным образом, Nginx может вернуть код состояния HTTP 502.

Распространённые причины:

• Службы серверных приложений остановлены или аварийно завершились.
• Неправильно указаны IP-адреса, порты или Unix-сокеты серверов приложений.
• Сбои PHP-FPM или процессов приложений.
• Проблемы с правами доступа к сокету.
• Недостаточно оперативной памяти или места на диске.
• Некорректные или преждевременно закрытые соединения с серверами приложений.

Для следующих проверок вам понадобятся доступ по SSH и права на администрирование сервера Linux.

1. Проверьте журналы ошибок Nginx

Журналы ошибок Nginx обычно помогают быстрее всего определить причину ошибки 502.

Подключитесь к серверу по SSH и выполните команду:

sudo tail -n 50 /var/log/nginx/error.log

Она выведет последние 50 записей журнала.

Чтобы отслеживать записи в реальном времени, используйте:

sudo tail -f /var/log/nginx/error.log

Обновите страницу, на которой возникла ошибка, и следите за новыми сообщениями.

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

Не меняйте настройки Nginx, пока не определите вероятную причину ошибки.

2. Проверьте, работает ли служба серверного приложения

Ошибка 502 часто возникает из-за остановки приложения, работающего за Nginx.

Если службой приложения управляет systemd, выполните:

sudo systemctl status myapp

Замените myapp фактическим именем службы.

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

sudo systemctl status php8.3-fpm

Версия установленного PHP и имя службы могут отличаться.

Если служба завершилась с ошибкой, изучите её журналы:

sudo journalctl -u myapp -n 50

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

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

3. Проверьте порт или сокет сервера приложения

Nginx должен перенаправлять запросы на правильный адрес серверного приложения.

Например, в конфигурации обратного прокси может быть указано:

location / {
    proxy_pass http://127.0.0.1:3000;
}

Это предписывает Nginx перенаправлять запросы HTTP-приложению, которое прослушивает порт 3000.

Проверьте, прослушивается ли этот порт:

sudo ss -ltnp | grep ':3000'

Также можно напрямую проверить HTTP-приложение:

curl -i http://127.0.0.1:3000/

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

Проверьте сокеты PHP-FPM

PHP-FPM часто использует Unix-сокеты или TCP-порты.

Конфигурация Nginx может содержать:

fastcgi_pass unix:/run/php/php8.3-fpm.sock;

Проверьте, существует ли сокет, указанный в конфигурации:

ls -l /run/php/

Путь к сокету должен совпадать со значением параметра listen в настройках пула PHP-FPM, а у Nginx должны быть права на подключение к нему.

Важно: proxy_pass используется для серверов приложений, работающих по HTTP, а fastcgi_pass — для служб FastCGI, таких как PHP-FPM. Эти директивы не взаимозаменяемы.

4. Проверьте оперативную память и место на диске сервера

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

Проверьте оперативную память:

free -h

Проверьте место на диске:

df -h

Проверьте запущенные процессы:

top

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

sudo journalctl -k --since "1 hour ago"

Ищите сообщения о нехватке памяти или завершении процессов.

Если место на диске закончилось, прежде чем удалять файлы, определите, что его занимает.

5. Проверьте права доступа к сокету и журналы приложения

Иногда серверное приложение работает, но Nginx не может с ним связаться.

Для Unix-сокетов проверьте владельца и права доступа:

ls -l /run/php/

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

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

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

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

6. Проверьте конфигурацию Nginx

Неправильные настройки прокси или изменения конфигурации также могут нарушить связь с сервером приложения.

Прежде чем применять изменения, проверьте конфигурацию Nginx:

sudo nginx -t

Если проверка прошла успешно, перезагрузите конфигурацию Nginx:

sudo systemctl reload nginx

Это применит корректные изменения конфигурации без ненужного перезапуска службы.

Если проверка не прошла, сначала исправьте указанную ошибку конфигурации.

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

7. Убедитесь, что ошибка 502 устранена

После устранения основной причины проверьте URL, при открытии которого возникала ошибка:

curl -I https://example.com

Замените example.com своим доменом.

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

Также откройте сайт в браузере и ещё раз проверьте журналы ошибок Nginx.

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

Как предотвратить ошибки 502 в Nginx

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

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

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

Часто задаваемые вопросы

Заключение

Чтобы исправить ошибку 502 Bad Gateway в Nginx, сначала нужно выяснить, почему серверное приложение не отвечает должным образом.

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

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