Каждый сисадмин хоть раз сталкивался с 502 Bad Gateway, 503 Service Unavailable и 504 Gateway Timeout. Эти ошибки появляются неожиданно и пугают тем, что где-то что-то упало. Но откуда вообще взялись сами коды и почему именно они так часто преследуют администраторов? Под катом погружусь в историю HTTP, объясню банальные причины и расскажу, как найти и где пофиксить эти проблемы. 

Небольшой экскурс в историю HTTP

Когда HTTP только появился, он был удивительно прост — браузер шёл к одному серверу, и тот почти всегда отвечал. В ранних версиях вроде HTTP/0.9 никаких статусов вообще не существовало, поэтому интерпретировать там было нечего.

Нумерация ответов появилась в HTTP/1.0, в середине девяностых. Тогда между клиентом и сервером начали появляться посредники, а вместе с ними и классические 500-е коды. Именно тогда оформились 502 Bad Gateway и 503 Service Unavailable. То есть понимание о том, что ломаться может не приложение, а путь к нему, появилось задолго до эпохи облаков. 

С HTTP/1.1 в 1997–1999 годах архитектуры стали многоуровневыми — появились прокси, балансировщики, шлюзы, а чуть позже и API-шлюзы. Под такую реальность в стандарт добавили 504 Gateway Timeout. 

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

Что значат ошибки 502, 503 и 504

Код 502 Bad Gateway означает, что сервер, выступающий как шлюз или прокси, получил недействительный (ошибочный) ответ от вышестоящего сервера. Формально ответ есть, но он «битый», странный или просто не соответствует ожиданиям.

Почти всегда ошибка «Плохой шлюз» указывает на проблему взаимодействия между компонентами инфраструктуры. Классический пример — неверные параметры upstream в конфигурации NGINX (порт, адрес, протокол). 

503 Service Unavailable значит, что сервер временно не может обработать запрос из-за перегрузки или обслуживания. Этот код не описывает как таковой сбой, а фиксирует отказ в обслуживании в текущий момент времени.

Ошибку «Сервис временно недоступен» может возвращать как само приложение, так и балансировщик или фронтовый сервер. В отличие от 502, здесь нет проблемы в передаче данных между узлами — система сообщает, что не готова принимать новые запросы.

В HTTP-стандарте при этой ошибке рекомендует вернуть клиенту заголовок Retry-After, сообщающий, когда стоит повторить запрос. Однако на практике он используется нерегулярно.

504 Gateway Timeout («Таймаут шлюза») — ошибка, сообщающая, что сервер-посредник не получил ответа от вышестоящего сервера в пределах установленного времени ожидания. То есть вместо некорректного ответа в этом случае его просто нет в отведённый таймаут.

Типовая архитектура здесь та же, что и у 502: прокси или балансировщик отправляет запрос к бэкенду и ожидает ответ в течение заданного тайм-аута. Если бэкенд отвечает слишком медленно или не отвечает вовсе, посредник завершает ожидание и возвращает клиенту 504. Причиной может быть перегруженное приложение, медленная база данных, внешнее API с высокой латентностью или сетевые задержки.

Почему эти ошибки «преследуют» сисадминов

502, 503 и 504 — самые частые представители семейства 500-х, потому что именно они отражают реальное устройство веба. Сегодня запросы почти не идут напрямую от клиента к приложению, они проходят через длинную цепочку промежуточных узлов, и каждый из них имеет собственные условия отказа.

То есть чем сложнее архитектура, тем больше мест, где можно получить эти ошибки, не имея при этом ни одного «упавшего сервера». Дальше разберу классические причины.

Многоуровневые прокси и балансировщики

Предполагается, что конфигурация любой системы с прокси, CDN и балансировщиками согласована. Это предположение чаще всего ошибочно — ведь достаточно забыть обновить IP, порт или DNS-запись после замены сервера, и прокси начинает слать запросы туда, где сервиса уже нет. В результате это приводит к 502 Bad Gateway.

Есть отдельная категория проблем, связанных с DNS. Ошибки разрешения имён, задержки обновления записей, временная недоступность — все они приводят к тому, что шлюз пытается установить соединение не с тем узлом. В логах появляется 502-я или 504-я ошибка, хотя причина лежит далеко за пределами веб-сервера.

Перегрузка и нехватка ресурсов

При росте нагрузки из-за всплеска трафика, массовых операций, DDoS или недооценённых лимитов первыми сбоят точки агрегации — веб-серверы (Apache, NGINX) и балансировщики. Заполняются очереди соединений, время ответа растёт, а система или отказывается принимать новые запросы, или не успевает обработать уже принятые.

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

Техобслуживание и дедлоки

Ошибка «Сервис временно недоступен» часто появляется, когда система работает корректно, но недоступна по понятным причинам. Например, плановым работам, обновлениям или рестартам сервисов. В этих случаях сервер осознанно возвращает 503 Service Unavailable.

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

Сетевые задержки и таймауты

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

Причиной 504-й ошибки выступают и несогласованные параметры ожидания. Важно, чтобы компоненты «ждали» одинаковое время.

Ошибки конфигурации и кодовые опечатки

Ну и наконец, конфигурация — самый банальный и самый неприятный источник проблем. Неверный proxy_pass, забытый порт, несоответствие протоколов или истёкший сертификат мгновенно превращаются в 502-ю ошибку. При этом со стороны всё это может выглядеть как «инфраструктурная авария», хоть причина и умещается в одной строке конфига.

По вышеописанным причинам 502, 503 и 504 так раздражают администраторов. Они редко указывают на конкретный сломанный компонент. Чаще это всего лишь сигналы об отсутствии согласованности. 

Как бороться с этими ошибками 

Все три ошибки «лечатся» одинаково — сначала нужно разобраться, на каком участке цепочки произошёл сбой, а уже потом что-то чинить. 

Как исправить 502 Bad Gateway

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

Обратите внимание и на параметры upstream и proxy_pass, а также на протокол и порт. Параметры должны быть согласованы с реальным поведением бэкенда. Если причину не нашли — проверяйте сам бэкенд. Он должен быть доступен напрямую. 

Отдельно проверьте DNS. После смены серверов или адресов могут быть проблемы с обновлением записей или сбросом кэша. В этом случае прокси будет «ходить» по старому адресу и в ответ получать пустоту. Если используете CDN, полезно на некоторое время отключить его и посмотреть, отвечает ли сам сервер.

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

Как исправить 503 Service Unavailable

503 Service Unavailable — это почти всегда вопрос нагрузки или режима работы сервиса. Если включён maintenance mode, нужно либо завершить обслуживание, либо корректно оформить отказ, добавив заг Retry-After, чтобы клиенты бессмысленно не штурмовали сервис.

При перегрузке сервера вариантов немного — либо снижать входящий поток, либо увеличивать доступные ресурсы. Стандартно могут помочь масштабирование бэкенда, включение кэширования, вынос статики в CDN и настройка очередей. А для классических PHP/Apache/CMS-систем часто помогает пересмотр лимитов.

Доступность сервера также может пропадать из-за заполненного диска, ошибок в .htaccess или некорректных параметров PHP. Поэтому логи приложения и системные метрики обязательны к просмотру. Если на стороне сервера всё выглядит чисто, стоит проверить мониторинг хоста и состояние инфраструктуры у провайдера.

Как исправить 504 Gateway Timeout

Как я говорил ранее, эта ошибка указывает на медленный участок цепочки, поэтому тут нужно понять, кто именно не «успевает». Это может быть база данных, внешний API, внутренний сервис или сеть между ними.

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

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

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

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

В заключение дам парочку советов: 

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

• Чтобы ускорить диагностику, полезно временно отключить промежуточные слои и проверить запрос напрямую — от клиента к бэкенду, минуя прокси и балансировщики. 

• Иногда ошибки снимают перезапуск веб-сервера или очистка кэша, особенно при DDoS или сразу после «выката» конфигурации. 

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

Делитесь своими лайфхаками по починке 502-й, 503-й и 504-й ошибок в комментариях. На что смотрите в первую очередь? 

© 2025 ООО «МТ ФИНАНС»