From mdounin на mdounin.ru Sun Jul 1 14:20:07 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 1 Jul 2018 17:20:07 +0300 Subject: image_filter size In-Reply-To: References: <7578267.n7h3G5SPec@vbart-workstation> Message-ID: <20180701142007.GO35731@mdounin.ru> Hello! On Wed, Jun 27, 2018 at 10:03:51AM -0400, imsystem wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Wednesday 27 June 2018 09:36:21 imsystem wrote: > > [..] > > > image_filter size; > > > image_filter resize $1 $2; > > [..] > > > > Нужно определиться, либо одно действие, либо другое. > > > > В данном случае работает последяя встреченная в location > > директива image_filter. > > Спасибо, работает. > Получается одновременно ресайзить и получать ответ я не могу. Это нужно делать в разных location'ах. И, соответствено, по одному URI получать размер картинки, а по другому - саму картинку в нужном размере. -- Maxim Dounin http://mdounin.ru/ From nginx на kinetiksoft.com Sun Jul 1 16:18:38 2018 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Sun, 1 Jul 2018 19:18:38 +0300 Subject: =?UTF-8?B?dW5pdDog0LHRg9C00LXRgiDQu9C4INC/0L7QtNC00LXRgNC20LrQsCDQt9Cw0LQ=?= =?UTF-8?B?0LDQvdC40Y8g0L/QtdGA0LXQvNC10L3QvdGL0YUgX1NFUlZFUiA/?= Message-ID: <4060d191-2131-16b3-d339-bf2857830525@kinetiksoft.com> Здравствуйте! Сегодня попробовал unit в продакшене. Немного отзывов, вопросы через абзац. Переключил на него matomo(piwik), который обслуживает сайт с 300000 посетителей ежедневно. В php-fpm мне давно не нравилось, как он использует память в static режиме (он её, собственно, сжирает как не в себя. последняя php  ветки 7.0). Так вот unit оказался прекрасным продуктом с точки зрения производительности. Потребление памяти теперь фискированное и упало в разы. Завтра буду пробовать переводить ядро самого сайта. Вопрос:ы В nginx при работе с php-fpm по fastcgi, можно было подделать любой заголовок, чаще всего это делалось с https. Сегодня мне очень не хватало GEOIP_* заголовков. Если заголовки проксировать, то на бэкэнд они приезжают с префиксом HTTP_, и бэкэнд их не видит. Планируется ли как-то решить этот вопрос? Переменные окружения - это не то, это другой массив. Планируется ли поддержка юникс-сокетов в listener'ах? Статистика? Хотя бы аналогичная nginx_stats. Ну и вы, наверное, в курсе, но у вас документация отстаёт от действительности. Не описаны нововведения из unit 1.2. В остальном - спасибо за прекрасный продукт! С уважением, Иван. From vbart на nginx.com Sun Jul 1 22:25:27 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 02 Jul 2018 01:25:27 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6INCx0YPQtNC10YIg0LvQuCDQv9C+0LTQtNC10YDQttC60LAg0Lc=?= =?UTF-8?B?0LDQtNCw0L3QuNGPINC/0LXRgNC10LzQtdC90L3Ri9GFIF9TRVJWRVIgPw==?= In-Reply-To: <4060d191-2131-16b3-d339-bf2857830525@kinetiksoft.com> References: <4060d191-2131-16b3-d339-bf2857830525@kinetiksoft.com> Message-ID: <2233102.QtTl1W1WfC@vbart-laptop> On Sunday, 1 July 2018 19:18:38 MSK Иван wrote: [..] > В nginx при работе с php-fpm по fastcgi, можно было подделать любой > заголовок, чаще всего это делалось с https. Сегодня мне очень не хватало > GEOIP_* заголовков. Если заголовки проксировать, то на бэкэнд они > приезжают с префиксом HTTP_, и бэкэнд их не видит. Планируется ли как-то > решить этот вопрос? Переменные окружения - это не то, это другой массив. Да, проблема понятна. Возможность настраивать переменные запроса планируется. > > Планируется ли поддержка юникс-сокетов в listener'ах? Они поддерживаются. Достаточно вместо адреса и порта указать путь к сокету с префиксом unix: "unix:/path/to/unix.sock". Смотрите пример конфигурации тут: https://github.com/nginx/unit/issues/61 Впрочем, с ними есть сейчас несколько известных проблем. В частности, к такому объекту внутри listeners пока нельзя обратиться по URI. > > Статистика? Хотя бы аналогичная nginx_stats. > Сбор метрик появится в будущем. > Ну и вы, наверное, в курсе, но у вас документация отстаёт от > действительности. Не описаны нововведения из unit 1.2. > И чтобы основательно решить проблему с качеством и полнотой документации открыта вакансия технического писателя: https://www.nginx.com/careers/current-openings/?job_id=1187667 На данный момент, информацию по большинству возможностей, появившихся в последних версиях, можно почерпнуть из блога: https://www.nginx.com/blog/nginx-unit-1-2-release-available-now/ https://www.nginx.com/blog/unit-0-6-beta-release-available-now/ https://www.nginx.com/blog/unit-0-3-beta-release-available-now/ > > В остальном - спасибо за прекрасный продукт! > Спасибо за хороший отзыв, нам ещё много предстоит сделать. -- Валентин Бартенев From nginx-forum на forum.nginx.org Mon Jul 2 06:31:06 2018 From: nginx-forum на forum.nginx.org (yanda.a) Date: Mon, 02 Jul 2018 02:31:06 -0400 Subject: =?UTF-8?B?UmU6IFJlWzRdOiDQl9Cw0L/Rg9GB0LogcGhwINGB0LrRgNC40L/RgtC+0LIg0Lg=?= =?UTF-8?B?0Lcg0YDQsNC30L3Ri9GFINC00LjRgNC10LrRgtC+0YDQuNC4?= In-Reply-To: <6d65f3d89cb9350ee35fa1aba872d6c9.NginxMailingListRussian@forum.nginx.org> References: <6ae52a4a0830b3d0b071e127c2724e2b.NginxMailingListRussian@forum.nginx.org> <7aef51268afdea43166482fa185be705.NginxMailingListRussian@forum.nginx.org> <6d65f3d89cb9350ee35fa1aba872d6c9.NginxMailingListRussian@forum.nginx.org> Message-ID: <87e5ed2faa0e7aa3015f3e4599e17994.NginxMailingListRussian@forum.nginx.org> Конечно не получится. Еще раз повторюсь, nginx не имеет никакого отношения к PHP и ни коим образом не разграничивает права доступа к файлам. al3x Wrote: ------------------------------------------------------- > index.php: > echo file_get_contents('template/news.html'); > ?> > > То есть что-то типа такого не получится для моей задачи:? > > root /home/user; > > location / { > try_files $uri $uri/ @fallback; > } > > location @fallback { > root /home/admin; > try_files $uri $uri/ /index.php?$query_string; > } > > yanda.a Wrote: > ------------------------------------------------------- > > Так это же задача PHP, а не Nginx. Nginx должен проксировать > запросы > > на бекенд, балансировать нагрузку на бекенды, возможно менять uri > > запроса и отдавать статику. Но иметь какое-либо отношение к PHP он > не > > должен! > > > > Хотя, что имеется в виду под "Далее /home/admin/index.php выполняет > > свою работу и хочет обработать файл template/news.html."? > > > > al3x Wrote: > > ------------------------------------------------------- > > > Я уже начинаю думать, что у меня какая-то бредовая идея... еще > > немного > > > и я откажусь от нее =) > > > Не знаю как еще объяснить, но попробую... > > > > > > Есть файлы CMS: > > > /home/admin/index.php > > > /home/admin/modules/module.php > > > /home/admin/template/news.html > > > /home/admin/template/style.css > > > > > > Директория юзера: > > > /home/user/ - у юзера есть доступ только к этой директории. > > > > > > При обращении по IP сервера nginx сначала смотрит в /home/user/ и > > если > > > не находит там index.php, то смотрит в /home/admin/index.php и > > отдает > > > его. > > > > > > Далее /home/admin/index.php выполняет свою работу и хочет > > обработать > > > файл template/news.html. Nginx должен проверить, нет ли этого > файла > > в > > > директории юзера /home/user/template/news.html и если есть, то > > отдать > > > его. Если этого файла нет, то отдать из папки > > > /home/admin/template/news.html > > > > > > Затем юзер захотел создать свой личный модуль и положил его в > папку > > > /home/user/modules/new_module.php > > > и когда /home/admin/index.php загружает модули из папки /modules/ > > то > > > nginx должен сначала проверить все файлы в директории юзера > > > /home/user/modules/, а затем здесь /home/admin/modules/ и таким > > > образом подгрузить для PHP все модули из двух директорий, словно > из > > > одной. > > > > > > Т.е. директории должны быть как бы зеркалами друг друга. > > > > > > Это возможно сделать? > > > > > > Dmitriy Lyalyuev Wrote: > > > ------------------------------------------------------- > > > > Может я чего не понимаю, но может стоит сделать локейшн типа > > > > /user_content > > > > и рут выставить ​в хомяк юзера? > > > > Туда же и ФТП пусть смотрит с ограничением юзера в этом > каталоге. > > > > А все остальное юзеру не будет доступно от слова совсем. > > > > > > > > Задача простая как 3 копейки и слабо имеет отношение к Nginx. > > > > Или я чего-то не понимаю? > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru на nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280329,280362#msg-280362 From nginx на kinetiksoft.com Mon Jul 2 22:37:06 2018 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Tue, 3 Jul 2018 01:37:06 +0300 Subject: =?UTF-8?B?dW5pdDogNDAwINC+0YjQuNCx0LrQsCDQv9GA0Lgg0LfQsNCz0L7Qu9C+0LLQutCw?= =?UTF-8?B?0YUsINGB0L7QtNC10YDQttCw0YnQuNGFINGO0L3QuNC60L7QtA==?= Message-ID: Здравствуйте! Только я научил бэкэнд получать геоданные из HTTP_* заголовков, так столкнулся со следующей проблемой. Если в заголовке содержаться какие-то юникодные символы, например, кириллица *или *'ü' , то unit возвращает 400 ошибку. Это баг unit или заголовки по стандарту не умеют юникод? Если баг, готов его оформить на гитхабе. Если не баг и так задумано, то я совсем не понимаю как передавать geoip данные от nginx (использую geoip2 модуль) к бэкэнду за unit. Если у меня клиент из немецкого Baden-Württemberg Region или французского Île-de-France, unit на каждый запрос вернет ему 400. С уважением, Иван. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Tue Jul 3 01:09:49 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 03 Jul 2018 04:09:49 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0LvQvtCy?= =?UTF-8?B?0LrQsNGFLCDRgdC+0LTQtdGA0LbQsNGJ0LjRhSDRjtC90LjQutC+0LQ=?= In-Reply-To: References: Message-ID: <90036204.JihCADgUBL@vbart-laptop> On Tuesday, 3 July 2018 01:37:06 MSK Иван wrote: > Здравствуйте! > > Только я научил бэкэнд получать геоданные из HTTP_* заголовков, так > столкнулся со следующей проблемой. > > Если в заголовке содержаться какие-то юникодные символы, например, > кириллица *или *'ü' , то unit возвращает 400 ошибку. > > Это баг unit или заголовки по стандарту не умеют юникод? > > Если баг, готов его оформить на гитхабе. > > Если не баг и так задумано, то я совсем не понимаю как передавать geoip > данные от nginx (использую geoip2 модуль) к бэкэнду за unit. Если у меня > клиент из немецкого Baden-Württemberg Region или французского > Île-de-France, unit на каждый запрос вернет ему 400. > Действительно, сейчас Unit разрешает только 0x20-0x7E в значениях заголовков. Пожалуй стоит смягчить ограничение до 0x20-0xFF. -- Валентин Бартенев From vbart на nginx.com Tue Jul 3 13:05:22 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 03 Jul 2018 16:05:22 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0LvQvtCy?= =?UTF-8?B?0LrQsNGFLCDRgdC+0LTQtdGA0LbQsNGJ0LjRhSDRjtC90LjQutC+0LQ=?= In-Reply-To: <90036204.JihCADgUBL@vbart-laptop> References: <90036204.JihCADgUBL@vbart-laptop> Message-ID: <1926370.JLfsRog4WB@vbart-workstation> On Tuesday 03 July 2018 04:09:49 Валентин Бартенев wrote: > On Tuesday, 3 July 2018 01:37:06 MSK Иван wrote: > > Здравствуйте! > > > > Только я научил бэкэнд получать геоданные из HTTP_* заголовков, так > > столкнулся со следующей проблемой. > > > > Если в заголовке содержаться какие-то юникодные символы, например, > > кириллица *или *'ü' , то unit возвращает 400 ошибку. > > > > Это баг unit или заголовки по стандарту не умеют юникод? > > > > Если баг, готов его оформить на гитхабе. > > > > Если не баг и так задумано, то я совсем не понимаю как передавать geoip > > данные от nginx (использую geoip2 модуль) к бэкэнду за unit. Если у меня > > клиент из немецкого Baden-Württemberg Region или французского > > Île-de-France, unit на каждый запрос вернет ему 400. > > > > Действительно, сейчас Unit разрешает только 0x20-0x7E в значениях заголовков. > Пожалуй стоит смягчить ограничение до 0x20-0xFF. > Сделано: http://hg.nginx.org/unit/rev/95538a9d4050 -- Валентин Бартенев From mdounin на mdounin.ru Tue Jul 3 15:37:34 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 3 Jul 2018 18:37:34 +0300 Subject: nginx-1.15.1 Message-ID: <20180703153734.GI56558@mdounin.ru> Изменения в nginx 1.15.1 03.07.2018 *) Добавление: директива random в блоке upstream. *) Добавление: улучшена производительность при использовании директив hash и ip_hash совместно с директивой zone. *) Добавление: параметр reuseport директивы listen теперь использует SO_REUSEPORT_LB на FreeBSD 12. *) Исправление: HTTP/2 server push не работал, если SSL терминировался прокси-сервером перед nginx'ом. *) Исправление: директива tcp_nopush всегда использовалась для соединений к бэкендам. *) Исправление: при отправке сохранённого на диск тела запроса на gRPC-бэкенд могли возникать ошибки. -- Maxim Dounin http://nginx.org/ From nginx на mva.name Thu Jul 5 12:28:48 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 05 Jul 2018 15:28:48 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0LvQvtCy?= =?UTF-8?B?0LrQsNGFLCDRgdC+0LTQtdGA0LbQsNGJ0LjRhSDRjtC90LjQutC+0LQ=?= In-Reply-To: <1926370.JLfsRog4WB@vbart-workstation> References: <90036204.JihCADgUBL@vbart-laptop> <1926370.JLfsRog4WB@vbart-workstation> Message-ID: <4489136.Yjl4KqOE1K@tp> А почему бы не разрешить юникод? Ну и, справедливости ради, я был бы не против если бы поддержка (отсутствие запрета, точнее) юникода была не только в *значениях* заголовков, но и в самих именах. Не то, чтобы я это активно испольновал, но не вижу явных причин для запрета... From vbart на nginx.com Thu Jul 5 14:11:57 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 05 Jul 2018 17:11:57 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0LvQvtCy?= =?UTF-8?B?0LrQsNGFLCDRgdC+0LTQtdGA0LbQsNGJ0LjRhSDRjtC90LjQutC+0LQ=?= In-Reply-To: <4489136.Yjl4KqOE1K@tp> References: <1926370.JLfsRog4WB@vbart-workstation> <4489136.Yjl4KqOE1K@tp> Message-ID: <2886357.QEqd3zEzdT@vbart-workstation> On Thursday 05 July 2018 15:28:48 Vadim A. Misbakh-Soloviov wrote: > А почему бы не разрешить юникод? > Ну и, справедливости ради, я был бы не против если бы поддержка (отсутствие > запрета, точнее) юникода была не только в *значениях* заголовков, но и в самих > именах. > > Не то, чтобы я это активно испольновал, но не вижу явных причин для запрета... Всё это потом попадает в интерпретаторы языков программирования и в сами программы, разработчики которых очень часто не предполагают, что в заголовке может прилететь что-то подобное. Как результат потом имеем разные занятные уязвимости в самых неожиданных местах. -- Валентин Бартенев From chipitsine на gmail.com Thu Jul 5 14:29:37 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 5 Jul 2018 19:29:37 +0500 Subject: =?UTF-8?B?Indvcmtlcl9jb25uZWN0aW9ucyBhcmUgbm90IGVub3VnaCIgLSDQvtCx0YHRg9C0?= =?UTF-8?B?0LjQvCA/?= Message-ID: привет! налетели на ситуацию. сценарий, как воспроизвести на стенде 1. centos 7, nginx-1.15.1 из официального репозитория 2. конфиг # cat /etc/nginx/nginx.conf user root; worker_processes auto; events { worker_connections 512; } stream { include /etc/nginx/conf.d/*.conf; } т.е. видим (дефолтное ограничение в "worker_connections 512;") далее при помощи вот такого генератора # cat generator.sh #!/bin/bash i=2000 while [ $i -le 2700 ] do ((i++)) cat <> /etc/nginx/conf.d/stream.conf server { listen 127.0.0.1:${i}; proxy_pass 127.0.0.2:${i}; } EOF done генерируем 700 стримов. проверяем, nginx говорит, что ему конфиг ок # nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful # перезапускаем, все тоже ок # systemctl restart nginx # но в процессах только мастер, воркера нет. смотрим лог: # cat /var/log/nginx/error.log | tail -2 2018/07/05 14:27:53 [alert] 1546#1546: 512 worker_connections are not enough 2018/07/05 14:27:53 [alert] 1545#1545: worker process 1546 exited with fatal code 2 and cannot be respawned # кажется, что было бы логично отсекать такие ошибки во время "nginx -t" что думаете ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vp7 на mail.ru Thu Jul 5 14:30:58 2018 From: vp7 на mail.ru (=?UTF-8?B?Vml0YWx5IFBvbm9tYXJldg==?=) Date: Thu, 05 Jul 2018 17:30:58 +0300 Subject: =?UTF-8?B?UmVbMl06IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0Ls=?= =?UTF-8?B?0L7QstC60LDRhSwg0YHQvtC00LXRgNC20LDRidC40YUg0Y7QvdC40LrQvtC0?= In-Reply-To: <2886357.QEqd3zEzdT@vbart-workstation> References: <4489136.Yjl4KqOE1K@tp> <2886357.QEqd3zEzdT@vbart-workstation> Message-ID: <1530801058.14576632@f486.i.mail.ru> А если добавить специальный ключик для этих целей? Кому надо - осознанно разрешат. == # Разрешить использовать переменные со значениями в unicode hdr_unicode_values yes|no; default no # Разрешить использовать переменные с именами в unicode hdr_unicode_keys yes|no; default no >Четверг, 5 июля 2018, 17:12 +03:00 от Валентин Бартенев : > >On Thursday 05 July 2018 15:28:48 Vadim A. Misbakh-Soloviov wrote: >> А почему бы не разрешить юникод? >> Ну и, справедливости ради, я был бы не против если бы поддержка (отсутствие >> запрета, точнее) юникода была не только в *значениях* заголовков, но и в самих >> именах. >> >> Не то, чтобы я это активно испольновал, но не вижу явных причин для запрета... > >Всё это потом попадает в интерпретаторы языков программирования и в сами >программы, разработчики которых очень часто не предполагают, что в заголовке >может прилететь что-то подобное. Как результат потом имеем разные занятные >уязвимости в самых неожиданных местах. > >-- >Валентин Бартенев >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru --- С уважением, Виталий ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Jul 5 14:38:54 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 5 Jul 2018 19:38:54 +0500 Subject: =?UTF-8?B?UmU6IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0LvQvtCy?= =?UTF-8?B?0LrQsNGFLCDRgdC+0LTQtdGA0LbQsNGJ0LjRhSDRjtC90LjQutC+0LQ=?= In-Reply-To: <2886357.QEqd3zEzdT@vbart-workstation> References: <1926370.JLfsRog4WB@vbart-workstation> <4489136.Yjl4KqOE1K@tp> <2886357.QEqd3zEzdT@vbart-workstation> Message-ID: чт, 5 июл. 2018 г. в 19:12, Валентин Бартенев : > On Thursday 05 July 2018 15:28:48 Vadim A. Misbakh-Soloviov wrote: > > А почему бы не разрешить юникод? > > Ну и, справедливости ради, я был бы не против если бы поддержка > (отсутствие > > запрета, точнее) юникода была не только в *значениях* заголовков, но и в > самих > > именах. > > > > Не то, чтобы я это активно испольновал, но не вижу явных причин для > запрета... > > Всё это потом попадает в интерпретаторы языков программирования и в сами > программы, разработчики которых очень часто не предполагают, что в > заголовке > может прилететь что-то подобное. Как результат потом имеем разные занятные > уязвимости в самых неожиданных местах. > мы в режиме реального времени наблюдаем, как браузер MSIE (разработки компании Microsoft) упорно пихает юникод в заголовки, а веб-сервер Kestrel (тоже разработки компании Microsoft) на это говорит "ая-а-я-яй, не по RFC, вот тебе 400, держи" не всегда разработчики браузеров и вебсерверов одинаково читают RFC > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Jul 5 14:45:35 2018 From: nginx-forum на forum.nginx.org (YuriN) Date: Thu, 05 Jul 2018 10:45:35 -0400 Subject: =?UTF-8?B?0J/QvtGH0LXQvNGDINGB0YLQsNGC0LjRh9C10YHQutC40LUg0YTQsNC50LvRiyAo?= =?UTF-8?B?MjDQmtCxKSDQsiDQu9C+0LrQsNC70YzQvdC+0Lkg0YHQtdGC0LgoMUdiaXQv?= =?UTF-8?B?cykg0L7RgtC00LDRjtGC0YHRjyAxLDUg0YHQtdC60YPQvdC00Ys/?= Message-ID: Добрый день! Имеем очень медленную отдачу закэшированной статики. Посоветуйте пожалуйста как можно ускорить работу. Статика, скажем, размером 20kb отдаётся порядка 1-1.5 секунды. При чём TTFB относительно быстрый - 200-300 ms, а доставка от nginx до браузера уже 1-1.5 секунды. По логам видно, что эта статика берётся из кэша всё-таки ($upstream_response_time = 0). Условия проверки: обращение к титульной странице нашего сайта - это 80 запросов, 2.7Mb трафика суммарно, по https, http2. Конфиг вроде бы стандартный, без особого тюнинга (приложен) Если скачивать один только статический файл (1 запрос) - то он скачивается без этих задержек - 27 ms. Топология: nginx-сервер в нашей конфигурации является проскирующим и кэширующим сервером: кэширует статику с сервера приложений, к-ый расположен в этой же локальной сети. Ошибок на сетевых интерфейсах клиента и сервера нет. Каналы не перегружены. (Пропускная способность 1Гбит/с), И в момент обращения к nginx - загрузка максимум 5Mbit/s). В лимиты ЦПУ/память/ дисковый I/O /сеть не упираемся судя по vmstat, top, atop, zabbix. Хотя очевидно есть какое-то ограничение, про к-ое мне пока неизвестно. 8 ядер, 8Gb RAM, Load average 0.00, 0.00, 0.00 В error логах пусто, строки о nginx: [warn] the "ssl" directive is deprecated, use the "listen ... ssl" directive instead in /etc/nginx/conf.d/ не считаю важными. Также я пробовал размещать proxy_cache_path на tmpfs (в ОЗУ) - не дало никакого прироста. nginx последний stable, из оффициального репозитория nginx.org Я проверял в разных сетях (с разным коммутационным оборудованием), на разных физических серверах, на разных дистрибутивах Linux. _____________________________________________________________ Версии ПО и конфиги : root на proxy4:~# uname -a Linux proxy4 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux nginx 1.14.0-0ubuntu1 дефолтовые настройки sysctl root на proxy4:~# lsb_release -a Description: Ubuntu 18.04 LTS root на proxy4:~# nginx -V nginx version: nginx/1.14.0 built by gcc 7.3.0 (Ubuntu 7.3.0-16ubuntu3) built with OpenSSL 1.1.0g 2 Nov 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.14.0/debian/debuild-base/nginx-1.14.0=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' /etc/nginx/nginx.conf user www-data; worker_processes 8; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 4000; } worker_rlimit_nofile 200000; http { client_max_body_size 10m; charset utf-8; proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:512m; include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" $upstream_response_time'; access_log /var/log/nginx/access.log main buffer=16k; server_tokens off; client_body_buffer_size 128k; keepalive_requests 1000; sendfile on; sendfile_max_chunk 512k; proxy_buffering on; open_file_cache max=200000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; keepalive_timeout 65; include /etc/nginx/conf.d/*.conf; } /etc/nginx/conf.d/beta.domain.ru.conf proxy_cache_path /tmp/nginx_CACHE_ZONE keys_zone=CACHE:2048M; proxy_temp_path /tmp/nginx_temp; upstream backend { server 195.209.xx:80; } upstream backend_old { server 195.209.xx:8098; } server { listen 443 ssl http2; server_name www.domain.ru; access_log /var/log/nginx/www.domain.ru.access.log main buffer=16k; error_log /var/log/nginx/www.domain.ru.error.log; client_max_body_size 20m; keepalive_timeout 60; gzip on; gzip_proxied any; gzip_types *; gzip_vary on; ssl on; ssl_certificate /etc/dehydrated/certs/domain.ru/fullchain.pem; ssl_certificate_key /etc/dehydrated/certs/domain.ru/privkey.pem; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; ssl_prefer_server_ciphers on; ssl_dhparam /etc/nginx/ssl/crt/dhparam.pem; charset utf-8; proxy_send_timeout 300; proxy_read_timeout 300; location = / { proxy_cache_valid 200 301 302 304 5m; proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; proxy_hide_header "Set-Cookie"; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504; proxy_cache CACHE; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://backend; } location ~* ^(/static/|/buildpack/|/assets/|/devadm/|/desktop/|/bitrix/|/jsframework/|/templates/|/upload/|/tmp/).+\.(jpg|jpeg|gif|png|ico|css|css.*|js|js.*|swf|txt|ico|svg|woff2)$ { expires 1h; add_header Cache-Control public; proxy_hide_header "Set-Cookie"; proxy_pass http://backend; proxy_cache CACHE; proxy_cache_valid 1h; } location / { proxy_set_header Accept-Encoding ""; sub_filter 'http://' 'https://'; sub_filter_once off; proxy_redirect off; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://backend_old; } } root на proxy4:~# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 7716604 25012 264788 0 0 4 2 54 36 0 0 100 0 0 0 0 0 7716632 25012 264788 0 0 0 0 418 286 0 0 100 0 0 0 0 0 7716664 25020 264784 0 0 0 28 408 285 0 0 100 0 0 0 0 0 7716728 25020 264788 0 0 0 0 434 300 0 0 100 0 0 0 0 0 7716600 25020 264788 0 0 0 0 411 290 0 0 100 0 0 0 0 0 7716604 25020 264804 0 0 0 28 615 305 1 0 99 0 0 0 0 0 7716604 25020 264804 0 0 0 0 582 283 0 0 99 0 0 0 0 0 7716508 25020 264804 0 0 0 0 396 256 0 0 100 0 0 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280414,280414#msg-280414 From vp7 на mail.ru Thu Jul 5 14:56:56 2018 From: vp7 на mail.ru (=?UTF-8?B?Vml0YWx5IFBvbm9tYXJldg==?=) Date: Thu, 05 Jul 2018 17:56:56 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDRgdGC0LDRgtC40YfQtdGB0LrQuNC1INGE0LDQudC7?= =?UTF-8?B?0YsgKDIw0JrQsSkg0LIg0LvQvtC60LDQu9GM0L3QvtC5INGB0LXRgtC4KDFH?= =?UTF-8?B?Yml0L3MpINC+0YLQtNCw0Y7RgtGB0Y8gMSw1INGB0LXQutGD0L3QtNGLPw==?= In-Reply-To: References: Message-ID: <1530802616.902583092@f426.i.mail.ru> Добрый день. > Статика, скажем, размером 20kb отдаётся порядка 1-1.5 секунды. Самый первый вопрос - определить, кто тупит. Либо тупит сервер и тогда вопрос к nginx, либо клиент и тогда вопрос не сюда. Соберите tcp трейс на стороне сервера и посмотрите сколько времени реально уходит у nginx'а и нет ли tcp retry в сторону клиента. >Четверг, 5 июля 2018, 17:45 +03:00 от YuriN : > >Добрый день! > >Имеем очень медленную отдачу закэшированной статики. Посоветуйте пожалуйста >как можно ускорить работу. > >Статика, скажем, размером 20kb отдаётся порядка 1-1.5 секунды. При чём TTFB >относительно быстрый - 200-300 ms, а доставка от nginx до браузера уже 1-1.5 >секунды. По логам видно, что эта статика берётся из кэша всё-таки >($upstream_response_time = 0). >Условия проверки: обращение к титульной странице нашего сайта - это 80 >запросов, 2.7Mb трафика суммарно, по https, http2. >Конфиг вроде бы стандартный, без особого тюнинга (приложен) >Если скачивать один только статический файл (1 запрос) - то он скачивается >без этих задержек - 27 ms. > >Топология: >nginx-сервер в нашей конфигурации является проскирующим и кэширующим >сервером: >кэширует статику с сервера приложений, к-ый расположен в этой же локальной >сети. > >Ошибок на сетевых интерфейсах клиента и сервера нет. Каналы не перегружены. >(Пропускная способность 1Гбит/с), И в момент обращения к nginx - загрузка >максимум 5Mbit/s). В лимиты ЦПУ/память/ дисковый I/O /сеть не упираемся >судя по vmstat, top, atop, zabbix. Хотя очевидно есть какое-то ограничение, >про к-ое мне пока неизвестно. >8 ядер, 8Gb RAM, Load average 0.00, 0.00, 0.00 > >В error логах пусто, строки о nginx: [warn] the "ssl" directive is >deprecated, use the "listen ... ssl" directive instead in /etc/nginx/conf.d/ >не считаю важными. > >Также я пробовал размещать proxy_cache_path на tmpfs (в ОЗУ) - не дало >никакого прироста. > >nginx последний stable, из оффициального репозитория nginx.org > >Я проверял в разных сетях (с разным коммутационным оборудованием), на разных >физических серверах, на разных дистрибутивах Linux. > > >_____________________________________________________________ > >Версии ПО и конфиги : >root на proxy4:~# uname -a >Linux proxy4 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 >x86_64 x86_64 x86_64 GNU/Linux >nginx 1.14.0-0ubuntu1 >дефолтовые настройки sysctl >root на proxy4:~# lsb_release -a >Description: Ubuntu 18.04 LTS >root на proxy4:~# nginx -V >nginx version: nginx/1.14.0 >built by gcc 7.3.0 (Ubuntu 7.3.0-16ubuntu3) >built with OpenSSL 1.1.0g 2 Nov 2017 >TLS SNI support enabled >configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx >--modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf >--error-log-path=/var/log/nginx/error.log >--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid >--lock-path=/var/run/nginx.lock >--http-client-body-temp-path=/var/cache/nginx/client_temp >--http-proxy-temp-path=/var/cache/nginx/proxy_temp >--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp >--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp >--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx >--with-compat --with-file-aio --with-threads --with-http_addition_module >--with-http_auth_request_module --with-http_dav_module >--with-http_flv_module --with-http_gunzip_module >--with-http_gzip_static_module --with-http_mp4_module >--with-http_random_index_module --with-http_realip_module >--with-http_secure_link_module --with-http_slice_module >--with-http_ssl_module --with-http_stub_status_module --with-http_sub_module >--with-http_v2_module --with-mail --with-mail_ssl_module --with-stream >--with-stream_realip_module --with-stream_ssl_module >--with-stream_ssl_preread_module --with-cc-opt='-g -O2 >-fdebug-prefix-map=/data/builder/debuild/nginx-1.14.0/debian/debuild-base/nginx-1.14.0=. >-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong >-Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' >--with-ld-opt='-Wl,-Bsymbolic-functions >-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now >-Wl,--as-needed -pie' > > >/etc/nginx/nginx.conf > >user www-data; >worker_processes 8; >error_log /var/log/nginx/error.log; >pid /var/run/nginx.pid; >events { >    worker_connections 4000; >} >worker_rlimit_nofile 200000; >http { >    client_max_body_size 10m; >    charset utf-8; >    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:512m; >    include /etc/nginx/mime.types; >    default_type application/octet-stream; >    log_format main '$remote_addr - $remote_user [$time_local] "$request" >' >                      '$status $body_bytes_sent "$http_referer" ' >                      '"$http_user_agent" "$http_x_forwarded_for" >$upstream_response_time'; >    access_log /var/log/nginx/access.log main buffer=16k; >server_tokens off; >client_body_buffer_size 128k; >keepalive_requests 1000; >  sendfile on; >sendfile_max_chunk 512k; >proxy_buffering on; >open_file_cache max=200000 inactive=20s; >open_file_cache_valid 30s; >open_file_cache_min_uses 2; >open_file_cache_errors on; >    keepalive_timeout 65; >    include /etc/nginx/conf.d/*.conf; >} > > >/etc/nginx/conf.d/beta.domain.ru.conf > >proxy_cache_path /tmp/nginx_CACHE_ZONE keys_zone=CACHE:2048M; >proxy_temp_path /tmp/nginx_temp; >upstream backend { >server 195.209.xx:80; >} >upstream backend_old { >server 195.209.xx:8098; >} >server { >listen 443 ssl http2; >server_name www.domain.ru; >access_log /var/log/nginx/www.domain.ru.access.log main buffer=16k; >error_log /var/log/nginx/www.domain.ru.error.log; >client_max_body_size 20m; >keepalive_timeout 60; >gzip on; >gzip_proxied any; >gzip_types *; >gzip_vary on; >ssl on; >ssl_certificate /etc/dehydrated/certs/domain.ru/fullchain.pem; >ssl_certificate_key /etc/dehydrated/certs/domain.ru/privkey.pem; >ssl_session_timeout 5m; >ssl_protocols TLSv1 TLSv1.1 TLSv1.2; >ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; >ssl_prefer_server_ciphers on; >ssl_dhparam /etc/nginx/ssl/crt/dhparam.pem; >        charset utf-8; >proxy_send_timeout 300; >proxy_read_timeout 300; >location = / { >proxy_cache_valid 200 301 302 304 5m; >proxy_cache_key >"$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; >proxy_hide_header "Set-Cookie"; >proxy_ignore_headers "Cache-Control" "Expires"; >proxy_cache_use_stale error timeout invalid_header http_500 http_502 >http_503 http_504; >proxy_cache CACHE; >proxy_redirect off; >proxy_set_header Host $host; >proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >proxy_pass http://backend; >} >        location ~* >^(/static/|/buildpack/|/assets/|/devadm/|/desktop/|/bitrix/|/jsframework/|/templates/|/upload/|/tmp/).+\.(jpg|jpeg|gif|png|ico|css|css.*|js|js.*|swf|txt|ico|svg|woff2)$ >{ >                expires 1h; >                add_header Cache-Control public; >proxy_hide_header "Set-Cookie"; >                proxy_pass http://backend; >                proxy_cache CACHE; >                proxy_cache_valid 1h; >        } >location / { >proxy_set_header Accept-Encoding ""; >sub_filter 'http://' 'https://'; >sub_filter_once off; > >proxy_redirect off; >proxy_set_header Host $http_host; >proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >proxy_pass http://backend_old; >} >} > >root на proxy4:~# vmstat 1 >procs -----------memory---------- ---swap-- -----io---- -system-- >------cpu----- > r b swpd free buff cache si so bi bo in cs us sy id >wa st > 1 0 0 7716604 25012 264788 0 0 4 2 54 36 0 0 100 > 0 0 > 0 0 0 7716632 25012 264788 0 0 0 0 418 286 0 0 100 > 0 0 > 0 0 0 7716664 25020 264784 0 0 0 28 408 285 0 0 100 > 0 0 > 0 0 0 7716728 25020 264788 0 0 0 0 434 300 0 0 100 > 0 0 > 0 0 0 7716600 25020 264788 0 0 0 0 411 290 0 0 100 > 0 0 > 0 0 0 7716604 25020 264804 0 0 0 28 615 305 1 0 99 >0 0 > 0 0 0 7716604 25020 264804 0 0 0 0 582 283 0 0 99 >0 0 > 0 0 0 7716508 25020 264804 0 0 0 0 396 256 0 0 100 > 0 0 > >Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280414,280414#msg-280414 > >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru --- С уважением, Виталий ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Jul 5 15:07:52 2018 From: nginx-forum на forum.nginx.org (YuriN) Date: Thu, 05 Jul 2018 11:07:52 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDRgdGC0LDRgtC40YfQtdGB0LrQuNC1INGE0LDQudC7?= =?UTF-8?B?0YsgKDIw0JrQsSkg0LIg0LvQvtC60LDQu9GM0L3QvtC5INGB0LXRgtC4KDFH?= =?UTF-8?B?Yml0L3MpINC+0YLQtNCw0Y7RgtGB0Y8gMSw1INGB0LXQutGD0L3QtNGLPw==?= In-Reply-To: <1530802616.902583092@f426.i.mail.ru> References: <1530802616.902583092@f426.i.mail.ru> Message-ID: Виталий, спасибо за ответ. Да, тупит на стороне nginx'а. Я же написал: TTFB = быстрый, все файлы уже на диске сервера nginx, в директории указанной в proxy_cache_path лежат. Он проксирует и кэширует исправно (видно что файлы берутся из его кэша, т.к. upstream_response_time = 0, но почему так медленно в браузер отдаёт ответ не ясно. >Соберите tcp трейс на стороне сервера и посмотрите сколько времени реально уходит у nginx'а и нет ли tcp retry в сторону клиента. Собирал. Смотрел Wireshark'ом - есть несколько TCP ACK Duplicates (от клиента) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280414,280416#msg-280416 From vbart на nginx.com Thu Jul 5 15:23:22 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 05 Jul 2018 18:23:22 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0LvQvtCy?= =?UTF-8?B?0LrQsNGFLCDRgdC+0LTQtdGA0LbQsNGJ0LjRhSDRjtC90LjQutC+0LQ=?= In-Reply-To: <1530801058.14576632@f486.i.mail.ru> References: <2886357.QEqd3zEzdT@vbart-workstation> <1530801058.14576632@f486.i.mail.ru> Message-ID: <7258491.8gtfczzh0h@vbart-workstation> On Thursday 05 July 2018 17:30:58 Vitaly Ponomarev wrote: > А если добавить специальный ключик для этих целей? > Кому надо - осознанно разрешат. > > == > # Разрешить использовать переменные со значениями в unicode > hdr_unicode_values yes|no; default no > > # Разрешить использовать переменные с именами в unicode > hdr_unicode_keys yes|no; default no > [..] nginx испокон веков не пропускает в именах заголовков что-либо, кроме A-Za-z_- (таким образом фильтруется не просто юникод, а даже +.$\/ и куча других интересных символов) и ручки для отключения нет. Делать ручку на всякий случай, без реального кейса - это плохой подход, ведущий к появлению сотен подобных ручек и последующему хаосу. ИМХО, на интерфейсе, который смотрит в интернет, уж лучше зафильтровать лишнее, чем это лишнее пропустить. -- Валентин Бартенев From mdounin на mdounin.ru Thu Jul 5 15:37:34 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 5 Jul 2018 18:37:34 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0LvQvtCy?= =?UTF-8?B?0LrQsNGFLCDRgdC+0LTQtdGA0LbQsNGJ0LjRhSDRjtC90LjQutC+0LQ=?= In-Reply-To: <7258491.8gtfczzh0h@vbart-workstation> References: <2886357.QEqd3zEzdT@vbart-workstation> <1530801058.14576632@f486.i.mail.ru> <7258491.8gtfczzh0h@vbart-workstation> Message-ID: <20180705153734.GR56558@mdounin.ru> Hello! On Thu, Jul 05, 2018 at 06:23:22PM +0300, Валентин Бартенев wrote: > On Thursday 05 July 2018 17:30:58 Vitaly Ponomarev wrote: > > А если добавить специальный ключик для этих целей? > > Кому надо - осознанно разрешат. > > > > == > > # Разрешить использовать переменные со значениями в unicode > > hdr_unicode_values yes|no; default no > > > > # Разрешить использовать переменные с именами в unicode > > hdr_unicode_keys yes|no; default no > > > [..] > > nginx испокон веков не пропускает в именах заголовков что-либо, > кроме A-Za-z_- (таким образом фильтруется не просто юникод, > а даже +.$\/ и куча других интересных символов) и ручки для > отключения нет. Ручка для отключения - есть, "ignore_invalid_headers off", http://nginx.org/r/ignore_invalid_headers. -- Maxim Dounin http://mdounin.ru/ From vbart на nginx.com Thu Jul 5 16:00:55 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 05 Jul 2018 19:00:55 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6IDQwMCDQvtGI0LjQsdC60LAg0L/RgNC4INC30LDQs9C+0LvQvtCy?= =?UTF-8?B?0LrQsNGFLCDRgdC+0LTQtdGA0LbQsNGJ0LjRhSDRjtC90LjQutC+0LQ=?= In-Reply-To: <20180705153734.GR56558@mdounin.ru> References: <7258491.8gtfczzh0h@vbart-workstation> <20180705153734.GR56558@mdounin.ru> Message-ID: <9816356.JXlixEiOod@vbart-workstation> On Thursday 05 July 2018 18:37:34 Maxim Dounin wrote: > Hello! > > On Thu, Jul 05, 2018 at 06:23:22PM +0300, Валентин Бартенев wrote: > > > On Thursday 05 July 2018 17:30:58 Vitaly Ponomarev wrote: > > > А если добавить специальный ключик для этих целей? > > > Кому надо - осознанно разрешат. > > > > > > == > > > # Разрешить использовать переменные со значениями в unicode > > > hdr_unicode_values yes|no; default no > > > > > > # Разрешить использовать переменные с именами в unicode > > > hdr_unicode_keys yes|no; default no > > > > > [..] > > > > nginx испокон веков не пропускает в именах заголовков что-либо, > > кроме A-Za-z_- (таким образом фильтруется не просто юникод, > > а даже +.$\/ и куча других интересных символов) и ручки для > > отключения нет. > > Ручка для отключения - есть, "ignore_invalid_headers off", > http://nginx.org/r/ignore_invalid_headers. > Запамятовал значит. =) -- Валентин Бартенев From bgx на protva.ru Thu Jul 5 18:37:12 2018 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 5 Jul 2018 21:37:12 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDRgdGC0LDRgtC40YfQtdGB0LrQuNC1INGE0LDQudC7?= =?UTF-8?B?0YsgKDIw0JrQsSkg0LIg0LvQvtC60LDQu9GM0L3QvtC5INGB0LXRgtC4KDFH?= =?UTF-8?B?Yml0L3MpINC+0YLQtNCw0Y7RgtGB0Y8gMSw1INGB0LXQutGD0L3QtNGLPw==?= In-Reply-To: References: Message-ID: <20180705183712.GG21350@protva.ru> On Thu, Jul 05, 2018 at 10:45:35AM -0400, YuriN wrote: > Статика, скажем, размером 20kb отдаётся порядка 1-1.5 секунды. При чём TTFB > относительно быстрый - 200-300 ms, а доставка от nginx до браузера уже 1-1.5 > секунды. По логам видно, что эта статика берётся из кэша всё-таки > ($upstream_response_time = 0). > Условия проверки: обращение к титульной странице нашего сайта - это 80 > запросов, 2.7Mb трафика суммарно, по https, http2. > Конфиг вроде бы стандартный, без особого тюнинга (приложен) > Если скачивать один только статический файл (1 запрос) - то он скачивается > без этих задержек - 27 ms. Показатель TTFB (time to first byte) при отсутствии каких-либо тормозов на сервере должен быть около двух задержек (rtt) от сервера к клиенту. Но если в этот показатель включается время ssl-ного хендшейка, то он может быть существенно выше, т.к. включает тяжёлую криптографию и зависит от скорости шифрования на клиенте и на сервере. Как измеряется этот TTFB и каково реальное значение rtt? Вы пишете, что TTFB порядка 200-300 ms, а ниже, что заказчка целого файла занимает целых 27 ms. Здесь явно противоречие, причём на порядок. Какова получается скорость загрузки по http без ssl? В дампе, при подозрении на потери в канале, прежде всего следует искать пакеты с селективными подтверждениями (sack), это удобный индикатор потерь. Разумеется, нужно убедиться, при tcp-шном хендшейке что обе стороны договорились эту опцию использовать. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Thu Jul 5 21:10:03 2018 From: nginx-forum на forum.nginx.org (ngnx8810773a83) Date: Thu, 05 Jul 2018 17:10:03 -0400 Subject: =?UTF-8?B?UmU6INCe0YLQutGA0YvRgtGL0LUg0YTQsNC50LvRiyDRgNCw0YHRgtGD0YIg0L8=?= =?UTF-8?B?0L7RgdC70LUg0L7QsdC90L7QstC70LXQvdC40Y8g0LTQviAxLjE0?= In-Reply-To: References: <350e47c180330e56827a4fb3a2d1a63a.NginxMailingListRussian@forum.nginx.org> <550999926f61203f0a38e801069e4bdd.NginxMailingListRussian@forum.nginx.org> Message-ID: Запуск тогоже с обновленным модулем brotli тоже проблему решил. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280196,280424#msg-280424 From nginx-forum на forum.nginx.org Thu Jul 5 21:22:20 2018 From: nginx-forum на forum.nginx.org (zerko) Date: Thu, 05 Jul 2018 17:22:20 -0400 Subject: =?UTF-8?B?0L/RgNC+0LHQu9C10LzRiyByZXdyaXRlICsgc2VjdXJlIGxpbmssINGN0LrRgNCw?= =?UTF-8?B?0L3QuNC30LDRhtC40Y8g0YHQuNC80LLQvtC70LAgPyAo0LLQvtC/0YDQvtGB?= =?UTF-8?B?0LAp?= Message-ID: Здравствуйте форумчане, целый день провозился с проблемой, помогите пожалуйста, буду признателен! nginx version: nginx/1.14.0 стоит реврайт: rewrite ^/sec/(.*)/(\d+)/((film|serial)/(.*))$ /stream/$3?md5=$1&expires=$2 last; и есть этот локейшен: location /stream { secure_link $arg_md5,$arg_expires; secure_link_md5 "$secure_link_expires$uri$remote_addr secret"; if ($secure_link = "") { return 200 "$query_string $arg_md5 $uri $secure_link_expires $uri $remote_addr secret"; } if ($secure_link = "0") { return 410; } rewrite ^/stream/(.*)$ /content/vod/$1 break; } и запросы не приходят в локейшен /stream (Почему? я пологаю что не передаются hash и expires, но даже без них должен обрабатываться запрос?), стоит только добавить в регулярное вырожение экранирование \? (rewrite ^/sec/(.*)/(\d+)/((film|serial)/(.*))$ /stream/$3\?md5=$1&expires=$2 last;) - так все работает. НО! в переменную $3 добавляется этот слэш - "\", и расшифровка не происходит.. Что делать? Интересно что даже без ЧПУ ссылок, ввида: /stream/film/rampage.2018.720p/hls/720/index.m3u8?md5=sC-pYJ0gHU5PjJDi-18BOQ&expires=1530842792 запрос не работает тоже, в локейшен не попадает, добавляю \ перед ? (вопросов) и все опять работает!!! Надеюсь на вашу помощь. На другом сервере, на старой версии подобные реврайты работают. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280425,280425#msg-280425 From mdounin на mdounin.ru Fri Jul 6 01:31:34 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 6 Jul 2018 04:31:34 +0300 Subject: =?UTF-8?B?UmU6ICJ3b3JrZXJfY29ubmVjdGlvbnMgYXJlIG5vdCBlbm91Z2giIC0g0L7QsdGB?= =?UTF-8?B?0YPQtNC40LwgPw==?= In-Reply-To: References: Message-ID: <20180706013134.GU56558@mdounin.ru> Hello! On Thu, Jul 05, 2018 at 07:29:37PM +0500, Илья Шипицин wrote: [...] > # cat /var/log/nginx/error.log | tail -2 > 2018/07/05 14:27:53 [alert] 1546#1546: 512 worker_connections are not enough > 2018/07/05 14:27:53 [alert] 1545#1545: worker process 1546 exited with > fatal code 2 and cannot be respawned > # > > > кажется, что было бы логично отсекать такие ошибки во время "nginx -t" > что думаете ? Кажется, ситуация не отличается принципиально от любой другой, когда nginx'у не хватает соединений для нормальной работы. Но можно попробовать какой-то такой патч, сколько-то ног он наверное сохранит: # HG changeset patch # User Maxim Dounin # Date 1530840179 -10800 # Fri Jul 06 04:22:59 2018 +0300 # Node ID 7f4aa03a8a21164881429568bd2f70a311c5c599 # Parent 54683f650cbdcd73f7f8d845c843295978da5a85 Events: added configuration check on the number of connections. There should be at least one worker connection for each listening socket, plus an additional connection for channel between worker and master, or starting worker process will fail. diff --git a/src/event/ngx_event.c b/src/event/ngx_event.c --- a/src/event/ngx_event.c +++ b/src/event/ngx_event.c @@ -416,6 +416,21 @@ ngx_event_init_conf(ngx_cycle_t *cycle, return NGX_CONF_ERROR; } + if (cycle->connection_n < cycle->listening.nelts + 1) { + + /* + * there should be at least one connection for each listening + * socket, plus one connection for channel + */ + + ngx_log_error(NGX_LOG_EMERG, cycle->log, 0, + "%ui worker_connections are not enough " + "for nginx with %ui listening sockets", + cycle->connection_n, cycle->listening.nelts); + + return NGX_CONF_ERROR; + } + return NGX_CONF_OK; } -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Fri Jul 6 04:41:24 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 6 Jul 2018 09:41:24 +0500 Subject: =?UTF-8?B?UmU6ICJ3b3JrZXJfY29ubmVjdGlvbnMgYXJlIG5vdCBlbm91Z2giIC0g0L7QsdGB?= =?UTF-8?B?0YPQtNC40LwgPw==?= In-Reply-To: <20180706013134.GU56558@mdounin.ru> References: <20180706013134.GU56558@mdounin.ru> Message-ID: пт, 6 июл. 2018 г. в 6:32, Maxim Dounin : > Hello! > > On Thu, Jul 05, 2018 at 07:29:37PM +0500, Илья Шипицин wrote: > > [...] > > > # cat /var/log/nginx/error.log | tail -2 > > 2018/07/05 14:27:53 [alert] 1546#1546: 512 worker_connections are not > enough > > 2018/07/05 14:27:53 [alert] 1545#1545: worker process 1546 exited with > > fatal code 2 and cannot be respawned > > # > > > > > > кажется, что было бы логично отсекать такие ошибки во время "nginx -t" > > что думаете ? > > Кажется, ситуация не отличается принципиально от любой другой, > когда nginx'у не хватает соединений для нормальной работы. Но > можно попробовать какой-то такой патч, сколько-то ног он наверное > сохранит: > попробовал, все получается так, как задумано [root на xxx nginx-1.15.1]# objs/nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: [emerg] 512 worker_connections are not enough for nginx with 701 listening sockets nginx: configuration file /etc/nginx/nginx.conf test failed [root на xxx nginx-1.15.1]# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful [root на xxx nginx-1.15.1]# > > # HG changeset patch > # User Maxim Dounin > # Date 1530840179 -10800 > # Fri Jul 06 04:22:59 2018 +0300 > # Node ID 7f4aa03a8a21164881429568bd2f70a311c5c599 > # Parent 54683f650cbdcd73f7f8d845c843295978da5a85 > Events: added configuration check on the number of connections. > > There should be at least one worker connection for each listening socket, > plus an additional connection for channel between worker and master, > or starting worker process will fail. > > diff --git a/src/event/ngx_event.c b/src/event/ngx_event.c > --- a/src/event/ngx_event.c > +++ b/src/event/ngx_event.c > @@ -416,6 +416,21 @@ ngx_event_init_conf(ngx_cycle_t *cycle, > return NGX_CONF_ERROR; > } > > + if (cycle->connection_n < cycle->listening.nelts + 1) { > + > + /* > + * there should be at least one connection for each listening > + * socket, plus one connection for channel > + */ > + > + ngx_log_error(NGX_LOG_EMERG, cycle->log, 0, > + "%ui worker_connections are not enough " > + "for nginx with %ui listening sockets", > + cycle->connection_n, cycle->listening.nelts); > + > + return NGX_CONF_ERROR; > + } > + > return NGX_CONF_OK; > } > > > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Jul 6 12:41:48 2018 From: nginx-forum на forum.nginx.org (YuriN) Date: Fri, 06 Jul 2018 08:41:48 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDRgdGC0LDRgtC40YfQtdGB0LrQuNC1INGE0LDQudC7?= =?UTF-8?B?0YsgKDIw0JrQsSkg0LIg0LvQvtC60LDQu9GM0L3QvtC5INGB0LXRgtC4KDFH?= =?UTF-8?B?Yml0L3MpINC+0YLQtNCw0Y7RgtGB0Y8gMSw1INGB0LXQutGD0L3QtNGLPw==?= In-Reply-To: <20180705183712.GG21350@protva.ru> References: <20180705183712.GG21350@protva.ru> Message-ID: > Показатель TTFB (time to first byte) при отсутствии каких-либо тормозов на сервере должен быть около двух задержек (rtt) от сервера к клиенту. Но если в этот показатель включается время ssl-ного хендшейка, то он может быть существенно выше, т.к. включает тяжёлую криптографию и зависит от скорости шифрования на клиенте и на сервере. Как измеряется этот TTFB и каково реальное значение rtt? Измеряется при помощи DeveloperTools в Chrome. Вот скриншот https://i.snag.gy/XSY3Rm.jpg rtt, если замерять пингом сейчас при размере пакета 56 байт: 64 bytes from xx.yy.zz.ww: icmp_seq=0 ttl=51 time=12.021 ms 64 bytes from xx.yy.zz.ww: icmp_seq=1 ttl=51 time=11.656 ms 64 bytes from xx.yy.zz.ww: icmp_seq=2 ttl=51 time=13.301 ms 64 bytes from xx.yy.zz.ww: icmp_seq=3 ttl=51 time=13.470 ms 64 bytes from xx.yy.zz.ww: icmp_seq=4 ttl=51 time=12.245 ms (в данный момент замеры не внутри локальной сети, а по интернету, однако вообще никакой разницы в производительности не наблюдалось когда сервер nginx был в одной локальной сети (1Гб/с у обоих, клиента и сервера) с браузером) >Вы пишете, что TTFB порядка 200-300 ms, а ниже, что заказчка целого файла занимает целых 27 ms. Здесь явно противоречие, причём на порядок. Здесь нюанс: При 80 запросах - время закачки каждого из файлов по отдельности 1-1.5 сек. При 1 единственном запросе - время закачки одного файла 23 ms (это тот же файл, к-ый присутствует в предыдущих 80-и запросах) TTFB варьируется и это нормально - т.е. если не было файла в кэше, конечно TTFB будет больше (пока nginx заберёт файл с upstream или пока считает его с диска) TTFB мы даже не рассматриваем, он вполне себе нормальный. А вот доставка ответа от nginx до браузера феноменально тормознутая. При чём, как я говорил уже, без разницы в локальной сети nginx c браузером находится или нет. > Какова получается скорость загрузки по http без ssl? Без ssl время отдачи каждого запроса сократилось примерно на 50мс. И сегодня большинство запросов уже по полсекунды обрабатываются, вместо вчерашней секунды! (при том что я не менял какие-то настройки) Также я заметил есть пара файлов ( SVG картинки менее 1кб) - они стабильно грузятся 1 секунду (при том что точно берутся из кэша). https://i.snag.gy/Yuczp3.jpg > В дампе, при подозрении на потери в канале, прежде всего следует искать пакеты с селективными подтверждениями (sack),  Сделал фильтр по tcp.options.sack.count - Wireshark показал множество таких пакетов. Скажем я снимал дамп секунд 10 (время загрузки титульной страницы сайта) и за это время в дампе оказалось 285 пакетов с SACK из 2284 суммарно. Что с этим можно сделать? >Разумеется, нужно убедиться, при tcp-шном хендшейке что обе стороны договорились эту опцию использовать. handshake’а нет в этом дампе, смогу написать несколько позже о том, что происходит нём. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280414,280435#msg-280435 From slw на zxy.spb.ru Fri Jul 6 12:56:06 2018 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 6 Jul 2018 15:56:06 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDRgdGC0LDRgtC40YfQtdGB0LrQuNC1INGE0LDQudC7?= =?UTF-8?B?0YsgKDIw0JrQsSkg0LIg0LvQvtC60LDQu9GM0L3QvtC5INGB0LXRgtC4KDFH?= =?UTF-8?B?Yml0L3MpINC+0YLQtNCw0Y7RgtGB0Y8gMSw1INGB0LXQutGD0L3QtNGLPw==?= In-Reply-To: References: <20180705183712.GG21350@protva.ru> Message-ID: <20180706125606.GG71987@zxy.spb.ru> On Fri, Jul 06, 2018 at 08:41:48AM -0400, YuriN wrote: > > В дампе, при подозрении на потери в канале, прежде всего следует искать > пакеты с селективными подтверждениями (sack),  > Сделал фильтр по tcp.options.sack.count - Wireshark показал множество таких > пакетов. > Скажем я снимал дамп секунд 10 (время загрузки титульной страницы сайта) и > за это время в дампе оказалось 285 пакетов с SACK из 2284 суммарно. > Что с этим можно сделать? наврное лучше всего оплатить консультацию квалифицированного сетевого инженера, который сможет проанализировать дампы. потому что по таким признакам ("285 пакетов с SACK из 2284 суммарно") что-то достоверно сказать нельзя, но их как-то черезчур многовато и возникают подозрения не проблемы на сетевом уровне. возможно проблемы с half/full дуплексом со стороны сервера. > >Разумеется, нужно убедиться, при tcp-шном хендшейке что обе стороны > договорились эту опцию использовать. > handshake’а нет в этом дампе, смогу написать несколько позже о том, что > происходит нём. From nginx-forum на forum.nginx.org Fri Jul 6 15:19:36 2018 From: nginx-forum на forum.nginx.org (YuriN) Date: Fri, 06 Jul 2018 11:19:36 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDRgdGC0LDRgtC40YfQtdGB0LrQuNC1INGE0LDQudC7?= =?UTF-8?B?0YsgKDIw0JrQsSkg0LIg0LvQvtC60LDQu9GM0L3QvtC5INGB0LXRgtC4KDFH?= =?UTF-8?B?Yml0L3MpINC+0YLQtNCw0Y7RgtGB0Y8gMSw1INGB0LXQutGD0L3QtNGLPw==?= In-Reply-To: <20180706125606.GG71987@zxy.spb.ru> References: <20180706125606.GG71987@zxy.spb.ru> Message-ID: >наврное лучше всего оплатить консультацию квалифицированного сетевого инженера, который сможет проанализировать дампы. потому что по таким признакам ("285 пакетов с SACK из 2284 суммарно") что-то достоверно сказать нельзя, но их как-то черезчур многовато и возникают подозрения не проблемы на сетевом уровне. > возможно проблемы с half/full дуплексом со стороны сервера. я пробовал запускать виртуалку с nginx на двух разных физических серверах. (и по совместительству это были разные гипервизоры: ESXi 5.5 и Proxmox/KVM) судя по ifconfig на гипервизоре сейчас, коллизий 0 - соответственно это не half duplex. ethtool -S enp2s0f0 | egrep 'miss|over|drop|lost|fifo' - по нулям На виртуалке сейчас watch -n1 -d ifconfig -a показывает примерно один dropped пакет в секунду. Может ли один отброшенный пакет в секунду доставлять такие проблемы. Допустим. Это единственная очевидная зацепка пока. Интернет пишет по этому поводу: Some general reasons * NIC ring buffers getting full and unable to cope-up with incoming bursts of traffic * CPU receiving NIC interrupts is very busy and unable to process * some cable/hardware/duplex issues * some bug in NIC driver Попробую решить первые два пункта. Если есть ещё соображения - буду признателен. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280414,280438#msg-280438 From bgx на protva.ru Fri Jul 6 16:37:28 2018 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 6 Jul 2018 19:37:28 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDRgdGC0LDRgtC40YfQtdGB0LrQuNC1INGE0LDQudC7?= =?UTF-8?B?0YsgKDIw0JrQsSkg0LIg0LvQvtC60LDQu9GM0L3QvtC5INGB0LXRgtC4KDFH?= =?UTF-8?B?Yml0L3MpINC+0YLQtNCw0Y7RgtGB0Y8gMSw1INGB0LXQutGD0L3QtNGLPw==?= In-Reply-To: References: <20180706125606.GG71987@zxy.spb.ru> Message-ID: <20180706163728.GN21350@protva.ru> On Fri, Jul 06, 2018 at 11:19:36AM -0400, YuriN wrote: > На виртуалке сейчас watch -n1 -d ifconfig -a показывает примерно один > dropped пакет в секунду. > Может ли один отброшенный пакет в секунду доставлять такие проблемы. > Допустим. Это единственная очевидная зацепка пока. Если мне не изменяет склероз, dropped в RX это к-во пакетов, которые были нормально приняты (чексумма правильная и в буфере карты хватило места, поэтому они не попали ни в errors, ни в overrun), но которым не нашлось свободного skb в ядре, и потому они были выброшены - dropped. Ситуация ненормальная, нормой является несколько пакетов на миллион принятых. Возможно, сетевой подсистеме не хватает памяти, но это мизерные потери. Раньше речь шла про пакеты с tcp-опцией sack, которая отражают потери на маршруте. Вы писали: > Скажем я снимал дамп секунд 10 (время загрузки титульной страницы сайта) и > за это время в дампе оказалось 285 пакетов с SACK из 2284 суммарно. Думаю, должно быть на порядок меньше, чтобы сеть можно было считать работающей удовлетворительно. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Mon Jul 9 02:15:31 2018 From: nginx-forum на forum.nginx.org (zerko) Date: Sun, 08 Jul 2018 22:15:31 -0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80YsgcmV3cml0ZSArIHNlY3VyZSBsaW5rLCDRjdC6?= =?UTF-8?B?0YDQsNC90LjQt9Cw0YbQuNGPINGB0LjQvNCy0L7Qu9CwID8gKNCy0L7Qv9GA?= =?UTF-8?B?0L7RgdCwKQ==?= In-Reply-To: References: Message-ID: <6a30b2800d1562dcff0cabba9627a014.NginxMailingListRussian@forum.nginx.org> Ребят, думал проблема в том что на редиректе в новом локейшене нету internal; поставил - все равно не помогло, на других серверах подобный конфиг крутится и все работает.. можете сказать в чем причина? вот конфиг: location /stream { secure_link $arg_md5,$arg_expires; secure_link_md5 "$secure_link_expires$uri$remote_addr secret"; if ($secure_link = "") { return 403; } if ($secure_link = "0") { return 410; } return 200 "$uri"; # rewrite ^/stream/(.*)$ /content/vod/$1 break; } location /content/vod { internal; } ссылки - /stream/film/rampage.2018.720p/hls/360/segment1.ts?md5=LiQjwr4LZRGdOVCV-aeOgg&expires=1531119761 в логах пишет: open () "/home/stream/www/stream/film/rampage.2018.720p/hls/360/segment1.ts" failed (2: No such file or directory) почему не попадает ссылка в локейшен /stream и не проходит проверка с реврайтом? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280425,280448#msg-280448 From nginx-forum на forum.nginx.org Mon Jul 9 02:38:46 2018 From: nginx-forum на forum.nginx.org (zerko) Date: Sun, 08 Jul 2018 22:38:46 -0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80YsgcmV3cml0ZSArIHNlY3VyZSBsaW5rLCDRjdC6?= =?UTF-8?B?0YDQsNC90LjQt9Cw0YbQuNGPINGB0LjQvNCy0L7Qu9CwID8gKNCy0L7Qv9GA?= =?UTF-8?B?0L7RgdCwKQ==?= In-Reply-To: <6a30b2800d1562dcff0cabba9627a014.NginxMailingListRussian@forum.nginx.org> References: <6a30b2800d1562dcff0cabba9627a014.NginxMailingListRussian@forum.nginx.org> Message-ID: только добавляю в ссылку слэш перед вопросом - /stream/film/rampage.2018.720p/hls/360/segment1.ts\?md5=LiQjwr4LZRGdOVCV-aeOgg&expires=1531119761 попадает в локейшен!! и выдает 403 форбиден. Ну как так? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280425,280449#msg-280449 From nefer05 на gmail.com Mon Jul 9 08:54:28 2018 From: nefer05 на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Mon, 9 Jul 2018 11:54:28 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80YsgcmV3cml0ZSArIHNlY3VyZSBsaW5rLCDRjdC6?= =?UTF-8?B?0YDQsNC90LjQt9Cw0YbQuNGPINGB0LjQvNCy0L7Qu9CwID8gKNCy0L7Qv9GA?= =?UTF-8?B?0L7RgdCwKQ==?= In-Reply-To: References: <6a30b2800d1562dcff0cabba9627a014.NginxMailingListRussian@forum.nginx.org> Message-ID: RTFM! Параметры не являются частью локейшена! On Mon, Jul 9, 2018 at 5:38 AM zerko wrote: > только добавляю в ссылку слэш перед вопросом - > > /stream/film/rampage.2018.720p/hls/360/segment1.ts\?md5=LiQjwr4LZRGdOVCV-aeOgg&expires=1531119761 > попадает в локейшен!! и выдает 403 форбиден. Ну как так? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,280425,280449#msg-280449 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Jul 9 09:18:22 2018 From: nginx-forum на forum.nginx.org (zerko) Date: Mon, 09 Jul 2018 05:18:22 -0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80YsgcmV3cml0ZSArIHNlY3VyZSBsaW5rLCDRjdC6?= =?UTF-8?B?0YDQsNC90LjQt9Cw0YbQuNGPINGB0LjQvNCy0L7Qu9CwID8gKNCy0L7Qv9GA?= =?UTF-8?B?0L7RgdCwKQ==?= In-Reply-To: References: Message-ID: <66d2b60af5b037f4133cd384cc651604.NginxMailingListRussian@forum.nginx.org> Так а почему на других серверах параметры передаются? Эта инструкция secure link описана на офф сайте, я сделал 1в1, в итоге не работает, что не так? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280425,280456#msg-280456 From nefer05 на gmail.com Mon Jul 9 09:38:16 2018 From: nefer05 на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Mon, 9 Jul 2018 12:38:16 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80YsgcmV3cml0ZSArIHNlY3VyZSBsaW5rLCDRjdC6?= =?UTF-8?B?0YDQsNC90LjQt9Cw0YbQuNGPINGB0LjQvNCy0L7Qu9CwID8gKNCy0L7Qv9GA?= =?UTF-8?B?0L7RgdCwKQ==?= In-Reply-To: <66d2b60af5b037f4133cd384cc651604.NginxMailingListRussian@forum.nginx.org> References: <66d2b60af5b037f4133cd384cc651604.NginxMailingListRussian@forum.nginx.org> Message-ID: Я буду полностью перечитывать сообщение перед ответом! Я буду полностью перечитывать сообщение перед ответом! On Mon, Jul 9, 2018 at 12:18 PM zerko wrote: > Так а почему на других серверах параметры передаются? Эта инструкция secure > link описана на офф сайте, я сделал 1в1, в итоге не работает, что не так? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,280425,280456#msg-280456 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nefer05 на gmail.com Mon Jul 9 09:39:00 2018 From: nefer05 на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Mon, 9 Jul 2018 12:39:00 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80YsgcmV3cml0ZSArIHNlY3VyZSBsaW5rLCDRjdC6?= =?UTF-8?B?0YDQsNC90LjQt9Cw0YbQuNGPINGB0LjQvNCy0L7Qu9CwID8gKNCy0L7Qv9GA?= =?UTF-8?B?0L7RgdCwKQ==?= References: <66d2b60af5b037f4133cd384cc651604.NginxMailingListRussian@forum.nginx.org> Message-ID: Да что ж такое то. :( Извиняюсь, моя первоначальная реплика немного неуместна, контекст попутал :( On Mon, Jul 9, 2018 at 12:38 PM Роман Москвитин wrote: > Я буду полностью перечитывать сообщение перед ответом! > Я буду полностью перечитывать сообщение перед ответом! > > > On Mon, Jul 9, 2018 at 12:18 PM zerko wrote: > >> Так а почему на других серверах параметры передаются? Эта инструкция >> secure >> link описана на офф сайте, я сделал 1в1, в итоге не работает, что не так? >> >> Posted at Nginx Forum: >> https://forum.nginx.org/read.php?21,280425,280456#msg-280456 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Fri Jul 13 13:30:16 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 13 Jul 2018 16:30:16 +0300 Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuMw==?= Message-ID: <2296119.1MaD7Tglpp@vbart-workstation> Здравствуйте. Рад сообщить о выпуске новой версии NGINX Unit. Изменения в Unit 1.3 13.07.2018 *) Изменение: в значениях полей заголовка запроса разрешены символы UTF-8. *) Добавление: настройка ограничения на размер тела запроса. *) Добавление: настройка различных таймаутов HTTP соединения. *) Добавление: теперь модуль Ruby автоматически использует Bundler, если тот доступен. *) Добавление: интерфейс http.Flusher в модуле Go. *) Исправление: различные проблемы при обработке ошибок в HTTP соединении. *) Исправление: запросы с телом могли некорректно обрабатываться в модуле PHP. *) Исправление: отдельные опций конфигурации PHP, установленные через API, сбрасывались после обработки первого запроса в процессе приложения. Пример конфигурации с новыми параметрами: { "settings": { "http": { "header_read_timeout": 30, "body_read_timeout": 30, "send_timeout": 30, "idle_timeout": 180, "max_body_size": 8388608 } }, "listeners": { "127.0.0.1:8034": { "application": "mercurial" } }, "applications": { "mercurial": { "type": "python 2", "module": "hgweb", "path": "/data/hg" } } } Все таймауты указываются в секундах. Значение "max_body_size" задается в байтах. Обратите внимание, что в данном примере параметры объекта "http" установлены в свои значения по умолчанию. Если данные значения вас устраивают, то нет необходимости задавать их явно. Пакеты для дистрибутивов Linux, а также Docker-образы доступны по ссылкам: - Пакеты: https://unit.nginx.org/installation/#precompiled-packages - Docker: https://hub.docker.com/r/nginx/unit/tags/ Также следите за статьями в нашем блоге, где подробнее рассказывается о новых возможностях в свежих версиях Unit'a: - https://www.nginx.com/blog/tag/nginx-unit/ -- Валентин Бартенев From nginx-forum на forum.nginx.org Sun Jul 15 03:20:59 2018 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Sat, 14 Jul 2018 23:20:59 -0400 Subject: =?UTF-8?B?bmd4IHNzbCBjZXJ0aWZpY2F0ZXMg0LLRi9C30YvQstCw0LXRgtGB0Y8g0LTQsNC2?= =?UTF-8?B?0LUg0LTQu9GPINGB0LDQudGC0L7QsiDQsdC10Lcgc3Ns?= Message-ID: <84ea3345ea2720eed5f186bba6bf39d7.NginxMailingListRussian@forum.nginx.org> Имеется конфигурация с ~500-600 сайтов, из них примерно 10% с поддержкой https, в остальных только http. wildcard-ключ с сертификатом указан в блоке "http". Обратил внимание, что "nginx -t" и "nginx -s reload" стали отрабатывать секунд по 10. Профайлер говорит, что 90% времени уходит на ngx_http_ssl_merge_srv_conf => ngx_ssl_certificates, количество вызовов у них одинаковое. Переместил сертификат в блоки "server", где используется ssl - nginx стал читать конфигурацию в несколько раз быстрее. Какой смысл проверять сертификаты для серверов без https? Можно ли отключить такую проверку? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280523,280523#msg-280523 From mdounin на mdounin.ru Sun Jul 15 22:11:58 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 16 Jul 2018 01:11:58 +0300 Subject: =?UTF-8?B?UmU6IG5neCBzc2wgY2VydGlmaWNhdGVzINCy0YvQt9GL0LLQsNC10YLRgdGPINC0?= =?UTF-8?B?0LDQttC1INC00LvRjyDRgdCw0LnRgtC+0LIg0LHQtdC3IHNzbA==?= In-Reply-To: <84ea3345ea2720eed5f186bba6bf39d7.NginxMailingListRussian@forum.nginx.org> References: <84ea3345ea2720eed5f186bba6bf39d7.NginxMailingListRussian@forum.nginx.org> Message-ID: <20180715221158.GS56558@mdounin.ru> Hello! On Sat, Jul 14, 2018 at 11:20:59PM -0400, Ilya Evseev wrote: > Имеется конфигурация с ~500-600 сайтов, из них примерно 10% с поддержкой > https, в остальных только http. > wildcard-ключ с сертификатом указан в блоке "http". > > Обратил внимание, что "nginx -t" и "nginx -s reload" стали отрабатывать > секунд по 10. > > Профайлер говорит, что 90% времени уходит на ngx_http_ssl_merge_srv_conf => > ngx_ssl_certificates, > количество вызовов у них одинаковое. > > Переместил сертификат в блоки "server", где используется ssl - nginx стал > читать конфигурацию в несколько раз быстрее. > > Какой смысл проверять сертификаты для серверов без https? > Можно ли отключить такую проверку? В силу исторических причин на уровне server{} в момент merge'а конфигурации неизвестно, может ли в него попасть HTTPS-соединение, или нет. Скажем, вот в такой конфигурации HTTPS-соединение может попасть и в сервер foo, и в сервер bar, но nginx об этом знает только в сервере foo: server { listen 443; server_name foo; ssl on; } server { listen 443; server_name bar; } Соответственно признаком для того, что нужно создавать SSL-контекст и загружать сертификаты служит собственно наличие сертфикатов. Если SSL-сертификат в данном сервере задан (или унаследован с уровня http) - то SSL-контекст создаётся. Если не задан - не создаётся. Начиная с 1.15.0 nginx ругается на наличие директивы "ssl", и предлагает вместо неё использовать "listen ... ssl". Когда мы её окончательно запретим - возможно, дойдут руки и до оптимизации создания SSL-контекстов, благо при использовании "listen ... ssl" это получается сделать несколько проще. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Jul 17 06:40:18 2018 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Tue, 17 Jul 2018 02:40:18 -0400 Subject: =?UTF-8?B?UmU6IG5neCBzc2wgY2VydGlmaWNhdGVzINCy0YvQt9GL0LLQsNC10YLRgdGPINC0?= =?UTF-8?B?0LDQttC1INC00LvRjyDRgdCw0LnRgtC+0LIg0LHQtdC3IHNzbA==?= In-Reply-To: <20180715221158.GS56558@mdounin.ru> References: <20180715221158.GS56558@mdounin.ru> Message-ID: <30653e70be022ca09ce72030e920de0f.NginxMailingListRussian@forum.nginx.org> А парсинг конфига - это операция по определению однопоточная? Её никак не распараллелить? Пользователи меняют настройки своих сайтов довольно часто, при этом автоматически перестраивается конфиг nginx'a и вызывается nginx -t && nginx -s reload. Пока https был не в моде, это происходило мгновенно. Когда https появится у всех, каждое перечитывание будет длиться по минуте и дольше. Перспектива малоприятная. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280525,280543#msg-280543 From chipitsine на gmail.com Tue Jul 17 07:31:27 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 17 Jul 2018 12:31:27 +0500 Subject: =?UTF-8?B?UmU6IG5neCBzc2wgY2VydGlmaWNhdGVzINCy0YvQt9GL0LLQsNC10YLRgdGPINC0?= =?UTF-8?B?0LDQttC1INC00LvRjyDRgdCw0LnRgtC+0LIg0LHQtdC3IHNzbA==?= In-Reply-To: <30653e70be022ca09ce72030e920de0f.NginxMailingListRussian@forum.nginx.org> References: <20180715221158.GS56558@mdounin.ru> <30653e70be022ca09ce72030e920de0f.NginxMailingListRussian@forum.nginx.org> Message-ID: вт, 17 июл. 2018 г. в 11:40, Ilya Evseev : > А парсинг конфига - это операция по определению однопоточная? > Её никак не распараллелить? > Пользователи меняют настройки своих сайтов довольно часто, при этом > автоматически перестраивается конфиг nginx'a и вызывается nginx -t && nginx > -s reload. > Пока https был не в моде, это происходило мгновенно. > Когда https появится у всех, каждое перечитывание будет длиться по минуте и > дольше. > Перспектива малоприятная. > можно распилить на "systemd instantiated units" и, соответственно, перегружать только то, что поменялось (а не всё каждый раз). в целом эта гонка вооружений "запихать всё-всё-всё в один конфиг и делать reload" печалит, конечно на reload есть неприятный выбор из двух зол - оставлять или принудительно закрывать worker-ы (например, у вас есть stream-ы долгоиграющие, которые своим чередом никогда не закроются). как поступить, оставить их навечно ? тогда закончится память. принудительно прописать worker_shutdown_timeout ? тогда к вам придут жаловаться пользователи stream-ов. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,280525,280543#msg-280543 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From jd на jdwuzhere.ru Tue Jul 17 10:16:14 2018 From: jd на jdwuzhere.ru (Vladimir Sopot) Date: Tue, 17 Jul 2018 13:16:14 +0300 Subject: a client request body is buffered to a temporary file Message-ID: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> Привет! Хотел бы предложить добавить размер сохраняемого тела в notice "a client request body is buffered to a temporary file /wwwroot/tmp/nginx/client_body_temp/0004405740”, типа “a client request body (100Mb) is buffered to a temporary file /wwwroot/tmp/nginx/client_body_temp/0004405740”. Просто, чтобы понять, то ли пользователи пихают невпихуемое (и насколько) , то ли client_body_buffer_size закручен неправильно. Спасибо. From nginx-forum на forum.nginx.org Tue Jul 17 11:21:23 2018 From: nginx-forum на forum.nginx.org (Reborns) Date: Tue, 17 Jul 2018 07:21:23 -0400 Subject: Nginx Unit + Ruby from rvm.io Message-ID: Приветствую. Суть вопроса ... можно ли как то использовать юнит если руби стоит не из APT ? Тоесть в системе есть ruby и rack .и все это работает на nginx + passenger .. но как обяснить юниту что бы смотрел не в /usr/lib/ruby а в /usr/local/rvm/gems/ruby-2.4.1 итп. итд. для passenger а например в конфиге nginx а есть настройки типа... passenger_root /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.3.3; passenger_ruby /usr/local/rvm/gems/ruby-2.4.1/wrappers/ruby; passenger_env_var PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; Хочу отказаться от пассенджера в пользу юнита , но при условии что руби будет ставиться не из пакетов а через RVM .. Спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280546,280546#msg-280546 From igor на sysoev.ru Tue Jul 17 12:11:49 2018 From: igor на sysoev.ru (Igor Sysoev) Date: Tue, 17 Jul 2018 15:11:49 +0300 Subject: Nginx Unit + Ruby from rvm.io In-Reply-To: References: Message-ID: <4E1E0258-5046-44A8-AC4D-6CF7EABFE4A0@sysoev.ru> > On 17 Jul 2018, at 14:21, Reborns wrote: > > Приветствую. > Суть вопроса ... можно ли как то использовать юнит если руби стоит не из APT > ? Тоесть в системе есть ruby и rack .и все это работает на nginx + > passenger .. но как обяснить юниту что бы смотрел не в /usr/lib/ruby а в > /usr/local/rvm/gems/ruby-2.4.1 итп. итд. > > для passenger а например в конфиге nginx а есть настройки типа... > > passenger_root /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.3.3; > passenger_ruby /usr/local/rvm/gems/ruby-2.4.1/wrappers/ruby; > passenger_env_var PATH > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; > > > Хочу отказаться от пассенджера в пользу юнита , но при условии что руби > будет ставиться не из пакетов а через RVM .. Для этого придётся собрать unit из исходников с нужными параметрами, например, так: ./configure --prefix=/usr/local/ Возможные параметры можно посмотреть так: ./configure --help Какие параметры используются в уже собранном unitd, можно узнать так: /path/to/unitd --help После этого нужно сконфигурировать модуль ruby: ./configure ruby --ruby=/usr/local/rvm/gems/ruby-2.4.1/bin/ruby Потом собрать и установить: make sudo make install Итак, всё вместе: ./configure --prefix=/usr/local/ ./configure ruby --ruby=/usr/local/rvm/gems/ruby-2.4.1/bin/ruby make sudo make install -- Igor Sysoev http://nginx.com From mdounin на mdounin.ru Tue Jul 17 12:29:00 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 17 Jul 2018 15:29:00 +0300 Subject: a client request body is buffered to a temporary file In-Reply-To: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> Message-ID: <20180717122900.GZ56558@mdounin.ru> Hello! On Tue, Jul 17, 2018 at 01:16:14PM +0300, Vladimir Sopot wrote: > Хотел бы предложить добавить размер сохраняемого тела в notice > "a client request body is buffered to a temporary file > /wwwroot/tmp/nginx/client_body_temp/0004405740”, типа “a client > request body (100Mb) is buffered to a temporary file > /wwwroot/tmp/nginx/client_body_temp/0004405740”. Просто, чтобы > понять, то ли пользователи пихают невпихуемое (и насколько) , то > ли client_body_buffer_size закручен неправильно. В общем случае размер тела запроса в момент логгирования сообщения про "client request body is buffered to a temporary file" - неизвестен. Так что по большому счёту информацию о размере тела запроса всё равно можно получить только из access-лога, настроив логгирование $content_length. Само сообщение стоит рассматривать скорее как напоминание о том, что это может иметь смысл сделать, если использование дисковой подсистемы для тел запросов не ожидается. Что до "пихают невпихуемое", то для этого есть директива client_max_body_size, по умолчанию 1 мегабайт. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Jul 17 13:06:46 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 17 Jul 2018 16:06:46 +0300 Subject: =?UTF-8?B?UmU6IG5neCBzc2wgY2VydGlmaWNhdGVzINCy0YvQt9GL0LLQsNC10YLRgdGPINC0?= =?UTF-8?B?0LDQttC1INC00LvRjyDRgdCw0LnRgtC+0LIg0LHQtdC3IHNzbA==?= In-Reply-To: <30653e70be022ca09ce72030e920de0f.NginxMailingListRussian@forum.nginx.org> References: <20180715221158.GS56558@mdounin.ru> <30653e70be022ca09ce72030e920de0f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20180717130646.GB56558@mdounin.ru> Hello! On Tue, Jul 17, 2018 at 02:40:18AM -0400, Ilya Evseev wrote: > А парсинг конфига - это операция по определению однопоточная? > Её никак не распараллелить? > Пользователи меняют настройки своих сайтов довольно часто, при этом > автоматически перестраивается конфиг nginx'a и вызывается nginx -t && nginx > -s reload. > Пока https был не в моде, это происходило мгновенно. > Когда https появится у всех, каждое перечитывание будет длиться по минуте и > дольше. > Перспектива малоприятная. Кажется, что для начала стоит избавится от двух лишних операций парсинга конфига, которые делает конструкция "nginx -t && nginx -s reload". Ибо при таком подходе - сначала "nginx -t" парсит и тестирует конфигурацию; - потом "nginx -s reload" парсит конфигурацию, чтобы получить из неё pid-файл, после чего отправляет сигнал работающему мастеру; - и наконец уже мастер парсит конфигурацию, и применяет её. Из всех этих действий нужно на самом деле только последнее. Если в конфигурации ошибка - мастер это обнаружит сам, и конфигурацию отклонит. Посылать сигнал мастеру можно и нужно напрямую, "kill -HUP `cat /path/to/nginx.pid`". -- Maxim Dounin http://mdounin.ru/ From vp7 на mail.ru Wed Jul 18 10:10:55 2018 From: vp7 на mail.ru (=?UTF-8?B?Vml0YWx5IFBvbm9tYXJldg==?=) Date: Wed, 18 Jul 2018 13:10:55 +0300 Subject: =?UTF-8?B?UmVbMl06IG5neCBzc2wgY2VydGlmaWNhdGVzINCy0YvQt9GL0LLQsNC10YLRgdGP?= =?UTF-8?B?INC00LDQttC1INC00LvRjyDRgdCw0LnRgtC+0LIg0LHQtdC3IHNzbA==?= In-Reply-To: <20180717130646.GB56558@mdounin.ru> References: <20180715221158.GS56558@mdounin.ru> <30653e70be022ca09ce72030e920de0f.NginxMailingListRussian@forum.nginx.org> <20180717130646.GB56558@mdounin.ru> Message-ID: <1531908655.327948131@f184.i.mail.ru> Добрый день. Насколько допустимо посылать HUP сразу всем процессам nginx при условии, что в данной виртуалке запущен только один демон nginx'а? Т.е. делать вот так: == killall -HUP nginx == >Вторник, 17 июля 2018, 16:07 +03:00 от Maxim Dounin : > >Hello! > >On Tue, Jul 17, 2018 at 02:40:18AM -0400, Ilya Evseev wrote: > >> А парсинг конфига - это операция по определению однопоточная? >> Её никак не распараллелить? >> Пользователи меняют настройки своих сайтов довольно часто, при этом >> автоматически перестраивается конфиг nginx'a и вызывается nginx -t && nginx >> -s reload. >> Пока https был не в моде, это происходило мгновенно. >> Когда https появится у всех, каждое перечитывание будет длиться по минуте и >> дольше. >> Перспектива малоприятная. > >Кажется, что для начала стоит избавится от двух лишних операций >парсинга конфига, которые делает конструкция "nginx -t && nginx -s >reload". Ибо при таком подходе > >- сначала "nginx -t" парсит и тестирует конфигурацию; > >- потом "nginx -s reload" парсит конфигурацию, чтобы получить >  из неё pid-файл, после чего отправляет сигнал работающему >  мастеру; > >- и наконец уже мастер парсит конфигурацию, и применяет её. > >Из всех этих действий нужно на самом деле только последнее. Если >в конфигурации ошибка - мастер это обнаружит сам, и конфигурацию >отклонит. Посылать сигнал мастеру можно и нужно напрямую, "kill >-HUP `cat /path/to/nginx.pid`". > >-- >Maxim Dounin >http://mdounin.ru/ >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru --- С уважением, Виталий ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex на vorona.com.ua Wed Jul 18 11:30:11 2018 From: alex на vorona.com.ua (Alex Vorona) Date: Wed, 18 Jul 2018 14:30:11 +0300 Subject: =?UTF-8?B?UmU6IG5neCBzc2wgY2VydGlmaWNhdGVzINCy0YvQt9GL0LLQsNC10YLRgdGPINC0?= =?UTF-8?B?0LDQttC1INC00LvRjyDRgdCw0LnRgtC+0LIg0LHQtdC3IHNzbA==?= In-Reply-To: <1531908655.327948131@f184.i.mail.ru> References: <20180715221158.GS56558@mdounin.ru> <30653e70be022ca09ce72030e920de0f.NginxMailingListRussian@forum.nginx.org> <20180717130646.GB56558@mdounin.ru> <1531908655.327948131@f184.i.mail.ru> Message-ID: <6aee3d72-2951-b07b-8445-1146708e2305@vorona.com.ua> Здравствуйте, 18.07.18 13:10, Vitaly Ponomarev wrote: > Добрый день. > > Насколько допустимо посылать HUP сразу всем процессам nginx при условии, что в данной виртуалке запущен только один демон nginx'а? > Т.е. делать вот так: > == > killall -HUP nginx > == pkill -f "nginx: master" -HUP Ну и/или другие критерии, позволяющие отличить master'а от worker'ов в списке процессов, такие как user pkill -u root nginx -HUP -- Alex Vorona From mdounin на mdounin.ru Wed Jul 18 12:09:59 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 18 Jul 2018 15:09:59 +0300 Subject: =?UTF-8?B?UmU6IG5neCBzc2wgY2VydGlmaWNhdGVzINCy0YvQt9GL0LLQsNC10YLRgdGPINC0?= =?UTF-8?B?0LDQttC1INC00LvRjyDRgdCw0LnRgtC+0LIg0LHQtdC3IHNzbA==?= In-Reply-To: <1531908655.327948131@f184.i.mail.ru> References: <20180715221158.GS56558@mdounin.ru> <30653e70be022ca09ce72030e920de0f.NginxMailingListRussian@forum.nginx.org> <20180717130646.GB56558@mdounin.ru> <1531908655.327948131@f184.i.mail.ru> Message-ID: <20180718120958.GF56558@mdounin.ru> Hello! On Wed, Jul 18, 2018 at 01:10:55PM +0300, Vitaly Ponomarev wrote: > Насколько допустимо посылать HUP сразу всем процессам nginx при > условии, что в данной виртуалке запущен только один демон > nginx'а? > Т.е. делать вот так: > == > killall -HUP nginx > == Конкретно HUP - рабочими процессами будет просто проигнорирован с соответствующими сообщениями в логах на уровне notice, каких-либо других последствий быть не должно. Но вообще я бы так делать не рекомендовал, особенно - в автоматическом режиме. Проще и правильнее воспользоваться pid-файлом, он специально для этого пишется. Это, в частности, позволит избежать неприятностей, если вдруг окажется, что nginx на самом деле запущен не один. Или же он в процессе обновления исполняемого файла, и соответственно мастер-процессов больше одного. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Jul 20 09:29:43 2018 From: nginx-forum на forum.nginx.org (nophear2) Date: Fri, 20 Jul 2018 05:29:43 -0400 Subject: =?UTF-8?B?0JTQvtCx0LDQstC40Lsg0LLRgtC+0YDQvtC5INGB0LDQudGCLCDQsCDQvtGC0Lo=?= =?UTF-8?B?0YDRi9Cy0LDQtdGC0YHRjyDQv9C+INCw0LTRgNC10YHRgyDQstGB0ZEg0YA=?= =?UTF-8?B?0LDQstC90L4g0YLQvtC70YzQutC+INC/0LXRgNCy0YvQuQ==?= Message-ID: Помогите плиз, даже не знаю в чём может быть косяк. Конфиг первого сайта в файле default: #------------------------ первый сайт server { listen 80 default_server; root /var/www/html; server_name site1.ru www.site1.ru; # доменные имена return 301 https://www.site1.ru$request_uri; # непосредственно редирект на https } server { listen 443 ssl; server_name site1.ru www.site1.ru; root /var/www/html; ssl_certificate /etc/ssl/site1.ru/site1_ru.crt; # файл цепочки сертификатов ssl_certificate_key /etc/ssl/site1.ru/5532697.key; # # передача запроса апачу location / { proxy_pass http://127.0.0.1:81/; # Порт на котором висит Apache proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300; proxy_redirect off; proxy_set_header Connection close; proxy_pass_header Content-Type; proxy_pass_header Content-Disposition; proxy_pass_header Content-Length; } } #------------------------ всё Да, сайт висит на apache по ssl. Конфиг второго: server { listen 80; server_name site2.ru www.site2.ru; root /home/site2/www; index index.html index.htm; location / { try_files $uri $uri/ =404; } } Пытаюсь заходить по site2.ru и происходит редирект на https site1. Что я сделал не так? Разумеется, на оба конфига лежат ссылки в /etc/nginx/sites-enabled Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280582,280582#msg-280582 From nginx-forum на forum.nginx.org Sat Jul 21 09:18:22 2018 From: nginx-forum на forum.nginx.org (Romano) Date: Sat, 21 Jul 2018 05:18:22 -0400 Subject: =?UTF-8?B?0JzQtdGF0LDQvdC40LfQvCDQvdCw0LfQvdCw0YfQtdC90LjRjyDQv9C10YDQtdC8?= =?UTF-8?B?0LXQvdC90L7QuSAkc3NsIHNlc3Npb24gaWQ=?= Message-ID: Насколько я понял, значение этой переменой доступно для конфигурации сервера после получения ssl-сессии из кеша, т.е. как минимум после повторного захода на сайт. Вопрос, каким образом спамеры "получают" идентификатор с первого захода ранее неизвестных адресов? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,280591,280591#msg-280591 From andrey на kopeyko.ru Sat Jul 21 10:36:58 2018 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Sat, 21 Jul 2018 13:36:58 +0300 Subject: =?UTF-8?B?UmU6INCc0LXRhdCw0L3QuNC30Lwg0L3QsNC30L3QsNGH0LXQvdC40Y8g0L/QtdGA?= =?UTF-8?B?0LXQvNC10L3QvdC+0LkgJHNzbCBzZXNzaW9uIGlk?= In-Reply-To: References: Message-ID: <72AD54D2-4F33-4103-8EA3-F00214EB5FB7@kopeyko.ru> Спаммеры получают его при установлении TLS-соединения. 21 июля 2018 г. 12:18:22 GMT+03:00, Romano пишет: >Насколько я понял, значение этой переменой доступно для конфигурации >сервера >после получения ssl-сессии из кеша, т.е. как минимум после повторного >захода >на сайт. > >Вопрос, каким образом спамеры "получают" идентификатор с первого захода >ранее неизвестных адресов? > >Posted at Nginx Forum: >https://forum.nginx.org/read.php?21,280591,280591#msg-280591 > >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Простите за краткость, создано в K-9 Mail. From uncleandyv на gmail.com Sun Jul 22 19:48:33 2018 From: uncleandyv на gmail.com (Andrey Velikoredchanin) Date: Sun, 22 Jul 2018 22:48:33 +0300 Subject: =?UTF-8?B?R3ppcCArIGh0dHBzOiDQtdGB0YLRjC3Qu9C4INGB0LzRi9GB0Ls/?= Message-ID: Всем привет! Извиняюсь если вопрос древний (а у меня есть такое подозрение), но почему-то не смог найти информацию о том, имеет-ли смысл включать gzip для статики если сайт работает через https? Я помню что что-то об этом слышал, но, как уже отметил - не смог найти подтверждения этому. Спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Sun Jul 22 22:59:02 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 23 Jul 2018 01:59:02 +0300 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: References: Message-ID: <20180722225902.GT56558@mdounin.ru> Hello! On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey Velikoredchanin wrote: > Извиняюсь если вопрос древний (а у меня есть такое подозрение), но > почему-то не смог найти информацию о том, имеет-ли смысл включать gzip для > статики если сайт работает через https? Я помню что что-то об этом слышал, > но, как уже отметил - не смог найти подтверждения этому. Есть. Одно время люди из мира SSL/TLS пытались продвигать сжатие на уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы они и не пытались, и б) делает динамический контент уязвимым к атакам, см. https://en.wikipedia.org/wiki/CRIME. Так что nginx всегда запрещает сжатие на уровне SSL. -- Maxim Dounin http://mdounin.ru/ From uncleandyv на gmail.com Mon Jul 23 05:57:08 2018 From: uncleandyv на gmail.com (Andrey Velikoredchanin) Date: Mon, 23 Jul 2018 08:57:08 +0300 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: <20180722225902.GT56558@mdounin.ru> References: <20180722225902.GT56558@mdounin.ru> Message-ID: Максим, спасибо за ответ! Однако, он не совсем прояснил ситуацию. Попробую переформулировать... 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не рекомендуется, т.к. есть проблемы с безопасностью. 2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к. это НЕ внутреннее сжатие SSL. Я правильно понял? 23 июля 2018 г., 1:59 пользователь Maxim Dounin написал: > Hello! > > On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey Velikoredchanin wrote: > > > Извиняюсь если вопрос древний (а у меня есть такое подозрение), но > > почему-то не смог найти информацию о том, имеет-ли смысл включать gzip > для > > статики если сайт работает через https? Я помню что что-то об этом > слышал, > > но, как уже отметил - не смог найти подтверждения этому. > > Есть. > > Одно время люди из мира SSL/TLS пытались продвигать сжатие на > уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы они и не > пытались, и б) делает динамический контент уязвимым к атакам, см. > https://en.wikipedia.org/wiki/CRIME. Так что nginx всегда > запрещает сжатие на уровне SSL. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Mon Jul 23 06:57:05 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 23 Jul 2018 11:57:05 +0500 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: References: <20180722225902.GT56558@mdounin.ru> Message-ID: пн, 23 июл. 2018 г. в 10:57, Andrey Velikoredchanin : > Максим, спасибо за ответ! > > Однако, он не совсем прояснил ситуацию. Попробую переформулировать... > > 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не > рекомендуется, т.к. есть проблемы с безопасностью. > 2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к. > это НЕ внутреннее сжатие SSL. > пасьянс на самом деле более запутанный. gzip жмет тело ответа, но не заголовки. SSL теоретически, жмет в том числе заголовки (но ssl компрессия выключена при сборке nginx по причинам безопасности) в качестве вишенки на торте - http2, у него есть свои механизмы для минификации трафика (в том числе сжатые заголовки). если включать ssl компрессию, надо аккуратно, на ответах порядка 1Кб у нее по опыту отрицательный выигрыш > > Я правильно понял? > > 23 июля 2018 г., 1:59 пользователь Maxim Dounin > написал: > >> Hello! >> >> On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey Velikoredchanin wrote: >> >> > Извиняюсь если вопрос древний (а у меня есть такое подозрение), но >> > почему-то не смог найти информацию о том, имеет-ли смысл включать gzip >> для >> > статики если сайт работает через https? Я помню что что-то об этом >> слышал, >> > но, как уже отметил - не смог найти подтверждения этому. >> >> Есть. >> >> Одно время люди из мира SSL/TLS пытались продвигать сжатие на >> уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы они и не >> пытались, и б) делает динамический контент уязвимым к атакам, см. >> https://en.wikipedia.org/wiki/CRIME. Так что nginx всегда >> запрещает сжатие на уровне SSL. >> >> -- >> Maxim Dounin >> http://mdounin.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 uncleandyv на gmail.com Mon Jul 23 07:03:06 2018 From: uncleandyv на gmail.com (Andrey Velikoredchanin) Date: Mon, 23 Jul 2018 10:03:06 +0300 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: References: <20180722225902.GT56558@mdounin.ru> Message-ID: У меня основная цель - текстовую статику жать: html, css, js (в среднем все больше 1Кб). Для этого имеет смысл включать gzip под ssl? 23 июля 2018 г., 9:57 пользователь Илья Шипицин написал: > > > пн, 23 июл. 2018 г. в 10:57, Andrey Velikoredchanin >: > >> Максим, спасибо за ответ! >> >> Однако, он не совсем прояснил ситуацию. Попробую переформулировать... >> >> 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не >> рекомендуется, т.к. есть проблемы с безопасностью. >> 2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к. >> это НЕ внутреннее сжатие SSL. >> > > пасьянс на самом деле более запутанный. > > gzip жмет тело ответа, но не заголовки. SSL теоретически, жмет в том числе > заголовки (но ssl компрессия выключена при сборке nginx по причинам > безопасности) > в качестве вишенки на торте - http2, у него есть свои механизмы для > минификации трафика (в том числе сжатые заголовки). > > если включать ssl компрессию, надо аккуратно, на ответах порядка 1Кб у нее > по опыту отрицательный выигрыш > > >> >> Я правильно понял? >> >> 23 июля 2018 г., 1:59 пользователь Maxim Dounin >> написал: >> >>> Hello! >>> >>> On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey Velikoredchanin wrote: >>> >>> > Извиняюсь если вопрос древний (а у меня есть такое подозрение), но >>> > почему-то не смог найти информацию о том, имеет-ли смысл включать gzip >>> для >>> > статики если сайт работает через https? Я помню что что-то об этом >>> слышал, >>> > но, как уже отметил - не смог найти подтверждения этому. >>> >>> Есть. >>> >>> Одно время люди из мира SSL/TLS пытались продвигать сжатие на >>> уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы они и не >>> пытались, и б) делает динамический контент уязвимым к атакам, см. >>> https://en.wikipedia.org/wiki/CRIME. Так что nginx всегда >>> запрещает сжатие на уровне SSL. >>> >>> -- >>> Maxim Dounin >>> http://mdounin.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Mon Jul 23 07:11:47 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 23 Jul 2018 12:11:47 +0500 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: References: <20180722225902.GT56558@mdounin.ru> Message-ID: пн, 23 июл. 2018 г. в 12:03, Andrey Velikoredchanin : > У меня основная цель - текстовую статику жать: html, css, js (в среднем > все больше 1Кб). Для этого имеет смысл включать gzip под ssl? > в общем случае - не имеет (потому что есть проблемы с безопасностью) в конкретно вашем - исследуйте )) > > 23 июля 2018 г., 9:57 пользователь Илья Шипицин > написал: > >> >> >> пн, 23 июл. 2018 г. в 10:57, Andrey Velikoredchanin > >: >> >>> Максим, спасибо за ответ! >>> >>> Однако, он не совсем прояснил ситуацию. Попробую переформулировать... >>> >>> 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не >>> рекомендуется, т.к. есть проблемы с безопасностью. >>> 2. Включать "gzip on;" для статического контента под SSL есть смысл, >>> т.к. это НЕ внутреннее сжатие SSL. >>> >> >> пасьянс на самом деле более запутанный. >> >> gzip жмет тело ответа, но не заголовки. SSL теоретически, жмет в том >> числе заголовки (но ssl компрессия выключена при сборке nginx по причинам >> безопасности) >> в качестве вишенки на торте - http2, у него есть свои механизмы для >> минификации трафика (в том числе сжатые заголовки). >> >> если включать ssl компрессию, надо аккуратно, на ответах порядка 1Кб у >> нее по опыту отрицательный выигрыш >> >> >>> >>> Я правильно понял? >>> >>> 23 июля 2018 г., 1:59 пользователь Maxim Dounin >>> написал: >>> >>>> Hello! >>>> >>>> On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey Velikoredchanin wrote: >>>> >>>> > Извиняюсь если вопрос древний (а у меня есть такое подозрение), но >>>> > почему-то не смог найти информацию о том, имеет-ли смысл включать >>>> gzip для >>>> > статики если сайт работает через https? Я помню что что-то об этом >>>> слышал, >>>> > но, как уже отметил - не смог найти подтверждения этому. >>>> >>>> Есть. >>>> >>>> Одно время люди из мира SSL/TLS пытались продвигать сжатие на >>>> уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы они и не >>>> пытались, и б) делает динамический контент уязвимым к атакам, см. >>>> https://en.wikipedia.org/wiki/CRIME. Так что nginx всегда >>>> запрещает сжатие на уровне SSL. >>>> >>>> -- >>>> Maxim Dounin >>>> http://mdounin.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 >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From constantine на mellodesign.ru Mon Jul 23 09:18:49 2018 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Mon, 23 Jul 2018 12:18:49 +0300 Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCIFNOSSDQuCBodHRwMg==?= Message-ID: Здравствуйте! Нужна ваша помощь. Ситауция такая, пытаюсь использовать sni на одном сервере. Домены download.*.net и upload.*.net в браузере открываются. Ssllabs покзывает A+ по домену upload.*.net, в разделе Certificate #1 все нормально, но в разделе Certificate #2 no SNI и указывает на домен download.*.net Common names download.*.net Alternative names download.*.net *MISMATCH* Centos 6.9 nginx 1.15.1 (с включенной поддержкой SNI) openssl OpenSSL 1.0.1e-fips 11 Feb 2013 вроде все должно работать Ну и http2 тоже не рабоатет, в браузере ответ http1.1. Сравнивал включенные модули с другм сервером, где http2 работает, и вроде все необходимые имеются. В чем может быть причина или в какую хоть сторону копать? -- С уважением, Константин! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From koticka на mail.ru Mon Jul 23 11:15:44 2018 From: koticka на mail.ru (Kostya Alexandrov) Date: Mon, 23 Jul 2018 14:15:44 +0300 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: References: <20180722225902.GT56558@mdounin.ru> Message-ID: 2. Да. Имеет полный. Посмотрите так же в сторону http://nginx.org/ru/docs/http/ngx_http_gzip_static_module.html On 23/07/2018 10:03, Andrey Velikoredchanin wrote: > У меня основная цель - текстовую статику жать: html, css, js (в > среднем все больше 1Кб). Для этого имеет смысл включать gzip под ssl? > > 23 июля 2018 г., 9:57 пользователь Илья Шипицин > написал: > > > > пн, 23 июл. 2018 г. в 10:57, Andrey Velikoredchanin > >: > > Максим, спасибо за ответ! > > Однако, он не совсем прояснил ситуацию. Попробую > переформулировать... > > 1. Есть некий механизм сжатия, встроенный в SSL. Его > использовать не рекомендуется, т.к. есть проблемы с > безопасностью. > 2. Включать "gzip on;" для статического контента под SSL есть > смысл, т.к. это НЕ внутреннее сжатие SSL. > > > пасьянс на самом деле более запутанный. > > gzip жмет тело ответа, но не заголовки. SSL теоретически, жмет в > том числе заголовки (но ssl компрессия выключена при сборке nginx > по причинам безопасности) > в качестве вишенки на торте - http2, у него есть свои механизмы > для минификации трафика (в том числе сжатые заголовки). > > если включать ssl компрессию, надо аккуратно, на ответах порядка > 1Кб у нее по опыту отрицательный выигрыш > > > Я правильно понял? > > 23 июля 2018 г., 1:59 пользователь Maxim Dounin > > написал: > > Hello! > > On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey > Velikoredchanin wrote: > > > Извиняюсь если вопрос древний (а у меня есть такое > подозрение), но > > почему-то не смог найти информацию о том, имеет-ли смысл > включать gzip для > > статики если сайт работает через https? Я помню что > что-то об этом слышал, > > но, как уже отметил - не смог найти подтверждения этому. > > Есть. > > Одно время люди из мира SSL/TLS пытались продвигать сжатие на > уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы > они и не > пытались, и б) делает динамический контент уязвимым к > атакам, см. > https://en.wikipedia.org/wiki/CRIME > . Так что nginx всегда > запрещает сжатие на уровне SSL. > > -- > Maxim Dounin > http://mdounin.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 > > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen на yandex.ru Mon Jul 23 12:03:21 2018 From: annulen на yandex.ru (Konstantin Tokarev) Date: Mon, 23 Jul 2018 15:03:21 +0300 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: References: <20180722225902.GT56558@mdounin.ru> Message-ID: <17782051532347401@sas1-fb8a605c4548.qloud-c.yandex.net> 23.07.2018, 10:12, "Илья Шипицин" : > пн, 23 июл. 2018 г. в 12:03, Andrey Velikoredchanin : >> У меня основная цель - текстовую статику жать: html, css, js (в среднем все больше 1Кб). Для этого имеет смысл включать gzip под ssl? > > в общем случае - не имеет (потому что есть проблемы с безопасностью) директива gzip не имеет отношения к сжатию уровня SSL, так что проблем нет > в конкретно вашем - исследуйте )) > >> 23 июля 2018 г., 9:57 пользователь Илья Шипицин написал: >>> пн, 23 июл. 2018 г. в 10:57, Andrey Velikoredchanin : >>>> Максим, спасибо за ответ! >>>> >>>> Однако, он не совсем прояснил ситуацию. Попробую переформулировать... >>>> >>>> 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не рекомендуется, т.к. есть проблемы с безопасностью. >>>> 2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к. это НЕ внутреннее сжатие SSL. >>> >>> пасьянс на самом деле более запутанный. >>> >>> gzip жмет тело ответа, но не заголовки. SSL теоретически, жмет в том числе заголовки (но ssl компрессия выключена при сборке nginx по причинам безопасности) >>> в качестве вишенки на торте - http2, у него есть свои механизмы для минификации трафика (в том числе сжатые заголовки). >>> >>> если включать ssl компрессию, надо аккуратно, на ответах порядка 1Кб у нее по опыту отрицательный выигрыш >>> >>>> Я правильно понял? >>>> >>>> 23 июля 2018 г., 1:59 пользователь Maxim Dounin написал: >>>>> Hello! >>>>> >>>>> On Sun, Jul 22, 2018 at 10:48:33PM +0300, Andrey Velikoredchanin wrote: >>>>> >>>>>> Извиняюсь если вопрос древний (а у меня есть такое подозрение), но >>>>>> почему-то не смог найти информацию о том, имеет-ли смысл включать gzip для >>>>>> статики если сайт работает через https? Я помню что что-то об этом слышал, >>>>>> но, как уже отметил - не смог найти подтверждения этому. >>>>> >>>>> Есть. >>>>> >>>>> Одно время люди из мира SSL/TLS пытались продвигать сжатие на >>>>> уровне SSL/TLS, но оно а) ест столько памяти, что лучше бы они и не >>>>> пытались, и б) делает динамический контент уязвимым к атакам, см. >>>>> https://en.wikipedia.org/wiki/CRIME.  Так что nginx всегда >>>>> запрещает сжатие на уровне SSL. >>>>> >>>>> -- >>>>> Maxim Dounin >>>>> http://mdounin.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 >> _______________________________________________ >> 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 --  Regards, Konstantin From mdounin на mdounin.ru Mon Jul 23 12:34:48 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 23 Jul 2018 15:34:48 +0300 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: References: <20180722225902.GT56558@mdounin.ru> Message-ID: <20180723123448.GV56558@mdounin.ru> Hello! On Mon, Jul 23, 2018 at 08:57:08AM +0300, Andrey Velikoredchanin wrote: > Однако, он не совсем прояснил ситуацию. Попробую переформулировать... > > 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не > рекомендуется, т.к. есть проблемы с безопасностью. Всё так. Именно из-за наличия этого механизма могло быть "что-то об этом слышал" в контексте SSL - одно время были попытки пропагандировать идею "gzip в HTTP не нужен, если есть сжатие на уровне SSL/TLS". В современном мире этот механизм не используется, соответственно использование gzip'а ничем не отличается от такового в случае отсутствия SSL. > 2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к. > это НЕ внутреннее сжатие SSL. Да, использование gzip'а для статического контента в случае SSL ничем не отличается от такового в случае без SSL. Если выигрыш есть - сжатие стоит использовать, если нет - не стоит. Если статика меняется редко, можно подумать об использовании gzip_static вместо gzip. > Я правильно понял? Да. Отмечу также, что в случае динамического контента и SSL проблема использования gzip приобретает дополнительные нюансы, так как результат может быть опять же уязвим к атакам, см. https://en.wikipedia.org/wiki/BREACH. -- Maxim Dounin http://mdounin.ru/ From uncleandyv на gmail.com Mon Jul 23 12:38:58 2018 From: uncleandyv на gmail.com (Andrey Velikoredchanin) Date: Mon, 23 Jul 2018 15:38:58 +0300 Subject: =?UTF-8?B?UmU6IEd6aXAgKyBodHRwczog0LXRgdGC0Ywt0LvQuCDRgdC80YvRgdC7Pw==?= In-Reply-To: <20180723123448.GV56558@mdounin.ru> References: <20180722225902.GT56558@mdounin.ru> <20180723123448.GV56558@mdounin.ru> Message-ID: Ясно. Спасибо всем за пояснения! 23 июля 2018 г., 15:34 пользователь Maxim Dounin написал: > Hello! > > On Mon, Jul 23, 2018 at 08:57:08AM +0300, Andrey Velikoredchanin wrote: > > > Однако, он не совсем прояснил ситуацию. Попробую переформулировать... > > > > 1. Есть некий механизм сжатия, встроенный в SSL. Его использовать не > > рекомендуется, т.к. есть проблемы с безопасностью. > > Всё так. Именно из-за наличия этого механизма могло быть "что-то > об этом слышал" в контексте SSL - одно время были попытки > пропагандировать идею "gzip в HTTP не нужен, если есть сжатие на > уровне SSL/TLS". В современном мире этот механизм не > используется, соответственно использование gzip'а ничем не > отличается от такового в случае отсутствия SSL. > > > 2. Включать "gzip on;" для статического контента под SSL есть смысл, т.к. > > это НЕ внутреннее сжатие SSL. > > Да, использование gzip'а для статического контента в случае SSL > ничем не отличается от такового в случае без SSL. Если выигрыш > есть - сжатие стоит использовать, если нет - не стоит. Если > статика меняется редко, можно подумать об использовании > gzip_static вместо gzip. > > > Я правильно понял? > > Да. > > Отмечу также, что в случае динамического контента и SSL проблема > использования gzip приобретает дополнительные нюансы, так как > результат может быть опять же уязвим к атакам, см. > https://en.wikipedia.org/wiki/BREACH. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex на vorona.com.ua Mon Jul 23 12:59:08 2018 From: alex на vorona.com.ua (Alex Vorona) Date: Mon, 23 Jul 2018 15:59:08 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBTTkkg0LggaHR0cDI=?= In-Reply-To: References: Message-ID: <33a592d4-e18e-eeda-a9cf-77542721d016@vorona.com.ua> Здравствуйте, 23.07.18 12:18, Константин Ткаченко wrote: > openssl OpenSSL 1.0.1e-fips 11 Feb 2013 [...] > В чем может быть причина или в какую хоть сторону копать? Для начала - версия openssl. Для http2 ALPN нужна 1.0.2+ -- Alex Vorona From constantine на mellodesign.ru Mon Jul 23 13:07:44 2018 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Mon, 23 Jul 2018 16:07:44 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBTTkkg0LggaHR0cDI=?= In-Reply-To: <33a592d4-e18e-eeda-a9cf-77542721d016@vorona.com.ua> References: <33a592d4-e18e-eeda-a9cf-77542721d016@vorona.com.ua> Message-ID: 23 июля 2018 г., 15:59 пользователь Alex Vorona написал: > Здравствуйте, > > 23.07.18 12:18, Константин Ткаченко wrote: > > openssl OpenSSL 1.0.1e-fips 11 Feb 2013 >> > > [...] > >> В чем может быть причина или в какую хоть сторону копать? >> > > Для начала - версия openssl. Для http2 ALPN нужна 1.0.2+ > > -- > Alex Vorona > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru >Для начала - версия openssl. Для http2 ALPN нужна 1.0.2+ Хорошо, этот вопрос снимается. А SNI почему не работает? Или работает, но есть нюанс? -- С уважением, Константин! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Jul 23 14:44:49 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 23 Jul 2018 17:44:49 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBTTkkg0LggaHR0cDI=?= In-Reply-To: References: <33a592d4-e18e-eeda-a9cf-77542721d016@vorona.com.ua> Message-ID: <20180723144449.GW56558@mdounin.ru> Hello! On Mon, Jul 23, 2018 at 04:07:44PM +0300, Константин Ткаченко wrote: [...] > А SNI почему не работает? Или работает, но есть нюанс? Работает или не работает SNI - проще и правильнее всего проверять с помощью "openssl s_client -connect
-servername ". -- Maxim Dounin http://mdounin.ru/ From constantine на mellodesign.ru Tue Jul 24 08:46:06 2018 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Tue, 24 Jul 2018 11:46:06 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBTTkkg0LggaHR0cDI=?= In-Reply-To: <20180723144449.GW56558@mdounin.ru> References: <33a592d4-e18e-eeda-a9cf-77542721d016@vorona.com.ua> <20180723144449.GW56558@mdounin.ru> Message-ID: [...] >Работает или не работает SNI - проще и правильнее всего проверять >с помощью "openssl s_client -connect
-servername ". Погуглил куда смотреть, в openssl, вроде все нормально. Всем спасибо! -- С уважением, Константин! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.barut на gmail.com Tue Jul 24 09:25:02 2018 From: alex.barut на gmail.com (Alex Beljanski) Date: Tue, 24 Jul 2018 12:25:02 +0300 Subject: =?UTF-8?B?YXV0aF9yZXF1ZXN0INC4INC+0YjQuNCx0LrQuA==?= Message-ID: Добрый день! Хотим добавить определенной логики через auth_request, но не сломать основной функционал сайта. Для этого объявили location и подняли пока вирт хост на 127.0.0.1 с заглушкой в виде return 200 на все запросы. Иногда по некоторым запросам видим ошибки: auth request unexpected status: 504 while sending response to client В логах вирт хоста не видно чтобы запрос до него долетал по локейшену в котором была 504-ошибка. Подскажите, я ведь правильно понимаю, что пока мы пытались сходить авторизовать запрос, бекенд уже ответил 504 ошибкой и поэтому в логах такая запись? Или произошло что-то странное и auth_request не смог сходить в 127.0.0.1? Или вообще это что-то другое и не туда смотрю? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From constantine на mellodesign.ru Tue Jul 24 12:01:16 2018 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Tue, 24 Jul 2018 15:01:16 +0300 Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQvtGI0LjQsdC60Lg=?= In-Reply-To: References: Message-ID: > > Добрый день! > > Хотим добавить определенной логики через auth_request, но не сломать > основной функционал сайта. Для этого объявили location и подняли пока вирт > хост на 127.0.0.1 с заглушкой в виде return 200 на все запросы. Иногда по > некоторым запросам видим ошибки: > > auth request unexpected status: 504 while sending response to client > > В логах вирт хоста не видно чтобы запрос до него долетал по локейшену в > котором была 504-ошибка. > Подскажите, я ведь правильно понимаю, что пока мы пытались сходить > авторизовать запрос, бекенд уже ответил 504 ошибкой и поэтому в логах такая > запись? > Или произошло что-то странное и auth_request не смог сходить в 127.0.0.1? > Или вообще это что-то другое и не туда смотрю? > > Сокрее всего auth_request не смог достучаться до 127.0.0.1. Также, думаю, пример конфига не помешал бы. -- С уважением, Константин! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jul 24 13:28:40 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 24 Jul 2018 16:28:40 +0300 Subject: nginx-1.15.2 Message-ID: <20180724132840.GG56558@mdounin.ru> Изменения в nginx 1.15.2 24.07.2018 *) Добавление: переменная $ssl_preread_protocol в модуле ngx_stream_ssl_preread_module. *) Добавление: теперь при использовании директивы reset_timedout_connection nginx сбрасывает соединения, закрываемые с кодом 444. *) Изменение: уровень логгирования ошибок SSL "http request", "https proxy request", "unsupported protocol" и "version too low" понижен с уровня crit до info. *) Исправление: запросы к DNS-серверу не отправлялись повторно, если при первой попытке отправки происходила ошибка. *) Исправление: параметр reuseport директивы listen игнорировался, если количество рабочих процессов было задано после директивы listen. *) Исправление: при использовании OpenSSL 1.1.0 и новее директиву ssl_prefer_server_ciphers нельзя было выключить в виртуальном сервере, если она была включена в сервере по умолчанию. *) Исправление: повторное использование SSL-сессий к бэкендам не работало с протоколом TLS 1.3. -- Maxim Dounin http://nginx.org/ From alex на vorona.com.ua Tue Jul 24 17:54:25 2018 From: alex на vorona.com.ua (Alex Vorona) Date: Tue, 24 Jul 2018 20:54:25 +0300 Subject: nginx-1.15.2 In-Reply-To: <20180724132840.GG56558@mdounin.ru> References: <20180724132840.GG56558@mdounin.ru> Message-ID: <79841783-c48c-c360-9869-ec5c50959751@vorona.com.ua> Здравствуйте, 24.07.18 16:28, Maxim Dounin wrote: [...] > *) Исправление: параметр reuseport директивы listen игнорировался, если > количество рабочих процессов было задано после директивы listen. То есть context main, в котором задается количество рабочих процессов, обрабатывался при парсинге конфигурации не полностью до того, как начинали обрабатываться context'ы http, mail и другие ? Или это проявлялось только при переопределении через -g ? -- Alex Vorona From mdounin на mdounin.ru Tue Jul 24 18:11:53 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 24 Jul 2018 21:11:53 +0300 Subject: nginx-1.15.2 In-Reply-To: <79841783-c48c-c360-9869-ec5c50959751@vorona.com.ua> References: <20180724132840.GG56558@mdounin.ru> <79841783-c48c-c360-9869-ec5c50959751@vorona.com.ua> Message-ID: <20180724181153.GJ56558@mdounin.ru> Hello! On Tue, Jul 24, 2018 at 08:54:25PM +0300, Alex Vorona wrote: > 24.07.18 16:28, Maxim Dounin wrote: > [...] > > *) Исправление: параметр reuseport директивы listen игнорировался, если > > количество рабочих процессов было задано после директивы listen. > > То есть context main, в котором задается количество рабочих процессов, > обрабатывался при парсинге конфигурации не полностью до того, как > начинали обрабатываться context'ы http, mail и другие ? Или это > проявлялось только при переопределении через -g ? Контекст main - продолжается до окончания конфигурационного файла, и при большом желании директиву worker_processes можно указать после блока http: events { } http { server { listen 80 reuseport; ... } } worker_processes 4; В общем случае порядок директив не важен, всё должно работать корректно при любом порядке. В том числе и в данном случае - не важен порядок директив http и worker_processes. -- Maxim Dounin http://mdounin.ru/ From jd на jdwuzhere.ru Thu Jul 26 05:57:17 2018 From: jd на jdwuzhere.ru (Vladimir Sopot) Date: Thu, 26 Jul 2018 08:57:17 +0300 Subject: a client request body is buffered to a temporary file In-Reply-To: <20180717122900.GZ56558@mdounin.ru> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> Message-ID: <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> Спасибо, настроили $content_length. Стало ещё страннее. При настройках client_max_body_size 100m; client_body_buffer_size 100m; client_body_in_file_only off; клиенты делает POST c $content_length=61554, 566069 и тд (немного, совсем мало) и в логе та же самая ошибка. Между этими двумя $content_length=6849049 прошёл без ошибок Бонус: время у событий в access_log-е на секунду больше, чем в error_log-е, запросы отловлен точно, они достаточно редкие. # /usr/local/nginx/sbin/nginx -V nginx version: nginx/1.15.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --without-http_uwsgi_module --without-http_scgi_module --with-http_ssl_module --with-http_stub_status_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-file-aio --with-http_image_filter_module --with-http_realip_module --add-module=../ngx_cache_purge-2.3 --add-module=../ngx_http_geoip2_module > On 17 Jul 2018, at 15:29, Maxim Dounin wrote: > > Hello! > > On Tue, Jul 17, 2018 at 01:16:14PM +0300, Vladimir Sopot wrote: > >> Хотел бы предложить добавить размер сохраняемого тела в notice >> "a client request body is buffered to a temporary file >> /wwwroot/tmp/nginx/client_body_temp/0004405740”, типа “a client >> request body (100Mb) is buffered to a temporary file >> /wwwroot/tmp/nginx/client_body_temp/0004405740”. Просто, чтобы >> понять, то ли пользователи пихают невпихуемое (и насколько) , то >> ли client_body_buffer_size закручен неправильно. > > В общем случае размер тела запроса в момент логгирования сообщения > про "client request body is buffered to a temporary file" - > неизвестен. Так что по большому счёту информацию о размере тела > запроса всё равно можно получить только из access-лога, настроив > логгирование $content_length. Само сообщение стоит рассматривать > скорее как напоминание о том, что это может иметь смысл сделать, > если использование дисковой подсистемы для тел запросов не > ожидается. > > Что до "пихают невпихуемое", то для этого есть директива > client_max_body_size, по умолчанию 1 мегабайт. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin на mdounin.ru Thu Jul 26 12:40:04 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 26 Jul 2018 15:40:04 +0300 Subject: a client request body is buffered to a temporary file In-Reply-To: <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> Message-ID: <20180726124004.GP56558@mdounin.ru> Hello! On Thu, Jul 26, 2018 at 08:57:17AM +0300, Vladimir Sopot wrote: > Спасибо, настроили $content_length. Стало ещё страннее. При настройках > > client_max_body_size 100m; > client_body_buffer_size 100m; > client_body_in_file_only off; > > клиенты делает POST c $content_length=61554, 566069 и тд > (немного, совсем мало) и в логе та же самая ошибка. Между этими > двумя $content_length=6849049 прошёл без ошибок Для начала - смотреть внимательно на то, 1) где обрабатывается запрос и действительно ли в соответствующем контексте, где происходит чтения тела запроса, указано "client_body_buffer_size 100m", а тело запроса при этом меньше; 2) что именно написано в сообщении. Про "buffered to a temporary file" много похожих сообщений - в частности, оно может быть про тело ответа. Если не прояснится - попробовать воспроизвести как минимум без "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди отваживаются использовать эту поделку, она при любых внутренних изменениях в nginx'е разносит всё же), а лучше - вообще без сторонних модулей. Если воспроизведётся - приносите подробности (конфиг и способ вызвать warning, либо debug log полученного warning'а). Интересует именно ситуация, когда warning выдаётся для случая размера запроса меньше client_body_buffer_size, такого быть не должно. > Бонус: время у событий в access_log-е на секунду больше, чем в > error_log-е, запросы отловлен точно, они достаточно редкие. Это нормально, warning логгируется в момент первой записи во временный файл, в access log же запрос попадает после его окончания. -- Maxim Dounin http://mdounin.ru/ From kpoxa на kpoxa.net Thu Jul 26 12:43:39 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 26 Jul 2018 15:43:39 +0300 Subject: =?UTF-8?B?bG9jYXRpb24gdnMgbWFwINC/0L4g0YHQutC+0YDQvtGB0YLRjA==?= Message-ID: Добрый день. А что будет по скорости быстрее работать, при ограничении доступа к определенным расширениям файлов (2-3 десятка расширений): location ~* \.(ext1|ext2|ext3)$ { deny all; } location / { //access granted } или map $uri $error { ~".ext1$" 403; ~".ext2$" 403; ~".ext3$" 403; } location / { if ($error = 403) { return 403; } } From gmm на csdoc.com Thu Jul 26 12:59:02 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 26 Jul 2018 15:59:02 +0300 Subject: proxy_cache_purge In-Reply-To: <20180726124004.GP56558@mdounin.ru> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> Message-ID: <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> On 26.07.2018 15:40, Maxim Dounin wrote: > Если не прояснится - попробовать воспроизвести как минимум без > "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди > отваживаются использовать эту поделку, она при любых внутренних > изменениях в nginx'е разносит всё же) Если не использовать этот кривой сторонний модуль ngx_cache_purge, то какие у пользователей open source версии nginx есть альтернативы? Директиву proxy_cache_purge можете сделать доступной в open source версии nginx? -- Best regards, Gena From mdounin на mdounin.ru Thu Jul 26 13:50:45 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 26 Jul 2018 16:50:45 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHZzIG1hcCDQv9C+INGB0LrQvtGA0L7RgdGC0Yw=?= In-Reply-To: References: Message-ID: <20180726135045.GS56558@mdounin.ru> Hello! On Thu, Jul 26, 2018 at 03:43:39PM +0300, kpoxa wrote: > Добрый день. > > А что будет по скорости быстрее работать, при ограничении доступа к > определенным расширениям файлов (2-3 десятка расширений): > > location ~* \.(ext1|ext2|ext3)$ { > deny all; > } > location / { > //access granted > } > > или > > map $uri $error { > ~".ext1$" 403; > ~".ext2$" 403; > ~".ext3$" 403; > } > location / { > if ($error = 403) { > return 403; > } > } Вот конкретно из этих двух примеров - быстрее будет работать совершенно точно первый, потому что во втором случае будет выполняться три разных регулярных выражения, а не одно, как в первом случае. В общем случае, когда используемые регулярные выражения одинаковы и в том и в другом варианте, наверное тоже location чуть выиграет за счёт отсутствия лишних операций с переменными и инструкций rewrite-модуля. Впрочем, я сильно сомневаюсь, что разница будет хоть как-то измерима по сравнению с собственно обработкой запроса даже в этом случае, не говоря уже про общий. Так что выбирать стоит скорее исходя из удобства поддержки всего этого хозяйства. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Thu Jul 26 14:07:50 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 26 Jul 2018 17:07:50 +0300 Subject: proxy_cache_purge In-Reply-To: <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> Message-ID: <20180726140750.GT56558@mdounin.ru> Hello! On Thu, Jul 26, 2018 at 03:59:02PM +0300, Gena Makhomed wrote: > On 26.07.2018 15:40, Maxim Dounin wrote: > > > Если не прояснится - попробовать воспроизвести как минимум без > > "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди > > отваживаются использовать эту поделку, она при любых внутренних > > изменениях в nginx'е разносит всё же) > > Если не использовать этот кривой сторонний модуль ngx_cache_purge, > то какие у пользователей open source версии nginx есть альтернативы? > > Директиву proxy_cache_purge > можете сделать доступной в open source версии nginx? Наиболее простая и правильная альтернатива - использовать механизмы cache expiration, существующие в HTTP. И, собственно, только эта альтернатива и работает в сколько-нибудь сложных случаях - потому что всем клиентам нельзя сказать purge. -- Maxim Dounin http://mdounin.ru/ From alex.barut на gmail.com Thu Jul 26 15:31:21 2018 From: alex.barut на gmail.com (Alex Beljanski) Date: Thu, 26 Jul 2018 18:31:21 +0300 Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQvtGI0LjQsdC60Lg=?= In-Reply-To: References: Message-ID: Отвечу сам себе. Внутренняя логика подложила свинью. Nginx иногда зацикливался блуждая по внутренним перенаправлениям в рамках подзапроса к локейшену из auth_request. В лог попадали сообщения что апстрим отвечал с кодом 200, но при этом в error_log была ошибка: upstream timed out (110: Connection timed out) while SSL handshaking to upstream ну и после этого auth request unexpected status: 504 while sending response to client Помог разобраться debug_connection. вт, 24 июл. 2018 г. в 15:01, Константин Ткаченко : > Добрый день! >> >> Хотим добавить определенной логики через auth_request, но не сломать >> основной функционал сайта. Для этого объявили location и подняли пока вирт >> хост на 127.0.0.1 с заглушкой в виде return 200 на все запросы. Иногда по >> некоторым запросам видим ошибки: >> >> auth request unexpected status: 504 while sending response to client >> >> В логах вирт хоста не видно чтобы запрос до него долетал по локейшену в >> котором была 504-ошибка. >> Подскажите, я ведь правильно понимаю, что пока мы пытались сходить >> авторизовать запрос, бекенд уже ответил 504 ошибкой и поэтому в логах такая >> запись? >> Или произошло что-то странное и auth_request не смог сходить в 127.0.0.1? >> Или вообще это что-то другое и не туда смотрю? >> >> > Сокрее всего auth_request не смог достучаться до 127.0.0.1. > Также, думаю, пример конфига не помешал бы. > > -- > С уважением, Константин! > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ru на nginx.com Thu Jul 26 20:42:44 2018 From: ru на nginx.com (Ruslan Ermilov) Date: Thu, 26 Jul 2018 23:42:44 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHZzIG1hcCDQv9C+INGB0LrQvtGA0L7RgdGC0Yw=?= In-Reply-To: <20180726135045.GS56558@mdounin.ru> References: <20180726135045.GS56558@mdounin.ru> Message-ID: <20180726204244.GA47117@lo0.su> On Thu, Jul 26, 2018 at 04:50:45PM +0300, Maxim Dounin wrote: > On Thu, Jul 26, 2018 at 03:43:39PM +0300, kpoxa wrote: > > > Добрый день. > > > > А что будет по скорости быстрее работать, при ограничении доступа к > > определенным расширениям файлов (2-3 десятка расширений): > > > > location ~* \.(ext1|ext2|ext3)$ { > > deny all; > > } > > location / { > > //access granted > > } > > > > или > > > > map $uri $error { > > ~".ext1$" 403; > > ~".ext2$" 403; > > ~".ext3$" 403; > > } > > location / { > > if ($error = 403) { > > return 403; > > } > > } > > Вот конкретно из этих двух примеров - быстрее будет работать > совершенно точно первый, потому что во втором случае будет > выполняться три разных регулярных выражения, а не одно, как в > первом случае. В общем случае, когда используемые регулярные > выражения одинаковы и в том и в другом варианте, наверное тоже > location чуть выиграет за счёт отсутствия лишних операций с > переменными и инструкций rewrite-модуля. > > Впрочем, я сильно сомневаюсь, что разница будет хоть как-то > измерима по сравнению с собственно обработкой запроса даже в этом > случае, не говоря уже про общий. Так что выбирать стоит скорее > исходя из удобства поддержки всего этого хозяйства. Возможно есть смысл добавить переменную? # HG changeset patch # User Ruslan Ermilov # Date 1532637590 -10800 # Thu Jul 26 23:39:50 2018 +0300 # Node ID 430d80baa550a753a26b1a06d8213ca0e0030176 # Parent f7e79596baf209151682f2f7d220161c034657ac Added $exten. diff --git a/src/http/ngx_http_variables.c b/src/http/ngx_http_variables.c --- a/src/http/ngx_http_variables.c +++ b/src/http/ngx_http_variables.c @@ -226,6 +226,10 @@ static ngx_http_variable_t ngx_http_cor offsetof(ngx_http_request_t, uri), NGX_HTTP_VAR_NOCACHEABLE, 0 }, + { ngx_string("exten"), NULL, ngx_http_variable_request, + offsetof(ngx_http_request_t, exten), + NGX_HTTP_VAR_NOCACHEABLE, 0 }, + { ngx_string("request"), NULL, ngx_http_variable_request_line, 0, 0, 0 }, { ngx_string("document_root"), NULL, From mdounin на mdounin.ru Thu Jul 26 23:55:53 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 27 Jul 2018 02:55:53 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHZzIG1hcCDQv9C+INGB0LrQvtGA0L7RgdGC0Yw=?= In-Reply-To: <20180726204244.GA47117@lo0.su> References: <20180726135045.GS56558@mdounin.ru> <20180726204244.GA47117@lo0.su> Message-ID: <20180726235553.GU56558@mdounin.ru> Hello! On Thu, Jul 26, 2018 at 11:42:44PM +0300, Ruslan Ermilov wrote: > On Thu, Jul 26, 2018 at 04:50:45PM +0300, Maxim Dounin wrote: > > On Thu, Jul 26, 2018 at 03:43:39PM +0300, kpoxa wrote: > > > > > Добрый день. > > > > > > А что будет по скорости быстрее работать, при ограничении доступа к > > > определенным расширениям файлов (2-3 десятка расширений): > > > > > > location ~* \.(ext1|ext2|ext3)$ { > > > deny all; > > > } > > > location / { > > > //access granted > > > } > > > > > > или > > > > > > map $uri $error { > > > ~".ext1$" 403; > > > ~".ext2$" 403; > > > ~".ext3$" 403; > > > } > > > location / { > > > if ($error = 403) { > > > return 403; > > > } > > > } > > > > Вот конкретно из этих двух примеров - быстрее будет работать > > совершенно точно первый, потому что во втором случае будет > > выполняться три разных регулярных выражения, а не одно, как в > > первом случае. В общем случае, когда используемые регулярные > > выражения одинаковы и в том и в другом варианте, наверное тоже > > location чуть выиграет за счёт отсутствия лишних операций с > > переменными и инструкций rewrite-модуля. > > > > Впрочем, я сильно сомневаюсь, что разница будет хоть как-то > > измерима по сравнению с собственно обработкой запроса даже в этом > > случае, не говоря уже про общий. Так что выбирать стоит скорее > > исходя из удобства поддержки всего этого хозяйства. > > Возможно есть смысл добавить переменную? > > # HG changeset patch > # User Ruslan Ermilov > # Date 1532637590 -10800 > # Thu Jul 26 23:39:50 2018 +0300 > # Node ID 430d80baa550a753a26b1a06d8213ca0e0030176 > # Parent f7e79596baf209151682f2f7d220161c034657ac > Added $exten. IMHO, скорее нет, чем да. -- Maxim Dounin http://mdounin.ru/ From postmaster на softsearch.ru Fri Jul 27 21:39:58 2018 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Sat, 28 Jul 2018 00:39:58 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIHZzIG1hcCDQv9C+INGB0LrQvtGA0L7RgdGC0Yw=?= In-Reply-To: References: Message-ID: <1065089353.20180728003958@softsearch.ru> Здравствуйте, kpoxa. perf даст больше полезной информации. > А что будет по скорости быстрее работать, при ограничении доступа к > определенным расширениям файлов (2-3 десятка расширений): -- С уважением, Михаил mailto:postmaster на softsearch.ru From iippolitov на nginx.com Mon Jul 30 11:06:28 2018 From: iippolitov на nginx.com (Igor A. Ippolitov) Date: Mon, 30 Jul 2018 14:06:28 +0300 Subject: proxy_cache_purge In-Reply-To: <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> Message-ID: Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в кэше (что и делает purge, в широком смысле). On 26.07.2018 15:59, Gena Makhomed wrote: > On 26.07.2018 15:40, Maxim Dounin wrote: > >> Если не прояснится - попробовать воспроизвести как минимум без >> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди >> отваживаются использовать эту поделку, она при любых внутренних >> изменениях в nginx'е разносит всё же) > > Если не использовать этот кривой сторонний модуль ngx_cache_purge, > то какие у пользователей open source версии nginx есть альтернативы? > > Директиву proxy_cache_purge > можете сделать доступной в open source версии nginx? > From gmm на csdoc.com Mon Jul 30 11:29:48 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 30 Jul 2018 14:29:48 +0300 Subject: proxy_cache_purge In-Reply-To: References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> Message-ID: <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> On 30.07.2018 14:06, Igor A. Ippolitov wrote: > Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в > кэше (что и делает purge, в широком смысле). Замещать существующий контент или добавлять новый - да. Но удалять не позволяет, в этом и состоит (небольшое) отличие. Вот поэтому и не понятно, почему нельзя сделать директиву proxy_cache_purge доступной в open source версии nginx? Могу ошибаться, но коммерческую версию nginx покупают скорее всего не из-за директивы proxy_cache_purge, а ради других возможностей. >>> Если не прояснится - попробовать воспроизвести как минимум без >>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди >>> отваживаются использовать эту поделку, она при любых внутренних >>> изменениях в nginx'е разносит всё же) >> Если не использовать этот кривой сторонний модуль ngx_cache_purge, >> то какие у пользователей open source версии nginx есть альтернативы? >> Директиву proxy_cache_purge >> можете сделать доступной в open source версии nginx? P.S. Please do not top-post. Answer: Because it turns the discussion up-side-down. Question: Why should I not top-post? -- Best regards, Gena From chipitsine на gmail.com Mon Jul 30 13:49:07 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 30 Jul 2018 18:49:07 +0500 Subject: proxy_cache_purge In-Reply-To: <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> Message-ID: пн, 30 июл. 2018 г. в 16:30, Gena Makhomed : > On 30.07.2018 14:06, Igor A. Ippolitov wrote: > > > Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в > > кэше (что и делает purge, в широком смысле). > > Замещать существующий контент или добавлять новый - да. > Но удалять не позволяет, в этом и состоит (небольшое) отличие. > > Вот поэтому и не понятно, почему нельзя сделать директиву > proxy_cache_purge доступной в open source версии nginx? > ответ, вероятно, вы знаете. nginx это действительно open source, но, как и для любого open source, есть некая политика, какие патчи принимаются, какие нет. есть люди, которые принимают решения, включать патч или не включать. и есть ваше право сделать форк :) было бы круто услышать от Максима Коновалова про политику в отношение nginx, какие патчи могут быть приняты. допустим, будет патч, который повторяет платную функциональность. да, я понимаю, что Максим не обязан отвечать, но буду благодарен, если он ответит > > Могу ошибаться, но коммерческую версию nginx покупают скорее всего > не из-за директивы proxy_cache_purge, а ради других возможностей. > > >>> Если не прояснится - попробовать воспроизвести как минимум без > >>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди > >>> отваживаются использовать эту поделку, она при любых внутренних > >>> изменениях в nginx'е разносит всё же) > > >> Если не использовать этот кривой сторонний модуль ngx_cache_purge, > >> то какие у пользователей open source версии nginx есть альтернативы? > > >> Директиву proxy_cache_purge > >> можете сделать доступной в open source версии nginx? > > P.S. > > Please do not top-post. > > Answer: Because it turns the discussion up-side-down. > > Question: Why should I not top-post? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From iippolitov на nginx.com Mon Jul 30 16:59:01 2018 From: iippolitov на nginx.com (Igor A. Ippolitov) Date: Mon, 30 Jul 2018 19:59:01 +0300 Subject: proxy_cache_purge In-Reply-To: <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> Message-ID: On 30.07.2018 14:29, Gena Makhomed wrote: > On 30.07.2018 14:06, Igor A. Ippolitov wrote: > >> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент >> в кэше (что и делает purge, в широком смысле). > > Замещать существующий контент или добавлять новый - да. > Но удалять не позволяет, в этом и состоит (небольшое) отличие. Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт клиенту? Почему бы не закэшить сразу его. Или условную болванку с max-age:0, которая будет обновлена по первому же запросу от клиента На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. может упростить жизнь в каких-то конфигурациях. > > Вот поэтому и не понятно, почему нельзя сделать директиву > proxy_cache_purge доступной в open source версии nginx? > > Могу ошибаться, но коммерческую версию nginx покупают скорее всего > не из-за директивы proxy_cache_purge, а ради других возможностей. > >>>> Если не прояснится - попробовать воспроизвести как минимум без >>>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди >>>> отваживаются использовать эту поделку, она при любых внутренних >>>> изменениях в nginx'е разносит всё же) > >>> Если не использовать этот кривой сторонний модуль ngx_cache_purge, >>> то какие у пользователей open source версии nginx есть альтернативы? > >>> Директиву proxy_cache_purge >>> можете сделать доступной в open source версии nginx? > > P.S. > > Please do not top-post. > > Answer: Because it turns the discussion up-side-down. > > Question: Why should I not top-post? > From jd на jdwuzhere.ru Mon Jul 30 21:24:10 2018 From: jd на jdwuzhere.ru (jd на jdwuzhere.ru) Date: Tue, 31 Jul 2018 00:24:10 +0300 Subject: proxy_cache_purge In-Reply-To: References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> Message-ID: <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru> > On 30 Jul 2018, at 19:59, Igor A. Ippolitov wrote: > >> On 30.07.2018 14:29, Gena Makhomed wrote: >>> On 30.07.2018 14:06, Igor A. Ippolitov wrote: >>> >>> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в кэше (что и делает purge, в широком смысле). >> >> Замещать существующий контент или добавлять новый - да. >> Но удалять не позволяет, в этом и состоит (небольшое) отличие. > Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт клиенту? Почему бы не закэшить сразу его. > Или условную болванку с max-age:0, которая будет обновлена по первому же запросу от клиента Погодите, я что-то потерялся. Есть профиль игрока, который не меняется неделями. Nginx всю неделю (TTL кэша) радостно отдаёт страницу профиля из этого кэша. Но однажды, игрок начинает играть в новое и профиль необходимо обновить. Как без purge сообщить nginx, что информация обновилась и надо сходить в backend за новой страницей, чтобы положить её в кэш до следующего прихода? > На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. может упростить жизнь в каких-то конфигурациях. >> >> Вот поэтому и не понятно, почему нельзя сделать директиву >> proxy_cache_purge доступной в open source версии nginx? >> >> Могу ошибаться, но коммерческую версию nginx покупают скорее всего >> не из-за директивы proxy_cache_purge, а ради других возможностей. >> >>>>> Если не прояснится - попробовать воспроизвести как минимум без >>>>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди >>>>> отваживаются использовать эту поделку, она при любых внутренних >>>>> изменениях в nginx'е разносит всё же) >> >>>> Если не использовать этот кривой сторонний модуль ngx_cache_purge, >>>> то какие у пользователей open source версии nginx есть альтернативы? >> >>>> Директиву proxy_cache_purge >>>> можете сделать доступной в open source версии nginx? >> >> P.S. >> >> Please do not top-post. >> >> Answer: Because it turns the discussion up-side-down. >> >> Question: Why should I not top-post? >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine на gmail.com Mon Jul 30 21:36:57 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 31 Jul 2018 02:36:57 +0500 Subject: proxy_cache_purge In-Reply-To: <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru> Message-ID: вт, 31 июл. 2018 г. в 2:24, : > > > > On 30 Jul 2018, at 19:59, Igor A. Ippolitov > wrote: > > > >> On 30.07.2018 14:29, Gena Makhomed wrote: > >>> On 30.07.2018 14:06, Igor A. Ippolitov wrote: > >>> > >>> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в > кэше (что и делает purge, в широком смысле). > >> > >> Замещать существующий контент или добавлять новый - да. > >> Но удалять не позволяет, в этом и состоит (небольшое) отличие. > > Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт > клиенту? Почему бы не закэшить сразу его. > > Или условную болванку с max-age:0, которая будет обновлена по первому же > запросу от клиента > > Погодите, я что-то потерялся. Есть профиль игрока, который не меняется > неделями. Nginx всю неделю (TTL кэша) радостно отдаёт страницу профиля из > этого кэша. Но однажды, игрок начинает играть в новое и профиль необходимо > обновить. Как без purge сообщить nginx, что информация обновилась и надо > сходить в backend за новой страницей, чтобы положить её в кэш до следующего > прихода? > канонический ответ - поменять url на новый уникальный (я не отстаиваю позицию, что пурж не нужен, в некоторых сценариях он действительно может улучшить жизнь) > > > На первый взгляд, PURGE не кажется необходимым средством. Хотя, > вероятно. может упростить жизнь в каких-то конфигурациях. > >> > >> Вот поэтому и не понятно, почему нельзя сделать директиву > >> proxy_cache_purge доступной в open source версии nginx? > >> > >> Могу ошибаться, но коммерческую версию nginx покупают скорее всего > >> не из-за директивы proxy_cache_purge, а ради других возможностей. > >> > >>>>> Если не прояснится - попробовать воспроизвести как минимум без > >>>>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди > >>>>> отваживаются использовать эту поделку, она при любых внутренних > >>>>> изменениях в nginx'е разносит всё же) > >> > >>>> Если не использовать этот кривой сторонний модуль ngx_cache_purge, > >>>> то какие у пользователей open source версии nginx есть альтернативы? > >> > >>>> Директиву proxy_cache_purge > >>>> можете сделать доступной в open source версии nginx? > >> > >> P.S. > >> > >> Please do not top-post. > >> > >> Answer: Because it turns the discussion up-side-down. > >> > >> Question: Why should I not top-post? > >> > > > > _______________________________________________ > > 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 jd на jdwuzhere.ru Tue Jul 31 01:23:42 2018 From: jd на jdwuzhere.ru (Vladimir Sopot) Date: Tue, 31 Jul 2018 04:23:42 +0300 Subject: proxy_cache_purge In-Reply-To: References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru> Message-ID: > On 31 Jul 2018, at 00:36, Илья Шипицин wrote: > > > > вт, 31 июл. 2018 г. в 2:24, >: > > > > On 30 Jul 2018, at 19:59, Igor A. Ippolitov > wrote: > > > >> On 30.07.2018 14:29, Gena Makhomed wrote: > >>> On 30.07.2018 14:06, Igor A. Ippolitov wrote: > >>> > >>> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в кэше (что и делает purge, в широком смысле). > >> > >> Замещать существующий контент или добавлять новый - да. > >> Но удалять не позволяет, в этом и состоит (небольшое) отличие. > > Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт клиенту? Почему бы не закэшить сразу его. > > Или условную болванку с max-age:0, которая будет обновлена по первому же запросу от клиента > > Погодите, я что-то потерялся. Есть профиль игрока, который не меняется неделями. Nginx всю неделю (TTL кэша) радостно отдаёт страницу профиля из этого кэша. Но однажды, игрок начинает играть в новое и профиль необходимо обновить. Как без purge сообщить nginx, что информация обновилась и надо сходить в backend за новой страницей, чтобы положить её в кэш до следующего прихода? > > канонический ответ - поменять url на новый уникальный Менять https://truetrophies.com/gamer/username на https://truetrophies.com/gamer/username125r3s0 ? Это как бы вообще не очень. > (я не отстаиваю позицию, что пурж не нужен, в некоторых сценариях он действительно может улучшить жизнь) > > > > На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. может упростить жизнь в каких-то конфигурациях. > >> > >> Вот поэтому и не понятно, почему нельзя сделать директиву > >> proxy_cache_purge доступной в open source версии nginx? > >> > >> Могу ошибаться, но коммерческую версию nginx покупают скорее всего > >> не из-за директивы proxy_cache_purge, а ради других возможностей. > >> > >>>>> Если не прояснится - попробовать воспроизвести как минимум без > >>>>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди > >>>>> отваживаются использовать эту поделку, она при любых внутренних > >>>>> изменениях в nginx'е разносит всё же) > >> > >>>> Если не использовать этот кривой сторонний модуль ngx_cache_purge, > >>>> то какие у пользователей open source версии nginx есть альтернативы? > >> > >>>> Директиву proxy_cache_purge > >>>> можете сделать доступной в open source версии nginx? > >> > >> P.S. > >> > >> Please do not top-post. > >> > >> Answer: Because it turns the discussion up-side-down. > >> > >> Question: Why should I not top-post? > >> > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на kinetiksoft.com Tue Jul 31 11:03:47 2018 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Tue, 31 Jul 2018 14:03:47 +0300 Subject: ignore long locked inactive cache entry Message-ID: <72b6774c-8fad-4ccf-c98d-9db9da49801f@kinetiksoft.com> Здравствуйте!  Регулярно в логах (пару раз за 5 минут) вижу [alert] 17816#17816: ignore long locked inactive cache entry 9100488b2180c1fc582384712a73791d, count:1 Две прокси на один бэкэнд. Бэкэнд - сервер nginx, отдающий статику. Прокси - два одинаковых сервера, в разных странах. Проявляется только на одном Настроена зоне кеширования proxy_cache_path /var/cache/nginx.hdd/archive_video levels=2:2 keys_zone=a_v:10m inactive=2d max_size=145g use_temp_path=off; В локейшене:                 proxy_buffer_size 128k;                 proxy_buffers 32 16k;                 proxy_set_header host backend;                 proxy_cache_valid 2d;                 proxy_cache_use_stale updating;                 proxy_cache_key "$proxy_host$uri$http_origin";                 proxy_cache_lock on; С чем может быть связано? Локейшен обрабатывает не вебсокеты, а статические файлы. Раньше вроде не замечал, не помню когда начало появляться. Читал в поиске, что это может быть связано с медленными ответами, но не понял откуда и куда. Между прокси и бэкэндов - гигабит, в логах бэкэнда медленных ответов не увидел. На проксях медленных ответов (больше 5 секунд) сильно больше, чем сабжевых записей в логах, но это понятно, могут быть пользователи с медленными каналами. nginx -V nginx version: nginx/1.14.0 built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) built with OpenSSL 1.1.0f  25 May 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.14.0/debian/debuild-base/nginx-1.14.0=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' С уважением, Иван. From iippolitov на nginx.com Tue Jul 31 11:54:50 2018 From: iippolitov на nginx.com (Igor A. Ippolitov) Date: Tue, 31 Jul 2018 14:54:50 +0300 Subject: proxy_cache_purge In-Reply-To: <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru> Message-ID: On 31.07.2018 00:24, jd на jdwuzhere.ru wrote: > >> On 30 Jul 2018, at 19:59, Igor A. Ippolitov wrote: >> >>> On 30.07.2018 14:29, Gena Makhomed wrote: >>>> On 30.07.2018 14:06, Igor A. Ippolitov wrote: >>>> >>>> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в кэше (что и делает purge, в широком смысле). >>> Замещать существующий контент или добавлять новый - да. >>> Но удалять не позволяет, в этом и состоит (небольшое) отличие. >> Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт клиенту? Почему бы не закэшить сразу его. >> Или условную болванку с max-age:0, которая будет обновлена по первому же запросу от клиента > Погодите, я что-то потерялся. Есть профиль игрока, который не меняется неделями. Nginx всю неделю (TTL кэша) радостно отдаёт страницу профиля из этого кэша. Но однажды, игрок начинает играть в новое и профиль необходимо обновить. Как без purge сообщить nginx, что информация обновилась и надо сходить в backend за новой страницей, чтобы положить её в кэш до следующего прихода? Как бы вы делали PURGE для профиля игрока? URL профиля вы знаете. Для PURGE вы бы "дёрнули" запрос, который удалит ненужный элемент и в следующий раз nginx перезапросит контент с апстрима. Этот запрос, обычно, приходит в отдельный location с нужными настройками: ключ кэша, права доступа, всякое такое. В моём подходе вы "дёргаете" такой же запрос в специальный location, который ходит в апстрим мимо кэша (proxy_cache_bypass). В разных вариациях, апстримом будет:     либо сам nginx, который отдаёт HTTP 200 и Cache-Control: max-age=0;     либо реальный апстрим, который отдаст актуальную копию данных В первом случае контент сразу "протухает" и его актуализируют на первом же запросе. Во-втором - сразу актуальный. В следущий раз, когда запросят профиль пользователя, nginx либо пойдёт в апстрим, либо отдаст актуальную кэшированную версию. > >> На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. может упростить жизнь в каких-то конфигурациях. >>> Вот поэтому и не понятно, почему нельзя сделать директиву >>> proxy_cache_purge доступной в open source версии nginx? >>> >>> Могу ошибаться, но коммерческую версию nginx покупают скорее всего >>> не из-за директивы proxy_cache_purge, а ради других возможностей. >>> >>>>>> Если не прояснится - попробовать воспроизвести как минимум без >>>>>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди >>>>>> отваживаются использовать эту поделку, она при любых внутренних >>>>>> изменениях в nginx'е разносит всё же) >>>>> Если не использовать этот кривой сторонний модуль ngx_cache_purge, >>>>> то какие у пользователей open source версии nginx есть альтернативы? >>>>> Директиву proxy_cache_purge >>>>> можете сделать доступной в open source версии nginx? >>> P.S. >>> >>> Please do not top-post. >>> >>> Answer: Because it turns the discussion up-side-down. >>> >>> Question: Why should I not top-post? >>> >> _______________________________________________ >> 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 gmm на csdoc.com Tue Jul 31 13:11:51 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 31 Jul 2018 16:11:51 +0300 Subject: proxy_cache_purge In-Reply-To: References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> Message-ID: <8aa52d49-c8c8-a264-0aaa-ffe3a47f4a43@csdoc.com> On 30.07.2018 19:59, Igor A. Ippolitov wrote: >>> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент >>> в кэше (что и делает purge, в широком смысле). >> Замещать существующий контент или добавлять новый - да. >> Но удалять не позволяет, в этом и состоит (небольшое) отличие. > Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт > клиенту? Почему бы не закэшить сразу его. Потому что как правило объем кэша меньше объема сайта и поэтому имеет смысл держать в кэше только то, что реально запрашивается клиентами. У бекенда нет возможности узнать, ответ бекенда по какому-то урлу еще лежит в кэше или его там уже давно нет. В результате "замещение" контента в кэше через proxy_cache_bypass может быть на самом деле не замещением старого контента, а добавлением туда нового контента и вымыванием из кэша другого контента, который реально запрашивался клиентами, что ведет к уменьшению эффективности работы кэша nginx. > Или условную болванку с max-age:0, которая будет обновлена по первому же > запросу от клиента и при proxy_cache_use_stale updating; эта болванка будет отдана клиенту. а proxy_cache_lock действует только при заполнении нового элемента кэша. > На первый взгляд, PURGE не кажется необходимым средством. > Хотя, вероятно. может упростить жизнь в каких-то конфигурациях. proxy_cache_purge необходимым средством не является, без него можно обойтись - ценой снижения эффективности кэша, например, поставив небольшое время жизни элементов внутри кэша, или обновляя через proxy_cache_bypass в кэше те элементы, которые по-нормальному надо было бы оттуда просто удалять. >>>> Директиву proxy_cache_purge >>>> можете сделать доступной в open source версии nginx? -- Best regards, Gena From mdounin на mdounin.ru Tue Jul 31 13:26:41 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 31 Jul 2018 16:26:41 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: <72b6774c-8fad-4ccf-c98d-9db9da49801f@kinetiksoft.com> References: <72b6774c-8fad-4ccf-c98d-9db9da49801f@kinetiksoft.com> Message-ID: <20180731132641.GF56558@mdounin.ru> Hello! On Tue, Jul 31, 2018 at 02:03:47PM +0300, Иван wrote: > Регулярно в логах (пару раз за 5 минут) вижу > > [alert] 17816#17816: ignore long locked inactive cache entry > 9100488b2180c1fc582384712a73791d, count:1 > > Две прокси на один бэкэнд. Бэкэнд - сервер nginx, отдающий статику. > Прокси - два одинаковых сервера, в разных странах. Проявляется только на > одном > > Настроена зоне кеширования > > proxy_cache_path /var/cache/nginx.hdd/archive_video levels=2:2 > keys_zone=a_v:10m inactive=2d max_size=145g use_temp_path=off; > > > В локейшене: > >                 proxy_buffer_size 128k; >                 proxy_buffers 32 16k; >                 proxy_set_header host backend; > >                 proxy_cache_valid 2d; > >                 proxy_cache_use_stale updating; >                 proxy_cache_key "$proxy_host$uri$http_origin"; >                 proxy_cache_lock on; > > > С чем может быть связано? > > Локейшен обрабатывает не вебсокеты, а статические файлы. Раньше вроде не > замечал, не помню когда начало появляться. Читал в поиске, что это может > быть связано с медленными ответами, но не понял откуда и куда. Между > прокси и бэкэндов - гигабит, в логах бэкэнда медленных ответов не > увидел. На проксях медленных ответов (больше 5 секунд) сильно больше, > чем сабжевых записей в логах, но это понятно, могут быть пользователи с > медленными каналами. Сообщение "ignore long locked inactive cache entry" означает, что, пытаясь удалить из кэша наиболее давно не использовавшийся элемент, nginx наткнулся на элемент, используемый в настоящий момент. Такое сообщение может возникать: - Из-за того, что запись пытаются удалить слишком быстро после начала очередного запроса к ней. Такое может быть при малых значениях inactive, max_size или недостаточном размере keys_zone. В случае очистки по inactive и max_size сообщение будет от процесса cache manger'а, в случае keys_zone - от рабочих процессов, так что для начала проще всего посмотреть, что за процесс 17816 в сообщении выше. - Из-за того, что какие-то рабочие процессы nginx'а падали (или были завершены вручную), и оставили после себя некорректные данные в разделяемой памяти кэша. Информация о падениях есть на уровне alert в логе ошибок, его стоит почитать. Если там что-то есть про падения рабочих процессов - для начала нужно разобраться с ними. Сложнее с ручными завершениями по штатным сигналам - они логгируются на уровне notice, и если вдруг кто-то неосторожно посылает сигналы рабочим процессам - отследить это может быть непросто. Так что проще всего убедиться, что после загрузки кэша заново (для этого подойдёт перезапуск nginx'а или процедура обновления исполняемого файла на лету aka upgrade) и вплодь до появления сообщений pid'ы рабочих процессов остаются те же самые. - Из-за каких-либо ошибок, приводящих к утечке сокетов. Были сигналы, что такое бывает при использовании HTTP/2, но пока неподтверждённые. Ну и при использовании сторонних модулей такое также может быть легко, поэтому если вдруг используются сторонние модули - первым делом следует проверить, воспроизводится ли проблема без них. Утечки сокетов правильнее всего диагностировать по сообщениям "open socket ... left in connection ..." на уровне alert при плавном завершении рабочих процессов. Если процессы штатно завершаются без соответствующих сообщений - проблемы нет, если не завершаются вообще или при завершении в лог пишутся соответствующие ошибки - надо разбираться дальше. -- Maxim Dounin http://mdounin.ru/ From iippolitov на nginx.com Tue Jul 31 14:58:24 2018 From: iippolitov на nginx.com (Igor A. Ippolitov) Date: Tue, 31 Jul 2018 17:58:24 +0300 Subject: proxy_cache_purge In-Reply-To: <8aa52d49-c8c8-a264-0aaa-ffe3a47f4a43@csdoc.com> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> <8aa52d49-c8c8-a264-0aaa-ffe3a47f4a43@csdoc.com> Message-ID: On 31.07.2018 16:11, Gena Makhomed wrote: > On 30.07.2018 19:59, Igor A. Ippolitov wrote: > >>>> Мне кажется, что proxy_cache_bypass легко позволяет замещать >>>> контент в кэше (что и делает purge, в широком смысле). > >>> Замещать существующий контент или добавлять новый - да. >>> Но удалять не позволяет, в этом и состоит (небольшое) отличие. > >> Но ведь какой-то ответ на запрос "пурженного" контента всё равно >> придёт клиенту? Почему бы не закэшить сразу его. > > Потому что как правило объем кэша меньше объема сайта и поэтому имеет > смысл держать в кэше только то, что реально запрашивается клиентами. > > У бекенда нет возможности узнать, ответ бекенда по какому-то урлу > еще лежит в кэше или его там уже давно нет. В результате "замещение" > контента в кэше через proxy_cache_bypass может быть на самом деле > не замещением старого контента, а добавлением туда нового контента > и вымыванием из кэша другого контента, который реально запрашивался > клиентами, что ведет к уменьшению эффективности работы кэша nginx. Если задаться целью избежать добавления нового контента, можно самостоятельно считать md5 от ключа кэша и проверять наличие этого файла. Подобные вычисления можно делать в njs. Подобные же решения можно использовать для создания решений, для которых нет "подходящих по названию" директив в nginx. > >> Или условную болванку с max-age:0, которая будет обновлена по первому же >> запросу от клиента > Тут поправлю сам себя: max-age должен быть больше 0, что создаёт дополнительные сложности. > и при proxy_cache_use_stale updating; эта болванка будет отдана клиенту. > > а proxy_cache_lock действует только при заполнении нового элемента кэша. В отношении proxy_cache_use_stale updating - не могу сказать ничего конструктивного. Если вас устраивает stale контент, то смысл его purge'ить? А если stale не устраивает, то зачем включать proxy_cache_use_stale updating? Кроме того, есть Cache-Control: stale-while-revalidate, который тоже может быть полезен. С выкидыванием proxy_cache_use_stale жизнь дополнительно упрощается тем, что proxy_cache_lock будет работать ожидаемым образом. > >> На первый взгляд, PURGE не кажется необходимым средством. >> Хотя, вероятно. может упростить жизнь в каких-то конфигурациях. > > proxy_cache_purge необходимым средством не является, > без него можно обойтись - ценой снижения эффективности кэша, > например, поставив небольшое время жизни элементов внутри кэша, > или обновляя через proxy_cache_bypass в кэше те элементы, > которые по-нормальному надо было бы оттуда просто удалять. > >>>>> Директиву proxy_cache_purge >>>>> можете сделать доступной в open source версии nginx? > From gmm на csdoc.com Tue Jul 31 16:35:52 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 31 Jul 2018 19:35:52 +0300 Subject: proxy_cache_purge In-Reply-To: References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> <8aa52d49-c8c8-a264-0aaa-ffe3a47f4a43@csdoc.com> Message-ID: On 31.07.2018 17:58, Igor A. Ippolitov wrote: >> У бекенда нет возможности узнать, ответ бекенда по какому-то урлу >> еще лежит в кэше или его там уже давно нет. В результате "замещение" >> контента в кэше через proxy_cache_bypass может быть на самом деле >> не замещением старого контента, а добавлением туда нового контента >> и вымыванием из кэша другого контента, который реально запрашивался >> клиентами, что ведет к уменьшению эффективности работы кэша nginx. > Если задаться целью избежать добавления нового контента, можно > самостоятельно считать md5 от ключа кэша и проверять наличие этого > файла. Подобные вычисления можно делать в njs. Или просто самим backend`ом вычислять md5 от ключа и удалять файл из /var/cache/nginx/ - таким способом тоже должно все работать. >> и при proxy_cache_use_stale updating; эта болванка будет отдана клиенту. >> а proxy_cache_lock действует только при заполнении нового элемента кэша. > В отношении proxy_cache_use_stale updating - не могу сказать ничего > конструктивного. > Если вас устраивает stale контент, то смысл его purge'ить? Насколько я понимаю, если сделать purge для какого-то элемента кэша - то он не будет stale, а его в кэше не будет тогда вообще. Разве нет? stale контент будет использоваться очень непродолжительное время, только пока обновляется этот элемент кэша с backend`а. Кэш в nginx мне интересен прежде всего на тех сайтах, которые находятся / могут находиться под DDoS-атакой. proxy_cache_lock работает только при заполнении нового элемента кэша, поэтому мне приходится использовать proxy_cache_use_stale updating, иначе на backend свалится огромное количество запросов и он упадет. Если бы была возможность легко сделать purge для элемента кэша, тогда можно было бы средствами nginx выствлять большее время жизни для элементов кеша nginx и средствами backend`а их удалять как только они потеряют свою валидность. > А если stale не устраивает, то зачем включать proxy_cache_use_stale > updating? У меня есть небольшой выбор - или использовать stale контент, или backend будет нерабочий из-за большого количества запросов. > С выкидыванием proxy_cache_use_stale жизнь дополнительно упрощается тем, > что proxy_cache_lock будет работать ожидаемым образом. proxy_cache_lock и сейчас работает именно так, как это описано в документации к nginx, - только для новых элементов кэша. Если убрать proxy_cache_use_stale updating тогда на backend будет идти огромное количество запросов и proxy_cache_lock тут никак не поможет. -- Best regards, Gena From jd на jdwuzhere.ru Tue Jul 31 18:35:00 2018 From: jd на jdwuzhere.ru (jd на jdwuzhere.ru) Date: Tue, 31 Jul 2018 21:35:00 +0300 Subject: proxy_cache_purge In-Reply-To: References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> <8aa52d49-c8c8-a264-0aaa-ffe3a47f4a43@csdoc.com> Message-ID: <428E8851-BDE7-4B31-ADB4-575BF0403D18@jdwuzhere.ru> > On 31 Jul 2018, at 19:35, Gena Makhomed wrote: > > On 31.07.2018 17:58, Igor A. Ippolitov wrote: > >>> У бекенда нет возможности узнать, ответ бекенда по какому-то урлу >>> еще лежит в кэше или его там уже давно нет. В результате "замещение" >>> контента в кэше через proxy_cache_bypass может быть на самом деле >>> не замещением старого контента, а добавлением туда нового контента >>> и вымыванием из кэша другого контента, который реально запрашивался >>> клиентами, что ведет к уменьшению эффективности работы кэша nginx. > >> Если задаться целью избежать добавления нового контента, можно самостоятельно считать md5 от ключа кэша и проверять наличие этого файла. Подобные вычисления можно делать в njs. > > Или просто самим backend`ом вычислять md5 от ключа и удалять файл > из /var/cache/nginx/ - таким способом тоже должно все работать. Если удалить элемент кэша вручную backend-ом, то nginx будет очень сильно негодовать в error_log, hence привет, сторонние модули. >>> и при proxy_cache_use_stale updating; эта болванка будет отдана клиенту. >>> а proxy_cache_lock действует только при заполнении нового элемента кэша. > >> В отношении proxy_cache_use_stale updating - не могу сказать ничего конструктивного. >> Если вас устраивает stale контент, то смысл его purge'ить? > > Насколько я понимаю, если сделать purge для какого-то элемента кэша - > то он не будет stale, а его в кэше не будет тогда вообще. Разве нет? > > stale контент будет использоваться очень непродолжительное > время, только пока обновляется этот элемент кэша с backend`а. > > Кэш в nginx мне интересен прежде всего на тех сайтах, > которые находятся / могут находиться под DDoS-атакой. > > proxy_cache_lock работает только при заполнении нового элемента кэша, > поэтому мне приходится использовать proxy_cache_use_stale updating, > иначе на backend свалится огромное количество запросов и он упадет. > > Если бы была возможность легко сделать purge для элемента кэша, > тогда можно было бы средствами nginx выствлять большее время > жизни для элементов кеша nginx и средствами backend`а их удалять > как только они потеряют свою валидность. > >> А если stale не устраивает, то зачем включать proxy_cache_use_stale updating? > > У меня есть небольшой выбор - или использовать stale контент, > или backend будет нерабочий из-за большого количества запросов. > >> С выкидыванием proxy_cache_use_stale жизнь дополнительно упрощается тем, что proxy_cache_lock будет работать ожидаемым образом. > > proxy_cache_lock и сейчас работает именно так, как это описано > в документации к nginx, - только для новых элементов кэша. > > Если убрать proxy_cache_use_stale updating тогда на backend будет идти > огромное количество запросов и proxy_cache_lock тут никак не поможет. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From gmm на csdoc.com Tue Jul 31 18:55:15 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 31 Jul 2018 21:55:15 +0300 Subject: proxy_cache_purge In-Reply-To: <428E8851-BDE7-4B31-ADB4-575BF0403D18@jdwuzhere.ru> References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru> <20180717122900.GZ56558@mdounin.ru> <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru> <20180726124004.GP56558@mdounin.ru> <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com> <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com> <8aa52d49-c8c8-a264-0aaa-ffe3a47f4a43@csdoc.com> <428E8851-BDE7-4B31-ADB4-575BF0403D18@jdwuzhere.ru> Message-ID: <5f99b97f-f57c-182a-6f12-d1a1f4fcdf54@csdoc.com> On 31.07.2018 21:35, jd на jdwuzhere.ru wrote: >> Или просто самим backend`ом вычислять md5 от ключа и удалять файл >> из /var/cache/nginx/ - таким способом тоже должно все работать. > Если удалить элемент кэша вручную backend-ом, то nginx будет очень сильно негодовать в error_log Будет негодовать, но тем не менее, AFAIK все будет работать нормально. Хотя с помощью proxy_cache_purge было бы удобнее и без мусора в логах. > hence привет, сторонние модули. Максим говорит, что тот сторонний модуль кривой. Да и пересобирать тот сторонний модуль при каждом обновлении nginx совсем не хочется. -- Best regards, Gena