404, 502 или 504: с чего начинать диагностику
Статус ответа помогает выбрать первый шаг, но не раскрывает всю причину.
Сообщение «сайт не работает» объединяет десятки разных ситуаций. Для начала запишите точный адрес, время запроса и HTTP-статус. Если HTTP-ответ вообще не получен, сначала придётся разобраться с DNS, соединением или TLS.
404: ресурс не найден
Проверьте путь, регистр букв, завершающий слеш и существование файла или маршрута. Не спешите перезапускать приложение: ошибку может создавать одна неверная ссылка. Если 404 возвращает прокси, запрос мог вообще не дойти до нужного сервиса.
502: проблема ответа upstream
Шлюз получил некорректный ответ от вышестоящего сервера. Для обратного прокси стоит проверить адрес upstream, доступность процесса и соответствие протоколов. Точная причина обычно уточняется по журналам прокси.
504: upstream не ответил вовремя
Сначала выясните, где потрачено время: подключение, база данных, внешний API или обработчик. Увеличение таймаута может лишь отложить ту же ошибку.
Снять воспроизводимый пример
Команда ниже выполняет GET, показывает заголовки и не сохраняет тело. Домен нужно заменить.
curl -sS -D - -o /dev/null \
--connect-timeout 5 --max-time 20 \
https://blog.example.com/posts/example/Использование GET полезно, когда сервер обрабатывает HEAD иначе. Сохраните статус, время и идентификатор запроса, если он есть в ответе.
Менять по одной вещи
Сопоставьте событие с журналами за тот же интервал и проверьте одну гипотезу. Например, исправьте upstream-порт, повторите запрос и убедитесь, что изменился именно нужный результат. Одновременный перезапуск всего стека уничтожает часть наблюдений и затрудняет поиск причины.