From chipitsine на gmail.com Wed Feb 3 17:45:34 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 3 Feb 2021 22:45:34 +0500 Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?= =?UTF-8?B?0L3QsCBodHRwMg==?= In-Reply-To: <20201201134253.GN1147@mdounin.ru> References: <20201130231115.GJ1147@mdounin.ru> <20201201131320.GM1147@mdounin.ru> <20201201134253.GN1147@mdounin.ru> Message-ID: для истории - хром и сафари пытаются переиспользовать конекшин если отдавать 421, то хром переподключается (как и ожидается), а сафари превращается в тыкву. вт, 1 дек. 2020 г. в 18:43, Maxim Dounin : > Hello! > > On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote: > > > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin : > > > > > Hello! > > > > > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote: > > > > > > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin : > > > > > > > > > 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. > > > > > > > > > > > > > в исходниках это вот так > > > > > > > > if ((size_t) len > h2scf->max_field_size) { > > > > ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0, > > > > "client exceeded http2_max_field_size limit"); > > > > > > > > return ngx_http_v2_connection_error(h2c, > > > > NGX_HTTP_V2_ENHANCE_YOUR_CALM); > > > > } > > > > > > > > > > > > как можно в этом месте вернуть "по необходимости" 421 ? > > > > > > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим > > > соединением невозможна. Возвращать 421 надо заранее, до того, как > > > придёт кривой запрос. > > > > > > > > пардон. я не понимаю, что вы предлагаете. > > можете привести пример, как сделать ? > > Если добавить что-нибудь вроде: > > if ($ssl_server_name != "example.com") { > return 421; > } > > во все релевантные блоки server{}, это предотвратит reuse > соединений, кроме первых запросов. Соответственно соединения > будут отдельными, и при необходимости закрыть соединение - будет > закрываться только соединение с одним сервером, а не со всеми > серверами на данном IP. > > Ну и обращаю внимание на озвученный выше и проигнорированный > вариант разных сертификатов. Он позволяет контроллировать > поведение на стороне браузера и соответственно более эффективен, > т.к. нет проблемы первых запросов. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Feb 3 20:13:40 2021 From: nginx-forum на forum.nginx.org (slashik) Date: Wed, 03 Feb 2021 15:13:40 -0500 Subject: =?UTF-8?B?0JHQsNC70LDQvdGB0LjRgNC+0LLQutCwINGBIGJhY2t1cA==?= Message-ID: <37436635f83712252733c7557102da63.NginxMailingListRussian@forum.nginx.org> Добрый день форумчане! Возник вопрос. Настроена балансировка между 3 серверами. S1 weight =60 S2 weight=40 S3 backup Соответственно когда пропадают S1 И S2 задействуется S3. Как сделать, чтобы когда пропадает S1 ИЛИ S2 задействовался бы S3? Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290642,290642#msg-290642 From enp на itx.ru Mon Feb 8 16:15:43 2021 From: enp на itx.ru (Eugene Prokopiev) Date: Mon, 8 Feb 2021 19:15:43 +0300 Subject: Route by request method Message-ID: Здравствуйте! Требуется по GET /data.txt отдавать самый файл как есть, а по POST/PUT/DELETE /data.txt передавать запрос в какой-то бакенд через proxy_pass - по идее не самый редкий кейс, но никакого пример нагуглить не могу. Попробовал сделать так: location / { if ($request_method = 'GET') { root /data; } proxy_pass http://127.0.0.1:8080; } Но в if ничего не попадает. Я что-то делаю не неправильно? Или это вообще принято делать иначе? -- WBR, Eugene Prokopiev From red-fox0 на ya.ru Mon Feb 8 16:20:01 2021 From: red-fox0 на ya.ru (fox) Date: Mon, 8 Feb 2021 23:20:01 +0700 Subject: Route by request method In-Reply-To: References: Message-ID: <090a3ea7-ac5d-d336-b2d0-163c0bf4c045@ya.ru> Судя по гуглу, можно попробовать так: location / { if ($request_method = GET) { root /data; } if ($request_method != GET) { proxy_pass http://127.0.0.1:8080; } } 08.02.2021 23:15, Eugene Prokopiev пишет: > Здравствуйте! > > Требуется по GET /data.txt отдавать самый файл как есть, а по > POST/PUT/DELETE /data.txt передавать запрос в какой-то бакенд через > proxy_pass - по идее не самый редкий кейс, но никакого пример > нагуглить не могу. Попробовал сделать так: > > location / { > if ($request_method = 'GET') { > root /data; > } > proxy_pass http://127.0.0.1:8080; > } > > Но в if ничего не попадает. Я что-то делаю не неправильно? Или это > вообще принято делать иначе? > > From oleg на mamontov.net Mon Feb 8 21:24:02 2021 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Tue, 9 Feb 2021 00:24:02 +0300 Subject: Route by request method In-Reply-To: References: Message-ID: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> On Mon, Feb 08, 2021 at 07:15:43PM +0300, Eugene Prokopiev wrote: >Здравствуйте! > >Требуется по GET /data.txt отдавать самый файл как есть, а по >POST/PUT/DELETE /data.txt передавать запрос в какой-то бакенд через >proxy_pass - по идее не самый редкий кейс, но никакого пример >нагуглить не могу. Попробовал сделать так: > >location / { > if ($request_method = 'GET') { > root /data; > } > proxy_pass http://127.0.0.1:8080; >} > >Но в if ничего не попадает. Я что-то делаю не неправильно? Или это >вообще принято делать иначе? "Традиционный" подход - сделать по требуемому условию rewrite, уводящий обработку запроса в другой location. Обратите внимание - trailing slash в proxy_pass в данном случае имеет значение. --- location / { if ($request_method != 'GET') { rewrite ^/(.*) /proxy/$1 last; } root /data; } location /proxy/ { internal; proxy_pass http://127.0.0.1:8080/; } --- >-- >WBR, >Eugene Prokopiev >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cheers, Oleg A. Mamontov From gmm на csdoc.com Mon Feb 8 22:48:55 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 9 Feb 2021 00:48:55 +0200 Subject: Route by request method In-Reply-To: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> Message-ID: On 08.02.2021 23:24, Oleg A. Mamontov wrote: > "Традиционный" подход - сделать по требуемому условию rewrite, уводящий > обработку запроса в другой location. Обратите внимание - trailing slash > в proxy_pass в данном случае имеет значение. > --- > location / { >     if ($request_method != 'GET') { >         rewrite ^/(.*) /proxy/$1 last; >     } >     root /data; > } > location /proxy/ { >     internal; >     proxy_pass http://127.0.0.1:8080/; > } Возможно переход в именованный location с помощью директив "error_page 418 = @location; return 418;" будет лучше с точки зрения читабельности, чем rewrite директивы, делающие конфиг nginx похожим на конфиг sendmail? location / { if ($request_method != 'GET') { error_page 418 = @proxy; return 418; } root /data; } location @proxy { proxy_pass http://127.0.0.1:8080; } По-сути вот этот набор из двух директив: "error_page 418 = @location; return 418;" означает простое действие "goto @location;" -- Best regards, Gena From oleg на mamontov.net Tue Feb 9 08:17:12 2021 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Tue, 9 Feb 2021 11:17:12 +0300 Subject: Route by request method In-Reply-To: References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> Message-ID: <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote: >On 08.02.2021 23:24, Oleg A. Mamontov wrote: > >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий >>обработку запроса в другой location. Обратите внимание - trailing slash >>в proxy_pass в данном случае имеет значение. >>--- >>location / { >>     if ($request_method != 'GET') { >>         rewrite ^/(.*) /proxy/$1 last; >>     } >>     root /data; >>} >>location /proxy/ { >>     internal; >>     proxy_pass http://127.0.0.1:8080/; >>} > >Возможно переход в именованный location с помощью директив >"error_page 418 = @location; return 418;" будет лучше >с точки зрения читабельности, чем rewrite директивы, >делающие конфиг nginx похожим на конфиг sendmail? Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход с error_page лучше для решения поставленной задачи. Что вижу: нецелевое использование директивы / фиктивного статуса, появление лишней строки в конфиге и необходимость включать recursive_error_pages при использовании реальной обработки последующих ошибок проксирования. Но согласен - так делать тоже можно, TMTOWTDI >location / { > if ($request_method != 'GET') { > error_page 418 = @proxy; > return 418; > } > root /data; >} >location @proxy { > proxy_pass http://127.0.0.1:8080; >} > >По-сути вот этот набор из двух директив: >"error_page 418 = @location; return 418;" >означает простое действие "goto @location;" > >-- >Best regards, > Gena > >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From chipitsine на gmail.com Tue Feb 9 08:20:28 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 9 Feb 2021 13:20:28 +0500 Subject: Route by request method In-Reply-To: <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> Message-ID: можно на limit_except разрешить только GET. остальное попадет в запрет и навешать на него кастомную страницу ошибки вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov : > On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote: > >On 08.02.2021 23:24, Oleg A. Mamontov wrote: > > > >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий > >>обработку запроса в другой location. Обратите внимание - trailing slash > >>в proxy_pass в данном случае имеет значение. > >>--- > >>location / { > >> if ($request_method != 'GET') { > >> rewrite ^/(.*) /proxy/$1 last; > >> } > >> root /data; > >>} > >>location /proxy/ { > >> internal; > >> proxy_pass http://127.0.0.1:8080/; > >>} > > > >Возможно переход в именованный location с помощью директив > >"error_page 418 = @location; return 418;" будет лучше > >с точки зрения читабельности, чем rewrite директивы, > >делающие конфиг nginx похожим на конфиг sendmail? > > Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход > с error_page лучше для решения поставленной задачи. > > Что вижу: нецелевое использование директивы / фиктивного статуса, > появление лишней строки в конфиге и необходимость включать > recursive_error_pages при использовании реальной обработки последующих > ошибок проксирования. > > Но согласен - так делать тоже можно, TMTOWTDI > > >location / { > > if ($request_method != 'GET') { > > error_page 418 = @proxy; > > return 418; > > } > > root /data; > >} > >location @proxy { > > proxy_pass http://127.0.0.1:8080; > >} > > > >По-сути вот этот набор из двух директив: > >"error_page 418 = @location; return 418;" > >означает простое действие "goto @location;" > > > >-- > >Best regards, > > Gena > > > >_______________________________________________ > >nginx-ru mailing list > >nginx-ru на nginx.org > >http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > 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 enp на itx.ru Tue Feb 9 12:36:49 2021 From: enp на itx.ru (Eugene Prokopiev) Date: Tue, 9 Feb 2021 15:36:49 +0300 Subject: Route by request method In-Reply-To: References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> Message-ID: Всем спасибо! А нет ли чего-то среднего: передать запрос с помощью rewrite (это выглядит чище использования фиктивного статуса, хотя явный goto был бы еще чище) в именованный @location вместо internal (тогда переменная request_filename будет содержать правильное значение)? вт, 9 февр. 2021 г. в 11:20, Илья Шипицин : > > можно на limit_except разрешить только GET. остальное попадет в запрет и навешать на него кастомную страницу ошибки > > вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov : >> >> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote: >> >On 08.02.2021 23:24, Oleg A. Mamontov wrote: >> > >> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий >> >>обработку запроса в другой location. Обратите внимание - trailing slash >> >>в proxy_pass в данном случае имеет значение. >> >>--- >> >>location / { >> >> if ($request_method != 'GET') { >> >> rewrite ^/(.*) /proxy/$1 last; >> >> } >> >> root /data; >> >>} >> >>location /proxy/ { >> >> internal; >> >> proxy_pass http://127.0.0.1:8080/; >> >>} >> > >> >Возможно переход в именованный location с помощью директив >> >"error_page 418 = @location; return 418;" будет лучше >> >с точки зрения читабельности, чем rewrite директивы, >> >делающие конфиг nginx похожим на конфиг sendmail? >> >> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход >> с error_page лучше для решения поставленной задачи. >> >> Что вижу: нецелевое использование директивы / фиктивного статуса, >> появление лишней строки в конфиге и необходимость включать >> recursive_error_pages при использовании реальной обработки последующих >> ошибок проксирования. >> >> Но согласен - так делать тоже можно, TMTOWTDI >> >> >location / { >> > if ($request_method != 'GET') { >> > error_page 418 = @proxy; >> > return 418; >> > } >> > root /data; >> >} >> >location @proxy { >> > proxy_pass http://127.0.0.1:8080; >> >} >> > >> >По-сути вот этот набор из двух директив: >> >"error_page 418 = @location; return 418;" >> >означает простое действие "goto @location;" >> > >> >-- >> >Best regards, >> > Gena >> > >> >_______________________________________________ >> >nginx-ru mailing list >> >nginx-ru на nginx.org >> >http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> -- >> 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 -- WBR, Eugene Prokopiev From enp на itx.ru Tue Feb 9 12:46:47 2021 From: enp на itx.ru (Eugene Prokopiev) Date: Tue, 9 Feb 2021 15:46:47 +0300 Subject: Route by request method In-Reply-To: References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> Message-ID: Оказывается, это известный (и неудовлетворенный) фичреквест - http://mailman.nginx.org/pipermail/nginx-ru/2011-October/043596.html вт, 9 февр. 2021 г. в 15:36, Eugene Prokopiev : > > Всем спасибо! > > А нет ли чего-то среднего: передать запрос с помощью rewrite (это > выглядит чище использования фиктивного статуса, хотя явный goto был бы > еще чище) в именованный @location вместо internal (тогда переменная > request_filename будет содержать правильное значение)? > > вт, 9 февр. 2021 г. в 11:20, Илья Шипицин : > > > > можно на limit_except разрешить только GET. остальное попадет в запрет и навешать на него кастомную страницу ошибки > > > > вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov : > >> > >> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote: > >> >On 08.02.2021 23:24, Oleg A. Mamontov wrote: > >> > > >> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий > >> >>обработку запроса в другой location. Обратите внимание - trailing slash > >> >>в proxy_pass в данном случае имеет значение. > >> >>--- > >> >>location / { > >> >> if ($request_method != 'GET') { > >> >> rewrite ^/(.*) /proxy/$1 last; > >> >> } > >> >> root /data; > >> >>} > >> >>location /proxy/ { > >> >> internal; > >> >> proxy_pass http://127.0.0.1:8080/; > >> >>} > >> > > >> >Возможно переход в именованный location с помощью директив > >> >"error_page 418 = @location; return 418;" будет лучше > >> >с точки зрения читабельности, чем rewrite директивы, > >> >делающие конфиг nginx похожим на конфиг sendmail? > >> > >> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход > >> с error_page лучше для решения поставленной задачи. > >> > >> Что вижу: нецелевое использование директивы / фиктивного статуса, > >> появление лишней строки в конфиге и необходимость включать > >> recursive_error_pages при использовании реальной обработки последующих > >> ошибок проксирования. > >> > >> Но согласен - так делать тоже можно, TMTOWTDI > >> > >> >location / { > >> > if ($request_method != 'GET') { > >> > error_page 418 = @proxy; > >> > return 418; > >> > } > >> > root /data; > >> >} > >> >location @proxy { > >> > proxy_pass http://127.0.0.1:8080; > >> >} > >> > > >> >По-сути вот этот набор из двух директив: > >> >"error_page 418 = @location; return 418;" > >> >означает простое действие "goto @location;" > >> > > >> >-- > >> >Best regards, > >> > Gena > >> > > >> >_______________________________________________ > >> >nginx-ru mailing list > >> >nginx-ru на nginx.org > >> >http://mailman.nginx.org/mailman/listinfo/nginx-ru > >> > >> -- > >> 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 > > > > -- > WBR, > Eugene Prokopiev -- WBR, Eugene Prokopiev From oleg на mamontov.net Tue Feb 9 12:52:23 2021 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Tue, 9 Feb 2021 15:52:23 +0300 Subject: Route by request method In-Reply-To: References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> Message-ID: <20210209125223.pl4b7colcndeeql4@xenon.mamontov.net> On Tue, Feb 09, 2021 at 03:36:49PM +0300, Eugene Prokopiev wrote: >Всем спасибо! > >А нет ли чего-то среднего: передать запрос с помощью rewrite (это >выглядит чище использования фиктивного статуса, хотя явный goto был бы >еще чище) в именованный @location вместо internal (тогда переменная >request_filename будет содержать правильное значение)? Если вам хочется возвращать $uri в исходное значение, то это также достигается посредством rewrite, заодно тогда и trailing slash не нужен: --- location / { if ($request_method != 'GET') { rewrite ^/(.*) /proxy/$1 last; } root /data; } location /proxy/ { internal; rewrite ^/proxy/(.*) /$1 break; proxy_pass http://127.0.0.1:8080; } --- >вт, 9 февр. 2021 г. в 11:20, Илья Шипицин : >> >> можно на limit_except разрешить только GET. остальное попадет в запрет и навешать на него кастомную страницу ошибки >> >> вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov : >>> >>> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote: >>> >On 08.02.2021 23:24, Oleg A. Mamontov wrote: >>> > >>> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий >>> >>обработку запроса в другой location. Обратите внимание - trailing slash >>> >>в proxy_pass в данном случае имеет значение. >>> >>--- >>> >>location / { >>> >> if ($request_method != 'GET') { >>> >> rewrite ^/(.*) /proxy/$1 last; >>> >> } >>> >> root /data; >>> >>} >>> >>location /proxy/ { >>> >> internal; >>> >> proxy_pass http://127.0.0.1:8080/; >>> >>} >>> > >>> >Возможно переход в именованный location с помощью директив >>> >"error_page 418 = @location; return 418;" будет лучше >>> >с точки зрения читабельности, чем rewrite директивы, >>> >делающие конфиг nginx похожим на конфиг sendmail? >>> >>> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход >>> с error_page лучше для решения поставленной задачи. >>> >>> Что вижу: нецелевое использование директивы / фиктивного статуса, >>> появление лишней строки в конфиге и необходимость включать >>> recursive_error_pages при использовании реальной обработки последующих >>> ошибок проксирования. >>> >>> Но согласен - так делать тоже можно, TMTOWTDI >>> >>> >location / { >>> > if ($request_method != 'GET') { >>> > error_page 418 = @proxy; >>> > return 418; >>> > } >>> > root /data; >>> >} >>> >location @proxy { >>> > proxy_pass http://127.0.0.1:8080; >>> >} >>> > >>> >По-сути вот этот набор из двух директив: >>> >"error_page 418 = @location; return 418;" >>> >означает простое действие "goto @location;" >>> > >>> >-- >>> >Best regards, >>> > Gena >>> > >>> >_______________________________________________ >>> >nginx-ru mailing list >>> >nginx-ru на nginx.org >>> >http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >>> -- >>> 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 > > > >-- >WBR, >Eugene Prokopiev >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From enp на itx.ru Tue Feb 9 13:40:02 2021 From: enp на itx.ru (Eugene Prokopiev) Date: Tue, 9 Feb 2021 16:40:02 +0300 Subject: Route by request method In-Reply-To: <20210209125223.pl4b7colcndeeql4@xenon.mamontov.net> References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> <20210209125223.pl4b7colcndeeql4@xenon.mamontov.net> Message-ID: Спасибо! Но я вот задумался: а нельзя ли прямо внутри if использовать pass_proxy? Тут - https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass указан сontext: if in location - значит можно? Я попробовал - не работает. Почему? вт, 9 февр. 2021 г. в 15:52, Oleg A. Mamontov : > > On Tue, Feb 09, 2021 at 03:36:49PM +0300, Eugene Prokopiev wrote: > >Всем спасибо! > > > >А нет ли чего-то среднего: передать запрос с помощью rewrite (это > >выглядит чище использования фиктивного статуса, хотя явный goto был бы > >еще чище) в именованный @location вместо internal (тогда переменная > >request_filename будет содержать правильное значение)? > > Если вам хочется возвращать $uri в исходное значение, то это также > достигается посредством rewrite, заодно тогда и trailing slash не нужен: > --- > location / { > if ($request_method != 'GET') { > rewrite ^/(.*) /proxy/$1 last; > } > root /data; > } > location /proxy/ { > internal; > rewrite ^/proxy/(.*) /$1 break; > proxy_pass http://127.0.0.1:8080; > } > --- > > >вт, 9 февр. 2021 г. в 11:20, Илья Шипицин : > >> > >> можно на limit_except разрешить только GET. остальное попадет в запрет и навешать на него кастомную страницу ошибки > >> > >> вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov : > >>> > >>> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote: > >>> >On 08.02.2021 23:24, Oleg A. Mamontov wrote: > >>> > > >>> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий > >>> >>обработку запроса в другой location. Обратите внимание - trailing slash > >>> >>в proxy_pass в данном случае имеет значение. > >>> >>--- > >>> >>location / { > >>> >> if ($request_method != 'GET') { > >>> >> rewrite ^/(.*) /proxy/$1 last; > >>> >> } > >>> >> root /data; > >>> >>} > >>> >>location /proxy/ { > >>> >> internal; > >>> >> proxy_pass http://127.0.0.1:8080/; > >>> >>} > >>> > > >>> >Возможно переход в именованный location с помощью директив > >>> >"error_page 418 = @location; return 418;" будет лучше > >>> >с точки зрения читабельности, чем rewrite директивы, > >>> >делающие конфиг nginx похожим на конфиг sendmail? > >>> > >>> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход > >>> с error_page лучше для решения поставленной задачи. > >>> > >>> Что вижу: нецелевое использование директивы / фиктивного статуса, > >>> появление лишней строки в конфиге и необходимость включать > >>> recursive_error_pages при использовании реальной обработки последующих > >>> ошибок проксирования. > >>> > >>> Но согласен - так делать тоже можно, TMTOWTDI > >>> > >>> >location / { > >>> > if ($request_method != 'GET') { > >>> > error_page 418 = @proxy; > >>> > return 418; > >>> > } > >>> > root /data; > >>> >} > >>> >location @proxy { > >>> > proxy_pass http://127.0.0.1:8080; > >>> >} > >>> > > >>> >По-сути вот этот набор из двух директив: > >>> >"error_page 418 = @location; return 418;" > >>> >означает простое действие "goto @location;" > >>> > > >>> >-- > >>> >Best regards, > >>> > Gena > >>> > > >>> >_______________________________________________ > >>> >nginx-ru mailing list > >>> >nginx-ru на nginx.org > >>> >http://mailman.nginx.org/mailman/listinfo/nginx-ru > >>> > >>> -- > >>> 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 > > > > > > > >-- > >WBR, > >Eugene Prokopiev > >_______________________________________________ > >nginx-ru mailing list > >nginx-ru на nginx.org > >http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > 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 -- WBR, Eugene Prokopiev From mdounin на mdounin.ru Tue Feb 9 14:12:22 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 9 Feb 2021 17:12:22 +0300 Subject: Route by request method In-Reply-To: References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> <20210209125223.pl4b7colcndeeql4@xenon.mamontov.net> Message-ID: <20210209141222.GG77619@mdounin.ru> Hello! On Tue, Feb 09, 2021 at 04:40:02PM +0300, Eugene Prokopiev wrote: > Но я вот задумался: а нельзя ли прямо внутри if использовать > pass_proxy? Тут - > https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass > указан > сontext: if in location - значит можно? Я попробовал - не работает. Почему? Теоретически - можно. На практике - это чревато проблемами. Подробный ответ на вопрос "почему" есть в статье "if is evil", она ещё сохранилась в остатках wiki: https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ Скажем, вот такая конфигурация работает без проблем: location / { if ($request_method != GET) { proxy_pass http://127.0.0.1:8081; } # static } Но уже вот такая сделает совсем не то, что хотелось бы: location / { if ($request_method != GET) { proxy_pass http://127.0.0.1:8081; } set $true 1; if ($true) { # nothing } # static } Конкретно для исходной задачи наиболее простым и органичным решением будет, IMHO, использование limit_except, как-то так: location / { limit_except GET { proxy_pass http://127.0.0.1:8081; } # static } Но и тут есть свои нюансы: скажем, если в location'е есть директивы модуля rewrite, в часности - те же if'ы, то они просто не будут работать для запросов, попавших в блок limit_except. Ну а наиболее универсальное решение из всех возможных уже привёл Олег - сделать rewrite по нужному условию в другой location и там уже делать что угодно. -- Maxim Dounin http://mdounin.ru/ From enp на itx.ru Tue Feb 9 15:05:48 2021 From: enp на itx.ru (Eugene Prokopiev) Date: Tue, 9 Feb 2021 18:05:48 +0300 Subject: Route by request method In-Reply-To: <20210209141222.GG77619@mdounin.ru> References: <20210208212402.o4c4eq6pimdj5ucl@xenon.mamontov.net> <20210209081712.rsju4bsz7tx4fjgq@xenon.mamontov.net> <20210209125223.pl4b7colcndeeql4@xenon.mamontov.net> <20210209141222.GG77619@mdounin.ru> Message-ID: Понятно, спасибо! вт, 9 февр. 2021 г. в 17:12, Maxim Dounin : > > Hello! > > On Tue, Feb 09, 2021 at 04:40:02PM +0300, Eugene Prokopiev wrote: > > > Но я вот задумался: а нельзя ли прямо внутри if использовать > > pass_proxy? Тут - > > https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass > > указан > > сontext: if in location - значит можно? Я попробовал - не работает. Почему? > > Теоретически - можно. На практике - это чревато проблемами. > Подробный ответ на вопрос "почему" есть в статье "if is evil", она > ещё сохранилась в остатках wiki: > > https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ > > Скажем, вот такая конфигурация работает без проблем: > > location / { > if ($request_method != GET) { > proxy_pass http://127.0.0.1:8081; > } > > # static > } > > Но уже вот такая сделает совсем не то, что хотелось бы: > > location / { > if ($request_method != GET) { > proxy_pass http://127.0.0.1:8081; > } > > set $true 1; > if ($true) { > # nothing > } > > # static > } > > Конкретно для исходной задачи наиболее простым и органичным > решением будет, IMHO, использование limit_except, как-то так: > > location / { > limit_except GET { > proxy_pass http://127.0.0.1:8081; > } > > # static > } > > Но и тут есть свои нюансы: скажем, если в location'е есть > директивы модуля rewrite, в часности - те же if'ы, то они просто > не будут работать для запросов, попавших в блок limit_except. > > Ну а наиболее универсальное решение из всех возможных уже привёл > Олег - сделать rewrite по нужному условию в другой location и там > уже делать что угодно. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR, Eugene Prokopiev From nginx-forum на forum.nginx.org Wed Feb 10 05:53:08 2021 From: nginx-forum на forum.nginx.org (KDI) Date: Wed, 10 Feb 2021 00:53:08 -0500 Subject: NGINX - Microsoft Remote Desktop Gateway Message-ID: <8d7c2e49d947ce3e20c7083b621a5690.NginxMailingListRussian@forum.nginx.org> Как правильно проксировать 443 порт на сервер шлюзов удаленого рабочего стола Вот мой конфиг% root на nginx:/etc/nginx/sites-available# cat rds.domain.su server { if ($allowed_country = no) { return 404; } listen 443 ssl; server_name rds.domain.su; ssl_certificate /etc/nginx/ssl/domain.crt; ssl_certificate_key /etc/nginx/ssl/domain.rsa; location / { proxy_pass https://rds.domain.su:443; proxy_ssl_verify 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; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Proto https; proxy_request_buffering off; access_log /var/log/nginx/rds.access.log; error_log /var/log/nginx/rds.error.log; } } веб страница открывается ошибок нету а если подключаюсь через приложение mstsc выдается ошибка 2021/02/10 08:42:00 [error] 18427#18427: *400577 upstream prematurely closed connection while reading response header from upstream, client: что делаю не так ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290710,290710#msg-290710 From chipitsine на gmail.com Wed Feb 10 06:18:11 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 10 Feb 2021 11:18:11 +0500 Subject: NGINX - Microsoft Remote Desktop Gateway In-Reply-To: <8d7c2e49d947ce3e20c7083b621a5690.NginxMailingListRussian@forum.nginx.org> References: <8d7c2e49d947ce3e20c7083b621a5690.NginxMailingListRussian@forum.nginx.org> Message-ID: В ms rpc есть нарушения http, для апача есть поддержка. Для nginx только стрим. На http будет разваливаться On Wed, Feb 10, 2021, 10:53 AM KDI wrote: > Как правильно проксировать 443 порт на сервер шлюзов удаленого рабочего > стола > > Вот мой конфиг% > > root на nginx:/etc/nginx/sites-available# cat rds.domain.su > server { > if ($allowed_country = no) { > return 404; > } > listen 443 ssl; > server_name rds.domain.su; > ssl_certificate /etc/nginx/ssl/domain.crt; > ssl_certificate_key /etc/nginx/ssl/domain.rsa; > location / { > proxy_pass https://rds.domain.su:443; > proxy_ssl_verify 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; > proxy_set_header X-Forwarded-Host $server_name; > proxy_set_header X-Forwarded-Proto https; > proxy_request_buffering off; > access_log /var/log/nginx/rds.access.log; > error_log /var/log/nginx/rds.error.log; > } > } > > веб страница открывается ошибок нету а если подключаюсь через приложение > mstsc выдается ошибка > > 2021/02/10 08:42:00 [error] 18427#18427: *400577 upstream prematurely > closed > connection while reading response header from upstream, client: > > что делаю не так ? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,290710,290710#msg-290710 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Feb 10 07:39:28 2021 From: nginx-forum на forum.nginx.org (KDI) Date: Wed, 10 Feb 2021 02:39:28 -0500 Subject: NGINX - Microsoft Remote Desktop Gateway In-Reply-To: References: Message-ID: <4ad23547943506cd3582ca26a0c07709.NginxMailingListRussian@forum.nginx.org> Как правильно сделать стрим ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290710,290712#msg-290712 From chipitsine на gmail.com Wed Feb 10 07:57:49 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 10 Feb 2021 12:57:49 +0500 Subject: NGINX - Microsoft Remote Desktop Gateway In-Reply-To: <4ad23547943506cd3582ca26a0c07709.NginxMailingListRussian@forum.nginx.org> References: <4ad23547943506cd3582ca26a0c07709.NginxMailingListRussian@forum.nginx.org> Message-ID: (тут была бы уместна отправка на вики в раздел best practices, если такое есть, перенаправьте, плиз) пример с терминацией SSL --> TCP upstream rd-gateway { server x.x.x.x:80 ; server y.y.y.y:80 ; server z.z.z.z:80 ; hash $remote_addr consistent; } server { listen 443 ssl; proxy_pass rd-gateway; ssl_certificate /etc/ssl/fullchain.pem; ssl_certificate_key /etc/ssl/privkey.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA; ssl_session_cache shared:SSL_stream:60m; ssl_session_timeout 4h; ssl_handshake_timeout 30s; } ср, 10 февр. 2021 г. в 12:39, KDI : > Как правильно сделать стрим ? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,290710,290712#msg-290712 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From thresh на nginx.com Wed Feb 10 11:50:24 2021 From: thresh на nginx.com (Konstantin Pavlov) Date: Wed, 10 Feb 2021 14:50:24 +0300 Subject: =?UTF-8?B?UmU6INC/0LDQutC10YLRiyDQtNC70Y8gQVJNNjQ=?= In-Reply-To: <5aeb9ab5-e5a1-343b-2f9b-b6968516ff25@nginx.com> References: <5aeb9ab5-e5a1-343b-2f9b-b6968516ff25@nginx.com> Message-ID: <1784fe5a-a47d-3bb1-9d11-3e11a297173c@nginx.com> Добрый день, 31.12.2020 12:34, Konstantin Pavlov wrote: > Да, не было запросов конкретно на CentOS 7 aarch64 и мы их вообще не > собирали. > > К тому же, в CentOS 7 это не официально поддерживаемая архитектура - их > собирает AltArch SIG. > Для RHEL 7 похоже в AWS EC2 Red Hat тоже arm64 AMI не выкладывают (в > отличие от RHEL 8) -- так что перспективы добавления этой ОС/архитектуры > в наши сборки довольно туманны. Туман рассеялся и теперь пакеты mainline/stable для RHEL/CentOS 7 на aarch64 доступны в репозиториях на nginx.org. -- Konstantin Pavlov https://www.nginx.com/ From maxim на nginx.com Wed Feb 10 11:58:07 2021 From: maxim на nginx.com (Maxim Konovalov) Date: Wed, 10 Feb 2021 14:58:07 +0300 Subject: NGINX - Microsoft Remote Desktop Gateway In-Reply-To: References: <4ad23547943506cd3582ca26a0c07709.NginxMailingListRussian@forum.nginx.org> Message-ID: On 10.02.2021 10:57, Илья Шипицин wrote: > (тут была бы уместна отправка на вики в раздел best practices, если > такое есть, перенаправьте, плиз) > Эта часть есть, например, тут: https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/#example И даже без плюсо-специфичных фишек. > пример с терминацией SSL --> TCP > Кажется, для проксирования rdp терминировать ssl как раз не надо. -- Maxim Konovalov From chipitsine на gmail.com Wed Feb 10 12:14:24 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 10 Feb 2021 17:14:24 +0500 Subject: NGINX - Microsoft Remote Desktop Gateway In-Reply-To: References: <4ad23547943506cd3582ca26a0c07709.NginxMailingListRussian@forum.nginx.org> Message-ID: Не-не-не, это не rdp, а rdp gateway. Чуть другое. У гейтвея транспорт SSL в отличии от rdp. Терминировать SSL можно по настроению. Мы терминируем On Wed, Feb 10, 2021, 4:58 PM Maxim Konovalov wrote: > On 10.02.2021 10:57, Илья Шипицин wrote: > > (тут была бы уместна отправка на вики в раздел best practices, если > > такое есть, перенаправьте, плиз) > > > Эта часть есть, например, тут: > > > https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/#example > > И даже без плюсо-специфичных фишек. > > > пример с терминацией SSL --> TCP > > > Кажется, для проксирования rdp терминировать ssl как раз не надо. > > -- > Maxim Konovalov > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Feb 10 12:16:27 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 10 Feb 2021 17:16:27 +0500 Subject: =?UTF-8?B?UmU6INC/0LDQutC10YLRiyDQtNC70Y8gQVJNNjQ=?= In-Reply-To: <1784fe5a-a47d-3bb1-9d11-3e11a297173c@nginx.com> References: <5aeb9ab5-e5a1-343b-2f9b-b6968516ff25@nginx.com> <1784fe5a-a47d-3bb1-9d11-3e11a297173c@nginx.com> Message-ID: Я смотрел в src.rpm для rhel8, никакой специфики не увидел, собрал сам. Поигрался с версией gcc, 9-я даёт грубо 10% к производительности. Спасибо за пакеты)) On Wed, Feb 10, 2021, 4:50 PM Konstantin Pavlov wrote: > Добрый день, > > 31.12.2020 12:34, Konstantin Pavlov wrote: > > Да, не было запросов конкретно на CentOS 7 aarch64 и мы их вообще не > > собирали. > > > > К тому же, в CentOS 7 это не официально поддерживаемая архитектура - их > > собирает AltArch SIG. > > Для RHEL 7 похоже в AWS EC2 Red Hat тоже arm64 AMI не выкладывают (в > > отличие от RHEL 8) -- так что перспективы добавления этой ОС/архитектуры > > в наши сборки довольно туманны. > > Туман рассеялся и теперь пакеты mainline/stable для RHEL/CentOS 7 на > aarch64 доступны в репозиториях на nginx.org. > > -- > Konstantin Pavlov > https://www.nginx.com/ > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Wed Feb 10 12:19:30 2021 From: maxim на nginx.com (Maxim Konovalov) Date: Wed, 10 Feb 2021 15:19:30 +0300 Subject: NGINX - Microsoft Remote Desktop Gateway In-Reply-To: References: <4ad23547943506cd3582ca26a0c07709.NginxMailingListRussian@forum.nginx.org> Message-ID: <55d39ee4-375e-d86c-bcdc-ba7bc1370fda@nginx.com> On 10.02.2021 15:14, Илья Шипицин wrote: > Не-не-не, это не rdp, а rdp gateway. Чуть другое. У гейтвея транспорт > SSL в отличии от rdp. Терминировать SSL можно по настроению. Мы терминируем > А, сорри. Спасибо за разъяснение. > On Wed, Feb 10, 2021, 4:58 PM Maxim Konovalov > wrote: > > On 10.02.2021 10:57, Илья Шипицин wrote: > > (тут была бы уместна отправка на вики в раздел best practices, если > > такое есть, перенаправьте, плиз) > > > Эта часть есть, например, тут: > > https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/#example > > > И даже без плюсо-специфичных фишек. > > > пример с терминацией SSL --> TCP > > > Кажется, для проксирования rdp терминировать ssl как раз не надо. > > -- > Maxim Konovalov > -- Maxim Konovalov From nginx-forum на forum.nginx.org Wed Feb 10 13:41:37 2021 From: nginx-forum на forum.nginx.org (KDI) Date: Wed, 10 Feb 2021 08:41:37 -0500 Subject: NGINX - Microsoft Remote Desktop Gateway In-Reply-To: <55d39ee4-375e-d86c-bcdc-ba7bc1370fda@nginx.com> References: <55d39ee4-375e-d86c-bcdc-ba7bc1370fda@nginx.com> Message-ID: <72382cb43d2bed75b2db860570333990.NginxMailingListRussian@forum.nginx.org> Илья, спасибо ! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290710,290721#msg-290721 From alexcool на gmail.com Thu Feb 11 11:54:10 2021 From: alexcool на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lk=?=) Date: Thu, 11 Feb 2021 18:54:10 +0700 Subject: =?UTF-8?B?0J3QtdGA0LDQstC90L7QvNC10YDQvdC+0LUg0YDQsNGB0L/RgNC10LTQtdC70LU=?= =?UTF-8?B?0L3QuNC1INC90LDQs9GA0YPQt9C60LggaGFzaCBjb25zaXN0ZW50?= Message-ID: Здравствуйте. Создал балансировщик на 10 кэширующих серверов. Использовал consistent hash по $request_uri upstream cacheserver { hash $request_uri consistent; server 10.0.0.2:8080 max_fails=0; server 10.0.0.3:8080 max_fails=0; server 10.0.0.4:8080 max_fails=0; server 10.0.0.5:8080 max_fails=0; server 10.0.0.6:8080 max_fails=0; server 10.0.0.7:8080 max_fails=0; server 10.0.0.8:8080 max_fails=0; server 10.0.0.9:8080 max_fails=0; server 10.0.0.10:8080 max_fails=0; server 10.0.0.11:8080 max_fails=0; keepalive_requests 10000; keepalive 64; } Уникальных урлов более 20 миллионов. Размер файлов примерно одинаковый. Ожидал, что распределение нагрузки между серверами будет примерно одинаковое. Однако отклонения достигают 20% Динамика изменения объема занятого места в кэш партициях кэширующих серверов, [image: image.png] С наилучшими пожеланиями. Алексей ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: image.png Тип: image/png Размер: 35833 байтов Описание: отсутствует URL: From alexcool на gmail.com Sun Feb 14 08:46:04 2021 From: alexcool на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lk=?=) Date: Sun, 14 Feb 2021 15:46:04 +0700 Subject: =?UTF-8?B?0J3QtdGA0LDQstC90L7QvNC10YDQvdC+0LUg0YDQsNGB0L/RgNC10LTQtdC70LU=?= =?UTF-8?B?0L3QuNC1INC90LDQs9GA0YPQt9C60LggdXBzdHJlYW0gaGFzaCBjb25zaXN0?= =?UTF-8?B?ZW50?= Message-ID: Здравствуйте. Создал балансировщик на 10 кэширующих серверов. Использовал consistent hash по $request_uri upstream cacheserver { hash $request_uri consistent; server 10.0.0.2:8080 max_fails=0; server 10.0.0.3:8080 max_fails=0; server 10.0.0.4:8080 max_fails=0; server 10.0.0.5:8080 max_fails=0; server 10.0.0.6:8080 max_fails=0; server 10.0.0.7:8080 max_fails=0; server 10.0.0.8:8080 max_fails=0; server 10.0.0.9:8080 max_fails=0; server 10.0.0.10:8080 max_fails=0; server 10.0.0.11:8080 max_fails=0; keepalive_requests 10000; keepalive 64; } Уникальных урлов более 30 миллионов. Размер файлов примерно одинаковый. Ожидал, что распределение нагрузки между серверами будет примерно одинаковое. Однако отклонения достигают 23% как по трафику, так и по объему закэшированных данных. Поставил php реализацию библиотеки ketama, смоделировал эту ситуацию и получил похожий результат. На тесте с десятью серверами и миллионом ключей - отклонения до 27%. Улучшает ситуацию увеличение количества серверов. При десятикратном увеличении серверов отклонение составило 8%. Для выравнивания cache hit rate по серверам скорректировал размеры кэш зон в соответствии с реальным распределением нагрузки. С наилучшими пожеланиями. Алексей. P.S.: Может быть стоит отразить эту особенность в документации. From mdounin на mdounin.ru Tue Feb 16 16:12:49 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 16 Feb 2021 19:12:49 +0300 Subject: nginx-1.19.7 Message-ID: <20210216161249.GI77619@mdounin.ru> Изменения в nginx 1.19.7 16.02.2021 *) Изменение: обработка соединений в HTTP/2 была изменена и теперь более соответствует HTTP/1.x; директивы http2_recv_timeout, http2_idle_timeout и http2_max_requests упразднены, вместо них следует использовать директивы keepalive_timeout и keepalive_requests. *) Изменение: директивы http2_max_field_size и http2_max_header_size упразднены, вместо них следует использовать директиву large_client_header_buffers. *) Добавление: теперь при исчерпании свободных соединений nginx закрывает не только keepalive-соединения, но и соединения в lingering close. *) Исправление: в логах могли появляться сообщения "zero size buf in output", если бэкенд возвращал некорректный ответ при небуферизированном проксировании; ошибка появилась в 1.19.1. *) Исправление: при использовании директивы return вместе с image_filter или xslt_stylesheet HEAD-запросы обрабатывались некорректно. *) Исправление: в директиве add_trailer. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Sun Feb 21 10:57:05 2021 From: nginx-forum на forum.nginx.org (serglema) Date: Sun, 21 Feb 2021 05:57:05 -0500 Subject: =?UTF-8?B?0JrQsNC6INGB0LTQtdC70LDRgtGMINGA0LXQtNC40YDQtdC6INGBIHVybCDQsdC1?= =?UTF-8?B?0Lcg0LrQvtC00LAg0Y/Qt9GL0LrQsCDQsiDQvdCw0YfQsNC70LUsINC90LAg?= =?UTF-8?B?dXJsINGBINC60L7QtNC+0Lwg0Y/Qt9GL0LrQsC4=?= Message-ID: Добрый день! Раньше на сайте не было переключения между языками. Сейчас в начало url добавляется код языка. Например: было http://www.example.com/ssilka стало http://www.example.com/ru/ssilka Как сделать правильно редирект чтобы все ссылки без кода /ru/ вначале перенаправлялись на такие же ссылки только с кодом /ru/. Я пробовал сделать так set $default_lang "/ru"; if ($request_uri !~ "^/en/.*$|^/ru/.*$") { return 301 https://$host$default_lang$request_uri; } но в таком случае не работает ссылка на главную http://www.example.com и ссылки типа http://www.example.com/ru http://www.example.com/en а также проблемы з сылками на изображения и js а также css . С уважением, Сергей. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290812,290812#msg-290812 From nginx-forum на forum.nginx.org Tue Feb 23 09:50:31 2021 From: nginx-forum на forum.nginx.org (i_d) Date: Tue, 23 Feb 2021 04:50:31 -0500 Subject: =?UTF-8?B?0L/RgNC10YTQuNC60YEg0LTQu9GPINC/0L7RgdC70LXQtNGD0Y7RidC40YUg0YE=?= =?UTF-8?B?0YLRgNCw0L3QuNGGIC0g0L3QtSDRgNCw0LHQvtGC0LDQtdGC?= Message-ID: Добрый день! Я новичок, помогите пожалуйста с настройкой. Необходимо добавить префикс "test" в адресной строке. Это моя конфигурация: location /test/ { proxy_http_version 1.1; proxy_set_header Host $http_host; 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_read_timeout 900; proxy_set_header Connection ""; proxy_buffers 32 4k; proxy_pass http://localhost:7081/; } Первая страница открывается успешно, но вторая уже идет без префикса. На первой странице есть кнопка с ссылкой на вторую страницу такого образца Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290832,290832#msg-290832 From nginx-forum на forum.nginx.org Fri Feb 26 09:49:20 2021 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Fri, 26 Feb 2021 04:49:20 -0500 Subject: =?UTF-8?B?0JfQvdCw0Log0LLQvtC/0YDQvtGB0LAg0LIg0LjQvNC10L3QuCDRhNCw0LnQu9Cw?= =?UTF-8?B?Lg==?= Message-ID: <2f9aa9702420b1856f339725e1606845.NginxMailingListRussian@forum.nginx.org> Знаю. что это все очень странно и неправильно, но... Есть ли возможность как-то в try_files сделать проверку имени со знаком вопроса? ну что-то типа такого: try_files $uri?$variable =404; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290853,290853#msg-290853