From nginx-forum на forum.nginx.org Tue Feb 5 07:15:38 2019 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Tue, 05 Feb 2019 02:15:38 -0500 Subject: =?UTF-8?B?0JzQuNC70LvQuNGB0LXQutGD0L3QtNGLINCyIGVycm9yIGxvZw==?= Message-ID: <9c612345ebe18132783913f551552391.NginxMailingListRussian@forum.nginx.org> Пытаюсь отладить тормоза на одном из серверов Nginx. Включил "error_log ... debug" Проблема в том, что записи туда пишутся с секундной точностью. Есть ли возможность обеспечить миллисекундную? Написал патч, но ещё не проверил: https://gist.github.com/ilyaevseev/ca636314e1ba2a7889c7efca5d85f594 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282912,282912#msg-282912 From mdounin на mdounin.ru Tue Feb 5 15:03:27 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 5 Feb 2019 18:03:27 +0300 Subject: =?UTF-8?B?UmU6INCc0LjQu9C70LjRgdC10LrRg9C90LTRiyDQsiBlcnJvciBsb2c=?= In-Reply-To: <9c612345ebe18132783913f551552391.NginxMailingListRussian@forum.nginx.org> References: <9c612345ebe18132783913f551552391.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190205150327.GX1877@mdounin.ru> Hello! On Tue, Feb 05, 2019 at 02:15:38AM -0500, Ilya Evseev wrote: > Пытаюсь отладить тормоза на одном из серверов Nginx. > Включил "error_log ... debug" > Проблема в том, что записи туда пишутся с секундной точностью. > Есть ли возможность обеспечить миллисекундную? После каждого ухода в ядро (и соответственно обновления времени по выходе из него) - в debug-лог пишется строка "timer delta: ...", в которой указано количество прошедших миллисекунд. Вытаскивать миллисекунды в error log - мы в своё время думали, но, кажется, проблем от этого больше, чем пользы. Особенно с учётом того, что время nginx в норме обновляет один раз за итерацию event loop'а, и все сообщения между уходами в ядро будут использовать одно и то же время. -- Maxim Dounin http://mdounin.ru/ From annulen на yandex.ru Tue Feb 5 15:09:29 2019 From: annulen на yandex.ru (Konstantin Tokarev) Date: Tue, 05 Feb 2019 18:09:29 +0300 Subject: =?UTF-8?B?UmU6INCc0LjQu9C70LjRgdC10LrRg9C90LTRiyDQsiBlcnJvciBsb2c=?= In-Reply-To: <20190205150327.GX1877@mdounin.ru> References: <9c612345ebe18132783913f551552391.NginxMailingListRussian@forum.nginx.org> <20190205150327.GX1877@mdounin.ru> Message-ID: <4808501549379369@iva2-6ec8f0a6115e.qloud-c.yandex.net> 05.02.2019, 18:03, "Maxim Dounin" : > Hello! > > On Tue, Feb 05, 2019 at 02:15:38AM -0500, Ilya Evseev wrote: > >>  Пытаюсь отладить тормоза на одном из серверов Nginx. >>  Включил "error_log ... debug" >>  Проблема в том, что записи туда пишутся с секундной точностью. >>  Есть ли возможность обеспечить миллисекундную? > > После каждого ухода в ядро (и соответственно обновления времени по > выходе из него) - в debug-лог пишется строка "timer delta: ...", в > которой указано количество прошедших миллисекунд. > > Вытаскивать миллисекунды в error log - мы в своё время думали, но, > кажется, проблем от этого больше, чем пользы. Особенно с учётом > того, что время nginx в норме обновляет один раз за итерацию event > loop'а, и все сообщения между уходами в ядро будут использовать > одно и то же время. Если бы лично мне пришлось дебажить проблему, требующую миллисекундных таймингов, я бы добавил в ключевые точки кода трейспойнты LTTng https://lttng.org/docs/v2.10/#doc-tracef > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum на forum.nginx.org Wed Feb 6 06:09:57 2019 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Wed, 06 Feb 2019 01:09:57 -0500 Subject: =?UTF-8?B?UmU6INCc0LjQu9C70LjRgdC10LrRg9C90LTRiyDQsiBlcnJvciBsb2c=?= In-Reply-To: <20190205150327.GX1877@mdounin.ru> References: <20190205150327.GX1877@mdounin.ru> Message-ID: Вижу "timer delta: %M" в выводе "strings nginx-debug", но не вижу ни одной строки с ним в error_log. Упоминания про таймер только такие: 2019/02/05 09:38:23 [debug] 18108#18108: *5453 event timer add: 15: 75000:435707458 2019/02/05 09:38:23 [debug] 18108#18108: *5453 event timer del: 15: 435707458 2019/02/05 09:38:23 [debug] 18103#18103: *5454 event timer add: 27: 75000:435707463 2019/02/05 09:38:23 [debug] 18103#18103: *5454 event timer del: 27: 435707463 Как сделать так, чтобы сообщения timer delta тоже начали записываться в "error_log ... debug"? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282919,282927#msg-282927 From nginx-forum на forum.nginx.org Wed Feb 6 06:12:26 2019 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Wed, 06 Feb 2019 01:12:26 -0500 Subject: =?UTF-8?B?UmU6INCc0LjQu9C70LjRgdC10LrRg9C90LTRiyDQsiBlcnJvciBsb2c=?= In-Reply-To: <20190205150327.GX1877@mdounin.ru> References: <20190205150327.GX1877@mdounin.ru> Message-ID: <4ac2b3c090e13fb7e30f818beb7672be.NginxMailingListRussian@forum.nginx.org> > Вытаскивать миллисекунды в error log - мы в своё время думали, но, кажется, проблем от этого больше, > чем пользы. Особенно с учётом того, что время nginx в норме обновляет один раз за итерацию > event loop'а, и все сообщения между уходами в ядро будут использовать одно и то же время. Если миллисекунды не годятся, то годится ли rdtsc вместо них? Или это непортабельно\несекурно\ненаглядно\непроизводительно и т.д.? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282919,282928#msg-282928 From mdounin на mdounin.ru Wed Feb 6 11:09:28 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 6 Feb 2019 14:09:28 +0300 Subject: =?UTF-8?B?UmU6INCc0LjQu9C70LjRgdC10LrRg9C90LTRiyDQsiBlcnJvciBsb2c=?= In-Reply-To: References: <20190205150327.GX1877@mdounin.ru> Message-ID: <20190206110928.GY1877@mdounin.ru> Hello! On Wed, Feb 06, 2019 at 01:09:57AM -0500, Ilya Evseev wrote: > Вижу "timer delta: %M" в выводе "strings nginx-debug", но не вижу ни одной > строки с ним в error_log. > > Упоминания про таймер только такие: > > 2019/02/05 09:38:23 [debug] 18108#18108: *5453 event timer add: 15: > 75000:435707458 > 2019/02/05 09:38:23 [debug] 18108#18108: *5453 event timer del: 15: > 435707458 > 2019/02/05 09:38:23 [debug] 18103#18103: *5454 event timer add: 27: > 75000:435707463 > 2019/02/05 09:38:23 [debug] 18103#18103: *5454 event timer del: 27: > 435707463 > > Как сделать так, чтобы сообщения timer delta тоже начали записываться в > "error_log ... debug"? Следует задать "error_log ... debug" на глобальном уровне. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Feb 6 19:30:37 2019 From: nginx-forum на forum.nginx.org (314zd271c) Date: Wed, 06 Feb 2019 14:30:37 -0500 Subject: =?UTF-8?B?0YDQtdGI0LXQvdC40LUg0L7Qs9GA0LDQvdC40YfQtdC90LjRjyDQsiAxMCDQv9C1?= =?UTF-8?B?0YDQtdC90LDQv9GA0LDQstC70LXQvdC40LkgYyDQv9C+0LzQvtGJ0YzRjiA=?= =?UTF-8?B?0L/QtdGA0LXRgdCx0L7RgNC60Lggbmdpbng=?= Message-ID: <8617ff5fb286213588101a1e9f72ccc4.NginxMailingListRussian@forum.nginx.org> Здравствуйте! В данном топике https://forum.nginx.org/read.php?21,231038,231038#msg-231038 обсуждалось решение ограничения в 10 перенаправлений ("Для предотвращения зацикливания, которое может возникнуть при использовании некорректных конфигураций, количество внутренних перенаправлений ограничено десятью" https://nginx.org/ru/docs/http/ngx_http_core_module.html#internal ). И там есть решение "в лоб", а именно, указать в исходниках src/http/ngx_http_request.h значение NGX_HTTP_MAX_URI_CHANGES больше 10, https://forum.nginx.org/read.php?21,231038,231045#msg-231045 . При попытке указать NGX_HTTP_MAX_URI_CHANGES < 15 сборка проходит успешно. Но есть реальная необходимость делать 20 перенаправлений. К сожалению, при попытке указать NGX_HTTP_MAX_URI_CHANGES = 20 во время сборки происходит ошибка. Пожалуйста помогите выяснить: Что необходимо сделать, чтобы сборка прошла успешно при NGX_HTTP_MAX_URI_CHANGES = 20 ??? ----------- cc -c -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -I src/http -I src/http/modules \ -o objs/src/http/ngx_http_core_module.o \ src/http/ngx_http_core_module.c src/http/ngx_http_core_module.c: В функции «ngx_http_subrequest»: src/http/ngx_http_core_module.c:2368:5: ошибка: неявное приведение большого целого значения к беззнаковому типу [-Werror=overflow] sr->uri_changes = NGX_HTTP_MAX_URI_CHANGES + 1; ^ cc1: all warnings being treated as errors make[1]: *** [objs/src/http/ngx_http_core_module.o] Ошибка 1 make[1]: Выход из каталога '/*****/nginx-1.15.8' make: *** [build] Ошибка 2 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282935,282935#msg-282935 From vadim.lazovskiy на gmail.com Thu Feb 7 11:43:16 2019 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Thu, 7 Feb 2019 14:43:16 +0300 Subject: =?UTF-8?B?UmU6INGA0LXRiNC10L3QuNC1INC+0LPRgNCw0L3QuNGH0LXQvdC40Y8g0LIgMTAg?= =?UTF-8?B?0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC5IGMg0L/QvtC80L7RidGM?= =?UTF-8?B?0Y4g0L/QtdGA0LXRgdCx0L7RgNC60Lggbmdpbng=?= In-Reply-To: <8617ff5fb286213588101a1e9f72ccc4.NginxMailingListRussian@forum.nginx.org> References: <8617ff5fb286213588101a1e9f72ccc4.NginxMailingListRussian@forum.nginx.org> Message-ID: > > cc -c -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g > -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -I > src/http -I src/http/modules \ > -o objs/src/http/ngx_http_core_module.o \ > src/http/ngx_http_core_module.c > src/http/ngx_http_core_module.c: В функции «ngx_http_subrequest»: > src/http/ngx_http_core_module.c:2368:5: ошибка: неявное приведение большого > целого значения к беззнаковому типу [-Werror=overflow] > sr->uri_changes = NGX_HTTP_MAX_URI_CHANGES + 1; > ^ > cc1: all warnings being treated as errors > make[1]: *** [objs/src/http/ngx_http_core_module.o] Ошибка 1 > make[1]: Выход из каталога '/*****/nginx-1.15.8' > make: *** [build] Ошибка 2 > > Здравствуйте. Под поле uri_changes в ngx_http_request_t (src/http/ngx_http_request.h) отведено 4 бита: unsigned uri_changes:4; Можете попробовать увеличить до 8 или поменять тип на uint8_t, но я не разработчик и сохранение работоспособности и/или совместимости гарантировать не могу. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart на nginx.com Thu Feb 7 17:48:09 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 07 Feb 2019 20:48:09 +0300 Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuNy4x?= Message-ID: <3245223.HeNVid9cUm@vbart-workstation> Здравствуйте. Выпущен корректирующий релиз NGINX Unit для устранения уязвимости. Подвержены версии Unit начиная c 0.3 до 1.7. Всем настоятельно рекомендуется обновиться на новую версию. Изменения в Unit 1.7.1 07.02.2019 *) Безопасность: при обработке специально созданного запроса в процессе роутера могло происходить переполнение буфера, что могло приводить к ошибке сегментации, а также потенциально могло иметь другие последствия (CVE-2019-7401). *) Исправление: установка модуля Go не работала без предварительной сборки самого Unit-демона; ошибка появилась в версии 1.7. Выпуск Unit 1.8 с поддержкой внутренней маршрутизации запросов и экспериментального модуля Java запланирован на конец февраля. -- Валентин Бартенев From vbart на nginx.com Thu Feb 7 17:48:27 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 07 Feb 2019 20:48:27 +0300 Subject: Unit security advisory (CVE-2019-7401) Message-ID: <4656801.HcA8UObv1o@vbart-workstation> Здравствуйте. В NGINX Unit обнаружена уязвимость, которая позволяет атакующему с помощью специально созданного запроса вызвать переполнение буфера в памяти процесса роутера. Это может привести к отказу в обслуживании (краху процесса роутера) и другим неопределенным последствиям (CVE-2019-7401). Проблеме подвержен Unit 0.3 - 1.7. Проблема исправлена в Unit 1.7.1. -- Валентин Бартенев From nginx-forum на forum.nginx.org Thu Feb 7 19:22:41 2019 From: nginx-forum на forum.nginx.org (314zd271c) Date: Thu, 07 Feb 2019 14:22:41 -0500 Subject: =?UTF-8?B?UmU6INGA0LXRiNC10L3QuNC1INC+0LPRgNCw0L3QuNGH0LXQvdC40Y8g0LIgMTAg?= =?UTF-8?B?0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC5IGMg0L/QvtC80L7RidGM?= =?UTF-8?B?0Y4g0L/QtdGA0LXRgdCx0L7RgNC60Lggbmdpbng=?= In-Reply-To: References: Message-ID: <7dca8821ee813061dd18e1466655e6d8.NginxMailingListRussian@forum.nginx.org> Vadim Lazovskiy Wrote: ------------------------------------------------------- > > > > cc -c -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter > -Werror -g > > -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs > -I > > src/http -I src/http/modules \ > > -o objs/src/http/ngx_http_core_module.o \ > > src/http/ngx_http_core_module.c > > src/http/ngx_http_core_module.c: В функции «ngx_http_subrequest»: > > src/http/ngx_http_core_module.c:2368:5: ошибка: неявное приведение > большого > > целого значения к беззнаковому типу [-Werror=overflow] > > sr->uri_changes = NGX_HTTP_MAX_URI_CHANGES + 1; > > ^ > > cc1: all warnings being treated as errors > > make[1]: *** [objs/src/http/ngx_http_core_module.o] Ошибка 1 > > make[1]: Выход из каталога '/*****/nginx-1.15.8' > > make: *** [build] Ошибка 2 > > > > > Здравствуйте. > > Под поле uri_changes в ngx_http_request_t > (src/http/ngx_http_request.h) > отведено 4 бита: > unsigned uri_changes:4; > > Можете попробовать увеличить до 8 или поменять тип на uint8_t Владимир, помогло увеличение поля uri_changes до 8 бит, сборка успешная. Большое спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282935,282949#msg-282949 From chipitsine на gmail.com Thu Feb 7 20:08:44 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 8 Feb 2019 01:08:44 +0500 Subject: GeoIP In-Reply-To: <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> Message-ID: я один прозевал новость, что GeoLite всё ? )) https://support.maxmind.com/geolite-legacy-discontinuation-notice/ чт, 10 янв. 2019 г. в 19:47, Oleg A. Mamontov : > On Thu, Jan 10, 2019 at 08:53:12AM -0500, kycedbi wrote: > >> В данный момент рассматривается вопрос доработки ngx_http_geoip_module > >> для поддержки MaxMind GeoIP2, но пока это из области возможных планов > >> с неопределенными сроками. > >Благодарю за информацию. > >А в nginx, случаем, нету программы, с помощью которой можно было бы > ускорить > >реализацию некоторого функционала за донаты? > > Нет, программы такого формата у нас не существует, но качественные > предложения по дополнению функциональности от сообщества охотно > принимаются, подробнее можно прочитать тут: > http://nginx.org/ru/docs/contributing_changes.html > > -- > Cheers, > Oleg A. Mamontov > > mailto: oleg на mamontov.net > > skype: lonerr11 > cell: +7 (903) 798-1352 > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vladget на gmail.com Fri Feb 8 07:31:33 2019 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Fri, 8 Feb 2019 09:31:33 +0200 Subject: GeoIP In-Reply-To: References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> Message-ID: Угу, все в этом треде, используйте вторую версию... On Thu, Feb 7, 2019 at 10:09 PM Илья Шипицин wrote: > я один прозевал новость, что GeoLite всё ? )) > > https://support.maxmind.com/geolite-legacy-discontinuation-notice/ > > чт, 10 янв. 2019 г. в 19:47, Oleg A. Mamontov : > >> On Thu, Jan 10, 2019 at 08:53:12AM -0500, kycedbi wrote: >> >> В данный момент рассматривается вопрос доработки ngx_http_geoip_module >> >> для поддержки MaxMind GeoIP2, но пока это из области возможных планов >> >> с неопределенными сроками. >> >Благодарю за информацию. >> >А в nginx, случаем, нету программы, с помощью которой можно было бы >> ускорить >> >реализацию некоторого функционала за донаты? >> >> Нет, программы такого формата у нас не существует, но качественные >> предложения по дополнению функциональности от сообщества охотно >> принимаются, подробнее можно прочитать тут: >> http://nginx.org/ru/docs/contributing_changes.html >> >> -- >> Cheers, >> Oleg A. Mamontov >> >> mailto: oleg на mamontov.net >> >> skype: lonerr11 >> cell: +7 (903) 798-1352 >> _______________________________________________ >> 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 -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Feb 8 18:21:24 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 8 Feb 2019 23:21:24 +0500 Subject: GeoIP In-Reply-To: References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> Message-ID: а какое-то развитие родного модуля будет с учетом новостей от MaxMind? пт, 8 февр. 2019 г. в 12:31, Vladimir Getmanshchuk : > Угу, все в этом треде, используйте вторую версию... > > On Thu, Feb 7, 2019 at 10:09 PM Илья Шипицин wrote: > >> я один прозевал новость, что GeoLite всё ? )) >> >> https://support.maxmind.com/geolite-legacy-discontinuation-notice/ >> >> чт, 10 янв. 2019 г. в 19:47, Oleg A. Mamontov : >> >>> On Thu, Jan 10, 2019 at 08:53:12AM -0500, kycedbi wrote: >>> >> В данный момент рассматривается вопрос доработки ngx_http_geoip_module >>> >> для поддержки MaxMind GeoIP2, но пока это из области возможных планов >>> >> с неопределенными сроками. >>> >Благодарю за информацию. >>> >А в nginx, случаем, нету программы, с помощью которой можно было бы >>> ускорить >>> >реализацию некоторого функционала за донаты? >>> >>> Нет, программы такого формата у нас не существует, но качественные >>> предложения по дополнению функциональности от сообщества охотно >>> принимаются, подробнее можно прочитать тут: >>> http://nginx.org/ru/docs/contributing_changes.html >>> >>> -- >>> Cheers, >>> Oleg A. Mamontov >>> >>> mailto: oleg на mamontov.net >>> >>> skype: lonerr11 >>> cell: +7 (903) 798-1352 >>> _______________________________________________ >>> 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 > > > > -- > Yours sincerely, > Vladimir Getmanshchuk > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Feb 10 20:10:34 2019 From: nginx-forum на forum.nginx.org (gavrik) Date: Sun, 10 Feb 2019 15:10:34 -0500 Subject: =?UTF-8?B?bmdpbngg0L7RgtC+0LHRgNCw0LbQsNC10YIgaHRtbCDQutCw0Log0L7QsdGL0Yc=?= =?UTF-8?B?0L3Ri9C5INGC0LXQutGB0YIg0YHQviDQstGB0LXQvNC4IEh0dHAgaGVhZGVy?= =?UTF-8?B?cw==?= Message-ID: Добрый день! После сборки nginx отображает html страницу как текстовый файл со всеми полученными заголовками примерно вот такого вида: Date: Sun, 10 Feb 2019 19:33:52 GMT Content-Type: text/html Content-Length: 101 Connection: keep-alive test page some content Если собирать со стандартными файлами ngx_http_special_response.c и ngx_http_header_filter_module.c - всё работает как обычно. Я уже все перепробовал, всё перерыл, на сервер фолте спрашивал - никто не встречался с таким поведением. Вот параметры конфигурации: ./configure --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_secure_link_module ПОМОГИТЕ ПОЖАЛУЙСТА! Уже неделю я ищу ответа Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282969,282969#msg-282969 From nginx-forum на forum.nginx.org Sun Feb 10 20:27:58 2019 From: nginx-forum на forum.nginx.org (gavrik) Date: Sun, 10 Feb 2019 15:27:58 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: References: Message-ID: <47d46c1b41c19ab8293a30b0fc8b52fe.NginxMailingListRussian@forum.nginx.org> UP вносимые в файлы изменения не играют роли, потому что даже если поменять единственное слово Nginx начинает выдавать html как простой текстовый файл. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282969,282970#msg-282970 From jd на jdwuzhere.ru Sun Feb 10 21:40:53 2019 From: jd на jdwuzhere.ru (Vladimir Sopot) Date: Mon, 11 Feb 2019 00:40:53 +0300 Subject: =?UTF-8?B?cHJveHlfc3RvcmUgINC4INC/0LXRgNC10LzQtdC90L3Ri9C1?= Message-ID: <22B80189-51D3-440E-B7B9-75ABBBCBD00B@jdwuzhere.ru> Доброе утро! Строим вот такой просто кэшер уменьшенной статики. Для простоты добавляем это в nginx.conf.default resolver 8.8.8.8; server { listen *:80; server_name “~^cache-(\d).domain.ru$"; set $store_id $1; root /wwwroot/domain.ru/cache-$store_id/a/; location “~^.+\.jpg$" { error_page 404 /store$uri; } location "~^\/store/(.+\.jpg)$" { internal; # proxy_store /wwwroot/domain.ru/$store_id/a/$1; proxy_pass http://$host/resize/$1; } location "~^\/resize/(.+\.jpg)$" { image_filter crop 140 140; proxy_pass http://ori-$store_id.domain.ru/$1; proxy_set_header Cookie ''; proxy_set_header User-Agent ''; } } Всё работает, ничего не кэшируется. Раскомментирую proxy-store и получается ад: в $store_id попадает всё, что матчится (.+\.jpg) и складывается в '/wwwroot/domain.ru/cache-/path/to/original/jpg/request' , например. То есть $store_id почему-то перезаписывается следующим $1. Почему так и как это исправить, кроме как делать отдельный server{} для каждого $store_id? Спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Feb 11 01:04:07 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 11 Feb 2019 04:04:07 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlICDQuCDQv9C10YDQtdC80LXQvdC90YvQtQ==?= In-Reply-To: <22B80189-51D3-440E-B7B9-75ABBBCBD00B@jdwuzhere.ru> References: <22B80189-51D3-440E-B7B9-75ABBBCBD00B@jdwuzhere.ru> Message-ID: <20190211010407.GA1877@mdounin.ru> Hello! On Mon, Feb 11, 2019 at 12:40:53AM +0300, Vladimir Sopot wrote: > Строим вот такой просто кэшер уменьшенной статики. Для простоты > добавляем это в nginx.conf.default > > resolver 8.8.8.8; > > server { > listen *:80; > server_name “~^cache-(\d).domain.ru$"; > set $store_id $1; Так делать в сколько-нибудь сложных конфигурациях нельзя. После любого внутреннего перенаправления - серверные rewrite'ы отрабатают заново, и "set" будет использовать $1 от последнего выполневшегося регулярного выражения. И в вашем случае это будет совсем не регулярное выражение из server_name. Если хочется вытаскивать какую-либо информацию из server_name - это надо делать с помощью named captures, как-то так: server_name ~^cache-(?\d)\.domain\.ru$; [...] > Всё работает, ничего не кэшируется. Раскомментирую proxy-store и > получается ад: в $store_id попадает всё, что матчится (.+\.jpg) > и складывается в > '/wwwroot/domain.ru/cache-/path/to/original/jpg/request' > , > например. То есть $store_id почему-то перезаписывается следующим > $1. Почему так и как это исправить, кроме как делать отдельный > server{} для каждого $store_id? См. выше. Не надо использовать нумерованные выделения в сколько-нибудь сложных конструкциях. В декларативном конфиге nginx'а предугадать, какое регулярное выражение было выполнено последним - редко когда возможно, и подчас их их использование ведёт к появлению проблем в самых неожиданных местах. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Feb 11 01:05:31 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 11 Feb 2019 04:05:31 +0300 Subject: GeoIP In-Reply-To: References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> Message-ID: <20190211010531.GB1877@mdounin.ru> Hello! On Fri, Feb 08, 2019 at 11:21:24PM +0500, Илья Шипицин wrote: > а какое-то развитие родного модуля будет с учетом новостей от MaxMind? http://mailman.nginx.org/pipermail/nginx-devel/2019-February/011858.html [...] -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Feb 11 02:48:00 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 11 Feb 2019 05:48:00 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: References: Message-ID: <20190211024800.GC1877@mdounin.ru> Hello! On Sun, Feb 10, 2019 at 03:10:34PM -0500, gavrik wrote: > Добрый день! > > После сборки nginx отображает html страницу как текстовый файл со всеми > полученными заголовками примерно вот такого вида: > > Date: Sun, 10 Feb 2019 19:33:52 GMT > Content-Type: text/html > Content-Length: 101 > Connection: keep-alive > > > > test page > > > some content > > > > Если собирать со стандартными файлами ngx_http_special_response.c и > ngx_http_header_filter_module.c - всё работает как обычно. Я уже все > перепробовал, всё перерыл, на сервер фолте спрашивал - никто не встречался с > таким поведением. Судя по всему, вы пытаетесь убрать "Server: nginx" из ответов, и делаете это неправильно. Не стоит ожидать тут понимания и помощи в этом неблагородном деле. Оставьте файлы в их стандартном виде - и работать будет правильно, и совесть ваша будет чиста. Если хочется убрать версию из ответов - для этого есть директива server_tokens (хотя целосообразность даже этого действия, вообще говоря, сомнительна). А совсем убирать название сервера - не надо. Спасибо за понимание. -- Maxim Dounin http://mdounin.ru/ From jd на jdwuzhere.ru Mon Feb 11 06:10:34 2019 From: jd на jdwuzhere.ru (jd на jdwuzhere.ru) Date: Mon, 11 Feb 2019 09:10:34 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlICDQuCDQv9C10YDQtdC80LXQvdC90YvQtQ==?= In-Reply-To: <20190211010407.GA1877@mdounin.ru> References: <22B80189-51D3-440E-B7B9-75ABBBCBD00B@jdwuzhere.ru> <20190211010407.GA1877@mdounin.ru> Message-ID: Большое спасибо! > On 11 Feb 2019, at 04:04, Maxim Dounin wrote: > > Hello! > >> On Mon, Feb 11, 2019 at 12:40:53AM +0300, Vladimir Sopot wrote: >> >> Строим вот такой просто кэшер уменьшенной статики. Для простоты >> добавляем это в nginx.conf.default >> >> resolver 8.8.8.8; >> >> server { >> listen *:80; >> server_name “~^cache-(\d).domain.ru$"; >> set $store_id $1; > > Так делать в сколько-нибудь сложных конфигурациях нельзя. > > После любого внутреннего перенаправления - серверные rewrite'ы > отрабатают заново, и "set" будет использовать $1 от последнего > выполневшегося регулярного выражения. И в вашем случае это будет > совсем не регулярное выражение из server_name. > > Если хочется вытаскивать какую-либо информацию из server_name - > это надо делать с помощью named captures, как-то так: > > server_name ~^cache-(?\d)\.domain\.ru$; > > [...] > >> Всё работает, ничего не кэшируется. Раскомментирую proxy-store и >> получается ад: в $store_id попадает всё, что матчится (.+\.jpg) >> и складывается в >> '/wwwroot/domain.ru/cache-/path/to/original/jpg/request' >> , >> например. То есть $store_id почему-то перезаписывается следующим >> $1. Почему так и как это исправить, кроме как делать отдельный >> server{} для каждого $store_id? > > См. выше. Не надо использовать нумерованные выделения в > сколько-нибудь сложных конструкциях. В декларативном конфиге > nginx'а предугадать, какое регулярное выражение было выполнено > последним - редко когда возможно, и подчас их их использование > ведёт к появлению проблем в самых неожиданных местах. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx на kinetiksoft.com Mon Feb 11 07:41:23 2019 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Mon, 11 Feb 2019 10:41:23 +0300 Subject: GeoIP In-Reply-To: <20190211010531.GB1877@mdounin.ru> References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> <20190211010531.GB1877@mdounin.ru> Message-ID: <8f2ec9cd-c7ac-534b-059f-f749640118ac@kinetiksoft.com> Здравствуйте! Про конвертацию в формат доступный для geo прям свежая идея! Не подскажете, "выдюжит" geo-модуль geoip данные по городам? Там будет ~150 000 записей. Быть может у вас есть наработки для конвертации? С уважением, Иван. 11.02.2019 04:05, Maxim Dounin пишет: > Hello! > > On Fri, Feb 08, 2019 at 11:21:24PM +0500, Илья Шипицин wrote: > >> а какое-то развитие родного модуля будет с учетом новостей от MaxMind? > http://mailman.nginx.org/pipermail/nginx-devel/2019-February/011858.html > > [...] > From chipitsine на gmail.com Mon Feb 11 07:46:44 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 11 Feb 2019 12:46:44 +0500 Subject: GeoIP In-Reply-To: <8f2ec9cd-c7ac-534b-059f-f749640118ac@kinetiksoft.com> References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> <20190211010531.GB1877@mdounin.ru> <8f2ec9cd-c7ac-534b-059f-f749640118ac@kinetiksoft.com> Message-ID: пн, 11 февр. 2019 г. в 12:41, Иван : > Здравствуйте! > > Про конвертацию в формат доступный для geo прям свежая идея! Не > подскажете, "выдюжит" geo-модуль geoip данные по городам? Там будет ~150 > 000 записей. > > Быть может у вас есть наработки для конвертации? > https://github.com/m-messiah/ip2geo сдюжит. на наших бенчмарках он в два раза эффективнее, чем бинарный формат GeoIP > > С уважением, Иван. > > 11.02.2019 04:05, Maxim Dounin пишет: > > Hello! > > > > On Fri, Feb 08, 2019 at 11:21:24PM +0500, Илья Шипицин wrote: > > > >> а какое-то развитие родного модуля будет с учетом новостей от MaxMind? > > http://mailman.nginx.org/pipermail/nginx-devel/2019-February/011858.html > > > > [...] > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Feb 11 08:40:45 2019 From: nginx-forum на forum.nginx.org (gavrik) Date: Mon, 11 Feb 2019 03:40:45 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: <20190211024800.GC1877@mdounin.ru> References: <20190211024800.GC1877@mdounin.ru> Message-ID: <192cf95447a0626506395aaf97c50f5c.NginxMailingListRussian@forum.nginx.org> ой, я даже не подумал о лицензии. он же фришный вроде и свободен для тюнинга без дистрибьюции, по крайней мере раньше я именно так и думал Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282969,282980#msg-282980 From nginx-forum на forum.nginx.org Mon Feb 11 08:42:30 2019 From: nginx-forum на forum.nginx.org (gavrik) Date: Mon, 11 Feb 2019 03:42:30 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: <20190211024800.GC1877@mdounin.ru> References: <20190211024800.GC1877@mdounin.ru> Message-ID: <0fd30dce4b7ad44d0305a304ba78dbb0.NginxMailingListRussian@forum.nginx.org> хэш пади проверяется? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282969,282981#msg-282981 From chipitsine на gmail.com Mon Feb 11 12:20:49 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 11 Feb 2019 17:20:49 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: <192cf95447a0626506395aaf97c50f5c.NginxMailingListRussian@forum.nginx.org> References: <20190211024800.GC1877@mdounin.ru> <192cf95447a0626506395aaf97c50f5c.NginxMailingListRussian@forum.nginx.org> Message-ID: пн, 11 февр. 2019 г. в 13:40, gavrik : > ой, я даже не подумал о лицензии. он же фришный вроде и свободен для > тюнинга > без дистрибьюции, по крайней мере раньше я именно так и думал > Максим имел в виду, что модифицируя исходный код подобным образом, вы остаетесь с вашими правками один на один со стороны Nginx Inc, насколько я понял, не приветствуется модификация заголовка Server, потому что это портит статистику на http://news.netcraft.com > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,282969,282980#msg-282980 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Mon Feb 11 18:25:33 2019 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 11 Feb 2019 20:25:33 +0200 Subject: listen proxy_protocol Message-ID: Здравствуйте, All! Есть у нас такой документ: https://www.ietf.org/rfc/rfc2119.txt Key words for use in RFCs to Indicate Requirement Levels Для параметра proxy_protocol директивы listen в английской документации почему-то написано SHOULD, а в русской документации написано MUST. Насколько я понимаю, это есть ошибка в английской документации. Можно ли эту ошибку исправить, чтобы везде было написано MUST ? http://nginx.org/en/docs/http/ngx_http_core_module.html#listen The proxy_protocol parameter (1.5.12) allows specifying that all connections accepted on this port should use the PROXY protocol. http://nginx.org/ru/docs/http/ngx_http_core_module.html#listen Параметр proxy_protocol (1.5.12) указывает на то, что все соединения, принимаемые на данном порту, должны использовать протокол PROXY. -- Best regards, Gena From mdounin на mdounin.ru Mon Feb 11 18:40:00 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 11 Feb 2019 21:40:00 +0300 Subject: listen proxy_protocol In-Reply-To: References: Message-ID: <20190211184000.GF1877@mdounin.ru> Hello! On Mon, Feb 11, 2019 at 08:25:33PM +0200, Gena Makhomed wrote: > Есть у нас такой документ: https://www.ietf.org/rfc/rfc2119.txt > Key words for use in RFCs to Indicate Requirement Levels > > Для параметра proxy_protocol директивы listen в английской документации > почему-то написано SHOULD, а в русской документации написано MUST. > > Насколько я понимаю, это есть ошибка в английской документации. > Можно ли эту ошибку исправить, чтобы везде было написано MUST ? Ни в русской, ни в английской документации не используется нотация RFC 2119. Более того, RFC 8174 явно говорит нам, что "only UPPERCASE usage of the key words have the defined special meanings". В документации не используются слова SHOULD и/или MUST в верхнем регистре. Что до собственно текста английской документации, то он, кажется, достаточно однозначен, чтобы не вызывать вопросов. -- Maxim Dounin http://mdounin.ru/ From vladget на gmail.com Tue Feb 12 06:43:40 2019 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Tue, 12 Feb 2019 08:43:40 +0200 Subject: GeoIP In-Reply-To: <8f2ec9cd-c7ac-534b-059f-f749640118ac@kinetiksoft.com> References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> <20190211010531.GB1877@mdounin.ru> <8f2ec9cd-c7ac-534b-059f-f749640118ac@kinetiksoft.com> Message-ID: Работает в проде на нагрузках 1K rps. Проблем нет. On Mon, Feb 11, 2019 at 9:41 AM Иван wrote: > Здравствуйте! > > Про конвертацию в формат доступный для geo прям свежая идея! Не > подскажете, "выдюжит" geo-модуль geoip данные по городам? Там будет ~150 > 000 записей. > > Быть может у вас есть наработки для конвертации? > > С уважением, Иван. > > 11.02.2019 04:05, Maxim Dounin пишет: > > Hello! > > > > On Fri, Feb 08, 2019 at 11:21:24PM +0500, Илья Шипицин wrote: > > > >> а какое-то развитие родного модуля будет с учетом новостей от MaxMind? > > http://mailman.nginx.org/pipermail/nginx-devel/2019-February/011858.html > > > > [...] > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Feb 12 10:48:47 2019 From: nginx-forum на forum.nginx.org (gavrik) Date: Tue, 12 Feb 2019 05:48:47 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: References: Message-ID: <581c47770961f6288ce1bf5d4527eee9.NginxMailingListRussian@forum.nginx.org> В связи со спецификой сети для которой используется приложуха вряд ли сервер будет доступен дла анализа и статистики. Если софт распространяется под БСД лицензией из двух пунктов: /* * Copyright (C) 2002-2019 Igor Sysoev * Copyright (C) 2011-2019 Nginx, Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. */ То изменения заголовков ей не противоречит. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282969,283020#msg-283020 From annulen на yandex.ru Tue Feb 12 11:11:09 2019 From: annulen на yandex.ru (Konstantin Tokarev) Date: Tue, 12 Feb 2019 14:11:09 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: <581c47770961f6288ce1bf5d4527eee9.NginxMailingListRussian@forum.nginx.org> References: <581c47770961f6288ce1bf5d4527eee9.NginxMailingListRussian@forum.nginx.org> Message-ID: <2835811549969869@myt6-2fee75662a4f.qloud-c.yandex.net> 12.02.2019, 13:49, "gavrik" : > В связи со спецификой сети для которой используется приложуха вряд ли сервер > будет доступен дла анализа и статистики. Если софт распространяется под БСД > лицензией из двух пунктов: > > /* >  * Copyright (C) 2002-2019 Igor Sysoev >  * Copyright (C) 2011-2019 Nginx, Inc. >  * All rights reserved. >  * >  * Redistribution and use in source and binary forms, with or without >  * modification, are permitted provided that the following conditions >  * are met: >  * 1. Redistributions of source code must retain the above copyright >  * notice, this list of conditions and the following disclaimer. >  * 2. Redistributions in binary form must reproduce the above copyright >  * notice, this list of conditions and the following disclaimer in the >  * documentation and/or other materials provided with the distribution. > */ > > То изменения заголовков ей не противоречит. Но совесть все-таки надо иметь > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282969,283020#msg-283020 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum на forum.nginx.org Tue Feb 12 11:47:47 2019 From: nginx-forum на forum.nginx.org (gavrik) Date: Tue, 12 Feb 2019 06:47:47 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: <2835811549969869@myt6-2fee75662a4f.qloud-c.yandex.net> References: <2835811549969869@myt6-2fee75662a4f.qloud-c.yandex.net> Message-ID: Это вы в каком смысле? хD Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282969,283023#msg-283023 From maxim на nginx.com Tue Feb 12 12:10:45 2019 From: maxim на nginx.com (Maxim Konovalov) Date: Tue, 12 Feb 2019 15:10:45 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: References: <2835811549969869@myt6-2fee75662a4f.qloud-c.yandex.net> Message-ID: <3bf19b03-6f8b-8fb3-5e09-a6d38f193e90@nginx.com> Парни, давайте закончим. Модифицировать можно, лицензия позволяет практически все. Делать это или не делать -- up to you. Если это делается в целях секьюрити, то это сомнительное действие. -- Maxim Konovalov From nginx-forum на forum.nginx.org Tue Feb 12 12:20:44 2019 From: nginx-forum на forum.nginx.org (gavrik) Date: Tue, 12 Feb 2019 07:20:44 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQvtCx0YDQsNC20LDQtdGCIGh0bWwg0LrQsNC6INC+0LE=?= =?UTF-8?B?0YvRh9C90YvQuSDRgtC10LrRgdGCINGB0L4g0LLRgdC10LzQuCBIdHRwIGhl?= =?UTF-8?B?YWRlcnM=?= In-Reply-To: References: Message-ID: <179a0cfff3e414aaa637d150eedbc508.NginxMailingListRussian@forum.nginx.org> Господа, проблема решена. Спасибо за подсказки ) Всем удачи! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282969,283026#msg-283026 From lexore на gmail.com Tue Feb 12 14:06:09 2019 From: lexore на gmail.com (igor isaenko) Date: Tue, 12 Feb 2019 17:06:09 +0300 Subject: =?UTF-8?B?0JfQsNCy0LjRgdC40LzQvtGB0YLRjCDQt9C90LDRh9C10L3QuNC5INC00LjRgNC1?= =?UTF-8?B?0LrRgtC40LIgKl90aW1lb3V0INC+0YIg0LfQvdCw0YfQtdC90LjRjyB0aW1l?= =?UTF-8?B?cl9yZXNvbHV0aW9u?= Message-ID: Здравствуйте. Я заметил интересный момент и хотел бы уточнить, правильно ли я его понял. Похоже, работа директив директив *_timeout сильно зависит от значения timer_resolution. А точнее, лучше не ставить таймауты меньше или равными timer_resolution. При timer_resolution = 100ms, nginx узнает время раз в 100 миллисекунд. Т.е. грубо говоря, у него один момент времени "12:00:00 30:00,100", а второй момент времени - только "12:00:00 30:00,200". Все временные метки помечаются временем с точностью до 100 мс, потому что nginx округляет время до 100 мс. Длительность события получается, как с очередью в автобус - если упустил свой, жди следующего и получи +100мс к своей длительности. Если событие длится 2 мс, то время его работы для nginx = 0мс. Если длится 150 мс, оно засчитается, как 200мс. Но если nginx "узнал время" посреди какого-то события, получается интересная картина. Началось событие в 0,0 секунд, а закончилось в 0,1 секунд. Длительность этого события берется грубо = 100 мс. А если на это событие настроен timeout 100 мс, значит время кончилось и nginx прекращает это событие по таймауту. Получается, что любой таймаут должен быть больше, чем timer_resolution. Я наблюдал таймауты от nginx балансировщиков к nginx бекендов внутри одной локальной сети, что меня удивляло. Ведь большинство коннектов к бекенду выполняются не более, чем за 1-2 мс, а таймаут я выставил = 100. И я провел исследования. Я попробовал поставить 100мс для proxy_connect_timeout и timer_resolution стоял 100мс (это дефолтный). В итоге некоторые connect'ы к бекендам попадали на момент "тик-так" и для nginx их длительность превышала 100 мс (0.5 мс сам коннект + 100 мс от счетчика времени). Они отваливались по таймауту. Я поставил proxy_connect_timeout 101ms. Таймаутов стало чуть меньше, т.к. сюда попадали те, кто подключался за время "от 1мс до 2 мс" + 100 мс от счетчика. Я поставил proxy_connect_timeout 102ms. Тут таймауты резко пропали, т.к. большинство коннектов идет менее, чем за 2мс. Я поставил proxy_connect_timeout 100ms и timer_resolution 40 ms. Таймауты ушли. Не подскажите, правильно ли я нашел причину? Может быть, стоит указать в документации, что timer_resolution должен быть меньше, чем самый маленький *_timeout? -- С уважением, Игорь Исаенко lexore на gmail.com ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Tue Feb 12 14:24:09 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 12 Feb 2019 17:24:09 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQuNC80L7RgdGC0Ywg0LfQvdCw0YfQtdC90LjQuSDQtNC4?= =?UTF-8?B?0YDQtdC60YLQuNCyICpfdGltZW91dCDQvtGCINC30L3QsNGH0LXQvdC40Y8g?= =?UTF-8?B?dGltZXJfcmVzb2x1dGlvbg==?= In-Reply-To: References: Message-ID: <3937433.BBJF1po4Ix@vbart-workstation> On Tuesday 12 February 2019 17:06:09 igor isaenko wrote: [..] > Я поставил proxy_connect_timeout 100ms и timer_resolution 40 ms. > Таймауты ушли. [..] Зачем вообще устанавливать эту директиву? Я бы её вообще убрал из документации. -- Валентин Бартенев From lexore на gmail.com Tue Feb 12 14:31:10 2019 From: lexore на gmail.com (igor isaenko) Date: Tue, 12 Feb 2019 17:31:10 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQuNC80L7RgdGC0Ywg0LfQvdCw0YfQtdC90LjQuSDQtNC4?= =?UTF-8?B?0YDQtdC60YLQuNCyICpfdGltZW91dCDQvtGCINC30L3QsNGH0LXQvdC40Y8g?= =?UTF-8?B?dGltZXJfcmVzb2x1dGlvbg==?= In-Reply-To: <3937433.BBJF1po4Ix@vbart-workstation> References: <3937433.BBJF1po4Ix@vbart-workstation> Message-ID: В документации написано, что эта директива указывает, сколько раз в секунду дергать gettimeofday, чтобы не дергать её на каждый запрос. Она появилась в версии 0.3.х. Мне кажется, это отличная директива, просто нужно указать, на что она влияет. Если её убрать из конфига и оставить дефолтное значение (100мс), придется явно указать, что нельзя ставить директивам *_timeout значения <= 100 мс. А если её убрать только из документации, всем станет интересно, что это :) -- С уважением, Игорь Исаенко lexore на gmail.com ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Tue Feb 12 14:41:42 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 12 Feb 2019 17:41:42 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQuNC80L7RgdGC0Ywg0LfQvdCw0YfQtdC90LjQuSDQtNC4?= =?UTF-8?B?0YDQtdC60YLQuNCyICpfdGltZW91dCDQvtGCINC30L3QsNGH0LXQvdC40Y8g?= =?UTF-8?B?dGltZXJfcmVzb2x1dGlvbg==?= In-Reply-To: References: <3937433.BBJF1po4Ix@vbart-workstation> Message-ID: <1917028.dP5QmTjhK3@vbart-workstation> On Tuesday 12 February 2019 17:31:10 igor isaenko wrote: > В документации написано, что эта директива указывает, сколько раз в секунду > дергать gettimeofday, чтобы не дергать её на каждый запрос. > Она появилась в версии 0.3.х. > Мне кажется, это отличная директива, просто нужно указать, на что она > влияет. > > Если её убрать из конфига и оставить дефолтное значение (100мс), придется > явно указать, что нельзя ставить директивам *_timeout значения <= 100 мс. > А если её убрать только из документации, всем станет интересно, что это :) У неё нет дефолтного значения. По дефолту она выключена и лучше её оставить в таком состоянии. Смотрите: http://nginx.org/r/timer_resolution/ru На современных системах (последние 10+ лет?) вызовы gettimeofday и так очень дешевы. В свою очередь nginx их и так экономит, делает всего один вызов на итерацию цикла. Включение же timer_resolution в любое значение на Linux приводит к тому, что раз в заданный интервал начинает прилетать сигнал. Регулярно прилетающий сигнал может приводить к прерыванию выполняемых в этот момент системных вызовов. А то в свою очередь будет только негативно сказываеться на производительности. Кроме того это может приводить к разным спецэффектам в виде проявления очень редких багов, потенциально возможных в этом месте. -- Валентин Бартенев From lexore на gmail.com Tue Feb 12 14:49:12 2019 From: lexore на gmail.com (igor isaenko) Date: Tue, 12 Feb 2019 17:49:12 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQuNC80L7RgdGC0Ywg0LfQvdCw0YfQtdC90LjQuSDQtNC4?= =?UTF-8?B?0YDQtdC60YLQuNCyICpfdGltZW91dCDQvtGCINC30L3QsNGH0LXQvdC40Y8g?= =?UTF-8?B?dGltZXJfcmVzb2x1dGlvbg==?= In-Reply-To: <1917028.dP5QmTjhK3@vbart-workstation> References: <3937433.BBJF1po4Ix@vbart-workstation> <1917028.dP5QmTjhK3@vbart-workstation> Message-ID: Я понял вас. Похоже, в свое время пример значения в документации разлетелся по интернету, как рекомендуемое значение. То есть вы рекомендуете не указывать вообще эту директиву? -- Игорь Исаенко ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Feb 12 14:59:01 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 12 Feb 2019 17:59:01 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQuNC80L7RgdGC0Ywg0LfQvdCw0YfQtdC90LjQuSDQtNC4?= =?UTF-8?B?0YDQtdC60YLQuNCyICpfdGltZW91dCDQvtGCINC30L3QsNGH0LXQvdC40Y8g?= =?UTF-8?B?dGltZXJfcmVzb2x1dGlvbg==?= In-Reply-To: References: Message-ID: <20190212145855.GG1877@mdounin.ru> Hello! On Tue, Feb 12, 2019 at 05:06:09PM +0300, igor isaenko wrote: > Здравствуйте. > Я заметил интересный момент и хотел бы уточнить, правильно ли я его понял. > Похоже, работа директив директив *_timeout сильно зависит от значения > timer_resolution. > А точнее, лучше не ставить таймауты меньше или равными timer_resolution. > > При timer_resolution = 100ms, nginx узнает время раз в 100 миллисекунд. > Т.е. грубо говоря, у него один момент времени "12:00:00 30:00,100", а > второй момент времени - только "12:00:00 30:00,200". > Все временные метки помечаются временем с точностью до 100 мс, потому что > nginx округляет время до 100 мс. [...] > Не подскажите, правильно ли я нашел причину? > Может быть, стоит указать в документации, что timer_resolution должен быть > меньше, чем самый маленький *_timeout? Да, при использовании timer_resolution - погрешность определения времени будет от 0 до -timer_resolution, и соответственно погрешность определения длительности временного интревала - от 0 до timer_resolution. Очевидно, что при такой погрешности использовать таймауты, сравнимые с timer_resolution - не имеет смысла. Да и вообще использовать таймауты меньше 300 миллисекунд (NGX_TIMER_LAZY_DELAY) - не очень хорошая идея, nginx с ними не будет работать нормально. Так как при замене таймеров на близкие (отстающие менее чем на 300 миллисекунд от предыдущего установленного таймера) - nginx, в целях экономии ресурсов, таймеры на самом деле менять не будет. Соответственно для разовых таймаутов на connect - работать будет, а скажем для перевзводимых таймаутов на чтение - уже нет. Так как при обновлении таймаута nginx увидит различие меньше чем на 300 миллисекунд - и ничего не будет обновлять, а тем временем собственно таймаут случится. -- Maxim Dounin http://mdounin.ru/ From vbart на nginx.com Tue Feb 12 18:52:19 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 12 Feb 2019 21:52:19 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQuNC80L7RgdGC0Ywg0LfQvdCw0YfQtdC90LjQuSDQtNC4?= =?UTF-8?B?0YDQtdC60YLQuNCyICpfdGltZW91dCDQvtGCINC30L3QsNGH0LXQvdC40Y8g?= =?UTF-8?B?dGltZXJfcmVzb2x1dGlvbg==?= In-Reply-To: References: <1917028.dP5QmTjhK3@vbart-workstation> Message-ID: <33699068.ctDmYPl3bv@vbart-workstation> On Tuesday 12 February 2019 17:49:12 igor isaenko wrote: > Я понял вас. > Похоже, в свое время пример значения в документации разлетелся по > интернету, как рекомендуемое значение. > То есть вы рекомендуете не указывать вообще эту директиву? > Верно. Сколько-нибудь измеримую пользу от этой директивы бессмысленно ожидать, а на линуксе скорее даже будет больше вреда. -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed Feb 13 08:42:32 2019 From: nginx-forum на forum.nginx.org (xore) Date: Wed, 13 Feb 2019 03:42:32 -0500 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQuNC80L7RgdGC0Ywg0LfQvdCw0YfQtdC90LjQuSDQtNC4?= =?UTF-8?B?0YDQtdC60YLQuNCyICogdGltZW91dCDQvtGCINC30L3QsNGH0LXQvdC40Y8g?= =?UTF-8?B?dGltZXIgcmVzb2x1dGlvbg==?= In-Reply-To: <33699068.ctDmYPl3bv@vbart-workstation> References: <33699068.ctDmYPl3bv@vbart-workstation> Message-ID: Я понял, спасибо за объяснения. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283027,283048#msg-283048 From ano на bestmx.net Thu Feb 14 14:57:15 2019 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Thu, 14 Feb 2019 17:57:15 +0300 Subject: njs + json + \uXXXX Message-ID: Возможно ли в NJS получить строку {"text":"\u0431\u0435\u043b\u0438\u0431\u0435\u0440\u0434\u0430"} из такого JSON'a {"text":"белиберда"} JSON.parse прекрасно распознаёт такой JSON, а вот обратное преобразование как сделать, не соображу никак. >> s = JSON.stringify(JSON.parse('{"text":"\u0431\u0435\u043b\u0438\u0431\u0435\u0440\u0434\u0430"}')) '{"text":"белиберда"}' From xeioex на nginx.com Thu Feb 14 15:38:27 2019 From: xeioex на nginx.com (Dmitry Volyntsev) Date: Thu, 14 Feb 2019 18:38:27 +0300 Subject: njs + json + \uXXXX In-Reply-To: References: Message-ID: On 14.02.2019 17:57, Andrey Oktyabrskiy wrote: > Возможно ли в NJS получить строку > {"text":"\u0431\u0435\u043b\u0438\u0431\u0435\u0440\u0434\u0430"} > > из такого JSON'a > {"text":"белиберда"} > > JSON.parse прекрасно распознаёт такой JSON, а вот обратное > преобразование как сделать, не соображу никак. > > >> s = > JSON.stringify(JSON.parse('{"text":"\u0431\u0435\u043b\u0438\u0431\u0435\u0440\u0434\u0430"}')) > > '{"text":"белиберда"}' А какую задачу вы пытаетесь решить? Ничего готово не припоминаю, но можно, в качестве развлечения, написать такую функцию : function uniсode_escape(s) { : var codes = []; : for (var i = 0; i < s.length; i++) { : codes.push(s.codePointAt(i).toString(16).padStart(4, '0')); : }; : return '\\u'+codes.join('\\u'); : } : : >> unicode_escape('белиберда') : '\\u0431\\u0435\\u043b\\u0438\\u0431\\u0435\\u0440\\u0434\\u0430' : JSON.parse("\"" + unicode_escape('белиберда') + "\"") : 'белиберда' > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From artem.povaluhin на gmail.com Thu Feb 14 19:41:39 2019 From: artem.povaluhin на gmail.com (Artem S. Povalyukhin) Date: Thu, 14 Feb 2019 22:41:39 +0300 Subject: njs + json + \uXXXX In-Reply-To: References: Message-ID: <6f7bc92c-6c21-ec1e-a94e-ff78dfd12684@gmail.com> Hi! On 2/14/19 5:57 PM, Andrey Oktyabrskiy wrote: > Возможно ли в NJS получить строку > {"text":"\u0431\u0435\u043b\u0438\u0431\u0435\u0440\u0434\u0430"} > > из такого JSON'a > {"text":"белиберда"} > > JSON.parse прекрасно распознаёт такой JSON, а вот обратное > преобразование как сделать, не соображу никак. > Ввиду особенностей работы njs со строками, немного не тривиально (для случая наличия смайликов в тексте и тп): $ cat unicode.js // @see http://www.json.org/JSON_checker/utf8_to_utf16.c var u8 = '\\u0444\\u044b\\u0432\\u0430 asdf \\ud83d\\udc4d'; var a16 = []; var enc = function(c) { return '\\u' + c.toString(16).padStart(4, '0'); }; for (var i = 0; i < u8.length; ++i) { var c = u8.codePointAt(i); if (c < 0x7f) { a16.push(u8[i]); } else if (c < 0x10000) { a16.push(enc(c)); } else { c -= 0x10000; a16.push(enc(0xd800 | (c >> 10))); a16.push(enc(0xdc00 | (c & 0x3ff))); } } var u16 = a16.join(''); console.log('encoded: ', u16); console.log('parsed: ', JSON.parse('"' + u16 + '"')); $ njs unicode.js 'encoded: ' '\\u0444\\u044b\\u0432\\u0430 asdf \\ud83d\\udc4d' 'parsed: ' 'фыва asdf 👍' wbr, Artem From ano на bestmx.net Thu Feb 14 21:07:07 2019 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Fri, 15 Feb 2019 00:07:07 +0300 Subject: njs + json + \uXXXX In-Reply-To: References: Message-ID: <519c7646-2aeb-54ed-bead-3bfd48a56349@bestmx.net> On 14.02.2019 18:38, Dmitry Volyntsev wrote: > On 14.02.2019 17:57, Andrey Oktyabrskiy wrote: >> Возможно ли в NJS получить строку >> {"text":"\u0431\u0435\u043b\u0438\u0431\u0435\u0440\u0434\u0430"} >> >> из такого JSON'a >> {"text":"белиберда"} >> >> JSON.parse прекрасно распознаёт такой JSON, а вот обратное >> преобразование как сделать, не соображу никак. >> >>  >> s = >> JSON.stringify(JSON.parse('{"text":"\u0431\u0435\u043b\u0438\u0431\u0435\u0440\u0434\u0430"}')) >> >> '{"text":"белиберда"}' > > А какую задачу вы пытаетесь решить? Пытаюсь использовать чужой API, который принимает только такие строки. Требование выглядит странным, но повлиять на это поведение я никак не могу. > Ничего готово не припоминаю, но можно, в качестве развлечения, написать > такую функцию Я думал, может со stringify какой-то фокус можно сделать... > : function uniсode_escape(s) { > :   var codes = []; > :   for (var i = 0; i < s.length; i++) { > :       codes.push(s.codePointAt(i).toString(16).padStart(4, '0')); > :   }; > :   return '\\u'+codes.join('\\u'); > : } > : > : >> unicode_escape('белиберда') > : '\\u0431\\u0435\\u043b\\u0438\\u0431\\u0435\\u0440\\u0434\\u0430' > : JSON.parse("\"" + unicode_escape('белиберда') + "\"") > : 'белиберда' Спасибо! Для такой экзотической задачи очень даже адекватное решение. From ano на bestmx.net Thu Feb 14 21:13:19 2019 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Fri, 15 Feb 2019 00:13:19 +0300 Subject: njs + json + \uXXXX In-Reply-To: <6f7bc92c-6c21-ec1e-a94e-ff78dfd12684@gmail.com> References: <6f7bc92c-6c21-ec1e-a94e-ff78dfd12684@gmail.com> Message-ID: <8403959a-19ff-1563-5ec4-6684221a8b79@bestmx.net> On 14.02.2019 22:41, Artem S. Povalyukhin wrote: > Hi! > > On 2/14/19 5:57 PM, Andrey Oktyabrskiy wrote: >> Возможно ли в NJS получить строку >> {"text":"\u0431\u0435\u043b\u0438\u0431\u0435\u0440\u0434\u0430"} >> >> из такого JSON'a >> {"text":"белиберда"} >> >> JSON.parse прекрасно распознаёт такой JSON, а вот обратное >> преобразование как сделать, не соображу никак. >> > > Ввиду особенностей работы njs со строками, немного не тривиально > (для случая наличия смайликов в тексте и тп): > > $ cat unicode.js > // @see http://www.json.org/JSON_checker/utf8_to_utf16.c > var u8 = '\\u0444\\u044b\\u0432\\u0430 asdf \\ud83d\\udc4d'; > var a16 = []; > var enc = function(c) { > return '\\u' + c.toString(16).padStart(4, '0'); > }; > > for (var i = 0; i < u8.length; ++i) { > var c = u8.codePointAt(i); > if (c < 0x7f) { > a16.push(u8[i]); > } else if (c < 0x10000) { > a16.push(enc(c)); > } else { > c -= 0x10000; > a16.push(enc(0xd800 | (c >> 10))); > a16.push(enc(0xdc00 | (c & 0x3ff))); > } > } > > var u16 = a16.join(''); > > console.log('encoded: ', u16); > console.log('parsed: ', JSON.parse('"' + u16 + '"')); > > $ njs unicode.js > 'encoded: ' '\\u0444\\u044b\\u0432\\u0430 asdf \\ud83d\\udc4d' > 'parsed: ' 'фыва asdf 👍' Спасибо. Смайликов точно не будет. Только печатные символы. From artem.povaluhin на gmail.com Thu Feb 14 21:31:52 2019 From: artem.povaluhin на gmail.com (Artem S. Povalyukhin) Date: Fri, 15 Feb 2019 00:31:52 +0300 Subject: njs + json + \uXXXX In-Reply-To: <8403959a-19ff-1563-5ec4-6684221a8b79@bestmx.net> References: <6f7bc92c-6c21-ec1e-a94e-ff78dfd12684@gmail.com> <8403959a-19ff-1563-5ec4-6684221a8b79@bestmx.net> Message-ID: On 2/15/19 12:13 AM, Andrey Oktyabrskiy wrote: > On 14.02.2019 22:41, Artem S. Povalyukhin wrote: ... >> $ cat unicode.js - var u8 = '\\u0444\\u044b\\u0432\\u0430 asdf \\ud83d\\udc4d'; + var u8 = 'фыва asdf 👍'; > Спасибо. > > Смайликов точно не будет. Только печатные символы. есть еще китайский язык ). все-таки желательно проверять, что кодепоинт < 0x10000 чтобы не получить битый json. wbr, Artem From ano на bestmx.net Fri Feb 15 05:33:38 2019 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Fri, 15 Feb 2019 08:33:38 +0300 Subject: njs + json + \uXXXX In-Reply-To: References: <6f7bc92c-6c21-ec1e-a94e-ff78dfd12684@gmail.com> <8403959a-19ff-1563-5ec4-6684221a8b79@bestmx.net> Message-ID: <8e57eeb7-fdca-1f38-0dd9-d6388b047818@bestmx.net> On 15.02.2019 0:31, Artem S. Povalyukhin wrote: > > > On 2/15/19 12:13 AM, Andrey Oktyabrskiy wrote: >> On 14.02.2019 22:41, Artem S. Povalyukhin wrote: > ... >>> $ cat unicode.js > - var u8 = '\\u0444\\u044b\\u0432\\u0430 asdf \\ud83d\\udc4d'; > + var u8 = 'фыва asdf 👍'; > >> Спасибо. >> >> Смайликов точно не будет. Только печатные символы. > > есть еще китайский язык ). Не, там только печатные :-) > все-таки желательно проверять, что кодепоинт < 0x10000 > чтобы не получить битый json. Согласен, лишняя проверка редко когда вредит. From chipitsine на gmail.com Sat Feb 16 11:38:53 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 16 Feb 2019 16:38:53 +0500 Subject: =?UTF-8?B?0L/RgNC+0YTQuNC70LjRgNC+0LLQsNC90LjQtSBjcHU6INC+0LHRgdGD0LTQuNC8?= =?UTF-8?B?ID8=?= Message-ID: привет! посмотрел в вывод http://nginx.org/ru/docs/ngx_google_perftools_module.html получил такую картинку https://yadi.sk/i/ai-sUyCK3HasQA вопрос - это нормально, что компрессия занимает СТОЛЬКО ? компрессия включалась без выкрутасов gzip on; gzip_types text/css text/javascript application/x-javascript application/javascript text/plain text/xml text/x-component text/json application/json application/octet-stream application/atom image/svg+xml; gzip_min_length 500; gzip_disable msie6; из недефолтных настроек proxy_buffering off; (проверю, не влияет ли она). поделитесь best practice по профилированию ? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From annulen на yandex.ru Sun Feb 17 09:44:02 2019 From: annulen на yandex.ru (Konstantin Tokarev) Date: Sun, 17 Feb 2019 12:44:02 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtGE0LjQu9C40YDQvtCy0LDQvdC40LUgY3B1OiDQvtCx0YHRg9C0?= =?UTF-8?B?0LjQvCA/?= In-Reply-To: References: Message-ID: <3403031550396642@iva1-16f33c6a446b.qloud-c.yandex.net> 16.02.2019, 14:39, "Илья Шипицин" : > привет! > > посмотрел в вывод http://nginx.org/ru/docs/ngx_google_perftools_module.html > получил такую картинку > > https://yadi.sk/i/ai-sUyCK3HasQA > > вопрос - это нормально, что компрессия занимает СТОЛЬКО ? А почему бы и нет? Компрессия - это одна из немногих задач в веб-сервере, которая упирается в CPU, а не в I/O. Другая такая задача - блочный шифр в TLS, но здесь видно, что используется AES-NI, что снижает нагрузку > > компрессия включалась без выкрутасов > >     gzip on; >     gzip_types text/css text/javascript application/x-javascript application/javascript text/plain text/xml text/x-component text/json application/json application/octet-stream application/atom image/svg+xml; >     gzip_min_length 500; >     gzip_disable msie6; > > из недефолтных настроек > > proxy_buffering off; > > (проверю, не влияет ли она). > > поделитесь best practice по профилированию ? > , > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru --  Regards, Konstantin From mdounin на mdounin.ru Mon Feb 18 12:12:23 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 18 Feb 2019 15:12:23 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtGE0LjQu9C40YDQvtCy0LDQvdC40LUgY3B1OiDQvtCx0YHRg9C0?= =?UTF-8?B?0LjQvCA/?= In-Reply-To: References: Message-ID: <20190218121223.GQ1877@mdounin.ru> Hello! On Sat, Feb 16, 2019 at 04:38:53PM +0500, Илья Шипицин wrote: > привет! > > посмотрел в вывод http://nginx.org/ru/docs/ngx_google_perftools_module.html > получил такую картинку > > https://yadi.sk/i/ai-sUyCK3HasQA > > > вопрос - это нормально, что компрессия занимает СТОЛЬКО ? Да. Компрессия - один из наиболее серьёзных потребитилей процессорного времени, хуже - только SSL handshake'и. И, в частности, именно по этой причине gzip_comp_level - по умолчанию 1. > компрессия включалась без выкрутасов > > gzip on; > gzip_types text/css text/javascript application/x-javascript > application/javascript text/plain text/xml text/x-component text/json > application/json application/octet-stream application/atom image/svg+xml; > gzip_min_length 500; > gzip_disable msie6; Сжатие application/octet-stream - это обычно не лучший выбор, если ресурсы процессора важны. > из недефолтных настроек > > proxy_buffering off; > > (проверю, не влияет ли она). Влияет, сжатие работает более эффективно, если на вход подаются большие блоки (и не делается flush после каждой операции). Но в общей картине это влияние не принципиально, так или иначе сжатие требует много процессора. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Feb 18 19:03:32 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 19 Feb 2019 00:03:32 +0500 Subject: =?UTF-8?B?UmU6INC/0YDQvtGE0LjQu9C40YDQvtCy0LDQvdC40LUgY3B1OiDQvtCx0YHRg9C0?= =?UTF-8?B?0LjQvCA/?= In-Reply-To: <20190218121223.GQ1877@mdounin.ru> References: <20190218121223.GQ1877@mdounin.ru> Message-ID: пн, 18 февр. 2019 г. в 17:12, Maxim Dounin : > Hello! > > On Sat, Feb 16, 2019 at 04:38:53PM +0500, Илья Шипицин wrote: > > > привет! > > > > посмотрел в вывод > http://nginx.org/ru/docs/ngx_google_perftools_module.html > > получил такую картинку > > > > https://yadi.sk/i/ai-sUyCK3HasQA > > > > > > вопрос - это нормально, что компрессия занимает СТОЛЬКО ? > > Да. Компрессия - один из наиболее серьёзных потребитилей > процессорного времени, хуже - только SSL handshake'и. > ну то есть, поскольку при штатном использовании массово используются кипэлайвы и abbrevated handshakes, то из-за этого SSL хендшейки незначительны? > > И, в частности, именно по этой причине gzip_comp_level - по > умолчанию 1. > > это мы не трогали > > компрессия включалась без выкрутасов > > > > gzip on; > > gzip_types text/css text/javascript application/x-javascript > > application/javascript text/plain text/xml text/x-component text/json > > application/json application/octet-stream application/atom image/svg+xml; > > gzip_min_length 500; > > gzip_disable msie6; > > Сжатие application/octet-stream - это обычно не лучший выбор, если > ресурсы процессора важны. > сложно вспомнить, зачем это было сделано. но кажется, что среди общего трафика того сервера, который профилировался, application/octet-stream не должно быть много > > > из недефолтных настроек > > > > proxy_buffering off; > > > > (проверю, не влияет ли она). > > Влияет, сжатие работает более эффективно, если на вход подаются > большие блоки (и не делается flush после каждой операции). Но в > общей картине это влияние не принципиально, так или иначе сжатие > требует много процессора. > любопытства ради проверю с выключенной и включенной буферизацией > > -- > 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 Tue Feb 19 15:15:17 2019 From: nginx-forum на forum.nginx.org (darksmoke) Date: Tue, 19 Feb 2019 10:15:17 -0500 Subject: =?UTF-8?B?0JrQsNC6INC+0YLQvNC10L3QuNGC0Ywg0LfQsNC/0YDQvtGBPw==?= Message-ID: Добрый день Помогите, пожалуйста, разобраться как это работает. Есть фронт который шлет запрос на бэк (Клиент - nginx - бэк). Клиент послал запрос, nginx его спроксировал на бэк. На бэки запрос курится что то делает очень долго. Клиент уже не хочет ждать и уходит. Как разорвать это соединение на бэке? Т.е. Клиент устоновил соединение с nginx, а nginx с бэком. Клиент разорвал соединение с nginx, а nginx продолжает ждать запрос от бэка, а вот как раз хочу что бы не продолжал. Что бы разорвал соединение. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283076,283076#msg-283076 From mdounin на mdounin.ru Tue Feb 19 17:30:16 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 19 Feb 2019 20:30:16 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGC0LzQtdC90LjRgtGMINC30LDQv9GA0L7RgT8=?= In-Reply-To: References: Message-ID: <20190219173016.GW1877@mdounin.ru> Hello! On Tue, Feb 19, 2019 at 10:15:17AM -0500, darksmoke wrote: > Добрый день > Помогите, пожалуйста, разобраться как это работает. > Есть фронт который шлет запрос на бэк (Клиент - nginx - бэк). > Клиент послал запрос, nginx его спроксировал на бэк. На бэки запрос курится > что то делает очень долго. Клиент уже не хочет ждать и уходит. Как разорвать > это соединение на бэке? > Т.е. Клиент устоновил соединение с nginx, а nginx с бэком. Клиент разорвал > соединение с nginx, а nginx продолжает ждать запрос от бэка, а вот как раз > хочу что бы не продолжал. Что бы разорвал соединение. По умолчанию nginx разрывает соединение с бэкендом, если клиент закрывает соединение. И пишет при этом в лог на уровне info: ... client prematurely closed connection, so upstream connection is closed too ... Не разрывать может либо если вы об этом явно попросили в конфигурации (http:///nginx.org/r/proxy_ignore_client_abort), либо если включено кэширование/сохранение ответов (так как в этом случае ответ будет полезен даже если клиент закрыл соединение). Соответственно если ваша проблема в том, что nginx не закрывает соединение - для решения достаточно убрать настройки, которые не позволяют nginx'у это делать. Куда чаще, к сожалению, встречается ситуация, когда nginx соединение закрывает, а вот бэкенд никак не умеет это детектировать и обрабатывать. Но тут от nginx'а уже ничего не зависит. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Feb 20 12:08:13 2019 From: nginx-forum на forum.nginx.org (waster) Date: Wed, 20 Feb 2019 07:08:13 -0500 Subject: =?UTF-8?B?0J/QtdGA0LjQvtC00LjRh9C10YHQutC40LUg0L/RgNC+0LHQu9C10LzRiyDQv9C+?= =?UTF-8?B?0LQg0L3QsNCz0YDRg9C30LrQvtC5?= Message-ID: Добрый день, Для раздачи HLS используется схема из двух серверов cache-origin, ts-чанки отдаются cache, а все запросы на m3u8-плейлисты проксируются на origin. На cache настроено проксирование с keepalive. Кусок конфига cache: -------------------------------------------------------------------------------------------------- limit_req_zone $binary_remote_addr zone=hlslimit:10m rate=100r/s; proxy_http_version 1.1; upstream hls01 { server X.X.X.X:80 fail_timeout=3s max_fails=3; keepalive 500; keepalive_timeout 10; keepalive_requests 100000; } ... location ~* \.ts$ { proxy_set_header Host "XXX.XXXXXXX.ru"; proxy_set_header X-Cache-Host $host; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache e_v; proxy_cache_key $host$uri$is_args$args; proxy_cache_valid any 1m; proxy_cache_use_stale updating; proxy_cache_lock on; proxy_pass http://hls01; add_header X-Proxy-Cache $upstream_cache_status; } ... location ~* \.m3u8$ { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Connection ""; proxy_set_header Host "XXX.XXXXXX.ru"; proxy_set_header X-Cache-Host $host; proxy_cache off; expires -1; limit_req zone=hlslimit burst=50 nodelay; proxy_pass http://hls01; } -------------------------------------------------------------------------------------------------- Кусок конфига origin: -------------------------------------------------------------------------------------------------- http { ... sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 15; ... } -------------------------------------------------------------------------------------------------- У cache 10G интерфейс, sysctl настроен. Под нагрузкой периодически наблюдается такая картина: https://imgur.com/a/B3fOWg7 По понятным причинам также резко подпрыгивает кол-во открытых файловых дескрипторов. В error.log на cache в эти моменты иногда (но не всегда) видны несколько сообщений: -------------------------------------------------------------------------------------------------- *137407049 upstream timed out (110: Connection timed out) while connecting to upstream... ... *143796692 limiting requests, excess: 50.400 by zone "hlslimit"... -------------------------------------------------------------------------------------------------- В error.log на origin вообще тишина. Подскажите, пожуалуйста, в чем может быть проблема? Только лишь в иногда нестабильной сетевой связности между cache и origin, всплесками запросов? Уже множество параметров было перенастроено как на origin, так и на cache, но успехов в повышении стабильности это не дало. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283083,283083#msg-283083 From bgx на protva.ru Wed Feb 20 12:49:10 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 20 Feb 2019 15:49:10 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: References: Message-ID: <20190220124910.GF3053@protva.ru> On Wed, Feb 20, 2019 at 07:08:13AM -0500, waster wrote: > Под нагрузкой периодически наблюдается такая картина: > https://imgur.com/a/B3fOWg7 > По понятным причинам также резко подпрыгивает кол-во открытых файловых > дескрипторов. > > В error.log на cache в эти моменты иногда (но не всегда) видны несколько > сообщений: > -------------------------------------------------------------------------------------------------- > > *137407049 upstream timed out (110: Connection timed out) while connecting > to upstream... > ... > *143796692 limiting requests, excess: 50.400 by zone "hlslimit"... > -------------------------------------------------------------------------------------------------- > > В error.log на origin вообще тишина. > > Подскажите, пожуалуйста, в чем может быть проблема? Только лишь в иногда > нестабильной сетевой связности между cache и origin, всплесками запросов? > Уже множество параметров было перенастроено как на origin, так и на cache, > но успехов в повышении стабильности это не дало. Наблюдаемые симптомы (увеличение времени ожиданий read/write и таймауты на стороне клиента, увеличение к-ва файловых дескрипторов) вполне укладываются в гипотезу о том, что потерялась связь между cache и origin. На графике "Network traffic on enp7s0f0" явно виден провал по трафику. Поэтому нет смысла выдумывать другие возможные причины, пока не изучены сетевые проблемы между cache и origin. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Wed Feb 20 15:56:01 2019 From: nginx-forum на forum.nginx.org (waster) Date: Wed, 20 Feb 2019 10:56:01 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <20190220124910.GF3053@protva.ru> References: <20190220124910.GF3053@protva.ru> Message-ID: <1cd26db2b3131e4666c8f4bf0c230e81.NginxMailingListRussian@forum.nginx.org> Да, спасибо, я тоже думаю, что это первое на что надо обратить внимание, поставил ежеминутный mtr до origin в cron, но интересно, что это возникает только в моменты пиковой нагрузки, и приблизительно в одно и то же время. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283083,283092#msg-283092 From nginx-forum на forum.nginx.org Wed Feb 20 16:40:56 2019 From: nginx-forum на forum.nginx.org (trace) Date: Wed, 20 Feb 2019 11:40:56 -0500 Subject: HTTP keep-alive Message-ID: Привет. Подскажите про keep-alive Пробовал вот так proxy_http_version 1.1; proxy_set_header Connection ""; или вот так proxy_set_header Connection "keep-alive"; Ожидал увидеть что nginx будет проксировать в одном tcp.stream, однако Nginx отправляет FIN. Соответственно каждый http запрос - новое окно ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283095,283095#msg-283095 From mdounin на mdounin.ru Wed Feb 20 16:43:16 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 20 Feb 2019 19:43:16 +0300 Subject: HTTP keep-alive In-Reply-To: References: Message-ID: <20190220164316.GZ1877@mdounin.ru> Hello! On Wed, Feb 20, 2019 at 11:40:56AM -0500, trace wrote: > Привет. > Подскажите про keep-alive > > Пробовал вот так > > proxy_http_version 1.1; > proxy_set_header Connection ""; > > или вот так > > proxy_set_header Connection "keep-alive"; > > Ожидал увидеть что nginx будет проксировать в одном tcp.stream, однако Nginx > отправляет FIN. > Соответственно каждый http запрос - новое окно ? http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Feb 21 04:52:58 2019 From: nginx-forum на forum.nginx.org (trace) Date: Wed, 20 Feb 2019 23:52:58 -0500 Subject: HTTP keep-alive In-Reply-To: <20190220164316.GZ1877@mdounin.ru> References: <20190220164316.GZ1877@mdounin.ru> Message-ID: Для upstream прописывал keepalive. Видимо моя проблема, не дождался применения нового конфига. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283095,283100#msg-283100 From nginx-forum на forum.nginx.org Thu Feb 21 12:06:11 2019 From: nginx-forum на forum.nginx.org (waster) Date: Thu, 21 Feb 2019 07:06:11 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <20190220124910.GF3053@protva.ru> References: <20190220124910.GF3053@protva.ru> Message-ID: <23ef189e2f1b69a778cc47b692f0eabb.NginxMailingListRussian@forum.nginx.org> Все-таки странно, mtr не показывает проблем с пингом до ориджина во время таких скачков. Получается, что такое приличное падение трафика в эти моменты означает, что и чанки не отдаются в том числе, хотя для кэша установлено inactive=1m. Это либо недоступен вообще сам cache, либо затыкается nginx на cache? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283083,283105#msg-283105 From bgx на protva.ru Thu Feb 21 12:39:27 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 21 Feb 2019 15:39:27 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <23ef189e2f1b69a778cc47b692f0eabb.NginxMailingListRussian@forum.nginx.org> References: <20190220124910.GF3053@protva.ru> <23ef189e2f1b69a778cc47b692f0eabb.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190221123926.GA3062@protva.ru> On Thu, Feb 21, 2019 at 07:06:11AM -0500, waster wrote: > Все-таки странно, mtr не показывает проблем с пингом до ориджина во время > таких скачков. Получается, что такое приличное падение трафика в эти моменты > означает, что и чанки не отдаются в том числе, хотя для кэша установлено > inactive=1m. Это либо недоступен вообще сам cache, либо затыкается nginx на > cache? Вы показывали таймауты клиента, там скорее всего есть таймауты не только на передачу данных, но и на установку соединений. Запишите дамп трафика с обеих сторон, включающий лишь пакеты хендшейка (SYN, SYN-ACK), их будет немного. Там нужно будет найти эпизоды множественных ретрансмиссий, когда их найдёте, посмотрите на аналогичный дамп с другой стороны. Станет ясно, есть ли потери в канале связи или же пакеты теряются после прихода на сервер. В зависимости от результата нужно будет либо с каналом разбираться, либо с настройками сервера. -- Eugene Berdnikov From self на alaz.me Thu Feb 21 13:31:42 2019 From: self на alaz.me (Alexander Azarov) Date: Thu, 21 Feb 2019 15:31:42 +0200 Subject: =?UTF-8?B?Z3ppcCDQvtGC0LLQtdGCINC+0YIgdXBzdHJlYW0g4oaSIFNTSSDihpIg8J+Sow==?= Message-ID: Здравствуйте! Мне кажется, что я уже второй раз на это напарываюсь, но правда так и не смог вспомнить когда был предыдущий. Если ответ апстрима в gzip, то вставляя его как SSI получается мусор в результирующем документе. Я смог найти краткий совет так не делать от 2013 г тут: https://forum.nginx.org/read.php?2,244299,244303#msg-244303 Сейчас 2019 г, я использую Nginx 1.14, и словил то же самое. Вопросы: 1. Есть ли это в документации? 2. Баг или фича? С уважением, Александр ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From boco на ufanet.ru Thu Feb 21 13:39:46 2019 From: boco на ufanet.ru (damir bikmuhametov) Date: Thu, 21 Feb 2019 18:39:46 +0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <23ef189e2f1b69a778cc47b692f0eabb.NginxMailingListRussian@forum.nginx.org> References: <20190220124910.GF3053@protva.ru> <23ef189e2f1b69a778cc47b692f0eabb.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190221133945.GG37278@ufanet.ru> On Thu, Feb 21, 2019 at 07:06:11AM -0500, waster wrote: > Все-таки странно, mtr не показывает проблем с пингом до ориджина во время > таких скачков "conntrack: table full, dropping packet"? -- boco From nginx-forum на forum.nginx.org Thu Feb 21 13:55:30 2019 From: nginx-forum на forum.nginx.org (waster) Date: Thu, 21 Feb 2019 08:55:30 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <20190221133945.GG37278@ufanet.ru> References: <20190221133945.GG37278@ufanet.ru> Message-ID: <79797b7c97c27cc42173c2049a7d770d.NginxMailingListRussian@forum.nginx.org> Нет, в логах чисто, да и options nf_conntrack hashsize=32768. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283083,283110#msg-283110 From mdounin на mdounin.ru Thu Feb 21 14:11:31 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 21 Feb 2019 17:11:31 +0300 Subject: =?UTF-8?B?UmU6IGd6aXAg0L7RgtCy0LXRgiDQvtGCIHVwc3RyZWFtIOKGkiBTU0kg4oaSIA==?= =?UTF-8?B?8J+Sow==?= In-Reply-To: References: Message-ID: <20190221141131.GC1877@mdounin.ru> Hello! On Thu, Feb 21, 2019 at 03:31:42PM +0200, Alexander Azarov wrote: > Мне кажется, что я уже второй раз на это напарываюсь, но правда так и не > смог вспомнить когда был предыдущий. Если ответ апстрима в gzip, то > вставляя его как SSI получается мусор в результирующем документе. Я смог > найти краткий совет так не делать от 2013 г тут: > https://forum.nginx.org/read.php?2,244299,244303#msg-244303 По ссылке проблема немного другая - исходный ответ бэкенда в gzip, и из-за этого SSI не может его обработать. У вас же ответ на SSI-команду include в gzip. > Сейчас 2019 г, я использую Nginx 1.14, и словил то же самое. > > Вопросы: > 1. Есть ли это в документации? > 2. Баг или фича? SSI include вставляет в ответ то, что получено в результате выполнения подзапроса - в вашем случае то, что прислал бэкенд. Если вы не хотите, чтобы в соответствующем месте ответа был gzip - сделайте так, чтобы бэкенд такого не присылал. Обычно этого легко добиться с помощью конфигурирования бэкенда и/или выпиливанием заголовка Accept-Encoding с помощью директивы proxy_set_header. Добавить в документацию предупреждение "не делайте так", возможно, стоит, но я не могу сказать, что проблема сколько-нибудь частая. -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Thu Feb 21 14:12:52 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 21 Feb 2019 17:12:52 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <20190221133945.GG37278@ufanet.ru> References: <20190220124910.GF3053@protva.ru> <23ef189e2f1b69a778cc47b692f0eabb.NginxMailingListRussian@forum.nginx.org> <20190221133945.GG37278@ufanet.ru> Message-ID: <20190221141252.GP2161@zxy.spb.ru> On Thu, Feb 21, 2019 at 06:39:46PM +0500, damir bikmuhametov wrote: > On Thu, Feb 21, 2019 at 07:06:11AM -0500, waster wrote: > > Все-таки странно, mtr не показывает проблем с пингом до ориджина во время > > таких скачков > > "conntrack: table full, dropping packet"? я бы скорее ожидал что-то типа # netstat -s | grep -i list 172775 SYNs to LISTEN sockets dropped From self на alaz.me Thu Feb 21 14:43:33 2019 From: self на alaz.me (Alexander Azarov) Date: Thu, 21 Feb 2019 16:43:33 +0200 Subject: =?UTF-8?B?UmU6IGd6aXAg0L7RgtCy0LXRgiDQvtGCIHVwc3RyZWFtIOKGkiBTU0kg4oaSIA==?= =?UTF-8?B?8J+Sow==?= In-Reply-To: <20190221141131.GC1877@mdounin.ru> References: <20190221141131.GC1877@mdounin.ru> Message-ID: чт, 21 февр. 2019 г. в 16:11, Maxim Dounin : > Hello! > > On Thu, Feb 21, 2019 at 03:31:42PM +0200, Alexander Azarov wrote: > > > Мне кажется, что я уже второй раз на это напарываюсь, но правда так и не > > смог вспомнить когда был предыдущий. Если ответ апстрима в gzip, то > > вставляя его как SSI получается мусор в результирующем документе. Я смог > > найти краткий совет так не делать от 2013 г тут: > > https://forum.nginx.org/read.php?2,244299,244303#msg-244303 > > По ссылке проблема немного другая - исходный ответ бэкенда в gzip, > и из-за этого SSI не может его обработать. У вас же ответ на > SSI-команду include в gzip. > > > Сейчас 2019 г, я использую Nginx 1.14, и словил то же самое. > > > > Вопросы: > > 1. Есть ли это в документации? > > 2. Баг или фича? > > SSI include вставляет в ответ то, что получено в результате > выполнения подзапроса - в вашем случае то, что прислал бэкенд. > Если вы не хотите, чтобы в соответствующем месте ответа был gzip - > сделайте так, чтобы бэкенд такого не присылал. Кто-то может такого хотеть? Есть такой случай, когда вот так надо? Мне, как человеку попытавшемуся "выстрелить себе в ногу" было бы очень приятно увидеть какой-то warning в error log. Но Вы прямо не ответили на вопрос (2). Я не настаиваю. > Обычно этого легко > добиться с помощью конфигурирования бэкенда и/или выпиливанием > заголовка Accept-Encoding с помощью директивы proxy_set_header. > Да, я уже поправил бэкенд. Спасибо. > Добавить в документацию предупреждение "не делайте так", возможно, > стоит, но я не могу сказать, что проблема сколько-нибудь частая. > -- > 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 Thu Feb 21 16:17:44 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 21 Feb 2019 19:17:44 +0300 Subject: =?UTF-8?B?UmU6IGd6aXAg0L7RgtCy0LXRgiDQvtGCIHVwc3RyZWFtIOKGkiBTU0kg4oaSIA==?= =?UTF-8?B?8J+Sow==?= In-Reply-To: References: <20190221141131.GC1877@mdounin.ru> Message-ID: <20190221161744.GD1877@mdounin.ru> Hello! On Thu, Feb 21, 2019 at 04:43:33PM +0200, Alexander Azarov wrote: > чт, 21 февр. 2019 г. в 16:11, Maxim Dounin : > > > Hello! > > > > On Thu, Feb 21, 2019 at 03:31:42PM +0200, Alexander Azarov wrote: > > > > > Мне кажется, что я уже второй раз на это напарываюсь, но правда так и не > > > смог вспомнить когда был предыдущий. Если ответ апстрима в gzip, то > > > вставляя его как SSI получается мусор в результирующем документе. Я смог > > > найти краткий совет так не делать от 2013 г тут: > > > https://forum.nginx.org/read.php?2,244299,244303#msg-244303 > > > > По ссылке проблема немного другая - исходный ответ бэкенда в gzip, > > и из-за этого SSI не может его обработать. У вас же ответ на > > SSI-команду include в gzip. > > > > > Сейчас 2019 г, я использую Nginx 1.14, и словил то же самое. > > > > > > Вопросы: > > > 1. Есть ли это в документации? > > > 2. Баг или фича? > > > > SSI include вставляет в ответ то, что получено в результате > > выполнения подзапроса - в вашем случае то, что прислал бэкенд. > > Если вы не хотите, чтобы в соответствующем месте ответа был gzip - > > сделайте так, чтобы бэкенд такого не присылал. > > Кто-то может такого хотеть? Есть такой случай, когда вот так надо? Мне, как > человеку попытавшемуся "выстрелить себе в ногу" было бы очень приятно > увидеть какой-то warning в error log. На практике бывает сборка бинарных ответов через SSI. > Но Вы прямо не ответили на вопрос (2). Я не настаиваю. Это фича. Если вы направляете ружьё на ногу и нажимаете на курок - оно стреляет в ногу. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Feb 21 16:37:41 2019 From: nginx-forum на forum.nginx.org (waster) Date: Thu, 21 Feb 2019 11:37:41 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <20190221141252.GP2161@zxy.spb.ru> References: <20190221141252.GP2161@zxy.spb.ru> Message-ID: Да, выглядит не очень хорошо,и даже не под сильной нагрузкой помаленьку растет: # netstat -s | grep LIST 19014545 SYNs to LISTEN sockets dropped Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283083,283113#msg-283113 From self на alaz.me Thu Feb 21 22:05:28 2019 From: self на alaz.me (Alexander Azarov) Date: Fri, 22 Feb 2019 00:05:28 +0200 Subject: =?UTF-8?B?UmU6IGd6aXAg0L7RgtCy0LXRgiDQvtGCIHVwc3RyZWFtIOKGkiBTU0kg4oaSIA==?= =?UTF-8?B?8J+Sow==?= In-Reply-To: <20190221161744.GD1877@mdounin.ru> References: <20190221141131.GC1877@mdounin.ru> <20190221161744.GD1877@mdounin.ru> Message-ID: On Thu, Feb 21, 2019, 18:17 Maxim Dounin wrote: > Hello! > > On Thu, Feb 21, 2019 at 04:43:33PM +0200, Alexander Azarov wrote: > > > чт, 21 февр. 2019 г. в 16:11, Maxim Dounin : > > > > > Hello! > > > > > > On Thu, Feb 21, 2019 at 03:31:42PM +0200, Alexander Azarov wrote: > > > > > > > Мне кажется, что я уже второй раз на это напарываюсь, но правда так > и не > > > > смог вспомнить когда был предыдущий. Если ответ апстрима в gzip, то > > > > вставляя его как SSI получается мусор в результирующем документе. Я > смог > > > > найти краткий совет так не делать от 2013 г тут: > > > > https://forum.nginx.org/read.php?2,244299,244303#msg-244303 > > > > > > По ссылке проблема немного другая - исходный ответ бэкенда в gzip, > > > и из-за этого SSI не может его обработать. У вас же ответ на > > > SSI-команду include в gzip. > > > > > > > Сейчас 2019 г, я использую Nginx 1.14, и словил то же самое. > > > > > > > > Вопросы: > > > > 1. Есть ли это в документации? > > > > 2. Баг или фича? > > > > > > SSI include вставляет в ответ то, что получено в результате > > > выполнения подзапроса - в вашем случае то, что прислал бэкенд. > > > Если вы не хотите, чтобы в соответствующем месте ответа был gzip - > > > сделайте так, чтобы бэкенд такого не присылал. > > > > Кто-то может такого хотеть? Есть такой случай, когда вот так надо? Мне, > как > > человеку попытавшемуся "выстрелить себе в ногу" было бы очень приятно > > увидеть какой-то warning в error log. > > На практике бывает сборка бинарных ответов через SSI. > Да, понятно. Там правда вряд ли text/html. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Feb 22 08:36:07 2019 From: nginx-forum на forum.nginx.org (waster) Date: Fri, 22 Feb 2019 03:36:07 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <20190221123926.GA3062@protva.ru> References: <20190221123926.GA3062@protva.ru> Message-ID: По совету сделал дамп на обоих серверах, в момент проблем наблюдается такая картина: https://imgur.com/a/Y9xN0H1 Множественных ретрансмиссий не вижу. На обоих серверах сейчас backlog=65535 reuseport. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283083,283120#msg-283120 From bgx на protva.ru Fri Feb 22 13:51:58 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 22 Feb 2019 16:51:58 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: References: <20190221123926.GA3062@protva.ru> Message-ID: <20190222135158.GG3173@protva.ru> On Fri, Feb 22, 2019 at 03:36:07AM -0500, waster wrote: > По совету сделал дамп на обоих серверах, в момент проблем наблюдается такая > картина: https://imgur.com/a/Y9xN0H1 > > Множественных ретрансмиссий не вижу. На обоих серверах сейчас backlog=65535 > reuseport. Я лично вижу на этой картинке две странности: 1. Пакеты отправляются с хоста "cache" в строго последовательном порядке src_port, а приходят на хост "origin" в каком-то довольно хаотичном. Вы используете какой-то балансировщик нагрузки с мультипасом на несколько физических линков? 2. Верхняя часть картинки банально не стыкуется с нижней, на них очень далёкие порты. Как их совместить? Здесь по пути был NAT или что? К слову, при сравнении дампов с разных сторон очень полезны отметки времени. Разумеется, время на хостах должно быть синхронизовано. -- Eugene Berdnikov From self на alaz.me Sun Feb 24 10:25:08 2019 From: self на alaz.me (Alexander Azarov) Date: Sun, 24 Feb 2019 12:25:08 +0200 Subject: request reference counter overflow while processing In-Reply-To: <20170320134700.GB13617@mdounin.ru> References: <60ab73af705cb5b2a3cc15761e389d0c.NginxMailingListRussian@forum.nginx.org> <20170320134700.GB13617@mdounin.ru> Message-ID: пн, 20 мар. 2017 г. в 15:47, Maxim Dounin : > Hello! > > On Mon, Mar 20, 2017 at 08:35:36AM -0400, malaf wrote: > > > Здравствуйте. > > > > В error.log наблюдали такие ошибки: > > > > [crit] request reference counter overflow while processing > > "next_subrequest_uri", client: , server: , request: "GET > > HTTP/1.1", subrequest: "subrequest_uri", host: "", > referrer: > > > > > > Подскажите, какое максимальное значение имеет счетчик ссылок? > > Такое сообщение выдаётся, если используется больше 64 тысяч ссылок > на запрос. Если вы его видите - вряд ли проблема в максимальном > значении, скорее что-то пошло не так. > Докладываю, что тоже такое видел. Исправил конфиг, отправил мастеру HUP, но три worker процесса так и остались потреблять 100% CPU и радостно писать в лог: # grep 'request reference counter overflow' nginx/error.log | wc -l 1897925 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Feb 25 09:57:37 2019 From: nginx-forum на forum.nginx.org (waster) Date: Mon, 25 Feb 2019 04:57:37 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <20190222135158.GG3173@protva.ru> References: <20190222135158.GG3173@protva.ru> Message-ID: <8c29f3c879f5f0d0762ab315b2341c4f.NginxMailingListRussian@forum.nginx.org> Сравнил дампы с выровненными метками времени (время на серверах синхронизировано): https://imgur.com/a/ncIOTkf Картина похожая, хоть reuseport уже выключен. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283083,283138#msg-283138 From nginx-forum на forum.nginx.org Mon Feb 25 12:07:08 2019 From: nginx-forum на forum.nginx.org (waster) Date: Mon, 25 Feb 2019 07:07:08 -0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC40L7QtNC40YfQtdGB0LrQuNC1INC/0YDQvtCx0LvQtdC80Ysg?= =?UTF-8?B?0L/QvtC0INC90LDQs9GA0YPQt9C60L7QuQ==?= In-Reply-To: <20190222135158.GG3173@protva.ru> References: <20190222135158.GG3173@protva.ru> Message-ID: <5e46b55a585fb78cb4820e44c1054c97.NginxMailingListRussian@forum.nginx.org> Это похоже на то, что по какой-то причине быстро исчерпываются свободные сокеты и origin судорожно пытается использовать существующие, т.к. net.ipv4.tcp_tw_reuse=1. Также резко подскакивает кол-во стокетов во всех состояниях (TIME_WAIT, Orphaned и т.д. ): https://imgur.com/a/fAz8hkH Posted at Nginx Forum: https://forum.nginx.org/read.php?21,283083,283141#msg-283141 From vas на mpeks.tomsk.su Tue Feb 26 05:13:56 2019 From: vas на mpeks.tomsk.su (Victor Sudakov) Date: Tue, 26 Feb 2019 12:13:56 +0700 Subject: =?UTF-8?B?0KfQsNC50L3QuNC60L7QstGB0LrQuNC5INCy0L7Qv9GA0L7RgSDQv9GA0L4gbG9j?= =?UTF-8?B?YXRpb25z?= Message-ID: <20190226051356.GA85975@admin.sibptus.ru> Коллеги, Прошу простить чайниковский вопрос, не могу пока перестроить мозги после apache. Допустим имеется конфигурация server { listen 80 default; location / { root /home/www; index index.html; } location ~ \.php$ { root /home/www; fastcgi_pass unix:/tmp/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } Контент основного сайта лежит в /home/www, динамические страницы передаются в php-fpm, всё работает. Теперь ставится moodle в /usr/local/www/moodle/, как мне сказать nginx-у, что moodle должен быть доступен по ссылке http://mysite.example/moodle ? Надо видимо сделать location /moodle { alias /usr/local/www/moodle/; } или даже location /moodle { root /usr/local/www/; } а с php-контентом внутри Moodle как быть? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 на fidonet http://vas.tomsk.ru/ From mdounin на mdounin.ru Tue Feb 26 15:52:57 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 26 Feb 2019 18:52:57 +0300 Subject: nginx-1.15.9 Message-ID: <20190226155257.GY1877@mdounin.ru> Изменения в nginx 1.15.9 26.02.2019 *) Добавление: директивы ssl_certificate и ssl_certificate_key поддерживают переменные. *) Добавление: метод poll теперь доступен на Windows при использовании Windows Vista и новее. *) Исправление: если при использовании метода select на Windows происходила ошибка при установлении соединения с бэкендом, nginx ожидал истечения таймаута на установление соединения. *) Исправление: директивы proxy_upload_rate и proxy_download_rate в модуле stream работали некорректно при проксировании UDP-пакетов. -- Maxim Dounin http://nginx.org/ From igor.bliss на gmail.com Thu Feb 28 16:20:50 2019 From: igor.bliss на gmail.com (Igor Savenko) Date: Thu, 28 Feb 2019 18:20:50 +0200 Subject: local IP address Message-ID: Доброе время суток! Подскажите, есть ли вообще способ определить, на какой именно адрес был послан запрос (хост имеет несколько интерфейсов с разными адресами или несколько secondary адресов на одном интерфейсе), чтобы спроксировать этот запрос на корректный адрес upstream. который тоже слушает на localhost. Схема проста: server { listen *:80; server_name _; location / { proxy_pass http://$server_addr; } } При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и 5.6.7.8. Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addr был не 1.2.3.4 (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить программно (в каком-нибудь модуле, то подскажите, пожалуйста. Спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From fe на hamilton.rinet.ru Thu Feb 28 16:37:18 2019 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Thu, 28 Feb 2019 19:37:18 +0300 Subject: local IP address In-Reply-To: References: Message-ID: <725c73f9-aee5-bd52-7cff-711256a884bb@hamilton.rinet.ru> 28.02.2019 19:20, Igor Savenko пишет: > Доброе время суток! > Подскажите, есть ли вообще способ определить, на какой именно адрес был > послан запрос (хост имеет несколько интерфейсов с разными адресами или > несколько secondary адресов на одном интерфейсе), чтобы спроксировать > этот запрос на корректный адрес upstream. который тоже слушает на localhost. > Схема проста: > server { >     listen *:80; >     server_name _; >     location / { >         proxy_pass http://$server_addr; >     } > } > > При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и 5.6.7.8. > Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не 1.2.3.4 > (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить > программно (в каком-нибудь модуле, то подскажите, пожалуйста. Спасибо! Про правильный server_addr не понял, а сейчас что не так? > # ifconfig lo0 > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000 > inet 192.168.255.1 netmask 0xffffffff > inet 192.168.255.2 netmask 0xffffffff > inet 192.168.255.3 netmask 0xffffffff > inet 192.168.255.4 netmask 0xffffffff > inet 192.168.255.5 netmask 0xffffffff > nd6 options=21 > groups: lo > # cat localhost.conf > server { > listen 80; > > location / { return 200 "$server_addr\n"; } > } > # for h in 2 3 4; do curl 192.168.255.$h; done > 192.168.255.2 > 192.168.255.3 > 192.168.255.4 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From igor.bliss на gmail.com Thu Feb 28 18:35:13 2019 From: igor.bliss на gmail.com (Igor Savenko) Date: Thu, 28 Feb 2019 20:35:13 +0200 Subject: local IP address In-Reply-To: <725c73f9-aee5-bd52-7cff-711256a884bb@hamilton.rinet.ru> References: <725c73f9-aee5-bd52-7cff-711256a884bb@hamilton.rinet.ru> Message-ID: Хм. Интересно получается. Интерфейсы на хосте (поскольку это, видимо, KVM guest, то все они, наверное, выставлены в один бридж, но это не имеет отношения к делу): [root на blissstagingserver1 imunify360-webshield]# ip -o -4 ad | grep eth 2: eth0 inet 10.0.0.143/26 brd 10.0.0.191 scope global eth0\ valid_lft forever preferred_lft forever 3: eth1 inet 10.0.0.146/26 brd 10.0.0.191 scope global eth1\ valid_lft forever preferred_lft forever 4: eth2 inet 10.0.0.147/26 brd 10.0.0.191 scope global eth2\ valid_lft forever preferred_lft forever server { listen *:80; location / { proxy_set_header X-Server-IP $server_addr; proxy_pass $scheme://$server_addr; } } Бекэндом выступает питоновский http.server, который просто выводит в консоль заголовки Host и X-Server-IP $ curl -L -v http://10.0.0.146 * Rebuilt URL to: http://10.0.0.146/ * Trying 10.0.0.146... * TCP_NODELAY set * Connected to 10.0.0.146 (10.0.0.146) port 80 (#0) > GET / HTTP/1.1 > Host: 10.0.0.146 > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 200 OK На это питоновский сервер пишет Host: 10.0.0.146, IP: 10.0.0.143 То есть $server_addr -- 10.0.0.143, a не 146, как ожидалось... То есть в $server_add чт, 28 февр. 2019 г. в 18:37, Fedor Dikarev : > > 28.02.2019 19:20, Igor Savenko пишет: > > Доброе время суток! > > Подскажите, есть ли вообще способ определить, на какой именно адрес был > > послан запрос (хост имеет несколько интерфейсов с разными адресами или > > несколько secondary адресов на одном интерфейсе), чтобы спроксировать > > этот запрос на корректный адрес upstream. который тоже слушает на > localhost. > > Схема проста: > > server { > > listen *:80; > > server_name _; > > location / { > > proxy_pass http://$server_addr; > > } > > } > > > > При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и 5.6.7.8. > > Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не 1.2.3.4 > > (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить > > программно (в каком-нибудь модуле, то подскажите, пожалуйста. Спасибо! > > Про правильный server_addr не понял, а сейчас что не так? > > # ifconfig lo0 > > lo0: flags=8049 metric 0 mtu 16384 > > options=600003 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > inet 127.0.0.1 netmask 0xff000000 > > inet 192.168.255.1 netmask 0xffffffff > > inet 192.168.255.2 netmask 0xffffffff > > inet 192.168.255.3 netmask 0xffffffff > > inet 192.168.255.4 netmask 0xffffffff > > inet 192.168.255.5 netmask 0xffffffff > > nd6 options=21 > > groups: lo > > > # cat localhost.conf > > server { > > listen 80; > > > > location / { return 200 "$server_addr\n"; } > > } > > > # for h in 2 3 4; do curl 192.168.255.$h; done > > 192.168.255.2 > > 192.168.255.3 > > 192.168.255.4 > > > > > > _______________________________________________ > > 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 fe на hamilton.rinet.ru Thu Feb 28 20:00:30 2019 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Thu, 28 Feb 2019 23:00:30 +0300 Subject: local IP address In-Reply-To: References: <725c73f9-aee5-bd52-7cff-711256a884bb@hamilton.rinet.ru> Message-ID: <1c4a5863-fac7-9050-d863-1f28af684895@hamilton.rinet.ru> А это точно тестируемый конфиг приведен? Может там еще что-то есть? Тут получается что nginx проксирует сам на себя, и я даже не поленился это попробовать и получил ожидаемое: > # cat localhost.conf > server { > listen 80; > > access_log /var/log/nginx/local-access.log; > location / { return 200 "$server_addr\n"; } > location /one { > proxy_set_header X-Server-IP $server_addr; > proxy_pass $scheme://$server_addr; > } > } > # grep -c /one /var/log/nginx/local-access.log ; curl http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log > 909 > > 502 Bad Gateway > >

502 Bad Gateway

>
nginx/1.15.8
> > > 1813 > grep -c /one /var/log/nginx/local-access.log ; curl http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log > 1813 > > 502 Bad Gateway > >

502 Bad Gateway

>
nginx/1.15.8
> > > 2820 28.02.19 21:35, Igor Savenko пишет: > Хм. Интересно получается. > Интерфейсы на хосте (поскольку это, видимо, KVM guest, то все они, > наверное, выставлены в один бридж, но это не имеет отношения к делу): > [root на blissstagingserver1 imunify360-webshield]# ip -o -4 ad | grep eth > 2: eth0    inet 10.0.0.143/26 brd 10.0.0.191 > scope global eth0\       valid_lft forever preferred_lft forever > 3: eth1    inet 10.0.0.146/26 brd 10.0.0.191 > scope global eth1\       valid_lft forever preferred_lft forever > 4: eth2    inet 10.0.0.147/26 brd 10.0.0.191 > scope global eth2\       valid_lft forever preferred_lft forever > >     server { >         listen *:80; >         location / { >             proxy_set_header    X-Server-IP $server_addr; >             proxy_pass          $scheme://$server_addr; >         } >     } > > Бекэндом выступает питоновский http.server, который просто выводит в > консоль заголовки Host и X-Server-IP > > $ curl -L -v http://10.0.0.146 > * Rebuilt URL to: http://10.0.0.146/ > *   Trying 10.0.0.146... > * TCP_NODELAY set > * Connected to 10.0.0.146 (10.0.0.146) port 80 (#0) > > GET / HTTP/1.1 > > Host: 10.0.0.146 > > User-Agent: curl/7.52.1 > > Accept: */* > > > < HTTP/1.1 200 OK > > На это питоновский сервер пишет > Host: 10.0.0.146, IP: 10.0.0.143 > > То есть $server_addr -- 10.0.0.143, a не 146, как ожидалось... > > То есть в $server_add > > чт, 28 февр. 2019 г. в 18:37, Fedor Dikarev >: > > > 28.02.2019 19:20, Igor Savenko пишет: > > Доброе время суток! > > Подскажите, есть ли вообще способ определить, на какой именно > адрес был > > послан запрос (хост имеет несколько интерфейсов с разными > адресами или > > несколько secondary адресов на одном интерфейсе), чтобы спроксировать > > этот запрос на корректный адрес upstream. который тоже слушает на > localhost. > > Схема проста: > > server { > >     listen *:80; > >     server_name _; > >     location / { > >         proxy_pass http://$server_addr; > >     } > > } > > > > При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и 5.6.7.8. > > Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не > 1.2.3.4 > > (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить > > программно (в каком-нибудь модуле, то подскажите, пожалуйста. > Спасибо! > > Про правильный server_addr не понял, а сейчас что не так? > > # ifconfig lo0 > > lo0: flags=8049 metric 0 mtu 16384 > >         options=600003 > >         inet6 ::1 prefixlen 128 > >         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > >         inet 127.0.0.1 netmask 0xff000000 > >         inet 192.168.255.1 netmask 0xffffffff > >         inet 192.168.255.2 netmask 0xffffffff > >         inet 192.168.255.3 netmask 0xffffffff > >         inet 192.168.255.4 netmask 0xffffffff > >         inet 192.168.255.5 netmask 0xffffffff > >         nd6 options=21 > >         groups: lo > > > # cat localhost.conf > > server { > >         listen 80; > > > >         location / { return 200 "$server_addr\n"; } > > } > > > # for h in 2 3 4; do curl 192.168.255.$h; done > > 192.168.255.2 > > 192.168.255.3 > > 192.168.255.4 > > > > > > _______________________________________________ > > 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 > -- Fedor Dikarev From igor.bliss на gmail.com Thu Feb 28 20:08:40 2019 From: igor.bliss на gmail.com (Igor Savenko) Date: Thu, 28 Feb 2019 22:08:40 +0200 Subject: local IP address In-Reply-To: <1c4a5863-fac7-9050-d863-1f28af684895@hamilton.rinet.ru> References: <725c73f9-aee5-bd52-7cff-711256a884bb@hamilton.rinet.ru> <1c4a5863-fac7-9050-d863-1f28af684895@hamilton.rinet.ru> Message-ID: Спасибо, Федор! Разобрался. Дело в том, что трафик на nginx заводится через iptables REDIRECT. Поэтому какой бы адрес ни находился в качестве destination IP, из-за редиректа он всегда становится первым адресом интерфейса / адресом первого интерфейсаю Спасибо еще раз! чт, 28 февр. 2019 г. в 22:00, Fedor Dikarev : > А это точно тестируемый конфиг приведен? Может там еще что-то есть? > > Тут получается что nginx проксирует сам на себя, и я даже не поленился > это попробовать и получил ожидаемое: > > # cat localhost.conf > > server { > > listen 80; > > > > access_log /var/log/nginx/local-access.log; > > location / { return 200 "$server_addr\n"; } > > location /one { > > proxy_set_header X-Server-IP $server_addr; > > proxy_pass $scheme://$server_addr; > > } > > } > > > # grep -c /one /var/log/nginx/local-access.log ; curl > http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log > > 909 > > > > 502 Bad Gateway > > > >

502 Bad Gateway

> >
nginx/1.15.8
> > > > > > 1813 > > > grep -c /one /var/log/nginx/local-access.log ; curl > http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log > > 1813 > > > > 502 Bad Gateway > > > >

502 Bad Gateway

> >
nginx/1.15.8
> > > > > > 2820 > > > 28.02.19 21:35, Igor Savenko пишет: > > Хм. Интересно получается. > > Интерфейсы на хосте (поскольку это, видимо, KVM guest, то все они, > > наверное, выставлены в один бридж, но это не имеет отношения к делу): > > [root на blissstagingserver1 imunify360-webshield]# ip -o -4 ad | grep eth > > 2: eth0 inet 10.0.0.143/26 brd 10.0.0.191 > > scope global eth0\ valid_lft forever preferred_lft forever > > 3: eth1 inet 10.0.0.146/26 brd 10.0.0.191 > > scope global eth1\ valid_lft forever preferred_lft forever > > 4: eth2 inet 10.0.0.147/26 brd 10.0.0.191 > > scope global eth2\ valid_lft forever preferred_lft forever > > > > server { > > listen *:80; > > location / { > > proxy_set_header X-Server-IP $server_addr; > > proxy_pass $scheme://$server_addr; > > } > > } > > > > Бекэндом выступает питоновский http.server, который просто выводит в > > консоль заголовки Host и X-Server-IP > > > > $ curl -L -v http://10.0.0.146 > > * Rebuilt URL to: http://10.0.0.146/ > > * Trying 10.0.0.146... > > * TCP_NODELAY set > > * Connected to 10.0.0.146 (10.0.0.146) port 80 (#0) > > > GET / HTTP/1.1 > > > Host: 10.0.0.146 > > > User-Agent: curl/7.52.1 > > > Accept: */* > > > > > < HTTP/1.1 200 OK > > > > На это питоновский сервер пишет > > Host: 10.0.0.146, IP: 10.0.0.143 > > > > То есть $server_addr -- 10.0.0.143, a не 146, как ожидалось... > > > > То есть в $server_add > > > > чт, 28 февр. 2019 г. в 18:37, Fedor Dikarev > >: > > > > > > 28.02.2019 19:20, Igor Savenko пишет: > > > Доброе время суток! > > > Подскажите, есть ли вообще способ определить, на какой именно > > адрес был > > > послан запрос (хост имеет несколько интерфейсов с разными > > адресами или > > > несколько secondary адресов на одном интерфейсе), чтобы > спроксировать > > > этот запрос на корректный адрес upstream. который тоже слушает на > > localhost. > > > Схема проста: > > > server { > > > listen *:80; > > > server_name _; > > > location / { > > > proxy_pass http://$server_addr; > > > } > > > } > > > > > > При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и > 5.6.7.8. > > > Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не > > 1.2.3.4 > > > (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить > > > программно (в каком-нибудь модуле, то подскажите, пожалуйста. > > Спасибо! > > > > Про правильный server_addr не понял, а сейчас что не так? > > > # ifconfig lo0 > > > lo0: flags=8049 metric 0 mtu 16384 > > > options=600003 > > > inet6 ::1 prefixlen 128 > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > > inet 127.0.0.1 netmask 0xff000000 > > > inet 192.168.255.1 netmask 0xffffffff > > > inet 192.168.255.2 netmask 0xffffffff > > > inet 192.168.255.3 netmask 0xffffffff > > > inet 192.168.255.4 netmask 0xffffffff > > > inet 192.168.255.5 netmask 0xffffffff > > > nd6 options=21 > > > groups: lo > > > > > # cat localhost.conf > > > server { > > > listen 80; > > > > > > location / { return 200 "$server_addr\n"; } > > > } > > > > > # for h in 2 3 4; do curl 192.168.255.$h; done > > > 192.168.255.2 > > > 192.168.255.3 > > > 192.168.255.4 > > > > > > > > > > _______________________________________________ > > > 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 > > > > -- > Fedor Dikarev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From fe на hamilton.rinet.ru Thu Feb 28 20:11:32 2019 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Thu, 28 Feb 2019 23:11:32 +0300 Subject: local IP address In-Reply-To: <1c4a5863-fac7-9050-d863-1f28af684895@hamilton.rinet.ru> References: <725c73f9-aee5-bd52-7cff-711256a884bb@hamilton.rinet.ru> <1c4a5863-fac7-9050-d863-1f28af684895@hamilton.rinet.ru> Message-ID: <690c09f3-bfff-89bb-0bde-a3c1eef32528@hamilton.rinet.ru> В общем я подумал еще раз, и понял что или не понимаю исходную задачу, или не понимаю пути ее решения. Но вдруг это поможет: у нас тоже есть задача, что разные сервисы должны слушаться на разных адресах: один адрес для public-сервисов, второй для ограниченного круга лиц, третий для другого круга и т.д. Решаем это так: в конфиге nginx-а для каждого сервера пишем listen ip:80 для каждого уровня доступа свой ip адрес, дальше server_name нужный для сервиса. А сервисы уже в docker-е, и в nginx-е просто proxy_pass на expose-нутый порт. И все работает. (понятно что эти конфиги пишем не руками, но как идея. хотя могу и программой поделиться, если задача такая же) 28.02.19 23:00, Fedor Dikarev пишет: > А это точно тестируемый конфиг приведен? Может там еще что-то есть? > > Тут получается что nginx проксирует сам на себя, и я даже не поленился > это попробовать и получил ожидаемое: >> # cat localhost.conf server { >>         listen 80; >> >>         access_log /var/log/nginx/local-access.log; >>         location / { return 200 "$server_addr\n"; } >>         location /one { >>                 proxy_set_header    X-Server-IP $server_addr; >>                 proxy_pass          $scheme://$server_addr; >>         } >> } > >> # grep -c /one /var/log/nginx/local-access.log ; curl >> http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log >> 909 >> >> 502 Bad Gateway >> >>

502 Bad Gateway

>>
nginx/1.15.8
>> >> >> 1813 > >> grep -c /one /var/log/nginx/local-access.log ; curl >> http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log >> 1813 >> >> 502 Bad Gateway >> >>

502 Bad Gateway

>>
nginx/1.15.8
>> >> >> 2820 > > > 28.02.19 21:35, Igor Savenko пишет: >> Хм. Интересно получается. >> Интерфейсы на хосте (поскольку это, видимо, KVM guest, то все они, >> наверное, выставлены в один бридж, но это не имеет отношения к делу): >> [root на blissstagingserver1 imunify360-webshield]# ip -o -4 ad | grep eth >> 2: eth0    inet 10.0.0.143/26 brd 10.0.0.191 >> scope global eth0\       valid_lft forever preferred_lft forever >> 3: eth1    inet 10.0.0.146/26 brd 10.0.0.191 >> scope global eth1\       valid_lft forever preferred_lft forever >> 4: eth2    inet 10.0.0.147/26 brd 10.0.0.191 >> scope global eth2\       valid_lft forever preferred_lft forever >> >>      server { >>          listen *:80; >>          location / { >>              proxy_set_header    X-Server-IP $server_addr; >>              proxy_pass          $scheme://$server_addr; >>          } >>      } >> >> Бекэндом выступает питоновский http.server, который просто выводит в >> консоль заголовки Host и X-Server-IP >> >> $ curl -L -v http://10.0.0.146 >> * Rebuilt URL to: http://10.0.0.146/ >> *   Trying 10.0.0.146... >> * TCP_NODELAY set >> * Connected to 10.0.0.146 (10.0.0.146) port 80 (#0) >>  > GET / HTTP/1.1 >>  > Host: 10.0.0.146 >>  > User-Agent: curl/7.52.1 >>  > Accept: */* >>  > >> < HTTP/1.1 200 OK >> >> На это питоновский сервер пишет >> Host: 10.0.0.146, IP: 10.0.0.143 >> >> То есть $server_addr -- 10.0.0.143, a не 146, как ожидалось... >> >> То есть в $server_add >> >> чт, 28 февр. 2019 г. в 18:37, Fedor Dikarev > >: >> >> >>     28.02.2019 19:20, Igor Savenko пишет: >>      > Доброе время суток! >>      > Подскажите, есть ли вообще способ определить, на какой именно >>     адрес был >>      > послан запрос (хост имеет несколько интерфейсов с разными >>     адресами или >>      > несколько secondary адресов на одном интерфейсе), чтобы >> спроксировать >>      > этот запрос на корректный адрес upstream. который тоже слушает на >>     localhost. >>      > Схема проста: >>      > server { >>      >     listen *:80; >>      >     server_name _; >>      >     location / { >>      >         proxy_pass http://$server_addr; >>      >     } >>      > } >>      > >>      > При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и >> 5.6.7.8. >>      > Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не >>     1.2.3.4 >>      > (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить >>      > программно (в каком-нибудь модуле, то подскажите, пожалуйста. >>     Спасибо! >> >>     Про правильный server_addr не понял, а сейчас что не так? >>      > # ifconfig lo0 >>      > lo0: flags=8049 metric 0 mtu 16384 >>      >         options=600003 >>      >         inet6 ::1 prefixlen 128 >>      >         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >>      >         inet 127.0.0.1 netmask 0xff000000 >>      >         inet 192.168.255.1 netmask 0xffffffff >>      >         inet 192.168.255.2 netmask 0xffffffff >>      >         inet 192.168.255.3 netmask 0xffffffff >>      >         inet 192.168.255.4 netmask 0xffffffff >>      >         inet 192.168.255.5 netmask 0xffffffff >>      >         nd6 options=21 >>      >         groups: lo >> >>      > # cat localhost.conf >>      > server { >>      >         listen 80; >>      > >>      >         location / { return 200 "$server_addr\n"; } >>      > } >> >>      > # for h in 2 3 4; do curl 192.168.255.$h; done >>      > 192.168.255.2 >>      > 192.168.255.3 >>      > 192.168.255.4 >> >> >>      > >>      > _______________________________________________ >>      > 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 >> > -- Fedor Dikarev From igor.bliss на gmail.com Thu Feb 28 20:17:16 2019 From: igor.bliss на gmail.com (Igor Savenko) Date: Thu, 28 Feb 2019 22:17:16 +0200 Subject: local IP address In-Reply-To: <690c09f3-bfff-89bb-0bde-a3c1eef32528@hamilton.rinet.ru> References: <725c73f9-aee5-bd52-7cff-711256a884bb@hamilton.rinet.ru> <1c4a5863-fac7-9050-d863-1f28af684895@hamilton.rinet.ru> <690c09f3-bfff-89bb-0bde-a3c1eef32528@hamilton.rinet.ru> Message-ID: Спасибо, но раз уж проблема понятна -- становится все проще. Надо разобраться с redirect'ом, чтобы трафик приезжал туда, куда должен, а дальше уже, как я уже понял, разрулимся через $server_addr. чт, 28 февр. 2019 г. в 22:11, Fedor Dikarev : > В общем я подумал еще раз, и понял что или не понимаю исходную задачу, > или не понимаю пути ее решения. > > Но вдруг это поможет: > у нас тоже есть задача, что разные сервисы должны слушаться на разных > адресах: один адрес для public-сервисов, второй для ограниченного круга > лиц, третий для другого круга и т.д. > > Решаем это так: в конфиге nginx-а для каждого сервера пишем listen ip:80 > для каждого уровня доступа свой ip адрес, дальше server_name нужный для > сервиса. А сервисы уже в docker-е, и в nginx-е просто proxy_pass на > expose-нутый порт. И все работает. (понятно что эти конфиги пишем не > руками, но как идея. хотя могу и программой поделиться, если задача > такая же) > > 28.02.19 23:00, Fedor Dikarev пишет: > > А это точно тестируемый конфиг приведен? Может там еще что-то есть? > > > > Тут получается что nginx проксирует сам на себя, и я даже не поленился > > это попробовать и получил ожидаемое: > >> # cat localhost.conf server { > >> listen 80; > >> > >> access_log /var/log/nginx/local-access.log; > >> location / { return 200 "$server_addr\n"; } > >> location /one { > >> proxy_set_header X-Server-IP $server_addr; > >> proxy_pass $scheme://$server_addr; > >> } > >> } > > > >> # grep -c /one /var/log/nginx/local-access.log ; curl > >> http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log > >> 909 > >> > >> 502 Bad Gateway > >> > >>

502 Bad Gateway

> >>
nginx/1.15.8
> >> > >> > >> 1813 > > > >> grep -c /one /var/log/nginx/local-access.log ; curl > >> http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log > >> 1813 > >> > >> 502 Bad Gateway > >> > >>

502 Bad Gateway

> >>
nginx/1.15.8
> >> > >> > >> 2820 > > > > > > 28.02.19 21:35, Igor Savenko пишет: > >> Хм. Интересно получается. > >> Интерфейсы на хосте (поскольку это, видимо, KVM guest, то все они, > >> наверное, выставлены в один бридж, но это не имеет отношения к делу): > >> [root на blissstagingserver1 imunify360-webshield]# ip -o -4 ad | grep eth > >> 2: eth0 inet 10.0.0.143/26 brd 10.0.0.191 > >> scope global eth0\ valid_lft forever preferred_lft forever > >> 3: eth1 inet 10.0.0.146/26 brd 10.0.0.191 > >> scope global eth1\ valid_lft forever preferred_lft forever > >> 4: eth2 inet 10.0.0.147/26 brd 10.0.0.191 > >> scope global eth2\ valid_lft forever preferred_lft forever > >> > >> server { > >> listen *:80; > >> location / { > >> proxy_set_header X-Server-IP $server_addr; > >> proxy_pass $scheme://$server_addr; > >> } > >> } > >> > >> Бекэндом выступает питоновский http.server, который просто выводит в > >> консоль заголовки Host и X-Server-IP > >> > >> $ curl -L -v http://10.0.0.146 > >> * Rebuilt URL to: http://10.0.0.146/ > >> * Trying 10.0.0.146... > >> * TCP_NODELAY set > >> * Connected to 10.0.0.146 (10.0.0.146) port 80 (#0) > >> > GET / HTTP/1.1 > >> > Host: 10.0.0.146 > >> > User-Agent: curl/7.52.1 > >> > Accept: */* > >> > > >> < HTTP/1.1 200 OK > >> > >> На это питоновский сервер пишет > >> Host: 10.0.0.146, IP: 10.0.0.143 > >> > >> То есть $server_addr -- 10.0.0.143, a не 146, как ожидалось... > >> > >> То есть в $server_add > >> > >> чт, 28 февр. 2019 г. в 18:37, Fedor Dikarev >> >: > >> > >> > >> 28.02.2019 19:20, Igor Savenko пишет: > >> > Доброе время суток! > >> > Подскажите, есть ли вообще способ определить, на какой именно > >> адрес был > >> > послан запрос (хост имеет несколько интерфейсов с разными > >> адресами или > >> > несколько secondary адресов на одном интерфейсе), чтобы > >> спроксировать > >> > этот запрос на корректный адрес upstream. который тоже слушает на > >> localhost. > >> > Схема проста: > >> > server { > >> > listen *:80; > >> > server_name _; > >> > location / { > >> > proxy_pass http://$server_addr; > >> > } > >> > } > >> > > >> > При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и > >> 5.6.7.8. > >> > Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не > >> 1.2.3.4 > >> > (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить > >> > программно (в каком-нибудь модуле, то подскажите, пожалуйста. > >> Спасибо! > >> > >> Про правильный server_addr не понял, а сейчас что не так? > >> > # ifconfig lo0 > >> > lo0: flags=8049 metric 0 mtu 16384 > >> > options=600003 > >> > inet6 ::1 prefixlen 128 > >> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > >> > inet 127.0.0.1 netmask 0xff000000 > >> > inet 192.168.255.1 netmask 0xffffffff > >> > inet 192.168.255.2 netmask 0xffffffff > >> > inet 192.168.255.3 netmask 0xffffffff > >> > inet 192.168.255.4 netmask 0xffffffff > >> > inet 192.168.255.5 netmask 0xffffffff > >> > nd6 options=21 > >> > groups: lo > >> > >> > # cat localhost.conf > >> > server { > >> > listen 80; > >> > > >> > location / { return 200 "$server_addr\n"; } > >> > } > >> > >> > # for h in 2 3 4; do curl 192.168.255.$h; done > >> > 192.168.255.2 > >> > 192.168.255.3 > >> > 192.168.255.4 > >> > >> > >> > > >> > _______________________________________________ > >> > 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 > >> > > > > -- > Fedor Dikarev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: