upstream sent too big header while reading response header from upstream

[Hennadii Makhomed]

On 06.03.2025 11:54, Илья Шипицин wrote:

 >> upstream sent too big header
 >> while reading response header from upstream

 > в данном случае имеется в виду весь header,
 > не какой-то конкретный заголовок

директива fastcgi_buffer_size задает размер буфера для чтения
заголовка ответа от апстрима, а директива fastcgi_buffers задает
число и размер буферов которые потом уже используются для чтения
тела ответа от апстрима. соответственно, чтобы убрать 502 ошибку
достаточно будет просто увеличивать fastcgi_buffer_size на размер
еще одной страницы памяти, для x86_64 - это ровно 4096 байт.

по умолчанию, этого буфера размер равен 4K, если есть 502 ошибки -
увеличиваем 4, 8, 12, 16, 20, 24, 28, 32, 36, 40,... до тех пор,
пока 502 ошибки полностью не пропадут. и все, - проблема решена!

а размер каждого буфера в fastcgi_buffers - увеличивать не надо,
и лучше оставить равным размеру страницы, чтобы не было впустую
расходования памяти, вместо этого лучше увеличить их количество,
они же выделяются не все сразу, а только по мере необходиомости.

зачем же тогда в интернете такое большое количество рекомендаций
делать большой размер одного буфера в директиве fastcgi_buffers?

 > увеличение размера буферов --> увеличение расхода памяти.
 > если она есть в достатке, почему бы и нет.

вне зависимости от того, сколько там есть памяти, все равно,
убрать эту 502 ошибку можно только увеличивая размер буфера
с помощою директивы fastcgi_buffer_size - и других вариантов
тут нет, если backend должен вернуть именно такие заголовки.

пока что остановился на таком наборе директив:

     fastcgi_buffer_size         8k;
     fastcgi_busy_buffers_size  16k;
     fastcgi_buffers          16 4k;

     proxy_buffer_size           8k;
     proxy_busy_buffers_size    16k;
     proxy_buffers            16 4k;

Илья, спасибо, что помогли мне лучше разобраться с этим вопросом.

P.S.

freenginx уже не развивается, последнее обновление там было 2024-09-03.

из живых форков nginx остались только nginx, OpenResty, Tengine и Angie.

осталось только 4 варианта nginx, если не считать коммерческие версии.

>>> у всех ли стоит задача максимально разгрузить бекенд ?
>>
>> а разве нет?
> 
> сильно зависит от бекенда. если бекенд вполне современный
> и не имеет проблем с c10k, то дополнительная буферизация не нужна.
> мы перед asp.net выключали буферизацию. отлично работало.
> 
> какой смысл ? терминация ssl, высокая плотность хостинга на белых адресах,
> L7 маршрутизация по локейшенам.

для такого набора задач - разве не будет лучше использовать haproxy ?

https://en.wikipedia.org/wiki/HAProxy

HAProxy was written in 2000 by Willy Tarreau,
a core contributor to the Linux kernel,
who still maintains the project.

тут это оффтопик наверное, но в open source версии haproxy, как я понял
из документации, есть такие возможности настроки очередей и приоритетов,
каких нет даже в коммерческой версии nginx и тем более в open source
версии nginx, так что для терминации TLS, маршрутизации и приоретизации
запросов - наверное haproxy еще лучше подходит? В том числе и уровень
защиты от  DDoS можно значительно повысить, разбив все клиентские
подключения на классы, и в первую очередь обслуживая запросы от
целевой аудитории, а те страны из которых приходят как правило
только DDoS-запросы - обслуживать в самом конце списка приоритетов,
только если будут свободными ресурсы сервера и не будет более 
приоритетных и более важных запросов от целевой аудитории
и ботов поисковых систем. Такой алгоритм haproxy, как я понял
из их документации, позволяет сделать. это же очень хорошие
возможности, позволяют сделать сайт гораздо более защищенным
от DDoS-атак и это позволит "максимально разгрузить бекенд".

очереди есть только в платной версии nginx, а приоритетов -
нет даже и в платной версии nginx, насколько я помню из доки.

и Максим Дунин сказал, что не надо надеяться на то, что очереди
из платной версии nginx когда-либо появятся в бесплатной версии.


-- 
Best regards,
  Gena