upstream sent too big header while reading response header from upstream

[Vasily Soshnikov]

Привет,

Просто увеличить буфер, размер таблицы. Данная ошибка может не быть
ошибкой. Например, приложение за NGINX высылает слишком много заголовков
и/или большое значение или значения.





*Regard,Soshnikov Vasily mailto:dedok.mad на gmail.com <dedok.mad на gmail.com>*

ср, 5 мар. 2025 г., 21:10 Hennadii Makhomed <gmm на csdoc.com>:

> Здравствуйте, All!
>
> В error.log встречается время от времени 502 статус и такая запись:
>
> upstream sent too big header while reading response header from upstream
>
> но какой именно заголовок в ответе от backend большого размера
> и какое его очень большое содержимое не указывается в error.log,
> - что значительно затрудняет поиск причины ошибки и ее устранение.
>
> можно ли сделать так, чтобы в случае возникновения такой 502 ошибки
> чтобы имя этого очень большого заголовка ответа и его содержимое
> писалось в error.log файл? или вообще все заголовки запроса
> и все заголовки ответа пис ались в лог, в случае, если возникает
> такая вот неожидання 502 ошибка по причине, что там too big header?
>
> ошибки такие возникают не так часто и поймать их очень трудно.
> приходится включать
>
> error_log /var/log/nginx/error.log debug;
>
> и переключаться на nginx-debug, что приводит
> к очень быстрому росту лог-файла на диске.
>
> ведь никаких других способов кроме использования tcpdump
> и использования error_log /var/log/nginx/error.log debug;
> как я понимаю для поиска причины этой ошибки не существует?
>
> на backend - не хотят или не умеют найти причину этой ошибки.
>
> или - имеет смысл не искать причину ошибки,
> а просто увеличить размер буферов и все?
>
> chat.deepseek.com рекомендует поставить
>
> fastcgi_buffer_size 32k;          # Было 4k/8k → увеличиваем до 32k
> fastcgi_buffers 16 32k;           # Было 8 4k/8k → 16 буферов по 32k
> fastcgi_busy_buffers_size 64k;    # Было 8k/16k → увеличиваем до 64k
>
> если это не поможет - то выставлять тогда
>
> fastcgi_buffer_size 64k;
> fastcgi_buffers 32 64k;
> fastcgi_busy_buffers_size 128k;
>
> и если ошибка сохраняется - то увеличивать и дальше, 32k → 64k → 128k
>
> наверное вот эти значения:
>
> fastcgi_buffer_size 32k;          # Было 4k/8k → увеличиваем до 32k
> fastcgi_buffers 16 32k;           # Было 8 4k/8k → 16 буферов по 32k
> fastcgi_busy_buffers_size 64k;    # Было 8k/16k → увеличиваем до 64k
>
> - это будет нормально, а чтобы не падал с out of memory, просто
> дам каждой виртуальной машине 256 гигабайт swap на диске, да и все.
>
> дефолтовые значения для директив fastcgi_buffer_size, fastcgi_buffers
> и fastcgi_busy_buffers_size - такого небольшого размера - это самый
> оптимальный вариант, их точно не надо сейчас сделать больше,
> хотя бы в два раза больше, для современных сайтов?
>
> насколько я понимаю, никак нельзя исправить эту ситуацию, что nginx
> аварийно завершает обработку запроса и возвращает 502 статус, если
> ему размер header не понравился, отправленный ему со стороны upstream?
>
> если он считает размеры буферов не оптимальными - можно было бы написать
> warning в error.log, но зачем же возвращать 502 стратус вместо ответа?
>
> большой размер заголовков, например, до 32KiB или 64KiB - это же
> не является нарушением HTTP стандарта? Зачем же тогда 502 статус?
>
> и как их правильно тюнить, эти размеры буферов fastcgi_buffer_size,
> fastcgi_buffers и fastcgi_busy_buffers_size ? увеливать до тех пор,
> пока nginx не прекратит возвращать 502 ошибки на запросы клиентов?
>
> P.S.
>
> — В nginx ты можешь настроить всё... и ты будешь настраивать всё!
>
> так это оказывается не шутка была... это так есть, на самом деле?
>
> --
> Best regards,
>   Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20250313/1d3b36b3/attachment.htm>