From nginx-forum на forum.nginx.org Mon Mar 1 13:45:03 2021 From: nginx-forum на forum.nginx.org (ivanff) Date: Mon, 01 Mar 2021 08:45:03 -0500 Subject: =?UTF-8?B?0JrQsNGB0YLQvtC80L3QsNGPINGB0YLRgNCw0L3QuNGG0LAg0L7RiNC40LHQutC4?= =?UTF-8?B?INC4IGh0dHAg0LrQvtC0INC+0YLQstC10YLQsA==?= Message-ID: При проксировании ошибки на другой хост с целью замены страницы ошибки, при сохрании http кода происходит потеря овзвращаемой страницы сервер один proxy_intercept_errors on; error_page 503 = @errorpages; location @errorpages { proxy_set_header Host ingress-insales-apps; proxy_set_header X-Code $status; proxy_pass http://172.16.0.4; } сервер 2 root /var/www/html; .... error_page 503 /503.html; location / { <------>return 503; } location = /503.html { <------>internal; } и тоге когда первый сервер по какомуто url получит 503, то пользователь увидит стандартную страницу nginx вместо /503.html Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290859,290859#msg-290859 From nginx-forum на forum.nginx.org Mon Mar 1 13:45:35 2021 From: nginx-forum на forum.nginx.org (ivanff) Date: Mon, 01 Mar 2021 08:45:35 -0500 Subject: =?UTF-8?B?UmU6INCa0LDRgdGC0L7QvNC90LDRjyDRgdGC0YDQsNC90LjRhtCwINC+0YjQuNCx?= =?UTF-8?B?0LrQuCDQuCBodHRwINC60L7QtCDQvtGC0LLQtdGC0LA=?= In-Reply-To: References: Message-ID: <0f352c059579019c2c8fcdb5e0735bb3.NginxMailingListRussian@forum.nginx.org> я понимаю почему так происходит, но не знаю как это обойти Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290859,290860#msg-290860 From mdounin на mdounin.ru Mon Mar 1 14:29:36 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 1 Mar 2021 17:29:36 +0300 Subject: =?UTF-8?B?UmU6INCa0LDRgdGC0L7QvNC90LDRjyDRgdGC0YDQsNC90LjRhtCwINC+0YjQuNCx?= =?UTF-8?B?0LrQuCDQuCBodHRwINC60L7QtCDQvtGC0LLQtdGC0LA=?= In-Reply-To: <0f352c059579019c2c8fcdb5e0735bb3.NginxMailingListRussian@forum.nginx.org> References: <0f352c059579019c2c8fcdb5e0735bb3.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Mon, Mar 01, 2021 at 08:45:35AM -0500, ivanff wrote: > я понимаю почему так происходит, но не знаю как это обойти Это происходит потому, что у вас включён перехват ошибок от бэкендов, proxy_intercept_errors. Очевидное решение - выключить proxy_intercept_errors, нет? Выключить можно в конкреном location'е, используемом для обращения за ошибками на бэкенд. Как-то так: proxy_intercept_errors on; error_page 503 = @errorpages; location @errorpages { proxy_pass http://...; proxy_intercept_errors off; ... } Кроме того, можно отказаться от переопределения кодов ошибок в error_page, то есть убрать модификатор "=", и с бэкенда возвращать не 503-й ответ, а просто 200-й с нужным содержимым. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Mar 9 15:42:43 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 9 Mar 2021 18:42:43 +0300 Subject: nginx-1.19.8 Message-ID: Изменения в nginx 1.19.8 09.03.2021 *) Добавление: в директиве proxy_cookie_flags теперь флаги можно задавать с помощью переменных. *) Добавление: параметр proxy_protocol в директиве listen, директивы proxy_protocol и set_real_ip_from в почтовом прокси-сервере. *) Исправление: HTTP/2-соединения сразу закрывались при использовании "keepalive_timeout 0"; ошибка появилась в 1.19.7. *) Исправление: некоторые ошибки логгировались как неизвестные, если nginx был собран с glibc 2.32. *) Исправление: в методе обработки соединений eventport. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Sat Mar 20 23:29:27 2021 From: nginx-forum на forum.nginx.org (edo1) Date: Sat, 20 Mar 2021 19:29:27 -0400 Subject: =?UTF-8?B?0LrRjdGIIChwcm94eSBjYWNoZSBwYXRoKSDQuCBuZ2lueCAtcyByZWxvYWQ=?= Message-ID: <3654ee4c45e3c3fccdccb3e692919096.NginxMailingListRussian@forum.nginx.org> правильно ли я понимаю, что после перезагрузки конфигурации теряется информация о времени последнего доступа к элементам кэша и при необходимости чистки удаление файлов идёт по сути «наобум»? поясню: у нас есть раздача статики, есть кэширующий nginx с кэшем, который наполняется несколько суток, после заполнения кэша ещё несколько дней процент попадания продолжает расти. возникла потребность менять «на лету» некоторые параметры в конфиге, задумался, частый (каждые 10 минут, например) релоад конфига не навредит ли? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291019,291019#msg-291019 From alexcool на gmail.com Sun Mar 21 04:29:25 2021 From: alexcool на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lk=?=) Date: Sun, 21 Mar 2021 11:29:25 +0700 Subject: =?UTF-8?B?UmU6INC60Y3RiCAocHJveHkgY2FjaGUgcGF0aCkg0LggbmdpbnggLXMgcmVsb2Fk?= In-Reply-To: <3654ee4c45e3c3fccdccb3e692919096.NginxMailingListRussian@forum.nginx.org> References: <3654ee4c45e3c3fccdccb3e692919096.NginxMailingListRussian@forum.nginx.org> Message-ID: reload не вредит restart вредит On Sun, Mar 21, 2021 at 6:29 AM edo1 wrote: > правильно ли я понимаю, что после перезагрузки конфигурации теряется > информация о времени последнего доступа к элементам кэша и при > необходимости > чистки удаление файлов идёт по сути «наобум»? > > поясню: у нас есть раздача статики, есть кэширующий nginx с кэшем, который > наполняется несколько суток, после заполнения кэша ещё несколько дней > процент попадания продолжает расти. > возникла потребность менять «на лету» некоторые параметры в конфиге, > задумался, частый (каждые 10 минут, например) релоад конфига не навредит > ли? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291019,291019#msg-291019 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Mar 21 10:36:15 2021 From: nginx-forum на forum.nginx.org (edo1) Date: Sun, 21 Mar 2021 06:36:15 -0400 Subject: =?UTF-8?B?UmU6INC60Y3RiCAocHJveHkgY2FjaGUgcGF0aCkg0LggbmdpbnggLXMgcmVsb2Fk?= In-Reply-To: References: Message-ID: <4de246278bfa6beb1601048d425cb0ea.NginxMailingListRussian@forum.nginx.org> > reload не вредит > restart вредит точно keys_zone выживает при релоаде? вот что нашёл: The cache loader then exits and doesn’t need to run again unless NGINX is restarted or reconfigured and the shared memory segment needs to be reinitialized. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291022,291023#msg-291023 From alexcool на gmail.com Sun Mar 21 13:24:49 2021 From: alexcool на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lk=?=) Date: Sun, 21 Mar 2021 20:24:49 +0700 Subject: =?UTF-8?B?UmU6INC60Y3RiCAocHJveHkgY2FjaGUgcGF0aCkg0LggbmdpbnggLXMgcmVsb2Fk?= In-Reply-To: <4de246278bfa6beb1601048d425cb0ea.NginxMailingListRussian@forum.nginx.org> References: <4de246278bfa6beb1601048d425cb0ea.NginxMailingListRussian@forum.nginx.org> Message-ID: Сто про, братишка. On Sun, Mar 21, 2021 at 5:36 PM edo1 wrote: > > reload не вредит > > restart вредит > > точно keys_zone выживает при релоаде? > > вот что нашёл: > The cache loader then exits and doesn’t need to run again unless NGINX is > restarted or reconfigured and the shared memory segment needs to be > reinitialized. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291022,291023#msg-291023 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Mar 21 21:44:34 2021 From: nginx-forum на forum.nginx.org (edo1) Date: Sun, 21 Mar 2021 17:44:34 -0400 Subject: =?UTF-8?B?RlI6INC00LDQvNC/INC00LXQudGB0YLQstGD0Y7RidC10LPQviDQutC+0L3RhNC4?= =?UTF-8?B?0LPQsA==?= Message-ID: <367b8d52d5c6ed4435a5ab515445ad72.NginxMailingListRussian@forum.nginx.org> несколько раз возникала потребность посмотреть конфиг, с которым работает nginx. подобные запросы находил на SO, так что актуально не только для меня, в одном из вариантов ответа даже gdb приспособили: https://serverfault.com/questions/361421/dump-nginx-config-from-running-process возможно ли сделать что-то вроде `nginx -T`, только выводящее конфиг с которым сейчас работает nginx? как вариант, при запуске записывать актуальный конфиг куда-нибудь в /run и обновлять после `nginx -s reload` Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291028,291028#msg-291028 From mdounin на mdounin.ru Mon Mar 22 14:28:01 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 22 Mar 2021 17:28:01 +0300 Subject: =?UTF-8?B?UmU6IEZSOiDQtNCw0LzQvyDQtNC10LnRgdGC0LLRg9GO0YnQtdCz0L4g0LrQvtC9?= =?UTF-8?B?0YTQuNCz0LA=?= In-Reply-To: <367b8d52d5c6ed4435a5ab515445ad72.NginxMailingListRussian@forum.nginx.org> References: <367b8d52d5c6ed4435a5ab515445ad72.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Sun, Mar 21, 2021 at 05:44:34PM -0400, edo1 wrote: > несколько раз возникала потребность посмотреть конфиг, с которым работает > nginx. > > подобные запросы находил на SO, так что актуально не только для меня, в > одном из вариантов ответа даже gdb приспособили: > https://serverfault.com/questions/361421/dump-nginx-config-from-running-process > > возможно ли сделать что-то вроде `nginx -T`, только выводящее конфиг с > которым сейчас работает nginx? как вариант, при запуске записывать > актуальный конфиг куда-нибудь в /run и обновлять после `nginx -s reload` Сейчас конфиг в исходном виде сохраняется в памяти, если nginx собран с --with-debug. Достать его при необходимости можно с помощью gdb и/или прямым поиском в памяти процесса. В общем случае исходный конфиг не сохраняется, и посмотреть его, соответственно, никак нельзя. В первую очередь потому, что конфиг может быть очень большим, особенно при использовании блоков map{} и geo{}, и хранение его "на всякий случай" - сомнительная трата ресурсов. Какого-либо хорошего решения я тут не вижу. Разве что хранить конфиг до какого-то разумного размера, а дальше переставать. Что до решения "записывать актуальный конфиг куда-нибудь в /run", то это, скорее, внешняя по отношению к nginx'у задача, решаемая скриптами запуска. Но закончится, думаю, как обычно: кто-то этот актуальный конфиг удалит или перепишет, и снова возникнет потребность посмотреть конфиг, с которым работает nginx. Вообще, судя по вопросу на serverfault, основная решаемая задача - "конфиг случайно промотался". Для её решения не нужен конфиг, с которым работает nginx, для её решения нужно не забывать бэкапиться. В случае конфигов - хорошо помогает хранение их хотя бы в локальном репозитории и коммиты после любых значимых изменений. -- Maxim Dounin http://mdounin.ru/ From kvt на kvtsoftware.com Tue Mar 23 06:29:58 2021 From: kvt на kvtsoftware.com (kvt на kvtsoftware.com) Date: Tue, 23 Mar 2021 09:29:58 +0300 Subject: =?UTF-8?B?UmU6IEZSOiDQtNCw0LzQvyDQtNC10LnRgdGC0LLRg9GO0YnQtdCz0L4g0LrQvtC9?= =?UTF-8?B?0YTQuNCz0LA=?= In-Reply-To: References: <367b8d52d5c6ed4435a5ab515445ad72.NginxMailingListRussian@forum.nginx.org> Message-ID: <1177231616480847@mail.yandex.ru> Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Mar 23 15:30:42 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 23 Mar 2021 18:30:42 +0300 Subject: =?UTF-8?B?UmU6IEZSOiDQtNCw0LzQvyDQtNC10LnRgdGC0LLRg9GO0YnQtdCz0L4g0LrQvtC9?= =?UTF-8?B?0YTQuNCz0LA=?= In-Reply-To: <1177231616480847@mail.yandex.ru> References: <367b8d52d5c6ed4435a5ab515445ad72.NginxMailingListRussian@forum.nginx.org> <1177231616480847@mail.yandex.ru> Message-ID: Hello! On Tue, Mar 23, 2021 at 09:29:58AM +0300, kvt на kvtsoftware.com wrote: > Можно сделать к nginx -T опцию, чтобы сохранять результирующий конфиг в > файл/распечатывать на экран. Тогда никакого промежуточного хранения не > нужно будет, а тем кто захочет исследовать - есть такая возможность. Исходная задача - получить конфиг, с которым работает запущенный процесс nginx'а, если этот конфиг уже стёрли с диска. Эта задача не решается, если в master-процессе nginx'а нет этого конфига в исходном виде, а есть только получившиеся в результате парсинга конфига бинарные структуры (ибо из этих бинарных структур восстановить исходныый конфиг нельзя, там для этого недостаточно данных). -- Maxim Dounin http://mdounin.ru/ From kvt на kvtsoftware.com Wed Mar 24 07:05:01 2021 From: kvt на kvtsoftware.com (kvt на kvtsoftware.com) Date: Wed, 24 Mar 2021 10:05:01 +0300 Subject: =?UTF-8?B?UmU6IEZSOiDQtNCw0LzQvyDQtNC10LnRgdGC0LLRg9GO0YnQtdCz0L4g0LrQvtC9?= =?UTF-8?B?0YTQuNCz0LA=?= In-Reply-To: References: <367b8d52d5c6ed4435a5ab515445ad72.NginxMailingListRussian@forum.nginx.org> <1177231616480847@mail.yandex.ru> Message-ID: <225821616569400@mail.yandex.ru> Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Mar 25 02:45:54 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 25 Mar 2021 05:45:54 +0300 Subject: =?UTF-8?B?UmU6IEZSOiDQtNCw0LzQvyDQtNC10LnRgdGC0LLRg9GO0YnQtdCz0L4g0LrQvtC9?= =?UTF-8?B?0YTQuNCz0LA=?= In-Reply-To: <225821616569400@mail.yandex.ru> References: <367b8d52d5c6ed4435a5ab515445ad72.NginxMailingListRussian@forum.nginx.org> <1177231616480847@mail.yandex.ru> <225821616569400@mail.yandex.ru> Message-ID: Hello! On Wed, Mar 24, 2021 at 10:05:01AM +0300, kvt на kvtsoftware.com wrote: > Насколько я понял из первого сообщения требовался именно конфиг с > которым сейчас работает nginx. > > несколько раз возникала потребность посмотреть конфиг, с которым > работает > nginx. > > Вполне возможно, что человек хочет посмотреть что получилось после > инклюда всех файлов в основной конфиг. :) Нет, вопрос именно про конфиг, с которым nginx запущен, и который уже отсутствует на диске, а не про то, что получается после включения всех файлов в основной конфиг. Если у вас сомнения в смысле вопроса - сходите по ссылке на serverfault, сомнения исчезнут. -- Maxim Dounin http://mdounin.ru/ From vitaliy.okulov на gmail.com Thu Mar 25 09:49:39 2021 From: vitaliy.okulov на gmail.com (Vitaliy Okulov) Date: Thu, 25 Mar 2021 12:49:39 +0300 Subject: =?UTF-8?B?0LfQsNC/0LjRgdGMINC+0YLQstC10YLQsCDQvtGCINGB0LXRgNCy0LjRgdCwINCy?= =?UTF-8?B?INC70L7QsyDRhNCw0LnQuyBuZ2lueA==?= Message-ID: Добрый день. Подскажите что можно сделать в ситуации когда требуется писать в файл тело ответа сервиса, попробовал вариант с обработкой в body_filter_by_lua, но при больших телах ответа воркер блокируется и потребляет 100% CPU Какие еще варианты реализовать задачу на уровне nginx возможны? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Mar 25 11:30:42 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 25 Mar 2021 16:30:42 +0500 Subject: =?UTF-8?B?UmU6INC30LDQv9C40YHRjCDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC40YE=?= =?UTF-8?B?0LAg0LIg0LvQvtCzINGE0LDQudC7IG5naW54?= In-Reply-To: References: Message-ID: proxy_store ? чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov : > Добрый день. > Подскажите что можно сделать в ситуации когда требуется писать в файл тело > ответа сервиса, попробовал вариант с обработкой в body_filter_by_lua, но > при больших телах ответа воркер блокируется и потребляет 100% CPU > Какие еще варианты реализовать задачу на уровне nginx возможны? > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vitaliy.okulov на gmail.com Thu Mar 25 13:07:37 2021 From: vitaliy.okulov на gmail.com (Vitaliy Okulov) Date: Thu, 25 Mar 2021 16:07:37 +0300 Subject: =?UTF-8?B?UmU6INC30LDQv9C40YHRjCDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC40YE=?= =?UTF-8?B?0LAg0LIg0LvQvtCzINGE0LDQudC7IG5naW54?= In-Reply-To: References: Message-ID: Я так понимаю что возникнут проблемы с уникальностью данных в зависимости от пользователя, запроса который он создает и т.д. чт, 25 мар. 2021 г. в 14:30, Илья Шипицин : > proxy_store ? > > чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov : > >> Добрый день. >> Подскажите что можно сделать в ситуации когда требуется писать в файл >> тело ответа сервиса, попробовал вариант с обработкой в body_filter_by_lua, >> но при больших телах ответа воркер блокируется и потребляет 100% CPU >> Какие еще варианты реализовать задачу на уровне nginx возможны? >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ngnx8810773a83 на avksrv.org Thu Mar 25 20:48:36 2021 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Thu, 25 Mar 2021 23:48:36 +0300 Subject: =?UTF-8?B?UmU6INC30LDQv9C40YHRjCDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC40YE=?= =?UTF-8?B?0LAg0LIg0LvQvtCzINGE0LDQudC7IG5naW54?= In-Reply-To: References: Message-ID: Както так ? proxy_store /data/www/$uri/$request_id ? 25.03.2021 16:07, Vitaliy Okulov пишет: > Я так понимаю что возникнут проблемы с уникальностью данных в > зависимости от пользователя, запроса который он создает и т.д. > > чт, 25 мар. 2021 г. в 14:30, Илья Шипицин >: > > proxy_store ? > > чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov > >: > > Добрый день. > Подскажите что можно сделать в ситуации когда требуется писать > в файл тело ответа сервиса, попробовал вариант с обработкой в > body_filter_by_lua, но при больших телах ответа воркер > блокируется и потребляет 100% CPU > Какие еще варианты реализовать задачу на уровне nginx возможны? > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Thu Mar 25 20:59:30 2021 From: nginx-forum на forum.nginx.org (maximkherson) Date: Thu, 25 Mar 2021 16:59:30 -0400 Subject: =?UTF-8?B?0JrQsNC6INGD0LHRgNCw0YLRjCDRgdC70LXRiCAvINC40Lcg0L3QsNGH0LDQu9Cw?= =?UTF-8?B?ICRyZXF1ZXN0IHVyaQ==?= Message-ID: Приветсвую! Делаю редирект с локального хочта на гугл. В начальном запросе в браузере после / идёт поисковый запрос: http://redirect.localhost/hello Далее происходит редирект на google.com/search?q= и проблема в том, что не знаю как добавить к этому адресу (google.com/search?q=) $request_uri без слеша в начале. Получается вот так: https://www.google.com/search?q=/hello а надо так: https://www.google.com/search?q=hello Мой код: server { <------>listen *:80; <------>server_name redirect.localhost; <------>return 302 https://google.com/search?q=$request_uri; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291051,291051#msg-291051 From root на dl.sm.ua Fri Mar 26 03:44:30 2021 From: root на dl.sm.ua (Dmytro Lavryk) Date: Fri, 26 Mar 2021 05:44:30 +0200 Subject: =?UTF-8?B?0JLRltC00L/QvtCy0ZbQtNGMOiDQmtCw0Log0YPQsdGA0LDRgtGMINGB0LvQtdGI?= =?UTF-8?B?IC8g0LjQtyDQvdCw0YfQsNC70LAgJHJlcXVlc3QgdXJp?= In-Reply-To: References: Message-ID: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> rewrite ^/(.+) https://google.com/search?q=$1 redirect; ---- Увімкнуто чт, 25 бер. 2021 22:59:30 +0200 maximkherson написав ---- Приветсвую! Делаю редирект с локального хочта на гугл. В начальном запросе в браузере после / идёт поисковый запрос: http://redirect.localhost/hello Далее происходит редирект на google.com/search?q= и проблема в том, что не знаю как добавить к этому адресу (google.com/search?q=) $request_uri без слеша в начале. Получается вот так: https://www.google.com/search?q=/hello а надо так: https://www.google.com/search?q=hello Мой код: server { <------>listen *:80; <------>server_name redirect.localhost; <------>return 302 https://google.com/search?q=$request_uri; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291051,291051#msg-291051 _______________________________________________ nginx-ru mailing list mailto:nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Mar 26 06:45:33 2021 From: nginx-forum на forum.nginx.org (maximkherson) Date: Fri, 26 Mar 2021 02:45:33 -0400 Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INGD0LHRgNCw0YLRjCDRgdC7?= =?UTF-8?B?0LXRiCAvINC40Lcg0L3QsNGH0LDQu9CwICRyZXF1ZXN0IHVyaQ==?= In-Reply-To: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> Message-ID: Могли бы вы пожалуйста пояснить данную запись? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291054,291055#msg-291055 From raven_kg на megaline.kg Fri Mar 26 10:14:52 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Fri, 26 Mar 2021 16:14:52 +0600 Subject: =?UTF-8?B?0J7RiNC40LHQutC4INC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCB6?= =?UTF-8?B?bGliLW5n?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> Message-ID: <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме совместимости с zlib) лог буквально завален ошибками: "gzip filter failed to use preallocated memory: 65536 of 0 while sending to client" Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в анонсе к какой-то из версий 1.13. From pluknet на nginx.com Fri Mar 26 10:32:48 2021 From: pluknet на nginx.com (Sergey Kandaurov) Date: Fri, 26 Mar 2021 13:32:48 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> Message-ID: <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> > On 26 Mar 2021, at 13:14, raven_kg на megaline.kg wrote: > > После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме совместимости с zlib) лог буквально завален ошибками: > > "gzip filter failed to use preallocated memory: 65536 of 0 while sending to client" > > Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в анонсе к какой-то из версий 1.13. > Попробуйте патч, при сборке с zlib-ng: diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c --- a/src/http/modules/ngx_http_gzip_filter_module.c +++ b/src/http/modules/ngx_http_gzip_filter_module.c @@ -516,7 +516,7 @@ ngx_http_gzip_filter_memory(ngx_http_req */ if (conf->level == 1) { - wbits = ngx_max(wbits, 13); + wbits = ngx_max(wbits, 15); } ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) -- Sergey Kandaurov From raven_kg на megaline.kg Fri Mar 26 10:37:07 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Fri, 26 Mar 2021 16:37:07 +0600 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> Message-ID: Т.е. использовать нативную сборку nginx не получится? 26.03.2021 16:32, Sergey Kandaurov пишет: >> On 26 Mar 2021, at 13:14, raven_kg на megaline.kg wrote: >> >> После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме совместимости с zlib) лог буквально завален ошибками: >> >> "gzip filter failed to use preallocated memory: 65536 of 0 while sending to client" >> >> Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в анонсе к какой-то из версий 1.13. >> > Попробуйте патч, при сборке с zlib-ng: > > diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c > --- a/src/http/modules/ngx_http_gzip_filter_module.c > +++ b/src/http/modules/ngx_http_gzip_filter_module.c > @@ -516,7 +516,7 @@ ngx_http_gzip_filter_memory(ngx_http_req > */ > > if (conf->level == 1) { > - wbits = ngx_max(wbits, 13); > + wbits = ngx_max(wbits, 15); > } > > ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > > From root на dl.sm.ua Fri Mar 26 10:42:51 2021 From: root на dl.sm.ua (Dmytro Lavryk) Date: Fri, 26 Mar 2021 12:42:51 +0200 Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INGD0LHRgNCw0YLRjCDRgdC7?= =?UTF-8?B?0LXRiCAvINC40Lcg0L3QsNGH0LDQu9CwICRyZXF1ZXN0IHVyaQ==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> Message-ID: <1786e212d5e.c3dea1c21117644.1676870692236632406@dl.sm.ua> Не очень понимаю, что тут объяснять еще можно... Смотрим УРЛ, если есть хоть что-то после слеша, запоминаем его и потом подставляем в урл гугла в качестве параметра. И отсылаем 302 на этот урл ---- Увімкнуто пт, 26 бер. 2021 08:45:33 +0200 maximkherson написав ---- Могли бы вы пожалуйста пояснить данную запись? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291054,291055#msg-291055 _______________________________________________ nginx-ru mailing list mailto:nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vitaliy.okulov на gmail.com Fri Mar 26 13:04:07 2021 From: vitaliy.okulov на gmail.com (Vitaliy Okulov) Date: Fri, 26 Mar 2021 16:04:07 +0300 Subject: =?UTF-8?B?UmU6INC30LDQv9C40YHRjCDQvtGC0LLQtdGC0LAg0L7RgiDRgdC10YDQstC40YE=?= =?UTF-8?B?0LAg0LIg0LvQvtCzINGE0LDQudC7IG5naW54?= In-Reply-To: References: Message-ID: Точно, пойдет, спасибо! Кто-нибудь разбирался как оно работает внутри, какое влияние на скорость обработки запросов? чт, 25 мар. 2021 г. в 23:48, Alexey : > Както так ? > proxy_store /data/www/$uri/$request_id ? > > 25.03.2021 16:07, Vitaliy Okulov пишет: > > Я так понимаю что возникнут проблемы с уникальностью данных в > > зависимости от пользователя, запроса который он создает и т.д. > > > > чт, 25 мар. 2021 г. в 14:30, Илья Шипицин > >: > > > > proxy_store ? > > > > чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov > > >: > > > > Добрый день. > > Подскажите что можно сделать в ситуации когда требуется писать > > в файл тело ответа сервиса, попробовал вариант с обработкой в > > body_filter_by_lua, но при больших телах ответа воркер > > блокируется и потребляет 100% CPU > > Какие еще варианты реализовать задачу на уровне nginx возможны? > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Mar 26 17:47:32 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 26 Mar 2021 20:47:32 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> Message-ID: Hello! On Fri, Mar 26, 2021 at 04:37:07PM +0600, raven_kg на megaline.kg wrote: > Т.е. использовать нативную сборку nginx не получится? Использовать можно как есть, если сами по себе алерты не смущают. Эти alert'ы не фатальны и говорят лишь о том, что nginx был вынужден аллоцировать дополнительную память, хотя от zlib'а это не ожидалось (и требования по памяти задокументированы), т.е. zlib ведёт себя некорректно. В вашем случае некорректное поведение ожидаемо. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Mar 26 18:54:43 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 26 Mar 2021 21:54:43 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> Message-ID: Hello! On Fri, Mar 26, 2021 at 01:32:48PM +0300, Sergey Kandaurov wrote: > > On 26 Mar 2021, at 13:14, raven_kg на megaline.kg wrote: > > > > После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме совместимости с zlib) лог буквально завален ошибками: > > > > "gzip filter failed to use preallocated memory: 65536 of 0 while sending to client" > > > > Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в анонсе к какой-то из версий 1.13. > > > > Попробуйте патч, при сборке с zlib-ng: > > diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c > --- a/src/http/modules/ngx_http_gzip_filter_module.c > +++ b/src/http/modules/ngx_http_gzip_filter_module.c > @@ -516,7 +516,7 @@ ngx_http_gzip_filter_memory(ngx_http_req > */ > > if (conf->level == 1) { > - wbits = ngx_max(wbits, 13); > + wbits = ngx_max(wbits, 15); Насколько я вижу, в zlib-ng используюся те же 13, что и в варианте от Intel: https://github.com/jtkukunas/zlib/blob/master/deflate.c#L296 https://github.com/zlib-ng/zlib-ng/blob/develop/deflate.c#L304 А вот аллокация под hash стала 2x64k. (В интеловском варианте, кстати, за последнее время и hash подужался, и windowBits в 13 ставится только для значений, больших 13. Возможно, на него стоит ещё разок взглянуть и урезать осетра.) # HG changeset patch # User Maxim Dounin # Date 1616784418 -10800 # Fri Mar 26 21:46:58 2021 +0300 # Node ID cc67b7253d6c19fa172c8412111568398a5e7b5b # Parent 2ed5d03c2d902efef969e24be6bb4d3f98a49efa Gzip: support for zlib-ng. diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c --- a/src/http/modules/ngx_http_gzip_filter_module.c +++ b/src/http/modules/ngx_http_gzip_filter_module.c @@ -57,6 +57,7 @@ typedef struct { unsigned nomem:1; unsigned buffering:1; unsigned intel:1; + unsigned zlib_ng:1; size_t zin; size_t zout; @@ -214,6 +215,7 @@ static ngx_http_output_header_filter_pt static ngx_http_output_body_filter_pt ngx_http_next_body_filter; static ngx_uint_t ngx_http_gzip_assume_intel; +static ngx_uint_t ngx_http_gzip_assume_zlib_ng; static ngx_int_t @@ -506,7 +508,7 @@ ngx_http_gzip_filter_memory(ngx_http_req if (!ngx_http_gzip_assume_intel) { ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9)); - } else { + } else if (!ngx_http_gzip_assume_zlib_ng) { /* * A zlib variant from Intel, https://github.com/jtkukunas/zlib. * It can force window bits to 13 for fast compression level, @@ -523,6 +525,20 @@ ngx_http_gzip_filter_memory(ngx_http_req + (1 << (ngx_max(memlevel, 8) + 8)) + (1 << (memlevel + 8)); ctx->intel = 1; + + } else { + /* + * Another zlib variant, https://github.com/zlib-ng/zlib-ng. + * Similar to Intel's variant, though uses 128K hash. + */ + + if (conf->level == 1) { + wbits = ngx_max(wbits, 13); + } + + ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) + + (1 << 17) + (1 << (memlevel + 8)); + ctx->zlib_ng = 1; } } @@ -945,11 +961,14 @@ ngx_http_gzip_filter_alloc(void *opaque, return p; } - if (ctx->intel) { + if (ctx->zlib_ng) { ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0, "gzip filter failed to use preallocated memory: " "%ud of %ui", items * size, ctx->allocated); + } else if (ctx->intel) { + ngx_http_gzip_assume_zlib_ng = 1; + } else { ngx_http_gzip_assume_intel = 1; } -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Mar 29 02:09:14 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Mar 2021 05:09:14 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> Message-ID: Hello! On Fri, Mar 26, 2021 at 09:54:43PM +0300, Maxim Dounin wrote: > Hello! > > On Fri, Mar 26, 2021 at 01:32:48PM +0300, Sergey Kandaurov wrote: > > > > On 26 Mar 2021, at 13:14, raven_kg на megaline.kg wrote: > > > > > > После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме совместимости с zlib) лог буквально завален ошибками: > > > > > > "gzip filter failed to use preallocated memory: 65536 of 0 while sending to client" > > > > > > Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в анонсе к какой-то из версий 1.13. > > > > > > > Попробуйте патч, при сборке с zlib-ng: > > > > diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c > > --- a/src/http/modules/ngx_http_gzip_filter_module.c > > +++ b/src/http/modules/ngx_http_gzip_filter_module.c > > @@ -516,7 +516,7 @@ ngx_http_gzip_filter_memory(ngx_http_req > > */ > > > > if (conf->level == 1) { > > - wbits = ngx_max(wbits, 13); > > + wbits = ngx_max(wbits, 15); > > Насколько я вижу, в zlib-ng используюся те же 13, что и в варианте > от Intel: > > https://github.com/jtkukunas/zlib/blob/master/deflate.c#L296 > https://github.com/zlib-ng/zlib-ng/blob/develop/deflate.c#L304 > > А вот аллокация под hash стала 2x64k. > > (В интеловском варианте, кстати, за последнее время и hash > подужался, и windowBits в 13 ставится только для значений, больших > 13. Возможно, на него стоит ещё разок взглянуть и урезать осетра.) Взглянул, урезал. # HG changeset patch # User Maxim Dounin # Date 1616983280 -10800 # Mon Mar 29 05:01:20 2021 +0300 # Node ID d82e9d8285e2552cafcea2033069cdd31f4a5d32 # Parent 1ebd78df4ce7262967c5dadce7bac454c4086896 Gzip: support for zlib-ng. diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c --- a/src/http/modules/ngx_http_gzip_filter_module.c +++ b/src/http/modules/ngx_http_gzip_filter_module.c @@ -57,6 +57,7 @@ typedef struct { unsigned nomem:1; unsigned buffering:1; unsigned intel:1; + unsigned zlib_ng:1; size_t zin; size_t zout; @@ -214,6 +215,7 @@ static ngx_http_output_header_filter_pt static ngx_http_output_body_filter_pt ngx_http_next_body_filter; static ngx_uint_t ngx_http_gzip_assume_intel; +static ngx_uint_t ngx_http_gzip_assume_zlib_ng; static ngx_int_t @@ -506,7 +508,7 @@ ngx_http_gzip_filter_memory(ngx_http_req if (!ngx_http_gzip_assume_intel) { ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9)); - } else { + } else if (!ngx_http_gzip_assume_zlib_ng) { /* * A zlib variant from Intel, https://github.com/jtkukunas/zlib. * It can force window bits to 13 for fast compression level, @@ -523,6 +525,20 @@ ngx_http_gzip_filter_memory(ngx_http_req + (1 << (ngx_max(memlevel, 8) + 8)) + (1 << (memlevel + 8)); ctx->intel = 1; + + } else { + /* + * Another zlib variant, https://github.com/zlib-ng/zlib-ng. + * Similar to Intel's variant, though uses 128K hash. + */ + + if (conf->level == 1) { + wbits = ngx_max(wbits, 13); + } + + ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) + + 131072 + (1 << (memlevel + 8)); + ctx->zlib_ng = 1; } } @@ -945,11 +961,14 @@ ngx_http_gzip_filter_alloc(void *opaque, return p; } - if (ctx->intel) { + if (ctx->zlib_ng) { ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0, "gzip filter failed to use preallocated memory: " "%ud of %ui", items * size, ctx->allocated); + } else if (ctx->intel) { + ngx_http_gzip_assume_zlib_ng = 1; + } else { ngx_http_gzip_assume_intel = 1; } # HG changeset patch # User Maxim Dounin # Date 1616983654 -10800 # Mon Mar 29 05:07:34 2021 +0300 # Node ID e70b352ddb2ed1e92997408b3926e64aa55b4a14 # Parent d82e9d8285e2552cafcea2033069cdd31f4a5d32 Gzip: updated handling of zlib variant from Intel. In current versions (all versions based on zlib 1.2.11, at least since 2018) it no longer uses 64K hash and does not force window bits to 13 if it is less than 13. That is, it needs just 16 bytes more memory than normal zlib, so these bytes are simply added to the normal size calculation. diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c --- a/src/http/modules/ngx_http_gzip_filter_module.c +++ b/src/http/modules/ngx_http_gzip_filter_module.c @@ -56,7 +56,6 @@ typedef struct { unsigned done:1; unsigned nomem:1; unsigned buffering:1; - unsigned intel:1; unsigned zlib_ng:1; size_t zin; @@ -214,7 +213,6 @@ static ngx_str_t ngx_http_gzip_ratio = static ngx_http_output_header_filter_pt ngx_http_next_header_filter; static ngx_http_output_body_filter_pt ngx_http_next_body_filter; -static ngx_uint_t ngx_http_gzip_assume_intel; static ngx_uint_t ngx_http_gzip_assume_zlib_ng; @@ -503,33 +501,21 @@ ngx_http_gzip_filter_memory(ngx_http_req * 8K is for zlib deflate_state, it takes * *) 5816 bytes on i386 and sparc64 (32-bit mode) * *) 5920 bytes on amd64 and sparc64 + * + * A zlib variant from Intel (https://github.com/jtkukunas/zlib) + * uses additional 16-byte padding in one of window-sized buffers. */ - if (!ngx_http_gzip_assume_intel) { - ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9)); - - } else if (!ngx_http_gzip_assume_zlib_ng) { - /* - * A zlib variant from Intel, https://github.com/jtkukunas/zlib. - * It can force window bits to 13 for fast compression level, - * on processors with SSE 4.2 it uses 64K hash instead of scaling - * it from the specified memory level, and also introduces - * 16-byte padding in one out of the two window-sized buffers. - */ - - if (conf->level == 1) { - wbits = ngx_max(wbits, 13); - } - + if (!ngx_http_gzip_assume_zlib_ng) { ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) - + (1 << (ngx_max(memlevel, 8) + 8)) - + (1 << (memlevel + 8)); - ctx->intel = 1; + + (1 << (memlevel + 9)); } else { /* * Another zlib variant, https://github.com/zlib-ng/zlib-ng. - * Similar to Intel's variant, though uses 128K hash. + * It forces window bits to 13 for fast compression level, + * uses 16-byte padding in one of window-sized buffers, and + * uses 128K hash. */ if (conf->level == 1) { @@ -966,11 +952,8 @@ ngx_http_gzip_filter_alloc(void *opaque, "gzip filter failed to use preallocated memory: " "%ud of %ui", items * size, ctx->allocated); - } else if (ctx->intel) { + } else { ngx_http_gzip_assume_zlib_ng = 1; - - } else { - ngx_http_gzip_assume_intel = 1; } p = ngx_palloc(ctx->request->pool, items * size); -- Maxim Dounin http://mdounin.ru/ From raven_kg на megaline.kg Mon Mar 29 07:00:21 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Mon, 29 Mar 2021 13:00:21 +0600 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> Message-ID: <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> 29.03.2021 08:09, Maxim Dounin пишет: > Hello! > > On Fri, Mar 26, 2021 at 09:54:43PM +0300, Maxim Dounin wrote: > >> Hello! >> >> On Fri, Mar 26, 2021 at 01:32:48PM +0300, Sergey Kandaurov wrote: >> >>>> On 26 Mar 2021, at 13:14, raven_kg на megaline.kg wrote: >>>> >>>> После смены нативной zlib-1.2.7 на zlib-ng 2.0.1 (собрана в режиме совместимости с zlib) лог буквально завален ошибками: >>>> >>>> "gzip filter failed to use preallocated memory: 65536 of 0 while sending to client" >>>> >>>> Хотя, насколько я припоминаю, обход ошибок такого рода упоминался в анонсе к какой-то из версий 1.13. >>>> >>> Попробуйте патч, при сборке с zlib-ng: >>> >>> diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c >>> --- a/src/http/modules/ngx_http_gzip_filter_module.c >>> +++ b/src/http/modules/ngx_http_gzip_filter_module.c >>> @@ -516,7 +516,7 @@ ngx_http_gzip_filter_memory(ngx_http_req >>> */ >>> >>> if (conf->level == 1) { >>> - wbits = ngx_max(wbits, 13); >>> + wbits = ngx_max(wbits, 15); >> Насколько я вижу, в zlib-ng используюся те же 13, что и в варианте >> от Intel: >> >> https://github.com/jtkukunas/zlib/blob/master/deflate.c#L296 >> https://github.com/zlib-ng/zlib-ng/blob/develop/deflate.c#L304 >> >> А вот аллокация под hash стала 2x64k. >> >> (В интеловском варианте, кстати, за последнее время и hash >> подужался, и windowBits в 13 ставится только для значений, больших >> 13. Возможно, на него стоит ещё разок взглянуть и урезать осетра.) > Взглянул, урезал. > > # HG changeset patch > # User Maxim Dounin > # Date 1616983280 -10800 > # Mon Mar 29 05:01:20 2021 +0300 > # Node ID d82e9d8285e2552cafcea2033069cdd31f4a5d32 > # Parent 1ebd78df4ce7262967c5dadce7bac454c4086896 > Gzip: support for zlib-ng. > > diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c > --- a/src/http/modules/ngx_http_gzip_filter_module.c > +++ b/src/http/modules/ngx_http_gzip_filter_module.c > @@ -57,6 +57,7 @@ typedef struct { > unsigned nomem:1; > unsigned buffering:1; > unsigned intel:1; > + unsigned zlib_ng:1; > > size_t zin; > size_t zout; > @@ -214,6 +215,7 @@ static ngx_http_output_header_filter_pt > static ngx_http_output_body_filter_pt ngx_http_next_body_filter; > > static ngx_uint_t ngx_http_gzip_assume_intel; > +static ngx_uint_t ngx_http_gzip_assume_zlib_ng; > > > static ngx_int_t > @@ -506,7 +508,7 @@ ngx_http_gzip_filter_memory(ngx_http_req > if (!ngx_http_gzip_assume_intel) { > ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9)); > > - } else { > + } else if (!ngx_http_gzip_assume_zlib_ng) { > /* > * A zlib variant from Intel, https://github.com/jtkukunas/zlib. > * It can force window bits to 13 for fast compression level, > @@ -523,6 +525,20 @@ ngx_http_gzip_filter_memory(ngx_http_req > + (1 << (ngx_max(memlevel, 8) + 8)) > + (1 << (memlevel + 8)); > ctx->intel = 1; > + > + } else { > + /* > + * Another zlib variant, https://github.com/zlib-ng/zlib-ng. > + * Similar to Intel's variant, though uses 128K hash. > + */ > + > + if (conf->level == 1) { > + wbits = ngx_max(wbits, 13); > + } > + > + ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > + + 131072 + (1 << (memlevel + 8)); > + ctx->zlib_ng = 1; > } > } > > @@ -945,11 +961,14 @@ ngx_http_gzip_filter_alloc(void *opaque, > return p; > } > > - if (ctx->intel) { > + if (ctx->zlib_ng) { > ngx_log_error(NGX_LOG_ALERT, ctx->request->connection->log, 0, > "gzip filter failed to use preallocated memory: " > "%ud of %ui", items * size, ctx->allocated); > > + } else if (ctx->intel) { > + ngx_http_gzip_assume_zlib_ng = 1; > + > } else { > ngx_http_gzip_assume_intel = 1; > } > # HG changeset patch > # User Maxim Dounin > # Date 1616983654 -10800 > # Mon Mar 29 05:07:34 2021 +0300 > # Node ID e70b352ddb2ed1e92997408b3926e64aa55b4a14 > # Parent d82e9d8285e2552cafcea2033069cdd31f4a5d32 > Gzip: updated handling of zlib variant from Intel. > > In current versions (all versions based on zlib 1.2.11, at least > since 2018) it no longer uses 64K hash and does not force window > bits to 13 if it is less than 13. That is, it needs just 16 bytes > more memory than normal zlib, so these bytes are simply added to > the normal size calculation. > > diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c > --- a/src/http/modules/ngx_http_gzip_filter_module.c > +++ b/src/http/modules/ngx_http_gzip_filter_module.c > @@ -56,7 +56,6 @@ typedef struct { > unsigned done:1; > unsigned nomem:1; > unsigned buffering:1; > - unsigned intel:1; > unsigned zlib_ng:1; > > size_t zin; > @@ -214,7 +213,6 @@ static ngx_str_t ngx_http_gzip_ratio = > static ngx_http_output_header_filter_pt ngx_http_next_header_filter; > static ngx_http_output_body_filter_pt ngx_http_next_body_filter; > > -static ngx_uint_t ngx_http_gzip_assume_intel; > static ngx_uint_t ngx_http_gzip_assume_zlib_ng; > > > @@ -503,33 +501,21 @@ ngx_http_gzip_filter_memory(ngx_http_req > * 8K is for zlib deflate_state, it takes > * *) 5816 bytes on i386 and sparc64 (32-bit mode) > * *) 5920 bytes on amd64 and sparc64 > + * > + * A zlib variant from Intel (https://github.com/jtkukunas/zlib) > + * uses additional 16-byte padding in one of window-sized buffers. > */ > > - if (!ngx_http_gzip_assume_intel) { > - ctx->allocated = 8192 + (1 << (wbits + 2)) + (1 << (memlevel + 9)); > - > - } else if (!ngx_http_gzip_assume_zlib_ng) { > - /* > - * A zlib variant from Intel, https://github.com/jtkukunas/zlib. > - * It can force window bits to 13 for fast compression level, > - * on processors with SSE 4.2 it uses 64K hash instead of scaling > - * it from the specified memory level, and also introduces > - * 16-byte padding in one out of the two window-sized buffers. > - */ > - > - if (conf->level == 1) { > - wbits = ngx_max(wbits, 13); > - } > - > + if (!ngx_http_gzip_assume_zlib_ng) { > ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > - + (1 << (ngx_max(memlevel, 8) + 8)) > - + (1 << (memlevel + 8)); > - ctx->intel = 1; > + + (1 << (memlevel + 9)); > > } else { > /* > * Another zlib variant, https://github.com/zlib-ng/zlib-ng. > - * Similar to Intel's variant, though uses 128K hash. > + * It forces window bits to 13 for fast compression level, > + * uses 16-byte padding in one of window-sized buffers, and > + * uses 128K hash. > */ > > if (conf->level == 1) { > @@ -966,11 +952,8 @@ ngx_http_gzip_filter_alloc(void *opaque, > "gzip filter failed to use preallocated memory: " > "%ud of %ui", items * size, ctx->allocated); > > - } else if (ctx->intel) { > + } else { > ngx_http_gzip_assume_zlib_ng = 1; > - > - } else { > - ngx_http_gzip_assume_intel = 1; > } > > p = ngx_palloc(ctx->request->pool, items * size); > Будут-ли эти правки включены в какой-либо из релизов? From izorkin на gmail.com Mon Mar 29 07:04:52 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Mon, 29 Mar 2021 10:04:52 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> Message-ID: <974749458.20210329100452@gmail.com> Здравствуйте, Maxim. А патч, который расположен тут - https://github.com/zlib-ng/patches/tree/master/nginx не подойдёт? Вы писали 29 марта 2021 г., 5:09:14: > Взглянул, урезал. > ... -- С уважением, Izorkin mailto:izorkin на gmail.com From raven_kg на megaline.kg Mon Mar 29 07:16:51 2021 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Mon, 29 Mar 2021 13:16:51 +0600 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <974749458.20210329100452@gmail.com> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <974749458.20210329100452@gmail.com> Message-ID: <08b71360-2a45-5317-3e7b-6e2bd661a5e7@megaline.kg> Это патч, позволяющий использовать zlib-ng собранную без совместимости с нативной zlib, т.е. исключается возможность выбора библиотеки. 29.03.2021 13:04, izorkin на gmail.com пишет: > Здравствуйте, Maxim. > > А патч, который расположен тут - https://github.com/zlib-ng/patches/tree/master/nginx не подойдёт? > > Вы писали 29 марта 2021 г., 5:09:14: > >> Взглянул, урезал. >> ... > From mdounin на mdounin.ru Mon Mar 29 13:19:47 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Mar 2021 16:19:47 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> Message-ID: Hello! On Mon, Mar 29, 2021 at 01:00:21PM +0600, raven_kg на megaline.kg wrote: [...] > Будут-ли эти правки включены в какой-либо из релизов? Да, как только пройдут review. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Mar 29 13:31:39 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 29 Mar 2021 18:31:39 +0500 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> Message-ID: недавно проводил бенчмарки, zlib не самое быстрое https://github.com/inikep/lzbench при том, что на браузерной нагрузке (html + css + js) сжимается всё хорошо и из обшей нагрузки gzip занимает процентов 80 от cpu. glib-ng я не тестил, но взял на заметку. не рассматривали slz, например ? пн, 29 мар. 2021 г. в 18:19, Maxim Dounin : > Hello! > > On Mon, Mar 29, 2021 at 01:00:21PM +0600, raven_kg на megaline.kg wrote: > > [...] > > > Будут-ли эти правки включены в какой-либо из релизов? > > Да, как только пройдут review. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Mar 29 13:44:11 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Mar 2021 16:44:11 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: <974749458.20210329100452@gmail.com> References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <974749458.20210329100452@gmail.com> Message-ID: Hello! On Mon, Mar 29, 2021 at 10:04:52AM +0300, izorkin на gmail.com wrote: > А патч, который расположен тут - https://github.com/zlib-ng/patches/tree/master/nginx не подойдёт? Зависит от задачи. Если я правильно понимаю, основная задача, которую решает этот патч - затащить zlib-ng без использования уровня совместимости с zlib. Эта задача, вроде бы, не стоит примерно ни перед кем. Что касается размеров выделяемой памяти, которые и обсуждаются в этом треде, то они в этом патче неправильные. Хотя и вроде бы перекрывают потребности zlib-ng во всех возможных случаях, так что работать без ругани будет. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Mar 29 14:55:18 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Mar 2021 17:55:18 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> Message-ID: Hello! On Mon, Mar 29, 2021 at 06:31:39PM +0500, Илья Шипицин wrote: > недавно проводил бенчмарки, zlib не самое быстрое > https://github.com/inikep/lzbench > > > при том, что на браузерной нагрузке (html + css + js) сжимается всё хорошо > и из обшей нагрузки gzip занимает процентов 80 от cpu. Тут важно держать себя в руках и не пытаться крутить уровень сжатия. Я неоднократно встречал ситуации, когда люди зачем-то ставили "gzip_comp_level 9;", а потом удивлялись потреблению процессора. Не говоря уже про регулярно встречающиеся попытки поставить 6. Если использовать zlib на уровне сжатия 1, то он вполне неплох в части потребления процессора, а если этого мало - стоит смотреть в сторону gzip_static и/или кэширования сжатых ответов. > glib-ng я не тестил, но взял на заметку. AFAIK, сейчас существует три вариации "на тему zlib", все пытаются ускорить работу на современных процесорах: zlib "от Intel", zlib "от Cloudflare", и вот темерь ещё zlib-ng. Было бы интересно посмотреть на какое-нибудь сравнение скорости между всеми этими вариациями на разных процессорах. > не рассматривали slz, например ? ЕМНИП, мы на него смотрели когда-то давно. В целом идея интересная, но качество сжатия оставляет желать. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Mar 29 15:40:04 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 29 Mar 2021 20:40:04 +0500 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> Message-ID: пн, 29 мар. 2021 г. в 19:55, Maxim Dounin : > Hello! > > On Mon, Mar 29, 2021 at 06:31:39PM +0500, Илья Шипицин wrote: > > > недавно проводил бенчмарки, zlib не самое быстрое > > https://github.com/inikep/lzbench > > > > > > при том, что на браузерной нагрузке (html + css + js) сжимается всё > хорошо > > и из обшей нагрузки gzip занимает процентов 80 от cpu. > > Тут важно держать себя в руках и не пытаться крутить уровень > сжатия. Я неоднократно встречал ситуации, когда люди зачем-то > ставили "gzip_comp_level 9;", а потом удивлялись потреблению > процессора. Не говоря уже про регулярно встречающиеся попытки > поставить 6. Если использовать zlib на уровне сжатия 1, то он > вполне неплох в части потребления процессора, а если этого мало - > стоит смотреть в сторону gzip_static и/или кэширования сжатых > ответов. > для примера, silesia xml, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz [root на localhost lzbench]# ./lzbench -ezlib,1/slz_zlib,1 silezia/xml lzbench 1.8 (64-bit Linux) Assembled by P.Skibinski Compressor name Compress. Decompress. Compr. size Ratio Filename memcpy 10948 MB/s 15766 MB/s 5345280 100.00 silezia/xml zlib 1.2.11 -1 125 MB/s 429 MB/s 965248 18.06 silezia/xml slz_zlib 1.2.0 -1 329 MB/s 331 MB/s 1294302 24.21 silezia/xml done... (cIters=1 dIters=1 cTime=1.0 dTime=2.0 chunkSize=1706MB cSpeed=0MB) [root на localhost lzbench]# на одной и той же степени сжатия 1 скорость сжатия в два раза выше, чем у zlib > > > glib-ng я не тестил, но взял на заметку. > > AFAIK, сейчас существует три вариации "на тему zlib", все пытаются > ускорить работу на современных процесорах: zlib "от Intel", zlib > "от Cloudflare", и вот темерь ещё zlib-ng. > > Было бы интересно посмотреть на какое-нибудь сравнение скорости > между всеми этими вариациями на разных процессорах. > да, было бы неплохо иметь референсную табличку. могу какие-нибудь тесты на имеющемся железе погонять. какие-то сравнительные тесты я гонял, выяснилось, что если взять gcc9 вместо идущего в коробке gcc-4.8, то производительность растет на 10% > > > не рассматривали slz, например ? > > ЕМНИП, мы на него смотрели когда-то давно. В целом идея > интересная, но качество сжатия оставляет желать. > сжатие уровня 1 и на zlib оставляет желать лучшего. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Mar 29 16:20:30 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Mar 2021 19:20:30 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> Message-ID: Hello! On Mon, Mar 29, 2021 at 08:40:04PM +0500, Илья Шипицин wrote: > пн, 29 мар. 2021 г. в 19:55, Maxim Dounin : > > > Hello! > > > > On Mon, Mar 29, 2021 at 06:31:39PM +0500, Илья Шипицин wrote: > > > > > недавно проводил бенчмарки, zlib не самое быстрое > > > https://github.com/inikep/lzbench > > > > > > > > > при том, что на браузерной нагрузке (html + css + js) сжимается всё > > хорошо > > > и из обшей нагрузки gzip занимает процентов 80 от cpu. > > > > Тут важно держать себя в руках и не пытаться крутить уровень > > сжатия. Я неоднократно встречал ситуации, когда люди зачем-то > > ставили "gzip_comp_level 9;", а потом удивлялись потреблению > > процессора. Не говоря уже про регулярно встречающиеся попытки > > поставить 6. Если использовать zlib на уровне сжатия 1, то он > > вполне неплох в части потребления процессора, а если этого мало - > > стоит смотреть в сторону gzip_static и/или кэширования сжатых > > ответов. > > > > > для примера, silesia xml, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz > > [root на localhost lzbench]# ./lzbench -ezlib,1/slz_zlib,1 silezia/xml > lzbench 1.8 (64-bit Linux) Assembled by P.Skibinski > Compressor name Compress. Decompress. Compr. size Ratio Filename > memcpy 10948 MB/s 15766 MB/s 5345280 100.00 silezia/xml > zlib 1.2.11 -1 125 MB/s 429 MB/s 965248 18.06 silezia/xml > slz_zlib 1.2.0 -1 329 MB/s 331 MB/s 1294302 24.21 silezia/xml > done... (cIters=1 dIters=1 cTime=1.0 dTime=2.0 chunkSize=1706MB cSpeed=0MB) > [root на localhost lzbench]# > > на одной и той же степени сжатия 1 скорость сжатия в два раза выше, чем у > zlib [...] > > > не рассматривали slz, например ? > > > > ЕМНИП, мы на него смотрели когда-то давно. В целом идея > > интересная, но качество сжатия оставляет желать. > > > > сжатие уровня 1 и на zlib оставляет желать лучшего. Оставляет, но таки slz производит результат, который на треть больше того, что делает zlib. И при этом по скорости уступает какому-нибудь brotli, который на уровне 0 производит результат, аналогичный zlib'у. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Mar 29 18:49:58 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 29 Mar 2021 23:49:58 +0500 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> Message-ID: пн, 29 мар. 2021 г. в 21:20, Maxim Dounin : > Hello! > > On Mon, Mar 29, 2021 at 08:40:04PM +0500, Илья Шипицин wrote: > > > пн, 29 мар. 2021 г. в 19:55, Maxim Dounin : > > > > > Hello! > > > > > > On Mon, Mar 29, 2021 at 06:31:39PM +0500, Илья Шипицин wrote: > > > > > > > недавно проводил бенчмарки, zlib не самое быстрое > > > > https://github.com/inikep/lzbench > > > > > > > > > > > > при том, что на браузерной нагрузке (html + css + js) сжимается всё > > > хорошо > > > > и из обшей нагрузки gzip занимает процентов 80 от cpu. > > > > > > Тут важно держать себя в руках и не пытаться крутить уровень > > > сжатия. Я неоднократно встречал ситуации, когда люди зачем-то > > > ставили "gzip_comp_level 9;", а потом удивлялись потреблению > > > процессора. Не говоря уже про регулярно встречающиеся попытки > > > поставить 6. Если использовать zlib на уровне сжатия 1, то он > > > вполне неплох в части потребления процессора, а если этого мало - > > > стоит смотреть в сторону gzip_static и/или кэширования сжатых > > > ответов. > > > > > > > > > для примера, silesia xml, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz > > > > [root на localhost lzbench]# ./lzbench -ezlib,1/slz_zlib,1 silezia/xml > > lzbench 1.8 (64-bit Linux) Assembled by P.Skibinski > > Compressor name Compress. Decompress. Compr. size Ratio Filename > > memcpy 10948 MB/s 15766 MB/s 5345280 100.00 > silezia/xml > > zlib 1.2.11 -1 125 MB/s 429 MB/s 965248 18.06 > silezia/xml > > slz_zlib 1.2.0 -1 329 MB/s 331 MB/s 1294302 24.21 > silezia/xml > > done... (cIters=1 dIters=1 cTime=1.0 dTime=2.0 chunkSize=1706MB > cSpeed=0MB) > > [root на localhost lzbench]# > > > > на одной и той же степени сжатия 1 скорость сжатия в два раза выше, чем у > > zlib > > [...] > > > > > не рассматривали slz, например ? > > > > > > ЕМНИП, мы на него смотрели когда-то давно. В целом идея > > > интересная, но качество сжатия оставляет желать. > > > > > > > сжатие уровня 1 и на zlib оставляет желать лучшего. > > Оставляет, но таки slz производит результат, который на треть > больше того, что делает zlib. И при этом по скорости уступает > какому-нибудь brotli, который на уровне 0 производит результат, > аналогичный zlib'у. > на треть меньше сжатие, выигрыш по процессору более чем в два раза. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Mar 29 19:12:20 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 30 Mar 2021 00:12:20 +0500 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> Message-ID: оказывается, zlib-ng уже в процессе https://github.com/inikep/lzbench/pull/100 на этой неделе погоняю бенчмарки пн, 29 мар. 2021 г. в 23:49, Илья Шипицин : > > > пн, 29 мар. 2021 г. в 21:20, Maxim Dounin : > >> Hello! >> >> On Mon, Mar 29, 2021 at 08:40:04PM +0500, Илья Шипицин wrote: >> >> > пн, 29 мар. 2021 г. в 19:55, Maxim Dounin : >> > >> > > Hello! >> > > >> > > On Mon, Mar 29, 2021 at 06:31:39PM +0500, Илья Шипицин wrote: >> > > >> > > > недавно проводил бенчмарки, zlib не самое быстрое >> > > > https://github.com/inikep/lzbench >> > > > >> > > > >> > > > при том, что на браузерной нагрузке (html + css + js) сжимается всё >> > > хорошо >> > > > и из обшей нагрузки gzip занимает процентов 80 от cpu. >> > > >> > > Тут важно держать себя в руках и не пытаться крутить уровень >> > > сжатия. Я неоднократно встречал ситуации, когда люди зачем-то >> > > ставили "gzip_comp_level 9;", а потом удивлялись потреблению >> > > процессора. Не говоря уже про регулярно встречающиеся попытки >> > > поставить 6. Если использовать zlib на уровне сжатия 1, то он >> > > вполне неплох в части потребления процессора, а если этого мало - >> > > стоит смотреть в сторону gzip_static и/или кэширования сжатых >> > > ответов. >> > > >> > >> > >> > для примера, silesia xml, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz >> > >> > [root на localhost lzbench]# ./lzbench -ezlib,1/slz_zlib,1 silezia/xml >> > lzbench 1.8 (64-bit Linux) Assembled by P.Skibinski >> > Compressor name Compress. Decompress. Compr. size Ratio >> Filename >> > memcpy 10948 MB/s 15766 MB/s 5345280 100.00 >> silezia/xml >> > zlib 1.2.11 -1 125 MB/s 429 MB/s 965248 18.06 >> silezia/xml >> > slz_zlib 1.2.0 -1 329 MB/s 331 MB/s 1294302 24.21 >> silezia/xml >> > done... (cIters=1 dIters=1 cTime=1.0 dTime=2.0 chunkSize=1706MB >> cSpeed=0MB) >> > [root на localhost lzbench]# >> > >> > на одной и той же степени сжатия 1 скорость сжатия в два раза выше, чем >> у >> > zlib >> >> [...] >> >> > > > не рассматривали slz, например ? >> > > >> > > ЕМНИП, мы на него смотрели когда-то давно. В целом идея >> > > интересная, но качество сжатия оставляет желать. >> > > >> > >> > сжатие уровня 1 и на zlib оставляет желать лучшего. >> >> Оставляет, но таки slz производит результат, который на треть >> больше того, что делает zlib. И при этом по скорости уступает >> какому-нибудь brotli, который на уровне 0 производит результат, >> аналогичный zlib'у. >> > > на треть меньше сжатие, выигрыш по процессору более чем в два раза. > > > >> >> -- >> Maxim Dounin >> http://mdounin.ru/ >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Mar 30 15:00:45 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 30 Mar 2021 18:00:45 +0300 Subject: nginx-1.19.9 Message-ID: Изменения в nginx 1.19.9 30.03.2021 *) Исправление: nginx не собирался с почтовым прокси-сервером, но без модуля ngx_mail_ssl_module; ошибка появилась в 1.19.8. *) Исправление: при работе с gRPC-бэкендами могли возникать ошибки "upstream sent response body larger than indicated content length"; ошибка появилась в 1.19.1. *) Исправление: если клиент закрывал соединение в момент отбрасывания тела запроса, nginx мог не закрыть соединение до истечения keepalive-таймаута. *) Исправление: при ожидании задержки limit_req или auth_delay, а также при работе с бэкендами nginx мог не обнаружить, что соединение уже закрыто клиентом. *) Исправление: в методе обработки соединений eventport. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Mar 31 17:59:09 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 31 Mar 2021 13:59:09 -0400 Subject: =?UTF-8?B?0KDQsNC30L3Ri9C5INC60L7QvdGC0LXQvdGCINC00LvRjyDQv9C+0LvRjNC30L4=?= =?UTF-8?B?0LLQsNGC0LXQu9C10Lkg0YDQsNC30L3Ri9GFINGB0LXRgtC10Lk=?= Message-ID: Нужно отдавать разный index.html для локальных пользователей и пользователей интернета Делаю так location /local.html { allow 192.168.1.0/24; deny all; internal; } location /global.html { deny 192.168.1.0/24; allow all; internal; } location / { try_files /global.html /local.html =404; } пользователи локальной сети видят global.html да и напрямую если указать урл конкретного документа имеется доступ ( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291116#msg-291116 From igor на sysoev.ru Wed Mar 31 18:11:06 2021 From: igor на sysoev.ru (Igor Sysoev) Date: Wed, 31 Mar 2021 21:11:06 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: References: Message-ID: <6D862C2F-96D4-43AC-ADFB-57B8435F8549@sysoev.ru> geo $geo { default global; 192.168.1.0/24 local; } server { location / { index $geo.html; } location = /global.html { internal; } location = /local.html { internal; } } -- Igor Sysoev > On 31 Mar 2021, at 20:59, budarin wrote: > > Нужно отдавать разный index.html для локальных пользователей и пользователей > интернета > Делаю так > > location /local.html { > allow 192.168.1.0/24; > deny all; > internal; > } > > location /global.html { > deny 192.168.1.0/24; > allow all; > internal; > } > > location / { > try_files /global.html /local.html =404; > } > > пользователи локальной сети видят global.html да и напрямую если указать урл > конкретного документа имеется доступ ( > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291116#msg-291116 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Wed Mar 31 18:30:16 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 31 Mar 2021 14:30:16 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: <6D862C2F-96D4-43AC-ADFB-57B8435F8549@sysoev.ru> References: <6D862C2F-96D4-43AC-ADFB-57B8435F8549@sysoev.ru> Message-ID: <56262ab107e27c8303e3e8496189bbfb.NginxMailingListRussian@forum.nginx.org> Игорь, спасибо за ответ! но к сожалению получаю global в локальной сети на машине где стоит nginx и где тестирую похоже что не срабатывает geo модуль - как можно проверить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291118#msg-291118 From igor на sysoev.ru Wed Mar 31 18:32:05 2021 From: igor на sysoev.ru (Igor Sysoev) Date: Wed, 31 Mar 2021 21:32:05 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: <56262ab107e27c8303e3e8496189bbfb.NginxMailingListRussian@forum.nginx.org> References: <6D862C2F-96D4-43AC-ADFB-57B8435F8549@sysoev.ru> <56262ab107e27c8303e3e8496189bbfb.NginxMailingListRussian@forum.nginx.org> Message-ID: <0EB10436-41ED-44C2-85ED-D76E02D837E3@sysoev.ru> Возможно, кэширование в браузере. Попробуйте curl’ом. -- Igor Sysoev > On 31 Mar 2021, at 21:30, budarin wrote: > > Игорь, спасибо за ответ! > > но к сожалению получаю global в локальной сети на машине где стоит nginx и > где тестирую > похоже что не срабатывает geo модуль - как можно проверить? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291118#msg-291118 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx на kinetiksoft.com Wed Mar 31 18:36:00 2021 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Wed, 31 Mar 2021 21:36:00 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: <56262ab107e27c8303e3e8496189bbfb.NginxMailingListRussian@forum.nginx.org> References: <6D862C2F-96D4-43AC-ADFB-57B8435F8549@sysoev.ru> <56262ab107e27c8303e3e8496189bbfb.NginxMailingListRussian@forum.nginx.org> Message-ID: <0f70dbdc-bb0d-2b56-33e6-70557b85261f@kinetiksoft.com> Здравствуйте! Попробуйте geo  $geo  {      default          global;      192.168.1.0/24   local; } server {     location / {         return 200 $geo;     #return 200 $remote_addr;     }  } и, дёрнуть curl'ом. Увидите что у вас в geo. А, если заменить на закомментированную строчку, то IP адрес, с которого обращаетесь, чтоб убедиться, что ничего не путаете. С уважением, Иван. 31.03.2021 21:30, budarin пишет: > Игорь, спасибо за ответ! > > но к сожалению получаю global в локальной сети на машине где стоит nginx и > где тестирую > похоже что не срабатывает geo модуль - как можно проверить? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291118#msg-291118 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Wed Mar 31 18:53:21 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 31 Mar 2021 14:53:21 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: <0f70dbdc-bb0d-2b56-33e6-70557b85261f@kinetiksoft.com> References: <0f70dbdc-bb0d-2b56-33e6-70557b85261f@kinetiksoft.com> Message-ID: Понял в чем проблема (благодаря return 200 $remote_addr) - у меня nginx и сервисы в докере а там своя подсеть10.0.0.0/24 насколько я понимаю все запросы там будут из этой подсети получается я не смогу различить локальная это сеть или интернет- пользователь? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291121#msg-291121 From nginx на kinetiksoft.com Wed Mar 31 19:00:44 2021 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Wed, 31 Mar 2021 22:00:44 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: References: <0f70dbdc-bb0d-2b56-33e6-70557b85261f@kinetiksoft.com> Message-ID: Здравствуйте! Запускайте контейнер с nginx c network driver (параметр докера) - host, nginx будет слушать порт непосредственно на хосте, и будет знать реальный IP клиента. Либо запустите отдельный nginx на хосте, который будет ставить заголовок X-Forwarded-For и проксировать запросы к nginx в докер, на котором в свою очередь включите директиву proxy в geo. В принципе проксирующий nginx может быть не обязательно на том же хосте, где докер-контейнер, а где угодно в сети. С уважением, Иван. 31.03.2021 21:53, budarin пишет: > Понял в чем проблема (благодаря return 200 $remote_addr) - у меня nginx и > сервисы в докере а там своя подсеть10.0.0.0/24 > > насколько я понимаю все запросы там будут из этой подсети > получается я не смогу различить локальная это сеть или интернет- > пользователь? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291121#msg-291121 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From alex.hha на gmail.com Wed Mar 31 19:01:45 2021 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 31 Mar 2021 22:01:45 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: References: <0f70dbdc-bb0d-2b56-33e6-70557b85261f@kinetiksoft.com> Message-ID: если запустить docker с network_mode: host, то сможете различать On Wed, Mar 31, 2021 at 9:53 PM budarin wrote: > Понял в чем проблема (благодаря return 200 $remote_addr) - у меня nginx и > сервисы в докере а там своя подсеть10.0.0.0/24 > > насколько я понимаю все запросы там будут из этой подсети > получается я не смогу различить локальная это сеть или интернет- > пользователь? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291116,291121#msg-291121 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Mar 31 19:30:43 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 31 Mar 2021 15:30:43 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQuSDQutC+0L3RgtC10L3RgiDQtNC70Y8g0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtC10LvQtdC5INGA0LDQt9C90YvRhSDRgdC10YLQtdC5?= In-Reply-To: References: Message-ID: <3b71187a130e86c75ba5adbc3d1ace12.NginxMailingListRussian@forum.nginx.org> спасибо, получилось! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291116,291124#msg-291124 From izorkin на gmail.com Wed Mar 31 20:18:16 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 31 Mar 2021 23:18:16 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0LggemxpYi1uZw==?= In-Reply-To: References: <1786ca22a6e.dea7d9441099487.8984595071426552062@dl.sm.ua> <6e9699c4-acf4-62ca-0837-a94052e53b81@megaline.kg> <06D2F14C-EC83-4F68-90BF-233C36E6D4FF@nginx.com> <03f8371d-280f-2c7a-ca1b-a3e31d17b6d3@megaline.kg> Message-ID: <423129039.20210331231816@gmail.com> Здравствуйте, Maxim. Если в сборке zlib-ng отключить совместимость с zlib, то nginx не видит zlib-ng и собирается с zlib 1.2.11. Или эти патчи работают только в режиме совместимости с zlib? Вы писали 29 марта 2021 г., 16:19:47: > Hello! > On Mon, Mar 29, 2021 at 01:00:21PM +0600, raven_kg на megaline.kg wrote: > [...] >> Будут-ли эти правки включены в какой-либо из релизов? > Да, как только пройдут review. -- С уважением, Izorkin mailto:izorkin на gmail.com From nginx-forum на forum.nginx.org Wed Mar 31 21:09:45 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 31 Mar 2021 17:09:45 -0400 Subject: =?UTF-8?B?0J3QtSDRg9C00LDQtdGC0YHRjyDQv9C+0LTQvNC10L3QuNGC0Ywg0L7RiNC40LE=?= =?UTF-8?B?0LrQuCDRgdCy0L7QuNC80Lgg0YHRgtGA0LDQvdC40YbQsNC80Lg=?= Message-ID: <885638feaa433b22bca431c55559b3c3.NginxMailingListRussian@forum.nginx.org> В папке /var/www лежат файлы 404.html 502.html 503.html 500.html остальные ресурсы лежат в папке /var/www/web работающий конфиг: http { upstream web_app { least_conn; server 10.0.1.43:3000; } server { listen 443; listen 443 ssl; server_name localhost; root /var/www/web; error_page 404 /404.html; error_page 502 504 /502.html; error_page 503 /503.html; error_page 500 501 504 /500.html; location ~ [4-5][0-9][0-9].html { internal; root /var/www; include /etc/nginx/config/disable/access_logs.conf; } location / { proxy_pass http://web_app; } location ~* \.(?:html|css|js)$ { etag on; sendfile on; tcp_nopush on; tcp_nodelay on; add_header Cache-Control "public"; } } удаляю из конфига описание upstream и жду что вместо стандартного ответа на клиенте я получу кастомную страницу, но получаю стандартный ответ 404 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291126,291126#msg-291126