Nginx Linux

Nginx: 502 Bad Gateway при больших заголовках PHP-FPM

  • Обновлено
  • Чтение ≈ 3 минуты
  • Нужны права администратора

Краткий ответ

При большом ответном заголовке FastCGI Nginx может выдавать 502 и сообщение upstream sent too big header while reading response header from upstream. Обычно виноваты многочисленные Set-Cookie или большие заголовки ответа.

В этой статье
  1. Что означает и когда возникает ошибка
  2. Причины и как их различить
  3. Пошаговая диагностика и исправление
  4. Проверка результата
  5. Если проблема осталась

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

Нужно отличить заголовки ответа PHP-FPM от слишком длинного входящего Cookie: во втором случае чаще появляется 400, а не описанная 502. Простое увеличение лимитов PHP на загрузку файлов проблему не решает.

#Причины и как их различить

Возможная причинаКак узнатьЧто делать
Велик заголовок ответа PHPПриложение отправляет много Set-Cookie или длинные значения заголовков.502 именно после входа или при запуске сессии, error.log указывает too big header.Сократить ответные заголовки в приложении.
Мал fastcgi_buffer_sizeПервый буфер FastCGI не вмещает сформированные заголовки ответа.После изменения авторизации, плагина или переменных выросла длина заголовков.Точечно увеличить fastcgi_buffer_size после оценки.
Причина не в размерах заголовков502 вызывают недоступный сокет, падение PHP-FPM или нарушение протокола.В error.log есть connect() failed, prematurely closed или другой текст, не too big header.Диагностировать сокет/пул отдельно, не применять решение этой статьи.

#Пошаговая диагностика и исправление

  1. Зафиксируйте точное сообщениеОткройте проблемный URL в безопасном тестовом сценарии и запишите время. По SSH найдите путь error_log через sudo nginx -T и посмотрите строки за этот интервал. Для данной инструкции ключевая фраза — upstream sent too big header while reading response header from upstream. Если её нет, не меняйте буферы; сначала разберите фактическую запись журнала.
  2. Определите блок FastCGI, который обслуживает URLВыполните sudo nginx -T 2>&1 | grep -nE "fastcgi_pass|fastcgi_buffer_size|fastcgi_buffers|server_name". Найдите location для PHP соответствующего сайта и убедитесь, что там именно fastcgi_pass к PHP-FPM, а не proxy_pass к HTTP-серверу. Для proxy_pass действует другой параметр proxy_buffer_size; подменять ими друг друга нельзя.
  3. Проверьте заголовки на тестовой копии запросаЕсли сайт доступен без риска для данных, в браузере откройте F12 → «Сеть», выполните действие и посмотрите заголовки ответа успешных похожих запросов. Особое внимание уделите количеству и длине Set-Cookie, Location и служебных заголовков. Не пересылайте cookie третьим лицам: они могут содержать действующие ключи сеанса. При статусе 502 Nginx может не показать клиенту исходные заголовки — тогда нужен журнал приложения.
  4. Уберите из приложения лишние заголовкиПроверьте код входа/сессий и плагины, которые ставят повторные cookie или длинные JWT в заголовок. Для штатных идентификаторов сеанса храните сведения на сервере, а не огромные структуры в cookie. Сначала исправьте причину на тестовой площадке, затем повторите операцию: если 502 исчезла, конфигурацию Nginx можно не менять.
  5. При необходимости увеличьте только FastCGI-буферСохраните копию файла конфигурации реального сайта, затем в его блоке location с fastcgi_pass добавьте fastcgi_buffer_size 32k; как пример, предварительно оценив размер заголовка и расход памяти. Не задавайте огромные значения во всех сайтах. Проверьте sudo nginx -t; только если вывод сообщает, что тест успешен, выполните sudo systemctl reload nginx.
  6. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения
    Вариант 1Команды на сервере по SSH: просмотр фактической конфигурации и проверка синтаксиса.
    Linux · Терминал (Bash)КомандаНужен sudo
    Команды на сервере по SSH: просмотр фактической конфигурации и проверка синтаксиса.
    sudo nginx -T 2>&1 | grep -nE "fastcgi_pass|fastcgi_buffer_size|proxy_pass|proxy_buffer_size"
    sudo nginx -t
    Вариант 2Неполный иллюстративный фрагмент; не заменяйте им действующий блок location целиком.
    Nginx
    Неполный иллюстративный фрагмент; не заменяйте им действующий блок location целиком.
    location ~ \.php$ {
    # Существующие fastcgi_pass, include и SCRIPT_FILENAME сохраняйте без изменений.
    fastcgi_buffer_size 32k;
}
  7. Проверьте результат и путь откатаЕщё раз войдите в приложение или откройте страницу, вызывавшую 502. Должен появиться нужный контент без 502, а в error.log не должно быть новой записи too big header. Если ошибка сохранилась, верните файл из сделанной копии, запустите sudo nginx -t и sudo systemctl reload nginx. Далее исследуйте размер заголовков и логи PHP, а не увеличивайте буфер вслепую.

#Проверка результата

Точный тест — ранее сбойный запрос возвращает правильный код и содержимое, а в журнале нет нового сообщения upstream sent too big header.

#Если проблема осталась

Сохраните дату, точный URL без паролей и токенов, код ответа, обезличенные строки error.log и access.log за это время и перечень уже сделанных изменений. Сравните работу при обращении через публичный адрес и через внутренний балансировщик, если он есть. Если причину пока не удалось подтвердить, восстановите исходную конфигурацию из копии и передайте эти сведения администратору или разработчику приложения; не меняйте несколько параметров одновременно.

Так эту ошибку тоже называют

502 502 Bad Gateway в Nginx: причины и быстрый способ найти виновника Ответ `502 Bad Gateway` означает, что Nginx, выступая шлюзом, не смог получить корректный ответ от backend-сервера — чаще всего PHP-FPM или приложения за `proxy_pass`. С… Сайты, серверы и хостинг Nginx NginxLinux Nginx: 502 Bad Gateway с PHP-FPM — причины и решение Проверьте, запущен ли php-fpm, путь к сокету и права. Сайты, серверы и хостинг Nginx Linux 504 Nginx 504 Gateway Time-out — причины и как исправить Ошибка `504 Gateway Time-out` значит, что Nginx отправил запрос приложению (PHP-FPM, Node.js, другому серверу), но не дождался ответа за отведённое время. Чаще всего при… Сайты, серверы и хостинг Nginx NginxLinuxPHP-FPM Nginx: ERR_TOO_MANY_REDIRECTS — цикл редиректов http/https и www — причины и решение Найдите петлю редиректов в конфиге и CMS, проверьте Cloudflare и proxy. Сайты, серверы и хостинг Nginx Linux 504 Nginx: 504 Gateway Time-out — upstream не отвечает вовремя — причины и решение Nginx выдаёт 504 Gateway Time-out, когда backend (PHP-FPM, Node.js, прокси) не успевает ответить за отведённое время. Увеличьте proxy_read_timeout или fastcgi_read_timeo… Сайты, серверы и хостинг Nginx Linux

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.