Зафиксировать время
Точный момент ошибки нужен для сопоставления с логами.
Практическая диагностика · сервер
Сайт периодически выдаёт 502 или 504: где искать причину
Если ошибка появляется не постоянно, одиночная проверка страницы почти ничего не доказывает. Нужно понять, кто именно возвращает 502/504, в какой момент это происходит и что в это время происходило с backend, PHP, базой данных и нагрузкой.
Быстрый маршрут
Что проверить за первые 5 минут
Не перезапускаем всё подряд. Сначала фиксируем код, время, URL и слой, который его отдал.
Проверить несколько URL
Понять, падает весь сайт или отдельный тип страниц.
Сравнить 502 и 504
502 чаще означает плохой ответ upstream, 504 — ожидание истекло.
Посмотреть логи
Nginx/Apache, PHP-FPM, приложение и база показывают разные части цепочки.
Проверить ресурсы
CPU, RAM, swap, диски, процессы и лимиты соединений.
Периодическая 502/504 — это событие во времени, а не статическая страница.Диагностика становится точной только когда ошибка сопоставлена с логами и состоянием сервера в тот же момент.
Шаг 1
Определите, на каком слое возникает 502 или 504
В типичной схеме запрос проходит через nginx или другой reverse proxy к PHP-FPM, контейнеру, Node.js-приложению или внешнему upstream. 502 означает, что прокси не получил корректный ответ от следующего звена; 504 — что ответ не пришёл вовремя.
Если ошибка видна только на одной части сайта, например в каталоге или поиске, это уже сильная подсказка: общий веб-сервер жив, а проблема локализуется в конкретном backend-сценарии.
Шаг 2
Сопоставьте время ошибки с журналами сервера и приложения
Ищем записи вида upstream timed out, connection refused, prematurely closed connection, PHP fatal error, exhausted memory, deadlock или slow query. Важно смотреть несколько журналов с одной временной меткой, а не один error.log.
Если 504 появляется ровно через одинаковый интервал, например 30 или 60 секунд, проверяем timeout на прокси и реальную длительность backend-операции. Увеличивать timeout без поиска причины опасно: это может только дольше удерживать занятые воркеры.
Полезно сохранить один конкретный пример: URL, время до секунды, код и request ID, если приложение его выдаёт.
Шаг 3
Проверьте, не заканчиваются ли воркеры или не падает приложение
Для PHP-проектов частая причина — очередь запросов к PHP-FPM: все воркеры заняты долгими операциями, а новые запросы ждут или получают отказ. Для Node/Java-приложений аналогичный эффект создают зависшие процессы, event loop, pool соединений или аварийный restart.
Если ошибка совпадает с импортом, резервным копированием, cron или тяжёлым отчётом, проблема может быть не в веб-запросе как таковом, а в конкуренции за CPU, память или базу.
Шаг 4
Смотрите не только среднюю нагрузку, но и пики
Средние 20% CPU за час не исключают короткий пик до 100% всех ядер. То же относится к памяти: OOM может убить PHP/MySQL за секунды, после чего график быстро возвращается к норме.
Проверяем swap, iowait, свободное место, количество процессов, OOM-события и лимиты файловых дескрипторов. На виртуальном сервере дополнительно учитываем ограничения самого тарифа.
curl -I https://example.ru/Фиксирует текущий HTTP-код, но не заменяет наблюдение во времени.
free -hПоказывает RAM и swap; важна динамика около момента ошибки.
uptimeLoad average помогает увидеть очередь, но требует контекста по числу CPU.
Шаг 5
Долгий запрос к базе или внешнему API может выглядеть как проблема nginx
Страница может зависать, пока приложение ждёт MySQL, Redis, API платёжной системы, CRM или другого сервиса. Reverse proxy видит только то, что upstream не отвечает вовремя.
Если 504 возникает на определённой операции, трассируем именно её: медленные SQL-запросы, блокировки таблиц, DNS внешнего API, сетевые таймауты и повторные попытки.
Практический пример
502 появляется только вечером под нагрузкой
Днём сайт работает нормально, а около 19:00 отдельные запросы начинают отдавать 502. Простая ручная проверка утром не воспроизводит проблему, поэтому кажется, что ошибка случайна.
Сопоставляем время сбоя с nginx error log, PHP-FPM и системными метриками. В момент ошибки видно, что все PHP-воркеры заняты тяжёлыми запросами каталога, очередь растёт, а часть соединений upstream закрывается.
| Наблюдение | Вывод |
|---|---|
| Ошибка только в пиковое время | ищем зависимость от нагрузки |
| upstream errors в ту же минуту | проблема после nginx |
| PHP-FPM pool заполнен | нужно разбирать долгие запросы и размер пула |
Типовые сценарии
Как читать сочетание симптомов
Код сам по себе не называет виновника, но сочетание времени, URL и логов сильно сужает поиск.
| Симптом | Вероятная зона | Что проверить |
|---|---|---|
| 502 сразу после deploy | backend не стартовал или сокет недоступен | процесс, socket/port, конфигурацию upstream |
| 504 через одинаковые 60 секунд | backend выполняется дольше timeout | медленную операцию и timeout-цепочку |
| 502 только под нагрузкой | заканчиваются воркеры/соединения/память | PHP-FPM pool, DB pool, RAM, OOM |
| 504 только в одной функции | тяжёлый SQL или внешний API | логи приложения, slow query, API timeout |
| Ошибки ночью | cron, backup, импорт | расписание фоновых задач и ресурсы |
Чего не делать
Типичные действия, которые мешают диагностике
Перезапускать сервер при каждом 502
После restart исчезает важное состояние, а причина остаётся.
Сразу увеличивать timeout
Долгий запрос начинает занимать ресурсы ещё дольше.
Смотреть только nginx error.log
Причина часто находится в PHP, приложении или базе.
Оценивать только среднюю нагрузку
Короткие пики и OOM могут не быть видны по среднему графику.
Чек-лист
Проверка периодических 502/504
- Зафиксировать время: URL, код и точный момент ошибки.
- Определить масштаб: Весь сайт или отдельный тип страниц.
- Сопоставить логи: Proxy, backend, PHP и база в одно время.
- Проверить воркеры: Нет ли очереди или отказов backend.
- Проверить RAM и OOM: Процессы не убиваются системой.
- Проверить CPU и iowait: Нет ли кратких пиков.
- Проверить базу: Медленные запросы и блокировки.
- Проверить внешние API: Таймауты и DNS зависимостей.
- Сверить cron: Ошибка не совпадает с фоновыми задачами.
- Повторить под наблюдением: Подтвердить исправление на следующем событии.
Когда нужен доступ к проекту
Какие данные ускоряют диагностику
Если для проверки нужны error log, настройки FPM, slow query и системные метрики, без серверного доступа остаются только предположения. Передавайте специалисту точное время, URL и код — это резко ускоряет поиск причины.
Передавать пароли в текст статьи или публичную переписку не нужно. Для рабочей диагностики доступы выдаются отдельно и только к тем системам, которые действительно нужны для проверки.
Вопросы
Короткие ответы
Чем 502 отличается от 504?
502 обычно означает некорректный или недоступный ответ upstream, 504 — что прокси не дождался ответа вовремя.
Поможет ли увеличение proxy_read_timeout?
Иногда как временная мера, но сначала нужно понять, почему операция стала такой долгой.
Почему ошибка исчезает после перезапуска?
Restart освобождает память и очереди, но это не доказывает, что первопричина устранена.
Можно ли найти причину без логов?
Иногда по симптомам можно сузить область, но периодические ошибки надёжнее всего диагностируются по журналам и метрикам в тот же момент.