From simplebox66 на gmail.com Tue Oct 1 10:02:32 2019 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Tue, 1 Oct 2019 13:02:32 +0300 Subject: =?UTF-8?B?0JTRg9Cx0LvQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA0L7RgdC+0LI=?= Message-ID: Добрый день! Подскажите, может ли nginx отправлять один запрос сразу на несколько апстримов, не round-robin, а именно дублирование/зеркалирование. Т.е. например в апстриме три сервера, приходит запрос и nginx его отправлят сразу на три апстрима/сервера. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From drybalka на docdoc.ru Tue Oct 1 10:21:49 2019 From: drybalka на docdoc.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0KDRi9Cx0LDQu9C60LA=?=) Date: Tue, 1 Oct 2019 12:21:49 +0200 Subject: =?UTF-8?B?UmU6INCU0YPQsdC70LjRgNC+0LLQsNC90LjQtSDQt9Cw0L/RgNC+0YHQvtCy?= In-Reply-To: References: Message-ID: модуль миррор это делает, ед что при его использовании ответы от бекенда игнорируются вт, 1 окт. 2019 г. в 12:02, Иван Мишин : > Добрый день! > Подскажите, может ли nginx отправлять один запрос сразу на несколько > апстримов, не round-robin, а именно дублирование/зеркалирование. Т.е. > например в апстриме три сервера, приходит запрос и nginx его отправлят > сразу на три апстрима/сервера. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From rogat1y на gmail.com Tue Oct 1 16:34:38 2019 From: rogat1y на gmail.com (Maxim K) Date: Tue, 1 Oct 2019 19:34:38 +0300 Subject: =?UTF-8?B?UmU6INCU0YPQsdC70LjRgNC+0LLQsNC90LjQtSDQt9Cw0L/RgNC+0YHQvtCy?= In-Reply-To: References: Message-ID: http://nginx.org/ru/docs/http/ngx_http_mirror_module.html вт, 1 окт. 2019 г. в 13:02, Иван Мишин : > Добрый день! > Подскажите, может ли nginx отправлять один запрос сразу на несколько > апстримов, не round-robin, а именно дублирование/зеркалирование. Т.е. > например в апстриме три сервера, приходит запрос и nginx его отправлят > сразу на три апстрима/сервера. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Oct 9 09:12:53 2019 From: nginx-forum на forum.nginx.org (yanda.a) Date: Wed, 09 Oct 2019 05:12:53 -0400 Subject: =?UTF-8?B?0J/QvtC40YHQuiDRg9C30LrQuNGFINC80LXRgdGC?= Message-ID: <3c27409538167a757ba3be893ea8e1c6.NginxMailingListRussian@forum.nginx.org> Добрый день! Есть nginx с модулем lua. Мы используем content_by, в котором происходит подключение к tarantool и выполнение одной функции в нем. Библиотека для работы с tarantool умеет nginx cosockets, также используется keepalive (соединения попадают в пул). Все это работает достаточно быстро, но периодически бывают всплески по времени работы кода. Например, подключение к tarantool порой достигает 200мс, при том, что соединение находится в пуле. Для более точного измерения времени используем posix.clock_gettime() вместо ngx.now(), так как он более точный и не кеширует время. Да, есть дополнительные два системных вызова, но маловероятно, что они способны блокировать nginx на такое длительное время. Само время замеряем до и после tarantool:connect(). Первым делом грешили на сам tarantool, но сняв дамп трафика с обоих стороны поняли, что по факту само соединение происходит быстро, попросту сам nginx пытается подключиться с "запозданием". Вероятно что-то блокирует его. Так как основной причиной блокировок может быть файловый I/O, решили воспользоваться bcc-tools для подтверждения этого. В частности, воспользовались funcslower. На данный момент пытаемся искать медленное выполнение следующих функций: /usr/sbin/nginx:ngx_write_file /usr/sbin/nginx:ngx_read_file /usr/sbin/nginx:ngx_copy_file c:open c:write c:read Но, к сожалению, в моменты всплеска времени подключения у нас нет медленной работы одной из этих функций. Подскажите, какие еще функции могут блокировать event loop? И каким образом можно диагностировать эту ситуацию? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285826,285826#msg-285826 From chipitsine на gmail.com Wed Oct 9 09:22:14 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 9 Oct 2019 14:22:14 +0500 Subject: =?UTF-8?B?UmU6INCf0L7QuNGB0Log0YPQt9C60LjRhSDQvNC10YHRgg==?= In-Reply-To: <3c27409538167a757ba3be893ea8e1c6.NginxMailingListRussian@forum.nginx.org> References: <3c27409538167a757ba3be893ea8e1c6.NginxMailingListRussian@forum.nginx.org> Message-ID: на 2018-м nginx.conf был доклад, как профилировать в районе Lua (и не только) https://openresty.org/slides/nginx-conf-2018/ ср, 9 окт. 2019 г. в 14:13, yanda.a : > Добрый день! > Есть nginx с модулем lua. Мы используем content_by, в котором происходит > подключение к tarantool и выполнение одной функции в нем. Библиотека для > работы с tarantool умеет nginx cosockets, также используется keepalive > (соединения попадают в пул). Все это работает достаточно быстро, но > периодически бывают всплески по времени работы кода. Например, подключение > к > tarantool порой достигает 200мс, при том, что соединение находится в пуле. > Для более точного измерения времени используем posix.clock_gettime() вместо > ngx.now(), так как он более точный и не кеширует время. Да, есть > дополнительные два системных вызова, но маловероятно, что они способны > блокировать nginx на такое длительное время. Само время замеряем до и после > tarantool:connect(). > > Первым делом грешили на сам tarantool, но сняв дамп трафика с обоих стороны > поняли, что по факту само соединение происходит быстро, попросту сам nginx > пытается подключиться с "запозданием". Вероятно что-то блокирует его. > > Так как основной причиной блокировок может быть файловый I/O, решили > воспользоваться bcc-tools для подтверждения этого. В частности, > воспользовались funcslower. На данный момент пытаемся искать медленное > выполнение следующих функций: > /usr/sbin/nginx:ngx_write_file > /usr/sbin/nginx:ngx_read_file > /usr/sbin/nginx:ngx_copy_file > c:open > c:write > c:read > > Но, к сожалению, в моменты всплеска времени подключения у нас нет медленной > работы одной из этих функций. > > Подскажите, какие еще функции могут блокировать event loop? И каким образом > можно диагностировать эту ситуацию? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,285826,285826#msg-285826 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From defan на nginx.com Wed Oct 9 09:33:32 2019 From: defan на nginx.com (Andrei Belov) Date: Wed, 9 Oct 2019 12:33:32 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QuNGB0Log0YPQt9C60LjRhSDQvNC10YHRgg==?= In-Reply-To: References: <3c27409538167a757ba3be893ea8e1c6.NginxMailingListRussian@forum.nginx.org> Message-ID: > On 9 Oct 2019, at 12:22, Илья Шипицин wrote: > > на 2018-м nginx.conf был доклад, как профилировать в районе Lua (и не только) > > https://openresty.org/slides/nginx-conf-2018/ + видео: https://www.youtube.com/watch?v=NR8U1qYHGqk > > ср, 9 окт. 2019 г. в 14:13, yanda.a >: > Добрый день! > Есть nginx с модулем lua. Мы используем content_by, в котором происходит > подключение к tarantool и выполнение одной функции в нем. Библиотека для > работы с tarantool умеет nginx cosockets, также используется keepalive > (соединения попадают в пул). Все это работает достаточно быстро, но > периодически бывают всплески по времени работы кода. Например, подключение к > tarantool порой достигает 200мс, при том, что соединение находится в пуле. > Для более точного измерения времени используем posix.clock_gettime() вместо > ngx.now(), так как он более точный и не кеширует время. Да, есть > дополнительные два системных вызова, но маловероятно, что они способны > блокировать nginx на такое длительное время. Само время замеряем до и после > tarantool:connect(). > > Первым делом грешили на сам tarantool, но сняв дамп трафика с обоих стороны > поняли, что по факту само соединение происходит быстро, попросту сам nginx > пытается подключиться с "запозданием". Вероятно что-то блокирует его. > > Так как основной причиной блокировок может быть файловый I/O, решили > воспользоваться bcc-tools для подтверждения этого. В частности, > воспользовались funcslower. На данный момент пытаемся искать медленное > выполнение следующих функций: > /usr/sbin/nginx:ngx_write_file > /usr/sbin/nginx:ngx_read_file > /usr/sbin/nginx:ngx_copy_file > c:open > c:write > c:read > > Но, к сожалению, в моменты всплеска времени подключения у нас нет медленной > работы одной из этих функций. > > Подскажите, какие еще функции могут блокировать event loop? И каким образом > можно диагностировать эту ситуацию? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Wed Oct 9 09:42:48 2019 From: nginx-forum на forum.nginx.org (yanda.a) Date: Wed, 09 Oct 2019 05:42:48 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QuNGB0Log0YPQt9C60LjRhSDQvNC10YHRgg==?= In-Reply-To: References: Message-ID: Спасибо большое, достаточно интересно! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285826,285829#msg-285829 From chipitsine на gmail.com Sun Oct 13 09:18:30 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 13 Oct 2019 14:18:30 +0500 Subject: =?UTF-8?B?0L7RiNC40LHQutCwICJ1cHN0cmVhbSBwcmVtYXR1cmVseSBjbG9zZWQgY29ubmVj?= =?UTF-8?B?dGlvbiIgLSDQvtCx0YHRg9C00LjQvCA/?= Message-ID: привет, предыстория. видим ошибку в логах. вспоминаем концепцию, что с уровнем error логируются ошибки на стороне сервера. считаем, что ошибка действительно была. идем к клиенту - у клиента статус 200, ему хорошо, все, что он хотел считать, он вычитал. повторяем несколько раз, в большинстве случаев ситуация повторяется, в логах ошибка, у клиента все хорошо. ок. идем смотреть исходники вывод сообщения об ошибке встречается три раза ./nginx-1.17.4/src/http/ngx_http_upstream.c: "upstream prematurely closed connection"); ./nginx-1.17.4/src/http/ngx_http_upstream.c: "upstream prematurely closed connection"); ./nginx-1.17.4/src/http/ngx_http_upstream.c: "upstream prematurely closed connection"); в двух случаях запрос завершается статусом 502 ngx_http_upstream_finalize_request(r, u, NGX_HTTP_BAD_GATEWAY); в одном месте - не завершается: http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_upstream.c#l2369 собственно, recv в некоторых случаях может выдавать 0 и это не всегда ошибка (у нас CentOS 7, возможно, там какая-то своя магия еще, с какими-нибудь сетевыми штуками бекпортированными в ядро 3.10) man recv ... "The value 0 may also be returned if the requested number of bytes to receive from a stream socket was 0." собственно, в этом месте меняем текст. и, чудо, после этого залогированные "upstream prematurely closed connection" идеально кореллируют с реальными обрывами. вопрос - в этом месте действительно стоит логировать ошибку с таким текстом ? может поменять уровень на info (или debug), а текст сделать что-то типа "zero bytes read from recv" ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Sun Oct 13 13:19:22 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 13 Oct 2019 18:19:22 +0500 Subject: =?UTF-8?B?0L/QvtCy0LXQtNC10L3QuNC1INC60YPQutC4IHVzZXJpZCDQvdCwIHByZWZsaWdo?= =?UTF-8?B?dCDQt9Cw0L/RgNC+0YHQsNGF?= Message-ID: привет, столкнулись с тем, что модуль https://nginx.org/en/docs/http/ngx_http_userid_module.html#userid выставляет куку в том числе на OPTIONS, который браузер отправляет без кук, потому что CORS https://stackoverflow.com/questions/41478229/set-cookie-header-behaviour-in-a-preflight-options-request при поведение браузеров разное. MSIE принимает новую куку (была старая, сделал OPTIONS без кук, получил новую, принял). может есть смысл перестать отправлять эту куку на OPTIONS ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Sun Oct 13 15:11:03 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sun, 13 Oct 2019 18:11:03 +0300 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCAidXBzdHJlYW0gcHJlbWF0dXJlbHkgY2xvc2VkIGNv?= =?UTF-8?B?bm5lY3Rpb24iIC0g0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: References: Message-ID: <20191013151103.GJ2770@sie.protva.ru> On Sun, Oct 13, 2019 at 02:18:30PM +0500, Илья Шипицин wrote: > в одном месте - не завершается: > http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_upstream.c#l2369 > собственно, recv в некоторых случаях может выдавать 0 и это не всегда > ошибка (у нас CentOS 7, возможно, там какая-то своя магия еще, с > какими-нибудь сетевыми штуками бекпортированными в ядро 3.10) > man recv > ... > "The value 0 may also be returned if the requested number of bytes to > receive from a stream socket was 0." Насколько я разбираюсь в английском, "requested number of bytes" -- это значение аргумента len, т.е. ситуация, когда в recv() передают длину буфера равную нулю, т.е. из сокета запрашивается чтение нуля байт. Nginx действительно так делает? > собственно, в этом месте меняем текст. и, чудо, после этого залогированные > "upstream prematurely closed connection" идеально кореллируют с реальными > обрывами. Что на что меняем? diff покажите. -- Eugene Berdnikov From chipitsine на gmail.com Sun Oct 13 15:44:03 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 13 Oct 2019 20:44:03 +0500 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCAidXBzdHJlYW0gcHJlbWF0dXJlbHkgY2xvc2VkIGNv?= =?UTF-8?B?bm5lY3Rpb24iIC0g0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: <20191013151103.GJ2770@sie.protva.ru> References: <20191013151103.GJ2770@sie.protva.ru> Message-ID: вс, 13 окт. 2019 г. в 20:11, Evgeniy Berdnikov : > On Sun, Oct 13, 2019 at 02:18:30PM +0500, Илья Шипицин wrote: > > в одном месте - не завершается: > > http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_upstream.c#l2369 > > собственно, recv в некоторых случаях может выдавать 0 и это не всегда > > ошибка (у нас CentOS 7, возможно, там какая-то своя магия еще, с > > какими-нибудь сетевыми штуками бекпортированными в ядро 3.10) > > man recv > > ... > > "The value 0 may also be returned if the requested number of bytes to > > receive from a stream socket was 0." > > Насколько я разбираюсь в английском, "requested number of bytes" -- это > значение аргумента len, т.е. ситуация, когда в recv() передают длину > буфера равную нулю, т.е. из сокета запрашивается чтение нуля байт. > Nginx действительно так делает? > я не добавлял в это место логирование. не могу наверняка сказать. у нас выключена настройка "proxy_buffering off;" и еще в каких-то моментах конфиг отличается от дефолтного. возможно, что при некоторой комбинации параметров может передаваться 0 в recv (я попробую в это место отладку добавить), возможно, что 0 возращается по каким-то другим причинам, связанным с особенностью recv под centos > > собственно, в этом месте меняем текст. и, чудо, после этого > залогированные > > "upstream prematurely closed connection" идеально кореллируют с > реальными > > обрывами. > > Что на что меняем? diff покажите. > вроде бы это не должно иметь значения. у меня три места, где генерируется "upstream prematurely closed connection". одно из этих мест я меняю на что-то отличное, чтобы в логе понять, где срабатывает ошибка. допустим, меняю на "xyz" > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Oct 14 06:59:44 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 14 Oct 2019 11:59:44 +0500 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCAidXBzdHJlYW0gcHJlbWF0dXJlbHkgY2xvc2VkIGNv?= =?UTF-8?B?bm5lY3Rpb24iIC0g0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: References: <20191013151103.GJ2770@sie.protva.ru> Message-ID: добавил отладку. в recv передается не ноль. из recv возвращается ноль. вс, 13 окт. 2019 г. в 20:44, Илья Шипицин : > > > вс, 13 окт. 2019 г. в 20:11, Evgeniy Berdnikov : > >> On Sun, Oct 13, 2019 at 02:18:30PM +0500, Илья Шипицин wrote: >> > в одном месте - не завершается: >> > >> http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_upstream.c#l2369 >> > собственно, recv в некоторых случаях может выдавать 0 и это не всегда >> > ошибка (у нас CentOS 7, возможно, там какая-то своя магия еще, с >> > какими-нибудь сетевыми штуками бекпортированными в ядро 3.10) >> > man recv >> > ... >> > "The value 0 may also be returned if the requested number of bytes to >> > receive from a stream socket was 0." >> >> Насколько я разбираюсь в английском, "requested number of bytes" -- это >> значение аргумента len, т.е. ситуация, когда в recv() передают длину >> буфера равную нулю, т.е. из сокета запрашивается чтение нуля байт. >> Nginx действительно так делает? >> > > я не добавлял в это место логирование. не могу наверняка сказать. > у нас выключена настройка "proxy_buffering off;" и еще в каких-то моментах > конфиг отличается от дефолтного. > > возможно, что при некоторой комбинации параметров может передаваться 0 в > recv (я попробую в это место отладку добавить), > возможно, что 0 возращается по каким-то другим причинам, связанным с > особенностью recv под centos > > > >> > собственно, в этом месте меняем текст. и, чудо, после этого >> залогированные >> > "upstream prematurely closed connection" идеально кореллируют с >> реальными >> > обрывами. >> >> Что на что меняем? diff покажите. >> > > вроде бы это не должно иметь значения. > у меня три места, где генерируется "upstream prematurely closed > connection". одно из этих мест я меняю на что-то отличное, чтобы в логе > понять, > где срабатывает ошибка. допустим, меняю на "xyz" > > >> -- >> Eugene Berdnikov >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Mon Oct 14 07:32:57 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 14 Oct 2019 10:32:57 +0300 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCAidXBzdHJlYW0gcHJlbWF0dXJlbHkgY2xvc2VkIGNv?= =?UTF-8?B?bm5lY3Rpb24iIC0g0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: References: <20191013151103.GJ2770@sie.protva.ru>

Message-ID: <20191014073257.GA2646@protva.ru> On Mon, Oct 14, 2019 at 11:59:44AM +0500, Илья Шипицин wrote: > добавил отладку. > в recv передается не ноль. из recv возвращается ноль. Значит процитированный фрагмент man recv и все домыслы вокруг него (насчёт специфики реализации в каком-то центосе) оказались мимо темы. Теперь самое время разобраться в обстоятельствах, при которых recv() возвращает ноль. Смотрите что высылает бэкенд, что прилетает по сети. -- Eugene Berdnikov From chipitsine на gmail.com Mon Oct 14 07:48:17 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 14 Oct 2019 12:48:17 +0500 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCAidXBzdHJlYW0gcHJlbWF0dXJlbHkgY2xvc2VkIGNv?= =?UTF-8?B?bm5lY3Rpb24iIC0g0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: <20191014073257.GA2646@protva.ru> References: <20191013151103.GJ2770@sie.protva.ru>

<20191014073257.GA2646@protva.ru> Message-ID: не мимо темы. мы просим из recv столько то данных, возвращается ноль. дальнейшую отладку попробую собрать пн, 14 окт. 2019 г. в 12:33, Evgeniy Berdnikov : > On Mon, Oct 14, 2019 at 11:59:44AM +0500, Илья Шипицин wrote: > > добавил отладку. > > в recv передается не ноль. из recv возвращается ноль. > > Значит процитированный фрагмент man recv и все домыслы вокруг него > (насчёт специфики реализации в каком-то центосе) оказались мимо темы. > > Теперь самое время разобраться в обстоятельствах, при которых recv() > возвращает ноль. Смотрите что высылает бэкенд, что прилетает по сети. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Oct 14 13:09:36 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 14 Oct 2019 16:09:36 +0300 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCAidXBzdHJlYW0gcHJlbWF0dXJlbHkgY2xvc2VkIGNv?= =?UTF-8?B?bm5lY3Rpb24iIC0g0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: References: Message-ID: <20191014130936.GL1877@mdounin.ru> Hello! On Sun, Oct 13, 2019 at 02:18:30PM +0500, Илья Шипицин wrote: > привет, > > предыстория. видим ошибку в логах. вспоминаем концепцию, что с уровнем > error логируются ошибки на стороне сервера. считаем, что ошибка > действительно была. идем к клиенту - у клиента статус 200, ему хорошо, все, > что он хотел считать, он вычитал. повторяем несколько раз, в большинстве > случаев ситуация повторяется, в логах ошибка, у клиента все хорошо. > > ок. идем смотреть исходники > > вывод сообщения об ошибке встречается три раза > > ./nginx-1.17.4/src/http/ngx_http_upstream.c: > "upstream prematurely closed connection"); > ./nginx-1.17.4/src/http/ngx_http_upstream.c: > "upstream prematurely closed connection"); > ./nginx-1.17.4/src/http/ngx_http_upstream.c: > "upstream prematurely closed connection"); > > в двух случаях запрос завершается статусом 502 > > ngx_http_upstream_finalize_request(r, u, NGX_HTTP_BAD_GATEWAY); > > > в одном месте - не завершается: > http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_upstream.c#l2369 Да, если ошибка происходит при чтении заголовка ответа - nginx пробует перейти к следующему бэкенду, так как это ещё возможно. Что, однако же, не означает, что ошибки нет - она есть. > собственно, recv в некоторых случаях может выдавать 0 и это не всегда > ошибка (у нас CentOS 7, возможно, там какая-то своя магия еще, с > какими-нибудь сетевыми штуками бекпортированными в ядро 3.10) > > man recv > ... > "The value 0 may also be returned if the requested number of bytes to > receive from a stream socket was 0." > > собственно, в этом месте меняем текст. и, чудо, после этого залогированные > "upstream prematurely closed connection" идеально кореллируют с реальными > обрывами. > > вопрос - в этом месте действительно стоит логировать ошибку с таким текстом > ? может поменять уровень на info (или debug), а текст сделать что-то типа > "zero bytes read from recv" ? Если recv() возвращает 0 байт - в предположении, что буфер был не нулевого размера - то это означает, что соединение закрыто "той стороной". Если это происходит в момент времени, не предусмотренный протоколом - то это ошибка, и она логгируется соответственно. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Oct 14 15:35:42 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 14 Oct 2019 18:35:42 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QstC10LTQtdC90LjQtSDQutGD0LrQuCB1c2VyaWQg0L3QsCBwcmVm?= =?UTF-8?B?bGlnaHQg0LfQsNC/0YDQvtGB0LDRhQ==?= In-Reply-To: References: Message-ID: <20191014153542.GN1877@mdounin.ru> Hello! On Sun, Oct 13, 2019 at 06:19:22PM +0500, Илья Шипицин wrote: > привет, > > столкнулись с тем, что модуль > > https://nginx.org/en/docs/http/ngx_http_userid_module.html#userid > > > выставляет куку в том числе на OPTIONS, который браузер отправляет без кук, > потому что CORS > > https://stackoverflow.com/questions/41478229/set-cookie-header-behaviour-in-a-preflight-options-request > при > > поведение браузеров разное. MSIE принимает новую куку (была старая, сделал > OPTIONS без кук, получил новую, принял). > > может есть смысл перестать отправлять эту куку на OPTIONS ? С учётом того, что : Browser discards Set-Cookie in the response to OPTIONS. : : (Tried Chrome, Firefox, and Opera. Set-Cookie in the response to : OPTIONS is always ignored.) а равно текста спецификации CORS (которая предписывает для preflight-запросов не только не отправлять cookie, но и не принимать их) - это выглядит как проблема MSIE. Ну то есть не отправлять Set-Cookie с целью оптимизации - можно, но в общем случае неизвестно же, что это за OPTIONS и используется ли он как preflight-запрос в рамках CORS, или это какая-нибудь другая экзотика. А с функциональной точки зрения - нет разницы, отправлять или не отправлять (а если вдруг есть - то это ошибка клиента). -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Oct 15 05:49:17 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 15 Oct 2019 10:49:17 +0500 Subject: RSA + EC - ocsp stapling ? Message-ID: Добрый день! допустим, у нас сайт на двух сертификатах. включаем директиву ssl_stapling on; для обоих сертификатов должно включиться ? а что надо указывать в директиве *ssl_stapling_file* *файл*; ответ для обоих сертификатов ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Oct 15 07:25:38 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 15 Oct 2019 12:25:38 +0500 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCAidXBzdHJlYW0gcHJlbWF0dXJlbHkgY2xvc2VkIGNv?= =?UTF-8?B?bm5lY3Rpb24iIC0g0L7QsdGB0YPQtNC40LwgPw==?= In-Reply-To: <20191014130936.GL1877@mdounin.ru> References: <20191014130936.GL1877@mdounin.ru> Message-ID: пн, 14 окт. 2019 г. в 18:09, Maxim Dounin : > Hello! > > On Sun, Oct 13, 2019 at 02:18:30PM +0500, Илья Шипицин wrote: > > > привет, > > > > предыстория. видим ошибку в логах. вспоминаем концепцию, что с уровнем > > error логируются ошибки на стороне сервера. считаем, что ошибка > > действительно была. идем к клиенту - у клиента статус 200, ему хорошо, > все, > > что он хотел считать, он вычитал. повторяем несколько раз, в большинстве > > случаев ситуация повторяется, в логах ошибка, у клиента все хорошо. > > > > ок. идем смотреть исходники > > > > вывод сообщения об ошибке встречается три раза > > > > ./nginx-1.17.4/src/http/ngx_http_upstream.c: > > "upstream prematurely closed connection"); > > ./nginx-1.17.4/src/http/ngx_http_upstream.c: > > "upstream prematurely closed connection"); > > ./nginx-1.17.4/src/http/ngx_http_upstream.c: > > "upstream prematurely closed connection"); > > > > в двух случаях запрос завершается статусом 502 > > > > ngx_http_upstream_finalize_request(r, u, NGX_HTTP_BAD_GATEWAY); > > > > > > в одном месте - не завершается: > > http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_upstream.c#l2369 > > Да, если ошибка происходит при чтении заголовка ответа - nginx > пробует перейти к следующему бэкенду, так как это ещё возможно. > Что, однако же, не означает, что ошибки нет - она есть. > по наблюдаемой картинке - да, похоже, в этом дело и было. получаем 0 из recv во время чтения заголовков, запрос переотправляется, в целом он получается успешный > > > собственно, recv в некоторых случаях может выдавать 0 и это не всегда > > ошибка (у нас CentOS 7, возможно, там какая-то своя магия еще, с > > какими-нибудь сетевыми штуками бекпортированными в ядро 3.10) > > > > man recv > > ... > > "The value 0 may also be returned if the requested number of bytes to > > receive from a stream socket was 0." > > > > собственно, в этом месте меняем текст. и, чудо, после этого > залогированные > > "upstream prematurely closed connection" идеально кореллируют с реальными > > обрывами. > > > > вопрос - в этом месте действительно стоит логировать ошибку с таким > текстом > > ? может поменять уровень на info (или debug), а текст сделать что-то типа > > "zero bytes read from recv" ? > > Если recv() возвращает 0 байт - в предположении, что буфер был не > нулевого размера - то это означает, что соединение закрыто "той > стороной". Если это происходит в момент времени, не > предусмотренный протоколом - то это ошибка, и она логгируется > соответственно. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Oct 15 07:28:29 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 15 Oct 2019 12:28:29 +0500 Subject: RSA + EC - ocsp stapling ? In-Reply-To: References: Message-ID: аналогичный вопрос по директиве *ssl_stapling_responder* *в случае, если несколько сертификатов* вт, 15 окт. 2019 г. в 10:49, Илья Шипицин : > Добрый день! > > допустим, у нас сайт на двух сертификатах. включаем директиву > > ssl_stapling on; > > для обоих сертификатов должно включиться ? > > > а что надо указывать в директиве > > *ssl_stapling_file* *файл*; > > ответ для обоих сертификатов ? > > Илья Шипицин > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Oct 15 13:52:06 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 15 Oct 2019 16:52:06 +0300 Subject: RSA + EC - ocsp stapling ? In-Reply-To: References: Message-ID: <20191015135205.GR1877@mdounin.ru> Hello! On Tue, Oct 15, 2019 at 10:49:17AM +0500, Илья Шипицин wrote: > допустим, у нас сайт на двух сертификатах. включаем директиву > > ssl_stapling on; > > для обоих сертификатов должно включиться ? Да. > а что надо указывать в директиве > > *ssl_stapling_file* *файл*; > > ответ для обоих сертификатов ? Ничего. Если что-либо указать - то всё содержимое файла будет возвращаться всем клиентам в рамках OCSP stapling'а, вне зависимости от используемого сертификата, и работать это не будет. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Oct 15 14:01:56 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 15 Oct 2019 19:01:56 +0500 Subject: RSA + EC - ocsp stapling ? In-Reply-To: <20191015135205.GR1877@mdounin.ru> References: <20191015135205.GR1877@mdounin.ru> Message-ID: вт, 15 окт. 2019 г. в 18:52, Maxim Dounin : > Hello! > > On Tue, Oct 15, 2019 at 10:49:17AM +0500, Илья Шипицин wrote: > > > допустим, у нас сайт на двух сертификатах. включаем директиву > > > > ssl_stapling on; > > > > для обоих сертификатов должно включиться ? > > Да. > > > а что надо указывать в директиве > > > > *ssl_stapling_file* *файл*; > > > > ответ для обоих сертификатов ? > > Ничего. Если что-либо указать - то всё содержимое файла будет > возвращаться всем клиентам в рамках OCSP stapling'а, вне > зависимости от используемого сертификата, и работать это не будет. > с дилетанской точки зрения выглядит разумным сценарий - первый раз взять OCSP ответ, сохранить его в файл, дальше отдавать из файла. такого не ренализовано? > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Oct 15 14:19:15 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 15 Oct 2019 17:19:15 +0300 Subject: RSA + EC - ocsp stapling ? In-Reply-To: References: <20191015135205.GR1877@mdounin.ru> Message-ID: <20191015141915.GS1877@mdounin.ru> Hello! On Tue, Oct 15, 2019 at 07:01:56PM +0500, Илья Шипицин wrote: > вт, 15 окт. 2019 г. в 18:52, Maxim Dounin : > > > Hello! > > > > On Tue, Oct 15, 2019 at 10:49:17AM +0500, Илья Шипицин wrote: > > > > > допустим, у нас сайт на двух сертификатах. включаем директиву > > > > > > ssl_stapling on; > > > > > > для обоих сертификатов должно включиться ? > > > > Да. > > > > > а что надо указывать в директиве > > > > > > *ssl_stapling_file* *файл*; > > > > > > ответ для обоих сертификатов ? > > > > Ничего. Если что-либо указать - то всё содержимое файла будет > > возвращаться всем клиентам в рамках OCSP stapling'а, вне > > зависимости от используемого сертификата, и работать это не будет. > > > > с дилетанской точки зрения выглядит разумным сценарий - первый раз взять > OCSP ответ, сохранить его в файл, дальше отдавать из файла. > такого не ренализовано? Нет. Поведение директивы ssl_stapling_file явно описано в документации (http://nginx.org/r/ssl_stapling_file). -- Maxim Dounin http://mdounin.ru/ From motienko на gmail.com Tue Oct 22 15:10:50 2019 From: motienko на gmail.com (Oleg Motienko) Date: Tue, 22 Oct 2019 18:10:50 +0300 Subject: nginx reverse proxy for grpc Message-ID: Добрый день. Можно ли как-то реализовать сабж? Есть несколько grpc серверов без tls (по сути нешифрованый http2) в локальной сети, надо их "выпустить" в интернет и обернуть трафик в tls. Запросы как-то балансировать и передавать каким-то образом IP адрес клиента в приложение. Насколько я понимаю, ngx_http_proxy_module не умеет http2 в proxy_pass. Есть ли другие варианты? -- Regards, Oleg From mdounin на mdounin.ru Tue Oct 22 15:15:04 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 22 Oct 2019 18:15:04 +0300 Subject: nginx reverse proxy for grpc In-Reply-To: References: Message-ID: <20191022151504.GU1877@mdounin.ru> Hello! On Tue, Oct 22, 2019 at 06:10:50PM +0300, Oleg Motienko wrote: > Можно ли как-то реализовать сабж? > > Есть несколько grpc серверов без tls (по сути нешифрованый http2) в > локальной сети, надо их "выпустить" в интернет и обернуть трафик в > tls. Запросы как-то балансировать и передавать каким-то образом IP > адрес клиента в приложение. > > Насколько я понимаю, ngx_http_proxy_module не умеет http2 в proxy_pass. > > Есть ли другие варианты? http://nginx.org/ru/docs/http/ngx_http_grpc_module.html -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Oct 22 15:35:08 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 22 Oct 2019 18:35:08 +0300 Subject: nginx-1.17.5 Message-ID: <20191022153507.GX1877@mdounin.ru> Изменения в nginx 1.17.5 22.10.2019 *) Добавление: теперь nginx использует вызов ioctl(FIONREAD), если он доступен, чтобы избежать чтения из быстрого соединения в течение долгого времени. *) Исправление: неполные закодированные символы в конце URI запроса игнорировались. *) Исправление: "/." и "/.." в конце URI запроса не нормализовывались. *) Исправление: в директиве merge_slashes. *) Исправление: в директиве ignore_invalid_headers. Спасибо Alan Kemp. *) Исправление: nginx не собирался с MinGW-w64 gcc 8.1 и новее. -- Maxim Dounin http://nginx.org/ From motienko на gmail.com Wed Oct 23 07:48:31 2019 From: motienko на gmail.com (Oleg Motienko) Date: Wed, 23 Oct 2019 10:48:31 +0300 Subject: nginx reverse proxy for grpc In-Reply-To: <20191022151504.GU1877@mdounin.ru> References: <20191022151504.GU1877@mdounin.ru> Message-ID: Добрый день. Спасибо, этот модуль, похоже, именно то, что я искал. Кстати, если передавать в grpc metadata "переменную" с подчеркиванием, она не проходит. Как я понимаю, это из-за того, что это metadata по сути есть http заголовки и символ подчеркивания недопустим ? On Tue, Oct 22, 2019 at 6:15 PM Maxim Dounin wrote: > > Hello! > > On Tue, Oct 22, 2019 at 06:10:50PM +0300, Oleg Motienko wrote: > > > Можно ли как-то реализовать сабж? > > > > Есть несколько grpc серверов без tls (по сути нешифрованый http2) в > > локальной сети, надо их "выпустить" в интернет и обернуть трафик в > > tls. Запросы как-то балансировать и передавать каким-то образом IP > > адрес клиента в приложение. > > > > Насколько я понимаю, ngx_http_proxy_module не умеет http2 в proxy_pass. > > > > Есть ли другие варианты? > > http://nginx.org/ru/docs/http/ngx_http_grpc_module.html > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Oleg From mdounin на mdounin.ru Wed Oct 23 12:25:01 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 23 Oct 2019 15:25:01 +0300 Subject: nginx reverse proxy for grpc In-Reply-To: References: <20191022151504.GU1877@mdounin.ru> Message-ID: <20191023122501.GZ1877@mdounin.ru> Hello! On Wed, Oct 23, 2019 at 10:48:31AM +0300, Oleg Motienko wrote: > Кстати, если передавать в grpc metadata "переменную" с подчеркиванием, > она не проходит. Как я понимаю, это из-за того, что это metadata по > сути есть http заголовки и символ подчеркивания недопустим ? Да, примерно. Строго говоря, символ подчёркивания допустим согласно грамматике HTTP-заголовков. Однако с ним имеется проблема: в рамках CGI (а следом - и много где ещё, включая переменные $http_* в nginx'е) заголовок запроса Foo-Bar передаётся в виде переменной окружения HTTP_FOO_BAR. И если разрешать символ подчёркивания в именах заголовков, то заголовок Foo_Bar на уровне CGI-приложения становится неотличим от Foo-Bar (хотя в HTTP это разные заголовки). Такое различие в обработке - очевидно, проблема с точки зрения безопасности. Поэтому по умолчанию nginx такие заголовки считает недопустимыми. Если очень надо - заголовки с символом подчёркивания можно разрешить, для этого есть директива underscores_in_headers: http://nginx.org/ru/docs/http/ngx_http_core_module.html#underscores_in_headers Но это именно что если очень надо. Лучше этого не делать, могут быть неожиданные последствия. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Oct 24 12:20:50 2019 From: nginx-forum на forum.nginx.org (bassay) Date: Thu, 24 Oct 2019 08:20:50 -0400 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgSDQvdCw0YHRgtGA0L7QudC60L7QuSDQutC+0L0=?= =?UTF-8?B?0YTQuNCz0LA=?= Message-ID: Добрый день! Если не сложно помогите настроить конфиг set $main_host 'site1.ru'; set $main_host2 'site2.ru'; if ($host != $main_host OR $host != $main_host2) { rewrite ^(.*)$ https://site1.ru$1 permanent; break; } Я хочу сделать так чтобы сайт работал на 2 доменах, и в случае если пользователь заходит на другие версии сайта, например с www.site1.ru , либо любое другое зеркало, вебсервер делал 301 редирект на домен site1.ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285989,285989#msg-285989 From red-fox0 на ya.ru Thu Oct 24 12:28:30 2019 From: red-fox0 на ya.ru (fox) Date: Thu, 24 Oct 2019 19:28:30 +0700 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YEg0L3QsNGB0YLRgNC+0LnQutC+0Lkg0Lo=?= =?UTF-8?B?0L7QvdGE0LjQs9Cw?= In-Reply-To: References: Message-ID: <0b043dad-f4cb-dfd3-279a-51b8670ccad0@ya.ru> server { server_name www.site1.ru site2.ru; return 301 http://site1.ru$request_uri; } server { server_name site1.ru; #… } 24.10.2019 19:20, bassay пишет: > Добрый день! Если не сложно помогите настроить конфиг > > set $main_host 'site1.ru'; > set $main_host2 'site2.ru'; > > if ($host != $main_host OR $host != $main_host2) { > rewrite ^(.*)$ https://site1.ru$1 permanent; > break; > } > > Я хочу сделать так чтобы сайт работал на 2 доменах, и в случае если > пользователь заходит на другие версии сайта, например с www.site1.ru , либо > любое другое зеркало, вебсервер делал 301 редирект на домен site1.ru > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285989,285989#msg-285989 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum на forum.nginx.org Sun Oct 27 11:05:43 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Sun, 27 Oct 2019 07:05:43 -0400 Subject: cache file has too long header In-Reply-To: References: Message-ID: <9779253980a332f6eab42e64b64821b5.NginxMailingListRussian@forum.nginx.org> Может лучше будет создать тикет здесь, чтобы не затерялось? https://trac.nginx.org/nginx/report/1 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,286008#msg-286008 From nginx-forum на forum.nginx.org Tue Oct 29 13:02:39 2019 From: nginx-forum на forum.nginx.org (RuslanValitov) Date: Tue, 29 Oct 2019 09:02:39 -0400 Subject: =?UTF-8?B?bmd4IGh0dHAgbGltaXQgcmVxIG1vZHVsZSArIGx1YSArIEpXVCDRgtC+0LrQtdC9?= =?UTF-8?B?0Ys=?= Message-ID: Добрый день. Собственно говоря вот статья: https://dislic.net/2015/11/06/advanced-limiting-request-with-nginx-or-openresty/ в которой предполагается ограничивать кол-во запросов по cookie, так как масса пользователей сидят за NAT! На практике в $cookie_userid на стороне клиента злоумышленник может поместить все что угодно, и как следствие каждый новый запрос злоумышленник может снабжать новым уникальным $cookie_userid, и не важно что такого user_id на стороне бэкэнда не существует, главное для злоумышленника это то, что на стороне nginx новый $cookie_userid будет восприниматься как новый key (новый пользователь) с не превышенным кол-вом запросов. Таким образом можно слать сотни тысяч запросов и каждый с новым $cookie_userid. Вопрос: Что если в location использовать связку ngx+lua+jwr_access_token? То есть, когда запросы будут попадают в защищаемый от ddos location, первое что будем делать помощи lua, это: вычислять HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload),secret) и если вычисленная и полученная сигнатуры access токена совпадут, то токен настоящий, его смело можно использовать для ограничения, и key для limit_req_zone будет иметь что то вроде: limit_req_zone $binary_remote_addr$cookie_hash zone=one:10m rate=90r/m; где set_md5 $cookie_hash $cookie_jwt; так мы установим ограничение для каждого аутентифицированного пользователя в разрезе IP адресов. Таким образом даже 10000 сидящим за NAT пользователям не грозит отказ в обслуживании! Если сигнатуры не совпали, значит JWT токен поддельный, и тогда: limit_req_zone $binary_remote_addr$cookie_hash zone=three:10m rate=90r/m; где $cookie_hash="" (не уверен что это правильно, но имею ввиду что ключ $binary_remote_addr$cookie_hash будет содержать только IP адрес учитывая что в $cookie_hash мы присвоим пустую строку) таким образом запросы не аутентифицированных пользователей (потенциально это могут быть и 1000 ботов сидящих за одним IP) будут ограничиваться одним IP адресом. В случае если, злоумышленник пройдет аутентификация и получит jwt access токен и будет подставлять его в атаках для 1000 ботов то все равно будут действовать ограничения на один токен+ip. 1. На сколько подобное решение РЕАЛЬНО? Только изучаю эти вопросы. 2. Создаст ли оно не оправдано высокую вычислительную нагрузку на nginx, что сделает такую схему перегружающей nginx? 3. Может есть какие то дополнения от опытных пользователей? Всем большое спасибо, буду очень признателен за ваше мнение! С уважением и наилучшими пожеланиями Руслан. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286037,286037#msg-286037 From nginx-forum на forum.nginx.org Tue Oct 29 23:04:07 2019 From: nginx-forum на forum.nginx.org (commeta) Date: Tue, 29 Oct 2019 19:04:07 -0400 Subject: =?UTF-8?B?cHJveHkgY2FjaGUg0L3QtSDQutGN0YjQuNGA0YPQtdGCIGh0dHAgMS4w?= Message-ID: server { server_name mysite.ru www.mysite.ru; charset UTF-8; index index.php index.html; disable_symlinks if_not_owner from=$root_path; include /etc/nginx/vhosts-includes/*.conf; include /etc/nginx/vhosts-resources/mysite.ru/*.conf; access_log /var/www/httpd-logs/mysite.ru.access.log; error_log /var/www/httpd-logs/mysite.ru.error.log notice; set $root_path /var/www/www-root/data/www/mysite.ru; root $root_path; location / { location ~ [^/]\.ph(p\d*|tml)$ { try_files /does_not_exists @fallback; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|woff|woff2|ico|ttf)$ { try_files $uri $uri/ @fallback; } location / { try_files /does_not_exists @fallback; } } location @fallback { proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port; access_log off; } return 301 https://$host:443$request_uri; gzip on; gzip_comp_level 9; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; listen 19.19.19.19:80; } server { # show cache status and any skip cache reason add_header Bullet-Proxy-Cache $upstream_cache_status; add_header Cache-BYPASS-Reason $skip_reason; # define nginx variables set $skip_cache 1; set $skip_reason ""; if ($request_uri ~* "/|/*.html|/*.txt|/*.xml") { set $skip_cache 0; set $skip_reason HTML; } # security for bypass so localhost can empty cache if ($remote_addr ~ "^(127.0.0.1|19.19.19.19)$") { set $bypass $http_secret_header; } # skip caching cookies if ($http_cookie ~* "modx_admin" ) { set $skip_cache 1; set $skip_reason Cookie; } # Don't cache URIs containing the following segments if ($request_uri ~* "/manager/|/*.php") { set $skip_cache 1; set $skip_reason URI; } # skip caching POST if ($request_method = POST) { set $skip_cache 1; set $skip_reason POST; } server_name mysite.ru www.mysite.ru; ssl_certificate "/var/www/httpd-cert/www-root/mysite.ru_le3.crtca"; ssl_certificate_key "/var/www/httpd-cert/www-root/mysite.ru_le3.key"; ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:!NULL:!RC4; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_dhparam /etc/ssl/certs/dhparam4096.pem; charset UTF-8; index index.php index.html; disable_symlinks if_not_owner from=$root_path; include /etc/nginx/vhosts-includes/*.conf; include /etc/nginx/vhosts-resources/mysite.ru/*.conf; access_log /var/www/httpd-logs/mysite.ru.access.log; error_log /var/www/httpd-logs/mysite.ru.error.log notice; set $root_path /var/www/www-root/data/www/mysite.ru; root $root_path; location / { location ~ [^/]\.ph(p\d*|tml)$ { try_files /does_not_exists @fallback; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|woff|woff2|ico|ttf)$ { try_files $uri $uri/ @fallback; expires 30d; } location / { try_files /does_not_exists @fallback; } } location @fallback { proxy_cache mysite.ru; proxy_cache_revalidate on; proxy_ignore_headers Expires Cache-Control X-Accel-Expires; #proxy_hide_header "Set-Cookie"; #expires -1; #add_header Last-Modified $sent_http_Expires; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504; proxy_cache_bypass $skip_cache; proxy_no_cache $skip_cache; proxy_cache_valid 301 302 0; proxy_cache_valid 200 24h; proxy_cache_valid 404 502 503 1m; # mobile users set $is_mobile 0; if ($http_user_agent ~* '(iPhone|iPod|mobile|Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile)') { set $is_mobile 1; } set $is_gzip 0; if ($http_accept_encoding ~* 'gzip') { set $is_gzip 1; } proxy_cache_key $request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$is_args|$is_mobile|$is_gzip; proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port; access_log off; } gzip on; gzip_comp_level 9; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; listen 19.19.19.19:443 ssl http2; } этот конфиг кэширует прокси запросы к apache, при отдаче сообщает в заголовках ответа, если есть в кэше то HIT а если нету то MISS. Проблема в том что при запросах из браузера (http 2 по логам) запросы кэшируются, первый MISS последующие HIT. А когда запрос идет через curl (http 1.0 по логам) то все время MISS. Подскажите что я делаю не так? Как сделать чтобы HTTP 1.0 тоже сохранялся в кэше? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286046,286046#msg-286046 From nginx-forum на forum.nginx.org Wed Oct 30 08:14:37 2019 From: nginx-forum на forum.nginx.org (ngnx8810773a83) Date: Wed, 30 Oct 2019 04:14:37 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINC90LUg0LrRjdGI0LjRgNGD0LXRgiBodHRwIDEuMA==?= In-Reply-To: References: Message-ID: <8d8fe373fb3eb8b365715a3efd9f726e.NginxMailingListRussian@forum.nginx.org> curl -v наверное поекажет в ответе Set-Cookie: заголовок ? наверное у вас в курле сессии нет и апач хочет её сделать. и весрия http тут непричем. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286046,286054#msg-286054 From nginx-forum на forum.nginx.org Thu Oct 31 14:07:08 2019 From: nginx-forum на forum.nginx.org (stitrace) Date: Thu, 31 Oct 2019 10:07:08 -0400 Subject: =?UTF-8?B?bmdpbngg0YjQu9GR0YIgc3lzbG9nINGC0L7Qu9GM0LrQviDRgSDQvtC00L3QvtCz?= =?UTF-8?B?0L4g0LjQvdGC0LXRgNGE0LXQudGB0LA=?= Message-ID: <32e5dce2b8065e10805831ce03825294.NginxMailingListRussian@forum.nginx.org> На сервере два сетевых интерфейса, один "смотрит" в internet, второй в локальую сеть (192.168.0.0/24). Если: access_log syslog:server=internet_site.ru:514,facility=local7,tag=nginx,severity=info mainlog; Где internet_site.ru это адрес где-то в интернете, то логи шлются нормально. Если: access_log syslog:server=192.168.0.10:514,facility=local7,tag=nginx,severity=info mainlog; То лог nginx не отсылает (проверяю tcpdump 'port 514'). Проверено на: Debian GNU/Linux 9 (stretch) nginx/1.14.2 и Gentoo/Linux nginx/1.11.8 С отключеными фаерволами. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286061,286061#msg-286061 From nginx-forum на forum.nginx.org Thu Oct 31 15:00:46 2019 From: nginx-forum на forum.nginx.org (stitrace) Date: Thu, 31 Oct 2019 11:00:46 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INGI0LvRkdGCIHN5c2xvZyDRgtC+0LvRjNC60L4g0YEg0L7QtNC9?= =?UTF-8?B?0L7Qs9C+INC40L3RgtC10YDRhNC10LnRgdCw?= In-Reply-To: <32e5dce2b8065e10805831ce03825294.NginxMailingListRussian@forum.nginx.org> References: <32e5dce2b8065e10805831ce03825294.NginxMailingListRussian@forum.nginx.org> Message-ID: <5afe39188d19b50dfaceafa4803bfc8c.NginxMailingListRussian@forum.nginx.org> Прошу прощения, не учёл, что nginx шлёт по UDP, всё в работает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286061,286062#msg-286062