From xeioex на nginx.com Tue Sep 1 04:56:37 2020 From: xeioex на nginx.com (Dmitry Volyntsev) Date: Tue, 1 Sep 2020 07:56:37 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?= =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?= In-Reply-To: <8CA18B57-1AB9-4239-A27C-B9B0CDB471D5@me.com> References: <20200831133331.GX12747@mdounin.ru> <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com> <20200831164118.GY12747@mdounin.ru> <8CA18B57-1AB9-4239-A27C-B9B0CDB471D5@me.com> Message-ID: <0a5ea337-bf87-f769-ba53-eb12b3dd5013@nginx.com> On 01.09.2020 00:42, Alexey Galygin wrote: > > но на всякий случай, может есть версия как-то это нативно переписать > для конфига без всяких языков и модулей? > какие есть рекомендации? (совсем выкидывать всё же стрёмно…) А подскажите свою версию njs (Если njs ставился из официальных пакетов, будет доступен бинарник njs, и тогда версию можно узнать так `njs -v`). > оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + Ubuntu 20.04 менялась ли версия njs при апгрейде? Если нет, единственное что пока приходит на ум это изменения в версии libpcre между дистрибутивами. Как воркараунд можно попробовать переписать эти функции без использования глобальных регулярок (наиболее вероятное место проблемы). function unescapeURI(r) {         return r.uri.replace(/%20/g, " "); } -> 1) // идентична по поведению исходной функции function unescapeURI(r) {         return r.uri.split(/%20/).join(" "); } 2) // более стандартный метод, но заменит все %-encoded комбинации https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/decodeURI function unescapeURI(r) {         return decodeURI(r.uri); } function escapeURI(r) {         return r.uri.replace(/\s/g, "%20").replace(/_/g, "%5F"); } -> 1) // идентична по поведению исходной функции function escapeURI(r) {         return r.uri.split(" ").join("%20").split("_").join("%5F"); } 2) // более стандартный метод, но заменит все %-encoded комбинации https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/encodeURI function escapeURI(r) {         return encodeURI(r.uri); } From mif на me.com Tue Sep 1 05:59:52 2020 From: mif на me.com (Alexey Galygin) Date: Tue, 1 Sep 2020 08:59:52 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?= =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?= In-Reply-To: <0a5ea337-bf87-f769-ba53-eb12b3dd5013@nginx.com> References: <20200831133331.GX12747@mdounin.ru> <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com> <20200831164118.GY12747@mdounin.ru> <8CA18B57-1AB9-4239-A27C-B9B0CDB471D5@me.com> <0a5ea337-bf87-f769-ba53-eb12b3dd5013@nginx.com> Message-ID: nginx из официального докер образа 1.18.0 njs шла в комплекте и отдельно не ставилась — 0.4.2 вообще никак не вмешивались… за альтернативу кода спасибо! сейчас думаем, как бы аккуратно выпилить эти артефакты совсем > On 1 Sep 2020, at 07:56, Dmitry Volyntsev wrote: > > > On 01.09.2020 00:42, Alexey Galygin wrote: >> >> но на всякий случай, может есть версия как-то это нативно переписать для конфига без всяких языков и модулей? >> какие есть рекомендации? (совсем выкидывать всё же стрёмно…) > > А подскажите свою версию njs (Если njs ставился из официальных пакетов, будет доступен бинарник njs, и тогда версию можно узнать так `njs -v`). > > > оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + Ubuntu 20.04 > > менялась ли версия njs при апгрейде? Если нет, единственное что пока приходит на ум это изменения в версии libpcre между дистрибутивами. > > Как воркараунд можно попробовать переписать эти функции без использования глобальных регулярок (наиболее вероятное место проблемы). > > function unescapeURI(r) { > return r.uri.replace(/%20/g, " "); > } > > -> > > 1) > // идентична по поведению исходной функции > function unescapeURI(r) { > return r.uri.split(/%20/).join(" "); > } > > 2) > // более стандартный метод, но заменит все %-encoded комбинации > https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/decodeURI > function unescapeURI(r) { > return decodeURI(r.uri); > } > > > function escapeURI(r) { > return r.uri.replace(/\s/g, "%20").replace(/_/g, "%5F"); > } > > -> > > 1) > // идентична по поведению исходной функции > function escapeURI(r) { > return r.uri.split(" ").join("%20").split("_").join("%5F"); > } > > 2) > // более стандартный метод, но заменит все %-encoded комбинации > https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/encodeURI > function escapeURI(r) { > return encodeURI(r.uri); > } > From xeioex на nginx.com Tue Sep 1 17:51:26 2020 From: xeioex на nginx.com (Dmitry Volyntsev) Date: Tue, 1 Sep 2020 20:51:26 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?= =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?= In-Reply-To: References: <20200831133331.GX12747@mdounin.ru> <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com> <20200831164118.GY12747@mdounin.ru> <8CA18B57-1AB9-4239-A27C-B9B0CDB471D5@me.com> <0a5ea337-bf87-f769-ba53-eb12b3dd5013@nginx.com> Message-ID: <050e20d8-0c21-e96c-68a8-efb63db35ee6@nginx.com> On 01.09.2020 08:59, Alexey Galygin wrote: > nginx из официального докер образа 1.18.0 > njs шла в комплекте и отдельно не ставилась — 0.4.2 > вообще никак не вмешивались… > > за альтернативу кода спасибо! > сейчас думаем, как бы аккуратно выпилить эти артефакты совсем > > Спасибо за баг-репорт. Могу подтвердить что проблема в NJS и появилась в версии 0.4.2 (вероятно обновилась вместе деплоем нового образа?). Удалось воспроизвести проблему самостоятельно. Она действительно оказалась связана с регулярными выражениями, а точнее с глобальным реплейсом replace(/_/g, "%5F"). При определенных условиях код мог уходить в endless-loop при этом поглощая всю доступную память. Исправленная версия приедет в 0.4.4. Уточнее касательно исходных сниппетов: function unescapeURI(r) { return r.uri.replace(/%20/g, ' '); } r.uri уже возвращает unescaped версию URI, и replace(/%20/g, ' ') вернет исходный URI. Как результат $uri $unescaped_uri должны быть идентичными. >> On 1 Sep 2020, at 07:56, Dmitry Volyntsev wrote: >> >> >> On 01.09.2020 00:42, Alexey Galygin wrote: >>> но на всякий случай, может есть версия как-то это нативно переписать для конфига без всяких языков и модулей? >>> какие есть рекомендации? (совсем выкидывать всё же стрёмно…) >> А подскажите свою версию njs (Если njs ставился из официальных пакетов, будет доступен бинарник njs, и тогда версию можно узнать так `njs -v`). >> >>> оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + Ubuntu 20.04 >> менялась ли версия njs при апгрейде? Если нет, единственное что пока приходит на ум это изменения в версии libpcre между дистрибутивами. >> >> Как воркараунд можно попробовать переписать эти функции без использования глобальных регулярок (наиболее вероятное место проблемы). >> >> function unescapeURI(r) { >> return r.uri.replace(/%20/g, " "); >> } >> >> -> >> >> 1) >> // идентична по поведению исходной функции >> function unescapeURI(r) { >> return r.uri.split(/%20/).join(" "); >> } >> >> 2) >> // более стандартный метод, но заменит все %-encoded комбинации >> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/decodeURI >> function unescapeURI(r) { >> return decodeURI(r.uri); >> } >> >> >> function escapeURI(r) { >> return r.uri.replace(/\s/g, "%20").replace(/_/g, "%5F"); >> } >> >> -> >> >> 1) >> // идентична по поведению исходной функции >> function escapeURI(r) { >> return r.uri.split(" ").join("%20").split("_").join("%5F"); >> } >> >> 2) >> // более стандартный метод, но заменит все %-encoded комбинации >> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/encodeURI >> function escapeURI(r) { >> return encodeURI(r.uri); >> } >> From mif на me.com Tue Sep 1 18:07:04 2020 From: mif на me.com (Alexey Galygin) Date: Tue, 1 Sep 2020 21:07:04 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?= =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?= In-Reply-To: <050e20d8-0c21-e96c-68a8-efb63db35ee6@nginx.com> References: <20200831133331.GX12747@mdounin.ru> <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com> <20200831164118.GY12747@mdounin.ru> <8CA18B57-1AB9-4239-A27C-B9B0CDB471D5@me.com> <0a5ea337-bf87-f769-ba53-eb12b3dd5013@nginx.com> <050e20d8-0c21-e96c-68a8-efb63db35ee6@nginx.com> Message-ID: <8D974D3F-7A2B-419E-8DD6-884EB8FDC876@me.com> да, спасибо за внимание и поддержку! удивительно, но на старом сервере действительно NJS младше: 0.4.0 хотя ставятся из одного докерфайла (и сегодня я даже пересобирал контейнер) мы также пришли к выводу, что пара переменных точно будет похожа (к тому же править частично — это странная практика) в итоге нашлось решение без NJS использовать $uri как unescaped-форму и вот такую конструкцию для получения исходной формы: map $request_uri $escaped_uri { "~^(?P[^?]*)(\?.*)?$" $path; } в итоге… мы поизучали свои данные и вообще это всё выкинули, оставив $uri — нечего баловать пользователей ;-) > On 1 Sep 2020, at 20:51, Dmitry Volyntsev wrote: > > > On 01.09.2020 08:59, Alexey Galygin wrote: >> nginx из официального докер образа 1.18.0 >> njs шла в комплекте и отдельно не ставилась — 0.4.2 >> вообще никак не вмешивались… >> >> за альтернативу кода спасибо! >> сейчас думаем, как бы аккуратно выпилить эти артефакты совсем >> >> > Спасибо за баг-репорт. Могу подтвердить что проблема в NJS и появилась в версии 0.4.2 (вероятно обновилась вместе деплоем нового образа?). > > Удалось воспроизвести проблему самостоятельно. Она действительно оказалась связана с регулярными выражениями, а точнее с глобальным реплейсом replace(/_/g, "%5F"). При определенных условиях код мог уходить в endless-loop при этом поглощая всю доступную память. Исправленная версия приедет в 0.4.4. > > Уточнее касательно исходных сниппетов: > > function unescapeURI(r) { return r.uri.replace(/%20/g, ' '); } > > r.uri уже возвращает unescaped версию URI, и replace(/%20/g, ' ') вернет исходный URI. > Как результат $uri $unescaped_uri должны быть идентичными. > >>> On 1 Sep 2020, at 07:56, Dmitry Volyntsev wrote: >>> >>> >>> On 01.09.2020 00:42, Alexey Galygin wrote: >>>> но на всякий случай, может есть версия как-то это нативно переписать для конфига без всяких языков и модулей? >>>> какие есть рекомендации? (совсем выкидывать всё же стрёмно…) >>> А подскажите свою версию njs (Если njs ставился из официальных пакетов, будет доступен бинарник njs, и тогда версию можно узнать так `njs -v`). >>> >>>> оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + Ubuntu 20.04 >>> менялась ли версия njs при апгрейде? Если нет, единственное что пока приходит на ум это изменения в версии libpcre между дистрибутивами. >>> >>> Как воркараунд можно попробовать переписать эти функции без использования глобальных регулярок (наиболее вероятное место проблемы). >>> >>> function unescapeURI(r) { >>> return r.uri.replace(/%20/g, " "); >>> } >>> >>> -> >>> >>> 1) >>> // идентична по поведению исходной функции >>> function unescapeURI(r) { >>> return r.uri.split(/%20/).join(" "); >>> } >>> >>> 2) >>> // более стандартный метод, но заменит все %-encoded комбинации >>> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/decodeURI >>> function unescapeURI(r) { >>> return decodeURI(r.uri); >>> } >>> >>> >>> function escapeURI(r) { >>> return r.uri.replace(/\s/g, "%20").replace(/_/g, "%5F"); >>> } >>> >>> -> >>> >>> 1) >>> // идентична по поведению исходной функции >>> function escapeURI(r) { >>> return r.uri.split(" ").join("%20").split("_").join("%5F"); >>> } >>> >>> 2) >>> // более стандартный метод, но заменит все %-encoded комбинации >>> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/encodeURI >>> function escapeURI(r) { >>> return encodeURI(r.uri); >>> } >>> From mif на me.com Tue Sep 1 18:59:57 2020 From: mif на me.com (Alexey Galygin) Date: Tue, 1 Sep 2020 21:59:57 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?= =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?= In-Reply-To: <8D974D3F-7A2B-419E-8DD6-884EB8FDC876@me.com> References: <20200831133331.GX12747@mdounin.ru> <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com> <20200831164118.GY12747@mdounin.ru> <8CA18B57-1AB9-4239-A27C-B9B0CDB471D5@me.com> <0a5ea337-bf87-f769-ba53-eb12b3dd5013@nginx.com> <050e20d8-0c21-e96c-68a8-efb63db35ee6@nginx.com> <8D974D3F-7A2B-419E-8DD6-884EB8FDC876@me.com> Message-ID: <2D806B55-14B1-4A21-A7E6-E77F0C74FF22@me.com> действительно Dockerfile обновился, но docker оказывается сам его не отслеживает и не перекачивает обновление с той же версией можно обновить — docker pull nginx:1.18.0 и тогда пришёл новый докерфайл/image — иначе всё из кэша бралось ENV NJS_VERSION 0.4.2 бэст-практика для прода фиксировать версию, а не использовать latest тут не сработала: кто бы мог предположить, что возможны правки в том, чего вроде как и не ожидаешь (в Dockerfile привязанном тегом к конкретной версии), что может тихо измениться (то что вроде бы должно намертво фиксироваться) docker history было: IMAGE CREATED CREATED BY SIZE COMMENT … 3 months ago /bin/sh -c #(nop) ENV PKG_RELEASE=1~buster 0B 3 months ago /bin/sh -c #(nop) ENV NJS_VERSION=0.4.0 0B 3 months ago /bin/sh -c #(nop) ENV NGINX_VERSION=1.18.0 0B 3 months ago /bin/sh -c #(nop) LABEL maintainer=NGINX Do… 0B 3 months ago /bin/sh -c #(nop) CMD ["bash"] 0B 3 months ago /bin/sh -c #(nop) ADD file:7780c81c33e6cc5b6… 69.2MB стало после docker pull nginx:1.18.0 IMAGE CREATED CREATED BY SIZE COMMENT … 3 months ago /bin/sh -c #(nop) ENV PKG_RELEASE=1~buster 0B 3 weeks ago /bin/sh -c #(nop) ENV NJS_VERSION=0.4.2 0B 3 weeks ago /bin/sh -c #(nop) ENV NGINX_VERSION=1.18.0 0B 3 weeks ago /bin/sh -c #(nop) LABEL maintainer=NGINX Do… 0B 4 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B 4 weeks ago /bin/sh -c #(nop) ADD file:3af3091e7d2bb40bc… 69.2MB и это ведь неочевидно, интуитивно отбрасывается и не учитывается при поиске проблем… > On 1 Sep 2020, at 21:07, Alexey Galygin wrote: > > да, спасибо за внимание и поддержку! > > удивительно, но на старом сервере действительно NJS младше: 0.4.0 > хотя ставятся из одного докерфайла (и сегодня я даже пересобирал контейнер) > > мы также пришли к выводу, что пара переменных точно будет похожа (к тому же править частично — это странная практика) > в итоге нашлось решение без NJS > > использовать $uri как unescaped-форму > и вот такую конструкцию для получения исходной формы: > > map $request_uri $escaped_uri { > "~^(?P[^?]*)(\?.*)?$" $path; > } > > в итоге… мы поизучали свои данные и вообще это всё выкинули, оставив $uri — нечего баловать пользователей ;-) > > > > >> On 1 Sep 2020, at 20:51, Dmitry Volyntsev wrote: >> >> >> On 01.09.2020 08:59, Alexey Galygin wrote: >>> nginx из официального докер образа 1.18.0 >>> njs шла в комплекте и отдельно не ставилась — 0.4.2 >>> вообще никак не вмешивались… >>> >>> за альтернативу кода спасибо! >>> сейчас думаем, как бы аккуратно выпилить эти артефакты совсем >>> >>> >> Спасибо за баг-репорт. Могу подтвердить что проблема в NJS и появилась в версии 0.4.2 (вероятно обновилась вместе деплоем нового образа?). >> >> Удалось воспроизвести проблему самостоятельно. Она действительно оказалась связана с регулярными выражениями, а точнее с глобальным реплейсом replace(/_/g, "%5F"). При определенных условиях код мог уходить в endless-loop при этом поглощая всю доступную память. Исправленная версия приедет в 0.4.4. >> >> Уточнее касательно исходных сниппетов: >> >> function unescapeURI(r) { return r.uri.replace(/%20/g, ' '); } >> >> r.uri уже возвращает unescaped версию URI, и replace(/%20/g, ' ') вернет исходный URI. >> Как результат $uri $unescaped_uri должны быть идентичными. >> >>>> On 1 Sep 2020, at 07:56, Dmitry Volyntsev wrote: >>>> >>>> >>>> On 01.09.2020 00:42, Alexey Galygin wrote: >>>>> но на всякий случай, может есть версия как-то это нативно переписать для конфига без всяких языков и модулей? >>>>> какие есть рекомендации? (совсем выкидывать всё же стрёмно…) >>>> А подскажите свою версию njs (Если njs ставился из официальных пакетов, будет доступен бинарник njs, и тогда версию можно узнать так `njs -v`). >>>> >>>>> оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + Ubuntu 20.04 >>>> менялась ли версия njs при апгрейде? Если нет, единственное что пока приходит на ум это изменения в версии libpcre между дистрибутивами. >>>> >>>> Как воркараунд можно попробовать переписать эти функции без использования глобальных регулярок (наиболее вероятное место проблемы). >>>> >>>> function unescapeURI(r) { >>>> return r.uri.replace(/%20/g, " "); >>>> } >>>> >>>> -> >>>> >>>> 1) >>>> // идентична по поведению исходной функции >>>> function unescapeURI(r) { >>>> return r.uri.split(/%20/).join(" "); >>>> } >>>> >>>> 2) >>>> // более стандартный метод, но заменит все %-encoded комбинации >>>> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/decodeURI >>>> function unescapeURI(r) { >>>> return decodeURI(r.uri); >>>> } >>>> >>>> >>>> function escapeURI(r) { >>>> return r.uri.replace(/\s/g, "%20").replace(/_/g, "%5F"); >>>> } >>>> >>>> -> >>>> >>>> 1) >>>> // идентична по поведению исходной функции >>>> function escapeURI(r) { >>>> return r.uri.split(" ").join("%20").split("_").join("%5F"); >>>> } >>>> >>>> 2) >>>> // более стандартный метод, но заменит все %-encoded комбинации >>>> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/encodeURI >>>> function escapeURI(r) { >>>> return encodeURI(r.uri); >>>> } >>>> > From nginx-forum на forum.nginx.org Wed Sep 2 04:30:56 2020 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Wed, 02 Sep 2020 00:30:56 -0400 Subject: =?UTF-8?B?0KDQtdCz0YPQu9GP0YDQutCwINC00LvRjyDQv9GA0L7QsdC10LvQsCDQsiByZXF1?= =?UTF-8?B?ZXN0IHVyaQ==?= Message-ID: Время от времени приходят какие-то странные УРЛы вида: "https://example.com/ https:/example.com/category/date/news-name/" хотелось бы их редиректить Пытался сделать так: if ($request_uri ~* "^/\shttps:") { rewrite "^/\shttps:/example.com/(.*)$" https://example.com/$1 permanent; } но не срабатывает. Пробовал по разному закодировать пробел, но нужного варианта не нашел. Подскажите как правильно это обработать. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289280,289280#msg-289280 From bgx на protva.ru Wed Sep 2 06:42:50 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 2 Sep 2020 09:42:50 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0LrQsCDQtNC70Y8g0L/RgNC+0LHQtdC70LAg0LIg?= =?UTF-8?B?cmVxdWVzdCB1cmk=?= In-Reply-To: References: Message-ID: <20200902064250.GA2679@sie.protva.ru> On Wed, Sep 02, 2020 at 12:30:56AM -0400, Dmytro Lavryk wrote: > Время от времени приходят какие-то странные УРЛы вида: > "https://example.com/ https:/example.com/category/date/news-name/" ... > Подскажите как правильно это обработать. Правильно это разобраться откуда такие урлы берутся и пофиксить клиента. Такие урлы могут возникать из-за того, что в каком-то документе (например, в письме из рассылки) ссылка создана неправильно, а браузер тупо обрабатывает некорректный href. Для начала посмотрите реферер. -- Eugene Berdnikov From root на dl.sm.ua Wed Sep 2 07:01:40 2020 From: root на dl.sm.ua (Dmytro Lavryk) Date: Wed, 02 Sep 2020 10:01:40 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0LrQsCDQtNC70Y8g0L/RgNC+0LHQtdC70LAg0LIg?= =?UTF-8?B?cmVxdWVzdCB1cmk=?= In-Reply-To: <20200902064250.GA2679@sie.protva.ru> References: <20200902064250.GA2679@sie.protva.ru> Message-ID: <1744d9f0200.12967b53a95654.4698356521653271462@dl.sm.ua> Я совершенно с вами согласен, что правильнее такие ссылки исключить, но система принятия решений достаточно громоздкая, кроме того такие ссылки УЖЕ есть где-то в каком-то количестве. Потому все же моя задача сделать часть СВОЕЙ работы и пофиксить со своей стороны, а там дальше будут заниматься отдельные люди поиском причин возникновения. ---- Увімкнуто ср, 02 вер. 2020 09:42:50 +0300 Evgeniy Berdnikov написав ---- On Wed, Sep 02, 2020 at 12:30:56AM -0400, Dmytro Lavryk wrote: > Время от времени приходят какие-то странные УРЛы вида: > "https://example.com/ https:/example.com/category/date/news-name/" ... > Подскажите как правильно это обработать. Правильно это разобраться откуда такие урлы берутся и пофиксить клиента. Такие урлы могут возникать из-за того, что в каком-то документе (например, в письме из рассылки) ссылка создана неправильно, а браузер тупо обрабатывает некорректный href. Для начала посмотрите реферер. -- Eugene Berdnikov _______________________________________________ nginx-ru mailing list mailto:nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From thresh на nginx.com Wed Sep 2 08:58:57 2020 From: thresh на nginx.com (Konstantin Pavlov) Date: Wed, 2 Sep 2020 11:58:57 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?= =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?= In-Reply-To: <2D806B55-14B1-4A21-A7E6-E77F0C74FF22@me.com> References: <20200831133331.GX12747@mdounin.ru> <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com> <20200831164118.GY12747@mdounin.ru> <8CA18B57-1AB9-4239-A27C-B9B0CDB471D5@me.com> <0a5ea337-bf87-f769-ba53-eb12b3dd5013@nginx.com> <050e20d8-0c21-e96c-68a8-efb63db35ee6@nginx.com> <8D974D3F-7A2B-419E-8DD6-884EB8FDC876@me.com> <2D806B55-14B1-4A21-A7E6-E77F0C74FF22@me.com> Message-ID: Здравствуйте, 01.09.2020 21:59, Alexey Galygin wrote: > действительно > > Dockerfile обновился, но docker оказывается сам его не отслеживает и не перекачивает > обновление с той же версией можно обновить — docker pull nginx:1.18.0 > > и тогда пришёл новый докерфайл/image — иначе всё из кэша бралось > ENV NJS_VERSION 0.4.2 > > бэст-практика для прода фиксировать версию, а не использовать latest тут не сработала: > кто бы мог предположить, что возможны правки в том, чего вроде как и не ожидаешь (в Dockerfile привязанном тегом к конкретной версии), что может тихо измениться (то что вроде бы должно намертво фиксироваться) > и это ведь неочевидно, интуитивно отбрасывается и не учитывается при поиске проблем… > Более того, версии зависимостей могут быть обновлены в новом image даже если изменений в Dockerfile не было - официальные образа мантейнеры официальной библиотеки docker hub (т.е. не мы) пересобирают периодически для закрытия различных CVE. Я могу только рекомендовать не брать ничего из docker hub, а пересобирать и держать все используемые образа в локальном registry. -- Konstantin Pavlov https://www.nginx.com/ From shadow.tehb на gmail.com Thu Sep 3 05:40:04 2020 From: shadow.tehb на gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCe0LvQtdCz0L7QstC40Yc=?=) Date: Thu, 03 Sep 2020 08:40:04 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0LrQsCDQtNC70Y8g0L/RgNC+0LHQtdC70LAg0LIg?= =?UTF-8?B?cmVxdWVzdCB1cmk=?= In-Reply-To: <1744d9f0200.12967b53a95654.4698356521653271462@dl.sm.ua> References: <20200902064250.GA2679@sie.protva.ru> <1744d9f0200.12967b53a95654.4698356521653271462@dl.sm.ua> Message-ID: <174527aa720.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com> Как вариант общей схемы. map: $request_uri и $new_request_uri. И location с регуляркой в котором будет редирект на новый запрос. По поводу обработки пробела - пишите как пробовали. Dmytro Lavryk 2 сентября 2020 г. 10:02:05 написал: > Я совершенно с вами согласен, что правильнее такие ссылки исключить, но > система принятия решений достаточно громоздкая, кроме того такие ссылки УЖЕ > есть где-то в каком-то количестве. Потому все же моя задача сделать часть > СВОЕЙ работы и пофиксить со своей стороны, а там дальше будут заниматься > отдельные люди поиском причин возникновения. > > ---- Увімкнуто ср, 02 вер. 2020 09:42:50 +0300 Evgeniy Berdnikov > написав ---- > > On Wed, Sep 02, 2020 at 12:30:56AM -0400, Dmytro Lavryk wrote: >> Время от времени приходят какие-то странные УРЛы вида: >> "https://example.com/ https:/example.com/category/date/news-name/" > ... >> Подскажите как правильно это обработать. > > Правильно это разобраться откуда такие урлы берутся и пофиксить клиента. > > Такие урлы могут возникать из-за того, что в каком-то документе > (например, в письме из рассылки) ссылка создана неправильно, а браузер > тупо обрабатывает некорректный href. Для начала посмотрите реферер. > -- > Eugene Berdnikov > _______________________________________________ > 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 root на dl.sm.ua Thu Sep 3 10:09:01 2020 From: root на dl.sm.ua (Dmytro Lavryk) Date: Thu, 03 Sep 2020 13:09:01 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0LrQsCDQtNC70Y8g0L/RgNC+0LHQtdC70LAg0LIg?= =?UTF-8?B?cmVxdWVzdCB1cmk=?= In-Reply-To: <174527aa720.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com> References: <20200902064250.GA2679@sie.protva.ru> <1744d9f0200.12967b53a95654.4698356521653271462@dl.sm.ua> <174527aa720.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com> Message-ID: <1745370e4f0.f4f6144f161870.522627026595286090@dl.sm.ua> Через map опять же нужна регулярка с пробелом... Или я чего-то не понимаю. Пробовал еще 2 варианта: if ($request_uri ~* "^/ https:") {     rewrite "^/ https:/example.com/(.*)$" https://example.com/$1 permanent; } if ($request_uri ~* "^/%20https:") {     rewrite "^/%20https:/example.com/(.*)$" https://example.com/$1 permanent; } Результата нет во всех трех случаях. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From red-fox0 на ya.ru Thu Sep 3 10:36:42 2020 From: red-fox0 на ya.ru (fox) Date: Thu, 3 Sep 2020 17:36:42 +0700 Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0LrQsCDQtNC70Y8g0L/RgNC+0LHQtdC70LAg0LIg?= =?UTF-8?B?cmVxdWVzdCB1cmk=?= In-Reply-To: <1745370e4f0.f4f6144f161870.522627026595286090@dl.sm.ua> References: <20200902064250.GA2679@sie.protva.ru> <1744d9f0200.12967b53a95654.4698356521653271462@dl.sm.ua> <174527aa720.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com> <1745370e4f0.f4f6144f161870.522627026595286090@dl.sm.ua> Message-ID: <57805b1c-cd34-8c48-c21c-36fd7f1133cb@ya.ru> location ~ "/ http\:(.*)$" { return 302 https://$host$1; } 03.09.2020 17:09, Dmytro Lavryk пишет: > Через map опять же нужна регулярка с пробелом... Или я чего-то не понимаю. > > > Пробовал еще 2 варианта: > > if ($request_uri ~* "^/ https:") { >     rewrite "^/ https:/example.com/(.*)$" https://example.com/$1 permanent; > } > > if ($request_uri ~* "^/%20https:") { >     rewrite "^/%20https:/example.com/(.*)$" > https://example.com/$1 permanent; > > } > > Результата нет во всех трех случаях. > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From root на dl.sm.ua Thu Sep 3 13:54:04 2020 From: root на dl.sm.ua (Dmytro Lavryk) Date: Thu, 03 Sep 2020 16:54:04 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0LrQsCDQtNC70Y8g0L/RgNC+0LHQtdC70LAg0LIg?= =?UTF-8?B?cmVxdWVzdCB1cmk=?= In-Reply-To: <57805b1c-cd34-8c48-c21c-36fd7f1133cb@ya.ru> References: <20200902064250.GA2679@sie.protva.ru> <1744d9f0200.12967b53a95654.4698356521653271462@dl.sm.ua> <174527aa720.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com> <1745370e4f0.f4f6144f161870.522627026595286090@dl.sm.ua> <57805b1c-cd34-8c48-c21c-36fd7f1133cb@ya.ru> Message-ID: <174543eee28.bbaf0e03178781.3831802483310150882@dl.sm.ua> Да, в location пробел в регулярке нормально срабатывает. Спасибо. Вот так по итогу получилось: location ~* "^/ https\:\/example\.com\/(.*)$" {         return 301 https://example.com/$1; } ---- Увімкнуто чт, 03 вер. 2020 13:36:42 +0300 fox написав ---- location ~ "/ http\:(.*)$" { return 302 https://$host$1; } 03.09.2020 17:09, Dmytro Lavryk пишет: > Через map опять же нужна регулярка с пробелом... Или я чего-то не понимаю. > > > Пробовал еще 2 варианта: > > if ($request_uri ~* "^/ https:") { >     rewrite "^/ https:/example.com/(.*)$" https://example.com/$1 permanent; > } > > if ($request_uri ~* "^/%20https:") { >     rewrite "^/%20https:/example.com/(.*)$" > https://example.com/$1 permanent; > > } > > Результата нет во всех трех случаях. > > > > _______________________________________________ > nginx-ru mailing list > mailto:nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ nginx-ru mailing list mailto:nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Thu Sep 3 16:38:55 2020 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 3 Sep 2020 19:38:55 +0300 Subject: proxy timeout code Message-ID: <20200903163855.GP2015@zxy.spb.ru> А есть какой-либо код у upstream timeout? Хочется для auth_request по таймауту считать OK. Ну а для этого прописать что-то типа error_page XXX =200 /50x.html Но что писать для XXX? From mdounin на mdounin.ru Thu Sep 3 16:42:59 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 3 Sep 2020 19:42:59 +0300 Subject: proxy timeout code In-Reply-To: <20200903163855.GP2015@zxy.spb.ru> References: <20200903163855.GP2015@zxy.spb.ru> Message-ID: <20200903164259.GD12747@mdounin.ru> Hello! On Thu, Sep 03, 2020 at 07:38:55PM +0300, Slawa Olhovchenkov wrote: > А есть какой-либо код у upstream timeout? > Хочется для auth_request по таймауту считать OK. > Ну а для этого прописать что-то типа > > error_page XXX =200 /50x.html > > Но что писать для XXX? 504 Gateway Timeout https://tools.ietf.org/html/rfc7231#section-6.6.5 -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Thu Sep 3 16:47:54 2020 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 3 Sep 2020 19:47:54 +0300 Subject: proxy timeout code In-Reply-To: <20200903164259.GD12747@mdounin.ru> References: <20200903163855.GP2015@zxy.spb.ru> <20200903164259.GD12747@mdounin.ru> Message-ID: <20200903164754.GQ2015@zxy.spb.ru> On Thu, Sep 03, 2020 at 07:42:59PM +0300, Maxim Dounin wrote: > Hello! > > On Thu, Sep 03, 2020 at 07:38:55PM +0300, Slawa Olhovchenkov wrote: > > > А есть какой-либо код у upstream timeout? > > Хочется для auth_request по таймауту считать OK. > > Ну а для этого прописать что-то типа > > > > error_page XXX =200 /50x.html > > > > Но что писать для XXX? > > 504 Gateway Timeout > https://tools.ietf.org/html/rfc7231#section-6.6.5 Спасибо, просто как-то в логах не обнаружил в явном виде. А если так все апстримы будут заблокированны ("upstream server temporarily disabled while reading response header from upstream"), то с каким кодом будет auth_request фэйлится? (ну т.е. у него нет живых апстримов) From mdounin на mdounin.ru Thu Sep 3 17:47:01 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 3 Sep 2020 20:47:01 +0300 Subject: proxy timeout code In-Reply-To: <20200903164754.GQ2015@zxy.spb.ru> References: <20200903163855.GP2015@zxy.spb.ru> <20200903164259.GD12747@mdounin.ru> <20200903164754.GQ2015@zxy.spb.ru> Message-ID: <20200903174701.GE12747@mdounin.ru> Hello! On Thu, Sep 03, 2020 at 07:47:54PM +0300, Slawa Olhovchenkov wrote: > On Thu, Sep 03, 2020 at 07:42:59PM +0300, Maxim Dounin wrote: > > > Hello! > > > > On Thu, Sep 03, 2020 at 07:38:55PM +0300, Slawa Olhovchenkov wrote: > > > > > А есть какой-либо код у upstream timeout? > > > Хочется для auth_request по таймауту считать OK. > > > Ну а для этого прописать что-то типа > > > > > > error_page XXX =200 /50x.html > > > > > > Но что писать для XXX? > > > > 504 Gateway Timeout > > https://tools.ietf.org/html/rfc7231#section-6.6.5 > > Спасибо, просто как-то в логах не обнаружил в явном виде. > А если так все апстримы будут заблокированны ("upstream server > temporarily disabled while reading response header from upstream"), то > с каким кодом будет auth_request фэйлится? (ну т.е. у него нет > живых апстримов) 502 Bad Gateway https://tools.ietf.org/html/rfc7231#section-6.6.3 -- Maxim Dounin http://mdounin.ru/ From shilov на extmail.info Thu Sep 3 19:04:13 2020 From: shilov на extmail.info (Shilov) Date: Thu, 3 Sep 2020 22:04:13 +0300 Subject: =?UTF-8?B?0KjQuNGE0YDRg9GO0YLRgdGPINC70Lgg0LLQtdCxLdGB0L7QutC10YLRiz8=?= In-Reply-To: <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua> References: <20200829192144.086d7fbd2521179560589e90@extmail.info> <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua> <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua> <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info> <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua> Message-ID: <20200903220413.ff908f9ab45affc234ea9cbb@extmail.info> Привет всем! Есть локальный веб-сервер, который отдает информацию с помощью веб-сокетами. Перед ним стоит локальный реверсный прокси, перед которым, в свою очередь, в Инете стоит внешний реверсный прокси. Между этими прокси организован канал, зашифрованный с помощью httpS. Обращаясь к внешнему прокси, попадаем в конечном счете на локальный веб-сервер. Возникает вопрос: веб-сокеты в этом канале тоже шифруются, или проходят незашифрованными? Спасибо за конструктивный ответ. -- Shilov From panichev на rutarget.ru Fri Sep 4 10:33:18 2020 From: panichev на rutarget.ru (Panichev Oleg) Date: Fri, 4 Sep 2020 13:33:18 +0300 Subject: =?UTF-8?B?dXBzdHJlYW0gZmFzdGNnaSBrZWVwYWxpdmUuINCi0LDQuNC90YHRgtCy0LXQvdC9?= =?UTF-8?B?0YvQtSA0MNC80YE=?= Message-ID: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> Добрый день. При включении keepalive в секции upstream для fastcgi серверов upstream_response_time увеличивается на 40мс при нагрузке. Это достаточно четкий шаг, реальный ответ бэкендову нас - единицы миллисекунд, но nginx показывает на 40мс больше.  Apache benchmark tool показывает тоже самое. С чем связана именно такая задержка? Изменения таймаутов, количества реквестов на эти 40мс не влияют, в логе всегда либо единицы миллисекунд (время ответа для простых соединений, без включения keepalive), либо сразу 40мс+время простого запроса. Есть ли способ измерять реальное время ответа от бэкенда при использовании keepalive? Спасибо, ниже конфиги и результаты ab. =========================================================== Пробовал на свежем нджинксе и стартовой странице php-fpm: Проверка с keepalive:     upstream sync {        server localhost:9000;        keepalive 8;     } ..     location ~ \.php$ {         fastcgi_pass sync;         fastcgi_keep_conn on; ... Percentage of the requests served within a certain time (ms)   50%      3   66%      3   75%      4   80%     42   90%     43   95%     44   98%     44   99%     45  100%     52 (longest request) ========================== Без keepalive тот же апстрим: Percentage of the requests served within a certain time (ms)   50%      1   66%      1   75%      1   80%      1   90%      1   95%      2   98%      2   99%      3  100%      7 (longest request) Это повторяется на разных приложениях и разных фронтендах (см. скриншот) ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: 2020-09-04_13-28.png Тип: image/png Размер: 10980 байтов Описание: отсутствует URL: From shadow.tehb на gmail.com Fri Sep 4 11:07:44 2020 From: shadow.tehb на gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCe0LvQtdCz0L7QstC40Yc=?=) Date: Fri, 4 Sep 2020 14:07:44 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIGZhc3RjZ2kga2VlcGFsaXZlLiDQotCw0LjQvdGB0YLQstC1?= =?UTF-8?B?0L3QvdGL0LUgNDDQvNGB?= In-Reply-To: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> References: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> Message-ID: Интересно, а есть ли зависимость между количеством keepalive и временем? пт, 4 сент. 2020 г. в 13:33, Panichev Oleg : > Добрый день. > > > При включении keepalive в секции upstream для fastcgi серверов > upstream_response_time увеличивается на 40мс при нагрузке. Это > достаточно четкий шаг, реальный ответ бэкендову нас - единицы > миллисекунд, но nginx показывает на 40мс больше. Apache benchmark tool > показывает тоже самое. > > С чем связана именно такая задержка? Изменения таймаутов, количества > реквестов на эти 40мс не влияют, в логе всегда либо единицы миллисекунд > (время ответа для простых соединений, без включения keepalive), либо > сразу 40мс+время простого запроса. Есть ли способ измерять реальное > время ответа от бэкенда при использовании keepalive? > > Спасибо, ниже конфиги и результаты ab. > > > =========================================================== > > Пробовал на свежем нджинксе и стартовой странице php-fpm: > > Проверка с keepalive: > > upstream sync { > server localhost:9000; > keepalive 8; > } > > .. > > location ~ \.php$ { > fastcgi_pass sync; > fastcgi_keep_conn on; > ... > > Percentage of the requests served within a certain time (ms) > 50% 3 > 66% 3 > 75% 4 > 80% 42 > 90% 43 > 95% 44 > 98% 44 > 99% 45 > 100% 52 (longest request) > ========================== > > Без keepalive тот же апстрим: > > Percentage of the requests served within a certain time (ms) > 50% 1 > 66% 1 > 75% 1 > 80% 1 > 90% 1 > 95% 2 > 98% 2 > 99% 3 > 100% 7 (longest request) > > Это повторяется на разных приложениях и разных фронтендах (см. скриншот) > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From panichev на rutarget.ru Fri Sep 4 11:22:27 2020 From: panichev на rutarget.ru (Panichev Oleg) Date: Fri, 4 Sep 2020 14:22:27 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIGZhc3RjZ2kga2VlcGFsaXZlLiDQotCw0LjQvdGB0YLQstC1?= =?UTF-8?B?0L3QvdGL0LUgNDDQvNGB?= In-Reply-To: References: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> Message-ID: В данном случае, с пустым конфигом и php-fpm, зависимости либо нет, либо она незаметна: keepalive 1: Percentage of the requests served within a certain time (ms)   50%      3   66%      3   75%     41   80%     43   90%     44   95%     44   98%     44   99%     44  100%     55 (longest request) keepalive 100:   50%      3   66%      3   75%      4   80%     42   90%     43   95%     44   98%     44   99%     45  100%     47 (longest request) On 9/4/20 2:07 PM, Сергей Олегович wrote: > Интересно, а есть ли зависимость между количеством keepalive и временем? > > пт, 4 сент. 2020 г. в 13:33, Panichev Oleg >: > > Добрый день. > > > При включении keepalive в секции upstream для fastcgi серверов > upstream_response_time увеличивается на 40мс при нагрузке. Это > достаточно четкий шаг, реальный ответ бэкендову нас - единицы > миллисекунд, но nginx показывает на 40мс больше.  Apache benchmark > tool > показывает тоже самое. > > С чем связана именно такая задержка? Изменения таймаутов, количества > реквестов на эти 40мс не влияют, в логе всегда либо единицы > миллисекунд > (время ответа для простых соединений, без включения keepalive), либо > сразу 40мс+время простого запроса. Есть ли способ измерять реальное > время ответа от бэкенда при использовании keepalive? > > Спасибо, ниже конфиги и результаты ab. > > > =========================================================== > > Пробовал на свежем нджинксе и стартовой странице php-fpm: > > Проверка с keepalive: > >      upstream sync { >         server localhost:9000; >         keepalive 8; >      } > > .. > >      location ~ \.php$ { >          fastcgi_pass sync; >          fastcgi_keep_conn on; > ... > > Percentage of the requests served within a certain time (ms) >    50%      3 >    66%      3 >    75%      4 >    80%     42 >    90%     43 >    95%     44 >    98%     44 >    99%     45 >   100%     52 (longest request) > ========================== > > Без keepalive тот же апстрим: > > Percentage of the requests served within a certain time (ms) >    50%      1 >    66%      1 >    75%      1 >    80%      1 >    90%      1 >    95%      2 >    98%      2 >    99%      3 >   100%      7 (longest request) > > Это повторяется на разных приложениях и разных фронтендах (см. > скриншот) > > > > _______________________________________________ > 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 red-fox0 на ya.ru Fri Sep 4 12:29:06 2020 From: red-fox0 на ya.ru (fox) Date: Fri, 4 Sep 2020 19:29:06 +0700 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIGZhc3RjZ2kga2VlcGFsaXZlLiDQotCw0LjQvdGB0YLQstC1?= =?UTF-8?B?0L3QvdGL0LUgNDDQvNGB?= In-Reply-To: References: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> Message-ID: Пинг до сервера какой? Протокол http 1.1? 04.09.2020 18:22, Panichev Oleg пишет: > В данном случае, с пустым конфигом и php-fpm, зависимости либо нет, либо > она незаметна: > > > keepalive 1: > > Percentage of the requests served within a certain time (ms) >   50%      3 >   66%      3 >   75%     41 >   80%     43 >   90%     44 >   95%     44 >   98%     44 >   99%     44 >  100%     55 (longest request) > > keepalive 100: > >   50%      3 >   66%      3 >   75%      4 >   80%     42 >   90%     43 >   95%     44 >   98%     44 >   99%     45 > >  100%     47 (longest request) > > > > On 9/4/20 2:07 PM, Сергей Олегович wrote: >> Интересно, а есть ли зависимость между количеством keepalive и временем? >> >> пт, 4 сент. 2020 г. в 13:33, Panichev Oleg > >: >> >> Добрый день. >> >> >> При включении keepalive в секции upstream для fastcgi серверов >> upstream_response_time увеличивается на 40мс при нагрузке. Это >> достаточно четкий шаг, реальный ответ бэкендову нас - единицы >> миллисекунд, но nginx показывает на 40мс больше.  Apache benchmark >> tool >> показывает тоже самое. >> >> С чем связана именно такая задержка? Изменения таймаутов, количества >> реквестов на эти 40мс не влияют, в логе всегда либо единицы >> миллисекунд >> (время ответа для простых соединений, без включения keepalive), либо >> сразу 40мс+время простого запроса. Есть ли способ измерять реальное >> время ответа от бэкенда при использовании keepalive? >> >> Спасибо, ниже конфиги и результаты ab. >> >> >> =========================================================== >> >> Пробовал на свежем нджинксе и стартовой странице php-fpm: >> >> Проверка с keepalive: >> >>      upstream sync { >>         server localhost:9000; >>         keepalive 8; >>      } >> >> .. >> >>      location ~ \.php$ { >>          fastcgi_pass sync; >>          fastcgi_keep_conn on; >> ... >> >> Percentage of the requests served within a certain time (ms) >>    50%      3 >>    66%      3 >>    75%      4 >>    80%     42 >>    90%     43 >>    95%     44 >>    98%     44 >>    99%     45 >>   100%     52 (longest request) >> ========================== >> >> Без keepalive тот же апстрим: >> >> Percentage of the requests served within a certain time (ms) >>    50%      1 >>    66%      1 >>    75%      1 >>    80%      1 >>    90%      1 >>    95%      2 >>    98%      2 >>    99%      3 >>   100%      7 (longest request) >> >> Это повторяется на разных приложениях и разных фронтендах (см. >> скриншот) >> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From panichev на rutarget.ru Fri Sep 4 12:45:25 2020 From: panichev на rutarget.ru (Panichev Oleg) Date: Fri, 4 Sep 2020 15:45:25 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIGZhc3RjZ2kga2VlcGFsaXZlLiDQotCw0LjQvdGB0YLQstC1?= =?UTF-8?B?0L3QvdGL0LUgNDDQvNGB?= In-Reply-To: References: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> Message-ID: <01507c48-e5a5-f537-a77d-0802c2a2b75f@rutarget.ru> Пинг в продакшн быстрый: rtt min/avg/max/mdev = 0.054/0.095/0.131/0.027 ms Примеры, приведенные выше, вообще делаются на одном сервере (localhost:9000) Протокол fastcgi. On 9/4/20 3:29 PM, fox wrote: > Пинг до сервера какой? Протокол http 1.1? > > > 04.09.2020 18:22, Panichev Oleg пишет: >> В данном случае, с пустым конфигом и php-fpm, зависимости либо нет, либо >> она незаметна: >> >> >> keepalive 1: >> >> Percentage of the requests served within a certain time (ms) >>   50%      3 >>   66%      3 >>   75%     41 >>   80%     43 >>   90%     44 >>   95%     44 >>   98%     44 >>   99%     44 >>  100%     55 (longest request) >> >> keepalive 100: >> >>   50%      3 >>   66%      3 >>   75%      4 >>   80%     42 >>   90%     43 >>   95%     44 >>   98%     44 >>   99%     45 >> >>  100%     47 (longest request) >> >> >> >> On 9/4/20 2:07 PM, Сергей Олегович wrote: >>> Интересно, а есть ли зависимость между количеством keepalive и временем? >>> >>> пт, 4 сент. 2020 г. в 13:33, Panichev Oleg >> >: >>> >>> Добрый день. >>> >>> >>> При включении keepalive в секции upstream для fastcgi серверов >>> upstream_response_time увеличивается на 40мс при нагрузке. Это >>> достаточно четкий шаг, реальный ответ бэкендову нас - единицы >>> миллисекунд, но nginx показывает на 40мс больше.  Apache benchmark >>> tool >>> показывает тоже самое. >>> >>> С чем связана именно такая задержка? Изменения таймаутов, количества >>> реквестов на эти 40мс не влияют, в логе всегда либо единицы >>> миллисекунд >>> (время ответа для простых соединений, без включения keepalive), либо >>> сразу 40мс+время простого запроса. Есть ли способ измерять реальное >>> время ответа от бэкенда при использовании keepalive? >>> >>> Спасибо, ниже конфиги и результаты ab. >>> >>> >>> =========================================================== >>> >>> Пробовал на свежем нджинксе и стартовой странице php-fpm: >>> >>> Проверка с keepalive: >>> >>>      upstream sync { >>>         server localhost:9000; >>>         keepalive 8; >>>      } >>> >>> .. >>> >>>      location ~ \.php$ { >>>          fastcgi_pass sync; >>>          fastcgi_keep_conn on; >>> ... >>> >>> Percentage of the requests served within a certain time (ms) >>>    50%      3 >>>    66%      3 >>>    75%      4 >>>    80%     42 >>>    90%     43 >>>    95%     44 >>>    98%     44 >>>    99%     45 >>>   100%     52 (longest request) >>> ========================== >>> >>> Без keepalive тот же апстрим: >>> >>> Percentage of the requests served within a certain time (ms) >>>    50%      1 >>>    66%      1 >>>    75%      1 >>>    80%      1 >>>    90%      1 >>>    95%      2 >>>    98%      2 >>>    99%      3 >>>   100%      7 (longest request) >>> >>> Это повторяется на разных приложениях и разных фронтендах (см. >>> скриншот) >>> >>> >>> >>> _______________________________________________ >>> 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 From mdounin на mdounin.ru Fri Sep 4 15:38:55 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 4 Sep 2020 18:38:55 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIGZhc3RjZ2kga2VlcGFsaXZlLiDQotCw0LjQvdGB0YLQstC1?= =?UTF-8?B?0L3QvdGL0LUgNDDQvNGB?= In-Reply-To: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> References: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> Message-ID: <20200904153855.GF12747@mdounin.ru> Hello! On Fri, Sep 04, 2020 at 01:33:18PM +0300, Panichev Oleg wrote: > При включении keepalive в секции upstream для fastcgi серверов > upstream_response_time увеличивается на 40мс при нагрузке. Это > достаточно четкий шаг, > реальный ответ бэкендову нас - единицы миллисекунд, но nginx > показывает на 40мс больше.  Apache benchmark tool показывает > тоже самое. > > С чем связана именно такая задержка? Изменения таймаутов, > количества реквестов на эти 40мс не влияют, в логе всегда либо > единицы миллисекунд (время ответа > для простых соединений, без включения keepalive), либо сразу > 40мс+время простого запроса. Есть ли способ измерять реальное > время ответа от бэкенда при > использовании keepalive? Смотрите tcpdump между nginx'ом и бэкендом, возможно станет понятнее, что происходит. Возможные направления, куда, как мне кажется, имеет смысл копать: 1. Keepalive в случае FastCGI означает, что nginx'у надо дожидаться не просто закрытия stdout-потока, но и записи FCGI_END_REQUEST. Если вдруг бэкенд её посылает с задержкой - это может быть причиной. 2. FastCGI - сложный протокол, и бэкенд может наступать на классическую проблему delayed ack vs. Nagle. Ну и это хорошо сочетается с предыдущим пунктом, скажем - если запись FCGI_END_REQUEST бэкенд шлёт отдельной записью в сокет, то реально отправится она только по получению ack'а на предыдущую запись, а тот в свою очередь придёт только по истечению таймаута delayed ack. Обычно для тестов проще всего отключить delayed ack глобально на машине, и посмотреть, не починится ли. Лечить правильно - либо грамотной работой с сокетами (не допускать паттерна write+write+read), либо выставлением на сокет TCP_NODELAY. Ну и да, гугл подсказывает, что 40ms - задержка delayed ack по умолчанию на линуксе, так что скорее всего оно. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Fri Sep 4 18:12:30 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 4 Sep 2020 23:12:30 +0500 Subject: =?UTF-8?B?0LfQsNC/0YPRgdC6INCw0LLRgtC+0YLQtdGB0YLQvtCyINGBINCy0LrQu9GO0Yc=?= =?UTF-8?B?0LXQvdC90YvQvCBhc2FuIChhZGRyZXNzIHNhbml0aXplcik=?= Message-ID: Добрый день! для тестирования самодельного модуля, использовали такую методику взяли https://github.com/nginx/nginx-tests собрали nginx с самодельным модулем и gcc asan (не суть, могли бы взять clang asan). собрали кучу вариантов прохода по коду (это круто), нашли сколько-то дефектов в своем модуле. интересные вещи возникают с asan, причем, воспроизводятся на оригинальном nginx. это непонятно. можете прокомментировать ? 1. беру nginx из официальной репы. смотрю "nginx -V", добавляю -fsanitize=address к cc-opts 2. выставляю ASAN_OPTIONS="log_path=asan.log" 3. запукаю тесты, смотрю, что упало в asan.log (а там есть сработки, это немного неожиданно) скрипт #!/bin/bash set -e sysctl kernel.core_pattern=/tmp/core-%e-%s-%u-%g-%p-%t ulimit -c unlimited export version=1.19.2 mkdir t cd t wget http://nginx.org/download/nginx-${version}.tar.gz tar xf nginx-${version}.tar.gz cd nginx-${version} ./configure --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 -O0 -fdebug-prefix-map=/data/builder/debuild/nginx-1.19.2/debian/debuild-base/nginx-1.19.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC -fsanitize=address' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie -fsanitize=address -lasan' --with-debug make export ASAN_OPTIONS="log_path=asan.log" export TEST_NGINX_BINARY=`pwd`/objs/nginx export TEST_NGINX_GLOBALS='user root; ' export TEST_NGINX_GLOBALS_HTTP='error_log /tmp/e.log;' git clone https://github.com/nginx/nginx-tests prove -r nginx-tests сработки # locate asan.log /root/t/nginx-1.19.2/nginx-tests/asan.log.46464 /root/t/nginx-1.19.2/nginx-tests/asan.log.46728 /root/t/nginx-1.19.2/nginx-tests/asan.log.46866 /root/t/nginx-1.19.2/nginx-tests/asan.log.46876 /root/t/nginx-1.19.2/nginx-tests/asan.log.47784 /root/t/nginx-1.19.2/nginx-tests/asan.log.47931 /root/t/nginx-1.19.2/nginx-tests/asan.log.47957 /root/t/nginx-1.19.2/nginx-tests/asan.log.47983 /root/t/nginx-1.19.2/nginx-tests/asan.log.48005 /root/t/nginx-1.19.2/nginx-tests/asan.log.48760 /root/t/nginx-1.19.2/nginx-tests/asan.log.48770 /root/t/nginx-1.19.2/nginx-tests/asan.log.48818 /root/t/nginx-1.19.2/nginx-tests/asan.log.49079 /root/t/nginx-1.19.2/nginx-tests/asan.log.49329 пример первой # cat /root/t/nginx-1.19.2/nginx-tests/asan.log.46464 ================================================================= ==46464==ERROR: LeakSanitizer: detected memory leaks Indirect leak of 16384 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dbaa5 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 #2 0x5627781231ef in ngx_palloc_block src/core/ngx_palloc.c:186 #3 0x562778123166 in ngx_palloc_small src/core/ngx_palloc.c:173 #4 0x562778122f91 in ngx_palloc src/core/ngx_palloc.c:127 #5 0x5627782744f4 in ngx_http_add_variable src/http/ngx_http_variables.c:449 #6 0x56277828046b in ngx_http_variables_add_core_vars src/http/ngx_http_variables.c:2622 #7 0x56277822fd37 in ngx_http_core_preconfiguration src/http/ngx_http_core_module.c:3262 #8 0x562778213c81 in ngx_http_block src/http/ngx_http.c:227 #9 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #10 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #11 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #12 0x5627781188ae in main src/core/nginx.c:291 #13 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 16384 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dbaa5 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 #2 0x5627781231ef in ngx_palloc_block src/core/ngx_palloc.c:186 #3 0x562778123166 in ngx_palloc_small src/core/ngx_palloc.c:173 #4 0x562778122f91 in ngx_palloc src/core/ngx_palloc.c:127 #5 0x562778123957 in ngx_pcalloc src/core/ngx_palloc.c:302 #6 0x5627783a72da in ngx_http_proxy_create_loc_conf src/http/modules/ngx_http_proxy_module.c:2854 #7 0x56277821386d in ngx_http_block src/http/ngx_http.c:209 #8 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #9 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #10 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #11 0x5627781188ae in main src/core/nginx.c:291 #12 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 16384 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dbaa5 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 #2 0x5627781231ef in ngx_palloc_block src/core/ngx_palloc.c:186 #3 0x562778123166 in ngx_palloc_small src/core/ngx_palloc.c:173 #4 0x562778122f91 in ngx_palloc src/core/ngx_palloc.c:127 #5 0x562778123957 in ngx_pcalloc src/core/ngx_palloc.c:302 #6 0x562778126bba in ngx_hash_init src/core/ngx_hash.c:392 #7 0x562778281545 in ngx_http_variables_init_vars src/http/ngx_http_variables.c:2730 #8 0x56277821470b in ngx_http_block src/http/ngx_http.c:314 #9 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #10 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #11 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #12 0x5627781188ae in main src/core/nginx.c:291 #13 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 16384 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dbaa5 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 #2 0x5627781231ef in ngx_palloc_block src/core/ngx_palloc.c:186 #3 0x562778123166 in ngx_palloc_small src/core/ngx_palloc.c:173 #4 0x562778122f91 in ngx_palloc src/core/ngx_palloc.c:127 #5 0x562778123957 in ngx_pcalloc src/core/ngx_palloc.c:302 #6 0x5627783dfe02 in ngx_http_scgi_create_loc_conf src/http/modules/ngx_http_scgi_module.c:1232 #7 0x56277822dbd8 in ngx_http_core_location src/http/ngx_http_core_module.c:2968 #8 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #9 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #10 0x56277822cfe6 in ngx_http_core_server src/http/ngx_http_core_module.c:2875 #11 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #12 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #13 0x562778213db5 in ngx_http_block src/http/ngx_http.c:237 #14 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #15 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #16 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #17 0x5627781188ae in main src/core/nginx.c:291 #18 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 16384 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dbaa5 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 #2 0x5627781231ef in ngx_palloc_block src/core/ngx_palloc.c:186 #3 0x562778123166 in ngx_palloc_small src/core/ngx_palloc.c:173 #4 0x562778122f91 in ngx_palloc src/core/ngx_palloc.c:127 #5 0x562778123957 in ngx_pcalloc src/core/ngx_palloc.c:302 #6 0x5627783d1c12 in ngx_http_uwsgi_create_loc_conf src/http/modules/ngx_http_uwsgi_module.c:1443 #7 0x5627782b22d9 in ngx_http_upstream src/http/ngx_http_upstream.c:5805 #8 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #9 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #10 0x562778213db5 in ngx_http_block src/http/ngx_http.c:237 #11 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #12 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #13 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #14 0x5627781188ae in main src/core/nginx.c:291 #15 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 16384 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dbaa5 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 #2 0x5627781225ac in ngx_create_pool src/core/ngx_palloc.c:23 #3 0x562778169b2d in ngx_init_cycle src/core/ngx_cycle.c:69 #4 0x5627781188ae in main src/core/nginx.c:291 #5 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 8192 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dabc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x5627781c10fb in ngx_alloc src/os/unix/ngx_alloc.c:22 #2 0x562778123488 in ngx_palloc_large src/core/ngx_palloc.c:220 #3 0x562778122fa6 in ngx_palloc src/core/ngx_palloc.c:131 #4 0x56277812479e in ngx_array_push src/core/ngx_array.c:76 #5 0x5627781293c2 in ngx_hash_add_key src/core/ngx_hash.c:840 #6 0x5627782747a6 in ngx_http_add_variable src/http/ngx_http_variables.c:468 #7 0x562778384f28 in ngx_http_map_block src/http/modules/ngx_http_map_module.c:230 #8 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #9 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #10 0x562778213db5 in ngx_http_block src/http/ngx_http.c:237 #11 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #12 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #13 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #14 0x5627781188ae in main src/core/nginx.c:291 #15 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 6464 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dabc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x5627781c10fb in ngx_alloc src/os/unix/ngx_alloc.c:22 #2 0x562778123488 in ngx_palloc_large src/core/ngx_palloc.c:220 #3 0x562778122fa6 in ngx_palloc src/core/ngx_palloc.c:131 #4 0x562778126c4a in ngx_hash_init src/core/ngx_hash.c:399 #5 0x562778281545 in ngx_http_variables_init_vars src/http/ngx_http_variables.c:2730 #6 0x56277821470b in ngx_http_block src/http/ngx_http.c:314 #7 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #8 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #9 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #10 0x5627781188ae in main src/core/nginx.c:291 #11 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 4280 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dabc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x5627781c10fb in ngx_alloc src/os/unix/ngx_alloc.c:22 #2 0x562778123488 in ngx_palloc_large src/core/ngx_palloc.c:220 #3 0x562778122fa6 in ngx_palloc src/core/ngx_palloc.c:131 #4 0x562778123957 in ngx_pcalloc src/core/ngx_palloc.c:302 #5 0x5627781288aa in ngx_hash_keys_array_init src/core/ngx_hash.c:723 #6 0x5627782803af in ngx_http_variables_add_core_vars src/http/ngx_http_variables.c:2608 #7 0x56277822fd37 in ngx_http_core_preconfiguration src/http/ngx_http_core_module.c:3262 #8 0x562778213c81 in ngx_http_block src/http/ngx_http.c:227 #9 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #10 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #11 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #12 0x5627781188ae in main src/core/nginx.c:291 #13 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 4280 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dabc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x5627781c10fb in ngx_alloc src/os/unix/ngx_alloc.c:22 #2 0x562778123488 in ngx_palloc_large src/core/ngx_palloc.c:220 #3 0x562778122fa6 in ngx_palloc src/core/ngx_palloc.c:131 #4 0x562778123957 in ngx_pcalloc src/core/ngx_palloc.c:302 #5 0x5627781287f3 in ngx_hash_keys_array_init src/core/ngx_hash.c:717 #6 0x5627782803af in ngx_http_variables_add_core_vars src/http/ngx_http_variables.c:2608 #7 0x56277822fd37 in ngx_http_core_preconfiguration src/http/ngx_http_core_module.c:3262 #8 0x562778213c81 in ngx_http_block src/http/ngx_http.c:227 #9 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #10 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #11 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #12 0x5627781188ae in main src/core/nginx.c:291 #13 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 4280 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dabc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x5627781c10fb in ngx_alloc src/os/unix/ngx_alloc.c:22 #2 0x562778123488 in ngx_palloc_large src/core/ngx_palloc.c:220 #3 0x562778122fa6 in ngx_palloc src/core/ngx_palloc.c:131 #4 0x562778123957 in ngx_pcalloc src/core/ngx_palloc.c:302 #5 0x56277812873c in ngx_hash_keys_array_init src/core/ngx_hash.c:712 #6 0x5627782803af in ngx_http_variables_add_core_vars src/http/ngx_http_variables.c:2608 #7 0x56277822fd37 in ngx_http_core_preconfiguration src/http/ngx_http_core_module.c:3262 #8 0x562778213c81 in ngx_http_block src/http/ngx_http.c:227 #9 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #10 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #11 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #12 0x5627781188ae in main src/core/nginx.c:291 #13 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Indirect leak of 4096 byte(s) in 1 object(s) allocated from: #0 0x7f36e86dabc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) #1 0x5627781c10fb in ngx_alloc src/os/unix/ngx_alloc.c:22 #2 0x562778123488 in ngx_palloc_large src/core/ngx_palloc.c:220 #3 0x562778122fa6 in ngx_palloc src/core/ngx_palloc.c:131 #4 0x56277812479e in ngx_array_push src/core/ngx_array.c:76 #5 0x5627781293c2 in ngx_hash_add_key src/core/ngx_hash.c:840 #6 0x5627782747a6 in ngx_http_add_variable src/http/ngx_http_variables.c:468 #7 0x56277828046b in ngx_http_variables_add_core_vars src/http/ngx_http_variables.c:2622 #8 0x56277822fd37 in ngx_http_core_preconfiguration src/http/ngx_http_core_module.c:3262 #9 0x562778213c81 in ngx_http_block src/http/ngx_http.c:227 #10 0x56277817679d in ngx_conf_handler src/core/ngx_conf_file.c:463 #11 0x5627781757c4 in ngx_conf_parse src/core/ngx_conf_file.c:319 #12 0x56277816b106 in ngx_init_cycle src/core/ngx_cycle.c:275 #13 0x5627781188ae in main src/core/nginx.c:291 #14 0x7f36e7fa40b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) SUMMARY: AddressSanitizer: 129896 byte(s) leaked in 12 allocation(s). реально утечки )) ? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Sat Sep 5 06:14:39 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 5 Sep 2020 09:14:39 +0300 Subject: =?UTF-8?B?UmU6INC30LDQv9GD0YHQuiDQsNCy0YLQvtGC0LXRgdGC0L7QsiDRgSDQstC60Ls=?= =?UTF-8?B?0Y7Rh9C10L3QvdGL0LwgYXNhbiAoYWRkcmVzcyBzYW5pdGl6ZXIp?= In-Reply-To: References: Message-ID: <20200905061439.GA18881@mdounin.ru> Hello! On Fri, Sep 04, 2020 at 11:12:30PM +0500, Илья Шипицин wrote: > для тестирования самодельного модуля, использовали такую методику > > взяли https://github.com/nginx/nginx-tests > собрали nginx с самодельным модулем и gcc asan (не суть, могли бы взять > clang asan). > собрали кучу вариантов прохода по коду (это круто), нашли сколько-то > дефектов в своем модуле. > > интересные вещи возникают с asan, причем, воспроизводятся на оригинальном > nginx. > это непонятно. можете прокомментировать ? > > 1. беру nginx из официальной репы. смотрю "nginx -V", добавляю > -fsanitize=address к cc-opts > 2. выставляю ASAN_OPTIONS="log_path=asan.log" > 3. запукаю тесты, смотрю, что упало в asan.log (а там есть сработки, это > немного неожиданно) LeakSanitizer любит ругаться при выходе процесса на любую выделенную и не освобождённую явно память. В результате ругани там достаточно в том числе на полностью корректном коде, причём она заметно варьируется в зависимости от используемых библиотек и операционной системы. На macOS, например, вызов localtime_r() приводит к аллокациям в системных библиотеках и ругани при выходе всегда. Ну и с учётом используемой nginx'ом модели выделения памяти через пулы - поймать что-то реальное с помощью LeakSanitizer'а практически невозможно. Так что тесты с санитайзером мы гоняем, но вот на ругань от LeakSanitizer'а смотреть систематически даже и не пытаемся: мусора много, а толку никакого. [...] > Indirect leak of 16384 byte(s) in 1 object(s) allocated from: > #0 0x7f36e86dbaa5 in posix_memalign > (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) > #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 > #2 0x5627781225ac in ngx_create_pool src/core/ngx_palloc.c:23 > #3 0x562778169b2d in ngx_init_cycle src/core/ngx_cycle.c:69 > #4 0x5627781188ae in main src/core/nginx.c:291 > #5 0x7f36e7fa40b2 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) Ругань в этом файле (вся, но тут вот наиболее наглядно) как бы предполагает, что созданный в ngx_init_cycle() пул не освобождён. Такое может быть при фатальных ошибках, скажем, если произошла ошибка при инициализации какого-то модуля в ngx_init_cycle(). На вскидку я никаких подобных проблем в тестах не помню (даже при использовании TEST_NGINX_UNSAFE, хотя там вообще-то может быть всё, что угодно), и погоняв тесты на Ubuntu 18.04 никакой подобной ругани от ASAN'а не наблюдаю (другую - наблюдаю, но там всё понятно: неосвобождения пула init-цикла при ошибках парсинга конфигурации, per-worker аллокации в random-балансировщике и разное в OpenSSL). Если воспроизводится - то стоит посмотреть, что конкретно за тест это триггерит, и что там происходит. Впрочем, шансов на то, что это таки утечка - никаких. Скорее какая-нибудь проблема с конкретным тестом на конкретной платформе. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Sat Sep 5 07:36:15 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 5 Sep 2020 10:36:15 +0300 Subject: =?UTF-8?B?UmU6INC30LDQv9GD0YHQuiDQsNCy0YLQvtGC0LXRgdGC0L7QsiDRgSDQstC60Ls=?= =?UTF-8?B?0Y7Rh9C10L3QvdGL0LwgYXNhbiAoYWRkcmVzcyBzYW5pdGl6ZXIp?= In-Reply-To: <20200905061439.GA18881@mdounin.ru> References: <20200905061439.GA18881@mdounin.ru> Message-ID: On Sat, Sep 5, 2020, 9:14 AM Maxim Dounin wrote: > Hello! > > On Fri, Sep 04, 2020 at 11:12:30PM +0500, Илья Шипицин wrote: > > > для тестирования самодельного модуля, использовали такую методику > > > > взяли https://github.com/nginx/nginx-tests > > собрали nginx с самодельным модулем и gcc asan (не суть, могли бы взять > > clang asan). > > собрали кучу вариантов прохода по коду (это круто), нашли сколько-то > > дефектов в своем модуле. > > > > интересные вещи возникают с asan, причем, воспроизводятся на оригинальном > > nginx. > > это непонятно. можете прокомментировать ? > > > > 1. беру nginx из официальной репы. смотрю "nginx -V", добавляю > > -fsanitize=address к cc-opts > > 2. выставляю ASAN_OPTIONS="log_path=asan.log" > > 3. запукаю тесты, смотрю, что упало в asan.log (а там есть сработки, это > > немного неожиданно) > > LeakSanitizer любит ругаться при выходе процесса на любую > выделенную и не освобождённую явно память. В результате ругани > там достаточно в том числе на полностью корректном коде, причём > она заметно варьируется в зависимости от используемых библиотек и > операционной системы. На macOS, например, вызов localtime_r() > приводит к аллокациям в системных библиотеках и ругани при выходе > всегда. > > Ну и с учётом используемой nginx'ом модели выделения памяти через > пулы - поймать что-то реальное с помощью LeakSanitizer'а > практически невозможно. > > Так что тесты с санитайзером мы гоняем, но вот на ругань от > LeakSanitizer'а смотреть систематически даже и не пытаемся: мусора > много, а толку никакого. > Вывод приведен, кстати, с bionic. Да, я тоже подумал, что скорее всего тесты с санитайзером запускаете. Ну и была надежда на бинарную логику "есть сработки - ура, смотрим, нет сработок - смотреть нечего" > [...] > > > Indirect leak of 16384 byte(s) in 1 object(s) allocated from: > > #0 0x7f36e86dbaa5 in posix_memalign > > (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) > > #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 > > #2 0x5627781225ac in ngx_create_pool src/core/ngx_palloc.c:23 > > #3 0x562778169b2d in ngx_init_cycle src/core/ngx_cycle.c:69 > > #4 0x5627781188ae in main src/core/nginx.c:291 > > #5 0x7f36e7fa40b2 in __libc_start_main > > (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) > > Ругань в этом файле (вся, но тут вот наиболее наглядно) как бы > предполагает, что созданный в ngx_init_cycle() пул не освобождён. > Такое может быть при фатальных ошибках, скажем, если произошла > ошибка при инициализации какого-то модуля в ngx_init_cycle(). > > На вскидку я никаких подобных проблем в тестах не помню (даже при > использовании TEST_NGINX_UNSAFE, хотя там вообще-то может быть > всё, что угодно), и погоняв тесты на Ubuntu 18.04 никакой подобной > ругани от ASAN'а не наблюдаю (другую - наблюдаю, но там всё > понятно: неосвобождения пула init-цикла при ошибках парсинга > конфигурации, per-worker аллокации в random-балансировщике и > разное в OpenSSL). Если воспроизводится - то стоит посмотреть, > что конкретно за тест это триггерит, и что там происходит. > > Впрочем, шансов на то, что это таки утечка - никаких. Скорее > какая-нибудь проблема с конкретным тестом на конкретной платформе. > > -- > 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 Sat Sep 5 07:43:17 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 5 Sep 2020 10:43:17 +0300 Subject: =?UTF-8?B?UmU6INC30LDQv9GD0YHQuiDQsNCy0YLQvtGC0LXRgdGC0L7QsiDRgSDQstC60Ls=?= =?UTF-8?B?0Y7Rh9C10L3QvdGL0LwgYXNhbiAoYWRkcmVzcyBzYW5pdGl6ZXIp?= In-Reply-To: <20200905061439.GA18881@mdounin.ru> References: <20200905061439.GA18881@mdounin.ru> Message-ID: Методика "взять референсные тесты ... запустить ... включить санитайзер и запустить" оказалась неплоха. Не думали популяризовать её для сторонних модулей? Раньше по крайней мере в рассылке частенько сегфолты на сторонних модулях были. Если гонять тесты, оно ловится ещё на этапе тестирования On Sat, Sep 5, 2020, 9:14 AM Maxim Dounin wrote: > Hello! > > On Fri, Sep 04, 2020 at 11:12:30PM +0500, Илья Шипицин wrote: > > > для тестирования самодельного модуля, использовали такую методику > > > > взяли https://github.com/nginx/nginx-tests > > собрали nginx с самодельным модулем и gcc asan (не суть, могли бы взять > > clang asan). > > собрали кучу вариантов прохода по коду (это круто), нашли сколько-то > > дефектов в своем модуле. > > > > интересные вещи возникают с asan, причем, воспроизводятся на оригинальном > > nginx. > > это непонятно. можете прокомментировать ? > > > > 1. беру nginx из официальной репы. смотрю "nginx -V", добавляю > > -fsanitize=address к cc-opts > > 2. выставляю ASAN_OPTIONS="log_path=asan.log" > > 3. запукаю тесты, смотрю, что упало в asan.log (а там есть сработки, это > > немного неожиданно) > > LeakSanitizer любит ругаться при выходе процесса на любую > выделенную и не освобождённую явно память. В результате ругани > там достаточно в том числе на полностью корректном коде, причём > она заметно варьируется в зависимости от используемых библиотек и > операционной системы. На macOS, например, вызов localtime_r() > приводит к аллокациям в системных библиотеках и ругани при выходе > всегда. > > Ну и с учётом используемой nginx'ом модели выделения памяти через > пулы - поймать что-то реальное с помощью LeakSanitizer'а > практически невозможно. > > Так что тесты с санитайзером мы гоняем, но вот на ругань от > LeakSanitizer'а смотреть систематически даже и не пытаемся: мусора > много, а толку никакого. > > [...] > > > Indirect leak of 16384 byte(s) in 1 object(s) allocated from: > > #0 0x7f36e86dbaa5 in posix_memalign > > (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10eaa5) > > #1 0x5627781c130d in ngx_memalign src/os/unix/ngx_alloc.c:57 > > #2 0x5627781225ac in ngx_create_pool src/core/ngx_palloc.c:23 > > #3 0x562778169b2d in ngx_init_cycle src/core/ngx_cycle.c:69 > > #4 0x5627781188ae in main src/core/nginx.c:291 > > #5 0x7f36e7fa40b2 in __libc_start_main > > (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) > > Ругань в этом файле (вся, но тут вот наиболее наглядно) как бы > предполагает, что созданный в ngx_init_cycle() пул не освобождён. > Такое может быть при фатальных ошибках, скажем, если произошла > ошибка при инициализации какого-то модуля в ngx_init_cycle(). > > На вскидку я никаких подобных проблем в тестах не помню (даже при > использовании TEST_NGINX_UNSAFE, хотя там вообще-то может быть > всё, что угодно), и погоняв тесты на Ubuntu 18.04 никакой подобной > ругани от ASAN'а не наблюдаю (другую - наблюдаю, но там всё > понятно: неосвобождения пула init-цикла при ошибках парсинга > конфигурации, per-worker аллокации в random-балансировщике и > разное в OpenSSL). Если воспроизводится - то стоит посмотреть, > что конкретно за тест это триггерит, и что там происходит. > > Впрочем, шансов на то, что это таки утечка - никаких. Скорее > какая-нибудь проблема с конкретным тестом на конкретной платформе. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From panichev на rutarget.ru Sun Sep 6 09:20:31 2020 From: panichev на rutarget.ru (Panichev Oleg) Date: Sun, 6 Sep 2020 12:20:31 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIGZhc3RjZ2kga2VlcGFsaXZlLiDQotCw0LjQvdGB0YLQstC1?= =?UTF-8?B?0L3QvdGL0LUgNDDQvNGB?= In-Reply-To: <20200904153855.GF12747@mdounin.ru> References: <012093cf-2245-f2be-8894-def9d29a05b9@rutarget.ru> <20200904153855.GF12747@mdounin.ru> Message-ID: <0d02abbd-76d3-1d39-bed6-5b4579f4dff5@rutarget.ru> Спасибо, Максим! Да, тестово получилось повторить, дело действительно в delayed Ack. On 9/4/20 6:38 PM, Maxim Dounin wrote: > Hello! > > On Fri, Sep 04, 2020 at 01:33:18PM +0300, Panichev Oleg wrote: > >> При включении keepalive в секции upstream для fastcgi серверов >> upstream_response_time увеличивается на 40мс при нагрузке. Это >> достаточно четкий шаг, >> реальный ответ бэкендову нас - единицы миллисекунд, но nginx >> показывает на 40мс больше.  Apache benchmark tool показывает >> тоже самое. >> >> С чем связана именно такая задержка? Изменения таймаутов, >> количества реквестов на эти 40мс не влияют, в логе всегда либо >> единицы миллисекунд (время ответа >> для простых соединений, без включения keepalive), либо сразу >> 40мс+время простого запроса. Есть ли способ измерять реальное >> время ответа от бэкенда при >> использовании keepalive? > Смотрите tcpdump между nginx'ом и бэкендом, возможно станет > понятнее, что происходит. Возможные направления, куда, как мне > кажется, имеет смысл копать: > > 1. Keepalive в случае FastCGI означает, что nginx'у надо > дожидаться не просто закрытия stdout-потока, но и записи > FCGI_END_REQUEST. Если вдруг бэкенд её посылает с задержкой - это > может быть причиной. > > 2. FastCGI - сложный протокол, и бэкенд может наступать на > классическую проблему delayed ack vs. Nagle. Ну и это хорошо > сочетается с предыдущим пунктом, скажем - если запись > FCGI_END_REQUEST бэкенд шлёт отдельной записью в сокет, то реально > отправится она только по получению ack'а на предыдущую запись, а > тот в свою очередь придёт только по истечению таймаута delayed > ack. Обычно для тестов проще всего отключить delayed ack > глобально на машине, и посмотреть, не починится ли. Лечить > правильно - либо грамотной работой с сокетами (не допускать > паттерна write+write+read), либо выставлением на сокет > TCP_NODELAY. > > Ну и да, гугл подсказывает, что 40ms - задержка delayed ack > по умолчанию на линуксе, так что скорее всего оно. > From nginx-forum на forum.nginx.org Tue Sep 8 06:21:21 2020 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Tue, 08 Sep 2020 02:21:21 -0400 Subject: =?UTF-8?B?0JLRi9GH0LjRgdC70LjRgtGMINC00LvQuNC90YMgdXNlciBhZ2VudA==?= Message-ID: Прилетали такие запросы: 103.47.172.95 [08/Sep/2020:00:18:57 +0300] "GET / HTTP/1.1" 499 0 "https://yahoo.com" "M" 186.6.101.4 [08/Sep/2020:00:19:14 +0300] "GET / HTTP/1.1" 499 0 "https://facebook.com" "k" 117.102.116.82 [08/Sep/2020:00:19:16 +0300] "GET / HTTP/1.1" 499 0 "https://bing.com" ")" 43.249.140.230 [08/Sep/2020:00:19:16 +0300] "GET / HTTP/1.1" 499 0 "https://baidu.com" "(" 61.5.39.35 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 "https://bing.com" "U" 189.50.9.250 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 "https://google.com" "2" 191.97.9.186 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 "https://reddit.com" "M" 198.50.163.192 [08/Sep/2020:00:19:18 +0300] "GET / HTTP/1.1" 499 0 "https://facebook.com" "n" 103.113.197.1 [08/Sep/2020:00:19:18 +0300] "GET / HTTP/1.1" 499 0 "https://gmail.com" "v" Очевидно юзер-агент "левый". Пришла мысль резать по длине его (юзер-агента). например если короче Х символов - отдавать просто 403 и не мучаться, потому что это явно не нормальная ситуация. Существует ли такая возможность? Или нужно на перле/луа прикручивать скрипты? Ну что-то типа такого хотелось бы: if ($http_user_agent_length < 7) { return 403; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289343,289343#msg-289343 From chipitsine на gmail.com Tue Sep 8 06:24:16 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 8 Sep 2020 11:24:16 +0500 Subject: =?UTF-8?B?UmU6INCS0YvRh9C40YHQu9C40YLRjCDQtNC70LjQvdGDIHVzZXIgYWdlbnQ=?= In-Reply-To: References: Message-ID: Регуляркой, наверное, можно On Tue, Sep 8, 2020, 11:21 AM Dmytro Lavryk wrote: > Прилетали такие запросы: > 103.47.172.95 [08/Sep/2020:00:18:57 +0300] "GET / HTTP/1.1" 499 0 > "https://yahoo.com" "M" > 186.6.101.4 [08/Sep/2020:00:19:14 +0300] "GET / HTTP/1.1" 499 0 > "https://facebook.com" "k" > 117.102.116.82 [08/Sep/2020:00:19:16 +0300] "GET / HTTP/1.1" 499 0 > "https://bing.com" ")" > 43.249.140.230 [08/Sep/2020:00:19:16 +0300] "GET / HTTP/1.1" 499 0 > "https://baidu.com" "(" > 61.5.39.35 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 > "https://bing.com" "U" > 189.50.9.250 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 > "https://google.com" "2" > 191.97.9.186 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 > "https://reddit.com" "M" > 198.50.163.192 [08/Sep/2020:00:19:18 +0300] "GET / HTTP/1.1" 499 0 > "https://facebook.com" "n" > 103.113.197.1 [08/Sep/2020:00:19:18 +0300] "GET / HTTP/1.1" 499 0 > "https://gmail.com" "v" > > Очевидно юзер-агент "левый". Пришла мысль резать по длине его > (юзер-агента). > например если короче Х символов - отдавать просто 403 и не мучаться, потому > что это явно не нормальная ситуация. Существует ли такая возможность? Или > нужно на перле/луа прикручивать скрипты? > > Ну что-то типа такого хотелось бы: > if ($http_user_agent_length < 7) { > return 403; > } > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,289343,289343#msg-289343 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From root на dl.sm.ua Tue Sep 8 06:46:29 2020 From: root на dl.sm.ua (Dmytro Lavryk) Date: Tue, 08 Sep 2020 09:46:29 +0300 Subject: =?UTF-8?B?UmU6INCS0YvRh9C40YHQu9C40YLRjCDQtNC70LjQvdGDIHVzZXIgYWdlbnQ=?= In-Reply-To: References: Message-ID: <1746c7742ca.10f5e5206320355.8512793539691334826@dl.sm.ua> Спасибо за здравую мысль! В итоге сделал так (рубит с длиной менее 4-х символов): if ($http_user_agent ~ "^.{0,4}$") {         return 403; } ---- Увімкнуто вт, 08 вер. 2020 09:24:16 +0300 Илья Шипицин написав ---- Регуляркой, наверное, можно On Tue, Sep 8, 2020, 11:21 AM Dmytro Lavryk wrote: Прилетали такие запросы: 103.47.172.95 [08/Sep/2020:00:18:57 +0300] "GET / HTTP/1.1" 499 0 "https://yahoo.com" "M" 186.6.101.4 [08/Sep/2020:00:19:14 +0300] "GET / HTTP/1.1" 499 0 "https://facebook.com" "k" 117.102.116.82 [08/Sep/2020:00:19:16 +0300] "GET / HTTP/1.1" 499 0 "https://bing.com" ")" 43.249.140.230 [08/Sep/2020:00:19:16 +0300] "GET / HTTP/1.1" 499 0 "https://baidu.com" "(" 61.5.39.35 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 "https://bing.com" "U" 189.50.9.250 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 "https://google.com" "2" 191.97.9.186 [08/Sep/2020:00:19:17 +0300] "GET / HTTP/1.1" 499 0 "https://reddit.com" "M" 198.50.163.192 [08/Sep/2020:00:19:18 +0300] "GET / HTTP/1.1" 499 0 "https://facebook.com" "n" 103.113.197.1 [08/Sep/2020:00:19:18 +0300] "GET / HTTP/1.1" 499 0 "https://gmail.com" "v" Очевидно юзер-агент "левый". Пришла мысль резать по длине его (юзер-агента). например если короче Х символов - отдавать просто 403 и не мучаться, потому что это явно не нормальная ситуация. Существует ли такая возможность? Или нужно на перле/луа прикручивать скрипты? Ну что-то типа такого хотелось бы: if ($http_user_agent_length < 7) {     return 403; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289343,289343#msg-289343 _______________________________________________ nginx-ru mailing list mailto:nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru _______________________________________________ nginx-ru mailing list mailto:nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Sep 9 10:07:23 2020 From: nginx-forum на forum.nginx.org (akoval) Date: Wed, 09 Sep 2020 06:07:23 -0400 Subject: =?UTF-8?B?0JrQsNC6INC30LDQutGA0YvRgtGMINGB0LXRgNCy0LXRgCDQtNC70Y8g0LLRgdC1?= =?UTF-8?B?0YUg0YHRgtGA0LDQvSDQutGA0L7QvNC1INGB0LLQvtC10Lkg0Lgg0YHQtdGA?= =?UTF-8?B?0LLQuNGB0L7QsiDQs9GD0LPQuw==?= Message-ID: <7d33276c0000f6e8a96ba9938b4c4bb6.NginxMailingListRussian@forum.nginx.org> Собственно сабж... Народ, как решаете данную проблему? Сайт постоянно сканируют левые боты и атаки с других стран... Но сервисы гугла нужны. Как закрыть сайт на уровне сервера? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289352,289352#msg-289352 From chipitsine на gmail.com Wed Sep 9 10:10:30 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 9 Sep 2020 15:10:30 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0LrRgNGL0YLRjCDRgdC10YDQstC10YAg0LTQu9GPINCy?= =?UTF-8?B?0YHQtdGFINGB0YLRgNCw0L0g0LrRgNC+0LzQtSDRgdCy0L7QtdC5INC4INGB?= =?UTF-8?B?0LXRgNCy0LjRgdC+0LIg0LPRg9Cz0Ls=?= In-Reply-To: <7d33276c0000f6e8a96ba9938b4c4bb6.NginxMailingListRussian@forum.nginx.org> References: <7d33276c0000f6e8a96ba9938b4c4bb6.NginxMailingListRussian@forum.nginx.org> Message-ID: частично решается путем настройки дефолт хоста server { listen N.N.N.N:80 default_server; server_name _; return 404; access_log off; error_log /dev/null; } сканеры чаще не знают ваш домен. если они идут по диапазону адресов, то попадают в дефолт ср, 9 сент. 2020 г. в 15:07, akoval : > Собственно сабж... > Народ, как решаете данную проблему? > Сайт постоянно сканируют левые боты и атаки с других стран... > Но сервисы гугла нужны. > Как закрыть сайт на уровне сервера? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,289352,289352#msg-289352 > > _______________________________________________ > 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 Sep 9 11:53:47 2020 From: nginx-forum на forum.nginx.org (akoval) Date: Wed, 09 Sep 2020 07:53:47 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0LrRgNGL0YLRjCDRgdC10YDQstC10YAg0LTQu9GPINCy?= =?UTF-8?B?0YHQtdGFINGB0YLRgNCw0L0g0LrRgNC+0LzQtSDRgdCy0L7QtdC5INC4INGB?= =?UTF-8?B?0LXRgNCy0LjRgdC+0LIg0LPRg9Cz0Ls=?= In-Reply-To: References: Message-ID: прописал: server { listen xxx.xxx.xxx.xxx:443 default_server; server_name _; ssl_certificate ...; ssl_certificate_key ...; return 404; access_log off; error_log /var/log/nginx/error_by_ip.log crit; } server { listen xxx.xxx.xxx.xxx:80; server_name _; return 404; access_log off; error_log /var/log/nginx/error_by_ip.log crit; } но при входе на https://xxx.xxx.xxx.xxx - Your connection is not private а на http://xxx.xxx.xxx.xxx - выдает приветственную страницу nginx Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289352,289358#msg-289358 From chipitsine на gmail.com Wed Sep 9 12:16:01 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 9 Sep 2020 17:16:01 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0LrRgNGL0YLRjCDRgdC10YDQstC10YAg0LTQu9GPINCy?= =?UTF-8?B?0YHQtdGFINGB0YLRgNCw0L0g0LrRgNC+0LzQtSDRgdCy0L7QtdC5INC4INGB?= =?UTF-8?B?0LXRgNCy0LjRgdC+0LIg0LPRg9Cz0Ls=?= In-Reply-To: References: Message-ID: у вас в директиве listen на 80-м порту не прописан default_server. действительно, сертификат не соответствует IP адресу, браузером будет ровно то, что вы показали. ср, 9 сент. 2020 г. в 16:53, akoval : > прописал: > > server { > listen xxx.xxx.xxx.xxx:443 default_server; > server_name _; > ssl_certificate ...; > ssl_certificate_key ...; > > > return 404; > > access_log off; > error_log /var/log/nginx/error_by_ip.log crit; > } > > server { > listen xxx.xxx.xxx.xxx:80; > server_name _; > > return 404; > > access_log off; > error_log /var/log/nginx/error_by_ip.log crit; > } > > но при входе на > https://xxx.xxx.xxx.xxx - Your connection is not private > а на > http://xxx.xxx.xxx.xxx - выдает приветственную страницу nginx > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,289352,289358#msg-289358 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Sep 9 12:57:02 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 9 Sep 2020 17:57:02 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0LrRgNGL0YLRjCDRgdC10YDQstC10YAg0LTQu9GPINCy?= =?UTF-8?B?0YHQtdGFINGB0YLRgNCw0L0g0LrRgNC+0LzQtSDRgdCy0L7QtdC5INC4INGB?= =?UTF-8?B?0LXRgNCy0LjRgdC+0LIg0LPRg9Cz0Ls=?= In-Reply-To: References: Message-ID: еще такой момент, listen должен быть идентичным вашему продовому. если у вас "listen 80". то дефолт надо такой же. пример с адресом - это просто пример. я имел в виду "посмотреть, какой реально listen, и сделать еще один такой же с дефолтом" ср, 9 сент. 2020 г. в 16:53, akoval : > прописал: > > server { > listen xxx.xxx.xxx.xxx:443 default_server; > server_name _; > ssl_certificate ...; > ssl_certificate_key ...; > > > return 404; > > access_log off; > error_log /var/log/nginx/error_by_ip.log crit; > } > > server { > listen xxx.xxx.xxx.xxx:80; > server_name _; > > return 404; > > access_log off; > error_log /var/log/nginx/error_by_ip.log crit; > } > > но при входе на > https://xxx.xxx.xxx.xxx - Your connection is not private > а на > http://xxx.xxx.xxx.xxx - выдает приветственную страницу nginx > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,289352,289358#msg-289358 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mif на me.com Thu Sep 10 11:48:22 2020 From: mif на me.com (Alexey Galygin) Date: Thu, 10 Sep 2020 14:48:22 +0300 Subject: =?UTF-8?B?0YDQtdC30L7Qu9Cy0Y/RgtGB0Y8g0L3QtSDQstGB0LUg0LjQvNC10L3QsCBob3N0?= =?UTF-8?B?LdGE0LDQudC70LA=?= Message-ID: доброго дня хотелось бы всё таки разобраться с вопросом резолвинга имён у нас есть докер-контейнер с nginx 1.18.0 с Docker Hub в него мы подкладываем в /etc/hosts файл свои несколько записей (условно): 10.0.3.4 docker_srv_a 10.0.3.5 docker_srv_b 10.0.3.6 docker_srv_c никакой разницы нет в дальнейшем использовании docker_srv_[a,b,c] в nginx.conf, при этом, srv_a и srv_b работают, а srv_c нет проверяли всё до знаков пунктуации — нет разницы в описании, но имя docker_srv_c nginx не видит пересборка, дублирование в родительской машинке в /etc/hosts, перезапуски nginx — ничего не помогает сам контейнер видит записи (через ping), nginx не видит одну из них — docker_srv_c все записи, но в особенности последняя резолвится (ping) в контейнере (docker exec -it nginx ping docker_srv_c), но последняя не резолвится в nginx в error log ошибка: 2020/09/10 13:24:58 [error] 22#22: *40 no resolver defined to resolve docker_srv_c, client: …, server: …, request: "GET /srv_c/api HTTP/1.1", host: "…" перевод строки ещё один на всякий случай добавлял в конец /etc/hosts — не помогло далее, поверх этих имён я просто повесил upstream'ы и, все три записи стали видны! убираю апстримы, пишу напрямую в proxy_pass http://docker_srv_c — не может разрешить имя всё же какой-то глюк тут явно есть… что за внутренняя процедура в nginx relover по умолчанию и почему она не полностью следует hosts-файлу? почему резолвится только часть имён? да и что за чудеса, чем upstream так помогает резолвингу? From bgx на protva.ru Thu Sep 10 12:01:22 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 10 Sep 2020 15:01:22 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQt9C+0LvQstGP0YLRgdGPINC90LUg0LLRgdC1INC40LzQtdC90LAg?= =?UTF-8?B?aG9zdC3RhNCw0LnQu9Cw?= In-Reply-To: References: Message-ID: <20200910120122.GE2608@protva.ru> On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote: > почему резолвится только часть имён? да и что за чудеса, чем upstream так помогает резолвингу? Проверьте на стандартную ошибку: где-то имя написано с символом в кириллице (скорее всего в конфиге nginx), а при проверках копи-пастилась откуда-то без кириллицы. Обычным грепом легко это выявить, и hd помогает. -- Eugene Berdnikov From mif на me.com Thu Sep 10 12:36:57 2020 From: mif на me.com (Alexey Galygin) Date: Thu, 10 Sep 2020 15:36:57 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQt9C+0LvQstGP0YLRgdGPINC90LUg0LLRgdC1INC40LzQtdC90LAg?= =?UTF-8?B?aG9zdC3RhNCw0LnQu9Cw?= In-Reply-To: <20200910120122.GE2608@protva.ru> References: <20200910120122.GE2608@protva.ru> Message-ID: не, grep'ом с нуля набивал ‘c’ могла бы быть проблемой но до того как сервис srv_c стал последним, проблемы были с srv_b … это что-то эфемерное, и от того так неприятно > On 10 Sep 2020, at 15:01, Evgeniy Berdnikov wrote: > > On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote: >> почему резолвится только часть имён? да и что за чудеса, чем upstream так помогает резолвингу? > > Проверьте на стандартную ошибку: где-то имя написано с символом в кириллице > (скорее всего в конфиге nginx), а при проверках копи-пастилась откуда-то > без кириллицы. Обычным грепом легко это выявить, и hd помогает. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From slw на zxy.spb.ru Thu Sep 10 12:38:19 2020 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 10 Sep 2020 15:38:19 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQt9C+0LvQstGP0YLRgdGPINC90LUg0LLRgdC1INC40LzQtdC90LAg?= =?UTF-8?B?aG9zdC3RhNCw0LnQu9Cw?= In-Reply-To: References: <20200910120122.GE2608@protva.ru> Message-ID: <20200910123819.GT2015@zxy.spb.ru> On Thu, Sep 10, 2020 at 03:36:57PM +0300, Alexey Galygin wrote: > не, grep'ом с нуля набивал > > ‘c’ могла бы быть проблемой > > но до того как сервис srv_c стал последним, проблемы были с srv_b … > это что-то эфемерное, и от того так неприятно хексдамп всего файла в студию > > On 10 Sep 2020, at 15:01, Evgeniy Berdnikov wrote: > > > > On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote: > >> почему резолвится только часть имён? да и что за чудеса, чем upstream так помогает резолвингу? > > > > Проверьте на стандартную ошибку: где-то имя написано с символом в кириллице > > (скорее всего в конфиге nginx), а при проверках копи-пастилась откуда-то > > без кириллицы. Обычным грепом легко это выявить, и hd помогает. > > -- > > Eugene Berdnikov > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Thu Sep 10 12:43:17 2020 From: nginx-forum на forum.nginx.org (lexey) Date: Thu, 10 Sep 2020 08:43:17 -0400 Subject: =?UTF-8?B?0KDQuNC00LjRgNC10LrRgiBSRFAg0LIg0LfQsNCy0LjRgdC40LzQvtGB0YLQuCA=?= =?UTF-8?B?0L7RgiDQtNC+0YHRgtGD0L/QvdC+0YHRgtC4?= Message-ID: <1eecced780a168859caab5f3dbef1026.NginxMailingListRussian@forum.nginx.org> Имеется 2 сервера с win server и 1 VDS где планируется установка Nginx, возможно ли настроить чтобы nginx делал ридирект RDP на 1 сервер в случае его доступности, a в случае отказа на 2? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289382,289382#msg-289382 From mdounin на mdounin.ru Thu Sep 10 13:15:06 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 10 Sep 2020 16:15:06 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQt9C+0LvQstGP0YLRgdGPINC90LUg0LLRgdC1INC40LzQtdC90LAg?= =?UTF-8?B?aG9zdC3RhNCw0LnQu9Cw?= In-Reply-To: References: Message-ID: <20200910131506.GP18881@mdounin.ru> Hello! On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote: > доброго дня > > хотелось бы всё таки разобраться с вопросом резолвинга имён > > у нас есть докер-контейнер с nginx 1.18.0 с Docker Hub > в него мы подкладываем в /etc/hosts файл свои несколько записей (условно): > > 10.0.3.4 docker_srv_a > 10.0.3.5 docker_srv_b > 10.0.3.6 docker_srv_c > > никакой разницы нет в дальнейшем использовании docker_srv_[a,b,c] в nginx.conf, при этом, srv_a и srv_b работают, а srv_c нет > > проверяли всё до знаков пунктуации — нет разницы в описании, но имя docker_srv_c nginx не видит > > пересборка, дублирование в родительской машинке в /etc/hosts, перезапуски nginx — ничего не помогает > сам контейнер видит записи (через ping), nginx не видит одну из них — docker_srv_c > > все записи, но в особенности последняя резолвится (ping) в контейнере (docker exec -it nginx ping docker_srv_c), но последняя не резолвится в nginx > > в error log ошибка: > > 2020/09/10 13:24:58 [error] 22#22: *40 no resolver defined to resolve docker_srv_c, client: …, server: …, request: "GET /srv_c/api HTTP/1.1", host: "…" Ошибка "no resolver defined" как бы говорит нам, что у вас конфигурация требует динамического резолвинга адресов (то есть имя используется вместе с переменными в proxy_pass). При динамичеком резолвинге невозможно использовать системный резолвер, и соответственно не используется файл /etc/hosts. Вместо этого надо либо использовать IP-адреса непосредственно в конфиге nginx'а, либо поднять DNS-сервер и указать его с помощью директивы resolver. > перевод строки ещё один на всякий случай добавлял в конец /etc/hosts — не помогло > > далее, поверх этих имён я просто повесил upstream'ы и, все три записи стали видны! > убираю апстримы, пишу напрямую в proxy_pass http://docker_srv_c — не может разрешить имя Цитата из документации (http://nginx.org/r/proxy_pass/ru): : В значении параметра можно использовать переменные. В этом случае, если адрес : указан в виде доменного имени, имя ищется среди описанных групп серверов и если : не найдено, то определяется с помощью resolver’а. > всё же какой-то глюк тут явно есть… > что за внутренняя процедура в nginx relover по умолчанию и почему она не полностью следует hosts-файлу? > > почему резолвится только часть имён? да и что за чудеса, чем upstream так помогает резолвингу? По умолчанию resolver не определён, и при динамическом резолвинге будут работать только IP-адреса, имена upstream'ов и имена, используемые в других частях конфига статически (так как для них создаются неявные upstream'ы). -- Maxim Dounin http://mdounin.ru/ From mif на me.com Thu Sep 10 14:07:19 2020 From: mif на me.com (Alexey Galygin) Date: Thu, 10 Sep 2020 17:07:19 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQt9C+0LvQstGP0YLRgdGPINC90LUg0LLRgdC1INC40LzQtdC90LAg?= =?UTF-8?B?aG9zdC3RhNCw0LnQu9Cw?= In-Reply-To: <20200910131506.GP18881@mdounin.ru> References: <20200910131506.GP18881@mdounin.ru> Message-ID: <4BA825B3-2A15-4C64-B4EF-C204A6778A99@me.com> действительно создал синтетический стенд как только дописал переменную — всё, резолвинг через hosts отвалился но это как-то странно, всё же… error_log /dev/stderr; events { use epoll; } http { server { server_name _; listen 80; location /srv_a { add_header Host ifconfig.co; proxy_pass http://docker_srv_a; } location /srv_b { add_header Host ifconfig.co; proxy_pass http://docker_srv_b; } location /srv_c { add_header Host ifconfig.co; proxy_pass http://docker_srv_c?$args; } } } > On 10 Sep 2020, at 16:15, Maxim Dounin wrote: > > Hello! > > On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote: > >> доброго дня >> >> хотелось бы всё таки разобраться с вопросом резолвинга имён >> >> у нас есть докер-контейнер с nginx 1.18.0 с Docker Hub >> в него мы подкладываем в /etc/hosts файл свои несколько записей (условно): >> >> 10.0.3.4 docker_srv_a >> 10.0.3.5 docker_srv_b >> 10.0.3.6 docker_srv_c >> >> никакой разницы нет в дальнейшем использовании docker_srv_[a,b,c] в nginx.conf, при этом, srv_a и srv_b работают, а srv_c нет >> >> проверяли всё до знаков пунктуации — нет разницы в описании, но имя docker_srv_c nginx не видит >> >> пересборка, дублирование в родительской машинке в /etc/hosts, перезапуски nginx — ничего не помогает >> сам контейнер видит записи (через ping), nginx не видит одну из них — docker_srv_c >> >> все записи, но в особенности последняя резолвится (ping) в контейнере (docker exec -it nginx ping docker_srv_c), но последняя не резолвится в nginx >> >> в error log ошибка: >> >> 2020/09/10 13:24:58 [error] 22#22: *40 no resolver defined to resolve docker_srv_c, client: …, server: …, request: "GET /srv_c/api HTTP/1.1", host: "…" > > Ошибка "no resolver defined" как бы говорит нам, что у вас > конфигурация требует динамического резолвинга адресов (то есть имя > используется вместе с переменными в proxy_pass). При динамичеком > резолвинге невозможно использовать системный резолвер, и > соответственно не используется файл /etc/hosts. Вместо этого надо > либо использовать IP-адреса непосредственно в конфиге nginx'а, > либо поднять DNS-сервер и указать его с помощью директивы > resolver. > >> перевод строки ещё один на всякий случай добавлял в конец /etc/hosts — не помогло >> >> далее, поверх этих имён я просто повесил upstream'ы и, все три записи стали видны! >> убираю апстримы, пишу напрямую в proxy_pass http://docker_srv_c — не может разрешить имя > > Цитата из документации (http://nginx.org/r/proxy_pass/ru ): > > : В значении параметра можно использовать переменные. В этом случае, если адрес > : указан в виде доменного имени, имя ищется среди описанных групп серверов и если > : не найдено, то определяется с помощью resolver’а. > >> всё же какой-то глюк тут явно есть… >> что за внутренняя процедура в nginx relover по умолчанию и почему она не полностью следует hosts-файлу? >> >> почему резолвится только часть имён? да и что за чудеса, чем upstream так помогает резолвингу? > > По умолчанию resolver не определён, и при динамическом резолвинге > будут работать только IP-адреса, имена upstream'ов и имена, > используемые в других частях конфига статически (так как для них > создаются неявные upstream'ы). > > -- > 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 Sep 11 12:32:15 2020 From: nginx-forum на forum.nginx.org (BieZax) Date: Fri, 11 Sep 2020 08:32:15 -0400 Subject: =?UTF-8?B?bmd4IGh0dHAgdXNlcmlkIG1vZHVsZSDQuCDQsNGC0YDQuNCx0YPRgtGLINC60YM=?= =?UTF-8?B?0LrQuA==?= Message-ID: <8f7f6d7f6a81e48a2aa4db26ddf416f9.NginxMailingListRussian@forum.nginx.org> В последних версиях chrome атрибуты кук "SameSite=None; Secure" стали обязательны, если необходимо, что-бы куки были доступны при обращении со сторонних ресурсов, например, если ресурс работает через frame’ы. Я использую модуль ngx_http_userid_module для идентификации уникальных пользователей, и это перестало работать в вышеописанных условиях. Модуль манипулировать этими атрибутами не умеет. Пробовал header_filter_by_lua, но так тоже не получилось получить доступ до нужной куки. Есть какой-то способ, кроме создания еще одного server, и изменения уже проксируемых кук? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289396,289396#msg-289396 From nginx-forum на forum.nginx.org Fri Sep 11 14:23:08 2020 From: nginx-forum на forum.nginx.org (akoval) Date: Fri, 11 Sep 2020 10:23:08 -0400 Subject: =?UTF-8?B?0J3QtSDQvNC+0LPRgyDQv9C+0L3Rj9GC0Ywg0LrQsNC6INGA0LDQsdC+0YLQsNC1?= =?UTF-8?B?0YIgbG9jYXRpb24uLi4=?= Message-ID: <3a2861e740064ae1e375d55b3267ad4e.NginxMailingListRussian@forum.nginx.org> Всем доброго! Посоветуйте, не могу въехать). Есть такие настройки сервера, помимо стандарных настроек nginx: server { listen xxx.xxx.xxx.xxx:80 default_server; server_name my_host; return 404; access_log off; error_log /var/log/nginx/error_by_ip.log crit; } server { listen xxx.xxx.xxx.xxx:443 default_server; server_name my_host; return 404; access_log off; error_log /var/log/nginx/error_by_ip.log crit; } server { listen 80; server_name my_host; rewrite ^/ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo$ https://my_host/blog-item/koronavirus-vse-shcho-potribno-znaty-pro-noho/ permanent; location = / { return 301 https://apteka-ds.com.ua; } } Вопрос: первый вход на http://my_host/ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo ведет на https://my_host/blog-item/koronavirus-vse-shcho-potribno-znaty-pro-noho/. когда захожу второй раз на http://my_host/ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo ведет на https://my_host/error-404 чищу кеш браузера, снова первый раз заходит, следующие лажа. Куда рыть? голова уже квадратная) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289398,289398#msg-289398 From nginx-forum на forum.nginx.org Fri Sep 11 14:45:38 2020 From: nginx-forum на forum.nginx.org (akoval) Date: Fri, 11 Sep 2020 10:45:38 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0LzQvtCz0YMg0L/QvtC90Y/RgtGMINC60LDQuiDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIGxvY2F0aW9uLi4u?= In-Reply-To: <3a2861e740064ae1e375d55b3267ad4e.NginxMailingListRussian@forum.nginx.org> References: <3a2861e740064ae1e375d55b3267ad4e.NginxMailingListRussian@forum.nginx.org> Message-ID: <793de1ccc8860129c8b4e9bf617d4da5.NginxMailingListRussian@forum.nginx.org> Дошлооо... Редиректы надо в основном блоке server прописыватььь... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289398,289399#msg-289399 From oleg на mamontov.net Fri Sep 11 15:51:28 2020 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Fri, 11 Sep 2020 18:51:28 +0300 Subject: =?UTF-8?B?UmU6IG5neCBodHRwIHVzZXJpZCBtb2R1bGUg0Lgg0LDRgtGA0LjQsdGD0YLRiyA=?= =?UTF-8?B?0LrRg9C60Lg=?= In-Reply-To: <8f7f6d7f6a81e48a2aa4db26ddf416f9.NginxMailingListRussian@forum.nginx.org> References: <8f7f6d7f6a81e48a2aa4db26ddf416f9.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200911155128.43uvhmhdgaumc2ph@xenon.mamontov.net> On Fri, Sep 11, 2020 at 08:32:15AM -0400, BieZax wrote: >В последних версиях chrome атрибуты кук "SameSite=None; Secure" стали >обязательны, если необходимо, что-бы куки были доступны при обращении со >сторонних ресурсов, например, если ресурс работает через frame’ы. Я >использую модуль ngx_http_userid_module для идентификации уникальных >пользователей, и это перестало работать в вышеописанных условиях. Модуль >манипулировать этими атрибутами не умеет. Пробовал header_filter_by_lua, >но так тоже не получилось получить доступ до нужной куки. Есть какой-то >способ, кроме создания еще одного server, и изменения уже проксируемых кук? Прямого решения нет, но есть простой и рабочий хак: userid_path '/; SameSite=None; Secure'; -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From nginx-forum на forum.nginx.org Tue Sep 15 13:21:10 2020 From: nginx-forum на forum.nginx.org (bagas) Date: Tue, 15 Sep 2020 09:21:10 -0400 Subject: nginx 1.18 lua51 Message-ID: Добрый день. Подскажите пожалуйста по проблеме как быть. Установил lua51 и указала поддержку в nginx lua. Создал виртуал хост, делаю проверку синтаксиса. Nginx ставил из портов. nginx -t nginx: [emerg] unknown directive "content_by_lua_block" in /usr/local/etc/nginx/sites-enabled/test.jpeg_png:49 nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed Почему-то не видится директива content_by_lua_block. Система freebsd 11.3 Nginx собран с --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.17 nginx -V nginx version: nginx/1.18.0 built with OpenSSL 1.1.1g 21 Apr 2020 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-pcre --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_sub_module --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-threads --with-stream=dynamic --add-dynamic-module=/usr/ports/www/nginx/work/ngx_devel_kit-0.3.1 --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.17 Софт в системе установлен такой: lua-resty-core-0.1.19 = lua-resty-lrucache-0.10 = lua51-5.1.5_9 = lua51-luarocks-3.3.1 = luajit-openresty-2.1.20200102 = Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289421,289421#msg-289421 From raven_kg на megaline.kg Wed Sep 16 02:46:01 2020 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Wed, 16 Sep 2020 08:46:01 +0600 Subject: nginx 1.18 lua51 In-Reply-To: References: Message-ID: Одно дело собрать с нужным модулем, другое дело - запустить с ним. Модуль собран динамически, соотв. должен быть загружен черезhttp://nginx.org/ru/docs/ngx_core_module.html#load_module 15.09.2020 19:21, bagas пишет: > Добрый день. > Подскажите пожалуйста по проблеме как быть. > Установил lua51 и указала поддержку в nginx lua. > Создал виртуал хост, делаю проверку синтаксиса. > > Nginx ставил из портов. > > nginx -t > nginx: [emerg] unknown directive "content_by_lua_block" in > /usr/local/etc/nginx/sites-enabled/test.jpeg_png:49 > nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed > > Почему-то не видится директива content_by_lua_block. > > Система freebsd 11.3 > > Nginx собран с > --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.17 > > nginx -V > nginx version: nginx/1.18.0 > built with OpenSSL 1.1.1g 21 Apr 2020 > TLS SNI support enabled > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx/error.log --user=www --group=www > --modules-path=/usr/local/libexec/nginx --with-file-aio > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx/access.log --with-http_v2_module > --with-http_addition_module --with-http_auth_request_module > --with-http_gunzip_module --with-http_gzip_static_module > --with-http_random_index_module --with-pcre --with-http_secure_link_module > --with-http_slice_module --with-http_ssl_module --with-http_sub_module > --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' > --without-mail_imap_module --without-mail_pop3_module > --without-mail_smtp_module --with-threads --with-stream=dynamic > --add-dynamic-module=/usr/ports/www/nginx/work/ngx_devel_kit-0.3.1 > --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.17 > > Софт в системе установлен такой: > > lua-resty-core-0.1.19 = > lua-resty-lrucache-0.10 = > lua51-5.1.5_9 = > lua51-luarocks-3.3.1 = > luajit-openresty-2.1.20200102 = > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289421,289421#msg-289421 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Sep 19 08:12:06 2020 From: nginx-forum на forum.nginx.org (SpectR16) Date: Sat, 19 Sep 2020 04:12:06 -0400 Subject: RTMP restream server In-Reply-To: <5d7870ef5a3f7dde5f852ad56d2cf8fc.NginxMailingListRussian@forum.nginx.org> References: <5d7870ef5a3f7dde5f852ad56d2cf8fc.NginxMailingListRussian@forum.nginx.org> Message-ID: Сам начал изучать этот вопрос и вроде даже понимаю как это сделать. Второй nginx не нужен, в конфиге просто создайте новый application, только укажите не live, а что то другое и впишите те сервисы, которые нужны. Если это не сработает, попробуйте создать новый раздел rtmp в конфиге и укажите все нужные сервисы. Я до этого еще не дошел, но вы можете попытаться. Помог чем мог )) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288508,289437#msg-289437 From nginx-forum на forum.nginx.org Sun Sep 20 19:09:09 2020 From: nginx-forum на forum.nginx.org (pavlusha23) Date: Sun, 20 Sep 2020 15:09:09 -0400 Subject: =?UTF-8?B?UmU6INCS0YvRh9C40YHQu9C40YLRjCDQtNC70LjQvdGDIHVzZXIgYWdlbnQ=?= In-Reply-To: <1746c7742ca.10f5e5206320355.8512793539691334826@dl.sm.ua> References: <1746c7742ca.10f5e5206320355.8512793539691334826@dl.sm.ua> Message-ID: <2b557cf9c375070d3a1b3169ba554c03.NginxMailingListRussian@forum.nginx.org> У меня был вариант с perl, но ваш действительно элегантнее. Спасибо:-) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289344,289441#msg-289441 From akapulko на gmail.com Wed Sep 23 01:10:12 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 04:10:12 +0300 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzRiyDRgdC+INGB0LLRj9C30L3QvtGB0YLRjNGOINC/0L4g?= =?UTF-8?B?aXB2NiDRgdCw0LnRgtCwIG5naW54Lm9yZw==?= Message-ID: Здравствуйте. Если у клиента ipv6 адрес, то домен nginx.org гарантированно не ресолвится первый раз, второй и последующие - ресолвится, потом через два часа по новой. Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес (подключение). А пока вынуждены таким костылем пользоваться: ping -4 -w 1 -c 1 -q nginx.org >> /dev/null Спасибо. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Wed Sep 23 06:19:36 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 23 Sep 2020 09:19:36 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: Message-ID: <20200923061936.GF4644@sie.protva.ru> On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote: > Если у клиента ipv6 адрес, то домен nginx.org гарантированно не > ресолвится первый раз, второй и последующие - ресолвится, потом через два > часа по новой.   Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем nginx-то в этом провинился? > Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес > (подключение). Каким образом это может исправить ситуацию? Изложите механизм чуда. > А пока вынуждены таким костылем пользоваться: > > ping -4 -w 1 -c 1 -q nginx.org >> /dev/null Это скорее не костыль, а шаманство. -- Eugene Berdnikov From sb на nginx.com Wed Sep 23 09:21:08 2020 From: sb на nginx.com (Sergey Budnevitch) Date: Wed, 23 Sep 2020 12:21:08 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200923061936.GF4644@sie.protva.ru> References: <20200923061936.GF4644@sie.protva.ru> Message-ID: <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> Добрый день Резолвер клиенты какой используют? > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov wrote: > > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote: >> Если у клиента ipv6 адрес, то домен nginx.org гарантированно не >> ресолвится первый раз, второй и последующие - ресолвится, потом через два >> часа по новой. > > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем > nginx-то в этом провинился? > >> Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес >> (подключение). > > Каким образом это может исправить ситуацию? Изложите механизм чуда. > >> А пока вынуждены таким костылем пользоваться: >> >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null > > Это скорее не костыль, а шаманство. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From akapulko на gmail.com Wed Sep 23 12:51:35 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 15:51:35 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> Message-ID: ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch : > Добрый день > > Резолвер клиенты какой используют? > Здравствуйте. Клиент получает и Ipv6 и Ipv4 ресолвер. Первым, получается, используется ipv6 ресолвер. > > > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov wrote: > > > > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote: > >> Если у клиента ipv6 адрес, то домен nginx.org гарантированно не > >> ресолвится первый раз, второй и последующие - ресолвится, потом через > два > >> часа по новой. > > > > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем > > nginx-то в этом провинился? > > > >> Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес > >> (подключение). > > > > Каким образом это может исправить ситуацию? Изложите механизм чуда. > > > >> А пока вынуждены таким костылем пользоваться: > >> > >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null > > > > Это скорее не костыль, а шаманство. > > -- > > Eugene Berdnikov > > _______________________________________________ > > 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 akapulko на gmail.com Wed Sep 23 13:59:50 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 16:59:50 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> Message-ID: Ну, и заодно "помешайте" NS сервера для доменов nginx.com nginx.net nginx.org. Например, nginx.com nginx.com name server ns.nginx.net. nginx.com name server ns2.nginx.com. nginx.com name server ns3.nginx.org. ср, 23 сент. 2020 г. в 15:51, Vladislav V. Prodan : > > > ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch : > >> Добрый день >> >> Резолвер клиенты какой используют? >> > > Здравствуйте. > Клиент получает и Ipv6 и Ipv4 ресолвер. > Первым, получается, используется ipv6 ресолвер. > > > >> >> > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov wrote: >> > >> > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote: >> >> Если у клиента ipv6 адрес, то домен nginx.org гарантированно не >> >> ресолвится первый раз, второй и последующие - ресолвится, потом >> через два >> >> часа по новой. >> > >> > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем >> > nginx-то в этом провинился? >> > >> >> Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес >> >> (подключение). >> > >> > Каким образом это может исправить ситуацию? Изложите механизм чуда. >> > >> >> А пока вынуждены таким костылем пользоваться: >> >> >> >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null >> > >> > Это скорее не костыль, а шаманство. >> > -- >> > Eugene Berdnikov >> > _______________________________________________ >> > 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 akapulko на gmail.com Wed Sep 23 14:58:17 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 17:58:17 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> Message-ID: Попытался воспроизвести проблему. Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: nginx.org Address: 3.125.197.172 Name: nginx.org Address: 52.58.199.22 Name: nginx.org Address: 2a05:d014:edb:5702::6 Name: nginx.org Address: 2a05:d014:edb:5704::6 Сущ:1 http://security.debian.org/debian-security buster/updates InRelease Сущ:2 http://deb.debian.org/debian buster InRelease Сущ:3 http://deb.debian.org/debian buster-updates InRelease Сущ:4 https://packages.sury.org/php buster InRelease Ошб:5 http://nginx.org/packages/debian buster InRelease Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] Чтение списков пакетов… Готово W: Не удалось получить http://nginx.org/packages/debian/dists/buster/InRelease Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] W: Некоторые индексные файлы скачать не удалось. Они были проигнорированы, или вместо них были использованы старые версии. Чтение списков пакетов… Готово ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch : > Добрый день > > Резолвер клиенты какой используют? > > > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov wrote: > > > > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote: > >> Если у клиента ipv6 адрес, то домен nginx.org гарантированно не > >> ресолвится первый раз, второй и последующие - ресолвится, потом через > два > >> часа по новой. > > > > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем > > nginx-то в этом провинился? > > > >> Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес > >> (подключение). > > > > Каким образом это может исправить ситуацию? Изложите механизм чуда. > > > >> А пока вынуждены таким костылем пользоваться: > >> > >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null > > > > Это скорее не костыль, а шаманство. > > -- > > Eugene Berdnikov > > _______________________________________________ > > 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 sb на nginx.com Wed Sep 23 15:05:33 2020 From: sb на nginx.com (Sergey Budnevitch) Date: Wed, 23 Sep 2020 18:05:33 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> Message-ID: <120B9DC4-4EA5-48F4-AFBF-3C2BBCAA2BB8@nginx.com> > On 23 Sep 2020, at 16:59, Vladislav V. Prodan wrote: > > Ну, и заодно "помешайте" NS сервера для доменов nginx.com nginx.net nginx.org . Это бессмысленное занятие, если добавлены glue records, для зон nginx.com & nginx.org glue records они существуют. > > Например, > nginx.com > nginx.com name server ns.nginx.net . > nginx.com name server ns2.nginx.com . > nginx.com name server ns3.nginx.org . > > > ср, 23 сент. 2020 г. в 15:51, Vladislav V. Prodan >: > > > ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch >: > Добрый день > > Резолвер клиенты какой используют? > > Здравствуйте. > Клиент получает и Ipv6 и Ipv4 ресолвер. > Первым, получается, используется ipv6 ресолвер. > > > > > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov > wrote: > > > > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote: > >> Если у клиента ipv6 адрес, то домен nginx.org гарантированно не > >> ресолвится первый раз, второй и последующие - ресолвится, потом через два > >> часа по новой. > > > > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, чем > > nginx-то в этом провинился? > > > >> Как решение проблемы, добавить NS для nginx.org , имеющий ipv6 адрес > >> (подключение). > > > > Каким образом это может исправить ситуацию? Изложите механизм чуда. > > > >> А пока вынуждены таким костылем пользоваться: > >> > >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null > > > > Это скорее не костыль, а шаманство. > > -- > > Eugene Berdnikov > > _______________________________________________ > > 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 sb на nginx.com Wed Sep 23 15:09:17 2020 From: sb на nginx.com (Sergey Budnevitch) Date: Wed, 23 Sep 2020 18:09:17 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> Message-ID: <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> > On 23 Sep 2020, at 17:58, Vladislav V. Prodan wrote: > > > Попытался воспроизвести проблему. > > Server: 8.8.8.8 > Address: 8.8.8.8#53 > > Non-authoritative answer: > Name: nginx.org > Address: 3.125.197.172 > Name: nginx.org > Address: 52.58.199.22 > Name: nginx.org > Address: 2a05:d014:edb:5702::6 > Name: nginx.org > Address: 2a05:d014:edb:5704::6 > > Сущ:1 http://security.debian.org/debian-security buster/updates InRelease > Сущ:2 http://deb.debian.org/debian buster InRelease > Сущ:3 http://deb.debian.org/debian buster-updates InRelease > Сущ:4 https://packages.sury.org/php buster InRelease > Ошб:5 http://nginx.org/packages/debian buster InRelease > Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] > Чтение списков пакетов… Готово > W: Не удалось получить http://nginx.org/packages/debian/dists/buster/InRelease Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] > W: Некоторые индексные файлы скачать не удалось. Они были проигнорированы, или вместо них были использованы старые версии. > Чтение списков пакетов… Готово То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с соединением. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akapulko на gmail.com Wed Sep 23 15:10:59 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 18:10:59 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <120B9DC4-4EA5-48F4-AFBF-3C2BBCAA2BB8@nginx.com> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <120B9DC4-4EA5-48F4-AFBF-3C2BBCAA2BB8@nginx.com> Message-ID: ср, 23 сент. 2020 г. в 18:05, Sergey Budnevitch : > > On 23 Sep 2020, at 16:59, Vladislav V. Prodan wrote: > > Ну, и заодно "помешайте" NS сервера для доменов nginx.com nginx.net > nginx.org. > > > Это бессмысленное занятие, если добавлены glue records, > для зон nginx.com & nginx.org glue records они существуют. > Это не решит проблему, в случае отвала зоны .com целиком. glue records совершенно для другого. > > > Например, > nginx.com > nginx.com name server ns.nginx.net. > nginx.com name server ns2.nginx.com. > nginx.com name server ns3.nginx.org. > > > ср, 23 сент. 2020 г. в 15:51, Vladislav V. Prodan : > >> >> >> ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch : >> >>> Добрый день >>> >>> Резолвер клиенты какой используют? >>> >> >> Здравствуйте. >> Клиент получает и Ipv6 и Ipv4 ресолвер. >> Первым, получается, используется ipv6 ресолвер. >> >> >> >>> >>> > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov wrote: >>> > >>> > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote: >>> >> Если у клиента ipv6 адрес, то домен nginx.org гарантированно не >>> >> ресолвится первый раз, второй и последующие - ресолвится, потом >>> через два >>> >> часа по новой. >>> > >>> > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, >>> чем >>> > nginx-то в этом провинился? >>> > >>> >> Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес >>> >> (подключение). >>> > >>> > Каким образом это может исправить ситуацию? Изложите механизм чуда. >>> > >>> >> А пока вынуждены таким костылем пользоваться: >>> >> >>> >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null >>> > >>> > Это скорее не костыль, а шаманство. >>> > -- >>> > Eugene Berdnikov >>> > _______________________________________________ >>> > 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 akapulko на gmail.com Wed Sep 23 15:12:32 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 18:12:32 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> Message-ID: ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch : > > > On 23 Sep 2020, at 17:58, Vladislav V. Prodan wrote: > > > Попытался воспроизвести проблему. > > Server: 8.8.8.8 > Address: 8.8.8.8#53 > > Non-authoritative answer: > Name: nginx.org > Address: 3.125.197.172 > Name: nginx.org > Address: 52.58.199.22 > Name: nginx.org > Address: 2a05:d014:edb:5702::6 > Name: nginx.org > Address: 2a05:d014:edb:5704::6 > > Сущ:1 http://security.debian.org/debian-security buster/updates InRelease > Сущ:2 http://deb.debian.org/debian buster InRelease > Сущ:3 http://deb.debian.org/debian buster-updates InRelease > Сущ:4 https://packages.sury.org/php buster InRelease > Ошб:5 http://nginx.org/packages/debian buster InRelease > Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] > Чтение списков пакетов… Готово > W: Не удалось получить > http://nginx.org/packages/debian/dists/buster/InRelease Соединение > разорвано [IP: 2a05:d014:edb:5704::6 80] > W: Некоторые индексные файлы скачать не удалось. Они были проигнорированы, > или вместо них были использованы старые версии. > Чтение списков пакетов… Готово > > > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с > соединением. > Спасибо. Я подожду, когда вы разберетесь с настройками ipv6 в AWS. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Sep 23 16:13:58 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 23 Sep 2020 19:13:58 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> Message-ID: <20200923161358.GG1136@mdounin.ru> Hello! On Wed, Sep 23, 2020 at 06:12:32PM +0300, Vladislav V. Prodan wrote: > ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch : > > > On 23 Sep 2020, at 17:58, Vladislav V. Prodan wrote: > > > > > > Попытался воспроизвести проблему. > > > > Server: 8.8.8.8 > > Address: 8.8.8.8#53 > > > > Non-authoritative answer: > > Name: nginx.org > > Address: 3.125.197.172 > > Name: nginx.org > > Address: 52.58.199.22 > > Name: nginx.org > > Address: 2a05:d014:edb:5702::6 > > Name: nginx.org > > Address: 2a05:d014:edb:5704::6 > > > > Сущ:1 http://security.debian.org/debian-security buster/updates InRelease > > Сущ:2 http://deb.debian.org/debian buster InRelease > > Сущ:3 http://deb.debian.org/debian buster-updates InRelease > > Сущ:4 https://packages.sury.org/php buster InRelease > > Ошб:5 http://nginx.org/packages/debian buster InRelease > > Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] > > Чтение списков пакетов… Готово > > W: Не удалось получить > > http://nginx.org/packages/debian/dists/buster/InRelease Соединение > > разорвано [IP: 2a05:d014:edb:5704::6 80] > > W: Некоторые индексные файлы скачать не удалось. Они были проигнорированы, > > или вместо них были использованы старые версии. > > Чтение списков пакетов… Готово > > > > > > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с > > соединением. > > > > Спасибо. > Я подожду, когда вы разберетесь с настройками ipv6 в AWS. Модель поведения - публично облажаться, после чего нахамить и слиться - понятная, но не конструктивная. Явно имеет место какая-то проблема, и возможно она на нашей стороне. Поскольку в настоящий момент вы единственный, у кого она проявляется - только вы можете разобраться, что происходит. Я бы начал с простого: проверил, получается ли запросить упомянутый URL с проблемного IP-адреса руками, например: $ curl -vso /dev/null --resolve nginx.org:80:[2a05:d014:edb:5704::6] http://nginx.org/packages/debian/dists/buster/InRelease * Added nginx.org:80:[2a05:d014:edb:5704::6] to DNS cache * Hostname nginx.org was found in DNS cache * Trying 2a05:d014:edb:5704::6:80... * Connected to nginx.org (2a05:d014:edb:5704::6) port 80 (#0) > GET /packages/debian/dists/buster/InRelease HTTP/1.1 > Host: nginx.org > User-Agent: curl/7.72.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Server: nginx/1.19.0 < Date: Wed, 23 Sep 2020 16:10:59 GMT < Content-Type: application/octet-stream < Content-Length: 2854 < Last-Modified: Tue, 11 Aug 2020 17:08:59 GMT < Connection: keep-alive < Keep-Alive: timeout=15 < ETag: "5f32d0ab-b26" < Accept-Ranges: bytes < { [2854 bytes data] * Connection #0 to host nginx.org left intact -- Maxim Dounin http://mdounin.ru/ From akapulko на gmail.com Wed Sep 23 17:43:08 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 20:43:08 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200923161358.GG1136@mdounin.ru> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> Message-ID: ср, 23 сент. 2020 г. в 19:14, Maxim Dounin : > Hello! > > On Wed, Sep 23, 2020 at 06:12:32PM +0300, Vladislav V. Prodan wrote: > > > ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch : > > > > > On 23 Sep 2020, at 17:58, Vladislav V. Prodan > wrote: > > > > > > > > > Попытался воспроизвести проблему. > > > > > > Server: 8.8.8.8 > > > Address: 8.8.8.8#53 > > > > > > Non-authoritative answer: > > > Name: nginx.org > > > Address: 3.125.197.172 > > > Name: nginx.org > > > Address: 52.58.199.22 > > > Name: nginx.org > > > Address: 2a05:d014:edb:5702::6 > > > Name: nginx.org > > > Address: 2a05:d014:edb:5704::6 > > > > > > Сущ:1 http://security.debian.org/debian-security buster/updates > InRelease > > > Сущ:2 http://deb.debian.org/debian buster InRelease > > > Сущ:3 http://deb.debian.org/debian buster-updates InRelease > > > Сущ:4 https://packages.sury.org/php buster InRelease > > > Ошб:5 http://nginx.org/packages/debian buster InRelease > > > Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] > > > Чтение списков пакетов… Готово > > > W: Не удалось получить > > > http://nginx.org/packages/debian/dists/buster/InRelease Соединение > > > разорвано [IP: 2a05:d014:edb:5704::6 80] > > > W: Некоторые индексные файлы скачать не удалось. Они были > проигнорированы, > > > или вместо них были использованы старые версии. > > > Чтение списков пакетов… Готово > > > > > > > > > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с > > > соединением. > > > > > > > Спасибо. > > Я подожду, когда вы разберетесь с настройками ipv6 в AWS. > > Модель поведения - публично облажаться, после чего нахамить и > слиться - понятная, но не конструктивная. Здравствуйте, Максим. Имеет место три проблемы, связанные с DNS, Ipv6 и вашим хостингом на AWS. > Явно имеет место > какая-то проблема, и возможно она на нашей стороне. Поскольку в > настоящий момент вы единственный, у кого она проявляется - только > вы можете разобраться, что происходит. > Да, я вижу. На обоих трассах с he.net потери 3-10% на хопах внутри Амазона. Кроме вас ну никто не может обратиться в ТП Амазона с указанными потерями. И при условии, что вы внутри не намудрили с списками доступами и firewall. > > Я бы начал с простого: проверил, получается ли запросить > упомянутый URL с проблемного IP-адреса руками, например: > Еще раз прочтите первое сообщение. НЕ работает первый запрос, второй и последующие - работают. И перестают работать где-то через час-два. P.S. И не судите о других по своим заключениям/измышлениям. > > $ curl -vso /dev/null --resolve nginx.org:80:[2a05:d014:edb:5704::6] > http://nginx.org/packages/debian/dists/buster/InRelease > * Added nginx.org:80:[2a05:d014:edb:5704::6] to DNS cache > * Hostname nginx.org was found in DNS cache > * Trying 2a05:d014:edb:5704::6:80... > * Connected to nginx.org (2a05:d014:edb:5704::6) port 80 (#0) > > GET /packages/debian/dists/buster/InRelease HTTP/1.1 > > Host: nginx.org > > User-Agent: curl/7.72.0 > > Accept: */* > > > * Mark bundle as not supporting multiuse > < HTTP/1.1 200 OK > < Server: nginx/1.19.0 > < Date: Wed, 23 Sep 2020 16:10:59 GMT > < Content-Type: application/octet-stream > < Content-Length: 2854 > < Last-Modified: Tue, 11 Aug 2020 17:08:59 GMT > < Connection: keep-alive > < Keep-Alive: timeout=15 > < ETag: "5f32d0ab-b26" > < Accept-Ranges: bytes > < > { [2854 bytes data] > * Connection #0 to host nginx.org left intact > > > -- > 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 Wed Sep 23 19:24:22 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 23 Sep 2020 22:24:22 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> Message-ID: <20200923192422.GI1136@mdounin.ru> Hello! On Wed, Sep 23, 2020 at 08:43:08PM +0300, Vladislav V. Prodan wrote: > ср, 23 сент. 2020 г. в 19:14, Maxim Dounin : > > > Hello! > > > > On Wed, Sep 23, 2020 at 06:12:32PM +0300, Vladislav V. Prodan wrote: > > > > > ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch : > > > > > > > On 23 Sep 2020, at 17:58, Vladislav V. Prodan > > wrote: > > > > > > > > > > > > Попытался воспроизвести проблему. > > > > > > > > Server: 8.8.8.8 > > > > Address: 8.8.8.8#53 > > > > > > > > Non-authoritative answer: > > > > Name: nginx.org > > > > Address: 3.125.197.172 > > > > Name: nginx.org > > > > Address: 52.58.199.22 > > > > Name: nginx.org > > > > Address: 2a05:d014:edb:5702::6 > > > > Name: nginx.org > > > > Address: 2a05:d014:edb:5704::6 > > > > > > > > Сущ:1 http://security.debian.org/debian-security buster/updates > > InRelease > > > > Сущ:2 http://deb.debian.org/debian buster InRelease > > > > Сущ:3 http://deb.debian.org/debian buster-updates InRelease > > > > Сущ:4 https://packages.sury.org/php buster InRelease > > > > Ошб:5 http://nginx.org/packages/debian buster InRelease > > > > Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] > > > > Чтение списков пакетов… Готово > > > > W: Не удалось получить > > > > http://nginx.org/packages/debian/dists/buster/InRelease Соединение > > > > разорвано [IP: 2a05:d014:edb:5704::6 80] > > > > W: Некоторые индексные файлы скачать не удалось. Они были > > проигнорированы, > > > > или вместо них были использованы старые версии. > > > > Чтение списков пакетов… Готово > > > > > > > > > > > > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит с > > > > соединением. > > > > > > > > > > Спасибо. > > > Я подожду, когда вы разберетесь с настройками ipv6 в AWS. > > > > Модель поведения - публично облажаться, после чего нахамить и > > слиться - понятная, но не конструктивная. > > Здравствуйте, Максим. > Имеет место три проблемы, связанные с DNS, Ipv6 и вашим хостингом на AWS. Продемонстрированная проблема ровно одна: пакетный менеджер не может получить http://nginx.org/packages/debian/dists/buster/InRelease с IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. Почему не может - вопрос для дополнительного разбирательства. Которое вы, почему-то, проводить не хотите даже на минимальном уровне. Какие-либо проблемы с DNS - не продемонстрированы. Наоброт, продемострировано, что если и есть какие-то теоретические претензии к DNS, как то отсутствие IPv6 NS-серверов, то они не относятся к наблюдаемой проблеме. > > Явно имеет место > > какая-то проблема, и возможно она на нашей стороне. Поскольку в > > настоящий момент вы единственный, у кого она проявляется - только > > вы можете разобраться, что происходит. > > > > Да, я вижу. На обоих трассах с he.net потери 3-10% на хопах внутри Амазона. > Кроме вас ну никто не может обратиться в ТП Амазона с указанными потерями. > И при условии, что вы внутри не намудрили с списками доступами и firewall. Потери в современном интернете, к сожалению, довольно трудно оценивать, ибо ICMP, даже если и не зафильтрован, обрабатывается по остаточном принципу. Но так или иначе потери не объясняют наблюдаемое вами поведение. > > Я бы начал с простого: проверил, получается ли запросить > > упомянутый URL с проблемного IP-адреса руками, например: > > > > Еще раз прочтите первое сообщение. > НЕ работает первый запрос, второй и последующие - работают. > И перестают работать где-то через час-два. Ну вот и попробуйте запросить руками через час-два. Лучше - с tcpdump'ом, чтобы видеть, что при этом происходит на уровне сети. И ещё можно Сергею скинуть IP-адрес, чтобы он посмотрел на происходящее со стороны сервера. (И да, в первом сообщении написано про "домен не ресолвится первый раз", что, как мы уже выяснили, не соответствует действительности. Не надо, пожалуйста, продолжать хамить, это гарантировано не приведёт ни к чему хорошему. Спасибо.) -- Maxim Dounin http://mdounin.ru/ From akapulko на gmail.com Wed Sep 23 20:06:25 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 23:06:25 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200923192422.GI1136@mdounin.ru> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> Message-ID: ср, 23 сент. 2020 г. в 22:24, Maxim Dounin : > Hello! > > On Wed, Sep 23, 2020 at 08:43:08PM +0300, Vladislav V. Prodan wrote: > > > ср, 23 сент. 2020 г. в 19:14, Maxim Dounin : > > > > > Hello! > > > > > > On Wed, Sep 23, 2020 at 06:12:32PM +0300, Vladislav V. Prodan wrote: > > > > > > > ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch : > > > > > > > > > On 23 Sep 2020, at 17:58, Vladislav V. Prodan > > > wrote: > > > > > > > > > > > > > > > Попытался воспроизвести проблему. > > > > > > > > > > Server: 8.8.8.8 > > > > > Address: 8.8.8.8#53 > > > > > > > > > > Non-authoritative answer: > > > > > Name: nginx.org > > > > > Address: 3.125.197.172 > > > > > Name: nginx.org > > > > > Address: 52.58.199.22 > > > > > Name: nginx.org > > > > > Address: 2a05:d014:edb:5702::6 > > > > > Name: nginx.org > > > > > Address: 2a05:d014:edb:5704::6 > > > > > > > > > > Сущ:1 http://security.debian.org/debian-security buster/updates > > > InRelease > > > > > Сущ:2 http://deb.debian.org/debian buster InRelease > > > > > Сущ:3 http://deb.debian.org/debian buster-updates InRelease > > > > > Сущ:4 https://packages.sury.org/php buster InRelease > > > > > Ошб:5 http://nginx.org/packages/debian buster InRelease > > > > > Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] > > > > > Чтение списков пакетов… Готово > > > > > W: Не удалось получить > > > > > http://nginx.org/packages/debian/dists/buster/InRelease > Соединение > > > > > разорвано [IP: 2a05:d014:edb:5704::6 80] > > > > > W: Некоторые индексные файлы скачать не удалось. Они были > > > проигнорированы, > > > > > или вместо них были использованы старые версии. > > > > > Чтение списков пакетов… Готово > > > > > > > > > > > > > > > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит > с > > > > > соединением. > > > > > > > > > > > > > Спасибо. > > > > Я подожду, когда вы разберетесь с настройками ipv6 в AWS. > > > > > > Модель поведения - публично облажаться, после чего нахамить и > > > слиться - понятная, но не конструктивная. > > > > Здравствуйте, Максим. > > Имеет место три проблемы, связанные с DNS, Ipv6 и вашим хостингом на AWS. > > Продемонстрированная проблема ровно одна: пакетный менеджер не > может получить > http://nginx.org/packages/debian/dists/buster/InRelease с > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > Первый запрос дождался таймаута (непонятно почему). Второй запрос выполнился мгновенно. https://pastebin.com/dWbffATH В соседнем окне скрина, во время работы первого запроса к nginx.org, curl прекрасно загрузил и youtube.com и ya.ru по IPv6. > Почему не может - вопрос для дополнительного разбирательства. > Которое вы, почему-то, проводить не хотите даже на минимальном > уровне. > > Какие-либо проблемы с DNS - не продемонстрированы. Наоброт, > продемострировано, что если и есть какие-то теоретические > претензии к DNS, как то отсутствие IPv6 NS-серверов, то они не > относятся к наблюдаемой проблеме. > > > > Явно имеет место > > > какая-то проблема, и возможно она на нашей стороне. Поскольку в > > > настоящий момент вы единственный, у кого она проявляется - только > > > вы можете разобраться, что происходит. > > > > > > > Да, я вижу. На обоих трассах с he.net потери 3-10% на хопах внутри > Амазона. > > Кроме вас ну никто не может обратиться в ТП Амазона с указанными > потерями. > > И при условии, что вы внутри не намудрили с списками доступами и > firewall. > > Потери в современном интернете, к сожалению, довольно трудно > оценивать, ибо ICMP, даже если и не зафильтрован, обрабатывается > по остаточном принципу. Но так или иначе потери не объясняют > наблюдаемое вами поведение. > > > > Я бы начал с простого: проверил, получается ли запросить > > > упомянутый URL с проблемного IP-адреса руками, например: > > > > > > > Еще раз прочтите первое сообщение. > > НЕ работает первый запрос, второй и последующие - работают. > > И перестают работать где-то через час-два. > > Ну вот и попробуйте запросить руками через час-два. Лучше - с > tcpdump'ом, чтобы видеть, что при этом происходит на уровне сети. > И ещё можно Сергею скинуть IP-адрес, чтобы он посмотрел на > происходящее со стороны сервера. > > (И да, в первом сообщении написано про "домен не ресолвится первый > раз", что, как мы уже выяснили, не соответствует действительности. > Не надо, пожалуйста, продолжать хамить, это гарантировано не > приведёт ни к чему хорошему. Спасибо.) > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From akapulko на gmail.com Wed Sep 23 20:11:12 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Wed, 23 Sep 2020 23:11:12 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200923192422.GI1136@mdounin.ru> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> Message-ID: ср, 23 сент. 2020 г. в 22:24, Maxim Dounin : > Hello! > > On Wed, Sep 23, 2020 at 08:43:08PM +0300, Vladislav V. Prodan wrote: > > > ср, 23 сент. 2020 г. в 19:14, Maxim Dounin : > > > > > Hello! > > > > > > On Wed, Sep 23, 2020 at 06:12:32PM +0300, Vladislav V. Prodan wrote: > > > > > > > ср, 23 сент. 2020 г. в 18:09, Sergey Budnevitch : > > > > > > > > > On 23 Sep 2020, at 17:58, Vladislav V. Prodan > > > wrote: > > > > > > > > > > > > > > > Попытался воспроизвести проблему. > > > > > > > > > > Server: 8.8.8.8 > > > > > Address: 8.8.8.8#53 > > > > > > > > > > Non-authoritative answer: > > > > > Name: nginx.org > > > > > Address: 3.125.197.172 > > > > > Name: nginx.org > > > > > Address: 52.58.199.22 > > > > > Name: nginx.org > > > > > Address: 2a05:d014:edb:5702::6 > > > > > Name: nginx.org > > > > > Address: 2a05:d014:edb:5704::6 > > > > > > > > > > Сущ:1 http://security.debian.org/debian-security buster/updates > > > InRelease > > > > > Сущ:2 http://deb.debian.org/debian buster InRelease > > > > > Сущ:3 http://deb.debian.org/debian buster-updates InRelease > > > > > Сущ:4 https://packages.sury.org/php buster InRelease > > > > > Ошб:5 http://nginx.org/packages/debian buster InRelease > > > > > Соединение разорвано [IP: 2a05:d014:edb:5704::6 80] > > > > > Чтение списков пакетов… Готово > > > > > W: Не удалось получить > > > > > http://nginx.org/packages/debian/dists/buster/InRelease > Соединение > > > > > разорвано [IP: 2a05:d014:edb:5704::6 80] > > > > > W: Некоторые индексные файлы скачать не удалось. Они были > > > проигнорированы, > > > > > или вместо них были использованы старые версии. > > > > > Чтение списков пакетов… Готово > > > > > > > > > > > > > > > То есть проблема не с резолвом. Смотрите tcpdump’ом что происходит > с > > > > > соединением. > > > > > > > > > > > > > Спасибо. > > > > Я подожду, когда вы разберетесь с настройками ipv6 в AWS. > > > > > > Модель поведения - публично облажаться, после чего нахамить и > > > слиться - понятная, но не конструктивная. > > > > Здравствуйте, Максим. > > Имеет место три проблемы, связанные с DNS, Ipv6 и вашим хостингом на AWS. > > Продемонстрированная проблема ровно одна: пакетный менеджер не > может получить > http://nginx.org/packages/debian/dists/buster/InRelease с > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > Почему не может - вопрос для дополнительного разбирательства. > Которое вы, почему-то, проводить не хотите даже на минимальном > уровне. > > Какие-либо проблемы с DNS - не продемонстрированы. Наоброт, > продемострировано, что если и есть какие-то теоретические > претензии к DNS, как то отсутствие IPv6 NS-серверов, то они не > относятся к наблюдаемой проблеме. > > > > Явно имеет место > > > какая-то проблема, и возможно она на нашей стороне. Поскольку в > > > настоящий момент вы единственный, у кого она проявляется - только > > > вы можете разобраться, что происходит. > > > > > > > Да, я вижу. На обоих трассах с he.net потери 3-10% на хопах внутри > Амазона. > > Кроме вас ну никто не может обратиться в ТП Амазона с указанными > потерями. > > И при условии, что вы внутри не намудрили с списками доступами и > firewall. > > Потери в современном интернете, к сожалению, довольно трудно > оценивать, ибо ICMP, даже если и не зафильтрован, обрабатывается > по остаточном принципу. Но так или иначе потери не объясняют > наблюдаемое вами поведение. > > > > Я бы начал с простого: проверил, получается ли запросить > > > упомянутый URL с проблемного IP-адреса руками, например: > > > > > > > Еще раз прочтите первое сообщение. > > НЕ работает первый запрос, второй и последующие - работают. > > И перестают работать где-то через час-два. > > Ну вот и попробуйте запросить руками через час-два. Лучше - с > tcpdump'ом, чтобы видеть, что при этом происходит на уровне сети. > И ещё можно Сергею скинуть IP-адрес, чтобы он посмотрел на > происходящее со стороны сервера. > > (И да, в первом сообщении написано про "домен не ресолвится первый > раз", что, как мы уже выяснили, не соответствует действительности. > Не надо, пожалуйста, продолжать хамить, это гарантировано не > приведёт ни к чему хорошему. Спасибо.) > Чтобы воспроизвести нересолвинг мне нужно подольше время, чтоб у "внешних" ресолверов протухли TTL записи. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From rajhoczki.tamas на gmail.com Thu Sep 24 03:37:22 2020 From: rajhoczki.tamas на gmail.com (AsderManas) Date: Thu, 24 Sep 2020 05:37:22 +0200 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <120B9DC4-4EA5-48F4-AFBF-3C2BBCAA2BB8@nginx.com> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <120B9DC4-4EA5-48F4-AFBF-3C2BBCAA2BB8@nginx.com> Message-ID: Stop send emil gay Sergey Budnevitch ezt írta (időpont: 2020. szept. 23., Sze 17:05): > > On 23 Sep 2020, at 16:59, Vladislav V. Prodan wrote: > > Ну, и заодно "помешайте" NS сервера для доменов nginx.com nginx.net > nginx.org. > > > Это бессмысленное занятие, если добавлены glue records, > для зон nginx.com & nginx.org glue records они существуют. > > > Например, > nginx.com > nginx.com name server ns.nginx.net. > nginx.com name server ns2.nginx.com. > nginx.com name server ns3.nginx.org. > > > ср, 23 сент. 2020 г. в 15:51, Vladislav V. Prodan : > >> >> >> ср, 23 сент. 2020 г. в 12:21, Sergey Budnevitch : >> >>> Добрый день >>> >>> Резолвер клиенты какой используют? >>> >> >> Здравствуйте. >> Клиент получает и Ipv6 и Ipv4 ресолвер. >> Первым, получается, используется ipv6 ресолвер. >> >> >> >>> >>> > On 23 Sep 2020, at 09:19, Evgeniy Berdnikov wrote: >>> > >>> > On Wed, Sep 23, 2020 at 04:10:12AM +0300, Vladislav V. Prodan wrote: >>> >> Если у клиента ipv6 адрес, то домен nginx.org гарантированно не >>> >> ресолвится первый раз, второй и последующие - ресолвится, потом >>> через два >>> >> часа по новой. >>> > >>> > Вы нашли себе такой резолвер, или же провайдера с таким резолвером, >>> чем >>> > nginx-то в этом провинился? >>> > >>> >> Как решение проблемы, добавить NS для nginx.org, имеющий ipv6 адрес >>> >> (подключение). >>> > >>> > Каким образом это может исправить ситуацию? Изложите механизм чуда. >>> > >>> >> А пока вынуждены таким костылем пользоваться: >>> >> >>> >> ping -4 -w 1 -c 1 -q nginx.org >> /dev/null >>> > >>> > Это скорее не костыль, а шаманство. >>> > -- >>> > Eugene Berdnikov >>> > _______________________________________________ >>> > 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 sb на nginx.com Thu Sep 24 11:03:37 2020 From: sb на nginx.com (Sergey Budnevitch) Date: Thu, 24 Sep 2020 14:03:37 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> Message-ID: <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> > > Продемонстрированная проблема ровно одна: пакетный менеджер не > может получить > http://nginx.org/packages/debian/dists/buster/InRelease с > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > > Первый запрос дождался таймаута (непонятно почему). > Второй запрос выполнился мгновенно. > https://pastebin.com/dWbffATH Смотрите: a) вы продемонстрировали проблему с первым подключением к nginx.org b) вы утверждаете что бывает проблема с резолвером, когда используется ipv6 c) вы используете Hurricane Electric tunnel brocker для ipv6 Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или на какие-то проблемы в he. nginx.org доступен по ipv6 c нескольких точек с которых я мог проверить, и судя по логам подключаются по ipv6 к nginx.org как обычно. From akapulko на gmail.com Thu Sep 24 11:29:21 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Thu, 24 Sep 2020 14:29:21 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> Message-ID: чт, 24 сент. 2020 г. в 14:03, Sergey Budnevitch : > > > > Продемонстрированная проблема ровно одна: пакетный менеджер не > > может получить > > http://nginx.org/packages/debian/dists/buster/InRelease с > > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > > > > > Первый запрос дождался таймаута (непонятно почему). > > Второй запрос выполнился мгновенно. > > https://pastebin.com/dWbffATH > > Смотрите: > a) вы продемонстрировали проблему с первым подключением к nginx.org > b) вы утверждаете что бывает проблема с резолвером, когда используется ipv6 > c) вы используете Hurricane Electric tunnel brocker для ipv6 > > Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или на > какие-то проблемы в he. > У вас пропущено ряд промежуточных выводов. А так понятно, вы подключили Ipv6 для галочки. Решил проблему с принудительной записью нужных данных в hosts. > > nginx.org доступен по ipv6 c нескольких точек с которых я мог проверить, > и судя по логам подключаются > по ipv6 к nginx.org как обычно. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugen на grosbein.net Thu Sep 24 12:00:22 2020 From: eugen на grosbein.net (Eugene Grosbein) Date: Thu, 24 Sep 2020 19:00:22 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> Message-ID: <0cc946b4-7d58-5ae3-49c3-932fc31d186f@grosbein.net> 24.09.2020 18:29, Vladislav V. Prodan пишет: > Решил проблему с принудительной записью нужных данных в hosts. Это не называется "решил". Это называется "замёл проблему под ковёр". From nginx-forum на forum.nginx.org Thu Sep 24 13:00:34 2020 From: nginx-forum на forum.nginx.org (Sergey Smirnov) Date: Thu, 24 Sep 2020 09:00:34 -0400 Subject: =?UTF-8?B?0J/Rj9GC0Lgg0YHQtdC60YPQvdC00L3QsNGPINC30LDQtNC10YDQttC60LAg0L0=?= =?UTF-8?B?0LAg0L7RgtC/0YDQsNCy0LrRgw==?= Message-ID: <2ab5296017aed7cd333cd92c92f8d7de.NginxMailingListRussian@forum.nginx.org> Добрый день! Использую NGINX в качестве Load balancer. Столкнулся с тем, что некоторые 200 приходят с задержкой в несколько секунд. Изучил логи, вижу следующее: 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 00007F344ED96750 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 00007F344ECDFA30 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 00007F344ED94200, unused: 8 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 00007F344ED4B380, unused: 400 2020/09/24 12:37:58 [debug] 18718#0: timer delta: 1 2020/09/24 12:37:58 [debug] 18718#0: worker cycle 2020/09/24 12:37:58 [debug] 18718#0: epoll timer: -1 //6 секунд задержки 2020/09/24 12:38:04 [debug] 18718#0: epoll: fd:9 ev:0001 d:00007F344DCE31F0 2020/09/24 12:38:04 [debug] 18718#0: accept on 0.0.0.0:443, ready: 0 2020/09/24 12:38:04 [debug] 18718#0: posix_memalign: 00007F344EC7F450:512 @16 2020/09/24 12:38:04 [debug] 18718#0: *2331 accept: 192.168.10.86:55013 fd:11 Прошу помощи, как это можно поправить? Что случилось? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289495,289495#msg-289495 From mdounin на mdounin.ru Thu Sep 24 13:26:59 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 24 Sep 2020 16:26:59 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> Message-ID: <20200924132659.GK1136@mdounin.ru> Hello! On Thu, Sep 24, 2020 at 02:03:37PM +0300, Sergey Budnevitch wrote: > > Продемонстрированная проблема ровно одна: пакетный менеджер не > > может получить > > http://nginx.org/packages/debian/dists/buster/InRelease с > > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > > > > > Первый запрос дождался таймаута (непонятно почему). > > Второй запрос выполнился мгновенно. > > https://pastebin.com/dWbffATH > > Смотрите: > a) вы продемонстрировали проблему с первым подключением к nginx.org > b) вы утверждаете что бывает проблема с резолвером, когда используется ipv6 > c) вы используете Hurricane Electric tunnel brocker для ipv6 > > Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или на какие-то проблемы в he. > > nginx.org доступен по ipv6 c нескольких точек с которых я мог проверить, и судя по логам подключаются > по ipv6 к nginx.org как обычно. Насколько я вижу, соединение нормально устанавливается, запрос отправляется, а ответ не приходит и ждёт таймаута. После чего на некоторое время всё исправляется. Если используется тоннель, то это выглядит и пахнет как классическая проблема с MTU, которая лечится за счёт PMTU black hole detection. Я со своей стороны давно разочаровался в идее работоспособности PMTU discovery в современном интернете, и жить с тоннелями без правки MSS никому не рекомендую. Но с нашей стороны явно имеет смысл проверить, что ICMP fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей ответственности ходят нормально и не зафильтрованы. С учётом того, что пинги не ходят - у меня вот лично в этом сомнения. -- Maxim Dounin http://mdounin.ru/ From bgx на protva.ru Thu Sep 24 13:30:42 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 24 Sep 2020 16:30:42 +0300 Subject: =?UTF-8?B?UmU6INCf0Y/RgtC4INGB0LXQutGD0L3QtNC90LDRjyDQt9Cw0LTQtdGA0LbQutCw?= =?UTF-8?B?INC90LAg0L7RgtC/0YDQsNCy0LrRgw==?= In-Reply-To: <2ab5296017aed7cd333cd92c92f8d7de.NginxMailingListRussian@forum.nginx.org> References: <2ab5296017aed7cd333cd92c92f8d7de.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200924133042.GI4644@sie.protva.ru> On Thu, Sep 24, 2020 at 09:00:34AM -0400, Sergey Smirnov wrote: > Добрый день! > > Использую NGINX в качестве Load balancer. > Столкнулся с тем, что некоторые 200 приходят с задержкой в несколько > секунд. > > Изучил логи, вижу следующее: > 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 00007F344ED96750 > 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 00007F344ECDFA30 > 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 00007F344ED94200, unused: > 8 > 2020/09/24 12:37:58 [debug] 18718#0: *1888 free: 00007F344ED4B380, unused: > 400 > 2020/09/24 12:37:58 [debug] 18718#0: timer delta: 1 > 2020/09/24 12:37:58 [debug] 18718#0: worker cycle > 2020/09/24 12:37:58 [debug] 18718#0: epoll timer: -1 > //6 секунд задержки > 2020/09/24 12:38:04 [debug] 18718#0: epoll: fd:9 ev:0001 d:00007F344DCE31F0 > 2020/09/24 12:38:04 [debug] 18718#0: accept on 0.0.0.0:443, ready: 0 > 2020/09/24 12:38:04 [debug] 18718#0: posix_memalign: 00007F344EC7F450:512 > @16 > 2020/09/24 12:38:04 [debug] 18718#0: *2331 accept: 192.168.10.86:55013 > fd:11 > > Прошу помощи, как это можно поправить? Что случилось? А где здесь видна задержка на отправку? По-моему, здесь 5-6 секунд между завершением предыдущего запроса и открытием коннекции (accept) для следующего, который может придти в любое время. Нужно посмотреть время поступления SYN-ов на балансировщик и сравнить с тем, что в логе. -- Eugene Berdnikov From akapulko на gmail.com Thu Sep 24 13:54:22 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Thu, 24 Sep 2020 16:54:22 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200924132659.GK1136@mdounin.ru> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> Message-ID: чт, 24 сент. 2020 г. в 16:27, Maxim Dounin : > Hello! > > On Thu, Sep 24, 2020 at 02:03:37PM +0300, Sergey Budnevitch wrote: > > > > Продемонстрированная проблема ровно одна: пакетный менеджер не > > > может получить > > > http://nginx.org/packages/debian/dists/buster/InRelease с > > > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > > > > > > > > Первый запрос дождался таймаута (непонятно почему). > > > Второй запрос выполнился мгновенно. > > > https://pastebin.com/dWbffATH > > > > Смотрите: > > a) вы продемонстрировали проблему с первым подключением к nginx.org > > b) вы утверждаете что бывает проблема с резолвером, когда используется > ipv6 > > c) вы используете Hurricane Electric tunnel brocker для ipv6 > > > > Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или > на какие-то проблемы в he. > > > > nginx.org доступен по ipv6 c нескольких точек с которых я мог > проверить, и судя по логам подключаются > > по ipv6 к nginx.org как обычно. > > Насколько я вижу, соединение нормально устанавливается, запрос > отправляется, а ответ не приходит и ждёт таймаута. После чего на > некоторое время всё исправляется. > > Если используется тоннель, то это выглядит и пахнет как > классическая проблема с MTU, которая лечится за счёт PMTU black > hole detection. > > Я со своей стороны давно разочаровался в идее работоспособности > PMTU discovery в современном интернете, и жить с тоннелями без > правки MSS никому не рекомендую. > > Но с нашей стороны явно имеет смысл проверить, что ICMP > fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей > ответственности ходят нормально и не зафильтрованы. С учётом > того, что пинги не ходят - у меня вот лично в этом сомнения. > > Благодарю. Похоже таки проблема в MTU/PMTU. Выставил в туннеле MTU 1480 при MTU 1500 физическом интерфейсе и заработало. Подозреваю опцию net.ipv4.tcp_mtu_probing = 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 eugen на grosbein.net Thu Sep 24 14:13:39 2020 From: eugen на grosbein.net (Eugene Grosbein) Date: Thu, 24 Sep 2020 21:13:39 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> Message-ID: 24.09.2020 20:54, Vladislav V. Prodan пишет: > > > чт, 24 сент. 2020 г. в 16:27, Maxim Dounin >: > > Hello! > > On Thu, Sep 24, 2020 at 02:03:37PM +0300, Sergey Budnevitch wrote: > > > > Продемонстрированная проблема ровно одна: пакетный менеджер не > > > может получить > > > http://nginx.org/packages/debian/dists/buster/InRelease с > > > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > > > > > > > > Первый запрос дождался таймаута (непонятно почему). > > > Второй запрос выполнился мгновенно. > > > https://pastebin.com/dWbffATH > > > > Смотрите: > > a) вы продемонстрировали проблему с первым подключением к nginx.org > > b) вы утверждаете что бывает проблема с резолвером, когда используется ipv6 > > c) вы используете Hurricane Electric tunnel brocker для ipv6 > > > > Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или на какие-то проблемы в he. > > > > nginx.org доступен по ipv6 c нескольких точек с которых я мог проверить, и судя по логам подключаются > > по ipv6 к nginx.org как обычно. > > Насколько я вижу, соединение нормально устанавливается, запрос > отправляется, а ответ не приходит и ждёт таймаута. После чего на > некоторое время всё исправляется. > > Если используется тоннель, то это выглядит и пахнет как > классическая проблема с MTU, которая лечится за счёт PMTU black > hole detection. > > Я со своей стороны давно разочаровался в идее работоспособности > PMTU discovery в современном интернете, и жить с тоннелями без > правки MSS никому не рекомендую. +100500 > Но с нашей стороны явно имеет смысл проверить, что ICMP > fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей > ответственности ходят нормально и не зафильтрованы. С учётом > того, что пинги не ходят - у меня вот лично в этом сомнения. > > > Благодарю. > Похоже таки проблема в MTU/PMTU. > Выставил в туннеле MTU 1480 при MTU 1500 физическом интерфейсе и заработало. > Подозреваю опцию > net.ipv4.tcp_mtu_probing = 0 > на маршрутизаторе. IPv4 PMTUD в современном (и уже лет 20 как, а то и больше) интернете сломан бесповоротно и время, которое тратится на восстановление его работы в публичном интернете, лучше потратить на что-нибудь другое. Это не касается контролируемых сетей и до определенной степени сетей с вменяемыми партнёрскими отношениями с их администрацией. Но для публичного интернета только занижение размера пакета любыми способами; в порядке уменшения предпочтительности: TCP MSS adjust, или занижение MTU на туннеле (иногда это лекарство хуже болезни), или принудительное снятие флага DF. From chipitsine на gmail.com Thu Sep 24 15:07:45 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 24 Sep 2020 20:07:45 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200924132659.GK1136@mdounin.ru> References: <20200923061936.GF4644@sie.protva.ru> <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com> <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> Message-ID: чт, 24 сент. 2020 г. в 18:27, Maxim Dounin : > Hello! > > On Thu, Sep 24, 2020 at 02:03:37PM +0300, Sergey Budnevitch wrote: > > > > Продемонстрированная проблема ровно одна: пакетный менеджер не > > > может получить > > > http://nginx.org/packages/debian/dists/buster/InRelease с > > > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > > > > > > > > Первый запрос дождался таймаута (непонятно почему). > > > Второй запрос выполнился мгновенно. > > > https://pastebin.com/dWbffATH > > > > Смотрите: > > a) вы продемонстрировали проблему с первым подключением к nginx.org > > b) вы утверждаете что бывает проблема с резолвером, когда используется > ipv6 > > c) вы используете Hurricane Electric tunnel brocker для ipv6 > > > > Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или > на какие-то проблемы в he. > > > > nginx.org доступен по ipv6 c нескольких точек с которых я мог > проверить, и судя по логам подключаются > > по ipv6 к nginx.org как обычно. > > Насколько я вижу, соединение нормально устанавливается, запрос > отправляется, а ответ не приходит и ждёт таймаута. После чего на > некоторое время всё исправляется. > > Если используется тоннель, то это выглядит и пахнет как > классическая проблема с MTU, которая лечится за счёт PMTU black > hole detection. > > Я со своей стороны давно разочаровался в идее работоспособности > PMTU discovery в современном интернете, и жить с тоннелями без > правки MSS никому не рекомендую. > > Но с нашей стороны явно имеет смысл проверить, что ICMP > fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей > ответственности ходят нормально и не зафильтрованы. С учётом > того, что пинги не ходят - у меня вот лично в этом сомнения. > есть распространенное ожидание, что якобы ICMP Frag needed может как-то помочь. на самом деле - скорее нет. допустим, у вас на участке сети мелкий MTU. в этом случае вы действительно увидите ICMP Frag required. если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric, whatever), то ICMP Frag required придет не вам, а туда, где терминируется туннель. благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию, которая идет снаружи туннеля ? что действительно работает, это манипуляции (в разумных пределах) с MSS, например --clamp-mss-to-pmtu очень интересно в этом плане жить в мире Windows (в нем принято ставить DF на https), и очень забавно наблюдать за MSS, например, от фейсбука (и прочих игроков такого масштаба) > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Thu Sep 24 16:06:06 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 24 Sep 2020 19:06:06 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> Message-ID: <20200924160606.GL4644@sie.protva.ru> On Thu, Sep 24, 2020 at 08:07:45PM +0500, Илья Шипицин wrote: > есть распространенное ожидание, что якобы ICMP Frag needed может как-то > помочь. > на самом деле - скорее нет. > допустим, у вас на участке сети мелкий MTU. в этом случае вы действительно > увидите ICMP Frag required. Ч.Т.Д. > если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric, > whatever), то ICMP Frag required придет не вам, а туда, где терминируется > туннель. > благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию, > которая идет снаружи туннеля ? PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не может. А обработка сигналов это задача тунеллятора. У него может быть несколько стратегий: 1. ставить df=0 и не париться, шлюзы сами всю работу сделают; 2. ставить df=1, ловить icmp[frag-need] и дробить-собирать пакеты самому; 3. ставить df=1, ловить icmp и ретранслировать его на нижний уровень. На самом деле лишь первые 2 стратегии можно нормально реализовать с классическим api сокетов. Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по умолчанию и ваша голова не болит, как он там пакеты дробит и куда свои служебные заголоки фасует. Другой вопрос, насколько кривы конкретные ipv6-to-ipv4 гейты и шлют ли они нужные клиенту icmp. > очень интересно в этом плане жить в мире Windows (в нем принято ставить DF > на https), Чем интересно? Браузерный трафик всегда идёт внутри туннеля. А если туннелятор не умеет PMTUD снаружи, то какое бы DF ни было внутри, результат будет одинаково печальным. -- Eugene Berdnikov From chipitsine на gmail.com Thu Sep 24 16:18:40 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 24 Sep 2020 21:18:40 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200924160606.GL4644@sie.protva.ru> References: <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> Message-ID: чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov : > On Thu, Sep 24, 2020 at 08:07:45PM +0500, Илья Шипицин wrote: > > есть распространенное ожидание, что якобы ICMP Frag needed может > как-то > > помочь. > > на самом деле - скорее нет. > > допустим, у вас на участке сети мелкий MTU. в этом случае вы > действительно > > увидите ICMP Frag required. > > Ч.Т.Д. > > > если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric, > > whatever), то ICMP Frag required придет не вам, а туда, где > терминируется > > туннель. > > благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию, > > которая идет снаружи туннеля ? > > > PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не может. > я примерно тыщу раз сталкивался с ситуацией "у нас не устанавливается SSL от браузера" --> "запускаем трейсроут" --> в транзите вижу узел с днс именем, содержащим pppoe. примерно в 100% случаях снижение MTU на клиенте или аналогичная манипуляция на сервере чинили при этом ни у меня, ни у клиента icmp не блокировано. просто сигнализация идет, вероятно, с pppoe узлами в транзите. > > А обработка сигналов это задача тунеллятора. У него может быть несколько > стратегий: > > 1. ставить df=0 и не париться, шлюзы сами всю работу сделают; > 2. ставить df=1, ловить icmp[frag-need] и дробить-собирать пакеты самому; > 3. ставить df=1, ловить icmp и ретранслировать его на нижний уровень. > > На самом деле лишь первые 2 стратегии можно нормально реализовать > с классическим api сокетов. > > Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по > умолчанию и ваша голова не болит, как он там пакеты дробит и куда > свои служебные заголоки фасует. > это ровно такая же ситуация, про которую я говорил. если вы являетесь той точкой, которая терминирует OpenVPN - вы видите icmp dest unreach и обрабатываете. если OpenVPN где-то в транзите, леший знает, как смаршрутизируется icmp dest unreach > > Другой вопрос, насколько кривы конкретные ipv6-to-ipv4 гейты и > шлют ли они нужные клиенту icmp. > > > очень интересно в этом плане жить в мире Windows (в нем принято > ставить DF > > на https), > > Чем интересно? Браузерный трафик всегда идёт внутри туннеля. > ну смотрите. фейсбук сталкивается примерно с несколькими миллиардами клиентов. в каких-то случаях настроенных вопреки здравому смыслу. и фейсбук выставляет MSS=1410. что-то в этом есть :) кажется, я понимаю, зачем. > А если туннелятор не умеет PMTUD снаружи, то какое бы DF ни было внутри, > результат будет одинаково печальным. > pmtud это какая-то вундервафля, которую умеют готовить в CloudFlare. я боюсь, что это технологии, открывающие портал и призывающие потусторонние силы. их работа за пределами понимания приматов > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Sep 24 16:28:37 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 24 Sep 2020 19:28:37 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> Message-ID: <20200924162837.GO1136@mdounin.ru> Hello! On Thu, Sep 24, 2020 at 08:07:45PM +0500, Илья Шипицин wrote: > чт, 24 сент. 2020 г. в 18:27, Maxim Dounin : > > > Hello! > > > > On Thu, Sep 24, 2020 at 02:03:37PM +0300, Sergey Budnevitch wrote: > > > > > > Продемонстрированная проблема ровно одна: пакетный менеджер не > > > > может получить > > > > http://nginx.org/packages/debian/dists/buster/InRelease с > > > > IPv6-адреса 2a05:d014:edb:5704::6, жалуясь на разрыв соединения. > > > > > > > > > > > > Первый запрос дождался таймаута (непонятно почему). > > > > Второй запрос выполнился мгновенно. > > > > https://pastebin.com/dWbffATH > > > > > > Смотрите: > > > a) вы продемонстрировали проблему с первым подключением к nginx.org > > > b) вы утверждаете что бывает проблема с резолвером, когда используется > > ipv6 > > > c) вы используете Hurricane Electric tunnel brocker для ipv6 > > > > > > Поскольку a) и b) не связаны, я бы грешил на конфигурацию туннеля и/или > > на какие-то проблемы в he. > > > > > > nginx.org доступен по ipv6 c нескольких точек с которых я мог > > проверить, и судя по логам подключаются > > > по ipv6 к nginx.org как обычно. > > > > Насколько я вижу, соединение нормально устанавливается, запрос > > отправляется, а ответ не приходит и ждёт таймаута. После чего на > > некоторое время всё исправляется. > > > > Если используется тоннель, то это выглядит и пахнет как > > классическая проблема с MTU, которая лечится за счёт PMTU black > > hole detection. > > > > Я со своей стороны давно разочаровался в идее работоспособности > > PMTU discovery в современном интернете, и жить с тоннелями без > > правки MSS никому не рекомендую. > > > > Но с нашей стороны явно имеет смысл проверить, что ICMP > > fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей > > ответственности ходят нормально и не зафильтрованы. С учётом > > того, что пинги не ходят - у меня вот лично в этом сомнения. > > > > > есть распространенное ожидание, что якобы ICMP Frag needed может как-то > помочь. > на самом деле - скорее нет. > > > допустим, у вас на участке сети мелкий MTU. в этом случае вы действительно > увидите ICMP Frag required. > если мы введем в уравнение туннель (pppoe, ipsec, hurricane electric, > whatever), то ICMP Frag required придет не вам, а туда, где терминируется > туннель. > благодаря каким механизмам вы (внутри туннеля) увидите сигнализацию, > которая идет снаружи туннеля ? Если ICMP fragmentation needed придёт для пакета, отправленного тоннелем - то он придёт, дествительно, туда, где терминируется тоннель, и задачей тоннеля будет как-то это обработать (например, уменьшить своё MTU и начать слать ICMP frag needed уже самому; впрочем, никогда не смотрел подробно, возможно типичные тоннели просто не ставят DF на своих пакетах, и кто неправильно выбрал MTU - тот просто попал на фрагментацию). Если же пакет не влезет в тоннель - то мы возвращаемся к той же ситуации, что и без тоннеля: где-то на участке сети мелкий MTU (и участок этот - тоннель, что, впрочем, не важно). И работающий ICMP тут проблему замечательно решает. Другой вопрос, что "работающий ICMP" - это сказочный персонаж. В современном интернете наверняка найдётся место, где его зафильтровали, и тоннель без правки MSS будет работать далеко не со всеми адресами. > что действительно работает, это манипуляции (в разумных пределах) с MSS, > например --clamp-mss-to-pmtu > очень интересно в этом плане жить в мире Windows (в нем принято ставить DF > на https), и очень забавно наблюдать > за MSS, например, от фейсбука (и прочих игроков такого масштаба) Ну вот пониманию, что ICMP frag needed не работает и этот интернет не починить - уже лет 20, если не больше. Присутствующий тут Руслан Ермилов свой tcpmssd сделал 20 лет назад. -- Maxim Dounin http://mdounin.ru/ From maxim на nginx.com Thu Sep 24 16:31:23 2020 From: maxim на nginx.com (Maxim Konovalov) Date: Thu, 24 Sep 2020 19:31:23 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200924162837.GO1136@mdounin.ru> References: <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924162837.GO1136@mdounin.ru> Message-ID: On 24.09.2020 19:28, Maxim Dounin wrote: [...] > Ну вот пониманию, что ICMP frag needed не работает и этот интернет > не починить - уже лет 20, если не больше. Присутствующий тут > Руслан Ермилов свой tcpmssd сделал 20 лет назад. Так это он интернет сломал? -- Maxim Konovalov From mdounin на mdounin.ru Thu Sep 24 16:59:43 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 24 Sep 2020 19:59:43 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924162837.GO1136@mdounin.ru> Message-ID: <20200924165943.GP1136@mdounin.ru> Hello! On Thu, Sep 24, 2020 at 07:31:23PM +0300, Maxim Konovalov wrote: > On 24.09.2020 19:28, Maxim Dounin wrote: > [...] > > Ну вот пониманию, что ICMP frag needed не работает и этот интернет > > не починить - уже лет 20, если не больше. Присутствующий тут > > Руслан Ермилов свой tcpmssd сделал 20 лет назад. > > Так это он интернет сломал? Нет же, он зафиксировал невозможность починки. Ну и хак с правкой MSS отправил в массы. С тех пор так и живём: интернет не работает, но где-то рядом незримо стоит Руслан и правит MSS, чтобы большие пакетики были не такие большие и хотя бы иногда пролезали. И всем кажется, что интернет работает. :)) -- Maxim Dounin http://mdounin.ru/ From bgx на protva.ru Thu Sep 24 17:01:53 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 24 Sep 2020 20:01:53 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> Message-ID: <20200924170153.GM4644@sie.protva.ru> On Thu, Sep 24, 2020 at 09:18:40PM +0500, Илья Шипицин wrote: > чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov : > >  PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не может. > > я примерно тыщу раз сталкивался с ситуацией > "у нас не устанавливается SSL от браузера" --> "запускаем трейсроут" --> в > транзите вижу узел с днс именем, содержащим pppoe. > примерно в 100% случаях снижение MTU на клиенте или аналогичная > манипуляция на сервере чинили > при этом ни у меня, ни у клиента icmp не блокировано. просто сигнализация > идет, вероятно, с pppoe узлами в транзите. Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите" наверняка нет (они могут быть лишь на 2м и предпоследнем хопе). "Снаружи" на pppoe icmp никогда не прилетают, хотя бы потому, что pppoe это не ip и вследствие этого он по интернету в принципе ходить не может. Здесь же наверняка причина в том, что терминирующий pppoе шлюз не посылает клиенту icmp на пакет с максимальным для изернета mtu, хотя приделать к нему pppoe-шные хедеры тоже не может: места нет. Таких кривых шлюзов немало, с этим я согласен. >  Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по >  умолчанию и ваша голова не болит, как он там пакеты дробит и куда >  свои служебные заголоки фасует. > > это ровно такая же ситуация, про которую я говорил. если вы являетесь той > точкой, которая терминирует OpenVPN - вы видите > icmp dest unreach и обрабатываете. если OpenVPN  где-то в транзите, леший > знает, как смаршрутизируется icmp dest unreach Никакой магии: icmp посылается на src_ip исходного пакета, и если пакет был от openvpn, то icmp придёт обратно к узлу-отправителю с openvpn. Тут всё детерминировано и однозначно. А тип icmp будет "frag-need". -- Eugene Berdnikov From chipitsine на gmail.com Thu Sep 24 17:50:25 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 24 Sep 2020 22:50:25 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200924170153.GM4644@sie.protva.ru> References: <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> Message-ID: чт, 24 сент. 2020 г. в 22:02, Evgeniy Berdnikov : > On Thu, Sep 24, 2020 at 09:18:40PM +0500, Илья Шипицин wrote: > > чт, 24 сент. 2020 г. в 21:06, Evgeniy Berdnikov : > > > > PPPoE ходит лишь по изернету, там "снаружи" ничего прилететь не > может. > > > > я примерно тыщу раз сталкивался с ситуацией > > "у нас не устанавливается SSL от браузера" --> "запускаем трейсроут" > --> в > > транзите вижу узел с днс именем, содержащим pppoe. > > примерно в 100% случаях снижение MTU на клиенте или аналогичная > > манипуляция на сервере чинили > > при этом ни у меня, ни у клиента icmp не блокировано. просто > сигнализация > > идет, вероятно, с pppoe узлами в транзите. > > Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите" > наверняка нет (они могут быть лишь на 2м и предпоследнем хопе). > "Снаружи" на pppoe icmp никогда не прилетают, хотя бы потому, что > pppoe это не ip и вследствие этого он по интернету в принципе ходить > не может. > вам может везти, если ваш сервер стоит рядом с сервером Яндекса. это будет гарантировать, что любой региональный провайдер будет запариваться, чтобы у его абонентов была связь до вас. поверьте, если вы не рядом с Яндексом, вы таких чудес в транзите насмотритесь ... > > Здесь же наверняка причина в том, что терминирующий pppoе шлюз не > посылает клиенту icmp на пакет с максимальным для изернета mtu, > хотя приделать к нему pppoe-шные хедеры тоже не может: места нет. > Таких кривых шлюзов немало, с этим я согласен. > > > Посмотрите на openvpn, например. Он даёт вам mtu=1500 в туннеле по > > умолчанию и ваша голова не болит, как он там пакеты дробит и куда > > свои служебные заголоки фасует. > > > > это ровно такая же ситуация, про которую я говорил. если вы являетесь > той > > точкой, которая терминирует OpenVPN - вы видите > > icmp dest unreach и обрабатываете. если OpenVPN где-то в транзите, > леший > > знает, как смаршрутизируется icmp dest unreach > > Никакой магии: icmp посылается на src_ip исходного пакета, и если пакет > был от openvpn, то icmp придёт обратно к узлу-отправителю с openvpn. > Тут всё детерминировано и однозначно. А тип icmp будет "frag-need". > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugen на grosbein.net Thu Sep 24 22:49:40 2020 From: eugen на grosbein.net (Eugene Grosbein) Date: Fri, 25 Sep 2020 05:49:40 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200924170153.GM4644@sie.protva.ru> References: <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> Message-ID: <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> 25.09.2020 0:01, Evgeniy Berdnikov пишет: > Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите" > наверняка нет (они могут быть лишь на 2м и предпоследнем хопе). О, сколько вам открытий чудных готовит просвященья дух! Даже операторы связи бывают такие, что у них MTU трассы во внешний мир меньше 1500, я встречал, что уж говорить о корпоративных и домашних сетях. А ещё есть особая, уличная магия в обработке входящего ICMP коробкой с NAT, за которой в одном или несколькими хопами (а не непосредственно на ней) стоит концентратор PPPoE или ещё какой туннель типа PPtP, а уже дальше клиенты. From eugen на grosbein.net Thu Sep 24 22:53:27 2020 From: eugen на grosbein.net (Eugene Grosbein) Date: Fri, 25 Sep 2020 05:53:27 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200924162837.GO1136@mdounin.ru> References: <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com> <20200923161358.GG1136@mdounin.ru> <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924162837.GO1136@mdounin.ru> Message-ID: <9805a916-a147-e31e-a630-069efa3d8940@grosbein.net> 24.09.2020 23:28, Maxim Dounin пишет: > Если ICMP fragmentation needed придёт для пакета, отправленного > тоннелем - то он придёт, дествительно, туда, где терминируется > тоннель, Или не придёт. Его кто угодно может не пропустить (NAT box) или даже изначально не сгенерить, дропнув пакет за превышение MTU молча, без отправки ICMP. > Ну вот пониманию, что ICMP frag needed не работает и этот интернет > не починить - уже лет 20, если не больше. Присутствующий тут > Руслан Ермилов свой tcpmssd сделал 20 лет назад. А нынче даже и tcpmssd не надо, функция adjust mss встроена в сетевые стеки или пакетные фильтры. From bgx на protva.ru Fri Sep 25 04:32:17 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 25 Sep 2020 07:32:17 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> References: <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> Message-ID: <20200925043217.GO4644@sie.protva.ru> On Fri, Sep 25, 2020 at 05:49:40AM +0700, Eugene Grosbein wrote: > 25.09.2020 0:01, Evgeniy Berdnikov пишет: > > > Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите" > > наверняка нет (они могут быть лишь на 2м и предпоследнем хопе). > > О, сколько вам открытий чудных готовит просвященья дух! > Даже операторы связи бывают такие, что у них MTU трассы во внешний мир меньше 1500, > я встречал, что уж говорить о корпоративных и домашних сетях. Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак. Поэтому бывает лишь на крайних хопах. > А ещё есть особая, уличная магия в обработке входящего ICMP коробкой с NAT, > за которой в одном или несколькими хопами (а не непосредственно на ней) > стоит концентратор PPPoE или ещё какой туннель типа PPtP, а уже дальше клиенты. Эта "магия" для tcp и udp ничего сложного не представляет, она уже лет 20 работает и в линуксах, и в бсд, и в цисках. Магию не осилили зиксели и прочие китайцы, да, но не потому что там что-то сверхсложное. У неасиливших вообще всё плохо, там даже icmp[source-quench] можно встретить. :) -- Eugene Berdnikov From eugen на grosbein.net Fri Sep 25 13:49:08 2020 From: eugen на grosbein.net (Eugene Grosbein) Date: Fri, 25 Sep 2020 20:49:08 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925043217.GO4644@sie.protva.ru> References: <20200923192422.GI1136@mdounin.ru> <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> Message-ID: 25.09.2020 11:32, Evgeniy Berdnikov wrote: >>> Вы перепрыгнули на другую ситуацию. Никаких там "pppoe в транзите" >>> наверняка нет (они могут быть лишь на 2м и предпоследнем хопе). >> О, сколько вам открытий чудных готовит просвященья дух! >> Даже операторы связи бывают такие, что у них MTU трассы во внешний мир меньше 1500, >> я встречал, что уж говорить о корпоративных и домашних сетях. > > Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак. Да. > Поэтому бывает лишь на крайних хопах. Нет. Это утверждение никак не связано с предыдущим и из него не вытекает, слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по PPPoE, а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ другой сети. >> А ещё есть особая, уличная магия в обработке входящего ICMP коробкой с NAT, >> за которой в одном или несколькими хопами (а не непосредственно на ней) >> стоит концентратор PPPoE или ещё какой туннель типа PPtP, а уже дальше клиенты. > > Эта "магия" для tcp и udp ничего сложного не представляет, она уже лет 20 > работает и в линуксах, и в бсд, и в цисках. Магию не осилили зиксели и > прочие китайцы, да, но не потому что там что-то сверхсложное. У неасиливших > вообще всё плохо, там даже icmp[source-quench] можно встретить. :) Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со входящим "снаружи" ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки) IP-пакет, изначально отправленного "изнутри"? Подсказка: существуют как минимум две разные политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И она же самая распространенная. From bgx на protva.ru Fri Sep 25 16:34:17 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 25 Sep 2020 19:34:17 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> Message-ID: <20200925163417.GQ4644@sie.protva.ru> On Fri, Sep 25, 2020 at 08:49:08PM +0700, Eugene Grosbein wrote: > 25.09.2020 11:32, Evgeniy Berdnikov wrote: > > Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак. > > Да. > > > Поэтому бывает лишь на крайних хопах. > > Нет. Это утверждение никак не связано с предыдущим и из него не вытекает, > слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по PPPoE, > а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ другой сети. Из "технически возможно" не следует "разумно и оправдано". Нужно иногда включать здравый смысл. PPPoE сделано для подключения для подключения множества клиентов к одному хабу, главная его цель -- авторизация клиента. Никто в здравом рассудке ТАК подключать аплинки на магистральном маршрутизаторе не будет. > Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со входящим "снаружи" > ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки) IP-пакет, > изначально отправленного "изнутри"? Подсказка: существуют как минимум две разные > политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И она же > самая распространенная. Есть только одна нормальная политика: доставить icmp по назначению. Все остальные политики ущербны, IMHO. Я лично никогда не встречал разумных "соображний безопасности", которые могли бы оправдать поломку одного из из базовых механизмов ip-стэка. Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать? -- Eugene Berdnikov From chipitsine на gmail.com Fri Sep 25 16:45:17 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 25 Sep 2020 21:45:17 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925163417.GQ4644@sie.protva.ru> References: <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> Message-ID: пт, 25 сент. 2020 г. в 21:34, Evgeniy Berdnikov : > On Fri, Sep 25, 2020 at 08:49:08PM +0700, Eugene Grosbein wrote: > > 25.09.2020 11:32, Evgeniy Berdnikov wrote: > > > Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. > Никак. > > > > Да. > > > > > Поэтому бывает лишь на крайних хопах. > > > > Нет. Это утверждение никак не связано с предыдущим и из него не вытекает, > > слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по > PPPoE, > > а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ > другой сети. > > Из "технически возможно" не следует "разумно и оправдано". Нужно иногда > включать здравый смысл. PPPoE сделано для подключения для подключения > множества клиентов к одному хабу, главная его цель -- авторизация клиента. > Никто в здравом рассудке ТАК подключать аплинки на магистральном > маршрутизаторе не будет. > > > Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со > входящим "снаружи" > > ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки) > IP-пакет, > > изначально отправленного "изнутри"? Подсказка: существуют как минимум > две разные > > политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И > она же > > самая распространенная. > > Есть только одна нормальная политика: доставить icmp по назначению. > Все остальные политики ущербны, IMHO. Я лично никогда не встречал > разумных "соображний безопасности", которые могли бы оправдать поломку > одного из из базовых механизмов ip-стэка. > > Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать? > по нашей оценке 1 пользователь на 10 тысяч пользователей сталкивается с поломанным MTU > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri Sep 25 16:49:06 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 25 Sep 2020 19:49:06 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> Message-ID: <20200925164906.GR4644@sie.protva.ru> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote: >  Насчёт "самая распостранённая" -- статистика есть? Как её вообще > собирать? > > по нашей оценке 1 пользователь на 10 тысяч пользователей сталкивается с > поломанным MTU Какое значение MSS анонсируют ваши серверы? -- Eugene Berdnikov From chipitsine на gmail.com Fri Sep 25 16:52:47 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 25 Sep 2020 21:52:47 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925164906.GR4644@sie.protva.ru> References: <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> Message-ID: пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov : > On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote: > > Насчёт "самая распостранённая" -- статистика есть? Как её вообще > > собирать? > > > > по нашей оценке 1 пользователь на 10 тысяч пользователей сталкивается > с > > поломанным MTU > > Какое значение MSS анонсируют ваши серверы? > 1416 > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Sep 25 16:54:36 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 25 Sep 2020 21:54:36 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> Message-ID: пт, 25 сент. 2020 г. в 21:52, Илья Шипицин : > > > пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov : > >> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote: >> > Насчёт "самая распостранённая" -- статистика есть? Как её вообще >> > собирать? >> > >> > по нашей оценке 1 пользователь на 10 тысяч пользователей >> сталкивается с >> > поломанным MTU >> >> Какое значение MSS анонсируют ваши серверы? >> > > 1416 > > мы итерационно подошли к этой цифре. я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали MTU на клиенте. и на очередном клиенты мы по одному байту крутили ну и получилось очень близко к фейсбуку (у них 1410) > -- >> Eugene Berdnikov >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri Sep 25 17:00:35 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 25 Sep 2020 20:00:35 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> Message-ID: <20200925170035.GS4644@sie.protva.ru> On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote: >  Какое значение MSS анонсируют ваши серверы? > > 1416 >   > > мы итерационно подошли к этой цифре. > я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали > MTU на клиенте. > и на очередном клиенты мы по одному байту крутили > ну и получилось очень близко к фейсбуку (у них 1410) Спасибо. Хотелось бы ещё уточнить: 1/10,000 -- это после подкручивания или до? -- Eugene Berdnikov From chipitsine на gmail.com Fri Sep 25 17:03:24 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 25 Sep 2020 22:03:24 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925170035.GS4644@sie.protva.ru> References: <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> <20200925170035.GS4644@sie.protva.ru> Message-ID: пт, 25 сент. 2020 г. в 22:00, Evgeniy Berdnikov : > On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote: > > Какое значение MSS анонсируют ваши серверы? > > > > 1416 > > > > > > мы итерационно подошли к этой цифре. > > я попросил техподдержку эскалировать на меня кейсы, когда они > подкручивали > > MTU на клиенте. > > и на очередном клиенты мы по одному байту крутили > > ну и получилось очень близко к фейсбуку (у них 1410) > > Спасибо. > > Хотелось бы ещё уточнить: 1/10,000 -- это после подкручивания или до? > количество обращений в поддержку, завершившихся подкручиванием MTU. до подкручивания. после подкручивания практически в ноль упало. было одно обращение, когда крутили MTU до 1300. мы решили больше не трогать MSS потому что это уменьшает объем полезной нагрузки per packet > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From akapulko на gmail.com Fri Sep 25 17:03:01 2020 From: akapulko на gmail.com (Vladislav V. Prodan) Date: Fri, 25 Sep 2020 20:03:01 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> Message-ID: пт, 25 сент. 2020 г. в 19:54, Илья Шипицин : > > > пт, 25 сент. 2020 г. в 21:52, Илья Шипицин : > >> >> >> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov : >> >>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote: >>> > Насчёт "самая распостранённая" -- статистика есть? Как её вообще >>> > собирать? >>> > >>> > по нашей оценке 1 пользователь на 10 тысяч пользователей >>> сталкивается с >>> > поломанным MTU >>> >>> Какое значение MSS анонсируют ваши серверы? >>> >> >> 1416 >> >> > > мы итерационно подошли к этой цифре. > я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали > MTU на клиенте. > > и на очередном клиенты мы по одному байту крутили > ну и получилось очень близко к фейсбуку (у них 1410) > > Есть ли еще статистика по использованию MSS у крупных сервисов? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Fri Sep 25 17:25:40 2020 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 25 Sep 2020 20:25:40 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> Message-ID: <20200925172539.GH2015@zxy.spb.ru> On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote: > >> > Насчёт "самая распостранённая" -- статистика есть? Как её вообще > >> > собирать? > >> > > >> > по нашей оценке 1 пользователь на 10 тысяч пользователей > >> сталкивается с > >> > поломанным MTU > >> > >> Какое значение MSS анонсируют ваши серверы? > >> > > > > 1416 > > > > > > мы итерационно подошли к этой цифре. > я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали > MTU на клиенте. > > и на очередном клиенты мы по одному байту крутили а чего по байту-то? From chipitsine на gmail.com Fri Sep 25 17:30:01 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 25 Sep 2020 22:30:01 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925172539.GH2015@zxy.spb.ru> References: <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> <20200925172539.GH2015@zxy.spb.ru> Message-ID: пт, 25 сент. 2020 г. в 22:25, Slawa Olhovchenkov : > On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote: > > > >> > Насчёт "самая распостранённая" -- статистика есть? Как её > вообще > > >> > собирать? > > >> > > > >> > по нашей оценке 1 пользователь на 10 тысяч пользователей > > >> сталкивается с > > >> > поломанным MTU > > >> > > >> Какое значение MSS анонсируют ваши серверы? > > >> > > > > > > 1416 > > > > > > > > > > мы итерационно подошли к этой цифре. > > я попросил техподдержку эскалировать на меня кейсы, когда они > подкручивали > > MTU на клиенте. > > > > и на очередном клиенты мы по одному байту крутили > > а чего по байту-то? > делением пополам, конечно. я к сожалению не документировал шаги. самому было бы интересно посмотреть. из того, что вспоминается, было две итерации, когда подгоняли под клиента. за первую мы снизились до 1456 кажется. и потом был еще один клиент, мы упали до 1416 теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugen на grosbein.net Fri Sep 25 17:30:45 2020 From: eugen на grosbein.net (Eugene Grosbein) Date: Sat, 26 Sep 2020 00:30:45 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925163417.GQ4644@sie.protva.ru> References: <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> Message-ID: 25.09.2020 23:34, Evgeniy Berdnikov пишет: > On Fri, Sep 25, 2020 at 08:49:08PM +0700, Eugene Grosbein wrote: >> 25.09.2020 11:32, Evgeniy Berdnikov wrote: >>> Ещё раз: PPPoE это не ip, поэтому по интернету он ходить не может. Никак. >> >> Да. >> >>> Поэтому бывает лишь на крайних хопах. >> >> Нет. Это утверждение никак не связано с предыдущим и из него не вытекает, >> слово "поэтому" неоправдано. Можно подключить маршрутизатор к аплинку по PPPoE, >> а за этим маршрутизатором ещё хоть пять хопов корпоративной или ЛЮБОЙ другой сети. > > Из "технически возможно" не следует "разумно и оправдано". Нужно иногда > включать здравый смысл. PPPoE сделано для подключения для подключения > множества клиентов к одному хабу, главная его цель -- авторизация клиента. Это никак не противоречит тому, что у "клиента" может быть сегментированная сеть, и даже распределенная сегментированная сеть. > Никто в здравом рассудке ТАК подключать аплинки на магистральном > маршрутизаторе не будет. PPPoE в данном случае лишь один вариант, когда MTU трассы оказывается меньше чем 1500, и да, я не оправдываю оператора связи, который даунлинкам-операторам даёт такую трассу, но И ТАКОЕ тоже бывало. >> Натурально, вы не понимаете. Вопрос: что должен делать NAT-box со входящим "снаружи" >> ICMP need-fragment, присланным в ответ на транзитный (для nat-коробки) IP-пакет, >> изначально отправленного "изнутри"? Подсказка: существуют как минимум две разные >> политики на эту тему. Одна из них ради "безопасности" ломает PMTUD. И она же >> самая распространенная. > > Есть только одна нормальная политика: доставить icmp по назначению. В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP. > Все остальные политики ущербны, IMHO. Я лично никогда не встречал > разумных "соображний безопасности", которые могли бы оправдать поломку > одного из из базовых механизмов ip-стэка. А вот некоторые считают, что пропускать ICMP внутрь NAT вообще не следует :-) > Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать? По количеству инсталляций стека. From slw на zxy.spb.ru Fri Sep 25 17:37:22 2020 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 25 Sep 2020 20:37:22 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> <20200925172539.GH2015@zxy.spb.ru> Message-ID: <20200925173722.GI2015@zxy.spb.ru> On Fri, Sep 25, 2020 at 10:30:01PM +0500, Илья Шипицин wrote: > > > мы итерационно подошли к этой цифре. > > > я попросил техподдержку эскалировать на меня кейсы, когда они > > подкручивали > > > MTU на клиенте. > > > > > > и на очередном клиенты мы по одному байту крутили > > > > а чего по байту-то? > > > > делением пополам, конечно. > > я к сожалению не документировал шаги. самому было бы интересно посмотреть. > из того, что вспоминается, было две итерации, когда подгоняли под клиента. > > за первую мы снизились до 1456 кажется. и потом был еще один клиент, мы > упали до 1416 > > теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались побитно тогда уж! как он не кратный четерем может быть-то? From bgx на protva.ru Fri Sep 25 17:45:15 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 25 Sep 2020 20:45:15 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> Message-ID: <20200925174515.GU4644@sie.protva.ru> On Sat, Sep 26, 2020 at 12:30:45AM +0700, Eugene Grosbein wrote: > > Есть только одна нормальная политика: доставить icmp по назначению. > > В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP. Не понял. Поясните на примере. Заведомо невалидные icmp не предлагать. > > Все остальные политики ущербны, IMHO. Я лично никогда не встречал > > разумных "соображний безопасности", которые могли бы оправдать поломку > > одного из из базовых механизмов ip-стэка. > > А вот некоторые считают, что пропускать ICMP внутрь NAT вообще не следует :-) Есть внятные аргументы кроме "хихи-хаха" и смайликов? > > Насчёт "самая распостранённая" -- статистика есть? Как её вообще собирать? > > По количеству инсталляций стека. Ну и как посчитать количество инсталяций? И где эта статистика по сломанным инсталлированным стэкам? Мне кажется это пустой трёп, но покажите. -- Eugene Berdnikov From bgx на protva.ru Fri Sep 25 17:51:53 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 25 Sep 2020 20:51:53 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925173722.GI2015@zxy.spb.ru> References: <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> <20200925172539.GH2015@zxy.spb.ru> <20200925173722.GI2015@zxy.spb.ru> Message-ID: <20200925175153.GV4644@sie.protva.ru> On Fri, Sep 25, 2020 at 08:37:22PM +0300, Slawa Olhovchenkov wrote: > > теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались > > побитно тогда уж! > как он не кратный четерем может быть-то? Анонсированный MSS -- запросто. :)) Вписал нечётный в правило, и вуаля. Iptables пропустит и ядро линикса поставит. Насчёт фрюх и цисок не знаю. -- Eugene Berdnikov From eugen на grosbein.net Fri Sep 25 21:07:10 2020 From: eugen на grosbein.net (Eugene Grosbein) Date: Sat, 26 Sep 2020 04:07:10 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925174515.GU4644@sie.protva.ru> References: <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925174515.GU4644@sie.protva.ru> Message-ID: 26.09.2020 0:45, Evgeniy Berdnikov пишет: > On Sat, Sep 26, 2020 at 12:30:45AM +0700, Eugene Grosbein wrote: >>> Есть только одна нормальная политика: доставить icmp по назначению. >> В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP. > > Не понял. Поясните на примере. Заведомо невалидные icmp не предлагать. Да почему же невалидные. NAT ведь разный бывает, например может быть "клиент" с выделенной ему сеткой 100.64.0.0/24 и выделенным же одним внешним IP, весь исходящий трафик из сетки транслируется в такой "персональный" внешний IP, весь входящий трафик на этот IP, не являющийся ответным, транслируется 1:1 на 100.64.0.1, что позволяет клиенту "публиковать сервисы". Пропускать ли снаружи внутрь ICMP echo-request, которые могут быть с заниженным TTL (traceroute probes) и хотя бы частично покажут внутренную часть сети за NAT между самим NAT и 100.64.0.1 ? Там может быть более одного хопа. Кто-то не пропускает. А пропускать ли такие же ICMP need-fragment? Кто-то не пропускает и ломает PMTUD. From slw на zxy.spb.ru Fri Sep 25 21:53:19 2020 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sat, 26 Sep 2020 00:53:19 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925175153.GV4644@sie.protva.ru> References: <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> <20200925172539.GH2015@zxy.spb.ru> <20200925173722.GI2015@zxy.spb.ru> <20200925175153.GV4644@sie.protva.ru> Message-ID: <20200925215318.GJ2015@zxy.spb.ru> On Fri, Sep 25, 2020 at 08:51:53PM +0300, Evgeniy Berdnikov wrote: > On Fri, Sep 25, 2020 at 08:37:22PM +0300, Slawa Olhovchenkov wrote: > > > теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались > > > > побитно тогда уж! > > как он не кратный четерем может быть-то? > > Анонсированный MSS -- запросто. :)) Вписал нечётный в правило, и вуаля. > Iptables пропустит и ядро линикса поставит. Насчёт фрюх и цисок не знаю. ну и зачем дураков копировать? From alicesafr на mail.ru Fri Sep 25 23:33:52 2020 From: alicesafr на mail.ru (alicesafr на mail.ru) Date: Sat, 26 Sep 2020 02:33:52 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925163417.GQ4644@sie.protva.ru> References: <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> Message-ID: An HTML attachment was scrubbed... URL: From alicesafr на mail.ru Fri Sep 25 23:33:52 2020 From: alicesafr на mail.ru (alicesafr на mail.ru) Date: Sat, 26 Sep 2020 02:33:52 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925164906.GR4644@sie.protva.ru> References: <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSC_1413.jpg Type: image/jpeg Size: 180516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSC_1417.jpg Type: image/jpeg Size: 140278 bytes Desc: not available URL: From alicesafr на mail.ru Fri Sep 25 23:33:57 2020 From: alicesafr на mail.ru (alicesafr на mail.ru) Date: Sat, 26 Sep 2020 02:33:57 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925170035.GS4644@sie.protva.ru> References: <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> <20200925170035.GS4644@sie.protva.ru> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSC_1411.jpg Type: image/jpeg Size: 142359 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSC_1410.jpg Type: image/jpeg Size: 142283 bytes Desc: not available URL: From alicesafr на mail.ru Fri Sep 25 23:33:58 2020 From: alicesafr на mail.ru (alicesafr на mail.ru) Date: Sat, 26 Sep 2020 02:33:58 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200925172539.GH2015@zxy.spb.ru> References: <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925164906.GR4644@sie.protva.ru> <20200925172539.GH2015@zxy.spb.ru> Message-ID: An HTML attachment was scrubbed... URL: From alicesafr на mail.ru Fri Sep 25 23:33:58 2020 From: alicesafr на mail.ru (alicesafr на mail.ru) Date: Sat, 26 Sep 2020 02:33:58 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com> <20200924132659.GK1136@mdounin.ru> <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> Message-ID: An HTML attachment was scrubbed... URL: From bgx на protva.ru Sat Sep 26 11:31:41 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sat, 26 Sep 2020 14:31:41 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: References: <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925174515.GU4644@sie.protva.ru> Message-ID: <20200926113141.GZ4644@sie.protva.ru> On Sat, Sep 26, 2020 at 04:07:10AM +0700, Eugene Grosbein wrote: > 26.09.2020 0:45, Evgeniy Berdnikov пишет: > > > On Sat, Sep 26, 2020 at 12:30:45AM +0700, Eugene Grosbein wrote: > >>> Есть только одна нормальная политика: доставить icmp по назначению. > >> В случае NAT "назначением" можно посчитать и внешний IP в самом ICMP. > > > > Не понял. Поясните на примере. Заведомо невалидные icmp не предлагать. > > Да почему же невалидные. NAT ведь разный бывает, например может быть > "клиент" с выделенной ему сеткой 100.64.0.0/24 и выделенным же одним внешним IP, > весь исходящий трафик из сетки транслируется в такой "персональный" внешний IP, > весь входящий трафик на этот IP, не являющийся ответным, транслируется 1:1 > на 100.64.0.1, что позволяет клиенту "публиковать сервисы". Я просил конкретный пример. Что здесь в icmp, какой ip "внешний"? > Пропускать ли снаружи внутрь ICMP echo-request, которые могут быть с заниженным TTL > (traceroute probes) и хотя бы частично покажут внутренную часть сети за NAT > между самим NAT и 100.64.0.1 ? Там может быть более одного хопа. > Кто-то не пропускает. А пропускать ли такие же ICMP need-fragment? > Кто-то не пропускает и ломает PMTUD. ICMP[frag-need] валиден лишь если он относится к открытому соединению, точнее, к существующей записи в контраке. Иначе icmp[frag-need] невалиден. В принципе пропускать же icmp[frag-need] можно любые, потому что ядро пользовательской системы точно так же должно проверять привязку icmp к установленному соединению, и по rfc обязано игнорировать невалидные. Но лучше мусор за nat не пропускать. Политика фильтрации может применяться только к тем типам icmp, которые к существованию записи в контраке не привязаны, скажем, для echo-request. Но не для echo-reply! Если кто-то делает иначе, в том числе тупо запрещает icmp внутрь, то он просто не понимает, что ломает базовые алгоримы ip. -- Eugene Berdnikov From eugen на grosbein.net Sat Sep 26 13:40:10 2020 From: eugen на grosbein.net (Eugene Grosbein) Date: Sat, 26 Sep 2020 20:40:10 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <20200926113141.GZ4644@sie.protva.ru> References: <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925174515.GU4644@sie.protva.ru> <20200926113141.GZ4644@sie.protva.ru> Message-ID: <19fc7d7f-2e31-0e0d-2772-1436207801d5@grosbein.net> 26.09.2020 18:31, Evgeniy Berdnikov пишет: > Я просил конкретный пример. Что здесь в icmp, какой ip "внешний"? Внешний = публично маршрутизируемый. IP-адрес назначения в любом ответном входящем ICMP-пакете, пришедшем на NAT-box снаружи, будет внешним. From alicesafr на mail.ru Sat Sep 26 13:42:12 2020 From: alicesafr на mail.ru (alicesafr на mail.ru) Date: Sat, 26 Sep 2020 16:42:12 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?= =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?= In-Reply-To: <19fc7d7f-2e31-0e0d-2772-1436207801d5@grosbein.net> References: <20200924160606.GL4644@sie.protva.ru> <20200924170153.GM4644@sie.protva.ru> <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net> <20200925043217.GO4644@sie.protva.ru> <20200925163417.GQ4644@sie.protva.ru> <20200925174515.GU4644@sie.protva.ru> <20200926113141.GZ4644@sie.protva.ru> <19fc7d7f-2e31-0e0d-2772-1436207801d5@grosbein.net> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSC_1413.jpg Type: image/jpeg Size: 180516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DSC_1417.jpg Type: image/jpeg Size: 140278 bytes Desc: not available URL: From cyril.zlachevsky на gmail.com Mon Sep 28 17:08:03 2020 From: cyril.zlachevsky на gmail.com (Cyril Zlachevsky) Date: Mon, 28 Sep 2020 20:08:03 +0300 Subject: =?UTF-8?B?0YHRgtCw0YLQuNGH0LXRgdC60LjQuSDQutC+0L3RgtC10L3RgiDQuCBOb2RlSlMg?= =?UTF-8?B?RXhwcmVzcw==?= Message-ID: Есть приложение на NodeJS, которое прекрасно работает в developer-режиме. В качестве http-сервера используется ExpressJS. В production-режиме появляется проблема - http GET запросы возвращают 404-ю ошибку для всех новых файлов, загруженных после старта приложения в каталог public. Пример: если до старта файл public/static/old.jpg существовал, GET запрос вернет его с кодом 200. Если мы загрузили через nodejs-приложение файл public/static/new.jpg GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, GET на public/static/new.jpg будет возвращать 200. Гугление проблемы привело к пониманию, что это не ошибка, а особенность Express-сервера и для production рекомендуется использовать связку nginx+express. Как мне настроить работу этой связки, я не вполне представляю, поэтому прошу помощи здесь. From chipitsine на gmail.com Mon Sep 28 17:18:18 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 28 Sep 2020 22:18:18 +0500 Subject: =?UTF-8?B?UmU6INGB0YLQsNGC0LjRh9C10YHQutC40Lkg0LrQvtC90YLQtdC90YIg0LggTm9k?= =?UTF-8?B?ZUpTIEV4cHJlc3M=?= In-Reply-To: References: Message-ID: Лучшим источником информации было бы описание со стороны Express. Вы у них эту рекомендацию нашли? Поделитесь ссылкой? On Mon, Sep 28, 2020, 10:08 PM Cyril Zlachevsky wrote: > Есть приложение на NodeJS, которое прекрасно работает в > developer-режиме. В качестве http-сервера используется ExpressJS. > В production-режиме появляется проблема - http GET запросы возвращают > 404-ю ошибку для всех новых файлов, загруженных после старта приложения > в каталог public. > > Пример: если до старта файл public/static/old.jpg существовал, GET > запрос вернет его с кодом 200. > Если мы загрузили через nodejs-приложение файл public/static/new.jpg > GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, > GET на public/static/new.jpg будет возвращать 200. > > Гугление проблемы привело к пониманию, что это не ошибка, а особенность > Express-сервера и для production рекомендуется использовать связку > nginx+express. Как мне настроить работу этой связки, я не вполне > представляю, поэтому прошу помощи здесь. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From cyril.zlachevsky на gmail.com Mon Sep 28 17:45:29 2020 From: cyril.zlachevsky на gmail.com (Cyril Zlachevsky) Date: Mon, 28 Sep 2020 20:45:29 +0300 Subject: =?UTF-8?B?UmU6INGB0YLQsNGC0LjRh9C10YHQutC40Lkg0LrQvtC90YLQtdC90YIg0LggTm9k?= =?UTF-8?B?ZUpTIEV4cHJlc3M=?= In-Reply-To: References: Message-ID: Ответ разработчиков NextJS (у меня SSR-приложение на React, поэтому сначала спросил у них) на данную проблему - для ее решения используйте стороннее решение https://github.com/vercel/next.js/discussions/16417 Отсылки к nginx для решения данной проблемы: https://stackoverflow.com/questions/58115695/how-to-detect-404-errors-from-express-static https://stackoverflow.com/questions/32419492/proxying-nginx-express-404-on-static-files пн, 28 сент. 2020 г. в 20:18, Илья Шипицин : > > Лучшим источником информации было бы описание со стороны Express. Вы у них эту рекомендацию нашли? Поделитесь ссылкой? > > On Mon, Sep 28, 2020, 10:08 PM Cyril Zlachevsky wrote: >> >> Есть приложение на NodeJS, которое прекрасно работает в >> developer-режиме. В качестве http-сервера используется ExpressJS. >> В production-режиме появляется проблема - http GET запросы возвращают >> 404-ю ошибку для всех новых файлов, загруженных после старта приложения >> в каталог public. >> >> Пример: если до старта файл public/static/old.jpg существовал, GET >> запрос вернет его с кодом 200. >> Если мы загрузили через nodejs-приложение файл public/static/new.jpg >> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, >> GET на public/static/new.jpg будет возвращать 200. >> >> Гугление проблемы привело к пониманию, что это не ошибка, а особенность >> Express-сервера и для production рекомендуется использовать связку >> nginx+express. Как мне настроить работу этой связки, я не вполне >> представляю, поэтому прошу помощи здесь. From mif на me.com Mon Sep 28 18:06:49 2020 From: mif на me.com (Alexey Galygin) Date: Mon, 28 Sep 2020 21:06:49 +0300 Subject: =?UTF-8?B?UmU6INGB0YLQsNGC0LjRh9C10YHQutC40Lkg0LrQvtC90YLQtdC90YIg0LggTm9k?= =?UTF-8?B?ZUpTIEV4cHJlc3M=?= In-Reply-To: References: Message-ID: Express действительно любит кэшировать состояния (правда это больше касается шаблонов — он их компилирует и больше не проверяет, но слышать про файлы такое удивительно, возможно используемое раздающее middleware придерживается другой политики) обычная практика в таких случаях: выделение «датахранилки» — папки, которую через настроенный location раздаёт nginx напрямую с кэшами (заголовки и настройки добавить по вкусу) https://nginx.org/ru/docs/beginners_guide.html#static вся статика складывается туда, и нет смысла грузить backend непрофильными запросами вообще — nginx отстреляется лучше всего если каким-то файлам требуется авторизация, можно сделать дополнительный internal location и с backend после проверки кидать туда (через x-accel-redirect — https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) и nginx опять таки отдаст статику напрямую и быстрее любой backend логики более того, можно сделать, чтобы правильна работала отдача частичного контента (bytes range) и эффективная раздача с диска всё что не попадает под пути хранилки проксировать на Express > On 28 Sep 2020, at 20:08, Cyril Zlachevsky wrote: > > Есть приложение на NodeJS, которое прекрасно работает в > developer-режиме. В качестве http-сервера используется ExpressJS. > В production-режиме появляется проблема - http GET запросы возвращают > 404-ю ошибку для всех новых файлов, загруженных после старта приложения > в каталог public. > > Пример: если до старта файл public/static/old.jpg существовал, GET > запрос вернет его с кодом 200. > Если мы загрузили через nodejs-приложение файл public/static/new.jpg > GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, > GET на public/static/new.jpg будет возвращать 200. > > Гугление проблемы привело к пониманию, что это не ошибка, а особенность > Express-сервера и для production рекомендуется использовать связку > nginx+express. Как мне настроить работу этой связки, я не вполне > представляю, поэтому прошу помощи здесь. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From cyril.zlachevsky на gmail.com Tue Sep 29 05:14:32 2020 From: cyril.zlachevsky на gmail.com (Cyril Zlachevsky) Date: Tue, 29 Sep 2020 08:14:32 +0300 Subject: =?UTF-8?B?UmU6INGB0YLQsNGC0LjRh9C10YHQutC40Lkg0LrQvtC90YLQtdC90YIg0LggTm9k?= =?UTF-8?B?ZUpTIEV4cHJlc3M=?= In-Reply-To: References: Message-ID: В middleware NextJS каталог public прописан как protected: protected generatePublicRoutes(): Route[] { Авторизация требуется только на загрузку файлов в данный каталог через запросы PUT и POST и реализована в Express. И насколько я представляю задачу, нужно, чтобы nginx знал об Express и динамический контент отдавал ему (на порт 3000 например), а работу со статикой брал на себя. Как этот функционал реализовать? пн, 28 сент. 2020 г. в 21:07, Alexey Galygin : > > Express действительно любит кэшировать состояния (правда это больше касается шаблонов — он их компилирует и больше не проверяет, но слышать про файлы такое удивительно, возможно используемое раздающее middleware придерживается другой политики) > > обычная практика в таких случаях: > > выделение «датахранилки» — папки, которую через настроенный location раздаёт nginx напрямую > с кэшами (заголовки и настройки добавить по вкусу) > https://nginx.org/ru/docs/beginners_guide.html#static > > вся статика складывается туда, и нет смысла грузить backend непрофильными запросами вообще — nginx отстреляется лучше всего > > если каким-то файлам требуется авторизация, можно сделать дополнительный internal location и с backend после проверки кидать туда (через x-accel-redirect — https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) > и nginx опять таки отдаст статику напрямую и быстрее любой backend логики > > более того, можно сделать, чтобы правильна работала отдача частичного контента (bytes range) и эффективная раздача с диска > > всё что не попадает под пути хранилки проксировать на Express > > On 28 Sep 2020, at 20:08, Cyril Zlachevsky wrote: > > Есть приложение на NodeJS, которое прекрасно работает в > developer-режиме. В качестве http-сервера используется ExpressJS. > В production-режиме появляется проблема - http GET запросы возвращают > 404-ю ошибку для всех новых файлов, загруженных после старта приложения > в каталог public. > > Пример: если до старта файл public/static/old.jpg существовал, GET > запрос вернет его с кодом 200. > Если мы загрузили через nodejs-приложение файл public/static/new.jpg > GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, > GET на public/static/new.jpg будет возвращать 200. > > Гугление проблемы привело к пониманию, что это не ошибка, а особенность > Express-сервера и для production рекомендуется использовать связку > nginx+express. Как мне настроить работу этой связки, я не вполне > представляю, поэтому прошу помощи здесь. From chipitsine на gmail.com Tue Sep 29 05:42:03 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 29 Sep 2020 10:42:03 +0500 Subject: =?UTF-8?B?UmU6INGB0YLQsNGC0LjRh9C10YHQutC40Lkg0LrQvtC90YLQtdC90YIg0LggTm9k?= =?UTF-8?B?ZUpTIEV4cHJlc3M=?= In-Reply-To: References: Message-ID: вт, 29 сент. 2020 г. в 10:14, Cyril Zlachevsky : > В middleware NextJS каталог public прописан как protected: > protected generatePublicRoutes(): Route[] { > > Авторизация требуется только на загрузку файлов в данный каталог через > запросы PUT и POST и реализована в Express. > И насколько я представляю задачу, нужно, чтобы nginx знал об Express и > динамический контент отдавал ему (на порт 3000 например), а работу со > статикой брал на себя. > Как этот функционал реализовать? > при помощи try_files > > пн, 28 сент. 2020 г. в 21:07, Alexey Galygin : > > > > Express действительно любит кэшировать состояния (правда это больше > касается шаблонов — он их компилирует и больше не проверяет, но слышать про > файлы такое удивительно, возможно используемое раздающее middleware > придерживается другой политики) > > > > > обычная практика в таких случаях: > > > > выделение «датахранилки» — папки, которую через настроенный location > раздаёт nginx напрямую > > с кэшами (заголовки и настройки добавить по вкусу) > > https://nginx.org/ru/docs/beginners_guide.html#static > > > > вся статика складывается туда, и нет смысла грузить backend > непрофильными запросами вообще — nginx отстреляется лучше всего > > > > если каким-то файлам требуется авторизация, можно сделать дополнительный > internal location и с backend после проверки кидать туда (через > x-accel-redirect — > https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) > > и nginx опять таки отдаст статику напрямую и быстрее любой backend логики > > > > более того, можно сделать, чтобы правильна работала отдача частичного > контента (bytes range) и эффективная раздача с диска > > > > всё что не попадает под пути хранилки проксировать на Express > > > > On 28 Sep 2020, at 20:08, Cyril Zlachevsky > wrote: > > > > Есть приложение на NodeJS, которое прекрасно работает в > > developer-режиме. В качестве http-сервера используется ExpressJS. > > В production-режиме появляется проблема - http GET запросы возвращают > > 404-ю ошибку для всех новых файлов, загруженных после старта приложения > > в каталог public. > > > > Пример: если до старта файл public/static/old.jpg существовал, GET > > запрос вернет его с кодом 200. > > Если мы загрузили через nodejs-приложение файл public/static/new.jpg > > GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, > > GET на public/static/new.jpg будет возвращать 200. > > > > Гугление проблемы привело к пониманию, что это не ошибка, а особенность > > Express-сервера и для production рекомендуется использовать связку > > nginx+express. Как мне настроить работу этой связки, я не вполне > > представляю, поэтому прошу помощи здесь. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From red-fox0 на ya.ru Tue Sep 29 05:43:33 2020 From: red-fox0 на ya.ru (fox) Date: Tue, 29 Sep 2020 12:43:33 +0700 Subject: =?UTF-8?B?UmU6INGB0YLQsNGC0LjRh9C10YHQutC40Lkg0LrQvtC90YLQtdC90YIg0LggTm9k?= =?UTF-8?B?ZUpTIEV4cHJlc3M=?= In-Reply-To: References: Message-ID: Как уже писали выше, например, так: server { location / { proxy_pass http://127.0.0.1:3000; } location /public/static/ { root /var/www/path/to/static; } } 29.09.2020 12:14, Cyril Zlachevsky пишет: > В middleware NextJS каталог public прописан как protected: > protected generatePublicRoutes(): Route[] { > > Авторизация требуется только на загрузку файлов в данный каталог через > запросы PUT и POST и реализована в Express. > И насколько я представляю задачу, нужно, чтобы nginx знал об Express и > динамический контент отдавал ему (на порт 3000 например), а работу со > статикой брал на себя. > Как этот функционал реализовать? > > пн, 28 сент. 2020 г. в 21:07, Alexey Galygin : >> >> Express действительно любит кэшировать состояния (правда это больше касается шаблонов — он их компилирует и больше не проверяет, но слышать про файлы такое удивительно, возможно используемое раздающее middleware придерживается другой политики) >> > >> обычная практика в таких случаях: >> >> выделение «датахранилки» — папки, которую через настроенный location раздаёт nginx напрямую >> с кэшами (заголовки и настройки добавить по вкусу) >> https://nginx.org/ru/docs/beginners_guide.html#static >> >> вся статика складывается туда, и нет смысла грузить backend непрофильными запросами вообще — nginx отстреляется лучше всего >> >> если каким-то файлам требуется авторизация, можно сделать дополнительный internal location и с backend после проверки кидать туда (через x-accel-redirect — https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) >> и nginx опять таки отдаст статику напрямую и быстрее любой backend логики >> >> более того, можно сделать, чтобы правильна работала отдача частичного контента (bytes range) и эффективная раздача с диска >> >> всё что не попадает под пути хранилки проксировать на Express >> >> On 28 Sep 2020, at 20:08, Cyril Zlachevsky wrote: >> >> Есть приложение на NodeJS, которое прекрасно работает в >> developer-режиме. В качестве http-сервера используется ExpressJS. >> В production-режиме появляется проблема - http GET запросы возвращают >> 404-ю ошибку для всех новых файлов, загруженных после старта приложения >> в каталог public. >> >> Пример: если до старта файл public/static/old.jpg существовал, GET >> запрос вернет его с кодом 200. >> Если мы загрузили через nodejs-приложение файл public/static/new.jpg >> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, >> GET на public/static/new.jpg будет возвращать 200. >> >> Гугление проблемы привело к пониманию, что это не ошибка, а особенность >> Express-сервера и для production рекомендуется использовать связку >> nginx+express. Как мне настроить работу этой связки, я не вполне >> представляю, поэтому прошу помощи здесь. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From cyril.zlachevsky на gmail.com Tue Sep 29 07:11:18 2020 From: cyril.zlachevsky на gmail.com (Cyril Zlachevsky) Date: Tue, 29 Sep 2020 10:11:18 +0300 Subject: =?UTF-8?B?UmU6INGB0YLQsNGC0LjRh9C10YHQutC40Lkg0LrQvtC90YLQtdC90YIg0LggTm9k?= =?UTF-8?B?ZUpTIEV4cHJlc3M=?= In-Reply-To: References: Message-ID: спасибо за помощь, все заработало как надо, с небольшими изменениями - в строке конфига nginx root root /var/www/path/to/static; не нужно указывать в конце static, иначе nginx будет добавлять static два раза в запрос и не находить запрашиваемый файл: 2020/09/29 09:21:30 [error] 1530#1530: *179 open() "home/user/src/nodejs-app/public/static/static/paintings/ekGLnI-1601359891434.jpg" failed (2: No such file or directory), client: 127.0.0.1, server: , request: "GET /static/paintings/ekGLnI-1601359891434.jpg HTTP/1.1", host: "127.0.0.1:8080", referrer: "http://127.0.0.1:8080/admin/paintings/16" В итоге рабочий конфиг у меня получился такой: server { listen 8080; location / { proxy_pass http://127.0.0.1:3000; } location /static/ { root /home/user/src/nodejs-app/public/; } } Осталось как-то проверить, будут ли отклоняться запросы PUT и POST-запросы к каталогу public/static, не содержащие кук авторизации - эта проверка есть на бек-энде, но я не уверен, сработает ли она в текущей связке с nginx. вт, 29 сент. 2020 г. в 08:44, fox : > > Как уже писали выше, например, так: > server { > location / { > proxy_pass http://127.0.0.1:3000; > } > > location /public/static/ { > root /var/www/path/to/static; > } > } > > 29.09.2020 12:14, Cyril Zlachevsky пишет: > > В middleware NextJS каталог public прописан как protected: > > protected generatePublicRoutes(): Route[] { > > > > Авторизация требуется только на загрузку файлов в данный каталог через > > запросы PUT и POST и реализована в Express. > > И насколько я представляю задачу, нужно, чтобы nginx знал об Express и > > динамический контент отдавал ему (на порт 3000 например), а работу со > > статикой брал на себя. > > Как этот функционал реализовать? > > > > пн, 28 сент. 2020 г. в 21:07, Alexey Galygin : > >> > >> Express действительно любит кэшировать состояния (правда это больше касается шаблонов — он их компилирует и больше не проверяет, но слышать про файлы такое удивительно, возможно используемое раздающее middleware придерживается другой политики) > >> > > > >> обычная практика в таких случаях: > >> > >> выделение «датахранилки» — папки, которую через настроенный location раздаёт nginx напрямую > >> с кэшами (заголовки и настройки добавить по вкусу) > >> https://nginx.org/ru/docs/beginners_guide.html#static > >> > >> вся статика складывается туда, и нет смысла грузить backend непрофильными запросами вообще — nginx отстреляется лучше всего > >> > >> если каким-то файлам требуется авторизация, можно сделать дополнительный internal location и с backend после проверки кидать туда (через x-accel-redirect — https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) > >> и nginx опять таки отдаст статику напрямую и быстрее любой backend логики > >> > >> более того, можно сделать, чтобы правильна работала отдача частичного контента (bytes range) и эффективная раздача с диска > >> > >> всё что не попадает под пути хранилки проксировать на Express > >> > >> On 28 Sep 2020, at 20:08, Cyril Zlachevsky wrote: > >> > >> Есть приложение на NodeJS, которое прекрасно работает в > >> developer-режиме. В качестве http-сервера используется ExpressJS. > >> В production-режиме появляется проблема - http GET запросы возвращают > >> 404-ю ошибку для всех новых файлов, загруженных после старта приложения > >> в каталог public. > >> > >> Пример: если до старта файл public/static/old.jpg существовал, GET > >> запрос вернет его с кодом 200. > >> Если мы загрузили через nodejs-приложение файл public/static/new.jpg > >> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, > >> GET на public/static/new.jpg будет возвращать 200. > >> > >> Гугление проблемы привело к пониманию, что это не ошибка, а особенность > >> Express-сервера и для production рекомендуется использовать связку > >> nginx+express. Как мне настроить работу этой связки, я не вполне > >> представляю, поэтому прошу помощи здесь. From chipitsine на gmail.com Tue Sep 29 09:44:53 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 29 Sep 2020 14:44:53 +0500 Subject: =?UTF-8?B?UmU6INGB0YLQsNGC0LjRh9C10YHQutC40Lkg0LrQvtC90YLQtdC90YIg0LggTm9k?= =?UTF-8?B?ZUpTIEV4cHJlc3M=?= In-Reply-To: References: Message-ID: вт, 29 сент. 2020 г. в 12:11, Cyril Zlachevsky : > спасибо за помощь, все заработало как надо, с небольшими изменениями - > в строке конфига nginx > root root /var/www/path/to/static; > не нужно указывать в конце static, иначе nginx будет добавлять static > два раза в запрос и не находить запрашиваемый файл: > 2020/09/29 09:21:30 [error] 1530#1530: *179 open() > > "home/user/src/nodejs-app/public/static/static/paintings/ekGLnI-1601359891434.jpg" > failed (2: No such file or directory), client: 127.0.0.1, server: , > request: "GET /static/paintings/ekGLnI-1601359891434.jpg HTTP/1.1", > host: "127.0.0.1:8080", referrer: > "http://127.0.0.1:8080/admin/paintings/16" > > В итоге рабочий конфиг у меня получился такой: > server { > listen 8080; > location / { > proxy_pass http://127.0.0.1:3000; > } > > location /static/ { > root /home/user/src/nodejs-app/public/; > } > } > > Осталось как-то проверить, будут ли отклоняться запросы PUT и > POST-запросы к каталогу public/static, не содержащие кук авторизации - > эта проверка есть на бек-энде, но я не уверен, сработает ли она в > текущей связке с nginx. > curl -X POST ... curl -X PUT ... > > > вт, 29 сент. 2020 г. в 08:44, fox : > > > > Как уже писали выше, например, так: > > server { > > location / { > > proxy_pass http://127.0.0.1:3000; > > } > > > > location /public/static/ { > > root /var/www/path/to/static; > > } > > } > > > > 29.09.2020 12:14, Cyril Zlachevsky пишет: > > > В middleware NextJS каталог public прописан как protected: > > > protected generatePublicRoutes(): Route[] { > > > > > > Авторизация требуется только на загрузку файлов в данный каталог через > > > запросы PUT и POST и реализована в Express. > > > И насколько я представляю задачу, нужно, чтобы nginx знал об Express и > > > динамический контент отдавал ему (на порт 3000 например), а работу со > > > статикой брал на себя. > > > Как этот функционал реализовать? > > > > > > пн, 28 сент. 2020 г. в 21:07, Alexey Galygin : > > >> > > >> Express действительно любит кэшировать состояния (правда это больше > касается шаблонов — он их компилирует и больше не проверяет, но слышать про > файлы такое удивительно, возможно используемое раздающее middleware > придерживается другой политики) > > >> > > > > > >> обычная практика в таких случаях: > > >> > > >> выделение «датахранилки» — папки, которую через настроенный location > раздаёт nginx напрямую > > >> с кэшами (заголовки и настройки добавить по вкусу) > > >> https://nginx.org/ru/docs/beginners_guide.html#static > > >> > > >> вся статика складывается туда, и нет смысла грузить backend > непрофильными запросами вообще — nginx отстреляется лучше всего > > >> > > >> если каким-то файлам требуется авторизация, можно сделать > дополнительный internal location и с backend после проверки кидать туда > (через x-accel-redirect — > https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) > > >> и nginx опять таки отдаст статику напрямую и быстрее любой backend > логики > > >> > > >> более того, можно сделать, чтобы правильна работала отдача частичного > контента (bytes range) и эффективная раздача с диска > > >> > > >> всё что не попадает под пути хранилки проксировать на Express > > >> > > >> On 28 Sep 2020, at 20:08, Cyril Zlachevsky < > cyril.zlachevsky на gmail.com> wrote: > > >> > > >> Есть приложение на NodeJS, которое прекрасно работает в > > >> developer-режиме. В качестве http-сервера используется ExpressJS. > > >> В production-режиме появляется проблема - http GET запросы возвращают > > >> 404-ю ошибку для всех новых файлов, загруженных после старта > приложения > > >> в каталог public. > > >> > > >> Пример: если до старта файл public/static/old.jpg существовал, GET > > >> запрос вернет его с кодом 200. > > >> Если мы загрузили через nodejs-приложение файл public/static/new.jpg > > >> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение, > > >> GET на public/static/new.jpg будет возвращать 200. > > >> > > >> Гугление проблемы привело к пониманию, что это не ошибка, а > особенность > > >> Express-сервера и для production рекомендуется использовать связку > > >> nginx+express. Как мне настроить работу этой связки, я не вполне > > >> представляю, поэтому прошу помощи здесь. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Sep 29 14:46:21 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 29 Sep 2020 17:46:21 +0300 Subject: nginx-1.19.3 Message-ID: <20200929144621.GF1136@mdounin.ru> Изменения в nginx 1.19.3 29.09.2020 *) Добавление: модуль ngx_stream_set_module. *) Добавление: директива proxy_cookie_flags. *) Добавление: директива userid_flags. *) Исправление: расширение управления кэшированием stale-if-error ошибочно применялось, если бэкенд возвращал ответ с кодом 500, 502, 503, 504, 403, 404 или 429. *) Исправление: если использовалось кэширование и бэкенд возвращал ответы с строкой заголовка Vary, в логах могли появляться сообщения "[crit] cache file ... has too long header". *) Изменение: при использовании OpenSSL 1.1.1 в логах могли появляться сообщения "[crit] SSL_write() failed". *) Исправление: в логах могли появляться сообщения "SSL_shutdown() failed (SSL: ... bad write retry)"; ошибка появилась в 1.19.2. *) Исправление: при использовании HTTP/2 в рабочем процессе мог произойти segmentation fault, если ошибки с кодом 400 с помощью директивы error_page перенаправлялись в проксируемый location. *) Исправление: утечки сокетов при использовании HTTP/2 и подзапросов в модуле njs. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Sep 29 16:12:14 2020 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Tue, 29 Sep 2020 12:12:14 -0400 Subject: =?UTF-8?B?0J/QvtGH0LXQvNGDINC/0YPRgdGC0L7QuSBpZiDQu9C+0LzQsNC10YIg0YDQsNCx?= =?UTF-8?B?0L7RgtGDIHRyeSBmaWxlcz8=?= Message-ID: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> Имеется nginx 1.19.2 со следующей настройкой: server { location / { if ($http_user_agent ~ "TestAgent") { } try_files $uri $uri/ /index.html; } } Проверяю: 1) curl http://127.0.0.1/unknown -- правильно возвращает index.html 2) curl http://127.0.0.1/ -H 'User-Agent: TestAgent' -- правильно возвращает index.html 3) curl http://127.0.0.1/unknown -H 'User-Agent: TestAgent' -- неправильно возвращает ошибку 404 Почему попадание в if меняет логику работы последующего try_files? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289591,289591#msg-289591 From pluknet на nginx.com Tue Sep 29 16:29:10 2020 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 29 Sep 2020 17:29:10 +0100 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> Message-ID: <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> > On 29 Sep 2020, at 17:12, Ilya Evseev wrote: > > Имеется nginx 1.19.2 со следующей настройкой: > > server { > location / { > if ($http_user_agent ~ "TestAgent") { } > try_files $uri $uri/ /index.html; > } > } > > Почему попадание в if меняет логику работы последующего try_files? https://wiki.nginx.org/IfIsEvil -- Sergey Kandaurov From mif на me.com Tue Sep 29 16:31:50 2020 From: mif на me.com (Alexey Galygin) Date: Tue, 29 Sep 2020 19:31:50 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> Message-ID: <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> присоединяюсь к вопросу: почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее нам вот тоже приходится делать по несколько map, чтобы логику чуть более сложную построить… и это ужас > On 29 Sep 2020, at 19:29, Sergey Kandaurov wrote: > > >> On 29 Sep 2020, at 17:12, Ilya Evseev wrote: >> >> Имеется nginx 1.19.2 со следующей настройкой: >> >> server { >> location / { >> if ($http_user_agent ~ "TestAgent") { } >> try_files $uri $uri/ /index.html; >> } >> } >> >> Почему попадание в if меняет логику работы последующего try_files? > > https://wiki.nginx.org/IfIsEvil > > -- > Sergey Kandaurov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From red-fox0 на ya.ru Tue Sep 29 16:47:58 2020 From: red-fox0 на ya.ru (fox) Date: Tue, 29 Sep 2020 23:47:58 +0700 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> Message-ID: 1) может, потому что конфиг - это не язык программирования? 2) изменение поведения сломает тысячи существующих систем. 29.09.2020 23:31, Alexey Galygin пишет: > присоединяюсь к вопросу: > > почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее > > нам вот тоже приходится делать по несколько map, чтобы логику чуть более сложную построить… > и это ужас > >> On 29 Sep 2020, at 19:29, Sergey Kandaurov wrote: >> >> >>> On 29 Sep 2020, at 17:12, Ilya Evseev wrote: >>> >>> Имеется nginx 1.19.2 со следующей настройкой: >>> >>> server { >>> location / { >>> if ($http_user_agent ~ "TestAgent") { } >>> try_files $uri $uri/ /index.html; >>> } >>> } >>> >>> Почему попадание в if меняет логику работы последующего try_files? >> >> https://wiki.nginx.org/IfIsEvil >> >> -- >> Sergey Kandaurov >> >> _______________________________________________ >> 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 mif на me.com Tue Sep 29 17:41:10 2020 From: mif на me.com (Alexey Galygin) Date: Tue, 29 Sep 2020 20:41:10 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> Message-ID: иногда трудно обойтись без дополнительной логики, которую ради такой мелочи отдавать на backend грустно и речь про улучшение поведения исключительно с обратной совместимостью если совсем никак, то можно добавить условно extended if — eif > On 29 Sep 2020, at 19:47, fox wrote: > > 1) может, потому что конфиг - это не язык программирования? > > 2) изменение поведения сломает тысячи существующих систем. > > > 29.09.2020 23:31, Alexey Galygin пишет: >> присоединяюсь к вопросу: >> >> почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее >> >> нам вот тоже приходится делать по несколько map, чтобы логику чуть более сложную построить… >> и это ужас >> >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov wrote: >>> >>> >>>> On 29 Sep 2020, at 17:12, Ilya Evseev wrote: >>>> >>>> Имеется nginx 1.19.2 со следующей настройкой: >>>> >>>> server { >>>> location / { >>>> if ($http_user_agent ~ "TestAgent") { } >>>> try_files $uri $uri/ /index.html; >>>> } >>>> } >>>> >>>> Почему попадание в if меняет логику работы последующего try_files? >>> >>> https://wiki.nginx.org/IfIsEvil >>> >>> -- >>> Sergey Kandaurov >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine на gmail.com Tue Sep 29 18:49:30 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 29 Sep 2020 23:49:30 +0500 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> Message-ID: это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в определенном синтаксисе. сейчас вы точно так же выражаете свою мысль через map-ы. по сути просто диалекты языка вт, 29 сент. 2020 г. в 22:41, Alexey Galygin : > иногда трудно обойтись без дополнительной логики, > которую ради такой мелочи отдавать на backend грустно > > и речь про улучшение поведения исключительно с обратной совместимостью > > если совсем никак, то можно добавить условно extended if — eif > > > > On 29 Sep 2020, at 19:47, fox wrote: > > > > 1) может, потому что конфиг - это не язык программирования? > > > > 2) изменение поведения сломает тысячи существующих систем. > > > > > > 29.09.2020 23:31, Alexey Galygin пишет: > >> присоединяюсь к вопросу: > >> > >> почему бы не сделать if нормальным? чтобы без артефактов… и немного > мощнее > >> > >> нам вот тоже приходится делать по несколько map, чтобы логику чуть > более сложную построить… > >> и это ужас > >> > >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov wrote: > >>> > >>> > >>>> On 29 Sep 2020, at 17:12, Ilya Evseev > wrote: > >>>> > >>>> Имеется nginx 1.19.2 со следующей настройкой: > >>>> > >>>> server { > >>>> location / { > >>>> if ($http_user_agent ~ "TestAgent") { } > >>>> try_files $uri $uri/ /index.html; > >>>> } > >>>> } > >>>> > >>>> Почему попадание в if меняет логику работы последующего try_files? > >>> > >>> https://wiki.nginx.org/IfIsEvil > >>> > >>> -- > >>> Sergey Kandaurov > >>> > >>> _______________________________________________ > >>> 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 mif на me.com Tue Sep 29 19:24:13 2020 From: mif на me.com (Alexey Galygin) Date: Tue, 29 Sep 2020 22:24:13 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> Message-ID: <3CD6B7DE-A25E-47C5-9DC7-59AC5C553F45@me.com> не вкусовщина часто очень не хватает простейших and/&& и or/|| вот чтобы такое не писать: if ($http_user_agent ~ "HackYou") { set $block "A"; } if ($method = "POST") { set $block "${block}B"; } if ($uri ~ “^/admin/some/url") { set $block "${block}C"; } if ($block = "ABC") { return 403; } vs условно: if/eif ($http_user_agent ~ “HackYou” && $method = “POST” && $uri ~ “^/admin/some/url”) { return 403; } > On 29 Sep 2020, at 21:49, Илья Шипицин wrote: > > это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в определенном синтаксисе. > сейчас вы точно так же выражаете свою мысль через map-ы. > > по сути просто диалекты языка > > вт, 29 сент. 2020 г. в 22:41, Alexey Galygin >: > иногда трудно обойтись без дополнительной логики, > которую ради такой мелочи отдавать на backend грустно > > и речь про улучшение поведения исключительно с обратной совместимостью > > если совсем никак, то можно добавить условно extended if — eif > > > > On 29 Sep 2020, at 19:47, fox > wrote: > > > > 1) может, потому что конфиг - это не язык программирования? > > > > 2) изменение поведения сломает тысячи существующих систем. > > > > > > 29.09.2020 23:31, Alexey Galygin пишет: > >> присоединяюсь к вопросу: > >> > >> почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее > >> > >> нам вот тоже приходится делать по несколько map, чтобы логику чуть более сложную построить… > >> и это ужас > >> > >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov > wrote: > >>> > >>> > >>>> On 29 Sep 2020, at 17:12, Ilya Evseev > wrote: > >>>> > >>>> Имеется nginx 1.19.2 со следующей настройкой: > >>>> > >>>> server { > >>>> location / { > >>>> if ($http_user_agent ~ "TestAgent") { } > >>>> try_files $uri $uri/ /index.html; > >>>> } > >>>> } > >>>> > >>>> Почему попадание в if меняет логику работы последующего try_files? > >>> > >>> https://wiki.nginx.org/IfIsEvil > >>> > >>> -- > >>> Sergey Kandaurov > >>> > >>> _______________________________________________ > >>> 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From red-fox0 на ya.ru Wed Sep 30 02:14:22 2020 From: red-fox0 на ya.ru (fox) Date: Wed, 30 Sep 2020 09:14:22 +0700 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: <3CD6B7DE-A25E-47C5-9DC7-59AC5C553F45@me.com> References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> <3CD6B7DE-A25E-47C5-9DC7-59AC5C553F45@me.com> Message-ID: Троллишь? map "$http_user_agent:$method:$uri" $block { "HackYou:POST:/admin/some/url" "1"; } if ($block) { return 403; } 30.09.2020 02:24, Alexey Galygin пишет: > не вкусовщина > часто очень не хватает простейших and/&& и or/|| > > вот чтобы такое не писать: > > if($http_user_agent~ "HackYou"){ set$block"A"; } if($method= "POST") { > set$block"${block}B"; } if($uri~ “^/admin/some/url") { > set$block"${block}C"; } if($block= "ABC") { return403; } > > vs условно: > > if/eif ($http_user_agent~ “HackYou” && $method= “POST” && $uri~ > “^/admin/some/url”) { > return403; > } > > >> On 29 Sep 2020, at 21:49, Илья Шипицин > > wrote: >> >> это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в >> определенном синтаксисе. >> сейчас вы точно так же выражаете свою мысль через map-ы. >> >> по сути просто диалекты языка >> >> вт, 29 сент. 2020 г. в 22:41, Alexey Galygin > >: >> >> иногда трудно обойтись без дополнительной логики, >> которую ради такой мелочи отдавать на backend грустно >> >> и речь про улучшение поведения исключительно с обратной совместимостью >> >> если совсем никак, то можно добавить условно extended if — eif >> >> >> > On 29 Sep 2020, at 19:47, fox > > wrote: >> > >> > 1) может, потому что конфиг - это не язык программирования? >> > >> > 2) изменение поведения сломает тысячи существующих систем. >> > >> > >> > 29.09.2020 23:31, Alexey Galygin пишет: >> >> присоединяюсь к вопросу: >> >> >> >> почему бы не сделать if нормальным? чтобы без артефактов… и >> немного мощнее >> >> >> >> нам вот тоже приходится делать по несколько map, чтобы логику >> чуть более сложную построить… >> >> и это ужас >> >> >> >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov > > wrote: >> >>> >> >>> >> >>>> On 29 Sep 2020, at 17:12, Ilya Evseev >> > >> wrote: >> >>>> >> >>>> Имеется nginx 1.19.2 со следующей настройкой: >> >>>> >> >>>>  server { >> >>>>      location / { >> >>>>          if ($http_user_agent ~ "TestAgent") { } >> >>>>          try_files $uri $uri/ /index.html; >> >>>>      } >> >>>>  } >> >>>> >> >>>> Почему попадание в if меняет логику работы последующего >> try_files? >> >>> >> >>> https://wiki.nginx.org/IfIsEvil >> >>> >> >>> -- >> >>> Sergey Kandaurov >> >>> >> >>> _______________________________________________ >> >>> 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 > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From mif на me.com Wed Sep 30 05:44:01 2020 From: mif на me.com (Alexey Galygin) Date: Wed, 30 Sep 2020 08:44:01 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> <3CD6B7DE-A25E-47C5-9DC7-59AC5C553F45@me.com> Message-ID: <9D9BC5E6-F4F0-4D9C-B6F0-2998491D2327@me.com> да, примеры были из habr, но и там к статье были претензии к map-решению + я специально усложнил пример регулярными выражениями поэтому указанный map это не эквивалент во вторых плохо читаемый хак и издевательство над линейной логикой зачем такие костыли, если можно доделать нормальный if? > On 30 Sep 2020, at 05:14, fox wrote: > > Троллишь? > > map "$http_user_agent:$method:$uri" $block { > "HackYou:POST:/admin/some/url" "1"; > } > > if ($block) { > return 403; > } > > > 30.09.2020 02:24, Alexey Galygin пишет: >> не вкусовщина >> часто очень не хватает простейших and/&& и or/|| >> >> вот чтобы такое не писать: >> >> if($http_user_agent~ "HackYou"){ set$block"A"; } if($method= "POST") { >> set$block"${block}B"; } if($uri~ “^/admin/some/url") { >> set$block"${block}C"; } if($block= "ABC") { return403; } >> >> vs условно: >> >> if/eif ($http_user_agent~ “HackYou” && $method= “POST” && $uri~ >> “^/admin/some/url”) { >> return403; >> } >> >> >>> On 29 Sep 2020, at 21:49, Илья Шипицин >> >> wrote: >>> >>> это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в >>> определенном синтаксисе. >>> сейчас вы точно так же выражаете свою мысль через map-ы. >>> >>> по сути просто диалекты языка >>> >>> вт, 29 сент. 2020 г. в 22:41, Alexey Galygin >>> >>: >>> >>> иногда трудно обойтись без дополнительной логики, >>> которую ради такой мелочи отдавать на backend грустно >>> >>> и речь про улучшение поведения исключительно с обратной совместимостью >>> >>> если совсем никак, то можно добавить условно extended if — eif >>> >>> >>>> On 29 Sep 2020, at 19:47, fox >>> >> wrote: >>>> >>>> 1) может, потому что конфиг - это не язык программирования? >>>> >>>> 2) изменение поведения сломает тысячи существующих систем. >>>> >>>> >>>> 29.09.2020 23:31, Alexey Galygin пишет: >>>>> присоединяюсь к вопросу: >>>>> >>>>> почему бы не сделать if нормальным? чтобы без артефактов… и >>> немного мощнее >>>>> >>>>> нам вот тоже приходится делать по несколько map, чтобы логику >>> чуть более сложную построить… >>>>> и это ужас >>>>> >>>>>> On 29 Sep 2020, at 19:29, Sergey Kandaurov >>> >> wrote: >>>>>> >>>>>> >>>>>>> On 29 Sep 2020, at 17:12, Ilya Evseev >>> >> >>> wrote: >>>>>>> >>>>>>> Имеется nginx 1.19.2 со следующей настройкой: >>>>>>> >>>>>>> server { >>>>>>> location / { >>>>>>> if ($http_user_agent ~ "TestAgent") { } >>>>>>> try_files $uri $uri/ /index.html; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Почему попадание в if меняет логику работы последующего >>> try_files? >>>>>> >>>>>> https://wiki.nginx.org/IfIsEvil >>>>>> >>>>>> -- >>>>>> Sergey Kandaurov >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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 chipitsine на gmail.com Wed Sep 30 05:49:18 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 30 Sep 2020 10:49:18 +0500 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQv9GD0YHRgtC+0LkgaWYg0LvQvtC80LDQtdGCINGA?= =?UTF-8?B?0LDQsdC+0YLRgyB0cnkgZmlsZXM/?= In-Reply-To: <9D9BC5E6-F4F0-4D9C-B6F0-2998491D2327@me.com> References: <16e52f782c1fa3a0ed7e2f4294fff148.NginxMailingListRussian@forum.nginx.org> <5FFAAD13-965C-403C-A05A-81D2F94E5A83@nginx.com> <93C9DA33-A223-4148-94D3-B35F1641D124@me.com> <3CD6B7DE-A25E-47C5-9DC7-59AC5C553F45@me.com> <9D9BC5E6-F4F0-4D9C-B6F0-2998491D2327@me.com> Message-ID: читаемость штука субъективная и скорее предмет холиваров. уверен, найдется непустое множество людей, для которых ваш вариант нечитаемый. наверное, хороший ответ про недостаток читаемости может заключаться в том, что конфиг можно сопровождать комментариями, улучшающими читаемость. а добавить кусок кода, который будет делать примерно то, что можно сделать без него, это усложнение на ровном месте и потенциальный источник ошибок ср, 30 сент. 2020 г. в 10:44, Alexey Galygin : > да, примеры были из habr, но и там к статье были претензии к map-решению > + я специально усложнил пример регулярными выражениями > > поэтому указанный map это не эквивалент > > во вторых плохо читаемый хак и издевательство над линейной логикой > зачем такие костыли, если можно доделать нормальный if? > > > > On 30 Sep 2020, at 05:14, fox wrote: > > Троллишь? > > map "$http_user_agent:$method:$uri" $block { > "HackYou:POST:/admin/some/url" "1"; > } > > if ($block) { > return 403; > } > > > 30.09.2020 02:24, Alexey Galygin пишет: > > не вкусовщина > часто очень не хватает простейших and/&& и or/|| > > вот чтобы такое не писать: > > if($http_user_agent~ "HackYou"){ set$block"A"; } if($method= "POST") { > set$block"${block}B"; } if($uri~ “^/admin/some/url") { > set$block"${block}C"; } if($block= "ABC") { return403; } > > vs условно: > > if/eif ($http_user_agent~ “HackYou” && $method= “POST” && $uri~ > “^/admin/some/url”) { > return403; > } > > > On 29 Sep 2020, at 21:49, Илья Шипицин >> wrote: > > это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в > определенном синтаксисе. > сейчас вы точно так же выражаете свою мысль через map-ы. > > по сути просто диалекты языка > > вт, 29 сент. 2020 г. в 22:41, Alexey Galygin >>: > > иногда трудно обойтись без дополнительной логики, > которую ради такой мелочи отдавать на backend грустно > > и речь про улучшение поведения исключительно с обратной совместимостью > > если совсем никак, то можно добавить условно extended if — eif > > > On 29 Sep 2020, at 19:47, fox > >> wrote: > > > 1) может, потому что конфиг - это не язык программирования? > > 2) изменение поведения сломает тысячи существующих систем. > > > 29.09.2020 23:31, Alexey Galygin пишет: > > присоединяюсь к вопросу: > > почему бы не сделать if нормальным? чтобы без артефактов… и > > немного мощнее > > > нам вот тоже приходится делать по несколько map, чтобы логику > > чуть более сложную построить… > > и это ужас > > On 29 Sep 2020, at 19:29, Sergey Kandaurov > >> wrote: > > > > On 29 Sep 2020, at 17:12, Ilya Evseev > > >> > wrote: > > > Имеется nginx 1.19.2 со следующей настройкой: > > server { > location / { > if ($http_user_agent ~ "TestAgent") { } > try_files $uri $uri/ /index.html; > } > } > > Почему попадание в if меняет логику работы последующего > > try_files? > > > https://wiki.nginx.org/IfIsEvil > > -- > Sergey Kandaurov > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 nginx-forum на forum.nginx.org Wed Sep 30 07:03:01 2020 From: nginx-forum на forum.nginx.org (skeletor) Date: Wed, 30 Sep 2020 03:03:01 -0400 Subject: =?UTF-8?B?0JjQt9C80LXQvdC10L3QuNGPINCyINCx0LvQvtC60LUgaWY=?= Message-ID: <159085ffca20c0833dafa5a3b498d20d.NginxMailingListRussian@forum.nginx.org> Всем привет. Начал замечать, что с недавних пор, (на версии 1.19.1 точно, и, скорее всего на 1.17.Х) поведение if поменялось. При этом в документации (что en, что ru - одинаково) сказано, что такая конструкция будет работать: if ($slow) { limit_rate 10k; } но на практике нужно писать if ($slow = 1) { limit_rate 10k; } иначе не работает. Могу привести конкретный пример, где у меня не работает "упрощенный" (то есть без сравнения с 1) if: map $is_bot:$uri:$http_referer $very_bad { default ''; "~*0:(\/api):(.*bad\.html)" '1'; } ... if ($very_bad = 1) {return 403;} Именно так работает. Если же указать if ($very_bad) {return 403;} то не работает. Есть такие, у которых нормально работает "упрощённый" if на новых версиях? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289612,289612#msg-289612 From fe на hamilton.rinet.ru Wed Sep 30 08:40:51 2020 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Wed, 30 Sep 2020 11:40:51 +0300 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjRjyDQsiDQsdC70L7QutC1IGlm?= In-Reply-To: <159085ffca20c0833dafa5a3b498d20d.NginxMailingListRussian@forum.nginx.org> References: <159085ffca20c0833dafa5a3b498d20d.NginxMailingListRussian@forum.nginx.org> Message-ID: у меня вот так работает: > map $request_uri $bad { > default ''; > /string '1'; > /number 1; > /zero_one '01'; > /one_space '1 '; > /space_one ' 1'; > /zero '0'; > } > ... > if ($bad) { return 403 "$bad"; } > [fe на hamilton ~]$ for loc in string number zero_one one_space space_one; do curl -w " %{http_code}\n" https://test.host/$loc; done > 1 403 > 1 403 > 01 403 > 1 403 > 1 403 Как-раз на части случаев тут if ($bad = '1') перестает работать. Но придумать кейс в обратную сторону у меня пока не получилось. Я бы ради дебага добавил бы локейшен, где бы поставил return 202 "$very_bad" и посмотрел какое значение там получается. p.s. > nginx version: nginx/1.19.2 built with OpenSSL 1.1.1g 21 Apr 2020 30.09.2020 10:03, skeletor пишет: > Всем привет. > Начал замечать, что с недавних пор, (на версии 1.19.1 точно, и, скорее всего > на 1.17.Х) поведение if поменялось. При этом в документации (что en, что ru > - одинаково) сказано, что такая конструкция будет работать: > > if ($slow) { > limit_rate 10k; > } > > но на практике нужно писать > > if ($slow = 1) { > limit_rate 10k; > } > > иначе не работает. > > Могу привести конкретный пример, где у меня не работает "упрощенный" (то > есть без сравнения с 1) if: > > map $is_bot:$uri:$http_referer $very_bad { > default ''; > "~*0:(\/api):(.*bad\.html)" '1'; > } > > ... > if ($very_bad = 1) {return 403;} > > Именно так работает. Если же указать > > if ($very_bad) {return 403;} > > то не работает. > > Есть такие, у которых нормально работает "упрощённый" if на новых версиях? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289612,289612#msg-289612 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From mdounin на mdounin.ru Wed Sep 30 14:04:00 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 30 Sep 2020 17:04:00 +0300 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjRjyDQsiDQsdC70L7QutC1IGlm?= In-Reply-To: <159085ffca20c0833dafa5a3b498d20d.NginxMailingListRussian@forum.nginx.org> References: <159085ffca20c0833dafa5a3b498d20d.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200930140400.GJ1136@mdounin.ru> Hello! On Wed, Sep 30, 2020 at 03:03:01AM -0400, skeletor wrote: > Всем привет. > Начал замечать, что с недавних пор, (на версии 1.19.1 точно, и, скорее всего > на 1.17.Х) поведение if поменялось. При этом в документации (что en, что ru > - одинаково) сказано, что такая конструкция будет работать: > > if ($slow) { > limit_rate 10k; > } > > но на практике нужно писать > > if ($slow = 1) { > limit_rate 10k; > } > > иначе не работает. > > Могу привести конкретный пример, где у меня не работает "упрощенный" (то > есть без сравнения с 1) if: > > map $is_bot:$uri:$http_referer $very_bad { > default ''; > "~*0:(\/api):(.*bad\.html)" '1'; > } > > ... > if ($very_bad = 1) {return 403;} > > Именно так работает. Если же указать > > if ($very_bad) {return 403;} > > то не работает. > > Есть такие, у которых нормально работает "упрощённый" if на новых версиях? Поведение "упрощённого" if не менялось с nginx 1.0.1: истиной считаются любые значения переменной, кроме пустой строки и "0". Оба приведённые выше условия отлично работают, в там числе упрощённое: map $connection $is_bot { default 0; } map $is_bot:$uri:$http_referer $very_bad { default ''; "~*0:(\/api):(.*bad\.html)" '1'; } server { listen 8080; if ($very_bad) {return 403 true\n;} return 200 "false\n"; } $ curl http://127.0.0.1:8080/api false $ curl http://127.0.0.1:8080/api -H 'Referer: bad.html' true Если у вас не работает - проблема где-то ещё. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Sep 30 15:25:46 2020 From: nginx-forum на forum.nginx.org (elc) Date: Wed, 30 Sep 2020 11:25:46 -0400 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90YvQtSA1MDIg0L7RgtCy0LXRgtGLLg==?= Message-ID: Опишу немного для общего понимания схему: Клиенты обращаются на несколько прокси серверов, которые проксирую запросы на другие (промежуточные) прокси и промежуточные прокси уже проксируют запрос на сервера оригинации. Client <-> Edge_proxy <-> proxy_промежуточные <-> Origin server Периодически возникают проблемы с 502-ми ответами в логе с одного из upstream серверов. При этом на запрос к апстриму, где в логе 502, есть записи в error.log вида 2020/09/29 07:28:09 [error] 13038#13038: *4641196828 upstream prematurely closed connection while reading response header from upstream, client: , server: , request: "GET HTTP/1.1", upstream: "http:///", host: "" или 2020/09/29 07:54:54 [error] 40174#40174: *3165979465 upstream prematurely closed connection while reading response header from upstream, client: , server: , request: "GET HTTP/1.1", upstream: "http:///", host: "" Сам лог запроса: IP [30/Sep/2020:10:12:57 +0000] "GET HTTP/1.1" 200 MISS "UPSTREAM1, UPSTREAM2" 75539 "-" "User_agent" "0.079" "-" "TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256" "21/7498183988" 75945 "0, 75539" "-, 0.076" "0.000, 0.076" "502, 200" RU 3dca4fc6a9c7cf10a8448faa0 443 Где "0.000, 0.076" - request_time "502, 200" - соотв коды ответов для Upstream1, Upstream2. При этом через секунду или даже меньше, запросы с этого промежуточного прокси-сервера приходят с 200-м кодом. + очень смущает то, что время ответа 0.000. Значит никакие таймауты не превышались. Проблем с сетью между серверами нет, MTR показывает 0% потерь на дистанции 1час+. Ресурсов на серверах хватает. Помогите, пожалуйста, понять в чем проблема. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289619,289619#msg-289619 From chipitsine на gmail.com Wed Sep 30 15:46:41 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 30 Sep 2020 20:46:41 +0500 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdGL0LUgNTAyINC+0YLQstC10YLRiy4=?= In-Reply-To: References: Message-ID: "while reading response header from upstream" что-то упало на стороне сервера, формирующего ответ. что там за софт ? ср, 30 сент. 2020 г. в 20:25, elc : > Опишу немного для общего понимания схему: > > Клиенты обращаются на несколько прокси серверов, которые проксирую запросы > на другие (промежуточные) прокси и промежуточные прокси уже проксируют > запрос на сервера оригинации. > Client <-> Edge_proxy <-> proxy_промежуточные <-> Origin server > > > > Периодически возникают проблемы с 502-ми ответами в логе с одного из > upstream серверов. > При этом на запрос к апстриму, где в логе 502, есть записи в error.log вида > > > 2020/09/29 07:28:09 [error] 13038#13038: *4641196828 upstream prematurely > closed connection while reading response header from upstream, client: > , > server: , request: "GET HTTP/1.1", upstream: > "http:///", host: "" > или > 2020/09/29 07:54:54 [error] 40174#40174: *3165979465 upstream prematurely > closed connection while reading response header from upstream, client: > , > server: , request: "GET HTTP/1.1", upstream: > "http:///", host: "" > > Сам лог запроса: > IP [30/Sep/2020:10:12:57 +0000] "GET HTTP/1.1" 200 MISS > "UPSTREAM1, UPSTREAM2" 75539 "-" "User_agent" "0.079" "-" > "TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256" "21/7498183988" 75945 "0, 75539" "-, > 0.076" "0.000, 0.076" "502, 200" RU 3dca4fc6a9c7cf10a8448faa0 443 > > Где "0.000, 0.076" - request_time > "502, 200" - соотв коды ответов для Upstream1, Upstream2. > > При этом через секунду или даже меньше, запросы с этого промежуточного > прокси-сервера приходят с 200-м кодом. > + очень смущает то, что время ответа 0.000. Значит никакие таймауты не > превышались. > > Проблем с сетью между серверами нет, MTR показывает 0% потерь на дистанции > 1час+. > Ресурсов на серверах хватает. > > Помогите, пожалуйста, понять в чем проблема. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,289619,289619#msg-289619 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: