From gmm на csdoc.com Wed Mar 5 18:10:10 2025 From: gmm на csdoc.com (Hennadii Makhomed) Date: Wed, 5 Mar 2025 19:10:10 +0100 Subject: upstream sent too big header while reading response header from upstream Message-ID: Здравствуйте, 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 From chipitsine на gmail.com Wed Mar 5 20:29:39 2025 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 5 Mar 2025 21:29:39 +0100 Subject: upstream sent too big header while reading response header from upstream In-Reply-To: References: Message-ID: ср, 5 мар. 2025 г. в 19:10, Hennadii Makhomed : > Здравствуйте, All! > > В error.log встречается время от времени 502 статус и такая запись: > > upstream sent too big header while reading response header from upstream > > но какой именно заголовок в ответе от backend большого размера > и какое его очень большое содержимое не указывается в error.log, > - что значительно затрудняет поиск причины ошибки и ее устранение. > в данном случае имеется в виду весь header, не какой-то конкретный заголовок (соглашусь, текст ошибки сбивает с толку) > > можно ли сделать так, чтобы в случае возникновения такой 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; > как я понимаю для поиска причины этой ошибки не существует? > я не пробовал, но приходит в голову вариант с "error_page 502=@some_location" и внутри some_location задать error_log возможно, что не сработает > > на 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 - это размер одного буфера. в один буфер предполагается, что должны поместиться все хедеры. а вот их количество увеличивать необязательно, и можно посмотреть в сторону отключения fastcgi_buffering, и тогда запрос будет вычитываться постепенно. зависит от объема доступной памяти > > если это не поможет - то выставлять тогда > > 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 будет вычитывать ответ чтобы максимально разгрузить бекенд (пытаясь сохранить сначала в своей памяти, а потом на диске). у всех ли стоит задача максимально разгрузить бекенд ? > > насколько я понимаю, никак нельзя исправить эту ситуацию, что 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: From gmm на csdoc.com Thu Mar 6 06:05:33 2025 From: gmm на csdoc.com (Hennadii Makhomed) Date: Thu, 6 Mar 2025 07:05:33 +0100 Subject: upstream sent too big header while reading response header from upstream In-Reply-To: References: Message-ID: <81b7c8a9-0113-4cce-9b3b-9f48b7a4a721@csdoc.com> On 05.03.2025 21:29, Илья Шипицин wrote: >> ведь никаких других способов кроме использования tcpdump >> и использования error_log /var/log/nginx/error.log debug; >> как я понимаю для поиска причины этой ошибки не существует? > > я не пробовал, но приходит в голову вариант с "error_page > 502=@some_location" и внутри some_location задать error_log > возможно, что не сработает server { root /home/www/example.com/public; location / { try_files $uri @backend; } location @backend { fastcgi_pass ...; error_page 502=@workaround; } location @workaround { if ($request_method = "POST") { return 500; } fastcgi_buffer_size 32k; fastcgi_buffers 16 32k; fastcgi_busy_buffers_size 64k; fastcgi_pass ... ; } } вместо того, чтобы вот такой workaround добавлять в каждый server { } мне проще будет увеличить размеры fastcgi буферов в контексте http { } >> или - имеет смысл не искать причину ошибки, >> а просто увеличить размер буферов и все? >> > > увеличение размера буферов --> увеличение расхода памяти. если она есть в > достатке, почему бы и нет. виртуальной памяти - в достатке, ее много, swap раздел на 256 гигабайт внутри каждой виртуальной машины, при этом на диске такой неиспользуемый swap раздел занимает физически мало места - всего несколько мегабайт. так и придется сделать, похоже на то. то есть, сейчас самый оптимальный алгоритм решения этой проблемы с 502 ошибками, которые возвращает nginx такой: увеличивать размеры fastcgi_buffer_size, fastcgi_buffers, fastcgi_busy_buffers_size до тех пор, пока nginx не прекратит возвращать 502 статусы на овтеты upstream. неудобно в этой ситуации то, что нет возможности как-либо мониторить сколько свободного места в буфере остается при обработке запросов, и насколько близко nginx находится к той критической границе, после которой он начнет сыпать 502 статусами, вместо нормальных ответов. может быть размеры этих буферов слишком большие или наоборот, слишком маленькие, и ситуация близкая к критической - это как можно узнать? в самом идеальном варианте - лучше было бы чтобы nginx сам мог бы добавить недостающие ему страницы буферов для обработки запроса, и мог бы динамически увеличивать размер одного буфера, чтобы нормально обработать ответ от upstream. например, идеальное решение проблемы: сделать переменную fastcgi_max_buffer_size, по умолчанию равную 8 размерам переменной fastcgi_buffer_size, и в той ситуации, когда размера fastcgi_buffer_size не хватает для обработки какого-то запроса - динамически, "на лету" увеличивать размер буфера в два раза и продлжать нормальную обработку запроса, до тех пор, пока не будет превышен размер лимита fastcgi_max_buffer_size. И только при превышении этого лимита - возвращать клиенту 502 статус вместо нормально ответа от upstream. вопрос к разработчикам: можно ли так сделать? что мешает? > к этому можно подойти творчески. > fastcgi_buffer_size - это размер одного буфера. в один буфер > предполагается, что должны поместиться все хедеры. > а вот их количество увеличивать необязательно, и можно посмотреть в > сторону отключения fastcgi_buffering, и тогда > запрос будет вычитываться постепенно. отключить fastcgi_buffering нельзя, тогда такой веб-сервер будет уявзвим к DDoS-атакам типа Slowloris и тогда будет очень мало смысла в наличии nginx перед upstream сервером и сайт сможет обработать меньше запросов. кстати, вариантов больше чем этих два: fastcgi_buffering on; fastcgi_buffering off; есть еще и промежуточный вариант между ними, когда буферизация в памяти разрешена, но только буферизация на диске запрещена. по умолчанию fastcgi_max_temp_file_size 1024m; но если поставить fastcgi_max_temp_file_size 0; то в таком случае на диск nginx ничего не будет писать, но при этом - будет использовать буферизацию только в памяти. и для большинства вариантов использования nginx - это более предпочительный вариант чем fastcgi_buffering off; потому что в режиме fastcgi_buffering on; fastcgi_max_temp_file_size 0; производительность веб-сервера будет выше, и веб-сервер сможет обработать большее количество запросов. только в очень небольшом количестве случаев может быть целесообразно fastcgi_buffering off; - это когда backend написан на Go - но в таком случае и nginx там не особо нужен вообще, можно напрямую софт на Go выставить в интернет - в таком случае все накладные расходы от промежуточного проксирования будут отсутствовать полностью. > совершенно необязательно следовать дефолтным значениям. > по дефолту включена буферизация ответа бекенда. т.е. nginx будет вычитывать > ответ чтобы максимально > разгрузить бекенд (пытаясь сохранить сначала в своей памяти, а потом на > диске). у всех ли стоит задача максимально разгрузить бекенд ? а разве нет? ведь с какой же целью nginx ставится перед backend? разве не для того, чтобы максимально разгрузить backend и чтобы веб-сервер смог обработать наибольшее количество запросов в секунду и выжать максимум из hardware? количество worker-процессов php-fpm на backend очень сильно ограничено, так что чем быстрее они обработают какой-либо запрос - тем будет лучше. я такого не видел, чтобы кто-то ставил nginx перед backend не для того, чтобы максимально разгрузить backend, а с прямо противоположной целью. -- Best regards, Gena From chipitsine на gmail.com Thu Mar 6 10:54:56 2025 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 6 Mar 2025 11:54:56 +0100 Subject: upstream sent too big header while reading response header from upstream In-Reply-To: <81b7c8a9-0113-4cce-9b3b-9f48b7a4a721@csdoc.com> References: <81b7c8a9-0113-4cce-9b3b-9f48b7a4a721@csdoc.com> Message-ID: чт, 6 мар. 2025 г. в 07:05, Hennadii Makhomed : > On 05.03.2025 21:29, Илья Шипицин wrote: > > >> ведь никаких других способов кроме использования tcpdump > >> и использования error_log /var/log/nginx/error.log debug; > >> как я понимаю для поиска причины этой ошибки не существует? > > > > я не пробовал, но приходит в голову вариант с "error_page > > 502=@some_location" и внутри some_location задать error_log > > возможно, что не сработает > > server { > root /home/www/example.com/public; > location / { try_files $uri @backend; } > location @backend { fastcgi_pass ...; error_page 502=@workaround; } > location @workaround { > if ($request_method = "POST") { return 500; } > fastcgi_buffer_size 32k; > fastcgi_buffers 16 32k; > fastcgi_busy_buffers_size 64k; > fastcgi_pass ... ; > } > } > > вместо того, чтобы вот такой workaround добавлять в каждый server { } > мне проще будет увеличить размеры fastcgi буферов в контексте http { } > > >> или - имеет смысл не искать причину ошибки, > >> а просто увеличить размер буферов и все? > >> > > > > увеличение размера буферов --> увеличение расхода памяти. если она есть в > > достатке, почему бы и нет. > > виртуальной памяти - в достатке, ее много, swap раздел на 256 > гигабайт внутри каждой виртуальной машины, при этом на диске > такой неиспользуемый swap раздел занимает физически мало места > - всего несколько мегабайт. так и придется сделать, похоже на то. > > то есть, сейчас самый оптимальный алгоритм решения этой проблемы > с 502 ошибками, которые возвращает nginx такой: увеличивать > размеры fastcgi_buffer_size, fastcgi_buffers, fastcgi_busy_buffers_size > до тех пор, пока nginx не прекратит возвращать 502 статусы на овтеты > upstream. > > неудобно в этой ситуации то, что нет возможности как-либо мониторить > сколько свободного места в буфере остается при обработке запросов, > и насколько близко nginx находится к той критической границе, > после которой он начнет сыпать 502 статусами, вместо нормальных ответов. > может быть размеры этих буферов слишком большие или наоборот, слишком > маленькие, и ситуация близкая к критической - это как можно узнать? > > в самом идеальном варианте - лучше было бы чтобы nginx сам мог > бы добавить недостающие ему страницы буферов для обработки запроса, > и мог бы динамически увеличивать размер одного буфера, чтобы нормально > обработать ответ от upstream. например, идеальное решение проблемы: > > сделать переменную fastcgi_max_buffer_size, по умолчанию равную 8 > размерам переменной fastcgi_buffer_size, и в той ситуации, когда > размера fastcgi_buffer_size не хватает для обработки какого-то запроса - > динамически, "на лету" увеличивать размер буфера в два раза и продлжать > нормальную обработку запроса, до тех пор, пока не будет превышен размер > лимита fastcgi_max_buffer_size. И только при превышении этого лимита - > возвращать клиенту 502 статус вместо нормально ответа от upstream. > > вопрос к разработчикам: можно ли так сделать? что мешает? > > > > к этому можно подойти творчески. > > fastcgi_buffer_size - это размер одного буфера. в один буфер > > предполагается, что должны поместиться все хедеры. > > а вот их количество увеличивать необязательно, и можно посмотреть в > > сторону отключения fastcgi_buffering, и тогда > > запрос будет вычитываться постепенно. > > отключить fastcgi_buffering нельзя, тогда такой веб-сервер будет уявзвим > к DDoS-атакам типа Slowloris и тогда будет очень мало смысла в наличии > nginx перед upstream сервером и сайт сможет обработать меньше запросов. > > кстати, вариантов больше чем этих два: > > fastcgi_buffering on; > > fastcgi_buffering off; > > есть еще и промежуточный вариант между ними, когда буферизация > в памяти разрешена, но только буферизация на диске запрещена. > по умолчанию > все верно. и еще есть request buffering )) > > fastcgi_max_temp_file_size 1024m; > > но если поставить > > fastcgi_max_temp_file_size 0; > > то в таком случае на диск nginx ничего не будет писать, > но при этом - будет использовать буферизацию только в памяти. > и для большинства вариантов использования nginx - это более > предпочительный вариант чем fastcgi_buffering off; > потому что в режиме > > fastcgi_buffering on; > fastcgi_max_temp_file_size 0; > > производительность веб-сервера будет выше, > и веб-сервер сможет обработать большее количество запросов. > > только в очень небольшом количестве случаев может быть целесообразно > fastcgi_buffering off; - это когда backend написан на Go - но в таком > случае и nginx там не особо нужен вообще, можно напрямую софт на > Go выставить в интернет - в таком случае все накладные расходы > от промежуточного проксирования будут отсутствовать полностью. > > > совершенно необязательно следовать дефолтным значениям. > > по дефолту включена буферизация ответа бекенда. т.е. nginx будет > вычитывать > > ответ чтобы максимально > > разгрузить бекенд (пытаясь сохранить сначала в своей памяти, а потом на > > диске). у всех ли стоит задача максимально разгрузить бекенд ? > > > а разве нет? > сильно зависит от бекенда. если бекенд вполне современный и не имеет проблем с c10k, то дополнительная буферизация не нужна. мы перед asp.net выключали буферизацию. отлично работало. какой смысл ? терминация ssl, высокая плотность хостинга на белых адресах, L7 маршрутизация по локейшенам. > > ведь с какой же целью nginx ставится перед backend? разве не для того, > чтобы максимально разгрузить backend и чтобы веб-сервер смог обработать > наибольшее количество запросов в секунду и выжать максимум из hardware? > > количество worker-процессов php-fpm на backend очень сильно ограничено, > так что чем быстрее они обработают какой-либо запрос - тем будет лучше. > > я такого не видел, чтобы кто-то ставил nginx перед backend не для того, > чтобы максимально разгрузить backend, а с прямо противоположной целью. > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Mar 6 16:55:12 2025 From: gmm на csdoc.com (Hennadii Makhomed) Date: Thu, 6 Mar 2025 17:55:12 +0100 Subject: upstream sent too big header while reading response header from upstream In-Reply-To: References: <81b7c8a9-0113-4cce-9b3b-9f48b7a4a721@csdoc.com> Message-ID: <1439bcd3-773b-4dd9-8019-48eac9f546e3@csdoc.com> 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 From chipitsine на gmail.com Thu Mar 6 17:42:22 2025 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 6 Mar 2025 18:42:22 +0100 Subject: upstream sent too big header while reading response header from upstream In-Reply-To: <1439bcd3-773b-4dd9-8019-48eac9f546e3@csdoc.com> References: <81b7c8a9-0113-4cce-9b3b-9f48b7a4a721@csdoc.com> <1439bcd3-773b-4dd9-8019-48eac9f546e3@csdoc.com> Message-ID: чт, 6 мар. 2025 г. в 17:55, 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 ? > одинаково хороши, что nginx, что 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-атак и это позволит "максимально разгрузить бекенд". > нет, к сожалению, в части "быстро вычитать терабайт с бекенда, сложить его временно на диск" haproxy не поможет. on disk буферов не умеет. > > очереди есть только в платной версии nginx, а приоритетов - > нет даже и в платной версии nginx, насколько я помню из доки. > > и Максим Дунин сказал, что не надо надеяться на то, что очереди > из платной версии nginx когда-либо появятся в бесплатной версии. > > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Mar 6 19:18:31 2025 From: gmm на csdoc.com (Hennadii Makhomed) Date: Thu, 6 Mar 2025 20:18:31 +0100 Subject: upstream sent too big header while reading response header from upstream In-Reply-To: References: <81b7c8a9-0113-4cce-9b3b-9f48b7a4a721@csdoc.com> <1439bcd3-773b-4dd9-8019-48eac9f546e3@csdoc.com> Message-ID: On 06.03.2025 18:42, Илья Шипицин wrote: >>>>> у всех ли стоит задача максимально разгрузить бекенд ? >>>> >>>> а разве нет? >>> >>> сильно зависит от бекенда. если бекенд вполне современный >>> и не имеет проблем с c10k, то дополнительная буферизация не нужна. >>> мы перед asp.net выключали буферизацию. отлично работало. >>> >>> какой смысл ? терминация ssl, высокая плотность хостинга >>> на белых адресах, L7 маршрутизация по локейшенам. >> >> для такого набора задач - разве не будет лучше использовать haproxy ? > > нет, к сожалению, в части "быстро вычитать терабайт с бекенда, > сложить его временно на диск" haproxy не поможет. > on disk буферов не умеет. "быстро вычитать терабайт с бекенда, сложить его временно на диск" ??? нет необходимости выбирать что-то одно, haproxy и nginx могут взаимодействовать через proxy protocol. TLS termination можно делать как на стороне haproxy, так и на стороне nginx. маршрутизацию запросов на haproxy можно делать на основании req.ssl_sni без TLS termination. -- Best regards, Gena From dedok.mad на gmail.com Thu Mar 13 20:11:54 2025 From: dedok.mad на gmail.com (Vasily Soshnikov) Date: Thu, 13 Mar 2025 23:11:54 +0300 Subject: upstream sent too big header while reading response header from upstream In-Reply-To: References: Message-ID: Привет, Просто увеличить буфер, размер таблицы. Данная ошибка может не быть ошибкой. Например, приложение за NGINX высылает слишком много заголовков и/или большое значение или значения. *Regard,Soshnikov Vasily mailto:dedok.mad на gmail.com * ср, 5 мар. 2025 г., 21:10 Hennadii Makhomed : > Здравствуйте, 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: