Диагностика ошибок 403, 404, 502 и 504 в Nginx

Задача и общий подход

Материал посвящён теме «Диагностика ошибок 403, 404, 502 и 504 в Nginx» с акцентом на диагностике и локализации ошибок.

Nginx часто становится первой точкой входа для сайта и внутренних сервисов. Ошибка в одном server-блоке способна одновременно затронуть статические файлы, TLS, reverse proxy и служебные панели.

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

Когда применять этот порядок

Этот сценарий подходит для следующих ситуаций:

• плановое внедрение или перенос компонента категории «Nginx» на новый VPS
• изменение портов, домена, сертификата, маршрута или способа публикации сервиса
• разбор инцидента, когда локальная и внешняя проверки дают разные результаты
• подготовка к обновлению пакета или восстановлению после неудачного изменения
• аварийная диагностика с фиксацией симптомов до перезапусков

Как устроена схема

Запрос сначала попадает на директиву listen, затем сопоставляется имя из Host с server_name, после чего выбирается location. Анализировать полезно полный вывод nginx -T, потому что include-файлы могут менять ожидаемое поведение.

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

Что должно получиться

После выполнения руководства по теме «Диагностика ошибок 403, 404, 502 и 504 в Nginx» результат должен быть измеримым:

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

Подготовка перед изменениями

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

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

Пошаговая настройка

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

sudo nginx -t

sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log

curl -I http://127.0.0.1/ -H 'Host: example.org'
curl -kI https://127.0.0.1/ -H 'Host: example.org'

sudo nginx -T > /root/nginx-full-$(date +%F-%H%M%S).txt
sudo tar -czf /root/nginx-config-$(date +%F-%H%M%S).tar.gz /etc/nginx

Имена доменов, адреса, порты и пути в примерах условные. Перед выполнением замените их фактическими значениями.

Проверка результата

Проверка должна охватывать конфигурацию, процесс, listener и реальный запрос.

• nginx -t проходит
• служба active
• ожидаемые порты слушаются
• curl получает нужный код
• в error.log нет новой критической ошибки

systemctl is-active SERVICE
systemctl status SERVICE --no-pager
journalctl -u SERVICE -n 80 --no-pager
ss -lntup

Дальнейшее сопровождение

Рабочая конфигурация со временем устаревает и требует контроля.

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

Диагностика, если не заработало

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

1. Подтвердите симптом точной командой и запишите время.
2. Проверьте конфигурацию штатным тестом.
3. Проверьте процесс и последние записи журнала.
4. Убедитесь, что нужный адрес и порт слушаются.
5. Сравните локальный запрос с запросом извне.
6. Только затем проверяйте firewall, DNS и маршрут.
7. Меняйте одну переменную и повторяйте тот же тест.

Для темы «Диагностика ошибок 403, 404, 502 и 504 в Nginx» важно не путать открытый firewall с запущенным сервисом: правило доступа не создаёт listener, а активный процесс не гарантирует доступность извне.

Типичные ошибки

Чаще всего восстановление усложняют следующие действия:

• открытие административного порта для всего интернета
• проверка только локального подключения без внешнего теста
• удаление рабочей конфигурации до успешного запуска новой
• перезапуск службы до проверки синтаксиса
• игнорирование различий правил IPv4 и IPv6
• изменение нескольких компонентов одной командой без промежуточных тестов

Безопасность

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

• просматривайте журналы аутентификации и ошибки запуска
• ограничивайте административный доступ доверенными IP или VPN
• выдавайте файлам конфигурации минимальные права
• не храните секреты в публикуемых конфигурациях и журналах
• используйте принцип минимально необходимых прав

Откат изменений

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

1. вернуть сохранённые файлы
2. повторить nginx -t
3. выполнить reload
4. проверить сайт локально и снаружи

Не удаляйте неудачную конфигурацию до выяснения причины: она полезна для diff и разбора инцидента.

Контрольный список

Перед тем как считать тему «Диагностика ошибок 403, 404, 502 и 504 в Nginx» закрытой, пройдите список:

Что дополнительно сверить в документации

При подготовке материала были сопоставлены разделы русскоязычной документации. Для углублённой проверки полезно изучить:

• nginx: документация
• Как nginx обрабатывает запросы
• Параметры командной строки nginx
• Руководство для начинающих

Повторная проверка после restart или перезагрузки

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

Сравните автозапуск, владельцев файлов, постоянные правила firewall, DNS и фактический listener. Это выявляет зависимость от ручной команды, временного файла или правила, которое не сохраняется.

sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

Критерий отката для текущей задачи

Для темы «Диагностика ошибок 403, 404, 502 и 504 в Nginx» заранее определите признаки неудачи: штатная проверка не проходит, процесс не запускается, ожидаемый listener исчез, внешний клиент получает неверный ответ или в журнале растёт число ошибок. После достижения лимита времени выполняйте откат, а не продолжайте добавлять неподтверждённые изменения.

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

• вернуть сохранённые файлы
• повторить nginx -t
• выполнить reload
• проверить сайт локально и снаружи

Финальная проверка с точки зрения реального клиента

Последнюю проверку темы «Диагностика ошибок 403, 404, 502 и 504 в Nginx» выполняйте тем же способом, которым сервисом будет пользоваться человек или приложение: с нужным доменом, протоколом, учётной записью и внешней сетью. Локальная команда остаётся диагностическим этапом, но не заменяет прохождение всей цепочки.

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

curl -I http://127.0.0.1/ -H 'Host: example.org'
curl -kI https://127.0.0.1/ -H 'Host: example.org'

Путь запроса внутри Nginx

При разборе конфигурации важно идти в том же порядке, в котором Nginx обрабатывает запрос: сначала адрес и порт из listen, затем имя из Host и server_name, после этого конкретный location. Ошибка на раннем этапе делает бессмысленной правку более позднего блока.

Смотрите развёрнутую конфигурацию, а не только один файл виртуального хоста. Директивы include могут подключать другой default_server, переопределять параметры журналов или добавлять location, который перехватывает запрос раньше ожидаемого.

sudo nginx -T > /root/nginx-full-$(date +%F-%H%M%S).txt
grep -nE 'listen|server_name|location|proxy_pass' /root/nginx-full-*.txt | tail -n 120

Источники и документация

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

• nginx: документация
• Как nginx обрабатывает запросы
• Параметры командной строки nginx
• Руководство для начинающих