Пользователи получают 504 / socket hang up, при этом CPU и память не нагружены — в чем может быть проблема и как её решить?

Ошибка 504 Gateway Timeout и сообщение socket hang up обычно приходят не от самого приложения, а от промежуточного слоя: nginx, HAProxy, API Gateway, ingress-контроллера или клиентской библиотеки. Они означают, что соединение было установлено, но ответ не пришёл вовремя, либо соединение было разорвано до получения ответа. Низкая загрузка CPU и памяти как раз типична для такой ситуации: сервер не работает, а ждёт.

Основные причины

• Медленный внешний вызов: запрос к БД, стороннему API или очереди, который висит дольше таймаута прокси.
• Блокировка event loop или пула потоков: синхронная операция в Node.js, долгий GC, deadlock в БД.
• Неверные таймауты: у прокси таймаут меньше, чем у бэкенда, поэтому прокси рвёт соединение первым.
• Проблемы с keep-alive: прокси держит соединение, а бэкенд его уже закрыл, отсюда socket hang up.
• Сетевые проблемы: потеря пакетов, MTU, DNS-резолвинг, нестабильный балансировщик.

Как диагностировать

Сначала смотрим логи прокси и приложения с request id, затем распределённый трейсинг (Jaeger, OpenTelemetry), чтобы увидеть, на каком шаге запрос зависает. Полезно снять метрики latency по эндпоинтам и проверить, не растёт ли время ответа постепенно.

# nginx: увеличиваем таймауты до upstream
proxy_connect_timeout 10s;
proxy_send_timeout    60s;
proxy_read_timeout    60s;

# Node.js: таймаут на fetch
const controller = new AbortController();
setTimeout(() => controller.abort(), 5000);
await fetch(url, { signal: controller.signal });

Как исправлять

1. Согласовать таймауты: таймаут прокси должен быть больше таймаута бэкенда, а таймаут бэкенда — больше таймаута внешнего вызова.
2. Добавить circuit breaker и retry с backoff для нестабильных зависимостей.
3. Вынести долгие операции в фоновые задачи (очереди, воркеры), а клиенту отдавать 202 Accepted.
4. Настроить health-check и корректное закрытие keep-alive соединений.

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