From nginx-forum на forum.nginx.org  Thu Oct  1 13:21:07 2020
From: nginx-forum на forum.nginx.org (elc)
Date: Thu, 01 Oct 2020 09:21:07 -0400
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdGL0LUgNTAyINC+0YLQstC10YLRiy4=?=
In-Reply-To: <CAFHpkQEZ7JnY7atXnGn+wM3gRE95Z_X_+qp2w9u44Rtetgb6mA@mail.gmail.com>
References: <CAFHpkQEZ7JnY7atXnGn+wM3gRE95Z_X_+qp2w9u44Rtetgb6mA@mail.gmail.com>
Message-ID: <e77488d3c4c7bb35002879129f1b425c.NginxMailingListRussian@forum.nginx.org>

Там тоже nginx.
Если быть точным, то nginx/1.17.3 и на Edge_proxy и на промежуточном proxy.
Что на стороне Origin server сказать не могу, но в рамках данного вопроса
это не имеет значения.
Вот в том и дело что на стороне сервера (промежуточном proxy) ничего не
падает, worker-ы работают стабильно, не убиваются.
По ресурсам CPU idle 80+% на всех серверах.

На промежуточных proxy в error.log есть записи "upstream prematurely closed
connection while reading response header from upstream" и "upstream timed
out (110: Connection timed out) while reading response header from upstream"
, это получается при запросах proxy_промежуточные <-> Origin server, но
сейчас вопрос не про них.

Других записей в error.log на промежуточном proxy нет. В access.log на
промежуточном proxy также запросы, которые на edge_proxy 502, отсутствуют.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289619,289627#msg-289627


From chipitsine на gmail.com  Thu Oct  1 13:32:24 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 1 Oct 2020 18:32:24 +0500
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdGL0LUgNTAyINC+0YLQstC10YLRiy4=?=
In-Reply-To: <e77488d3c4c7bb35002879129f1b425c.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEZ7JnY7atXnGn+wM3gRE95Z_X_+qp2w9u44Rtetgb6mA@mail.gmail.com>
 <e77488d3c4c7bb35002879129f1b425c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEDr=i7_TD+zeUUiYCnTJsJwU8P2-3Jdf+TwYmSsgC3-A@mail.gmail.com>

Тогда смотрите core dumped на том nginx, который так отвечает

On Thu, Oct 1, 2020, 6:21 PM elc <nginx-forum на forum.nginx.org> wrote:

> Там тоже nginx.
> Если быть точным, то nginx/1.17.3 и на Edge_proxy и на промежуточном proxy.
> Что на стороне Origin server сказать не могу, но в рамках данного вопроса
> это не имеет значения.
> Вот в том и дело что на стороне сервера (промежуточном proxy) ничего не
> падает, worker-ы работают стабильно, не убиваются.
> По ресурсам CPU idle 80+% на всех серверах.
>
> На промежуточных proxy в error.log есть записи "upstream prematurely closed
> connection while reading response header from upstream" и "upstream timed
> out (110: Connection timed out) while reading response header from
> upstream"
> , это получается при запросах proxy_промежуточные <-> Origin server, но
> сейчас вопрос не про них.
>
> Других записей в error.log на промежуточном proxy нет. В access.log на
> промежуточном proxy также запросы, которые на edge_proxy 502, отсутствуют.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,289619,289627#msg-289627
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201001/ef19afb3/attachment.htm>

From bgx на protva.ru  Thu Oct  1 13:52:07 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 1 Oct 2020 16:52:07 +0300
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdGL0LUgNTAyINC+0YLQstC10YLRiy4=?=
In-Reply-To: <e77488d3c4c7bb35002879129f1b425c.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEZ7JnY7atXnGn+wM3gRE95Z_X_+qp2w9u44Rtetgb6mA@mail.gmail.com>
 <e77488d3c4c7bb35002879129f1b425c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20201001135207.GE2686@sie.protva.ru>

On Thu, Oct 01, 2020 at 09:21:07AM -0400, elc wrote:
> Вот в том и дело что на стороне сервера (промежуточном proxy) ничего не
> падает, worker-ы работают стабильно, не убиваются.
> По ресурсам CPU idle 80+% на всех серверах.
> 
> На промежуточных proxy в error.log есть записи "upstream prematurely closed
> connection while reading response header from upstream" и "upstream timed
> out (110: Connection timed out) while reading response header from upstream"
> , это получается при запросах proxy_промежуточные <-> Origin server, но
> сейчас вопрос не про них.
> 
> Других записей в error.log на промежуточном proxy нет. В access.log на
> промежуточном proxy также запросы, которые на edge_proxy 502, отсутствуют.

 В чём вопрос-то заключается? Всё что знает о проблеме промежуточный прокси
 он написал в лог, его хоть обчитайся, дальше не сдвинешься. Выясняйте что
 происходит на upstream-е (который Origin), почему он обрывает коннекции.
 
 А то что прокси при этом выдаёт 502, так это закономерно: такой ответ и
 должен быть при обрыве коннекции upstream-ом.
-- 
 Eugene Berdnikov

From shilov на extmail.info  Sun Oct  4 17:38:15 2020
From: shilov на extmail.info (Shilov)
Date: Sun, 4 Oct 2020 20:38:15 +0300
Subject: =?UTF-8?B?0J3QtdC/0L7QvdGP0YLQutC4INGB0L4g0YHRgtGA0LDQvdC40YbQsNC80Lgg0L4=?=
 =?UTF-8?B?0YjQuNCx0L7Qug==?=
In-Reply-To: <CAFHpkQEitT1mSCDVfxzr1-KzpO7Q11G7M_vM4poPGRPM7DNixQ@mail.gmail.com>
References: <CAFHpkQGc28N=qwqXE6AKUW0Y6H7GUofZYsEZBpww-Ltg=wT_rA@mail.gmail.com>
 <b0543428d86fcaa67124b78875406134.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQEitT1mSCDVfxzr1-KzpO7Q11G7M_vM4poPGRPM7DNixQ@mail.gmail.com>
Message-ID: <20201004203815.04c8fac5937b74543cf05db3@extmail.info>

Привет всем!

Понадобилось скорректировать на свое усмотрение страницы ошибок 40x, 50x, но в отличие от Апача, не нашел их в отдельном html-виде.
Они что, вшиты в бинарник Nginx??

-- 
Shilov <shilov на extmail.info>

From red-fox0 на ya.ru  Mon Oct  5 02:13:21 2020
From: red-fox0 на ya.ru (fox)
Date: Mon, 5 Oct 2020 09:13:21 +0700
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0LrQuCDRgdC+INGB0YLRgNCw0L3QuNGG0LDQvNC4?=
 =?UTF-8?B?INC+0YjQuNCx0L7Qug==?=
In-Reply-To: <20201004203815.04c8fac5937b74543cf05db3@extmail.info>
References: <CAFHpkQGc28N=qwqXE6AKUW0Y6H7GUofZYsEZBpww-Ltg=wT_rA@mail.gmail.com>
 <b0543428d86fcaa67124b78875406134.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQEitT1mSCDVfxzr1-KzpO7Q11G7M_vM4poPGRPM7DNixQ@mail.gmail.com>
 <20201004203815.04c8fac5937b74543cf05db3@extmail.info>
Message-ID: <1cc8af3a-9f5e-7532-9baa-55276172495d@ya.ru>

Может и вшиты.

Добавь в конфиг такие строчки

error_page 404             /404.html;
error_page 500 502 503 504 /50x.html;


05.10.2020 00:38, Shilov пишет:
> Привет всем!
> 
> Понадобилось скорректировать на свое усмотрение страницы ошибок 40x, 50x, но в отличие от Апача, не нашел их в отдельном html-виде.
> Они что, вшиты в бинарник Nginx??
> 


From alex.hha на gmail.com  Mon Oct  5 07:36:42 2020
From: alex.hha на gmail.com (Alex Domoradov)
Date: Mon, 5 Oct 2020 10:36:42 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0LrQuCDRgdC+INGB0YLRgNCw0L3QuNGG0LDQvNC4?=
 =?UTF-8?B?INC+0YjQuNCx0L7Qug==?=
In-Reply-To: <1cc8af3a-9f5e-7532-9baa-55276172495d@ya.ru>
References: <CAFHpkQGc28N=qwqXE6AKUW0Y6H7GUofZYsEZBpww-Ltg=wT_rA@mail.gmail.com>
 <b0543428d86fcaa67124b78875406134.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQEitT1mSCDVfxzr1-KzpO7Q11G7M_vM4poPGRPM7DNixQ@mail.gmail.com>
 <20201004203815.04c8fac5937b74543cf05db3@extmail.info>
 <1cc8af3a-9f5e-7532-9baa-55276172495d@ya.ru>
Message-ID: <CAK90gp7nYaXJ_DNvO65PxjsNpSFOSheMk-8S7t-PMntsp09aNg@mail.gmail.com>

> но в отличие от Апача, не нашел их в отдельном html-виде

Плохо искал

# rpm -ql nginx | grep -E '(404|50x)'
/usr/share/nginx/html/404.html
/usr/share/nginx/html/50x.html

On Mon, Oct 5, 2020 at 5:13 AM fox <red-fox0 на ya.ru> wrote:

> Может и вшиты.
>
> Добавь в конфиг такие строчки
>
> error_page 404             /404.html;
> error_page 500 502 503 504 /50x.html;
>
>
> 05.10.2020 00:38, Shilov пишет:
> > Привет всем!
> >
> > Понадобилось скорректировать на свое усмотрение страницы ошибок 40x,
> 50x, но в отличие от Апача, не нашел их в отдельном html-виде.
> > Они что, вшиты в бинарник Nginx??
> >
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201005/67f46aa5/attachment.htm>

From simplebox66 на gmail.com  Mon Oct  5 16:47:57 2020
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Mon, 5 Oct 2020 19:47:57 +0300
Subject: =?UTF-8?B?0J3QtdC/0L7QvdGP0YLQvdCwINGA0LDQsdC+0YLQsCBsaW1pdF9yYXRl?=
Message-ID: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>

Добрый день!
Есть локейшн с настроенными вот такими директивами:
  limit_rate_after 150000k; #150Mb
  limit_rate 2048k;

Пробую качать с помощью wget большой файл, и примерно через 7 минут 49-55
секунд закачка обрывается ну и соответственно объем (1.1Гб) скачанных
данных в зависимости от времени слегка разный.
Как только убирают указанные выше две директивы, так все логично быстро
качается и самое главное без обрыва , качается целиком.
А проблема заключается в том что указанными директивами я лишь хотел
подрезать скорость, но не понятно почему при этом файл не скачивается до
конца! До 1.1Гб файлы скачиваются нормально, а больше уже нет. Хотел было
грешить на таймауты какие-нибудь, но время обрыва хоть и примерно
одинаковое, но все же не постоянное, поэтому идею с таймаутами отбросил.

Прошу подсказать как решить проблему?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201005/dfca3f44/attachment.htm>

From simplebox66 на gmail.com  Mon Oct  5 17:16:30 2020
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Mon, 5 Oct 2020 20:16:30 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
Message-ID: <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>

Забыл уточнить, что при обрыве в акцес логах все равно значится 200 код, а
в ерор логах пусто.

пн, 5 окт. 2020 г. в 19:47, Иван Мишин <simplebox66 на gmail.com>:

> Добрый день!
> Есть локейшн с настроенными вот такими директивами:
>   limit_rate_after 150000k; #150Mb
>   limit_rate 2048k;
>
> Пробую качать с помощью wget большой файл, и примерно через 7 минут 49-55
> секунд закачка обрывается ну и соответственно объем (1.1Гб) скачанных
> данных в зависимости от времени слегка разный.
> Как только убирают указанные выше две директивы, так все логично быстро
> качается и самое главное без обрыва , качается целиком.
> А проблема заключается в том что указанными директивами я лишь хотел
> подрезать скорость, но не понятно почему при этом файл не скачивается до
> конца! До 1.1Гб файлы скачиваются нормально, а больше уже нет. Хотел было
> грешить на таймауты какие-нибудь, но время обрыва хоть и примерно
> одинаковое, но все же не постоянное, поэтому идею с таймаутами отбросил.
>
> Прошу подсказать как решить проблему?
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201005/82f79658/attachment.htm>

From ngnx8810773a83 на avksrv.org  Mon Oct  5 19:24:17 2020
From: ngnx8810773a83 на avksrv.org (Alexey)
Date: Mon, 5 Oct 2020 22:24:17 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
Message-ID: <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>

День добрый!

Вы качаете файл, получаемых от прокси апстрима?
https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size

Вы упираетесь в 1Гб временного файла. когда качается быстро, он вообще в 
темп не пишется, если файл прилетает от апстрима быстрее чем забираем, 
то он уже пишется во временный файл. вы успеваете скачать столько, 
сколько прилетает до начала записи во временный файл + макс размер файла.


05.10.2020 20:16, Иван Мишин пишет:
> Забыл уточнить, что при обрыве в акцес логах все равно значится 200 
> код, а в ерор логах пусто.
>
> пн, 5 окт. 2020 г. в 19:47, Иван Мишин <simplebox66 на gmail.com 
> <mailto:simplebox66 на gmail.com>>:
>
>     Добрый день!
>     Есть локейшн с настроенными вот такими директивами:
>       limit_rate_after 150000k; #150Mb
>       limit_rate 2048k;
>
>     Пробую качать с помощью wget большой файл, и примерно через 7
>     минут 49-55 секунд закачка обрывается ну и соответственно объем
>     (1.1Гб) скачанных данных в зависимости от времени слегка разный.
>     Как только убирают указанные выше две директивы, так все логично
>     быстро качается и самое главное без обрыва , качается целиком.
>     А проблема заключается в том что указанными директивами я лишь
>     хотел подрезать скорость, но не понятно почему при этом файл не
>     скачивается до конца! До 1.1Гб файлы скачиваются нормально, а
>     больше уже нет. Хотел было грешить на таймауты какие-нибудь, но
>     время обрыва хоть и примерно одинаковое, но все же не постоянное,
>     поэтому идею с таймаутами отбросил.
>
>     Прошу подсказать как решить проблему?
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



From bgx на protva.ru  Tue Oct  6 07:42:47 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 6 Oct 2020 10:42:47 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
Message-ID: <20201006074247.GC2639@protva.ru>

On Mon, Oct 05, 2020 at 10:24:17PM +0300, Alexey wrote:
> День добрый!
> 
> Вы качаете файл, получаемых от прокси апстрима?
> https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size
> 
> Вы упираетесь в 1Гб временного файла. когда качается быстро, он
> вообще в темп не пишется, если файл прилетает от апстрима быстрее
> чем забираем, то он уже пишется во временный файл. вы успеваете
> скачать столько, сколько прилетает до начала записи во временный
> файл + макс размер файла.

 Наличие лимита на размер временного файла это что, повод обрывать закачку?
 Я бы предложил начать с wget -d.

> 05.10.2020 20:16, Иван Мишин пишет:
> >Забыл уточнить, что при обрыве в акцес логах все равно значится
> >200 код, а в ерор логах пусто.
> >
> >пн, 5 окт. 2020 г. в 19:47, Иван Мишин <simplebox66 на gmail.com
> ><mailto:simplebox66 на gmail.com>>:
> >
> >    Добрый день!
> >    Есть локейшн с настроенными вот такими директивами:
> >      limit_rate_after 150000k; #150Mb
> >      limit_rate 2048k;
> >
> >    Пробую качать с помощью wget большой файл, и примерно через 7
> >    минут 49-55 секунд закачка обрывается ну и соответственно объем
> >    (1.1Гб) скачанных данных в зависимости от времени слегка разный.
> >    Как только убирают указанные выше две директивы, так все логично
> >    быстро качается и самое главное без обрыва , качается целиком.
> >    А проблема заключается в том что указанными директивами я лишь
> >    хотел подрезать скорость, но не понятно почему при этом файл не
> >    скачивается до конца! До 1.1Гб файлы скачиваются нормально, а
> >    больше уже нет. Хотел было грешить на таймауты какие-нибудь, но
> >    время обрыва хоть и примерно одинаковое, но все же не постоянное,
> >    поэтому идею с таймаутами отбросил.
> >
> >    Прошу подсказать как решить проблему?
> >
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Tue Oct  6 10:21:14 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 6 Oct 2020 15:21:14 +0500
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <20201006074247.GC2639@protva.ru>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
Message-ID: <CAFHpkQHHkoJfwDcsHe6j7Jmdeccu1vybMufg9raW3FdRmVCaNg@mail.gmail.com>

вт, 6 окт. 2020 г. в 12:43, Evgeniy Berdnikov <bgx на protva.ru>:

> On Mon, Oct 05, 2020 at 10:24:17PM +0300, Alexey wrote:
> > День добрый!
> >
> > Вы качаете файл, получаемых от прокси апстрима?
> >
> https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size
> >
> > Вы упираетесь в 1Гб временного файла. когда качается быстро, он
> > вообще в темп не пишется, если файл прилетает от апстрима быстрее
> > чем забираем, то он уже пишется во временный файл. вы успеваете
> > скачать столько, сколько прилетает до начала записи во временный
> > файл + макс размер файла.
>
>  Наличие лимита на размер временного файла это что, повод обрывать закачку?
>

вы отдаете проксируемый контент по мере чтения.
статус 200 вы отдаете практически сразу.
поэтому клиент видит 200.

потом вы начинаете вычитывать ответ, и постепенно отдавать клиенту.

это регулируется (на выбор)

proxy_buffering (по умолчанию включено)
X-Accel-Buffering (можно отдать с апстрима)
proxy_max_temp_file_size (по  умолчанию 1Гб)

если вы с апстрима вычитываете на wire speed, а отдаете в узную дырочку, то
все шансы, что ответ попытается сбуферизоваться.
и это у него получится вплоть до размера 1Гб

а дальше - вы уже отдали (в сторону клиента) 200. поменять уже не можете.


это дефолтные настройки. их не меняют с целью сохранения совместимости
(вдруг кто-то от них зависит).
предполагается ответственный подход. если вы несчастливы с дефолтными
настройками - читаете документацию, меняете на нужные.


>  Я бы предложил начать с wget -d.
>
> > 05.10.2020 20:16, Иван Мишин пишет:
> > >Забыл уточнить, что при обрыве в акцес логах все равно значится
> > >200 код, а в ерор логах пусто.
> > >
> > >пн, 5 окт. 2020 г. в 19:47, Иван Мишин <simplebox66 на gmail.com
> > ><mailto:simplebox66 на gmail.com>>:
> > >
> > >    Добрый день!
> > >    Есть локейшн с настроенными вот такими директивами:
> > >      limit_rate_after 150000k; #150Mb
> > >      limit_rate 2048k;
> > >
> > >    Пробую качать с помощью wget большой файл, и примерно через 7
> > >    минут 49-55 секунд закачка обрывается ну и соответственно объем
> > >    (1.1Гб) скачанных данных в зависимости от времени слегка разный.
> > >    Как только убирают указанные выше две директивы, так все логично
> > >    быстро качается и самое главное без обрыва , качается целиком.
> > >    А проблема заключается в том что указанными директивами я лишь
> > >    хотел подрезать скорость, но не понятно почему при этом файл не
> > >    скачивается до конца! До 1.1Гб файлы скачиваются нормально, а
> > >    больше уже нет. Хотел было грешить на таймауты какие-нибудь, но
> > >    время обрыва хоть и примерно одинаковое, но все же не постоянное,
> > >    поэтому идею с таймаутами отбросил.
> > >
> > >    Прошу подсказать как решить проблему?
> > >
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201006/87bbef99/attachment-0001.htm>

From bgx на protva.ru  Tue Oct  6 10:45:01 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 6 Oct 2020 13:45:01 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <CAFHpkQHHkoJfwDcsHe6j7Jmdeccu1vybMufg9raW3FdRmVCaNg@mail.gmail.com>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
 <CAFHpkQHHkoJfwDcsHe6j7Jmdeccu1vybMufg9raW3FdRmVCaNg@mail.gmail.com>
Message-ID: <20201006104501.GE2639@protva.ru>

On Tue, Oct 06, 2020 at 03:21:14PM +0500, Илья Шипицин wrote:
>       Наличие лимита на размер временного файла это что, повод обрывать
>      закачку?
> 
>    вы отдаете проксируемый контент по мере чтения.
>    статус 200 вы отдаете практически сразу.
>    поэтому клиент видит 200.
>    потом вы начинаете вычитывать ответ, и постепенно отдавать клиенту.
>    это регулируется (на выбор)
>    proxy_buffering (по умолчанию включено)
>    X-Accel-Buffering (можно отдать с апстрима)
>    proxy_max_temp_file_size (по  умолчанию 1Гб)
>    если вы с апстрима вычитываете на wire speed, а отдаете в узную дырочку,
>    то все шансы, что ответ попытается сбуферизоваться.
>    и это у него получится вплоть до размера 1Гб
>    а дальше - вы уже отдали (в сторону клиента) 200. поменять уже не можете.

 А с чего бы статус менять? Не влез ответ в буфер -- положили на это болт
 (можно удалить файл из буфера, etc) и продолжаем отдавать клиенту дальше.

>    это дефолтные настройки. их не меняют с целью сохранения совместимости
>    (вдруг кто-то от них зависит).
>    предполагается ответственный подход. если вы несчастливы с дефолтными
>    настройками - читаете документацию, меняете на нужные.

 Не знаю, как ведёт себя nginx в данной конкретной ситуации, но думаю,
 что его авторы не столь тупы, чтобы не понимать: на апстриме всегда может
 найтись файл, который в буфер не влезет. При любых значениях настроечных
 параметров. Это нормальная ситуация, причём если Content-Length с апстрима
 пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту
 в таких условиях это баг, однозначно.
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Tue Oct  6 11:11:37 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 6 Oct 2020 16:11:37 +0500
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <20201006104501.GE2639@protva.ru>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
 <CAFHpkQHHkoJfwDcsHe6j7Jmdeccu1vybMufg9raW3FdRmVCaNg@mail.gmail.com>
 <20201006104501.GE2639@protva.ru>
Message-ID: <CAFHpkQFVg=hA_fQSFYpPHTLcQYNPoHjqL06MdfUBV8zMxBU8hg@mail.gmail.com>

вт, 6 окт. 2020 г. в 15:45, Evgeniy Berdnikov <bgx на protva.ru>:

> On Tue, Oct 06, 2020 at 03:21:14PM +0500, Илья Шипицин wrote:
> >       Наличие лимита на размер временного файла это что, повод обрывать
> >      закачку?
> >
> >    вы отдаете проксируемый контент по мере чтения.
> >    статус 200 вы отдаете практически сразу.
> >    поэтому клиент видит 200.
> >    потом вы начинаете вычитывать ответ, и постепенно отдавать клиенту.
> >    это регулируется (на выбор)
> >    proxy_buffering (по умолчанию включено)
> >    X-Accel-Buffering (можно отдать с апстрима)
> >    proxy_max_temp_file_size (по  умолчанию 1Гб)
> >    если вы с апстрима вычитываете на wire speed, а отдаете в узную
> дырочку,
> >    то все шансы, что ответ попытается сбуферизоваться.
> >    и это у него получится вплоть до размера 1Гб
> >    а дальше - вы уже отдали (в сторону клиента) 200. поменять уже не
> можете.
>
>  А с чего бы статус менять? Не влез ответ в буфер -- положили на это болт
>  (можно удалить файл из буфера, etc) и продолжаем отдавать клиенту дальше.
>
> >    это дефолтные настройки. их не меняют с целью сохранения совместимости
> >    (вдруг кто-то от них зависит).
> >    предполагается ответственный подход. если вы несчастливы с дефолтными
> >    настройками - читаете документацию, меняете на нужные.
>
>  Не знаю, как ведёт себя nginx в данной конкретной ситуации, но думаю,
>

это определенный этап, который проходит каждый крупный сервис, который
отдает файлы больше чем 1Гб :)
осознание, что дефолтные настройки не очень удачные в этом месте


>  что его авторы не столь тупы, чтобы не понимать: на апстриме всегда может
>  найтись файл, который в буфер не влезет. При любых значениях настроечных
>  параметров. Это нормальная ситуация, причём если Content-Length с апстрима
>

с одной стороны я с вами соглашусь, что дефолтное поведение не выглядит
отличным.
вероятно, если файл больше нельзя сохранять в кеш, то можно просто не
пытаться его сохранять,
а обойтись тем, что сохранено, остаток дочитать, ну или подождать

с другой стороны, вы несчастны с дефолтным поведением - ок, меняете
настройку на более комфортную вам
и живете с ней.


аргументы за "поменять жизнь вообще всем" тяжело заходят. но почему бы не
поменять ее конкретно тому,
кто несчастен с дефолтом


>  пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту
>  в таких условиях это баг, однозначно.
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201006/efc42e4a/attachment.htm>

From bgx на protva.ru  Tue Oct  6 11:35:35 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 6 Oct 2020 14:35:35 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <CAFHpkQFVg=hA_fQSFYpPHTLcQYNPoHjqL06MdfUBV8zMxBU8hg@mail.gmail.com>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
 <CAFHpkQHHkoJfwDcsHe6j7Jmdeccu1vybMufg9raW3FdRmVCaNg@mail.gmail.com>
 <20201006104501.GE2639@protva.ru>
 <CAFHpkQFVg=hA_fQSFYpPHTLcQYNPoHjqL06MdfUBV8zMxBU8hg@mail.gmail.com>
Message-ID: <20201006113535.GF2639@protva.ru>

On Tue, Oct 06, 2020 at 04:11:37PM +0500, Илья Шипицин wrote:
>    вт, 6 окт. 2020 г. в 15:45, Evgeniy Berdnikov <[1]bgx на protva.ru>:
>       найтись файл, который в буфер не влезет. При любых значениях
>      настроечных
>       параметров. Это нормальная ситуация, причём если Content-Length с
>      апстрима
> 
>    с одной стороны я с вами соглашусь, что дефолтное поведение не выглядит
>    отличным.
>    вероятно, если файл больше нельзя сохранять в кеш, то можно просто не
>    пытаться его сохранять,
>    а обойтись тем, что сохранено, остаток дочитать, ну или подождать
>    с другой стороны, вы несчастны с дефолтным поведением - ок, меняете
>    настройку на более комфортную вам
>    и живете с ней.
>    аргументы за "поменять жизнь вообще всем" тяжело заходят. но почему бы не
>    поменять ее конкретно тому,
>    кто несчастен с дефолтом

 Какая настройка "более комфортная", если апстрим не контролируем?
 Например, там хостинг, юзер захочет -- положит 4 гига файл, захочет -- 15G.
 И что, мне из-за этого отказаться от кэша вообще, хотя он в 97% уместен?
 Хотелось бы авторов nginx-a послушать.

>       пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту
>       в таких условиях это баг, однозначно.
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Tue Oct  6 11:57:00 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 6 Oct 2020 16:57:00 +0500
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <20201006113535.GF2639@protva.ru>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
 <CAFHpkQHHkoJfwDcsHe6j7Jmdeccu1vybMufg9raW3FdRmVCaNg@mail.gmail.com>
 <20201006104501.GE2639@protva.ru>
 <CAFHpkQFVg=hA_fQSFYpPHTLcQYNPoHjqL06MdfUBV8zMxBU8hg@mail.gmail.com>
 <20201006113535.GF2639@protva.ru>
Message-ID: <CAFHpkQE2a+hPFf=medFX85mwynu3+UMuvRyL2GR+Ust1+E=jJA@mail.gmail.com>

вт, 6 окт. 2020 г. в 16:35, Evgeniy Berdnikov <bgx на protva.ru>:

> On Tue, Oct 06, 2020 at 04:11:37PM +0500, Илья Шипицин wrote:
> >    вт, 6 окт. 2020 г. в 15:45, Evgeniy Berdnikov <[1]bgx на protva.ru>:
> >       найтись файл, который в буфер не влезет. При любых значениях
> >      настроечных
> >       параметров. Это нормальная ситуация, причём если Content-Length с
> >      апстрима
> >
> >    с одной стороны я с вами соглашусь, что дефолтное поведение не
> выглядит
> >    отличным.
> >    вероятно, если файл больше нельзя сохранять в кеш, то можно просто не
> >    пытаться его сохранять,
> >    а обойтись тем, что сохранено, остаток дочитать, ну или подождать
> >    с другой стороны, вы несчастны с дефолтным поведением - ок, меняете
> >    настройку на более комфортную вам
> >    и живете с ней.
> >    аргументы за "поменять жизнь вообще всем" тяжело заходят. но почему
> бы не
> >    поменять ее конкретно тому,
> >    кто несчастен с дефолтом
>
>  Какая настройка "более комфортная", если апстрим не контролируем?
>

дефолтные настройки уходят корнями во времена, когда бекендом был апач, для
которого
одновременное поддержание многих открытых соединений являлось узким местом.

и задача, решаемая многими дефолтными настройками звучит примерно "по
возможности
быстро вычитать файл с апача, и закрыть соединение".

с тех пор ситуация успела поменяться,  C10K умеют вообще, наверное, все
сервера
(для справки https://en.wikipedia.org/wiki/C10k_problem )

не выглядит большой проблемой вычитывать файл и без всякого буфера (на
диске) отдавать его
клиенту. более того, если вы помониторите список рассылки, тут регулярно
приходят видеостримеры,
с жалобами "у нас чуууууть-чууууууть деградировала сеть в сторону клиента и
непонятным образом
выросла в потолок нагрузка на диск прокси". понятно, выросла, потому что
ответы стали складываться на диск.
диск во многих случаях медленнее, чем сеть в сторону апстрима.

ответственное решение - настроить для себя буферизацию правильно.



>  Например, там хостинг, юзер захочет -- положит 4 гига файл, захочет --
> 15G.
>  И что, мне из-за этого отказаться от кэша вообще, хотя он в 97% уместен?
>  Хотелось бы авторов nginx-a послушать.
>


ну, я не автор. мне тоже интересно услышать эту историю.


>
> >       пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту
> >       в таких условиях это баг, однозначно.
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201006/c80f892a/attachment-0001.htm>

From mdounin на mdounin.ru  Tue Oct  6 14:16:32 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 6 Oct 2020 17:16:32 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <20201006074247.GC2639@protva.ru>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
Message-ID: <20201006141632.GQ1136@mdounin.ru>

Hello!

On Tue, Oct 06, 2020 at 10:42:47AM +0300, Evgeniy Berdnikov wrote:

> On Mon, Oct 05, 2020 at 10:24:17PM +0300, Alexey wrote:
> > День добрый!
> > 
> > Вы качаете файл, получаемых от прокси апстрима?
> > https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size
> > 
> > Вы упираетесь в 1Гб временного файла. когда качается быстро, он
> > вообще в темп не пишется, если файл прилетает от апстрима быстрее
> > чем забираем, то он уже пишется во временный файл. вы успеваете
> > скачать столько, сколько прилетает до начала записи во временный
> > файл + макс размер файла.
> 
>  Наличие лимита на размер временного файла это что, повод обрывать закачку?

Наличие лимита - ни разу не повод обрывать закачку, nginx её и не 
обрывает.

Другой вопрос, что если буфер забит - nginx'у некуда читать 
дополнительные данные, и в результате бэкенд может закрыть 
соединение по таймауту до того, как содержимое временного файла 
будет отдано клиену и соответственно nginx сможет дальше читать 
что-либо от бэкенда.

При заявленном ограничении скорости в 2 мегабайта в секунду - 
отправка клиенту гигабайта временных данных займёт секунд 500 
минимум.  Если при этом с бэкенда эти данные летят по гигабитному 
каналу со скоростью 100 мегабайт в секунду - прилетят они секунд за 
10.  То есть между nginx'ом и бэкендом 490 секунд ничего не будет 
происходить.  Шансов на то, что бэкенд дождётся при настройках по 
умолчанию - никаких.

Соответственно нужно:

- увеличить временный файл, чтобы ответы влезали;

- или уменьшить временный файл, чтобы его содержимое могло 
  отправиться до того, как сработает таймаут на бэкенде.

Ну либо настраивать таймауты на бэкенде и/или ограничение 
скорости, чтобы опять же временный файл мог отправиться до того, 
как сработает таймаут на бэкенде.

Вообще, когда речь идёт о том, что проксируются большие файлы - 
одним из лучших решений может быть просто выключенная буферизация 
на диск, "proxy_max_temp_file_size 0;".  Это позволяет избежать не 
только проблем с таймаутами на бэкенде, но и траты ресурсов на 
disk i/o, а равно проблем с переполнением диска под временные 
файлы при большом количестве одновременных запросов.

[...]

-- 
Maxim Dounin
http://mdounin.ru/

From simplebox66 на gmail.com  Wed Oct  7 15:07:43 2020
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 7 Oct 2020 18:07:43 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <20201006141632.GQ1136@mdounin.ru>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
 <20201006141632.GQ1136@mdounin.ru>
Message-ID: <CA+ksgADvoqfKRNoQiRd4SJvCbvbidZ8==rw8iTXDKAx6teqZQQ@mail.gmail.com>

При директивах

вт, 6 окт. 2020 г. в 17:16, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Oct 06, 2020 at 10:42:47AM +0300, Evgeniy Berdnikov wrote:
>
> > On Mon, Oct 05, 2020 at 10:24:17PM +0300, Alexey wrote:
> > > День добрый!
> > >
> > > Вы качаете файл, получаемых от прокси апстрима?
> > >
> https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size
> > >
> > > Вы упираетесь в 1Гб временного файла. когда качается быстро, он
> > > вообще в темп не пишется, если файл прилетает от апстрима быстрее
> > > чем забираем, то он уже пишется во временный файл. вы успеваете
> > > скачать столько, сколько прилетает до начала записи во временный
> > > файл + макс размер файла.
> >
> >  Наличие лимита на размер временного файла это что, повод обрывать
> закачку?
>
> Наличие лимита - ни разу не повод обрывать закачку, nginx её и не
> обрывает.
>
> Другой вопрос, что если буфер забит - nginx'у некуда читать
> дополнительные данные, и в результате бэкенд может закрыть
> соединение по таймауту до того, как содержимое временного файла
> будет отдано клиену и соответственно nginx сможет дальше читать
> что-либо от бэкенда.
>
> При заявленном ограничении скорости в 2 мегабайта в секунду -
> отправка клиенту гигабайта временных данных займёт секунд 500
> минимум.  Если при этом с бэкенда эти данные летят по гигабитному
> каналу со скоростью 100 мегабайт в секунду - прилетят они секунд за
> 10.  То есть между nginx'ом и бэкендом 490 секунд ничего не будет
> происходить.  Шансов на то, что бэкенд дождётся при настройках по
> умолчанию - никаких.
>
> Соответственно нужно:
>
> - увеличить временный файл, чтобы ответы влезали;
>
> - или уменьшить временный файл, чтобы его содержимое могло
>   отправиться до того, как сработает таймаут на бэкенде.
>
> Ну либо настраивать таймауты на бэкенде и/или ограничение
> скорости, чтобы опять же временный файл мог отправиться до того,
> как сработает таймаут на бэкенде.
>
> Вообще, когда речь идёт о том, что проксируются большие файлы -
> одним из лучших решений может быть просто выключенная буферизация
> на диск, "proxy_max_temp_file_size 0;".  Это позволяет избежать не
> только проблем с таймаутами на бэкенде, но и траты ресурсов на
> disk i/o, а равно проблем с переполнением диска под временные
> файлы при большом количестве одновременных запросов.
>
> [...]
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201007/2b6b9564/attachment.htm>

From simplebox66 на gmail.com  Wed Oct  7 15:10:01 2020
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 7 Oct 2020 18:10:01 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <CA+ksgADvoqfKRNoQiRd4SJvCbvbidZ8==rw8iTXDKAx6teqZQQ@mail.gmail.com>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
 <20201006141632.GQ1136@mdounin.ru>
 <CA+ksgADvoqfKRNoQiRd4SJvCbvbidZ8==rw8iTXDKAx6teqZQQ@mail.gmail.com>
Message-ID: <CA+ksgADUFmJdvWqFh_LG0JMxc2v28Tmm3jQ16N2A8f1P08PB8g@mail.gmail.com>

При директивах
limit_rate_after 150000k; #150Mb
limit_rate 2048k;
proxy_max_temp_file_size 0;
Скачивание происходит так как и ожидается, без обрывов и прочего, а так же
обрезается скорость правильным образом в соответствии с  директивами
limit_rate_after и  limit_rate.

Но вот при такой конфигурации:
limit_rate_after 150000k; #150Mb
limit_rate 2048k;
proxy_max_temp_file_size 6144m;

Поведение не понятно. При таких параметрах директив работает так -
скачивается 150Мб и затем обрыв. Почему?

ср, 7 окт. 2020 г. в 18:07, Иван Мишин <simplebox66 на gmail.com>:

> При директивах
>
> вт, 6 окт. 2020 г. в 17:16, Maxim Dounin <mdounin на mdounin.ru>:
>
>> Hello!
>>
>> On Tue, Oct 06, 2020 at 10:42:47AM +0300, Evgeniy Berdnikov wrote:
>>
>> > On Mon, Oct 05, 2020 at 10:24:17PM +0300, Alexey wrote:
>> > > День добрый!
>> > >
>> > > Вы качаете файл, получаемых от прокси апстрима?
>> > >
>> https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size
>> > >
>> > > Вы упираетесь в 1Гб временного файла. когда качается быстро, он
>> > > вообще в темп не пишется, если файл прилетает от апстрима быстрее
>> > > чем забираем, то он уже пишется во временный файл. вы успеваете
>> > > скачать столько, сколько прилетает до начала записи во временный
>> > > файл + макс размер файла.
>> >
>> >  Наличие лимита на размер временного файла это что, повод обрывать
>> закачку?
>>
>> Наличие лимита - ни разу не повод обрывать закачку, nginx её и не
>> обрывает.
>>
>> Другой вопрос, что если буфер забит - nginx'у некуда читать
>> дополнительные данные, и в результате бэкенд может закрыть
>> соединение по таймауту до того, как содержимое временного файла
>> будет отдано клиену и соответственно nginx сможет дальше читать
>> что-либо от бэкенда.
>>
>> При заявленном ограничении скорости в 2 мегабайта в секунду -
>> отправка клиенту гигабайта временных данных займёт секунд 500
>> минимум.  Если при этом с бэкенда эти данные летят по гигабитному
>> каналу со скоростью 100 мегабайт в секунду - прилетят они секунд за
>> 10.  То есть между nginx'ом и бэкендом 490 секунд ничего не будет
>> происходить.  Шансов на то, что бэкенд дождётся при настройках по
>> умолчанию - никаких.
>>
>> Соответственно нужно:
>>
>> - увеличить временный файл, чтобы ответы влезали;
>>
>> - или уменьшить временный файл, чтобы его содержимое могло
>>   отправиться до того, как сработает таймаут на бэкенде.
>>
>> Ну либо настраивать таймауты на бэкенде и/или ограничение
>> скорости, чтобы опять же временный файл мог отправиться до того,
>> как сработает таймаут на бэкенде.
>>
>> Вообще, когда речь идёт о том, что проксируются большие файлы -
>> одним из лучших решений может быть просто выключенная буферизация
>> на диск, "proxy_max_temp_file_size 0;".  Это позволяет избежать не
>> только проблем с таймаутами на бэкенде, но и траты ресурсов на
>> disk i/o, а равно проблем с переполнением диска под временные
>> файлы при большом количестве одновременных запросов.
>>
>> [...]
>>
>> --
>> Maxim Dounin
>> http://mdounin.ru/
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201007/e8eefd86/attachment-0001.htm>

From bgx на protva.ru  Wed Oct  7 15:22:30 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 7 Oct 2020 18:22:30 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QsCDRgNCw0LHQvtGC0LAgbGltaXRfcmF0ZQ==?=
In-Reply-To: <CA+ksgADUFmJdvWqFh_LG0JMxc2v28Tmm3jQ16N2A8f1P08PB8g@mail.gmail.com>
References: <CA+ksgAChY0PKBs=6udKYvfqMf_qkcy9fm8ogDL6E-mNAX17jXA@mail.gmail.com>
 <CA+ksgADnft7ZR=XBZTfn_VEMjcqEVhae2YoQXdfQfCB419Ufsg@mail.gmail.com>
 <c3c414cb-7c3f-5078-01ac-4a8d60b5f543@avksrv.org>
 <20201006074247.GC2639@protva.ru>
 <20201006141632.GQ1136@mdounin.ru>
 <CA+ksgADvoqfKRNoQiRd4SJvCbvbidZ8==rw8iTXDKAx6teqZQQ@mail.gmail.com>
 <CA+ksgADUFmJdvWqFh_LG0JMxc2v28Tmm3jQ16N2A8f1P08PB8g@mail.gmail.com>
Message-ID: <20201007152230.GL2686@sie.protva.ru>

On Wed, Oct 07, 2020 at 06:10:01PM +0300, Иван Мишин wrote:
>    Но вот при такой конфигурации:
>    limit_rate_after 150000k; #150Mb
>    limit_rate 2048k;
>    proxy_max_temp_file_size 6144m;  
>    Поведение не понятно. При таких параметрах директив работает так -
>    скачивается 150Мб и затем обрыв. Почему?

 Посмотрите логи прокси и бэкенда, посмотрите что выдаёт "wget -d".
 Для полноты можно посмотреть анализатором трафика где какая коннекция
 закрывается, обратить внимание на отметки времени, сравнить с заданными
 на всех узлах таймаутами.
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Thu Oct  8 08:06:25 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Thu, 08 Oct 2020 04:06:25 -0400
Subject: =?UTF-8?B?bmdpbngg0L3QtSDRgNC10LDQs9C40YDRg9C10YIgSWYtTW9kaWZpZWQtU2luY2U=?=
Message-ID: <eb0cfbaf657f69967ac53cf3bcdd75fa.NginxMailingListRussian@forum.nginx.org>

Привет всем!

nginx раздает статические файлы графики. Сейчас заметил, что он не реагирует
на If-Modified-Since и каждый раз отдает файл заново с кодом ответа 200,
вместо 304.

Подскажите, что прописать в конфиге, чтобы он учитывал дату последнего
изменения файла графики?

Спасибо.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289685,289685#msg-289685


From pluknet на nginx.com  Thu Oct  8 09:41:13 2020
From: pluknet на nginx.com (Sergey Kandaurov)
Date: Thu, 8 Oct 2020 10:41:13 +0100
Subject: =?UTF-8?B?UmU6IG5naW54INC90LUg0YDQtdCw0LPQuNGA0YPQtdGCIElmLU1vZGlmaWVkLVNp?=
 =?UTF-8?B?bmNl?=
In-Reply-To: <eb0cfbaf657f69967ac53cf3bcdd75fa.NginxMailingListRussian@forum.nginx.org>
References: <eb0cfbaf657f69967ac53cf3bcdd75fa.NginxMailingListRussian@forum.nginx.org>
Message-ID: <DFD61230-C268-4C3E-991C-D073BFB59A08@nginx.com>


> On 8 Oct 2020, at 09:06, grey <nginx-forum на forum.nginx.org> wrote:
> 
> Привет всем!
> 
> nginx раздает статические файлы графики. Сейчас заметил, что он не реагирует
> на If-Modified-Since и каждый раз отдает файл заново с кодом ответа 200,
> вместо 304.
> 
> Подскажите, что прописать в конфиге, чтобы он учитывал дату последнего
> изменения файла графики?

Дата учитывается, но см. http://nginx.org/r/if_modified_since

-- 
Sergey Kandaurov


From akapulko на gmail.com  Fri Oct  9 10:27:30 2020
From: akapulko на gmail.com (Vladislav V. Prodan)
Date: Fri, 9 Oct 2020 13:27:30 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?=
 =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?=
In-Reply-To: <CAFHpkQF+4jALQ0hMohvGmpj2XrUBQeKb2Hdp5YN8BE93Xf6Kig@mail.gmail.com>
References: <20200924132659.GK1136@mdounin.ru>
 <CAFHpkQGL062ZLJkaY0sL2mmv_qEj-byQVZYEJtWHh4TbeXzz2Q@mail.gmail.com>
 <20200924160606.GL4644@sie.protva.ru>
 <CAFHpkQHsjVJ+CETQ-Aj_McgdKsSzuN5HDOf7HhM6tR-OjQqXJA@mail.gmail.com>
 <20200924170153.GM4644@sie.protva.ru>
 <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net>
 <20200925043217.GO4644@sie.protva.ru>
 <edc6f7b1-820a-1130-2fbf-92af8c168f97@grosbein.net>
 <20200925163417.GQ4644@sie.protva.ru>
 <CAFHpkQFO1sOR9Az0K3xfLgDgnJANM0K_ukfGw96NKcmdBX0jPQ@mail.gmail.com>
 <20200925164906.GR4644@sie.protva.ru>
 <CAFHpkQF+4jALQ0hMohvGmpj2XrUBQeKb2Hdp5YN8BE93Xf6Kig@mail.gmail.com>
Message-ID: <CAH4R=3noMuV+AbFnu-95EVKyXJpxsQuE_j0HKgBmvOvSyeRkSA@mail.gmail.com>

пт, 25 сент. 2020 г. в 19:53, Илья Шипицин <chipitsine на gmail.com>:

>
>
> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov <bgx на protva.ru>:
>
>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>> >       Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>> >      собирать?
>> >
>> >    по нашей оценке 1 пользователь на 10 тысяч пользователей
>> сталкивается с
>> >    поломанным MTU
>>
>>  Какое значение MSS анонсируют ваши серверы?
>>
>
> 1416
>

Здравствуйте.
И как вы на сервере (с nginx) это изменили?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201009/b766d740/attachment.htm>

From chipitsine на gmail.com  Fri Oct  9 10:34:33 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 9 Oct 2020 15:34:33 +0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?=
 =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?=
In-Reply-To: <CAH4R=3noMuV+AbFnu-95EVKyXJpxsQuE_j0HKgBmvOvSyeRkSA@mail.gmail.com>
References: <20200924132659.GK1136@mdounin.ru>
 <CAFHpkQGL062ZLJkaY0sL2mmv_qEj-byQVZYEJtWHh4TbeXzz2Q@mail.gmail.com>
 <20200924160606.GL4644@sie.protva.ru>
 <CAFHpkQHsjVJ+CETQ-Aj_McgdKsSzuN5HDOf7HhM6tR-OjQqXJA@mail.gmail.com>
 <20200924170153.GM4644@sie.protva.ru>
 <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net>
 <20200925043217.GO4644@sie.protva.ru>
 <edc6f7b1-820a-1130-2fbf-92af8c168f97@grosbein.net>
 <20200925163417.GQ4644@sie.protva.ru>
 <CAFHpkQFO1sOR9Az0K3xfLgDgnJANM0K_ukfGw96NKcmdBX0jPQ@mail.gmail.com>
 <20200925164906.GR4644@sie.protva.ru>
 <CAFHpkQF+4jALQ0hMohvGmpj2XrUBQeKb2Hdp5YN8BE93Xf6Kig@mail.gmail.com>
 <CAH4R=3noMuV+AbFnu-95EVKyXJpxsQuE_j0HKgBmvOvSyeRkSA@mail.gmail.com>
Message-ID: <CAFHpkQHOa5OkcCzb36qY+fL-_Z2voW8rvODvkttXdufsm5zkhw@mail.gmail.com>

пт, 9 окт. 2020 г. в 15:28, Vladislav V. Prodan <akapulko на gmail.com>:

>
>
> пт, 25 сент. 2020 г. в 19:53, Илья Шипицин <chipitsine на gmail.com>:
>
>>
>>
>> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov <bgx на protva.ru>:
>>
>>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>>> >       Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>>> >      собирать?
>>> >
>>> >    по нашей оценке 1 пользователь на 10 тысяч пользователей
>>> сталкивается с
>>> >    поломанным MTU
>>>
>>>  Какое значение MSS анонсируют ваши серверы?
>>>
>>
>> 1416
>>
>
> Здравствуйте.
> И как вы на сервере (с nginx) это изменили?
>

iptables


>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201009/c72ecb2d/attachment.htm>

From akapulko на gmail.com  Fri Oct  9 10:49:59 2020
From: akapulko на gmail.com (Vladislav V. Prodan)
Date: Fri, 9 Oct 2020 13:49:59 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?=
 =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?=
In-Reply-To: <CAFHpkQHOa5OkcCzb36qY+fL-_Z2voW8rvODvkttXdufsm5zkhw@mail.gmail.com>
References: <20200924132659.GK1136@mdounin.ru>
 <CAFHpkQGL062ZLJkaY0sL2mmv_qEj-byQVZYEJtWHh4TbeXzz2Q@mail.gmail.com>
 <20200924160606.GL4644@sie.protva.ru>
 <CAFHpkQHsjVJ+CETQ-Aj_McgdKsSzuN5HDOf7HhM6tR-OjQqXJA@mail.gmail.com>
 <20200924170153.GM4644@sie.protva.ru>
 <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net>
 <20200925043217.GO4644@sie.protva.ru>
 <edc6f7b1-820a-1130-2fbf-92af8c168f97@grosbein.net>
 <20200925163417.GQ4644@sie.protva.ru>
 <CAFHpkQFO1sOR9Az0K3xfLgDgnJANM0K_ukfGw96NKcmdBX0jPQ@mail.gmail.com>
 <20200925164906.GR4644@sie.protva.ru>
 <CAFHpkQF+4jALQ0hMohvGmpj2XrUBQeKb2Hdp5YN8BE93Xf6Kig@mail.gmail.com>
 <CAH4R=3noMuV+AbFnu-95EVKyXJpxsQuE_j0HKgBmvOvSyeRkSA@mail.gmail.com>
 <CAFHpkQHOa5OkcCzb36qY+fL-_Z2voW8rvODvkttXdufsm5zkhw@mail.gmail.com>
Message-ID: <CAH4R=3=9_fCc8gz34NW-B3q=aUo-bLuF_rGx=nE3T+5-10rdAg@mail.gmail.com>

пт, 9 окт. 2020 г. в 13:34, Илья Шипицин <chipitsine на gmail.com>:

>
>
> пт, 9 окт. 2020 г. в 15:28, Vladislav V. Prodan <akapulko на gmail.com>:
>
>>
>>
>> пт, 25 сент. 2020 г. в 19:53, Илья Шипицин <chipitsine на gmail.com>:
>>
>>>
>>>
>>> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov <bgx на protva.ru>:
>>>
>>>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>>>> >       Насчёт "самая распостранённая" -- статистика есть? Как её вообще
>>>> >      собирать?
>>>> >
>>>> >    по нашей оценке 1 пользователь на 10 тысяч пользователей
>>>> сталкивается с
>>>> >    поломанным MTU
>>>>
>>>>  Какое значение MSS анонсируют ваши серверы?
>>>>
>>>
>>> 1416
>>>
>>
>> Здравствуйте.
>> И как вы на сервере (с nginx) это изменили?
>>
>
> iptables
>
>

А можно более подробно это правило показать?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201009/207d761b/attachment.htm>

From chipitsine на gmail.com  Fri Oct  9 10:58:25 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 9 Oct 2020 15:58:25 +0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?=
 =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?=
In-Reply-To: <CAH4R=3=9_fCc8gz34NW-B3q=aUo-bLuF_rGx=nE3T+5-10rdAg@mail.gmail.com>
References: <20200924132659.GK1136@mdounin.ru>
 <CAFHpkQGL062ZLJkaY0sL2mmv_qEj-byQVZYEJtWHh4TbeXzz2Q@mail.gmail.com>
 <20200924160606.GL4644@sie.protva.ru>
 <CAFHpkQHsjVJ+CETQ-Aj_McgdKsSzuN5HDOf7HhM6tR-OjQqXJA@mail.gmail.com>
 <20200924170153.GM4644@sie.protva.ru>
 <04b7f80c-c568-8168-734b-e63b9e4d791d@grosbein.net>
 <20200925043217.GO4644@sie.protva.ru>
 <edc6f7b1-820a-1130-2fbf-92af8c168f97@grosbein.net>
 <20200925163417.GQ4644@sie.protva.ru>
 <CAFHpkQFO1sOR9Az0K3xfLgDgnJANM0K_ukfGw96NKcmdBX0jPQ@mail.gmail.com>
 <20200925164906.GR4644@sie.protva.ru>
 <CAFHpkQF+4jALQ0hMohvGmpj2XrUBQeKb2Hdp5YN8BE93Xf6Kig@mail.gmail.com>
 <CAH4R=3noMuV+AbFnu-95EVKyXJpxsQuE_j0HKgBmvOvSyeRkSA@mail.gmail.com>
 <CAFHpkQHOa5OkcCzb36qY+fL-_Z2voW8rvODvkttXdufsm5zkhw@mail.gmail.com>
 <CAH4R=3=9_fCc8gz34NW-B3q=aUo-bLuF_rGx=nE3T+5-10rdAg@mail.gmail.com>
Message-ID: <CAFHpkQE02_x_ySv4NkT+9C6amYtJWdM6vom7MXCHiB7WZdLjew@mail.gmail.com>

пт, 9 окт. 2020 г. в 15:50, Vladislav V. Prodan <akapulko на gmail.com>:

>
>
> пт, 9 окт. 2020 г. в 13:34, Илья Шипицин <chipitsine на gmail.com>:
>
>>
>>
>> пт, 9 окт. 2020 г. в 15:28, Vladislav V. Prodan <akapulko на gmail.com>:
>>
>>>
>>>
>>> пт, 25 сент. 2020 г. в 19:53, Илья Шипицин <chipitsine на gmail.com>:
>>>
>>>>
>>>>
>>>> пт, 25 сент. 2020 г. в 21:49, Evgeniy Berdnikov <bgx на protva.ru>:
>>>>
>>>>> On Fri, Sep 25, 2020 at 09:45:17PM +0500, Илья Шипицин wrote:
>>>>> >       Насчёт "самая распостранённая" -- статистика есть? Как её
>>>>> вообще
>>>>> >      собирать?
>>>>> >
>>>>> >    по нашей оценке 1 пользователь на 10 тысяч пользователей
>>>>> сталкивается с
>>>>> >    поломанным MTU
>>>>>
>>>>>  Какое значение MSS анонсируют ваши серверы?
>>>>>
>>>>
>>>> 1416
>>>>
>>>
>>> Здравствуйте.
>>> И как вы на сервере (с nginx) это изменили?
>>>
>>
>> iptables
>>
>>
>
> А можно более подробно это правило показать?
>

NDA.

можно подсмотреть вот тут https://www.opennet.ru/docs/RUS/LARTC/x2657.html


>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201009/0b3f6bb9/attachment-0001.htm>

From sergio на outerface.net  Tue Oct 13 06:46:06 2020
From: sergio на outerface.net (sergio)
Date: Tue, 13 Oct 2020 09:46:06 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?=
 =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?=
In-Reply-To: <20200924132659.GK1136@mdounin.ru>
References: <20200923061936.GF4644@sie.protva.ru>
 <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com>
 <CAH4R=3nZong4gWZf2ApK4OjXp0ZtiXe-Cm3s9x3tp469ev32KA@mail.gmail.com>
 <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com>
 <CAH4R=3nTgVZn-oEKmSiyrD_rni-p7Fuy8N-XBPh4D7umuAd6wg@mail.gmail.com>
 <20200923161358.GG1136@mdounin.ru>
 <CAH4R=3nfLUv9SZ_gM0OmuiHOiQLsMYcQ5Wkt7EYLjeksZm1XBw@mail.gmail.com>
 <20200923192422.GI1136@mdounin.ru>
 <CAH4R=3moDfGiT4XyNOnrWfFSvud7VD6G9YfwNwquwQ2TaU=gEw@mail.gmail.com>
 <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com>
 <20200924132659.GK1136@mdounin.ru>
Message-ID: <8f20052c-c633-0ec4-c3d8-ce8cc54144c5@outerface.net>

On 24/09/2020 16:26, Maxim Dounin wrote:

> Но с нашей стороны явно имеет смысл проверить, что ICMP
> fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей
> ответственности ходят нормально и не зафильтрованы.  С учётом
> того, что пинги не ходят - у меня вот лично в этом сомнения.


Есть подозрение, что действительно зафильтрованы. Проверьте пожалуйста.


-- 
sergio.

From sergio на outerface.net  Thu Oct 15 21:06:15 2020
From: sergio на outerface.net (sergio)
Date: Fri, 16 Oct 2020 00:06:15 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?=
 =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?=
In-Reply-To: <8f20052c-c633-0ec4-c3d8-ce8cc54144c5@outerface.net>
References: <20200923061936.GF4644@sie.protva.ru>
 <86D49912-4572-416F-B0D4-0306C971FDC7@nginx.com>
 <CAH4R=3nZong4gWZf2ApK4OjXp0ZtiXe-Cm3s9x3tp469ev32KA@mail.gmail.com>
 <85E8C4EE-2777-49CD-A3B7-830743B18C80@nginx.com>
 <CAH4R=3nTgVZn-oEKmSiyrD_rni-p7Fuy8N-XBPh4D7umuAd6wg@mail.gmail.com>
 <20200923161358.GG1136@mdounin.ru>
 <CAH4R=3nfLUv9SZ_gM0OmuiHOiQLsMYcQ5Wkt7EYLjeksZm1XBw@mail.gmail.com>
 <20200923192422.GI1136@mdounin.ru>
 <CAH4R=3moDfGiT4XyNOnrWfFSvud7VD6G9YfwNwquwQ2TaU=gEw@mail.gmail.com>
 <0EB537D4-BA05-48F2-8509-2F7F695463AF@nginx.com>
 <20200924132659.GK1136@mdounin.ru>
 <8f20052c-c633-0ec4-c3d8-ce8cc54144c5@outerface.net>
Message-ID: <418a77d5-e4b0-fb9d-bb1e-6e19d4d88e02@outerface.net>

Уважаемые администраторы, проверьте пожалуйста, что на вашей стороне не 
фильтруется ICMPv6, в частности packet-too-big.

On 13/10/2020 09:46, sergio wrote:
> On 24/09/2020 16:26, Maxim Dounin wrote:
> 
>> Но с нашей стороны явно имеет смысл проверить, что ICMP
>> fragmentation needed (ICMPv6 Packet Too Big) в зоне нашей
>> ответственности ходят нормально и не зафильтрованы.  С учётом
>> того, что пинги не ходят - у меня вот лично в этом сомнения.
> 
> 
> Есть подозрение, что действительно зафильтрованы. Проверьте пожалуйста.


-- 
sergio.

From sb на nginx.com  Fri Oct 16 09:12:34 2020
From: sb на nginx.com (Sergey Budnevitch)
Date: Fri, 16 Oct 2020 12:12:34 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YHQviDRgdCy0Y/Qt9C90L7RgdGC0YzRjiA=?=
 =?UTF-8?B?0L/QviBpcHY2INGB0LDQudGC0LAgbmdpbngub3Jn?=
In-Reply-To: <418a77d5-e4b0-fb9d-bb1e-6e19d4d88e02@outerface.net>
References: <418a77d5-e4b0-fb9d-bb1e-6e19d4d88e02@outerface.net>
Message-ID: <7679FDFD-D876-42C8-916A-7B892787E894@nginx.com>


> On 16 Oct 2020, at 00:06, sergio <sergio на outerface.net> wrote:
> 
> Уважаемые администраторы, проверьте пожалуйста, что на вашей стороне не фильтруется ICMPv6, в частности packet-too-big.

Не фильтруется.


From nginx-forum на forum.nginx.org  Tue Oct 20 05:07:32 2020
From: nginx-forum на forum.nginx.org (Zalman_)
Date: Tue, 20 Oct 2020 01:07:32 -0400
Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCINGA0LXQtNC40YDQtdC60YIg0L3QsCBIVFRQ?=
 =?UTF-8?B?Uy4gT3BlblNTTC4=?=
Message-ID: <4c13a7bf990023569a356b62813c236b.NginxMailingListRussian@forum.nginx.org>

Доброго времени суток!

Нужна помощь по вопросу SSL шифрования.

Объясню, что есть и что уже имеется.

Основная задача – поднять RocketChat на локальном сервере и обеспечить
шифрование при доступе к локальному серверу из вне.

Для этих целей использовал Ubuntu 18.04 LTS на виртуалке на сервере. В
качестве веб-сервера использовал Nginx - 1.14.0 (Ubuntu), а в качестве СУБД
использую MongoDB - db version v4.0.20. Использование Nginx и MongoDB
описано в мануале по установке RocketChat.
Все это удалось сделать и все хорошо работает. То есть Nginx + MongoDB +
RocketChat хорошо работают как в локальной сети, так и из вне (с помощью
проброса портов). Однако не удается подключить SSL – сертификат. Так как
сервер поднимался локально (доступ из вне и локально осуществляется через
IP-адрес сервера и порт) и отсутствует какой-то домен, то получение
SSL-сертификата от Let’S Encrypt является проблематичным, поэтому выбрал
самоподписанный SSL-сертификат на основе OpenSSL.
Приватный ключ, сертификат, а также ключ Диффи-Хеллмана сделал. Конфиги
nginx.conf, а также конфиг в папке
/etc/nginx/sites-available/rocketchat.conf настроил, однако по каким-то
причинам доступ к чату есть через HTTP, но нет через HTTPS. 

С этой темой сижу уже достаточно долго. Пробовал много способов и много
различных конфигов, но все равно не работает. 
Причем пробовал как с отключенным UFW, так и с включенным (разрешал
подключение по портам 80, 443, *нужный мне порт*). Также в iptables тоже
разрешил 3 предыдущих порта, но эффекта ноль.

А вот тут я приведу конфиги.
/etc/nginx/nginx.conf
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {
        ##
        # Basic Settings
        ##
        #sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##
        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json
application/javascript text/xml application/xml applicatio$

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*.conf;
}

#mail {
#       # See sample authentication script at:
#       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#       # auth_http localhost/auth.php;
#       # pop3_capabilities "TOP" "USER";
#       # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#       server {
#               listen     localhost:110;
#               protocol   pop3;
#               proxy      on;
#       }
#
#       server {
#               listen     localhost:143;
#               protocol   imap;
#               proxy      on;
#       }
#}

/etc/nginx/sites-available/default.conf

upstream backend {
   server 127.0.0.1;
}

#HTTP
server {
        #Делаю конфиг согласно
https://techlist.top/translation-nginx-to-https/
        listen 80;
        server_name *IP локального сервера*;
        return 301 https://$server_name$request_uri;
}

#HTTPS
server {
        #Порт, который будет слушать Nginx для SSL
        listen 443 ssl http2;

        #Имя сайта
        server_name *IP локального сервера*;

        #Корневая директория и индексный файл (ничего не менял)
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;

        #Лог-файлы
        access_log  /var/www/html/access_https.log;
        error_log   /var/www/html/error_https.log;

        #SSL-секция

        #Сертификат и ключ
        ssl_certificate /etc/ssl/certs/rccrt.crt;
        ssl_certificate_key /etc/ssl/private/rckey.key;

        #SSL-сессия
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;

        #Diffie-Hellman ключ для DHE-шифров
        ssl_dhparam /etc/ssl/certs/dhparam.pem;

        #Используемые протоколы
        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        #Наборы шифров
        ssl_ciphers '*набор шифров*';

        #Приоритет серверных шифров
        ssl_prefer_server_ciphers on;

        #Включение HSTS (Strict-Transport-Security)(15768000 seconds = 6
месяцев)
        add_header Strict-Transport-Security max-age=15768000;

        resolver 8.8.8.8 8.8.4.4 valid=300s;

       # server_name _;

       location / {
                # Параметры проксирования
        proxy_send_timeout 600;
        proxy_read_timeout 600;
        proxy_buffer_size   128k;
        proxy_buffers   4 256k;
        proxy_busy_buffers_size   256k;
        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-Proto $scheme;
        proxy_set_header HTTPS YES;
        # IP-адрес целевой площадки для проксирования
        proxy_pass http://192.168.1.108;
        }

        # pass the PHP scripts to FastCGI server listening on
127.0.0.1:9000
        #
        #location ~ \.php$ {
        # include snippets/fastcgi-php.conf;
        #
        #       # With php7.0-cgi alone:
        #       fastcgi_pass 127.0.0.1:9000;
        #       # With php7.0-fpm:
        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}
}

Далее делаю «копию» в папку sites-enabled
sudo ln -s /etc/nginx/sites-available/default.conf
/etc/nginx/sites-enabled/

Проверяю синтаксис
sudo nginx -t
(на что получаю положительный ответ)
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

И последовательно делаю перезапуск Nginx
sudo service nginx restart
sudo systemctl restart nginx

В итоге, набирая IP и порт и пытаясь подключиться по HTTPS, в Google Chrome
вижу ошибку ERR_CONNECTION_CLOSED. В чем может быть проблема?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289759#msg-289759


From shadow.tehb на gmail.com  Tue Oct 20 06:52:18 2020
From: shadow.tehb на gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCe0LvQtdCz0L7QstC40Yc=?=)
Date: Tue, 20 Oct 2020 09:52:18 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <4c13a7bf990023569a356b62813c236b.NginxMailingListRussian@forum.nginx.org>
References: <4c13a7bf990023569a356b62813c236b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <17544c7acd0.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>

Клиент, в роли браузера, должен знать о вашем центре сертификации. Вы 
добавляли его сертификат в браузер?

"Zalman_" <nginx-forum на forum.nginx.org> 20 октября 2020 г. 08:07:44 написал:

> Доброго времени суток!
>
> Нужна помощь по вопросу SSL шифрования.
>
> Объясню, что есть и что уже имеется.
>
> Основная задача – поднять RocketChat на локальном сервере и обеспечить
> шифрование при доступе к локальному серверу из вне.
>
> Для этих целей использовал Ubuntu 18.04 LTS на виртуалке на сервере. В
> качестве веб-сервера использовал Nginx - 1.14.0 (Ubuntu), а в качестве СУБД
> использую MongoDB - db version v4.0.20. Использование Nginx и MongoDB
> описано в мануале по установке RocketChat.
> Все это удалось сделать и все хорошо работает. То есть Nginx + MongoDB +
> RocketChat хорошо работают как в локальной сети, так и из вне (с помощью
> проброса портов). Однако не удается подключить SSL – сертификат. Так как
> сервер поднимался локально (доступ из вне и локально осуществляется через
> IP-адрес сервера и порт) и отсутствует какой-то домен, то получение
> SSL-сертификата от Let’S Encrypt является проблематичным, поэтому выбрал
> самоподписанный SSL-сертификат на основе OpenSSL.
> Приватный ключ, сертификат, а также ключ Диффи-Хеллмана сделал. Конфиги
> nginx.conf, а также конфиг в папке
> /etc/nginx/sites-available/rocketchat.conf настроил, однако по каким-то
> причинам доступ к чату есть через HTTP, но нет через HTTPS.
>
> С этой темой сижу уже достаточно долго. Пробовал много способов и много
> различных конфигов, но все равно не работает.
> Причем пробовал как с отключенным UFW, так и с включенным (разрешал
> подключение по портам 80, 443, *нужный мне порт*). Также в iptables тоже
> разрешил 3 предыдущих порта, но эффекта ноль.
>
> А вот тут я приведу конфиги.
> /etc/nginx/nginx.conf
> user www-data;
> worker_processes auto;
> pid /run/nginx.pid;
> include /etc/nginx/modules-enabled/*.conf;
>
> events {
>        worker_connections 768;
>        # multi_accept on;
> }
>
> http {
>        ##
>        # Basic Settings
>        ##
>        #sendfile on;
>        tcp_nopush on;
>        tcp_nodelay on;
>        keepalive_timeout 65;
>        types_hash_max_size 2048;
>        # server_tokens off;
>
>        # server_names_hash_bucket_size 64;
>        # server_name_in_redirect off;
>
>        include /etc/nginx/mime.types;
>        default_type application/octet-stream;
>
>        ##
>        # SSL Settings
>        ##
>        ##
>        # Logging Settings
>        ##
>
>        access_log /var/log/nginx/access.log;
>        error_log /var/log/nginx/error.log;
>
>        ##
>        # Gzip Settings
>        ##
>
>        gzip on;
>
>        # gzip_vary on;
>        # gzip_proxied any;
>        # gzip_comp_level 6;
>        # gzip_buffers 16 8k;
>        # gzip_http_version 1.1;
>        # gzip_types text/plain text/css application/json
> application/javascript text/xml application/xml applicatio$
>
>        ##
>        # Virtual Host Configs
>        ##
>
>        include /etc/nginx/conf.d/*.conf;
>        include /etc/nginx/sites-enabled/*.conf;
> }
>
> #mail {
> #       # See sample authentication script at:
> #       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
> #
> #       # auth_http localhost/auth.php;
> #       # pop3_capabilities "TOP" "USER";
> #       # imap_capabilities "IMAP4rev1" "UIDPLUS";
> #
> #       server {
> #               listen     localhost:110;
> #               protocol   pop3;
> #               proxy      on;
> #       }
> #
> #       server {
> #               listen     localhost:143;
> #               protocol   imap;
> #               proxy      on;
> #       }
> #}
>
> /etc/nginx/sites-available/default.conf
>
> upstream backend {
>   server 127.0.0.1;
> }
>
> #HTTP
> server {
>        #Делаю конфиг согласно
> https://techlist.top/translation-nginx-to-https/
>        listen 80;
>        server_name *IP локального сервера*;
>        return 301 https://$server_name$request_uri;
> }
>
> #HTTPS
> server {
>        #Порт, который будет слушать Nginx для SSL
>        listen 443 ssl http2;
>
>        #Имя сайта
>        server_name *IP локального сервера*;
>
>        #Корневая директория и индексный файл (ничего не менял)
>        root /var/www/html;
>        index index.html index.htm index.nginx-debian.html;
>
>        #Лог-файлы
>        access_log  /var/www/html/access_https.log;
>        error_log   /var/www/html/error_https.log;
>
>        #SSL-секция
>
>        #Сертификат и ключ
>        ssl_certificate /etc/ssl/certs/rccrt.crt;
>        ssl_certificate_key /etc/ssl/private/rckey.key;
>
>        #SSL-сессия
>        ssl_session_timeout 1d;
>        ssl_session_cache shared:SSL:50m;
>        ssl_session_tickets off;
>
>        #Diffie-Hellman ключ для DHE-шифров
>        ssl_dhparam /etc/ssl/certs/dhparam.pem;
>
>        #Используемые протоколы
>        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
>
>        #Наборы шифров
>        ssl_ciphers '*набор шифров*';
>
>        #Приоритет серверных шифров
>        ssl_prefer_server_ciphers on;
>
>        #Включение HSTS (Strict-Transport-Security)(15768000 seconds = 6
> месяцев)
>        add_header Strict-Transport-Security max-age=15768000;
>
>        resolver 8.8.8.8 8.8.4.4 valid=300s;
>
>       # server_name _;
>
>       location / {
>                # Параметры проксирования
>        proxy_send_timeout 600;
>        proxy_read_timeout 600;
>        proxy_buffer_size   128k;
>        proxy_buffers   4 256k;
>        proxy_busy_buffers_size   256k;
>        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-Proto $scheme;
>        proxy_set_header HTTPS YES;
>        # IP-адрес целевой площадки для проксирования
>        proxy_pass http://192.168.1.108;
>        }
>
>        # pass the PHP scripts to FastCGI server listening on
> 127.0.0.1:9000
>        #
>        #location ~ \.php$ {
>        # include snippets/fastcgi-php.conf;
>        #
>        #       # With php7.0-cgi alone:
>        #       fastcgi_pass 127.0.0.1:9000;
>        #       # With php7.0-fpm:
>        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
>        #}
>
>        # deny access to .htaccess files, if Apache's document root
>        # concurs with nginx's one
>        #
>        #location ~ /\.ht {
>        #       deny all;
>        #}
> }
>
> Далее делаю «копию» в папку sites-enabled
> sudo ln -s /etc/nginx/sites-available/default.conf
> /etc/nginx/sites-enabled/
>
> Проверяю синтаксис
> sudo nginx -t
> (на что получаю положительный ответ)
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successful
>
> И последовательно делаю перезапуск Nginx
> sudo service nginx restart
> sudo systemctl restart nginx
>
> В итоге, набирая IP и порт и пытаясь подключиться по HTTPS, в Google Chrome
> вижу ошибку ERR_CONNECTION_CLOSED. В чем может быть проблема?
>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,289759,289759#msg-289759
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201020/d1204776/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Tue Oct 20 07:06:29 2020
From: nginx-forum на forum.nginx.org (Zalman_)
Date: Tue, 20 Oct 2020 03:06:29 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <17544c7acd0.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>
References: <17544c7acd0.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>
Message-ID: <ec7a84992b5521c4d40524e9ce4def1b.NginxMailingListRussian@forum.nginx.org>

imsystem Wrote:
-------------------------------------------------------
> Клиент, в роли браузера, должен знать о вашем центре сертификации. Вы 
> добавляли его сертификат в браузер?
> 
> "Zalman_" <nginx-forum на forum.nginx.org> 20 октября 2020 г. 08:07:44
> написал:
> 
> > Доброго времени суток!
> >
> > Нужна помощь по вопросу SSL шифрования.
> >
> > Объясню, что есть и что уже имеется.
> >
> > Основная задача – поднять RocketChat на локальном сервере и
> обеспечить
> > шифрование при доступе к локальному серверу из вне.
> >
> > Для этих целей использовал Ubuntu 18.04 LTS на виртуалке на сервере.
> В
> > качестве веб-сервера использовал Nginx - 1.14.0 (Ubuntu), а в
> качестве СУБД
> > использую MongoDB - db version v4.0.20. Использование Nginx и
> MongoDB
> > описано в мануале по установке RocketChat.
> > Все это удалось сделать и все хорошо работает. То есть Nginx +
> MongoDB +
> > RocketChat хорошо работают как в локальной сети, так и из вне (с
> помощью
> > проброса портов). Однако не удается подключить SSL – сертификат. Так
> как
> > сервер поднимался локально (доступ из вне и локально осуществляется
> через
> > IP-адрес сервера и порт) и отсутствует какой-то домен, то получение
> > SSL-сертификата от Let’S Encrypt является проблематичным, поэтому
> выбрал
> > самоподписанный SSL-сертификат на основе OpenSSL.
> > Приватный ключ, сертификат, а также ключ Диффи-Хеллмана сделал.
> Конфиги
> > nginx.conf, а также конфиг в папке
> > /etc/nginx/sites-available/rocketchat.conf настроил, однако по
> каким-то
> > причинам доступ к чату есть через HTTP, но нет через HTTPS.
> >
> > С этой темой сижу уже достаточно долго. Пробовал много способов и
> много
> > различных конфигов, но все равно не работает.
> > Причем пробовал как с отключенным UFW, так и с включенным (разрешал
> > подключение по портам 80, 443, *нужный мне порт*). Также в iptables
> тоже
> > разрешил 3 предыдущих порта, но эффекта ноль.
> >
> > А вот тут я приведу конфиги.
> > /etc/nginx/nginx.conf
> > user www-data;
> > worker_processes auto;
> > pid /run/nginx.pid;
> > include /etc/nginx/modules-enabled/*.conf;
> >
> > events {
> >        worker_connections 768;
> >        # multi_accept on;
> > }
> >
> > http {
> >        ##
> >        # Basic Settings
> >        ##
> >        #sendfile on;
> >        tcp_nopush on;
> >        tcp_nodelay on;
> >        keepalive_timeout 65;
> >        types_hash_max_size 2048;
> >        # server_tokens off;
> >
> >        # server_names_hash_bucket_size 64;
> >        # server_name_in_redirect off;
> >
> >        include /etc/nginx/mime.types;
> >        default_type application/octet-stream;
> >
> >        ##
> >        # SSL Settings
> >        ##
> >        ##
> >        # Logging Settings
> >        ##
> >
> >        access_log /var/log/nginx/access.log;
> >        error_log /var/log/nginx/error.log;
> >
> >        ##
> >        # Gzip Settings
> >        ##
> >
> >        gzip on;
> >
> >        # gzip_vary on;
> >        # gzip_proxied any;
> >        # gzip_comp_level 6;
> >        # gzip_buffers 16 8k;
> >        # gzip_http_version 1.1;
> >        # gzip_types text/plain text/css application/json
> > application/javascript text/xml application/xml applicatio$
> >
> >        ##
> >        # Virtual Host Configs
> >        ##
> >
> >        include /etc/nginx/conf.d/*.conf;
> >        include /etc/nginx/sites-enabled/*.conf;
> > }
> >
> > #mail {
> > #       # See sample authentication script at:
> > #       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
> > #
> > #       # auth_http localhost/auth.php;
> > #       # pop3_capabilities "TOP" "USER";
> > #       # imap_capabilities "IMAP4rev1" "UIDPLUS";
> > #
> > #       server {
> > #               listen     localhost:110;
> > #               protocol   pop3;
> > #               proxy      on;
> > #       }
> > #
> > #       server {
> > #               listen     localhost:143;
> > #               protocol   imap;
> > #               proxy      on;
> > #       }
> > #}
> >
> > /etc/nginx/sites-available/default.conf
> >
> > upstream backend {
> >   server 127.0.0.1;
> > }
> >
> > #HTTP
> > server {
> >        #Делаю конфиг согласно
> > https://techlist.top/translation-nginx-to-https/
> >        listen 80;
> >        server_name *IP локального сервера*;
> >        return 301 https://$server_name$request_uri;
> > }
> >
> > #HTTPS
> > server {
> >        #Порт, который будет слушать Nginx для SSL
> >        listen 443 ssl http2;
> >
> >        #Имя сайта
> >        server_name *IP локального сервера*;
> >
> >        #Корневая директория и индексный файл (ничего не менял)
> >        root /var/www/html;
> >        index index.html index.htm index.nginx-debian.html;
> >
> >        #Лог-файлы
> >        access_log  /var/www/html/access_https.log;
> >        error_log   /var/www/html/error_https.log;
> >
> >        #SSL-секция
> >
> >        #Сертификат и ключ
> >        ssl_certificate /etc/ssl/certs/rccrt.crt;
> >        ssl_certificate_key /etc/ssl/private/rckey.key;
> >
> >        #SSL-сессия
> >        ssl_session_timeout 1d;
> >        ssl_session_cache shared:SSL:50m;
> >        ssl_session_tickets off;
> >
> >        #Diffie-Hellman ключ для DHE-шифров
> >        ssl_dhparam /etc/ssl/certs/dhparam.pem;
> >
> >        #Используемые протоколы
> >        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
> >
> >        #Наборы шифров
> >        ssl_ciphers '*набор шифров*';
> >
> >        #Приоритет серверных шифров
> >        ssl_prefer_server_ciphers on;
> >
> >        #Включение HSTS (Strict-Transport-Security)(15768000 seconds
> = 6
> > месяцев)
> >        add_header Strict-Transport-Security max-age=15768000;
> >
> >        resolver 8.8.8.8 8.8.4.4 valid=300s;
> >
> >       # server_name _;
> >
> >       location / {
> >                # Параметры проксирования
> >        proxy_send_timeout 600;
> >        proxy_read_timeout 600;
> >        proxy_buffer_size   128k;
> >        proxy_buffers   4 256k;
> >        proxy_busy_buffers_size   256k;
> >        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-Proto $scheme;
> >        proxy_set_header HTTPS YES;
> >        # IP-адрес целевой площадки для проксирования
> >        proxy_pass http://192.168.1.108;
> >        }
> >
> >        # pass the PHP scripts to FastCGI server listening on
> > 127.0.0.1:9000
> >        #
> >        #location ~ \.php$ {
> >        # include snippets/fastcgi-php.conf;
> >        #
> >        #       # With php7.0-cgi alone:
> >        #       fastcgi_pass 127.0.0.1:9000;
> >        #       # With php7.0-fpm:
> >        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
> >        #}
> >
> >        # deny access to .htaccess files, if Apache's document root
> >        # concurs with nginx's one
> >        #
> >        #location ~ /\.ht {
> >        #       deny all;
> >        #}
> > }
> >
> > Далее делаю «копию» в папку sites-enabled
> > sudo ln -s /etc/nginx/sites-available/default.conf
> > /etc/nginx/sites-enabled/
> >
> > Проверяю синтаксис
> > sudo nginx -t
> > (на что получаю положительный ответ)
> > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> > nginx: configuration file /etc/nginx/nginx.conf test is successful
> >
> > И последовательно делаю перезапуск Nginx
> > sudo service nginx restart
> > sudo systemctl restart nginx
> >
> > В итоге, набирая IP и порт и пытаясь подключиться по HTTPS, в Google
> Chrome
> > вижу ошибку ERR_CONNECTION_CLOSED. В чем может быть проблема?
> >
> > Posted at Nginx Forum: 
> > https://forum.nginx.org/read.php?21,289759,289759#msg-289759
> >
> > _______________________________________________
> > 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

Нет, не добавлял
Не делал этого по причине того, что из всех прочтенных мною статей этим
никто не занимался
Тем более мне кажется, что не в браузере дело (IE, Chrome, Yandex)
До проверки сертификата дело даже не доходит, то есть нет всплывающего окна
о том, что сертификат не проверен (если сертификат работает, то такое окошко
появляется и либо ты переходишь дальне на сайт, либо нет). В моем же случае
при переходе по https соединение с сервером обрывается, но при переходе по
http все работает корректно

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289761#msg-289761


From chipitsine на gmail.com  Tue Oct 20 07:13:39 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 20 Oct 2020 12:13:39 +0500
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <ec7a84992b5521c4d40524e9ce4def1b.NginxMailingListRussian@forum.nginx.org>
References: <17544c7acd0.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>
 <ec7a84992b5521c4d40524e9ce4def1b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGGgnMTz7ePN+x-0HrB7gYQrHodjK4JW=zVD+EEjBDPeQ@mail.gmail.com>

а что-то банальное типа telnet на 443 порт ? curl, wget ?

вт, 20 окт. 2020 г. в 12:06, Zalman_ <nginx-forum на forum.nginx.org>:

> imsystem Wrote:
> -------------------------------------------------------
> > Клиент, в роли браузера, должен знать о вашем центре сертификации. Вы
> > добавляли его сертификат в браузер?
> >
> > "Zalman_" <nginx-forum на forum.nginx.org> 20 октября 2020 г. 08:07:44
> > написал:
> >
> > > Доброго времени суток!
> > >
> > > Нужна помощь по вопросу SSL шифрования.
> > >
> > > Объясню, что есть и что уже имеется.
> > >
> > > Основная задача – поднять RocketChat на локальном сервере и
> > обеспечить
> > > шифрование при доступе к локальному серверу из вне.
> > >
> > > Для этих целей использовал Ubuntu 18.04 LTS на виртуалке на сервере.
> > В
> > > качестве веб-сервера использовал Nginx - 1.14.0 (Ubuntu), а в
> > качестве СУБД
> > > использую MongoDB - db version v4.0.20. Использование Nginx и
> > MongoDB
> > > описано в мануале по установке RocketChat.
> > > Все это удалось сделать и все хорошо работает. То есть Nginx +
> > MongoDB +
> > > RocketChat хорошо работают как в локальной сети, так и из вне (с
> > помощью
> > > проброса портов). Однако не удается подключить SSL – сертификат. Так
> > как
> > > сервер поднимался локально (доступ из вне и локально осуществляется
> > через
> > > IP-адрес сервера и порт) и отсутствует какой-то домен, то получение
> > > SSL-сертификата от Let’S Encrypt является проблематичным, поэтому
> > выбрал
> > > самоподписанный SSL-сертификат на основе OpenSSL.
> > > Приватный ключ, сертификат, а также ключ Диффи-Хеллмана сделал.
> > Конфиги
> > > nginx.conf, а также конфиг в папке
> > > /etc/nginx/sites-available/rocketchat.conf настроил, однако по
> > каким-то
> > > причинам доступ к чату есть через HTTP, но нет через HTTPS.
> > >
> > > С этой темой сижу уже достаточно долго. Пробовал много способов и
> > много
> > > различных конфигов, но все равно не работает.
> > > Причем пробовал как с отключенным UFW, так и с включенным (разрешал
> > > подключение по портам 80, 443, *нужный мне порт*). Также в iptables
> > тоже
> > > разрешил 3 предыдущих порта, но эффекта ноль.
> > >
> > > А вот тут я приведу конфиги.
> > > /etc/nginx/nginx.conf
> > > user www-data;
> > > worker_processes auto;
> > > pid /run/nginx.pid;
> > > include /etc/nginx/modules-enabled/*.conf;
> > >
> > > events {
> > >        worker_connections 768;
> > >        # multi_accept on;
> > > }
> > >
> > > http {
> > >        ##
> > >        # Basic Settings
> > >        ##
> > >        #sendfile on;
> > >        tcp_nopush on;
> > >        tcp_nodelay on;
> > >        keepalive_timeout 65;
> > >        types_hash_max_size 2048;
> > >        # server_tokens off;
> > >
> > >        # server_names_hash_bucket_size 64;
> > >        # server_name_in_redirect off;
> > >
> > >        include /etc/nginx/mime.types;
> > >        default_type application/octet-stream;
> > >
> > >        ##
> > >        # SSL Settings
> > >        ##
> > >        ##
> > >        # Logging Settings
> > >        ##
> > >
> > >        access_log /var/log/nginx/access.log;
> > >        error_log /var/log/nginx/error.log;
> > >
> > >        ##
> > >        # Gzip Settings
> > >        ##
> > >
> > >        gzip on;
> > >
> > >        # gzip_vary on;
> > >        # gzip_proxied any;
> > >        # gzip_comp_level 6;
> > >        # gzip_buffers 16 8k;
> > >        # gzip_http_version 1.1;
> > >        # gzip_types text/plain text/css application/json
> > > application/javascript text/xml application/xml applicatio$
> > >
> > >        ##
> > >        # Virtual Host Configs
> > >        ##
> > >
> > >        include /etc/nginx/conf.d/*.conf;
> > >        include /etc/nginx/sites-enabled/*.conf;
> > > }
> > >
> > > #mail {
> > > #       # See sample authentication script at:
> > > #       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
> > > #
> > > #       # auth_http localhost/auth.php;
> > > #       # pop3_capabilities "TOP" "USER";
> > > #       # imap_capabilities "IMAP4rev1" "UIDPLUS";
> > > #
> > > #       server {
> > > #               listen     localhost:110;
> > > #               protocol   pop3;
> > > #               proxy      on;
> > > #       }
> > > #
> > > #       server {
> > > #               listen     localhost:143;
> > > #               protocol   imap;
> > > #               proxy      on;
> > > #       }
> > > #}
> > >
> > > /etc/nginx/sites-available/default.conf
> > >
> > > upstream backend {
> > >   server 127.0.0.1;
> > > }
> > >
> > > #HTTP
> > > server {
> > >        #Делаю конфиг согласно
> > > https://techlist.top/translation-nginx-to-https/
> > >        listen 80;
> > >        server_name *IP локального сервера*;
> > >        return 301 https://$server_name$request_uri;
> > > }
> > >
> > > #HTTPS
> > > server {
> > >        #Порт, который будет слушать Nginx для SSL
> > >        listen 443 ssl http2;
> > >
> > >        #Имя сайта
> > >        server_name *IP локального сервера*;
> > >
> > >        #Корневая директория и индексный файл (ничего не менял)
> > >        root /var/www/html;
> > >        index index.html index.htm index.nginx-debian.html;
> > >
> > >        #Лог-файлы
> > >        access_log  /var/www/html/access_https.log;
> > >        error_log   /var/www/html/error_https.log;
> > >
> > >        #SSL-секция
> > >
> > >        #Сертификат и ключ
> > >        ssl_certificate /etc/ssl/certs/rccrt.crt;
> > >        ssl_certificate_key /etc/ssl/private/rckey.key;
> > >
> > >        #SSL-сессия
> > >        ssl_session_timeout 1d;
> > >        ssl_session_cache shared:SSL:50m;
> > >        ssl_session_tickets off;
> > >
> > >        #Diffie-Hellman ключ для DHE-шифров
> > >        ssl_dhparam /etc/ssl/certs/dhparam.pem;
> > >
> > >        #Используемые протоколы
> > >        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
> > >
> > >        #Наборы шифров
> > >        ssl_ciphers '*набор шифров*';
> > >
> > >        #Приоритет серверных шифров
> > >        ssl_prefer_server_ciphers on;
> > >
> > >        #Включение HSTS (Strict-Transport-Security)(15768000 seconds
> > = 6
> > > месяцев)
> > >        add_header Strict-Transport-Security max-age=15768000;
> > >
> > >        resolver 8.8.8.8 8.8.4.4 valid=300s;
> > >
> > >       # server_name _;
> > >
> > >       location / {
> > >                # Параметры проксирования
> > >        proxy_send_timeout 600;
> > >        proxy_read_timeout 600;
> > >        proxy_buffer_size   128k;
> > >        proxy_buffers   4 256k;
> > >        proxy_busy_buffers_size   256k;
> > >        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-Proto $scheme;
> > >        proxy_set_header HTTPS YES;
> > >        # IP-адрес целевой площадки для проксирования
> > >        proxy_pass http://192.168.1.108;
> > >        }
> > >
> > >        # pass the PHP scripts to FastCGI server listening on
> > > 127.0.0.1:9000
> > >        #
> > >        #location ~ \.php$ {
> > >        # include snippets/fastcgi-php.conf;
> > >        #
> > >        #       # With php7.0-cgi alone:
> > >        #       fastcgi_pass 127.0.0.1:9000;
> > >        #       # With php7.0-fpm:
> > >        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
> > >        #}
> > >
> > >        # deny access to .htaccess files, if Apache's document root
> > >        # concurs with nginx's one
> > >        #
> > >        #location ~ /\.ht {
> > >        #       deny all;
> > >        #}
> > > }
> > >
> > > Далее делаю «копию» в папку sites-enabled
> > > sudo ln -s /etc/nginx/sites-available/default.conf
> > > /etc/nginx/sites-enabled/
> > >
> > > Проверяю синтаксис
> > > sudo nginx -t
> > > (на что получаю положительный ответ)
> > > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> > > nginx: configuration file /etc/nginx/nginx.conf test is successful
> > >
> > > И последовательно делаю перезапуск Nginx
> > > sudo service nginx restart
> > > sudo systemctl restart nginx
> > >
> > > В итоге, набирая IP и порт и пытаясь подключиться по HTTPS, в Google
> > Chrome
> > > вижу ошибку ERR_CONNECTION_CLOSED. В чем может быть проблема?
> > >
> > > Posted at Nginx Forum:
> > > https://forum.nginx.org/read.php?21,289759,289759#msg-289759
> > >
> > > _______________________________________________
> > > 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
>
> Нет, не добавлял
> Не делал этого по причине того, что из всех прочтенных мною статей этим
> никто не занимался
> Тем более мне кажется, что не в браузере дело (IE, Chrome, Yandex)
> До проверки сертификата дело даже не доходит, то есть нет всплывающего окна
> о том, что сертификат не проверен (если сертификат работает, то такое
> окошко
> появляется и либо ты переходишь дальне на сайт, либо нет). В моем же случае
> при переходе по https соединение с сервером обрывается, но при переходе по
> http все работает корректно
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,289759,289761#msg-289761
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201020/5af19346/attachment-0001.htm>

From root на dl.sm.ua  Tue Oct 20 07:17:52 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Tue, 20 Oct 2020 10:17:52 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <ec7a84992b5521c4d40524e9ce4def1b.NginxMailingListRussian@forum.nginx.org>
References: <17544c7acd0.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>
 <ec7a84992b5521c4d40524e9ce4def1b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>

Фаервол... Как правильно заметили - проверить телнетом банальным.


---- Увімкнуто вт, 20 жовт. 2020 10:06:29 +0300 Zalman_ <nginx-forum на forum.nginx.org> написав ----


imsystem Wrote:
-------------------------------------------------------
> Клиент, в роли браузера, должен знать о вашем центре сертификации. Вы 
> добавляли его сертификат в браузер?
> 
> "Zalman_" <mailto:nginx-forum на forum.nginx.org> 20 октября 2020 г. 08:07:44
> написал:
> 
> > Доброго времени суток!
> >
> > Нужна помощь по вопросу SSL шифрования.
> >
> > Объясню, что есть и что уже имеется.
> >
> > Основная задача – поднять RocketChat на локальном сервере и
> обеспечить
> > шифрование при доступе к локальному серверу из вне.
> >
> > Для этих целей использовал Ubuntu 18.04 LTS на виртуалке на сервере.
> В
> > качестве веб-сервера использовал Nginx - 1.14.0 (Ubuntu), а в
> качестве СУБД
> > использую MongoDB - db version v4.0.20. Использование Nginx и
> MongoDB
> > описано в мануале по установке RocketChat.
> > Все это удалось сделать и все хорошо работает. То есть Nginx +
> MongoDB +
> > RocketChat хорошо работают как в локальной сети, так и из вне (с
> помощью
> > проброса портов). Однако не удается подключить SSL – сертификат. Так
> как
> > сервер поднимался локально (доступ из вне и локально осуществляется
> через
> > IP-адрес сервера и порт) и отсутствует какой-то домен, то получение
> > SSL-сертификата от Let’S Encrypt является проблематичным, поэтому
> выбрал
> > самоподписанный SSL-сертификат на основе OpenSSL.
> > Приватный ключ, сертификат, а также ключ Диффи-Хеллмана сделал.
> Конфиги
> > nginx.conf, а также конфиг в папке
> > /etc/nginx/sites-available/rocketchat.conf настроил, однако по
> каким-то
> > причинам доступ к чату есть через HTTP, но нет через HTTPS.
> >
> > С этой темой сижу уже достаточно долго. Пробовал много способов и
> много
> > различных конфигов, но все равно не работает.
> > Причем пробовал как с отключенным UFW, так и с включенным (разрешал
> > подключение по портам 80, 443, *нужный мне порт*). Также в iptables
> тоже
> > разрешил 3 предыдущих порта, но эффекта ноль.
> >
> > А вот тут я приведу конфиги.
> > /etc/nginx/nginx.conf
> > user www-data;
> > worker_processes auto;
> > pid /run/nginx.pid;
> > include /etc/nginx/modules-enabled/*.conf;
> >
> > events {
> >        worker_connections 768;
> >        # multi_accept on;
> > }
> >
> > http {
> >        ##
> >        # Basic Settings
> >        ##
> >        #sendfile on;
> >        tcp_nopush on;
> >        tcp_nodelay on;
> >        keepalive_timeout 65;
> >        types_hash_max_size 2048;
> >        # server_tokens off;
> >
> >        # server_names_hash_bucket_size 64;
> >        # server_name_in_redirect off;
> >
> >        include /etc/nginx/mime.types;
> >        default_type application/octet-stream;
> >
> >        ##
> >        # SSL Settings
> >        ##
> >        ##
> >        # Logging Settings
> >        ##
> >
> >        access_log /var/log/nginx/access.log;
> >        error_log /var/log/nginx/error.log;
> >
> >        ##
> >        # Gzip Settings
> >        ##
> >
> >        gzip on;
> >
> >        # gzip_vary on;
> >        # gzip_proxied any;
> >        # gzip_comp_level 6;
> >        # gzip_buffers 16 8k;
> >        # gzip_http_version 1.1;
> >        # gzip_types text/plain text/css application/json
> > application/javascript text/xml application/xml applicatio$
> >
> >        ##
> >        # Virtual Host Configs
> >        ##
> >
> >        include /etc/nginx/conf.d/*.conf;
> >        include /etc/nginx/sites-enabled/*.conf;
> > }
> >
> > #mail {
> > #       # See sample authentication script at:
> > #       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
> > #
> > #       # auth_http localhost/auth.php;
> > #       # pop3_capabilities "TOP" "USER";
> > #       # imap_capabilities "IMAP4rev1" "UIDPLUS";
> > #
> > #       server {
> > #               listen     localhost:110;
> > #               protocol   pop3;
> > #               proxy      on;
> > #       }
> > #
> > #       server {
> > #               listen     localhost:143;
> > #               protocol   imap;
> > #               proxy      on;
> > #       }
> > #}
> >
> > /etc/nginx/sites-available/default.conf
> >
> > upstream backend {
> >   server 127.0.0.1;
> > }
> >
> > #HTTP
> > server {
> >        #Делаю конфиг согласно
> > https://techlist.top/translation-nginx-to-https/
> >        listen 80;
> >        server_name *IP локального сервера*;
> >        return 301 https://$server_name$request_uri;
> > }
> >
> > #HTTPS
> > server {
> >        #Порт, который будет слушать Nginx для SSL
> >        listen 443 ssl http2;
> >
> >        #Имя сайта
> >        server_name *IP локального сервера*;
> >
> >        #Корневая директория и индексный файл (ничего не менял)
> >        root /var/www/html;
> >        index index.html index.htm index.nginx-debian.html;
> >
> >        #Лог-файлы
> >        access_log  /var/www/html/access_https.log;
> >        error_log   /var/www/html/error_https.log;
> >
> >        #SSL-секция
> >
> >        #Сертификат и ключ
> >        ssl_certificate /etc/ssl/certs/rccrt.crt;
> >        ssl_certificate_key /etc/ssl/private/rckey.key;
> >
> >        #SSL-сессия
> >        ssl_session_timeout 1d;
> >        ssl_session_cache shared:SSL:50m;
> >        ssl_session_tickets off;
> >
> >        #Diffie-Hellman ключ для DHE-шифров
> >        ssl_dhparam /etc/ssl/certs/dhparam.pem;
> >
> >        #Используемые протоколы
> >        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
> >
> >        #Наборы шифров
> >        ssl_ciphers '*набор шифров*';
> >
> >        #Приоритет серверных шифров
> >        ssl_prefer_server_ciphers on;
> >
> >        #Включение HSTS (Strict-Transport-Security)(15768000 seconds
> = 6
> > месяцев)
> >        add_header Strict-Transport-Security max-age=15768000;
> >
> >        resolver 8.8.8.8 8.8.4.4 valid=300s;
> >
> >       # server_name _;
> >
> >       location / {
> >                # Параметры проксирования
> >        proxy_send_timeout 600;
> >        proxy_read_timeout 600;
> >        proxy_buffer_size   128k;
> >        proxy_buffers   4 256k;
> >        proxy_busy_buffers_size   256k;
> >        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-Proto $scheme;
> >        proxy_set_header HTTPS YES;
> >        # IP-адрес целевой площадки для проксирования
> >        proxy_pass http://192.168.1.108;
> >        }
> >
> >        # pass the PHP scripts to FastCGI server listening on
> > 127.0.0.1:9000
> >        #
> >        #location ~ \.php$ {
> >        # include snippets/fastcgi-php.conf;
> >        #
> >        #       # With php7.0-cgi alone:
> >        #       fastcgi_pass 127.0.0.1:9000;
> >        #       # With php7.0-fpm:
> >        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
> >        #}
> >
> >        # deny access to .htaccess files, if Apache's document root
> >        # concurs with nginx's one
> >        #
> >        #location ~ /\.ht {
> >        #       deny all;
> >        #}
> > }
> >
> > Далее делаю «копию» в папку sites-enabled
> > sudo ln -s /etc/nginx/sites-available/default.conf
> > /etc/nginx/sites-enabled/
> >
> > Проверяю синтаксис
> > sudo nginx -t
> > (на что получаю положительный ответ)
> > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> > nginx: configuration file /etc/nginx/nginx.conf test is successful
> >
> > И последовательно делаю перезапуск Nginx
> > sudo service nginx restart
> > sudo systemctl restart nginx
> >
> > В итоге, набирая IP и порт и пытаясь подключиться по HTTPS, в Google
> Chrome
> > вижу ошибку ERR_CONNECTION_CLOSED. В чем может быть проблема?
> >
> > Posted at Nginx Forum: 
> > https://forum.nginx.org/read.php?21,289759,289759#msg-289759
> >
> > _______________________________________________
> > nginx-ru mailing list
> > mailto:nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> _______________________________________________
> nginx-ru mailing list
> mailto:nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Нет, не добавлял
Не делал этого по причине того, что из всех прочтенных мною статей этим
никто не занимался
Тем более мне кажется, что не в браузере дело (IE, Chrome, Yandex)
До проверки сертификата дело даже не доходит, то есть нет всплывающего окна
о том, что сертификат не проверен (если сертификат работает, то такое окошко
появляется и либо ты переходишь дальне на сайт, либо нет). В моем же случае
при переходе по https соединение с сервером обрывается, но при переходе по
http все работает корректно

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289761#msg-289761

_______________________________________________
nginx-ru mailing list
mailto:nginx-ru на nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201020/22efeaca/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Tue Oct 20 07:36:37 2020
From: nginx-forum на forum.nginx.org (Zalman_)
Date: Tue, 20 Oct 2020 03:36:37 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <CAFHpkQGGgnMTz7ePN+x-0HrB7gYQrHodjK4JW=zVD+EEjBDPeQ@mail.gmail.com>
References: <CAFHpkQGGgnMTz7ePN+x-0HrB7gYQrHodjK4JW=zVD+EEjBDPeQ@mail.gmail.com>
Message-ID: <72b2c4cad31665e9cdc3c06ab21a27b6.NginxMailingListRussian@forum.nginx.org>

Илья Шипицин Wrote:
-------------------------------------------------------
> а что-то банальное типа telnet на 443 порт ? curl, wget ?
> 
> вт, 20 окт. 2020 г. в 12:06, Zalman_ <nginx-forum на forum.nginx.org>:
> 
> > imsystem Wrote:
> > -------------------------------------------------------
> > > Клиент, в роли браузера, должен знать о вашем центре сертификации.
> Вы
> > > добавляли его сертификат в браузер?
> > >
> > > "Zalman_" <nginx-forum на forum.nginx.org> 20 октября 2020 г.
> 08:07:44
> > > написал:
> > >
> > > > Доброго времени суток!
> > > >
> > > > Нужна помощь по вопросу SSL шифрования.
> > > >
> > > > Объясню, что есть и что уже имеется.
> > > >
> > > > Основная задача – поднять RocketChat на локальном сервере и
> > > обеспечить
> > > > шифрование при доступе к локальному серверу из вне.
> > > >
> > > > Для этих целей использовал Ubuntu 18.04 LTS на виртуалке на
> сервере.
> > > В
> > > > качестве веб-сервера использовал Nginx - 1.14.0 (Ubuntu), а в
> > > качестве СУБД
> > > > использую MongoDB - db version v4.0.20. Использование Nginx и
> > > MongoDB
> > > > описано в мануале по установке RocketChat.
> > > > Все это удалось сделать и все хорошо работает. То есть Nginx +
> > > MongoDB +
> > > > RocketChat хорошо работают как в локальной сети, так и из вне
> (с
> > > помощью
> > > > проброса портов). Однако не удается подключить SSL – сертификат.
> Так
> > > как
> > > > сервер поднимался локально (доступ из вне и локально
> осуществляется
> > > через
> > > > IP-адрес сервера и порт) и отсутствует какой-то домен, то
> получение
> > > > SSL-сертификата от Let’S Encrypt является проблематичным,
> поэтому
> > > выбрал
> > > > самоподписанный SSL-сертификат на основе OpenSSL.
> > > > Приватный ключ, сертификат, а также ключ Диффи-Хеллмана сделал.
> > > Конфиги
> > > > nginx.conf, а также конфиг в папке
> > > > /etc/nginx/sites-available/rocketchat.conf настроил, однако по
> > > каким-то
> > > > причинам доступ к чату есть через HTTP, но нет через HTTPS.
> > > >
> > > > С этой темой сижу уже достаточно долго. Пробовал много способов
> и
> > > много
> > > > различных конфигов, но все равно не работает.
> > > > Причем пробовал как с отключенным UFW, так и с включенным
> (разрешал
> > > > подключение по портам 80, 443, *нужный мне порт*). Также в
> iptables
> > > тоже
> > > > разрешил 3 предыдущих порта, но эффекта ноль.
> > > >
> > > > А вот тут я приведу конфиги.
> > > > /etc/nginx/nginx.conf
> > > > user www-data;
> > > > worker_processes auto;
> > > > pid /run/nginx.pid;
> > > > include /etc/nginx/modules-enabled/*.conf;
> > > >
> > > > events {
> > > >        worker_connections 768;
> > > >        # multi_accept on;
> > > > }
> > > >
> > > > http {
> > > >        ##
> > > >        # Basic Settings
> > > >        ##
> > > >        #sendfile on;
> > > >        tcp_nopush on;
> > > >        tcp_nodelay on;
> > > >        keepalive_timeout 65;
> > > >        types_hash_max_size 2048;
> > > >        # server_tokens off;
> > > >
> > > >        # server_names_hash_bucket_size 64;
> > > >        # server_name_in_redirect off;
> > > >
> > > >        include /etc/nginx/mime.types;
> > > >        default_type application/octet-stream;
> > > >
> > > >        ##
> > > >        # SSL Settings
> > > >        ##
> > > >        ##
> > > >        # Logging Settings
> > > >        ##
> > > >
> > > >        access_log /var/log/nginx/access.log;
> > > >        error_log /var/log/nginx/error.log;
> > > >
> > > >        ##
> > > >        # Gzip Settings
> > > >        ##
> > > >
> > > >        gzip on;
> > > >
> > > >        # gzip_vary on;
> > > >        # gzip_proxied any;
> > > >        # gzip_comp_level 6;
> > > >        # gzip_buffers 16 8k;
> > > >        # gzip_http_version 1.1;
> > > >        # gzip_types text/plain text/css application/json
> > > > application/javascript text/xml application/xml applicatio$
> > > >
> > > >        ##
> > > >        # Virtual Host Configs
> > > >        ##
> > > >
> > > >        include /etc/nginx/conf.d/*.conf;
> > > >        include /etc/nginx/sites-enabled/*.conf;
> > > > }
> > > >
> > > > #mail {
> > > > #       # See sample authentication script at:
> > > > #       #
> http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
> > > > #
> > > > #       # auth_http localhost/auth.php;
> > > > #       # pop3_capabilities "TOP" "USER";
> > > > #       # imap_capabilities "IMAP4rev1" "UIDPLUS";
> > > > #
> > > > #       server {
> > > > #               listen     localhost:110;
> > > > #               protocol   pop3;
> > > > #               proxy      on;
> > > > #       }
> > > > #
> > > > #       server {
> > > > #               listen     localhost:143;
> > > > #               protocol   imap;
> > > > #               proxy      on;
> > > > #       }
> > > > #}
> > > >
> > > > /etc/nginx/sites-available/default.conf
> > > >
> > > > upstream backend {
> > > >   server 127.0.0.1;
> > > > }
> > > >
> > > > #HTTP
> > > > server {
> > > >        #Делаю конфиг согласно
> > > > https://techlist.top/translation-nginx-to-https/
> > > >        listen 80;
> > > >        server_name *IP локального сервера*;
> > > >        return 301 https://$server_name$request_uri;
> > > > }
> > > >
> > > > #HTTPS
> > > > server {
> > > >        #Порт, который будет слушать Nginx для SSL
> > > >        listen 443 ssl http2;
> > > >
> > > >        #Имя сайта
> > > >        server_name *IP локального сервера*;
> > > >
> > > >        #Корневая директория и индексный файл (ничего не менял)
> > > >        root /var/www/html;
> > > >        index index.html index.htm index.nginx-debian.html;
> > > >
> > > >        #Лог-файлы
> > > >        access_log  /var/www/html/access_https.log;
> > > >        error_log   /var/www/html/error_https.log;
> > > >
> > > >        #SSL-секция
> > > >
> > > >        #Сертификат и ключ
> > > >        ssl_certificate /etc/ssl/certs/rccrt.crt;
> > > >        ssl_certificate_key /etc/ssl/private/rckey.key;
> > > >
> > > >        #SSL-сессия
> > > >        ssl_session_timeout 1d;
> > > >        ssl_session_cache shared:SSL:50m;
> > > >        ssl_session_tickets off;
> > > >
> > > >        #Diffie-Hellman ключ для DHE-шифров
> > > >        ssl_dhparam /etc/ssl/certs/dhparam.pem;
> > > >
> > > >        #Используемые протоколы
> > > >        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
> > > >
> > > >        #Наборы шифров
> > > >        ssl_ciphers '*набор шифров*';
> > > >
> > > >        #Приоритет серверных шифров
> > > >        ssl_prefer_server_ciphers on;
> > > >
> > > >        #Включение HSTS (Strict-Transport-Security)(15768000
> seconds
> > > = 6
> > > > месяцев)
> > > >        add_header Strict-Transport-Security max-age=15768000;
> > > >
> > > >        resolver 8.8.8.8 8.8.4.4 valid=300s;
> > > >
> > > >       # server_name _;
> > > >
> > > >       location / {
> > > >                # Параметры проксирования
> > > >        proxy_send_timeout 600;
> > > >        proxy_read_timeout 600;
> > > >        proxy_buffer_size   128k;
> > > >        proxy_buffers   4 256k;
> > > >        proxy_busy_buffers_size   256k;
> > > >        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-Proto $scheme;
> > > >        proxy_set_header HTTPS YES;
> > > >        # IP-адрес целевой площадки для проксирования
> > > >        proxy_pass http://192.168.1.108;
> > > >        }
> > > >
> > > >        # pass the PHP scripts to FastCGI server listening on
> > > > 127.0.0.1:9000
> > > >        #
> > > >        #location ~ \.php$ {
> > > >        # include snippets/fastcgi-php.conf;
> > > >        #
> > > >        #       # With php7.0-cgi alone:
> > > >        #       fastcgi_pass 127.0.0.1:9000;
> > > >        #       # With php7.0-fpm:
> > > >        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
> > > >        #}
> > > >
> > > >        # deny access to .htaccess files, if Apache's document
> root
> > > >        # concurs with nginx's one
> > > >        #
> > > >        #location ~ /\.ht {
> > > >        #       deny all;
> > > >        #}
> > > > }
> > > >
> > > > Далее делаю «копию» в папку sites-enabled
> > > > sudo ln -s /etc/nginx/sites-available/default.conf
> > > > /etc/nginx/sites-enabled/
> > > >
> > > > Проверяю синтаксис
> > > > sudo nginx -t
> > > > (на что получаю положительный ответ)
> > > > nginx: the configuration file /etc/nginx/nginx.conf syntax is
> ok
> > > > nginx: configuration file /etc/nginx/nginx.conf test is
> successful
> > > >
> > > > И последовательно делаю перезапуск Nginx
> > > > sudo service nginx restart
> > > > sudo systemctl restart nginx
> > > >
> > > > В итоге, набирая IP и порт и пытаясь подключиться по HTTPS, в
> Google
> > > Chrome
> > > > вижу ошибку ERR_CONNECTION_CLOSED. В чем может быть проблема?
> > > >
> > > > Posted at Nginx Forum:
> > > > https://forum.nginx.org/read.php?21,289759,289759#msg-289759
> > > >
> > > > _______________________________________________
> > > > 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
> >
> > Нет, не добавлял
> > Не делал этого по причине того, что из всех прочтенных мною статей
> этим
> > никто не занимался
> > Тем более мне кажется, что не в браузере дело (IE, Chrome, Yandex)
> > До проверки сертификата дело даже не доходит, то есть нет
> всплывающего окна
> > о том, что сертификат не проверен (если сертификат работает, то
> такое
> > окошко
> > появляется и либо ты переходишь дальне на сайт, либо нет). В моем же
> случае
> > при переходе по https соединение с сервером обрывается, но при
> переходе по
> > http все работает корректно
> >
> > Posted at Nginx Forum:
> > https://forum.nginx.org/read.php?21,289759,289761#msg-289761
> >
> > _______________________________________________
> > 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


443 и 80 порт слушает nginx:master, то есть сервер их слушает, но результат
отрицательный

к слову на этих портах больше ничего не висит, только nginx

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289764#msg-289764


From nginx-forum на forum.nginx.org  Tue Oct 20 07:43:28 2020
From: nginx-forum на forum.nginx.org (Zalman_)
Date: Tue, 20 Oct 2020 03:43:28 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
References: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
Message-ID: <b7b3f6527d5f85629ffdb9918a0bc971.NginxMailingListRussian@forum.nginx.org>

Dmytro Lavryk Wrote:
-------------------------------------------------------
> Фаервол... Как правильно заметили - проверить телнетом банальным.
> 
> 
> ---- Увімкнуто вт, 20 жовт. 2020 10:06:29 +0300 Zalman_
> <nginx-forum на forum.nginx.org> написав ----

telnet *локальный IP* - unable to connect to remote host: connection
refused
telnet *белый IP по которому осуществляется доступ из вне* - unable to
connect to remote host: connection timed out

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289767#msg-289767


From root на dl.sm.ua  Tue Oct 20 07:45:21 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Tue, 20 Oct 2020 10:45:21 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <b7b3f6527d5f85629ffdb9918a0bc971.NginxMailingListRussian@forum.nginx.org>
References: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
 <b7b3f6527d5f85629ffdb9918a0bc971.NginxMailingListRussian@forum.nginx.org>
Message-ID: <17544f84082.ddebf15552535.1625669973577216024@dl.sm.ua>

netstat -an | grep 443

думаю ответ "пусто"
---- Увімкнуто вт, 20 жовт. 2020 10:43:28 +0300 Zalman_ <nginx-forum на forum.nginx.org> написав ----


Dmytro Lavryk Wrote:
-------------------------------------------------------
> Фаервол... Как правильно заметили - проверить телнетом банальным.
> 
> 
> ---- Увімкнуто вт, 20 жовт. 2020 10:06:29 +0300 Zalman_
> <mailto:nginx-forum на forum.nginx.org> написав ----

telnet *локальный IP* - unable to connect to remote host: connection
refused
telnet *белый IP по которому осуществляется доступ из вне* - unable to
connect to remote host: connection timed out

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289767#msg-289767

_______________________________________________
nginx-ru mailing list
mailto:nginx-ru на nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201020/64c6383e/attachment.htm>

From nginx-forum на forum.nginx.org  Tue Oct 20 07:50:00 2020
From: nginx-forum на forum.nginx.org (Zalman_)
Date: Tue, 20 Oct 2020 03:50:00 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <17544f84082.ddebf15552535.1625669973577216024@dl.sm.ua>
References: <17544f84082.ddebf15552535.1625669973577216024@dl.sm.ua>
Message-ID: <3d2071704d8a292bc350da47bfb32644.NginxMailingListRussian@forum.nginx.org>

Dmytro Lavryk Wrote:
-------------------------------------------------------
> netstat -an | grep 443
> 
> думаю ответ "пусто"
> ---- Увімкнуто вт, 20 жовт. 2020 10:43:28 +0300 Zalman_
> <nginx-forum на forum.nginx.org> написав ----

tcp 0      0         0.0.0.0:443         0.0.0.0:*       LISTEN

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289769#msg-289769


From root на dl.sm.ua  Tue Oct 20 07:53:22 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Tue, 20 Oct 2020 10:53:22 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <3d2071704d8a292bc350da47bfb32644.NginxMailingListRussian@forum.nginx.org>
References: <17544f84082.ddebf15552535.1625669973577216024@dl.sm.ua>
 <3d2071704d8a292bc350da47bfb32644.NginxMailingListRussian@forum.nginx.org>
Message-ID: <17544ff96f2.ff023bad53135.9193576562577524271@dl.sm.ua>

Получается nginx слушает, но кто-то режет соединение. Возможно таки фаервол, возможно еще-то-то. Не настолько силен в Бубунте, чтобы подсказать что может и как диагностировать :(


---- Увімкнуто вт, 20 жовт. 2020 10:50:00 +0300 Zalman_ <nginx-forum на forum.nginx.org> написав ----


Dmytro Lavryk Wrote:
-------------------------------------------------------
> netstat -an | grep 443
> 
> думаю ответ "пусто"
> ---- Увімкнуто вт, 20 жовт. 2020 10:43:28 +0300 Zalman_
> <mailto:nginx-forum на forum.nginx.org> написав ----

tcp 0      0         0.0.0.0:443         0.0.0.0:*       LISTEN

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289769#msg-289769

_______________________________________________
nginx-ru mailing list
mailto:nginx-ru на nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201020/8e3ef596/attachment.htm>

From nginx-forum на forum.nginx.org  Tue Oct 20 07:57:50 2020
From: nginx-forum на forum.nginx.org (Zalman_)
Date: Tue, 20 Oct 2020 03:57:50 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <17544ff96f2.ff023bad53135.9193576562577524271@dl.sm.ua>
References: <17544ff96f2.ff023bad53135.9193576562577524271@dl.sm.ua>
Message-ID: <38db2134ea2ca57e6db052d9992552fb.NginxMailingListRussian@forum.nginx.org>

Dmytro Lavryk Wrote:
-------------------------------------------------------
> Получается nginx слушает, но кто-то режет соединение. Возможно таки
> фаервол, возможно еще-то-то. Не настолько силен в Бубунте, чтобы
> подсказать что может и как диагностировать :(
> 
> 
> ---- Увімкнуто вт, 20 жовт. 2020 10:50:00 +0300 Zalman_
> <nginx-forum на forum.nginx.org> написав ----

Самое интересно в этой ситуации то, что я тоже думал, что фаервол 
Насколько понимаю вы говорите об UFW 
Моя проблема отражается как с включенным, так и с выключенным UFW
Сейчас он включен для него внесены правила на 80, 443, *нужный мне порт* 
Причем внесены как в локальной сети, так и для белого IP с которого будет
осуществляться доступ
Причем внесен как IP (любой порт) так и конкретно правила для 3
вышеописанных портов

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289771#msg-289771


From chipitsine на gmail.com  Tue Oct 20 08:55:48 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 20 Oct 2020 13:55:48 +0500
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <17544ff96f2.ff023bad53135.9193576562577524271@dl.sm.ua>
References: <17544f84082.ddebf15552535.1625669973577216024@dl.sm.ua>
 <3d2071704d8a292bc350da47bfb32644.NginxMailingListRussian@forum.nginx.org>
 <17544ff96f2.ff023bad53135.9193576562577524271@dl.sm.ua>
Message-ID: <CAFHpkQF4Nn9=knPN==QM-0M_ONrQzwe5p7deECB0+LHFfBKn=w@mail.gmail.com>

есть немного сбивающая с толку команда

iptables-save

выводит (и только) список правил фаирвола на любых линуксовых вариантах
netfilter-а

вт, 20 окт. 2020 г. в 12:53, Dmytro Lavryk <root на dl.sm.ua>:

> Получается nginx слушает, но кто-то режет соединение. Возможно таки
> фаервол, возможно еще-то-то. Не настолько силен в Бубунте, чтобы подсказать
> что может и как диагностировать :(
>
>
> ---- Увімкнуто вт, 20 жовт. 2020 10:50:00 +0300 *Zalman_
> <nginx-forum на forum.nginx.org <nginx-forum на forum.nginx.org>>* написав ----
>
> Dmytro Lavryk Wrote:
> -------------------------------------------------------
> > netstat -an | grep 443
> >
> > думаю ответ "пусто"
> > ---- Увімкнуто вт, 20 жовт. 2020 10:43:28 +0300 Zalman_
> > <nginx-forum на forum.nginx.org> написав ----
>
> tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,289759,289769#msg-289769
>
> _______________________________________________
> 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 было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201020/9f530eb3/attachment.htm>

From nginx-forum на forum.nginx.org  Tue Oct 20 09:14:35 2020
From: nginx-forum на forum.nginx.org (Zalman_)
Date: Tue, 20 Oct 2020 05:14:35 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
References: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
Message-ID: <b1d045d4f74b3627af82ee3784bbe3f9.NginxMailingListRussian@forum.nginx.org>

Dmytro Lavryk Wrote:
-------------------------------------------------------
> Фаервол... Как правильно заметили - проверить телнетом банальным.
> 
> 
> ---- Увімкнуто вт, 20 жовт. 2020 10:06:29 +0300 Zalman_
> <nginx-forum на forum.nginx.org> написав ----
> 
> 

При проверке через telnet

telnet *адрес локального IP, к которому есть доступ через HTTP* - unable to
connect to remote host: connection refused
telnet *белый IP через который идет подключение из вне* - unable to connect
to remote host: connection timed out

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289766#msg-289766


From nginx-forum на forum.nginx.org  Tue Oct 20 09:15:05 2020
From: nginx-forum на forum.nginx.org (Zalman_)
Date: Tue, 20 Oct 2020 05:15:05 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
References: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
Message-ID: <62ae9450d62a3d2fd590c08dd5de9230.NginxMailingListRussian@forum.nginx.org>

Dmytro Lavryk Wrote:
-------------------------------------------------------
> Фаервол... Как правильно заметили - проверить телнетом банальным.
> 
> 
> ---- Увімкнуто вт, 20 жовт. 2020 10:06:29 +0300 Zalman_
> <nginx-forum на forum.nginx.org> написав ----
> 
> 
> imsystem Wrote:
> -------------------------------------------------------
> > Клиент, в роли браузера, должен знать о вашем центре сертификации.
> Вы 
> > добавляли его сертификат в браузер?
> > 
> > "Zalman_" <mailto:nginx-forum на forum.nginx.org> 20 октября 2020 г.
> 08:07:44
> > написал:
> > 
> > > Доброго времени суток!
> > >
> > > Нужна помощь по вопросу SSL шифрования.
> > >
> > > Объясню, что есть и что уже имеется.
> > >
> > > Основная задача – поднять RocketChat на локальном сервере и
> > обеспечить
> > > шифрование при доступе к локальному серверу из вне.
> > >
> > > Для этих целей использовал Ubuntu 18.04 LTS на виртуалке на
> сервере.
> > В
> > > качестве веб-сервера использовал Nginx - 1.14.0 (Ubuntu), а в
> > качестве СУБД
> > > использую MongoDB - db version v4.0.20. Использование Nginx и
> > MongoDB
> > > описано в мануале по установке RocketChat.
> > > Все это удалось сделать и все хорошо работает. То есть Nginx +
> > MongoDB +
> > > RocketChat хорошо работают как в локальной сети, так и из вне (с
> > помощью
> > > проброса портов). Однако не удается подключить SSL – сертификат.
> Так
> > как
> > > сервер поднимался локально (доступ из вне и локально
> осуществляется
> > через
> > > IP-адрес сервера и порт) и отсутствует какой-то домен, то
> получение
> > > SSL-сертификата от Let’S Encrypt является проблематичным, поэтому
> > выбрал
> > > самоподписанный SSL-сертификат на основе OpenSSL.
> > > Приватный ключ, сертификат, а также ключ Диффи-Хеллмана сделал.
> > Конфиги
> > > nginx.conf, а также конфиг в папке
> > > /etc/nginx/sites-available/rocketchat.conf настроил, однако по
> > каким-то
> > > причинам доступ к чату есть через HTTP, но нет через HTTPS.
> > >
> > > С этой темой сижу уже достаточно долго. Пробовал много способов и
> > много
> > > различных конфигов, но все равно не работает.
> > > Причем пробовал как с отключенным UFW, так и с включенным
> (разрешал
> > > подключение по портам 80, 443, *нужный мне порт*). Также в
> iptables
> > тоже
> > > разрешил 3 предыдущих порта, но эффекта ноль.
> > >
> > > А вот тут я приведу конфиги.
> > > /etc/nginx/nginx.conf
> > > user www-data;
> > > worker_processes auto;
> > > pid /run/nginx.pid;
> > > include /etc/nginx/modules-enabled/*.conf;
> > >
> > > events {
> > >        worker_connections 768;
> > >        # multi_accept on;
> > > }
> > >
> > > http {
> > >        ##
> > >        # Basic Settings
> > >        ##
> > >        #sendfile on;
> > >        tcp_nopush on;
> > >        tcp_nodelay on;
> > >        keepalive_timeout 65;
> > >        types_hash_max_size 2048;
> > >        # server_tokens off;
> > >
> > >        # server_names_hash_bucket_size 64;
> > >        # server_name_in_redirect off;
> > >
> > >        include /etc/nginx/mime.types;
> > >        default_type application/octet-stream;
> > >
> > >        ##
> > >        # SSL Settings
> > >        ##
> > >        ##
> > >        # Logging Settings
> > >        ##
> > >
> > >        access_log /var/log/nginx/access.log;
> > >        error_log /var/log/nginx/error.log;
> > >
> > >        ##
> > >        # Gzip Settings
> > >        ##
> > >
> > >        gzip on;
> > >
> > >        # gzip_vary on;
> > >        # gzip_proxied any;
> > >        # gzip_comp_level 6;
> > >        # gzip_buffers 16 8k;
> > >        # gzip_http_version 1.1;
> > >        # gzip_types text/plain text/css application/json
> > > application/javascript text/xml application/xml applicatio$
> > >
> > >        ##
> > >        # Virtual Host Configs
> > >        ##
> > >
> > >        include /etc/nginx/conf.d/*.conf;
> > >        include /etc/nginx/sites-enabled/*.conf;
> > > }
> > >
> > > #mail {
> > > #       # See sample authentication script at:
> > > #       #
> http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
> > > #
> > > #       # auth_http localhost/auth.php;
> > > #       # pop3_capabilities "TOP" "USER";
> > > #       # imap_capabilities "IMAP4rev1" "UIDPLUS";
> > > #
> > > #       server {
> > > #               listen     localhost:110;
> > > #               protocol   pop3;
> > > #               proxy      on;
> > > #       }
> > > #
> > > #       server {
> > > #               listen     localhost:143;
> > > #               protocol   imap;
> > > #               proxy      on;
> > > #       }
> > > #}
> > >
> > > /etc/nginx/sites-available/default.conf
> > >
> > > upstream backend {
> > >   server 127.0.0.1;
> > > }
> > >
> > > #HTTP
> > > server {
> > >        #Делаю конфиг согласно
> > > https://techlist.top/translation-nginx-to-https/
> > >        listen 80;
> > >        server_name *IP локального сервера*;
> > >        return 301 https://$server_name$request_uri;
> > > }
> > >
> > > #HTTPS
> > > server {
> > >        #Порт, который будет слушать Nginx для SSL
> > >        listen 443 ssl http2;
> > >
> > >        #Имя сайта
> > >        server_name *IP локального сервера*;
> > >
> > >        #Корневая директория и индексный файл (ничего не менял)
> > >        root /var/www/html;
> > >        index index.html index.htm index.nginx-debian.html;
> > >
> > >        #Лог-файлы
> > >        access_log  /var/www/html/access_https.log;
> > >        error_log   /var/www/html/error_https.log;
> > >
> > >        #SSL-секция
> > >
> > >        #Сертификат и ключ
> > >        ssl_certificate /etc/ssl/certs/rccrt.crt;
> > >        ssl_certificate_key /etc/ssl/private/rckey.key;
> > >
> > >        #SSL-сессия
> > >        ssl_session_timeout 1d;
> > >        ssl_session_cache shared:SSL:50m;
> > >        ssl_session_tickets off;
> > >
> > >        #Diffie-Hellman ключ для DHE-шифров
> > >        ssl_dhparam /etc/ssl/certs/dhparam.pem;
> > >
> > >        #Используемые протоколы
> > >        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
> > >
> > >        #Наборы шифров
> > >        ssl_ciphers '*набор шифров*';
> > >
> > >        #Приоритет серверных шифров
> > >        ssl_prefer_server_ciphers on;
> > >
> > >        #Включение HSTS (Strict-Transport-Security)(15768000
> seconds
> > = 6
> > > месяцев)
> > >        add_header Strict-Transport-Security max-age=15768000;
> > >
> > >        resolver 8.8.8.8 8.8.4.4 valid=300s;
> > >
> > >       # server_name _;
> > >
> > >       location / {
> > >                # Параметры проксирования
> > >        proxy_send_timeout 600;
> > >        proxy_read_timeout 600;
> > >        proxy_buffer_size   128k;
> > >        proxy_buffers   4 256k;
> > >        proxy_busy_buffers_size   256k;
> > >        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-Proto $scheme;
> > >        proxy_set_header HTTPS YES;
> > >        # IP-адрес целевой площадки для проксирования
> > >        proxy_pass http://192.168.1.108;
> > >        }
> > >
> > >        # pass the PHP scripts to FastCGI server listening on
> > > 127.0.0.1:9000
> > >        #
> > >        #location ~ \.php$ {
> > >        # include snippets/fastcgi-php.conf;
> > >        #
> > >        #       # With php7.0-cgi alone:
> > >        #       fastcgi_pass 127.0.0.1:9000;
> > >        #       # With php7.0-fpm:
> > >        #       fastcgi_pass unix:/run/php/php7.0-fpm.sock;
> > >        #}
> > >
> > >        # deny access to .htaccess files, if Apache's document root
> > >        # concurs with nginx's one
> > >        #
> > >        #location ~ /\.ht {
> > >        #       deny all;
> > >        #}
> > > }
> > >
> > > Далее делаю «копию» в папку sites-enabled
> > > sudo ln -s /etc/nginx/sites-available/default.conf
> > > /etc/nginx/sites-enabled/
> > >
> > > Проверяю синтаксис
> > > sudo nginx -t
> > > (на что получаю положительный ответ)
> > > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> > > nginx: configuration file /etc/nginx/nginx.conf test is successful
> > >
> > > И последовательно делаю перезапуск Nginx
> > > sudo service nginx restart
> > > sudo systemctl restart nginx
> > >
> > > В итоге, набирая IP и порт и пытаясь подключиться по HTTPS, в
> Google
> > Chrome
> > > вижу ошибку ERR_CONNECTION_CLOSED. В чем может быть проблема?
> > >
> > > Posted at Nginx Forum: 
> > > https://forum.nginx.org/read.php?21,289759,289759#msg-289759
> > >
> > > _______________________________________________
> > > nginx-ru mailing list
> > > mailto:nginx-ru на nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > 
> > _______________________________________________
> > nginx-ru mailing list
> > mailto:nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> Нет, не добавлял
> Не делал этого по причине того, что из всех прочтенных мною статей
> этим
> никто не занимался
> Тем более мне кажется, что не в браузере дело (IE, Chrome, Yandex)
> До проверки сертификата дело даже не доходит, то есть нет всплывающего
> окна
> о том, что сертификат не проверен (если сертификат работает, то такое
> окошко
> появляется и либо ты переходишь дальне на сайт, либо нет). В моем же
> случае
> при переходе по https соединение с сервером обрывается, но при
> переходе по
> http все работает корректно
> 
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,289759,289761#msg-289761
> 
> _______________________________________________
> nginx-ru mailing list
> mailto: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


При проверке через telnet

telnet *адрес локального IP, к которому есть доступ через HTTP* - unable to
connect to remote host: connection refused
telnet *белый IP через который идет подключение из вне* - unable to connect
to remote host: connection timed out

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289759,289765#msg-289765


From bgx на protva.ru  Tue Oct 20 09:42:01 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 20 Oct 2020 12:42:01 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <62ae9450d62a3d2fd590c08dd5de9230.NginxMailingListRussian@forum.nginx.org>
References: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
 <62ae9450d62a3d2fd590c08dd5de9230.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20201020094201.GD2676@protva.ru>

On Tue, Oct 20, 2020 at 05:15:05AM -0400, Zalman_ wrote:
> При проверке через telnet
> 
> telnet *адрес локального IP, к которому есть доступ через HTTP* - unable to
> connect to remote host: connection refused

 Это противоречит выдаче netstat-а о том, что порт прослушивается.

> telnet *белый IP через который идет подключение из вне* - unable to connect
> to remote host: connection timed out

 Это противоречит сообщению Chrome о том, что соединение устанавливается,
 а затем закрывается сервером.

 Похоже, вопрос не имеет отношения к nginx, тут нужен обычный сисадмин
 для настройки сети.
-- 
 Eugene Berdnikov

From eugen на grosbein.net  Tue Oct 20 11:43:23 2020
From: eugen на grosbein.net (Eugene Grosbein)
Date: Tue, 20 Oct 2020 18:43:23 +0700
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRgNC10LTQuNGA0LXQutGCINC90LAg?=
 =?UTF-8?B?SFRUUFMuIE9wZW5TU0wu?=
In-Reply-To: <62ae9450d62a3d2fd590c08dd5de9230.NginxMailingListRussian@forum.nginx.org>
References: <17544df1797.101a7cefb50761.7273214887633975177@dl.sm.ua>
 <62ae9450d62a3d2fd590c08dd5de9230.NginxMailingListRussian@forum.nginx.org>
Message-ID: <a962c735-561b-d39c-182f-54f0f16c3d0b@grosbein.net>

20.10.2020 16:15, Zalman_ пишет:

> При проверке через telnet
> 
> telnet *адрес локального IP, к которому есть доступ через HTTP* - unable to
> connect to remote host: connection refused
> telnet *белый IP через который идет подключение из вне* - unable to connect
> to remote host: connection timed out

Несколько вариантов.

Может быть, на самом деле подключение идёт на другой хост, не на тот, что вы думаете.
Проверить это легко на том хосте, что вы думаете: запустить tcpdump -np port 443
и сделать попытку браузером. Если tcpdump ничего не показывает, то разбираться,
что проиcходит, например запустить tcpdump -np icmp и попинговать этот хост.
Если пинги проходят и tcpdump их показывает, значит трафик https фильтрует кто-то ещё,
например клиентский антивирус, вмешивающийся в трафик. Если же tcpdump не показывает
пакетов ICMP, хотя пинги проходят, либо если пинги вообще не проходят - опять же искать,
кто фильтрует трафик по трассе, можно простым tracert.exe с Windows или traceroute -P ICMP с линукса.

Если же tcpdump показывает пакеты по порту 443, значит, их фильтрует локальная система,
например, пакетный фильтр и ваше предположение о том, что он отключен или правильно настроен, неверно
и разбираться надо именно с фильтрацией.


From shilov на extmail.info  Fri Oct 23 22:41:40 2020
From: shilov на extmail.info (Shilov)
Date: Sat, 24 Oct 2020 01:41:40 +0300
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INC30LDRiNC40YTRgNC+0LI=?=
 =?UTF-8?B?0LDRgtGMINC60LDQvdCw0Lsg0YEg0L/QvtC80L7RidGM0Y4gTmdpbng=?=
In-Reply-To: <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
 <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
 <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>
 <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>
Message-ID: <20201024014140.140587346ee394e6483ace11@extmail.info>

On Sun, 30 Aug 2020 15:43:24 +0300
Dmytro Lavryk <root на dl.sm.ua> wrote:

> Чето неудачи с мэйл клиентом...
> 
> Конфиги привести не могу - лень чистить от конфиденциального, но основная идея в том, что proxy_pass прекрасно работает через https, в чем проблема то?

-- 
Shilov <shilov на extmail.info>

From mdounin на mdounin.ru  Tue Oct 27 15:26:21 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 27 Oct 2020 18:26:21 +0300
Subject: nginx-1.19.4
Message-ID: <20201027152621.GF50919@mdounin.ru>

Изменения в nginx 1.19.4                                          27.10.2020

    *) Добавление: директивы ssl_conf_command, proxy_ssl_conf_command,
       grpc_ssl_conf_command и uwsgi_ssl_conf_command.

    *) Добавление: директива ssl_reject_handshake.

    *) Добавление: директива proxy_smtp_auth в почтовом прокси-сервере.


-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Wed Oct 28 22:19:01 2020
From: nginx-forum на forum.nginx.org (fingolor)
Date: Wed, 28 Oct 2020 18:19:01 -0400
Subject: wordpress+postfixadmin conf
Message-ID: <60c7f49b05e453593f9b0a0b208360b8.NginxMailingListRussian@forum.nginx.org>

Собственно нужно чтоб postfixadmin был доступен по ссылке
wordpress.example.com/mailadmin
Если ввести wordpress.example.com/mailadmin/public/login.php то postfixadmin
доступен.
Можно как то в конфиге Nginx сделать алиас /mailadmin/public/login.php
просто на /mailadmin/?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289821,289821#msg-289821