Nginx: upstream sent too big header while reading response header

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

«upstream sent too big header while reading response header from upstream» в логе nginx означает, что заголовки ответа бэкенда (PHP-FPM, Node.js, приложения) не помещаются в буфер, заданный по умолчанию (4k или 8k). Пользователь видит 502 Bad Gateway. Чаще всего проблема в большом количестве или размере cookie, длинных заголовках (Set-Cookie, Link, CSP) либо в нескольких прокси подряд.

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

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

1. Найдите ошибку в логеПодключитесь к серверу по SSH, запустите sudo tail -n 50 /var/log/nginx/error.log и найдите полную строку upstream sent too big header while reading response header from upstream с URL и upstream. Убедитесь, что она появилась в момент проблемного запроса, а не относится к другому домену. Запишите имя виртуального хоста и размер передаваемых заголовков, если есть диагностика.
2. Определите тип бэкендаОткройте конфигурацию нужного сайта через sudo nginx -T и найдите, обращается ли проблемный location к приложению через proxy_pass (HTTP-прокси) или fastcgi_pass (PHP-FPM). Это определяет, какой набор буферов применим: proxy_* или fastcgi_*. Не вставляйте обе конфигурации в каждый location, поскольку это не устраняет источник большого ответа.
3. Увеличьте буферыЕсли найден proxy_pass, сначала проверьте, не создаёт ли приложение чрезмерное количество Set-Cookie или длинную цепочку авторизации. При подтверждённой необходимости увеличьте proxy_buffer_size в конфигурации конкретного виртуального хоста умеренно, используя исходный пример как отправную точку, и сохраните старое значение. Большие буферы увеличивают расход памяти на соединения. Проверьте nginx -t перед применением.
4. Для FastCGIЕсли используется fastcgi_pass, проверьте журнал PHP и размер заголовков, которые генерирует приложение. Только затем в нужном location задайте fastcgi_buffer_size и при необходимости fastcgi_buffers с учётом нагрузки. Не меняйте глобально буферы всех сайтов, если сообщение относится к одной странице. Запишите прежние значения для отката.
5. Проверьте конфигурациюНа сервере выполните sudo nginx -t; ожидаются syntax is ok и test is successful. При ошибке синтаксиса не применяйте новую конфигурацию и откройте указанный файл и строку. Если проверка успешна, используйте sudo systemctl reload nginx и повторите конкретный запрос. Не перезапускайте сервис до проверки.
6. Перезагрузите конфигурациюЕсли Nginx уже работал, после успешного теста конфигурации примените sudo systemctl reload nginx. Проверьте systemctl status nginx, а затем по времени откройте свежий error.log: отсутствие новых строк об oversized header при воспроизведении подтверждает улучшение. Если ошибка остаётся, верните прежние буферы и ищите источник необычных cookie.
7. Уменьшите cookieОткройте инструменты разработчика браузера → «Сеть» → нужный запрос → «Заголовки», оцените количество и размер Set-Cookie, а также цепочку перенаправлений. Для просмотра пользовательской стороны очистите cookie только проблемного сайта после предупреждения о выходе из аккаунта. На стороне приложения уменьшайте содержимое cookie или храните сессию на сервере, не удаляя секретные токены из работающего приложения вслепую.
8. Проверьте заголовкиЕсли вы управляете приложением, выполните curl -sSI https://ваш-домен/путь для конкретного URL и посмотрите повторяющиеся заголовки и Location. При 502 ответа заголовков приложения может не быть, поэтому изучайте журнал backend. После исправления проверьте авторизацию и пользовательские сеансы: слишком маленький Set-Cookie не должен означать потерю необходимого состояния.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Проверка конфигурации и применение настроек nginx.

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

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

   sudo nginx -t

   sudo systemctl reload nginx

   sudo tail -n 50 /var/log/nginx/error.log

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

   Вариант 2Пример файла или настройки

   NginxКопировать всёВыделить

   location ~ \.php$ {
       fastcgi_pass unix:/run/php/php8.2-fpm.sock;
       fastcgi_buffer_size 32k;
       fastcgi_buffers 16 16k;
       include fastcgi_params;
   }
   location / {
       proxy_pass http://127.0.0.1:3000;
       proxy_buffer_size 16k;
       proxy_buffers 8 16k;
       proxy_busy_buffers_size 32k;
   }

Увеличивайте буферы умеренно: значения в десятки килобайт достаточно для большинства приложений; слишком большие значения увеличивают потребление памяти на каждое соединение. Если размер заголовков растёт из-за cookie, исправьте приложение (храните данные сессии на сервере, а не в cookie). В цепочке Cloudflare → nginx → приложение ограничения есть на каждом уровне. После правок проверьте проблемные страницы в режиме инкогнито и с авторизацией. Справка — документация nginx.

Чтобы выяснить точный размер заголовков, выполните curl -s -D - -o /dev/null https://сайт | wc -c. Если размер близок к 8 КБ, увеличивайте буфер. Для приложений за двумя nginx (внешний и внутренний) настройте буферы на обоих. Если ошибка появляется только у части пользователей, виноваты их cookie: проверьте, не накапливаются ли cookie со старых поддоменов.