From nginx-forum на forum.nginx.org Fri Nov 6 10:52:42 2020 From: nginx-forum на forum.nginx.org (redidka812) Date: Fri, 06 Nov 2020 05:52:42 -0500 Subject: =?UTF-8?B?0LLQvtC/0YDQvtGBINC90L7QstC40YfQutCwINC/0L4g0YDQtdC00LjRgNC10Lo=?= =?UTF-8?B?0YLRgyDQvdCwINC90L7QvNC10YAg0L/QvtGA0YLQsA==?= Message-ID: Добрый день, Помогите разобраться. у меня в домашней сети Есть компьютер(Linux) на нем крутится несколько серверов (используется как медиацентр):торрент качалка,Plex, dlna, и т.п.. каждый слушает свой порт.. и все хорошо(в домашней сети)... . Хочется управлять им удаленно, из интернета, для этого можно пробросить их парты за NAT.. но во-первых не все сервера с авторизацией, да и просто держать за натом кучу открытых портов мне кажется не самой лучшей идеей.... И можно поставить ngnix, за NAT вывести только его порт,а он уже будет редиректить на соответствующие службы внутри домашней сети, а заодно по необходимости прверять авторизацию ... Я ещё совсем зелёный и у меня пока ничего не получилось.. по манам ставилю ngnix.. При тесте на 80 порту выдает дефолтную страничку... И пытаюсь добавить правила/серверы в конфиг.. запутался в именах серверов.. Т.е. Я хочу придумать им имена по названию служб И в браузере вводить:http://IP:port/server_name Чтобы ngnix слушающий 80й порт, сопоставлял server_name с тем что у него имеются в конфиге И редиректил на соответствующий порт Пример: В браузере удаленной машины ввожу Http://192.168.1.100/transmission Где -192.168.1.100(или внешний белый ip) адрес машины где крутится ngnix "transmission"- имя сервера по которому ngnix должен опознать запрос и перенаправить на соответствующий порт В правилах ngnix server { ... server_name transmission www.transmission location / { proxy_pass http://192.168.1.100:8091/; } } -где 8091 номер порта где отвечает transmission в локальной сети... И так для всех служб для которых я хочу сделать редирект через ngnix (Свое уникальное имя сервера и порт на котором запущена /слушает служба) Далее рестарт ngnix И пока ничего не получается, при удаленном запросе в браузере (из домаашней сети) http://192.168.1.100/transmission Получаю 404, а хочу получить вебморду от торрент качалки... Ч.Я Д.Н.Т? Подскажите, как правильно прописать подобное перенаправление, и как правильно придумывать имена серверов/сайтов (для служб запущенных на той же машине где и ngnix , каждая служба отвечает на своем порту) чтоб редирект через ngnix их распознавал? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289885,289885#msg-289885 From root на dl.sm.ua Fri Nov 6 10:58:30 2020 From: root на dl.sm.ua (Dmytro Lavryk) Date: Fri, 06 Nov 2020 12:58:30 +0200 Subject: =?UTF-8?B?0JLRltC00L/QvtCy0ZbQtNGMOiDQstC+0L/RgNC+0YEg0L3QvtCy0LjRh9C60LAg?= =?UTF-8?B?0L/QviDRgNC10LTQuNGA0LXQutGC0YMg0L3QsCDQvdC+0LzQtdGAINC/0L4=?= =?UTF-8?B?0YDRgtCw?= In-Reply-To: References: Message-ID: <1759d35338d.122ea7aa8340200.8303642752543338798@dl.sm.ua> location /transmission {     proxy_pass http://192.168.1.100:8091/;     ..... } ---- Увімкнуто пт, 06 лист. 2020 12:52:42 +0200 redidka812 написав ---- Добрый день, Помогите разобраться. у меня в домашней сети Есть компьютер(Linux) на нем крутится несколько серверов (используется как медиацентр):торрент качалка,Plex, dlna, и т.п.. каждый слушает свой порт.. и все хорошо(в домашней сети)... . Хочется управлять им удаленно, из интернета, для этого можно пробросить их парты за NAT.. но во-первых не все сервера с авторизацией, да и просто держать за натом кучу открытых портов мне кажется не самой лучшей идеей.... И можно поставить ngnix, за NAT вывести только его порт,а он уже будет редиректить на соответствующие службы внутри домашней сети, а заодно по необходимости прверять авторизацию ... Я ещё совсем зелёный и у меня пока ничего не получилось.. по манам ставилю ngnix.. При тесте на 80 порту выдает дефолтную страничку... И пытаюсь добавить правила/серверы в конфиг.. запутался в именах серверов.. Т.е. Я хочу придумать им имена по названию служб И в браузере вводить:http://IP:port/server_name Чтобы ngnix слушающий 80й порт, сопоставлял server_name с тем что у него имеются в конфиге И редиректил на соответствующий порт Пример: В браузере удаленной машины ввожу Http://192.168.1.100/transmission Где -192.168.1.100(или внешний белый ip) адрес машины где крутится ngnix "transmission"- имя сервера по которому ngnix должен опознать запрос и перенаправить на соответствующий порт В правилах ngnix server { ... server_name transmission www.transmission location / { proxy_pass http://192.168.1.100:8091/; } } -где 8091 номер порта где отвечает transmission в локальной сети... И так для всех служб для которых я хочу сделать редирект через ngnix (Свое уникальное имя сервера и порт на котором запущена /слушает служба) Далее рестарт ngnix И пока ничего не получается, при удаленном запросе в браузере (из домаашней сети) http://192.168.1.100/transmission Получаю 404, а хочу получить вебморду от торрент качалки... Ч.Я Д.Н.Т? Подскажите, как правильно прописать подобное перенаправление, и как правильно придумывать имена серверов/сайтов (для служб запущенных на той же машине где и ngnix , каждая служба отвечает на своем порту) чтоб редирект через ngnix их распознавал? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289885,289885#msg-289885 _______________________________________________ nginx-ru mailing list mailto:nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From koshikov на gmail.com Fri Nov 6 17:40:14 2020 From: koshikov на gmail.com (Nikita Koshikov) Date: Fri, 6 Nov 2020 09:40:14 -0800 Subject: upstream priority Message-ID: Доброго всем времени суток Подскажите как можно сделать что-то максимально подобное для выбора backend сервера по приоритету, в идеале нужно что-то upstream backend { server [::1]:81 priority=1; server [::1]:82 priority=2; server [::1]:83 priority=3; server [::1]:84 priority=4; server [::1]:85 priority=5; } т.е. пока жив хоть один с более высоким приоритетом - слать запросы на него ? Из того что пробовал upstream backend { server [::1]:81 weight=1; server [::1]:83 backup; } Так работает - однако не поддерживает 2+ бекенда Из самого близкого что удалось сделать - через hash со статичным ключом upstream backend { hash 'http_balance'; server [::1]:81 weight=1 fail_timeout=60; server [::1]:82 weight=2 fail_timeout=60; server [::1]:83 weight=3 fail_timeout=60; } Проблема только что веса не всегда работают, - в данной конфигурации выбирается server:82, хотя у 83 более высокий weight. Полная цепочка при отказах - 82->83->81 Учитывается ли вес в такой конфигурации ? С более высокими весами начинает работать как нужно 83->82->81 upstream backend { hash 'http_balance'; server [::1]:81 weight=1 fail_timeout=60; server [::1]:82 weight=10 fail_timeout=60; server [::1]:83 weight=100 fail_timeout=60; } Хотелось бы понимать это совпадение или веса принимаются в расчет при выборе hash-а? From chipitsine на gmail.com Fri Nov 6 17:52:08 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 6 Nov 2020 22:52:08 +0500 Subject: upstream priority In-Reply-To: References: Message-ID: можно проксировать на самого себя каскадом. на каждом каскаде 2 бекенда пт, 6 нояб. 2020 г. в 22:40, Nikita Koshikov : > Доброго всем времени суток > > Подскажите как можно сделать что-то максимально подобное для выбора > backend сервера по приоритету, в идеале нужно что-то > > upstream backend { > server [::1]:81 priority=1; > server [::1]:82 priority=2; > server [::1]:83 priority=3; > server [::1]:84 priority=4; > server [::1]:85 priority=5; > } > т.е. пока жив хоть один с более высоким приоритетом - слать запросы на > него ? > > Из того что пробовал > upstream backend { > server [::1]:81 weight=1; > server [::1]:83 backup; > } > Так работает - однако не поддерживает 2+ бекенда > > Из самого близкого что удалось сделать - через hash со статичным ключом > upstream backend { > hash 'http_balance'; > server [::1]:81 weight=1 fail_timeout=60; > server [::1]:82 weight=2 fail_timeout=60; > server [::1]:83 weight=3 fail_timeout=60; > } > Проблема только что веса не всегда работают, - в данной конфигурации > выбирается server:82, хотя у 83 более высокий weight. Полная цепочка > при отказах - 82->83->81 > Учитывается ли вес в такой конфигурации ? > С более высокими весами начинает работать как нужно 83->82->81 > upstream backend { > hash 'http_balance'; > server [::1]:81 weight=1 fail_timeout=60; > server [::1]:82 weight=10 fail_timeout=60; > server [::1]:83 weight=100 fail_timeout=60; > } > Хотелось бы понимать это совпадение или веса принимаются в расчет при > выборе hash-а? > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From koshikov на gmail.com Fri Nov 6 18:16:48 2020 From: koshikov на gmail.com (Nikita Koshikov) Date: Fri, 6 Nov 2020 10:16:48 -0800 Subject: upstream priority In-Reply-To: References: Message-ID: Спасибо, Имеется ввиду два бекенда один из который с backup ? upstream c1 { server [::1]:81 ; server [::1]:82 backup; } upstream c2 { server [::1]:83 ; server [::1]:84 backup; } server { location { proxy_pass http://c1 error_page @c2 } } Или что-то другое ? On Fri, Nov 6, 2020 at 9:52 AM Илья Шипицин wrote: > > можно проксировать на самого себя каскадом. > на каждом каскаде 2 бекенда > > пт, 6 нояб. 2020 г. в 22:40, Nikita Koshikov : >> >> Доброго всем времени суток >> >> Подскажите как можно сделать что-то максимально подобное для выбора >> backend сервера по приоритету, в идеале нужно что-то >> >> upstream backend { >> server [::1]:81 priority=1; >> server [::1]:82 priority=2; >> server [::1]:83 priority=3; >> server [::1]:84 priority=4; >> server [::1]:85 priority=5; >> } >> т.е. пока жив хоть один с более высоким приоритетом - слать запросы на него ? >> >> Из того что пробовал >> upstream backend { >> server [::1]:81 weight=1; >> server [::1]:83 backup; >> } >> Так работает - однако не поддерживает 2+ бекенда >> >> Из самого близкого что удалось сделать - через hash со статичным ключом >> upstream backend { >> hash 'http_balance'; >> server [::1]:81 weight=1 fail_timeout=60; >> server [::1]:82 weight=2 fail_timeout=60; >> server [::1]:83 weight=3 fail_timeout=60; >> } >> Проблема только что веса не всегда работают, - в данной конфигурации >> выбирается server:82, хотя у 83 более высокий weight. Полная цепочка >> при отказах - 82->83->81 >> Учитывается ли вес в такой конфигурации ? >> С более высокими весами начинает работать как нужно 83->82->81 >> upstream backend { >> hash 'http_balance'; >> server [::1]:81 weight=1 fail_timeout=60; >> server [::1]:82 weight=10 fail_timeout=60; >> server [::1]:83 weight=100 fail_timeout=60; >> } >> Хотелось бы понимать это совпадение или веса принимаются в расчет при >> выборе hash-а? >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine на gmail.com Fri Nov 6 18:33:12 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 6 Nov 2020 23:33:12 +0500 Subject: upstream priority In-Reply-To: References: Message-ID: все верно, первый бекенд - с максимальным весом, бекапом - следующий (который устроен аналогично) но я бы не играл с error_page, это запутано получается. что именно редиректить на error_page, 502 ? 504 ? собственные 502 или проксированные ? в общем, сложно это. пт, 6 нояб. 2020 г. в 23:17, Nikita Koshikov : > Спасибо, > Имеется ввиду два бекенда один из который с backup ? > > upstream c1 { > server [::1]:81 ; > server [::1]:82 backup; > } > > upstream c2 { > server [::1]:83 ; > server [::1]:84 backup; > } > > server { > location { > proxy_pass http://c1 > error_page @c2 > } > } > Или что-то другое ? > > On Fri, Nov 6, 2020 at 9:52 AM Илья Шипицин wrote: > > > > можно проксировать на самого себя каскадом. > > на каждом каскаде 2 бекенда > > > > пт, 6 нояб. 2020 г. в 22:40, Nikita Koshikov : > >> > >> Доброго всем времени суток > >> > >> Подскажите как можно сделать что-то максимально подобное для выбора > >> backend сервера по приоритету, в идеале нужно что-то > >> > >> upstream backend { > >> server [::1]:81 priority=1; > >> server [::1]:82 priority=2; > >> server [::1]:83 priority=3; > >> server [::1]:84 priority=4; > >> server [::1]:85 priority=5; > >> } > >> т.е. пока жив хоть один с более высоким приоритетом - слать запросы на > него ? > >> > >> Из того что пробовал > >> upstream backend { > >> server [::1]:81 weight=1; > >> server [::1]:83 backup; > >> } > >> Так работает - однако не поддерживает 2+ бекенда > >> > >> Из самого близкого что удалось сделать - через hash со статичным ключом > >> upstream backend { > >> hash 'http_balance'; > >> server [::1]:81 weight=1 fail_timeout=60; > >> server [::1]:82 weight=2 fail_timeout=60; > >> server [::1]:83 weight=3 fail_timeout=60; > >> } > >> Проблема только что веса не всегда работают, - в данной конфигурации > >> выбирается server:82, хотя у 83 более высокий weight. Полная цепочка > >> при отказах - 82->83->81 > >> Учитывается ли вес в такой конфигурации ? > >> С более высокими весами начинает работать как нужно 83->82->81 > >> upstream backend { > >> hash 'http_balance'; > >> server [::1]:81 weight=1 fail_timeout=60; > >> server [::1]:82 weight=10 fail_timeout=60; > >> server [::1]:83 weight=100 fail_timeout=60; > >> } > >> Хотелось бы понимать это совпадение или веса принимаются в расчет при > >> выборе hash-а? > >> _______________________________________________ > >> nginx-ru mailing list > >> nginx-ru на nginx.org > >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From koshikov на gmail.com Fri Nov 6 18:42:32 2020 From: koshikov на gmail.com (Nikita Koshikov) Date: Fri, 6 Nov 2020 10:42:32 -0800 Subject: upstream priority In-Reply-To: References: Message-ID: Спасибо Хотелось бы еще услышать ответ на вопрос про веса и 'hash' при выборе бекендов Если можно - укажите пожалуйста в коде где это считается - дальше разбирусь On Fri, Nov 6, 2020 at 10:33 AM Илья Шипицин wrote: > > все верно, первый бекенд - с максимальным весом, бекапом - следующий (который устроен аналогично) > > но я бы не играл с error_page, это запутано получается. что именно редиректить на error_page, 502 ? 504 ? собственные 502 или проксированные ? > в общем, сложно это. > > пт, 6 нояб. 2020 г. в 23:17, Nikita Koshikov : >> >> Спасибо, >> Имеется ввиду два бекенда один из который с backup ? >> >> upstream c1 { >> server [::1]:81 ; >> server [::1]:82 backup; >> } >> >> upstream c2 { >> server [::1]:83 ; >> server [::1]:84 backup; >> } >> >> server { >> location { >> proxy_pass http://c1 >> error_page @c2 >> } >> } >> Или что-то другое ? >> >> On Fri, Nov 6, 2020 at 9:52 AM Илья Шипицин wrote: >> > >> > можно проксировать на самого себя каскадом. >> > на каждом каскаде 2 бекенда >> > >> > пт, 6 нояб. 2020 г. в 22:40, Nikita Koshikov : >> >> >> >> Доброго всем времени суток >> >> >> >> Подскажите как можно сделать что-то максимально подобное для выбора >> >> backend сервера по приоритету, в идеале нужно что-то >> >> >> >> upstream backend { >> >> server [::1]:81 priority=1; >> >> server [::1]:82 priority=2; >> >> server [::1]:83 priority=3; >> >> server [::1]:84 priority=4; >> >> server [::1]:85 priority=5; >> >> } >> >> т.е. пока жив хоть один с более высоким приоритетом - слать запросы на него ? >> >> >> >> Из того что пробовал >> >> upstream backend { >> >> server [::1]:81 weight=1; >> >> server [::1]:83 backup; >> >> } >> >> Так работает - однако не поддерживает 2+ бекенда >> >> >> >> Из самого близкого что удалось сделать - через hash со статичным ключом >> >> upstream backend { >> >> hash 'http_balance'; >> >> server [::1]:81 weight=1 fail_timeout=60; >> >> server [::1]:82 weight=2 fail_timeout=60; >> >> server [::1]:83 weight=3 fail_timeout=60; >> >> } >> >> Проблема только что веса не всегда работают, - в данной конфигурации >> >> выбирается server:82, хотя у 83 более высокий weight. Полная цепочка >> >> при отказах - 82->83->81 >> >> Учитывается ли вес в такой конфигурации ? >> >> С более высокими весами начинает работать как нужно 83->82->81 >> >> upstream backend { >> >> hash 'http_balance'; >> >> server [::1]:81 weight=1 fail_timeout=60; >> >> server [::1]:82 weight=10 fail_timeout=60; >> >> server [::1]:83 weight=100 fail_timeout=60; >> >> } >> >> Хотелось бы понимать это совпадение или веса принимаются в расчет при >> >> выборе hash-а? >> >> _______________________________________________ >> >> nginx-ru mailing list >> >> nginx-ru на nginx.org >> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru на nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin на mdounin.ru Fri Nov 6 18:49:10 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 6 Nov 2020 21:49:10 +0300 Subject: upstream priority In-Reply-To: References: Message-ID: <20201106184910.GE1147@mdounin.ru> Hello! On Fri, Nov 06, 2020 at 09:40:14AM -0800, Nikita Koshikov wrote: > Доброго всем времени суток > > Подскажите как можно сделать что-то максимально подобное для выбора > backend сервера по приоритету, в идеале нужно что-то > > upstream backend { > server [::1]:81 priority=1; > server [::1]:82 priority=2; > server [::1]:83 priority=3; > server [::1]:84 priority=4; > server [::1]:85 priority=5; > } > т.е. пока жив хоть один с более высоким приоритетом - слать запросы на него ? > > Из того что пробовал > upstream backend { > server [::1]:81 weight=1; > server [::1]:83 backup; > } > Так работает - однако не поддерживает 2+ бекенда Если хочется строгий порядок перебора бэкендов, то стоит посмотреть в сторону перенаправления по error_page. E.g.: location / { proxy_pass http://[::1]:81; error_page 502 504 @second; recursive_error_pages on; } location @second { proxy_pass http://[::1]:82; error_page 502 504 @third; recursive_error_pages on; } location @third { proxy_pass http://[::1]:82; } В зависимости от конкретных потребностей можно добавить proxy_intercept_errors и соответственно другие error_page по вкусу. > Из самого близкого что удалось сделать - через hash со статичным ключом > upstream backend { > hash 'http_balance'; > server [::1]:81 weight=1 fail_timeout=60; > server [::1]:82 weight=2 fail_timeout=60; > server [::1]:83 weight=3 fail_timeout=60; > } > Проблема только что веса не всегда работают, - в данной конфигурации > выбирается server:82, хотя у 83 более высокий weight. Полная цепочка > при отказах - 82->83->81 > Учитывается ли вес в такой конфигурации ? > С более высокими весами начинает работать как нужно 83->82->81 > upstream backend { > hash 'http_balance'; > server [::1]:81 weight=1 fail_timeout=60; > server [::1]:82 weight=10 fail_timeout=60; > server [::1]:83 weight=100 fail_timeout=60; > } > Хотелось бы понимать это совпадение или веса принимаются в расчет при > выборе hash-а? Вес - это не приоритет, а ручка для управления долей запросов, которые пойдут на конкретный бэкенд. Вес, естественно, при выборе бэкенда учитывается, но в том смысле, что на бэкенд с весом 10 - в среднем, в предположении случайных ключей - будет отправлено в 10 раз больше запросов, чем на бэкенд с весом 1. В случае ошибок - происходит перехэширования запроса с другим ключом, с добавлением к ключу количества перехэширований. И соответственно для конкретного ключа - последовательность бэкендов будет фиксированная, но для каждого ключа при этом своя. Но есть нюанс: если за 20 перехэширований nginx не найдёт бэкенд, на который ещё не ходил - он сдастся и переключится на round-robin балансировку, где живой бэкенд, если он есть, можно гарантировано выбрать за фиксированное количество операций. Соответственно подобрать такой статический ключ и такое распределение весов, при котором для данного ключа будет нужная вам последовательность перебора бэкендов - в принципе можно. Но это не то, как должена работать hash-балансировка, и скорее всего для сложных случаев вы просто устанете подбирать. Ну и, понятно, поддерживать это будет непросто. -- Maxim Dounin http://mdounin.ru/ From koshikov на gmail.com Fri Nov 6 19:28:16 2020 From: koshikov на gmail.com (Nikita Koshikov) Date: Fri, 6 Nov 2020 11:28:16 -0800 Subject: upstream priority In-Reply-To: <20201106184910.GE1147@mdounin.ru> References: <20201106184910.GE1147@mdounin.ru> Message-ID: Спасибо больше, Максим Хотелось бы уточнить насчет перехешированных ключей Вот конфигурация upstream backend { hash 'balance'; server [::1]:81 weight=100 fail_timeout=60; server [::1]:82 weight=100 fail_timeout=60; server [::1]:83 weight=1 fail_timeout=60; server [::1]:84 weight=1 fail_timeout=60; } Ключ статический, соответственно все запросы должны повторять цепочку отказов, однако на практике происходит так: 81->82 или 82->81 - пока кто-нибудь из них жив. Когда оба недоступны один и тот же запрос балансирует 83/84/83/84... Количество в данном примере 4 и не должно попадать под критерий 20+. Это баг или мое недопонимание как должен работать hash в данном конкретном примере ? (nginx/1.16.1) On Fri, Nov 6, 2020 at 10:49 AM Maxim Dounin wrote: > > Hello! > > On Fri, Nov 06, 2020 at 09:40:14AM -0800, Nikita Koshikov wrote: > > > Доброго всем времени суток > > > > Подскажите как можно сделать что-то максимально подобное для выбора > > backend сервера по приоритету, в идеале нужно что-то > > > > upstream backend { > > server [::1]:81 priority=1; > > server [::1]:82 priority=2; > > server [::1]:83 priority=3; > > server [::1]:84 priority=4; > > server [::1]:85 priority=5; > > } > > т.е. пока жив хоть один с более высоким приоритетом - слать запросы на него ? > > > > Из того что пробовал > > upstream backend { > > server [::1]:81 weight=1; > > server [::1]:83 backup; > > } > > Так работает - однако не поддерживает 2+ бекенда > > Если хочется строгий порядок перебора бэкендов, то стоит > посмотреть в сторону перенаправления по error_page. E.g.: > > location / { > proxy_pass http://[::1]:81; > error_page 502 504 @second; > recursive_error_pages on; > } > > location @second { > proxy_pass http://[::1]:82; > error_page 502 504 @third; > recursive_error_pages on; > } > > location @third { > proxy_pass http://[::1]:82; > } > > В зависимости от конкретных потребностей можно добавить > proxy_intercept_errors и соответственно другие error_page по > вкусу. > > > Из самого близкого что удалось сделать - через hash со статичным ключом > > upstream backend { > > hash 'http_balance'; > > server [::1]:81 weight=1 fail_timeout=60; > > server [::1]:82 weight=2 fail_timeout=60; > > server [::1]:83 weight=3 fail_timeout=60; > > } > > Проблема только что веса не всегда работают, - в данной конфигурации > > выбирается server:82, хотя у 83 более высокий weight. Полная цепочка > > при отказах - 82->83->81 > > Учитывается ли вес в такой конфигурации ? > > С более высокими весами начинает работать как нужно 83->82->81 > > upstream backend { > > hash 'http_balance'; > > server [::1]:81 weight=1 fail_timeout=60; > > server [::1]:82 weight=10 fail_timeout=60; > > server [::1]:83 weight=100 fail_timeout=60; > > } > > Хотелось бы понимать это совпадение или веса принимаются в расчет при > > выборе hash-а? > > Вес - это не приоритет, а ручка для управления долей запросов, > которые пойдут на конкретный бэкенд. Вес, естественно, при выборе > бэкенда учитывается, но в том смысле, что на бэкенд с весом 10 - в > среднем, в предположении случайных ключей - будет отправлено в 10 > раз больше запросов, чем на бэкенд с весом 1. > > В случае ошибок - происходит перехэширования запроса с другим > ключом, с добавлением к ключу количества перехэширований. И > соответственно для конкретного ключа - последовательность бэкендов > будет фиксированная, но для каждого ключа при этом своя. Но есть > нюанс: если за 20 перехэширований nginx не найдёт бэкенд, на > который ещё не ходил - он сдастся и переключится на round-robin > балансировку, где живой бэкенд, если он есть, можно гарантировано > выбрать за фиксированное количество операций. > > Соответственно подобрать такой статический ключ и такое > распределение весов, при котором для данного ключа будет нужная > вам последовательность перебора бэкендов - в принципе можно. Но > это не то, как должена работать hash-балансировка, и скорее всего > для сложных случаев вы просто устанете подбирать. Ну и, понятно, > поддерживать это будет непросто. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin на mdounin.ru Fri Nov 6 21:53:07 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 7 Nov 2020 00:53:07 +0300 Subject: upstream priority In-Reply-To: References: <20201106184910.GE1147@mdounin.ru> Message-ID: <20201106215307.GF1147@mdounin.ru> Hello! On Fri, Nov 06, 2020 at 11:28:16AM -0800, Nikita Koshikov wrote: > Спасибо больше, Максим > > Хотелось бы уточнить насчет перехешированных ключей > Вот конфигурация > upstream backend { > hash 'balance'; > server [::1]:81 weight=100 fail_timeout=60; > server [::1]:82 weight=100 fail_timeout=60; > server [::1]:83 weight=1 fail_timeout=60; > server [::1]:84 weight=1 fail_timeout=60; > } > > Ключ статический, соответственно все запросы должны повторять цепочку > отказов, однако на практике происходит так: > 81->82 или 82->81 - пока кто-нибудь из них жив. Когда оба недоступны > один и тот же запрос балансирует 83/84/83/84... > Количество в данном примере 4 и не должно попадать под критерий 20+. > Это баг или мое недопонимание как должен работать hash в данном > конкретном примере ? (nginx/1.16.1) Сколько в данном примере было попыток рехэширования - мы не знаем, так как при рехэшировании никто не гарантирует, что мы попадём на работающий бэкенд. Если мы снова попадаем на неработающий и/или испробованныый в рамках конкретного запроса бэкенд - происходит ещё одно рехэширование. В приведённом примере конфигурации после смерти бэкендов 81 и 82 вероятность попасть на "живой" бэкенд при очередном рехэшировании около 1 процента, а с вероятностью 99% нам потребуется делать рехэширование снова. Поскольку ограничение сработает на 20 попытках рехэширования - с вероятностью около 80% мы в это ограничение уткнёмся и выбор бэкенда будет делаться с помощью round-robin балансировки. Резюмируя вышесказанное: нет, это не баг, это ровно то, про что было сказано в предыдущем письме - устанете подбирать. Ибо с одной стороны надо обеспечить нужную последовательнось выбора бэкендов, а с другой - не выйти за ограничение в 20 попыток рехэширования. Если хочется всё-таки развлекаться - я бы смотрел в сторону алгоритма "сделать десяток/сотню фиктивных серверов, посмотреть, куда попадает запрос, и вписать нужные бэкенды на соответствующие места". Но, повторюсь, гораздо более прямой способ задать порядок явно - через error_page. -- Maxim Dounin http://mdounin.ru/ From koshikov на gmail.com Fri Nov 6 22:55:16 2020 From: koshikov на gmail.com (Nikita Koshikov) Date: Fri, 6 Nov 2020 14:55:16 -0800 Subject: upstream priority In-Reply-To: <20201106215307.GF1147@mdounin.ru> References: <20201106184910.GE1147@mdounin.ru> <20201106215307.GF1147@mdounin.ru> Message-ID: Еще раз спасибо за ответ и хороших выходных On Fri, Nov 6, 2020 at 1:53 PM Maxim Dounin wrote: > > Hello! > > On Fri, Nov 06, 2020 at 11:28:16AM -0800, Nikita Koshikov wrote: > > > Спасибо больше, Максим > > > > Хотелось бы уточнить насчет перехешированных ключей > > Вот конфигурация > > upstream backend { > > hash 'balance'; > > server [::1]:81 weight=100 fail_timeout=60; > > server [::1]:82 weight=100 fail_timeout=60; > > server [::1]:83 weight=1 fail_timeout=60; > > server [::1]:84 weight=1 fail_timeout=60; > > } > > > > Ключ статический, соответственно все запросы должны повторять цепочку > > отказов, однако на практике происходит так: > > 81->82 или 82->81 - пока кто-нибудь из них жив. Когда оба недоступны > > один и тот же запрос балансирует 83/84/83/84... > > Количество в данном примере 4 и не должно попадать под критерий 20+. > > Это баг или мое недопонимание как должен работать hash в данном > > конкретном примере ? (nginx/1.16.1) > > Сколько в данном примере было попыток рехэширования - мы не знаем, > так как при рехэшировании никто не гарантирует, что мы попадём на > работающий бэкенд. Если мы снова попадаем на неработающий и/или > испробованныый в рамках конкретного запроса бэкенд - происходит > ещё одно рехэширование. > > В приведённом примере конфигурации после смерти бэкендов 81 и 82 > вероятность попасть на "живой" бэкенд при очередном рехэшировании > около 1 процента, а с вероятностью 99% нам потребуется делать > рехэширование снова. Поскольку ограничение сработает на 20 > попытках рехэширования - с вероятностью около 80% мы в это > ограничение уткнёмся и выбор бэкенда будет делаться с помощью > round-robin балансировки. > > Резюмируя вышесказанное: нет, это не баг, это ровно то, про что > было сказано в предыдущем письме - устанете подбирать. Ибо с > одной стороны надо обеспечить нужную последовательнось выбора > бэкендов, а с другой - не выйти за ограничение в 20 попыток > рехэширования. > > Если хочется всё-таки развлекаться - я бы смотрел в сторону > алгоритма "сделать десяток/сотню фиктивных серверов, посмотреть, > куда попадает запрос, и вписать нужные бэкенды на соответствующие > места". Но, повторюсь, гораздо более прямой способ задать порядок > явно - через error_page. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Sun Nov 8 09:24:47 2020 From: nginx-forum на forum.nginx.org (redidka812) Date: Sun, 08 Nov 2020 04:24:47 -0500 Subject: =?UTF-8?B?bmdpbngg0Lgg0L7QsdGA0LDRgtC90L7QtSDQv9GA0L7QutGB0LjRgNC+0LLQsNC9?= =?UTF-8?B?0LjQtSBzb2NrczU/?= Message-ID: <12e8ca9df71710c2332a609150fe5220.NginxMailingListRussian@forum.nginx.org> Подскажите а можно ли настроить ngnix для работы с soscks5? Есть privoxy -soksk5 настроенная для заворота трафика в tor.. Работает на порту 8118 Для ее использования в настройках прокси браузера соответственно надо указать ip:8118 -так все работает, но держать открытым и проброшенным за NAT порт без авторизации не очень правильно.. Хочу настроить ngnix , ,,чтоб убрать 8118 из пророщенных портов.. Делаю listen 8080 { location /privoxy/ { proxy_pass http://127.0.0.1:8118/; } Где 8080-порт который слушает nginx и именно он будет проброшен за NAT /privoxy/ -имя которое будет слушать nginx для проксирования на порт 8118 -и не работает, причем как-то странно, если в браузере изменить сокс с :ip:8118 на IP:8080/privoxy -еше пару минут работает, и трафик идёт через тор, но после пары обновлений страницы(сек через 30)- сокс похоже отваливается и в сеть я выхожу с IP от провайдера, а не от выходной годы Тор, как если бы сокс работал.. Подскажите можно ли настроить корректно , или nginx не умеет работать как обратное пробки для socks5? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289908,289908#msg-289908 From nginx-forum на forum.nginx.org Sun Nov 8 09:25:22 2020 From: nginx-forum на forum.nginx.org (redidka812) Date: Sun, 08 Nov 2020 04:25:22 -0500 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQvdC+0LLQuNGH0LrQsCDQv9C+INGA0LXQtNC40YA=?= =?UTF-8?B?0LXQutGC0YMg0L3QsCDQvdC+0LzQtdGAINC/0L7RgNGC0LA=?= In-Reply-To: References: Message-ID: Подскажите а можно ли настроить ngnix для работы с soscks5? Есть privoxy -soksk5 настроенная для заворота трафика в tor.. Работает на порту 8118 Для ее использования в настройках прокси браузера соответственно надо указать ip:8118 -так все работает, но держать открытым и проброшенным за NAT порт без авторизации не очень правильно.. Хочу настроить ngnix , ,,чтоб убрать 8118 из пророщенных портов.. Делаю listen 8080 { location /privoxy/ { proxy_pass http://127.0.0.1:8118/; } Где 8080-порт который слушает nginx и именно он будет проброшен за NAT /privoxy/ -имя которое будет слушать nginx для проксирования на порт 8118 -и не работает, причем как-то странно, если в браузере изменить сокс с :ip:8118 на IP:8080/privoxy -еше пару минут работает, и трафик идёт через тор, но после пары обновлений страницы(сек через 30)- сокс похоже отваливается и в сеть я выхожу с IP от провайдера, а не от выходной годы Тор, как если бы сокс работал.. Подскажите можно ли настроить корректно , или nginx не умеет работать как обратное пробки для socks5? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289885,289906#msg-289906 From nginx-forum на forum.nginx.org Sun Nov 8 10:59:22 2020 From: nginx-forum на forum.nginx.org (redidka812) Date: Sun, 08 Nov 2020 05:59:22 -0500 Subject: =?UTF-8?B?cHJveHkgcGFzcyDQv9C10YDQtdC90LDQv9GA0LDQstC70LXQvdC40LUg0L3QsCA=?= =?UTF-8?B?0LTRgNGD0LPQvtC5INC/0L7RgNGCIDQwNCDQutCw0Log0L/QvtCx0L7RgNC+?= =?UTF-8?B?0YLRjD8=?= Message-ID: Есть служба работающая на локальной машине в частности torrserver, отзывается на порту 8090. хочу доступ к ней из интернета не через проброс порта 8090 за NAT, а через nginx(чтоб не создавать кучу портов за NAT о всех служб что есть в домашней сети, темболее часть из них без авторизации.. Итак делаю: server { proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; listen 8080 ; location /torrserver/ { proxy_pass http://127.0.0.1:8090/; } Где 8080 порт проброшеный за NAT от nginx /torrserver/ - имя службы по которому nginx будет перенаправлять запросы на порт 8090 И вводя в браузере IP:8080/torrserver Я попадаю на веб морду от to reserve слушаюшую на удаленной машине порт 8090, казалось бы вот оно счастье, но.... Все кнопки/управление на этой странице возвращают ошибку 404 Потому как происходит запрос другого адреса Например "настройки" Вида IP:8090/settings И.т.д.. Если бы я заходил по 8090 то все бы работало.. Через nginx при 8080/torrserver разумеется нет потому как страница 8090/settings в nginx не существует.. Хочу так настроить редирект/проксирование Чтоб открыв страницу по IP:8080/tiorrserver Функционирование/переход с этой страницы по кнопкам управления на ней также шел через nginx Т.е. при клике например по томуже settings запрос уходил к 8080/torrserver/settings а не к 8090/settings Можно ли это реализовать? С помощью каких команд в конфиге nginx не в смысле конкретно /settings/ а все ссылки на этой странице обрабатывались как будто бы nginx между пользователем и службой torrserver вообще отсутствует , (не знаю как правильно сформулировать, своими словами, чтоб при удаленном доступе вместо IP:8090(проброшенрого порта 8090) служба отзывалась на IP:8080/transmission/ и полностью функционировало управление... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289911,289911#msg-289911 From red-fox0 на ya.ru Sun Nov 8 11:06:56 2020 From: red-fox0 на ya.ru (fox) Date: Sun, 8 Nov 2020 18:06:56 +0700 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC9?= =?UTF-8?B?0LAg0LTRgNGD0LPQvtC5INC/0L7RgNGCIDQwNCDQutCw0Log0L/QvtCx0L4=?= =?UTF-8?B?0YDQvtGC0Yw/?= In-Reply-To: References: Message-ID: <65ad57ad-3617-547d-b87c-189f97532221@ya.ru> Можно попробовать обрезать префикс из запроса, не знаю будет ли работать location /torrserver/ { rewrite ^/torrserver/(.*) /$1 break; proxy_pass http://127.0.0.1:8090/$uri$is_args$args; } Расскажешь, заработало ли? 08.11.2020 17:59, redidka812 пишет: > Есть служба работающая на локальной машине в частности torrserver, > отзывается на порту 8090. хочу доступ к ней из интернета не через проброс > порта 8090 за NAT, а через nginx(чтоб не создавать кучу портов за NAT о > всех служб что есть в домашней сети, темболее часть из них без > авторизации.. > Итак делаю: > server { > proxy_redirect off; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > listen 8080 ; > location /torrserver/ { > proxy_pass http://127.0.0.1:8090/; > > } > Где 8080 порт проброшеный за NAT от nginx > /torrserver/ - имя службы по которому nginx будет перенаправлять запросы на > порт 8090 > > И вводя в браузере > IP:8080/torrserver > Я попадаю на веб морду от to reserve слушаюшую на удаленной машине порт > 8090, казалось бы вот оно счастье, но.... > Все кнопки/управление на этой странице возвращают ошибку 404 > Потому как происходит запрос другого адреса > Например "настройки" > Вида > IP:8090/settings > И.т.д.. > Если бы я заходил по 8090 то все бы работало.. > Через nginx при 8080/torrserver разумеется нет потому как страница > 8090/settings в nginx не существует.. > Хочу так настроить редирект/проксирование > Чтоб открыв страницу по > IP:8080/tiorrserver > Функционирование/переход с этой страницы по кнопкам управления на ней также > шел через nginx > Т.е. при клике например по томуже settings запрос уходил к > 8080/torrserver/settings а не к 8090/settings > > Можно ли это реализовать? С помощью каких команд в конфиге nginx не в > смысле конкретно /settings/ а все ссылки на этой странице обрабатывались > как будто бы nginx между пользователем и службой torrserver вообще > отсутствует , (не знаю как правильно сформулировать, своими словами, чтоб > при удаленном доступе вместо IP:8090(проброшенрого порта 8090) служба > отзывалась на IP:8080/transmission/ и полностью функционировало > управление... > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289911,289911#msg-289911 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From red-fox0 на ya.ru Sun Nov 8 11:09:03 2020 From: red-fox0 на ya.ru (fox) Date: Sun, 8 Nov 2020 18:09:03 +0700 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC9?= =?UTF-8?B?0LAg0LTRgNGD0LPQvtC5INC/0L7RgNGCIDQwNCDQutCw0Log0L/QvtCx0L4=?= =?UTF-8?B?0YDQvtGC0Yw/?= In-Reply-To: <65ad57ad-3617-547d-b87c-189f97532221@ya.ru> References: <65ad57ad-3617-547d-b87c-189f97532221@ya.ru> Message-ID: И ещё: sub_filter 'href="/' 'href="/torrserver/'; sub_filter_once on; 08.11.2020 18:06, fox пишет: > Можно попробовать обрезать префикс из запроса, не знаю будет ли работать > > location /torrserver/ { > rewrite ^/torrserver/(.*) /$1 break; > proxy_pass http://127.0.0.1:8090/$uri$is_args$args; > } > > Расскажешь, заработало ли? > > > 08.11.2020 17:59, redidka812 пишет: >> Есть служба работающая на локальной машине в частности torrserver, >> отзывается на порту 8090. хочу доступ к ней из интернета не через проброс >> порта 8090 за NAT, а через nginx(чтоб не создавать кучу портов за NAT о >> всех служб что есть в домашней сети, темболее часть из них без >> авторизации.. >> Итак делаю: >> server { >> proxy_redirect off; >> proxy_set_header Host $host; >> proxy_set_header X-Real-IP $remote_addr; >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> listen 8080 ; >> location /torrserver/ { >> proxy_pass http://127.0.0.1:8090/; >> >> } >> Где 8080 порт проброшеный за NAT от nginx >> /torrserver/ - имя службы по которому nginx будет перенаправлять запросы на >> порт 8090 >> >> И вводя в браузере >> IP:8080/torrserver >> Я попадаю на веб морду от to reserve слушаюшую на удаленной машине порт >> 8090, казалось бы вот оно счастье, но.... >> Все кнопки/управление на этой странице возвращают ошибку 404 >> Потому как происходит запрос другого адреса >> Например "настройки" >> Вида >> IP:8090/settings >> И.т.д.. >> Если бы я заходил по 8090 то все бы работало.. >> Через nginx при 8080/torrserver разумеется нет потому как страница >> 8090/settings в nginx не существует.. >> Хочу так настроить редирект/проксирование >> Чтоб открыв страницу по >> IP:8080/tiorrserver >> Функционирование/переход с этой страницы по кнопкам управления на ней также >> шел через nginx >> Т.е. при клике например по томуже settings запрос уходил к >> 8080/torrserver/settings а не к 8090/settings >> >> Можно ли это реализовать? С помощью каких команд в конфиге nginx не в >> смысле конкретно /settings/ а все ссылки на этой странице обрабатывались >> как будто бы nginx между пользователем и службой torrserver вообще >> отсутствует , (не знаю как правильно сформулировать, своими словами, чтоб >> при удаленном доступе вместо IP:8090(проброшенрого порта 8090) служба >> отзывалась на IP:8080/transmission/ и полностью функционировало >> управление... >> >> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289911,289911#msg-289911 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum на forum.nginx.org Tue Nov 10 06:26:24 2020 From: nginx-forum на forum.nginx.org (redidka812) Date: Tue, 10 Nov 2020 01:26:24 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC9?= =?UTF-8?B?0LAg0LTRgNGD0LPQvtC5INC/0L7RgNGCIDQwNCDQutCw0Log0L/QvtCx0L4=?= =?UTF-8?B?0YDQvtGC0Yw/?= In-Reply-To: <65ad57ad-3617-547d-b87c-189f97532221@ya.ru> References: <65ad57ad-3617-547d-b87c-189f97532221@ya.ru> Message-ID: Спасибо из любопытства конечно попробую и отпишу, а так я уже сдался, плюнул реализовать задуманное через nginx, и поставил VPN сервер, а все проброшенные порты на маршрутизаторе, закрыл ,и при необходимости просто включаю VPN и через него попадаю ко всем ресурсам домашней сети как будто бы я в ней нахожусь.. А раз столько времени потратил на выкуривание nginx, конечно попробую ваш вариант, вдруг потом пригодится. Спасибо. К вечеру или завтра отпишу получилось или нет Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289912,289940#msg-289940 From nginx-forum на forum.nginx.org Tue Nov 10 09:53:38 2020 From: nginx-forum на forum.nginx.org (fleedstix) Date: Tue, 10 Nov 2020 04:53:38 -0500 Subject: =?UTF-8?B?0JDQstGC0L7RgNC40LfQsNGG0LjRjyDQv9GA0Lgg0L/RgNC+0LrRgdC40YDQvtCy?= =?UTF-8?B?0LDQvdC40Lg=?= Message-ID: Добрый день! подскажите пожалуйста как можно реализовать авторизацию при проксировании. Есть два сервера(бекенд и фронт). По требованиям безопасности необходимо чтобы было проксирование с фронта на бек по защищенному соединению с авторизацией. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289943,289943#msg-289943 From andrey на kopeyko.ru Tue Nov 10 22:28:32 2020 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 11 Nov 2020 01:28:32 +0300 Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8g0L/RgNC4INC/0YDQvtC60YHQuNGA?= =?UTF-8?B?0L7QstCw0L3QuNC4?= In-Reply-To: References: Message-ID: <990904c06138b58fa3c78ad3a29cfb96@kopeyko.ru> fleedstix писал 2020-11-10 12:53: > Добрый день! Вечер добрый! > подскажите пожалуйста как можно реализовать авторизацию при > проксировании. Есть два сервера(бекенд и фронт). По требованиям > безопасности > необходимо чтобы было проксирование с фронта на бек по защищенному > соединению с авторизацией. Если вы уверены в безопасности вашего фронтенда - можно прямо в конфигурации добавлять заголовок "Authorization: Basic XYZ" в заголовки запроса к бэкенду. -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Wed Nov 11 06:08:30 2020 From: nginx-forum на forum.nginx.org (redidka812) Date: Wed, 11 Nov 2020 01:08:30 -0500 Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC9?= =?UTF-8?B?0LAg0LTRgNGD0LPQvtC5INC/0L7RgNGCIDQwNCDQutCw0Log0L/QvtCx0L4=?= =?UTF-8?B?0YDQvtGC0Yw/?= In-Reply-To: References: <65ad57ad-3617-547d-b87c-189f97532221@ya.ru> Message-ID: <04fe89532d7b2ab8df1a0c19256e07cc.NginxMailingListRussian@forum.nginx.org> Увы также самая 404 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289912,289958#msg-289958 From nginx-forum на forum.nginx.org Wed Nov 11 09:49:15 2020 From: nginx-forum на forum.nginx.org (zooleen) Date: Wed, 11 Nov 2020 04:49:15 -0500 Subject: =?UTF-8?B?UmU6IDQwNCDQv9GA0L7QsdC70LXQvNCwINGBIHN0dWIgc3RhdHVz?= In-Reply-To: <1b0a81dc817c0ee9c7b2230f39a04b03.NginxMailingListRussian@forum.nginx.org> References: <1b0a81dc817c0ee9c7b2230f39a04b03.NginxMailingListRussian@forum.nginx.org> Message-ID: Скорее всего, нужно изменить строку listen следующим образом: listen [::]:80; Чтобы сервер слушал 80 порт и по ipv6, у которого приоритет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,216178,289959#msg-289959 From mdounin на mdounin.ru Tue Nov 24 15:19:19 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 24 Nov 2020 18:19:19 +0300 Subject: nginx-1.19.5 Message-ID: <20201124151919.GN1147@mdounin.ru> Изменения в nginx 1.19.5 24.11.2020 *) Добавление: ключ -e. *) Добавление: при сборке дополнительных модулей теперь можно указывать одни и те же исходные файлы в разных модулях. *) Исправление: SSL shutdown не работал при закрытии соединений с ожиданием дополнительных данных (lingering close). *) Исправление: при работе с gRPC-бэкендами могли возникать ошибки "upstream sent frame for closed stream". *) Исправление: во внутреннем API для обработки тела запроса. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Mon Nov 30 18:58:59 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 30 Nov 2020 23:58:59 +0500 Subject: =?UTF-8?B?0YHRgtGA0LDQvdC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUgQ2hyb21lINC90LAg?= =?UTF-8?B?aHR0cDI=?= Message-ID: привет! может кто сталкивался, и знает, что с этим можно сделать. ситуация - хостинг высокой плотности, на одном IP много доменов. домены разные, каждый со своей бизнес логикой. у Chrome включается какая-то оптимизация, и типа "ну раз IP один, то я буду весь трафик гонять через одно tcp подключение". все бы ничего, но некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не подключение до конкретного сайта, а вообще все, которые он умудрился связать с этим tcp подключением. частный пример - сайт, который иногда формирует очень длинные URL, не помещающиеся в дефолтный http2_max_field_fize, при возникновение такой ситуации Chrome рвет всё до этого IP адреса. как-то не по христиански чтоли. подумалось, что аналогичных хостингов высокой плотности в рассылке может быть достаточное количество. не первый же я с таким столкнулся? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Nov 30 23:11:15 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 1 Dec 2020 02:11:15 +0300 Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?= =?UTF-8?B?0L3QsCBodHRwMg==?= In-Reply-To: References: Message-ID: <20201130231115.GJ1147@mdounin.ru> Hello! On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote: > привет! > > может кто сталкивался, и знает, что с этим можно сделать. > ситуация - хостинг высокой плотности, на одном IP много доменов. > домены разные, каждый со своей бизнес логикой. > > у Chrome включается какая-то оптимизация, и типа "ну раз IP один, то я > буду весь трафик гонять через одно tcp подключение". все бы ничего, но > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не > подключение до конкретного сайта, а вообще все, которые он умудрился > связать с этим tcp подключением. > > частный пример - сайт, который иногда формирует очень длинные URL, не > помещающиеся в дефолтный http2_max_field_fize, при возникновение такой > ситуации Chrome рвет всё до этого IP адреса. > > как-то не по христиански чтоли. > > подумалось, что аналогичных хостингов высокой плотности в рассылке может > быть достаточное количество. не первый же я с таким столкнулся? Это называется connection reuse, правила прописаны тут: https://tools.ietf.org/html/rfc7540#section-9.1.1 В частности: For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI. То есть если хочется, чтобы соединения не reuse'ались, можно сконфигурировать разные сертификаты для разных серверов (или групп серверов). Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name. -- Maxim Dounin http://mdounin.ru/