<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">ср, 5 мар. 2025 г. в 19:10, Hennadii Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Здравствуйте, All!<br>
<br>
В error.log встречается время от времени 502 статус и такая запись:<br>
<br>
upstream sent too big header while reading response header from upstream<br>
<br>
но какой именно заголовок в ответе от backend большого размера<br>
и какое его очень большое содержимое не указывается в error.log,<br>
- что значительно затрудняет поиск причины ошибки и ее устранение.<br></blockquote><div><br></div><div>в данном случае имеется в виду весь header, не какой-то конкретный заголовок</div><div>(соглашусь, текст ошибки сбивает с толку)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
можно ли сделать так, чтобы в случае возникновения такой 502 ошибки<br>
чтобы имя этого очень большого заголовка ответа и его содержимое <br>
писалось в error.log файл? или вообще все заголовки запроса<br>
и все заголовки ответа пис ались в лог, в случае, если возникает<br>
такая вот неожидання 502 ошибка по причине, что там too big header? </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
ошибки такие возникают не так часто и поймать их очень трудно.<br>
приходится включать<br>
<br>
error_log /var/log/nginx/error.log debug;<br>
<br>
и переключаться на nginx-debug, что приводит<br>
к очень быстрому росту лог-файла на диске.<br>
<br>
ведь никаких других способов кроме использования tcpdump<br>
и использования error_log /var/log/nginx/error.log debug;<br>
как я понимаю для поиска причины этой ошибки не существует?<br></blockquote><div><br></div><div>я не пробовал, но приходит в голову вариант с "error_page 502=@some_location" и внутри some_location задать error_log</div><div>возможно, что не сработает</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
на backend - не хотят или не умеют найти причину этой ошибки.<br>
<br>
или - имеет смысл не искать причину ошибки,<br>
а просто увеличить размер буферов и все?<br></blockquote><div><br></div><div>увеличение размера буферов --> увеличение расхода памяти. если она есть в достатке, почему бы и нет.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<a href="http://chat.deepseek.com" rel="noreferrer" target="_blank">chat.deepseek.com</a> рекомендует поставить<br>
<br>
fastcgi_buffer_size 32k; # Было 4k/8k → увеличиваем до 32k<br>
fastcgi_buffers 16 32k; # Было 8 4k/8k → 16 буферов по 32k<br>
fastcgi_busy_buffers_size 64k; # Было 8k/16k → увеличиваем до 64k<br></blockquote><div><br></div><div>к этому можно подойти творчески. </div><div>fastcgi_buffer_size - это размер одного буфера. в один буфер предполагается, что должны поместиться все хедеры.</div><div>а вот их количество увеличивать необязательно, и можно посмотреть в сторону отключения fastcgi_buffering, и тогда </div><div>запрос будет вычитываться постепенно.</div><div><br></div><div>зависит от объема доступной памяти</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
если это не поможет - то выставлять тогда<br>
<br>
fastcgi_buffer_size 64k;<br>
fastcgi_buffers 32 64k;<br>
fastcgi_busy_buffers_size 128k;<br>
<br>
и если ошибка сохраняется - то увеличивать и дальше, 32k → 64k → 128k<br>
<br>
наверное вот эти значения:<br>
<br>
fastcgi_buffer_size 32k; # Было 4k/8k → увеличиваем до 32k<br>
fastcgi_buffers 16 32k; # Было 8 4k/8k → 16 буферов по 32k<br>
fastcgi_busy_buffers_size 64k; # Было 8k/16k → увеличиваем до 64k<br>
<br>
- это будет нормально, а чтобы не падал с out of memory, просто<br>
дам каждой виртуальной машине 256 гигабайт swap на диске, да и все.<br>
<br>
дефолтовые значения для директив fastcgi_buffer_size, fastcgi_buffers<br>
и fastcgi_busy_buffers_size - такого небольшого размера - это самый<br>
оптимальный вариант, их точно не надо сейчас сделать больше,<br>
хотя бы в два раза больше, для современных сайтов?<br></blockquote><div><br></div><div>совершенно необязательно следовать дефолтным значениям.</div><div>по дефолту включена буферизация ответа бекенда. т.е. nginx будет вычитывать ответ чтобы максимально</div><div>разгрузить бекенд (пытаясь сохранить сначала в своей памяти, а потом на диске). у всех ли стоит</div><div>задача максимально разгрузить бекенд ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
насколько я понимаю, никак нельзя исправить эту ситуацию, что nginx<br>
аварийно завершает обработку запроса и возвращает 502 статус, если<br>
ему размер header не понравился, отправленный ему со стороны upstream?<br>
<br>
если он считает размеры буферов не оптимальными - можно было бы написать<br>
warning в error.log, но зачем же возвращать 502 стратус вместо ответа?<br></blockquote><div><br></div><div>такова механика работы - чтобы как-то работать с ответом, надо сначала вычитать полностью хедеры, </div><div>предполагая, что они поместились в один буфер. и далее стримится тело ответа.</div><div><br></div><div>если хедеры не влезли в один буфер, каких-то вариантов обработать запрос нет.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
большой размер заголовков, например, до 32KiB или 64KiB - это же<br>
не является нарушением HTTP стандарта? Зачем же тогда 502 статус?<br>
<br>
и как их правильно тюнить, эти размеры буферов fastcgi_buffer_size,<br>
fastcgi_buffers и fastcgi_busy_buffers_size ? увеливать до тех пор,<br>
пока nginx не прекратит возвращать 502 ошибки на запросы клиентов?<br>
<br>
P.S.<br>
<br>
— В nginx ты можешь настроить всё... и ты будешь настраивать всё!<br>
<br>
так это оказывается не шутка была... это так есть, на самом деле?<br>
<br>
-- <br>
Best regards,<br>
Gena<br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
</blockquote></div></div>