Nginx: upstream timed out (110: Connection timed out) while reading response header

#Что означает ошибка

«upstream timed out (110: Connection timed out) while reading response header from upstream» в журнале nginx означает, что бэкенд (PHP-FPM, Node, Gunicorn) не ответил в отведённое время. Посетитель при этом видит 504.

Нужно найти причину медленного ответа, а не только увеличить таймаут.

Различайте «connecting» и «reading response header».

Ошибка означает, что бэкенд (PHP-FPM, приложение) не ответил за время proxy_read_timeout / fastcgi_read_timeout. Найдите причину задержки и при необходимости увеличьте таймаут.

#Причины и решения

#Пошаговое решение

1. Найдите тип таймаута в логеЧерез SSH выполните sudo grep "upstream timed out" /var/log/nginx/error.log | tail -n 30, откройте полную строку и определите фазу: while connecting to upstream означает трудности соединения, while reading response header — backend принял запрос, но не отдал заголовки вовремя. Сравните точный URL, время и upstream-адрес с журналом PHP-FPM или приложения.
2. Проверьте состояние бэкендаПроверьте доступность соответствующего backend: для PHP-FPM определите реальную службу и сокет из fastcgi_pass, посмотрите systemctl status и ss -lxnp; для HTTP upstream — ss -ltnp и curl на разрешённый внутренний адрес. Не перезапускайте случайный PHP-пул и не изменяйте файл сокета вручную.
3. Увеличьте таймаутыЕсли в журнале видно, что приложение действительно обрабатывает длинный запрос, временно увеличивайте fastcgi_read_timeout или proxy_read_timeout только для нужного маршрута и в разумных пределах, после измерения нормальной задержки. Эти параметры не ускоряют код; длительное ожидание удерживает ресурсы и может усилить перегрузку.
4. Увеличьте число воркеровПри PHP-FPM проверьте его журнал на server reached pm.max_children, длительность очереди и фактический расход памяти пула. Изменяйте pm.max_children лишь после расчёта доступной RAM для всех пулов и БД; увеличение без расчёта способно вызвать OOM и ещё больше ответов 504.
5. Оптимизируйте медленные запросыВключите штатную регистрацию медленных запросов PHP-FPM или просмотр slow query log БД в контролируемое время, найдите конкретный SQL/внешний API/обработчик и оптимизируйте его на стенде. После изменений выполните sudo nginx -t && sudo systemctl reload nginx только если меняли Nginx, затем повторите исходный URL и проверьте время и логи.
6. Проверка конфигурации и перезагрузка nginx

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Проверка конфигурации и перезагрузка nginx.

   nginx -t && systemctl reload nginx

#Диагностика

Откройте /var/log/nginx/error.log и найдите фразы: while connecting to upstream — бэкенд не принимает подключение (упал или перегружен); while reading response header — бэкенд принял, но отвечает слишком долго. Проверьте systemctl status php8.2-fpm и нагрузку top.

#Таймауты

Для PHP-FPM: fastcgi_read_timeout 300; в location ~ \.php$; для прокси: proxy_read_timeout 300;, proxy_connect_timeout 60;. Перезагрузите nginx. В PHP-FPM увеличьте request_terminate_timeout и pm.max_children, чтобы не заканчивались воркеры.

#Оптимизация

Найдите медленные запросы через slow log PHP-FPM (request_slowlog_timeout = 5s) и MySQL (slow_query_log). Добавьте индексы, кэш (Redis/OPcache), вынесите тяжёлые задачи в очередь. Проверьте внешние API без таймаута и блокировки файлов.