From chipitsine на gmail.com Tue Jun 2 13:57:10 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 2 Jun 2020 18:57:10 +0500 Subject: =?UTF-8?B?NTAwLdC60LgsINC60L7RgtC+0YDRi9GFINC90LUg0L/QuNGI0LXRgtGB0Y8g0LIg?= =?UTF-8?B?ZXJyb3IubG9n?= Message-ID: привет, столкнулись с ситуацией, 500 пишется в access.log, при этом upstream_addr пустой, в error.log пусто. поиск по коду показывает несколько мест примерно вот таких (выделили память, она не выделилась, финализировали с 500-кой) http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_core_module.c#l1012 есть подозрение, что мы взорвались на каком-то таком palloc-е мониторинг не показывает, что на хосте не хватало памяти (но, возможно, у palloc-а были свои проблемы). в подобных местах, когда фейлится palloc, может стоит в error.log добавить ошибку ? или это по каким-то причинам невозможно ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jun 2 20:09:06 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 2 Jun 2020 23:09:06 +0300 Subject: =?UTF-8?B?UmU6IDUwMC3QutC4LCDQutC+0YLQvtGA0YvRhSDQvdC1INC/0LjRiNC10YLRgdGP?= =?UTF-8?B?INCyIGVycm9yLmxvZw==?= In-Reply-To: References: Message-ID: <20200602200906.GZ12747@mdounin.ru> Hello! On Tue, Jun 02, 2020 at 06:57:10PM +0500, Илья Шипицин wrote: > столкнулись с ситуацией, 500 пишется в access.log, при этом upstream_addr > пустой, в error.log пусто. > > поиск по коду показывает несколько мест примерно вот таких (выделили > память, она не выделилась, финализировали с 500-кой) > > http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_core_module.c#l1012 > > есть подозрение, что мы взорвались на каком-то таком palloc-е > мониторинг не показывает, что на хосте не хватало памяти (но, возможно, у > palloc-а были свои проблемы). > > в подобных местах, когда фейлится palloc, может стоит в error.log добавить > ошибку ? или это по каким-то причинам невозможно ? Все ошибки palloc'а - сводятся к невозможности получить память от системы, либо с помощью malloc(), либо с помощью posix_memalign() или memalign(). И это будет в error log'е на уровне emerg. Именно поэтому дополнительного логгирования в таких случаях не делается: оно не нужно, проблема уже залоггирована на максимально возможном уровне важности. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Jun 4 01:49:10 2020 From: nginx-forum на forum.nginx.org (yyyuuu) Date: Wed, 03 Jun 2020 21:49:10 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC0?= =?UTF-8?B?0YDRg9Cz0L7QuSDQsNC00YDQtdGB?= In-Reply-To: <6252477b6fda3249308649a438eb2cf0.NginxMailingListRussian@forum.nginx.org> References: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org> <08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org> <75a80bf654728bdf2cfde7dcc8c67f2b.NginxMailingListRussian@forum.nginx.org> <6252477b6fda3249308649a438eb2cf0.NginxMailingListRussian@forum.nginx.org> Message-ID: <70d711812d4b21f8dd7c546a31531942.NginxMailingListRussian@forum.nginx.org> Да Ты был прав, сработало. Но вот только одно не получилось. server { listen 80; server_name example.org; return 301 http://10.248.35.14:8092$request_uri; } Доступ к адресу есть только с одного компутера. При подключении к серверу 10.1.1.1 - он Меня переводить на http://10.248.35.14:8092 но доступа с компутера нету к этому адресу. Тут адрес не целиком должен заменить а выглядить что то вроде http://10.1.1.1/10.248.35.14:8092 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287854,288261#msg-288261 From red-fox0 на ya.ru Thu Jun 4 02:08:47 2020 From: red-fox0 на ya.ru (fox) Date: Thu, 4 Jun 2020 09:08:47 +0700 Subject: =?UTF-8?B?UmU6IE5naW54INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC0?= =?UTF-8?B?0YDRg9Cz0L7QuSDQsNC00YDQtdGB?= In-Reply-To: <70d711812d4b21f8dd7c546a31531942.NginxMailingListRussian@forum.nginx.org> References: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org> <08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org> <75a80bf654728bdf2cfde7dcc8c67f2b.NginxMailingListRussian@forum.nginx.org> <6252477b6fda3249308649a438eb2cf0.NginxMailingListRussian@forum.nginx.org> <70d711812d4b21f8dd7c546a31531942.NginxMailingListRussian@forum.nginx.org> Message-ID: <41a67941-567b-8522-a93e-0f6085b75a1f@ya.ru> Может, вам нужно проксировать запрос через сервер? server { listen 80; server_name example.org; location / { proxy_pass http://10.248.35.14:8092$request_uri; } } 04.06.2020 08:49, yyyuuu пишет: > Да Ты был прав, сработало. Но вот только одно не получилось. > server { > listen 80; > server_name example.org; > return 301 http://10.248.35.14:8092$request_uri; > } > Доступ к адресу есть только с одного компутера. При подключении к серверу > 10.1.1.1 - он Меня переводить на http://10.248.35.14:8092 но доступа с > компутера нету к этому адресу. Тут адрес не целиком должен заменить а > выглядить что то вроде http://10.1.1.1/10.248.35.14:8092 > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287854,288261#msg-288261 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum на forum.nginx.org Thu Jun 4 02:12:04 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Wed, 03 Jun 2020 22:12:04 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC0?= =?UTF-8?B?0YDRg9Cz0L7QuSDQsNC00YDQtdGB?= In-Reply-To: <70d711812d4b21f8dd7c546a31531942.NginxMailingListRussian@forum.nginx.org> References: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org> <08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org> <75a80bf654728bdf2cfde7dcc8c67f2b.NginxMailingListRussian@forum.nginx.org> <6252477b6fda3249308649a438eb2cf0.NginxMailingListRussian@forum.nginx.org> <70d711812d4b21f8dd7c546a31531942.NginxMailingListRussian@forum.nginx.org> Message-ID: <3d2135a60d4507e3dce6bb27f30e4287.NginxMailingListRussian@forum.nginx.org> yyyuuu Wrote: ------------------------------------------------------- > что то вроде http://10.1.1.1/10.248.35.14:8092 што это ^^ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287854,288263#msg-288263 From red-fox0 на ya.ru Thu Jun 4 02:20:25 2020 From: red-fox0 на ya.ru (fox) Date: Thu, 4 Jun 2020 09:20:25 +0700 Subject: =?UTF-8?B?UmU6IE5naW54INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQvdCwINC0?= =?UTF-8?B?0YDRg9Cz0L7QuSDQsNC00YDQtdGB?= In-Reply-To: <3d2135a60d4507e3dce6bb27f30e4287.NginxMailingListRussian@forum.nginx.org> References: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org> <08d33518ddc55988dc4b61810de727f5.NginxMailingListRussian@forum.nginx.org> <75a80bf654728bdf2cfde7dcc8c67f2b.NginxMailingListRussian@forum.nginx.org> <6252477b6fda3249308649a438eb2cf0.NginxMailingListRussian@forum.nginx.org> <70d711812d4b21f8dd7c546a31531942.NginxMailingListRussian@forum.nginx.org> <3d2135a60d4507e3dce6bb27f30e4287.NginxMailingListRussian@forum.nginx.org> Message-ID: <658f7f8e-d7b3-f957-9752-839663fd06de@ya.ru> Анонимайзер изобретают :) 04.06.2020 09:12, greenwar пишет: > yyyuuu Wrote: > ------------------------------------------------------- >> что то вроде http://10.1.1.1/10.248.35.14:8092 > > > што это ^^ > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287854,288263#msg-288263 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum на forum.nginx.org Wed Jun 10 15:04:39 2020 From: nginx-forum на forum.nginx.org (grey) Date: Wed, 10 Jun 2020 11:04:39 -0400 Subject: =?UTF-8?B?YWNjZXNzIGxvZyDQuCDQv9Cw0YDQsNC80LXRgtGAIGZsdXNo?= Message-ID: <62e5a4763eb7f02d724ecc0730c8d934.NginxMailingListRussian@forum.nginx.org> Привет! Хочу сделать, чтобы логи сбрасывались в файл раз в 5 минут. Делаю как в примере access_log /path/to/log.gz combined gzip flush=5m; только без параметра gzip, т.е. access_log /path/to/log.gz combined flush=5m; nginx ругается ошибкой при рестарте: nginx: [emerg] no buffer is defined for access_log "logs/access.log" Это нормальное поведение? В доках нигде не сказано, что параметр flush работает только вместе с gzip. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288324,288324#msg-288324 From matorola на gmail.com Wed Jun 10 15:07:32 2020 From: matorola на gmail.com (Anatoly Pugachev) Date: Wed, 10 Jun 2020 18:07:32 +0300 Subject: =?UTF-8?B?UmU6IGFjY2VzcyBsb2cg0Lgg0L/QsNGA0LDQvNC10YLRgCBmbHVzaA==?= In-Reply-To: <62e5a4763eb7f02d724ecc0730c8d934.NginxMailingListRussian@forum.nginx.org> References: <62e5a4763eb7f02d724ecc0730c8d934.NginxMailingListRussian@forum.nginx.org> Message-ID: On Wed, Jun 10, 2020 at 6:05 PM grey wrote: > > Привет! > > > Хочу сделать, чтобы логи сбрасывались в файл раз в 5 минут. Делаю как в > примере > > access_log /path/to/log.gz combined gzip flush=5m; > > только без параметра gzip, т.е. access_log /path/to/log.gz combined > flush=5m; > > nginx ругается ошибкой при рестарте: nginx: [emerg] no buffer is defined for > access_log "logs/access.log" > > Это нормальное поведение? В доках нигде не сказано, что параметр flush > работает только вместе с gzip. https://nginx.org/en/docs/http/ngx_http_log_module.html If either the buffer or gzip (1.3.10, 1.2.7) parameter is used, writes to log will be buffered. From nginx-forum на forum.nginx.org Wed Jun 10 15:13:27 2020 From: nginx-forum на forum.nginx.org (grey) Date: Wed, 10 Jun 2020 11:13:27 -0400 Subject: =?UTF-8?B?UmU6IGFjY2VzcyBsb2cg0Lgg0L/QsNGA0LDQvNC10YLRgCBmbHVzaA==?= In-Reply-To: References: Message-ID: <10c1f19d33afae36d504e22e5a6f7614.NginxMailingListRussian@forum.nginx.org> Это я видел в русской доке: Если задан размер буфера с помощью параметра buffer или указан параметр gzip (1.3.10, 1.2.7), то запись будет буферизованной. "Если задан", а он не задан, то по логике сброс должен происходить в 5 минут согласно параметру flush=5m. Получается, на сайте не совсем правильное описание. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288325,288326#msg-288326 From chipitsine на gmail.com Wed Jun 10 15:21:07 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 10 Jun 2020 20:21:07 +0500 Subject: =?UTF-8?B?UmU6IGFjY2VzcyBsb2cg0Lgg0L/QsNGA0LDQvNC10YLRgCBmbHVzaA==?= In-Reply-To: <10c1f19d33afae36d504e22e5a6f7614.NginxMailingListRussian@forum.nginx.org> References: <10c1f19d33afae36d504e22e5a6f7614.NginxMailingListRussian@forum.nginx.org> Message-ID: Сброс происходит в двух случаях, или при заполнении буфера или раз в какое-то время. Буфер фиксированного размера On Wed, Jun 10, 2020, 8:13 PM grey wrote: > Это я видел в русской доке: > > Если задан размер буфера с помощью параметра buffer или указан параметр > gzip > (1.3.10, 1.2.7), то запись будет буферизованной. > > "Если задан", а он не задан, то по логике сброс должен происходить в 5 > минут > согласно параметру flush=5m. Получается, на сайте не совсем правильное > описание. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,288325,288326#msg-288326 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From matorola на gmail.com Tue Jun 16 09:14:22 2020 From: matorola на gmail.com (Anatoly Pugachev) Date: Tue, 16 Jun 2020 12:14:22 +0300 Subject: =?UTF-8?B?0YPRgdC70L7QstC90YvQuSDQtNC+0YHRgtGD0L8gLyBhY2Nlc3MgY29udHJvbA==?= Message-ID: Здравствуйте! Есть обычный nginx (не plus). Добавил к нему geoip модуль, все работает. Теперь хочу сделать доступ на основе geoip и обычных IP списков доступа. По отдельности geoip и IP acl работают, как сделать чтобы работало вместе? Логика нужна такая: - если ip_whitelist, то дальше по конфигурационному файлу - если ip_blacklist , то return 403 - (тут geoip) если $allowed_country == no, то return 403 если убрать первые два пункта, то получается такая конфигурация nginx (относительно /etc/nginx/ ) : nginx.conf : load_module modules/ngx_http_geoip_module.so; load_module modules/ngx_stream_geoip_module.so; cat conf.d/site.conf map $geoip_country_code $allowed_country { default no; RU yes; } server { server_name site.ru; if ($allowed_country = no) { return 403; } } и это работает, доступ только тем, для кого geoip вычислил что он из "RU" . Есть ли возможность добавить еще проверку по IP как описано выше (whitelist, blacklist, country) ? Вероятно в теории это можно сделать через директиву(ы) map и условиями if , но я никак пока не могу сообразить... Спасибо. From nginx-forum на forum.nginx.org Wed Jun 17 06:16:47 2020 From: nginx-forum на forum.nginx.org (emejibka) Date: Wed, 17 Jun 2020 02:16:47 -0400 Subject: location + proxy pass = 404 Message-ID: <0d345b054068a52511468fd4bb262232.NginxMailingListRussian@forum.nginx.org> Здравствуйте, коллеги. Имеется два сервера, на одном nginx 1.12.2, на втором - 1.17.10. На сервере со старой версией nginx всё работает, скопировал конфиг на новый сервер, на нём получаем ошибки 404 при запросе любых ресурсов, кроме корня. Кусочек конфига location /fluorography/ { proxy_pass http://10.50.0.1/; } При запросе страницы /fluorography/ на новом сервере nginx проксирует запрос, браузер получает заглавную страницу, но не может загрузить стили, картинки и прочие ресурсы, см https://yadi.sk/i/6Y24WIxNudgKFw При замене /fluorography/ на / всё работает. Посмотрел историю изменений, не нашёл ничего об изменении работы proxy_pass. Как понять причину такого поведения? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288369,288369#msg-288369 From shadow.tehb на gmail.com Wed Jun 17 07:30:33 2020 From: shadow.tehb на gmail.com (=?utf-8?B?0KHQtdGA0LPQtdC5INCi0YPRgNCz0YPQt9C+0LI=?=) Date: Wed, 17 Jun 2020 10:30:33 +0300 Subject: location + proxy pass = 404 In-Reply-To: <0d345b054068a52511468fd4bb262232.NginxMailingListRussian@forum.nginx.org> References: <0d345b054068a52511468fd4bb262232.NginxMailingListRussian@forum.nginx.org> Message-ID: <01ED2EBD-7445-4D9D-B35C-190005E02B74@gmail.com> Проблему надо искать в location, которые относятся к /Content/, /bundles/, etc. > 17 июня 2020 г., в 09:16, emejibka написал(а): > > Здравствуйте, коллеги. > > Имеется два сервера, на одном nginx 1.12.2, на втором - 1.17.10. > > На сервере со старой версией nginx всё работает, скопировал конфиг на новый > сервер, на нём получаем ошибки 404 при запросе любых ресурсов, кроме корня. > > Кусочек конфига > location /fluorography/ { > proxy_pass http://10.50.0.1/; > } > > При запросе страницы /fluorography/ на новом сервере nginx проксирует > запрос, браузер получает заглавную страницу, но не может загрузить стили, > картинки и прочие ресурсы, см https://yadi.sk/i/6Y24WIxNudgKFw > > При замене /fluorography/ на / всё работает. > > Посмотрел историю изменений, не нашёл ничего об изменении работы > proxy_pass. > > Как понять причину такого поведения? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288369,288369#msg-288369 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Wed Jun 17 10:35:26 2020 From: nginx-forum на forum.nginx.org (emejibka) Date: Wed, 17 Jun 2020 06:35:26 -0400 Subject: location + proxy pass = 404 In-Reply-To: <01ED2EBD-7445-4D9D-B35C-190005E02B74@gmail.com> References: <01ED2EBD-7445-4D9D-B35C-190005E02B74@gmail.com> Message-ID: <95104bd5a4d35d3e68657387053c5aee.NginxMailingListRussian@forum.nginx.org> В том то и дело что другие location в конфиге отсутствуют. Как объяснить работающий конфиг на старой версии nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288370,288372#msg-288372 From shadow.tehb на gmail.com Wed Jun 17 10:43:45 2020 From: shadow.tehb на gmail.com (=?utf-8?B?0KHQtdGA0LPQtdC5INCi0YPRgNCz0YPQt9C+0LI=?=) Date: Wed, 17 Jun 2020 13:43:45 +0300 Subject: location + proxy pass = 404 In-Reply-To: <95104bd5a4d35d3e68657387053c5aee.NginxMailingListRussian@forum.nginx.org> References: <01ED2EBD-7445-4D9D-B35C-190005E02B74@gmail.com> <95104bd5a4d35d3e68657387053c5aee.NginxMailingListRussian@forum.nginx.org> Message-ID: <5E1E24FB-3A8C-4FD3-A37A-0A2372EE378F@gmail.com> Ещё вариант, можно через rewrite придти к нужному url. Но голый конфиг вида server { listen; location /asd/ { proxy_pass; } } работать не будет, у вас нет условия для ‘/‘, т.е. запросы неподходящие под заданный location будут выдавать ошибку. > 17 июня 2020 г., в 13:35, emejibka написал(а): > > В том то и дело что другие location в конфиге отсутствуют. > Как объяснить работающий конфиг на старой версии nginx? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288370,288372#msg-288372 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From bgx на protva.ru Wed Jun 17 12:26:37 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 17 Jun 2020 15:26:37 +0300 Subject: location + proxy pass = 404 In-Reply-To: <95104bd5a4d35d3e68657387053c5aee.NginxMailingListRussian@forum.nginx.org> References: <01ED2EBD-7445-4D9D-B35C-190005E02B74@gmail.com> <95104bd5a4d35d3e68657387053c5aee.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200617122637.GJ15464@sie.protva.ru> On Wed, Jun 17, 2020 at 06:35:26AM -0400, emejibka wrote: > В том то и дело что другие location в конфиге отсутствуют. > Как объяснить работающий конфиг на старой версии nginx? Для начала получить debug log-и и сравнить. -- Eugene Berdnikov From chipitsine на gmail.com Wed Jun 17 12:31:39 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 17 Jun 2020 17:31:39 +0500 Subject: location + proxy pass = 404 In-Reply-To: <95104bd5a4d35d3e68657387053c5aee.NginxMailingListRussian@forum.nginx.org> References: <01ED2EBD-7445-4D9D-B35C-190005E02B74@gmail.com> <95104bd5a4d35d3e68657387053c5aee.NginxMailingListRussian@forum.nginx.org> Message-ID: если локейшены отсутствуют, то при запросе на них отдается статика с пути, заданного в директиве root (это может быть неявно). вероятно, эти файлы лежали прямо на сервере. можно поставить вопрос по другому, что должно происходить при подобных запросах ? как они должны обрабатываться ? и уже по это нарисовать конфиг ср, 17 июн. 2020 г. в 15:35, emejibka : > В том то и дело что другие location в конфиге отсутствуют. > Как объяснить работающий конфиг на старой версии nginx? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,288370,288372#msg-288372 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Jun 17 12:32:26 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 17 Jun 2020 17:32:26 +0500 Subject: location + proxy pass = 404 In-Reply-To: <5E1E24FB-3A8C-4FD3-A37A-0A2372EE378F@gmail.com> References: <01ED2EBD-7445-4D9D-B35C-190005E02B74@gmail.com> <95104bd5a4d35d3e68657387053c5aee.NginxMailingListRussian@forum.nginx.org> <5E1E24FB-3A8C-4FD3-A37A-0A2372EE378F@gmail.com> Message-ID: было бы идеально, если бы подобные конфиги приводили к ошибке. но нет, они работают )) к сожалению, весьма запутанным образом ср, 17 июн. 2020 г. в 15:43, Сергей Тургузов : > Ещё вариант, можно через rewrite придти к нужному url. > Но голый конфиг вида server { listen; location /asd/ { proxy_pass; } } > работать не будет, у вас нет условия для ‘/‘, т.е. запросы неподходящие под > заданный location будут выдавать ошибку. > > > 17 июня 2020 г., в 13:35, emejibka > написал(а): > > > > В том то и дело что другие location в конфиге отсутствуют. > > Как объяснить работающий конфиг на старой версии nginx? > > > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,288370,288372#msg-288372 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Jun 17 16:53:23 2020 From: nginx-forum на forum.nginx.org (emejibka) Date: Wed, 17 Jun 2020 12:53:23 -0400 Subject: location + proxy pass = 404 In-Reply-To: References: Message-ID: Странно, запустил nginx версии 1.12 в докере с "рабочим" конфигом, результат тот же - 404. У нас следующая задача - необходимо спрятать за nginx с десяток других веб сервисов, nginx будет работать только как реверс-прокси. DNS использовать нельзя, nginx будет использоваться внутри локальной сети, dns может быть недоступен, да и адреса серверов могут быть разные. Т.е. надо поднять сервер по-умолчанию (без виртуальных серверов), где каждая "виртуальная папка" (location) будет проксировать запросы на другой веб-сервер. Пример /a => http://10.86.11.80/ /b => http://some_server /c => http://other_server/some_folder/api и т.д. Пока писал это понял что nginx`у будет необходимо заменить все ссылки в ответе, что вряд ли возможно или всё таки можно это сделать? Ещё раз посмотрел "рабочий" конфиг, вы были правы, я нашёл location / в котором был такой же proxy_pass поэтому всё работало. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288370,288381#msg-288381 From chipitsine на gmail.com Wed Jun 17 17:03:35 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 17 Jun 2020 22:03:35 +0500 Subject: location + proxy pass = 404 In-Reply-To: References: Message-ID: ср, 17 июн. 2020 г. в 21:53, emejibka : > Странно, запустил nginx версии 1.12 в докере с "рабочим" конфигом, > результат > тот же - 404. > > У нас следующая задача - необходимо спрятать за nginx с десяток других веб > сервисов, nginx будет работать только как реверс-прокси. DNS использовать > это тонкий момент. DNS используется только на чтении конфига. если у вас предполагается, что во время работы DNS может меняться, то это почти никак. если у вас адреса фиксированные - вы вполне можете работать на IP адресах. > нельзя, nginx будет использоваться внутри локальной сети, dns может быть > недоступен, да и адреса серверов могут быть разные. > Т.е. надо поднять сервер по-умолчанию (без виртуальных серверов), где > каждая > "виртуальная папка" (location) будет проксировать запросы на другой > веб-сервер. Пример > /a => http://10.86.11.80/ > /b => http://some_server > /c => http://other_server/some_folder/api > и т.д. > куча location-ов и куча правил проксирования. как обычно > > Пока писал это понял что nginx`у будет необходимо заменить все ссылки в > ответе, что вряд ли возможно или всё таки можно это сделать? > > Ещё раз посмотрел "рабочий" конфиг, вы были правы, я нашёл location / в > котором был такой же proxy_pass поэтому всё работало. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,288370,288381#msg-288381 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Jun 19 06:37:03 2020 From: nginx-forum на forum.nginx.org (emejibka) Date: Fri, 19 Jun 2020 02:37:03 -0400 Subject: location + proxy pass = 404 In-Reply-To: References: Message-ID: <1c12171287502764e7a21c896fbbf51b.NginxMailingListRussian@forum.nginx.org> Всем спасибо. В итоге сделал такой конфиг ... map $request_uri $topdir { ~(?^/[a-zA-Z0-9]+[/]) $captured_topdir; } ... server { listen 80; server_name _; proxy_set_header Accept-Encoding "gzip,deflate"; proxy_set_header Connection "upgrade"; proxy_set_header Upgrade $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header X-Forwarded-Proto $scheme; gzip off; gunzip on; location /test/ { proxy_pass https://some_service/; sub_filter "'/" "'$topdir"; sub_filter '"/' '"$topdir'; sub_filter_once off; } ... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288370,288397#msg-288397 From nginx-forum на forum.nginx.org Sun Jun 21 09:27:40 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Sun, 21 Jun 2020 05:27:40 -0400 Subject: =?UTF-8?B?0L3QvtCy0LDRjyDQutC+0L3RhNC40LPRg9GA0LDRhtC40Y8g0L3QtSDRgNCw0LE=?= =?UTF-8?B?0L7RgtCw0LXRgiDRgdGA0LDQt9GD?= Message-ID: <363e2bde30f7fd2336851b6cf46e28b5.NginxMailingListRussian@forum.nginx.org> столкнулся с такой проблемой, когда прописываешь новый конфиг в файлах, то долгое время работает старый конфиг например, прописал редирект на сайте потом редирект убрал nginx перезапустил 1000 раз а редирект всё равно работает и только если заменить файл в /sites-enabled/ на другой, с новым конфигом, тогда новый конфиг заработает а так надо ждать хз сколько... долго не пойму, это в браузере косяк или в nginx но такой косяк в обоих браузерах - chrome И firefox Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288413,288413#msg-288413 From nginx-forum на forum.nginx.org Sun Jun 21 09:30:26 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Sun, 21 Jun 2020 05:30:26 -0400 Subject: =?UTF-8?B?UmU6INC90L7QstCw0Y8g0LrQvtC90YTQuNCz0YPRgNCw0YbQuNGPINC90LUg0YA=?= =?UTF-8?B?0LDQsdC+0YLQsNC10YIg0YHRgNCw0LfRgw==?= In-Reply-To: <363e2bde30f7fd2336851b6cf46e28b5.NginxMailingListRussian@forum.nginx.org> References: <363e2bde30f7fd2336851b6cf46e28b5.NginxMailingListRussian@forum.nginx.org> Message-ID: <8c5b49466173c95cf66d5cb95c1cdb34.NginxMailingListRussian@forum.nginx.org> вот, например, был server_name test3.ru; прописал server_name www.test4.ru; перезапустил. а он всё равно ловит подключения с test3.ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288413,288414#msg-288414 From red-fox0 на ya.ru Sun Jun 21 09:39:42 2020 From: red-fox0 на ya.ru (fox) Date: Sun, 21 Jun 2020 16:39:42 +0700 Subject: =?UTF-8?B?UmU6INC90L7QstCw0Y8g0LrQvtC90YTQuNCz0YPRgNCw0YbQuNGPINC90LUg0YA=?= =?UTF-8?B?0LDQsdC+0YLQsNC10YIg0YHRgNCw0LfRgw==?= In-Reply-To: <8c5b49466173c95cf66d5cb95c1cdb34.NginxMailingListRussian@forum.nginx.org> References: <363e2bde30f7fd2336851b6cf46e28b5.NginxMailingListRussian@forum.nginx.org> <8c5b49466173c95cf66d5cb95c1cdb34.NginxMailingListRussian@forum.nginx.org> Message-ID: 301 редиректы, вроде, кешируются браузерами. Надо смотреть логи сервера. 21.06.2020 16:30, greenwar пишет: > вот, например, был server_name test3.ru; > прописал server_name www.test4.ru; > перезапустил. > а он всё равно ловит подключения с test3.ru > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288413,288414#msg-288414 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum на forum.nginx.org Sun Jun 21 14:33:39 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Sun, 21 Jun 2020 10:33:39 -0400 Subject: =?UTF-8?B?UmU6INC90L7QstCw0Y8g0LrQvtC90YTQuNCz0YPRgNCw0YbQuNGPINC90LUg0YA=?= =?UTF-8?B?0LDQsdC+0YLQsNC10YIg0YHRgNCw0LfRgw==?= In-Reply-To: References: Message-ID: <2bd2b4a210fc22ef383dc90238f6e0e4.NginxMailingListRussian@forum.nginx.org> да впечатление такое, что он как закешировал ответ, так и навсегда. пока комп не перезагрузишь. я с утра ещё отключил test3 и создал test4 а он всё ещё отдаёт test3... а в какие логи надо смотреть? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288413,288419#msg-288419 From red-fox0 на ya.ru Sun Jun 21 14:46:26 2020 From: red-fox0 на ya.ru (fox) Date: Sun, 21 Jun 2020 21:46:26 +0700 Subject: =?UTF-8?B?UmU6INC90L7QstCw0Y8g0LrQvtC90YTQuNCz0YPRgNCw0YbQuNGPINC90LUg0YA=?= =?UTF-8?B?0LDQsdC+0YLQsNC10YIg0YHRgNCw0LfRgw==?= In-Reply-To: <2bd2b4a210fc22ef383dc90238f6e0e4.NginxMailingListRussian@forum.nginx.org> References: <2bd2b4a210fc22ef383dc90238f6e0e4.NginxMailingListRussian@forum.nginx.org> Message-ID: https://stackoverflow.com/questions/9130422/how-long-do-browsers-cache-http-301s Логи nginx'а :) И увидеть в них, что браузер на самом деле не обращается к серверу, а сразу переходит по закешированному редиректу. 21.06.2020 21:33, greenwar пишет: > да впечатление такое, что он как закешировал ответ, так и навсегда. > пока комп не перезагрузишь. > я с утра ещё отключил test3 и создал test4 > а он всё ещё отдаёт test3... > > а в какие логи надо смотреть? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288413,288419#msg-288419 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum на forum.nginx.org Sun Jun 21 18:18:24 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Sun, 21 Jun 2020 14:18:24 -0400 Subject: =?UTF-8?B?UmU6INC90L7QstCw0Y8g0LrQvtC90YTQuNCz0YPRgNCw0YbQuNGPINC90LUg0YA=?= =?UTF-8?B?0LDQsdC+0YLQsNC10YIg0YHRgNCw0LfRgw==?= In-Reply-To: References: Message-ID: <183cd37f5c21bd2f801985f929d2bf2c.NginxMailingListRussian@forum.nginx.org> о, отличная ссылка. Вроде порешал, спасибо :) fox Wrote: ------------------------------------------------------- > https://stackoverflow.com/questions/9130422/how-long-do-browsers-cache > -http-301s > > Логи nginx'а :) И увидеть в них, что браузер на самом деле не > обращается > к серверу, а сразу переходит по закешированному редиректу. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288413,288421#msg-288421 From nginx-forum на forum.nginx.org Sun Jun 21 21:53:57 2020 From: nginx-forum на forum.nginx.org (edo1) Date: Sun, 21 Jun 2020 17:53:57 -0400 Subject: =?UTF-8?B?bGltaXQgcmF0ZSDQuCDQstGL0YHQvtC60LjQtSDRgdC60L7RgNC+0YHRgtC4?= Message-ID: <41eb1e571e7735baba2c396cb6a7071d.NginxMailingListRussian@forum.nginx.org> есть такой конфиг: server { listen 19999 default_server reuseport;# sndbuf=4m; location ~ ^/speedtest-limit-([0-9]+[km]?)/([^/]*)$ { limit_rate $1; limit_rate_after 2m; alias /var/www/speedtest/$2; } } проверяю скорость скачивания без лимита, вполне приличная: $ curl -o /dev/null 127.0.0.1:19999/speedtest-limit-0/1000mb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1000M 100 1000M 0 0 2375M 0 --:--:-- --:--:-- --:--:-- 2375M с относительно небольшим лимитом всё хорошо: $ curl -o /dev/null 127.0.0.1:19999/speedtest-limit-1m/100mb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 100M 100 100M 0 0 1044k 0 0:01:38 0:01:38 --:--:-- 1008k а вот с лимитом повыше ерунда выходит: $ curl -o /dev/null 127.0.0.1:19999/speedtest-limit-100m/1000mb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1000M 100 1000M 0 0 42.9M 0 0:00:23 0:00:23 --:--:-- 42.6M что можно подкрутить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288423,288423#msg-288423 From mdounin на mdounin.ru Mon Jun 22 10:25:58 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 22 Jun 2020 13:25:58 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUg0Lgg0LLRi9GB0L7QutC40LUg0YHQutC+0YDQvtGB0YI=?= =?UTF-8?B?0Lg=?= In-Reply-To: <41eb1e571e7735baba2c396cb6a7071d.NginxMailingListRussian@forum.nginx.org> References: <41eb1e571e7735baba2c396cb6a7071d.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200622102558.GB12747@mdounin.ru> Hello! On Sun, Jun 21, 2020 at 05:53:57PM -0400, edo1 wrote: > есть такой конфиг: > server { > listen 19999 default_server reuseport;# sndbuf=4m; > location ~ ^/speedtest-limit-([0-9]+[km]?)/([^/]*)$ { > limit_rate $1; > limit_rate_after 2m; > alias /var/www/speedtest/$2; > } > } > > проверяю скорость скачивания без лимита, вполне приличная: > $ curl -o /dev/null 127.0.0.1:19999/speedtest-limit-0/1000mb > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 100 1000M 100 1000M 0 0 2375M 0 --:--:-- --:--:-- --:--:-- > 2375M > > с относительно небольшим лимитом всё хорошо: > $ curl -o /dev/null 127.0.0.1:19999/speedtest-limit-1m/100mb > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 100 100M 100 100M 0 0 1044k 0 0:01:38 0:01:38 --:--:-- > 1008k > > а вот с лимитом повыше ерунда выходит: > $ curl -o /dev/null 127.0.0.1:19999/speedtest-limit-100m/1000mb > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 100 1000M 100 1000M 0 0 42.9M 0 0:00:23 0:00:23 --:--:-- > 42.6M > > > что можно подкрутить? Подкрутить можно размеры буферов и/или включить sendfile, подробнее тут: https://trac.nginx.org/nginx/ticket/1678#comment:1 -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Jun 25 11:34:25 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 25 Jun 2020 14:34:25 +0300 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) Message-ID: Здравствуйте, All! CentOS 8.2, nginx 1.19.0 из официального репозитория. Когда запускаю nginx внутри systemd-nspawn контейнера - в error.log видно большое количество сообщений про ошибку: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) Подозреваю, что nginx в контейнере не хватает каких-то лимитов, только не понятно каких именно. При worker_processes 64; ошибка появляется в логах, при worker_processes 32; ошибки в логах больше нет. Каким образом можно сделать так, чтобы nginx работал в контейнере systemd-nspawn без ошибок с директивой worker_processes 64; в конфиге? Насколько критична эта ошибка, и может ли она появиться в логах при worker_processes 32; в случае высокой нагрузки на nginx? Процессор на этом сервере: AMD EPYC 7502P 32-Core Processor 32 физических ядра, 64 виртуальных ядра (Simultaneous MultiThreading). Конфиг: /etc/systemd/nspawn/1.nspawn [Exec] ResolvConf=copy-host LimitNOFILE=infinity LimitNICE=40 [Network] Bridge=venet0 /etc/nginx/nginx.conf worker_processes 64; worker_priority -10; worker_rlimit_core 512M; worker_rlimit_nofile 262144; worker_shutdown_timeout 60s; working_directory /var/log/nginx; error_log /var/log/nginx/error.log warn; events { worker_connections 262144; use epoll; } http { # ... } -- Best regards, Gena From chipitsine на gmail.com Thu Jun 25 11:48:57 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 25 Jun 2020 16:48:57 +0500 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: References: Message-ID: чт, 25 июн. 2020 г. в 16:34, Gena Makhomed : > Здравствуйте, All! > > CentOS 8.2, nginx 1.19.0 из официального репозитория. > > Когда запускаю nginx внутри systemd-nspawn контейнера - > в error.log видно большое количество сообщений про ошибку: > > [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) > > Подозреваю, что nginx в контейнере не хватает каких-то лимитов, > только не понятно каких именно. > > При worker_processes 64; ошибка появляется в логах, > при worker_processes 32; ошибки в логах больше нет. > > Каким образом можно сделать так, чтобы nginx работал в контейнере > systemd-nspawn без ошибок с директивой worker_processes 64; в конфиге? > > Насколько критична эта ошибка, и может ли она появиться в логах > при worker_processes 32; в случае высокой нагрузки на nginx? > > Процессор на этом сервере: AMD EPYC 7502P 32-Core Processor > 32 физических ядра, 64 виртуальных ядра (Simultaneous MultiThreading). > > Конфиг: > > /etc/systemd/nspawn/1.nspawn > > [Exec] > ResolvConf=copy-host > LimitNOFILE=infinity > LimitNICE=40 > > [Network] > Bridge=venet0 > > /etc/nginx/nginx.conf > > worker_processes 64; > worker_priority -10; > worker_rlimit_core 512M; > worker_rlimit_nofile 262144; > в этом месте вы думаете, что воркер сам себе проставил такой лимит на количество файлов. посмотрите в /proc//limits , действительно ли там значения, которые вы ожидаете или нет у нас было, что systemd применял свои лимиты поверх > worker_shutdown_timeout 60s; > working_directory /var/log/nginx; > > error_log /var/log/nginx/error.log warn; > > events { > worker_connections 262144; > use epoll; > } > > http { > # ... > } > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Jun 25 13:05:19 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 25 Jun 2020 16:05:19 +0300 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: References: Message-ID: <96df6d8a-8232-31cb-747d-a6cd41bfe7ea@csdoc.com> On 25.06.2020 14:48, Илья Шипицин wrote: >> /etc/systemd/nspawn/1.nspawn >> >> [Exec] >> LimitNOFILE=infinity >> /etc/nginx/nginx.conf >> >> worker_rlimit_nofile 262144; > в этом месте вы думаете, что воркер сам себе проставил такой лимит на > количество файлов. > посмотрите в /proc//limits , действительно ли там значения, которые вы > ожидаете или нет > у нас было, что systemd применял свои лимиты поверх # cat /proc/205/cmdline nginx: worker process # grep "Max open files" /proc/205/limits Max open files 262144 262144 files -- Best regards, Gena From mdounin на mdounin.ru Thu Jun 25 14:23:41 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 25 Jun 2020 17:23:41 +0300 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: <96df6d8a-8232-31cb-747d-a6cd41bfe7ea@csdoc.com> References: <96df6d8a-8232-31cb-747d-a6cd41bfe7ea@csdoc.com> Message-ID: <20200625142341.GK12747@mdounin.ru> Hello! On Thu, Jun 25, 2020 at 04:05:19PM +0300, Gena Makhomed wrote: > On 25.06.2020 14:48, Илья Шипицин wrote: > > > > /etc/systemd/nspawn/1.nspawn > > > > > > [Exec] > > > LimitNOFILE=infinity > > > > /etc/nginx/nginx.conf > > > > > > worker_rlimit_nofile 262144; > > > в этом месте вы думаете, что воркер сам себе проставил такой лимит на > > количество файлов. > > > посмотрите в /proc//limits , действительно ли там значения, которые вы > > ожидаете или нет > > у нас было, что systemd применял свои лимиты поверх > > # cat /proc/205/cmdline > nginx: worker process > > # grep "Max open files" /proc/205/limits > Max open files 262144 262144 files А у master-процесса что? Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает, что количество одновременно отправляемых файловых дескрипторов превышает лимит на количество дескрипторов в отправляющем процессе, в данном случае - в мастере, ибо никто больше файловые дескрипторы с помощью sendmsg() не шлёт. Собственно, pid процесса можно смотреть сразу в сообщении об ошибке. Ну и отвечая на исходный вопрос про "насколько критична эта ошибка": приведённая ошибка как минимум означает, что система общения между мастером и рабочими процессами больше не работает. То есть отвечать на запросы nginx будет, а скажем reload сделать - уже нормально не сможет. То есть приблизительно как и со всеми ошибками уровня alert: "что-то развалилось и непредсказуемо глючит, сделайте что-нибудь". -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Jun 25 14:59:33 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 25 Jun 2020 17:59:33 +0300 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: <20200625142341.GK12747@mdounin.ru> References: <96df6d8a-8232-31cb-747d-a6cd41bfe7ea@csdoc.com> <20200625142341.GK12747@mdounin.ru> Message-ID: <4ac55d3c-3e41-6fdc-50c7-850ac7f09d93@csdoc.com> On 25.06.2020 17:23, Maxim Dounin wrote: >>> в этом месте вы думаете, что воркер сам себе проставил такой лимит на >>> количество файлов. >> >>> посмотрите в /proc//limits , действительно ли там значения, которые вы >>> ожидаете или нет >>> у нас было, что systemd применял свои лимиты поверх >> >> # cat /proc/205/cmdline >> nginx: worker process >> >> # grep "Max open files" /proc/205/limits >> Max open files 262144 262144 files > > А у master-процесса что? # cat /proc/182/cmdline nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf # grep "Max open files" /proc/182/limits Max open files 1024 262144 files С помощью директив конфига nginx, насколько я понимаю, 1024 нельзя увеличить до какого-нибудь большего значения. с помощью systemctl edit nginx сделал /etc/systemd/system/nginx.service.d/override.conf [Service] LimitNOFILE=infinity так что теперь, после перезапуска у мастера такие параметры: # cat /proc/690/cmdline nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf # grep "Max open files" /proc/690/limits Max open files 262144 262144 files И nginx теперь нормально запускается даже при worker_processes 128; Спасибо! > Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает, > что количество одновременно отправляемых файловых дескрипторов > превышает лимит на количество дескрипторов в отправляющем > процессе, в данном случае - в мастере, ибо никто больше файловые > дескрипторы с помощью sendmsg() не шлёт. > Ну и отвечая на исходный вопрос про "насколько критична эта > ошибка": приведённая ошибка как минимум означает, что система > общения между мастером и рабочими процессами больше не работает. > То есть отвечать на запросы nginx будет, а скажем reload сделать - > уже нормально не сможет. То есть приблизительно как и со всеми > ошибками уровня alert: "что-то развалилось и непредсказуемо > глючит, сделайте что-нибудь". Если я правильно понял Ваш ответ - nginx шлет файловые дескрипторы из мастера в воркеры только в процессе старта и в процессе релоада, то есть, эта ошибка sendmsg() failed (109: Too many references: cannot splice) не должна повториться в дальнейшем, в процессе работы nginx под большой нагрузкой, если в процессе запуска и релоада подобных ошибок не было. P.S. На том сервере процессор AMD EPYC 7502P 32-Core Processor так что 32 worker-процесса nginx вполне должно быть достаточно, по количеству физических ядер и без правки LimitNOFILE для мастера. Но при настройке worker_processes auto; глюки есть уже сейчас, потому что в auto считаются виртуальные а не физические ядра. Со стороны nginx этот глюк никак нельзя обойти/устранить, чтобы все работало при настройке worker_processes auto; без ручной правки LimitNOFILE через systemctl edit nginx на сервере с процессором AMD EPYC 7502P 32-Core Processor? -- Best regards, Gena From chipitsine на gmail.com Thu Jun 25 15:13:06 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 25 Jun 2020 20:13:06 +0500 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: <4ac55d3c-3e41-6fdc-50c7-850ac7f09d93@csdoc.com> References: <96df6d8a-8232-31cb-747d-a6cd41bfe7ea@csdoc.com> <20200625142341.GK12747@mdounin.ru> <4ac55d3c-3e41-6fdc-50c7-850ac7f09d93@csdoc.com> Message-ID: чт, 25 июн. 2020 г. в 19:59, Gena Makhomed : > On 25.06.2020 17:23, Maxim Dounin wrote: > > >>> в этом месте вы думаете, что воркер сам себе проставил такой лимит на > >>> количество файлов. > >> > >>> посмотрите в /proc//limits , действительно ли там значения, > которые вы > >>> ожидаете или нет > >>> у нас было, что systemd применял свои лимиты поверх > >> > >> # cat /proc/205/cmdline > >> nginx: worker process > >> > >> # grep "Max open files" /proc/205/limits > >> Max open files 262144 262144 files > > > > А у master-процесса что? > > # cat /proc/182/cmdline > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > > # grep "Max open files" /proc/182/limits > Max open files 1024 262144 files > > С помощью директив конфига nginx, насколько я понимаю, > 1024 нельзя увеличить до какого-нибудь большего значения. > > с помощью systemctl edit nginx сделал > > /etc/systemd/system/nginx.service.d/override.conf > > [Service] > LimitNOFILE=infinity > > так что теперь, после перезапуска у мастера такие параметры: > > # cat /proc/690/cmdline > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > > # grep "Max open files" /proc/690/limits > Max open files 262144 262144 files > > И nginx теперь нормально запускается даже при worker_processes 128; > > Спасибо! > > > Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает, > > что количество одновременно отправляемых файловых дескрипторов > > превышает лимит на количество дескрипторов в отправляющем > > процессе, в данном случае - в мастере, ибо никто больше файловые > > дескрипторы с помощью sendmsg() не шлёт. > > > Ну и отвечая на исходный вопрос про "насколько критична эта > > ошибка": приведённая ошибка как минимум означает, что система > > общения между мастером и рабочими процессами больше не работает. > > То есть отвечать на запросы nginx будет, а скажем reload сделать - > > уже нормально не сможет. То есть приблизительно как и со всеми > > ошибками уровня alert: "что-то развалилось и непредсказуемо > > глючит, сделайте что-нибудь". > > Если я правильно понял Ваш ответ - nginx шлет файловые дескрипторы > из мастера в воркеры только в процессе старта и в процессе релоада, > то есть, эта ошибка > насколько я помню, в принципе разная работа с дескрипторами может быть, например, если логи открыты в буферизированном варианте. (если небуферизированные, то воркер открывает, записывает и закрывает. если буферизированные, то дескриптор хранится в мастере) интересно посмотреть, что у вас в /proc//fd , это файлы открытые мастером > > sendmsg() failed (109: Too many references: cannot splice) > > не должна повториться в дальнейшем, в процессе работы nginx > под большой нагрузкой, если в процессе запуска и релоада > подобных ошибок не было. > > P.S. > > На том сервере процессор AMD EPYC 7502P 32-Core Processor > так что 32 worker-процесса nginx вполне должно быть достаточно, > по количеству физических ядер и без правки LimitNOFILE для мастера. > > Но при настройке worker_processes auto; глюки есть уже сейчас, > потому что в auto считаются виртуальные а не физические ядра. > > Со стороны nginx этот глюк никак нельзя обойти/устранить, > чтобы все работало при настройке worker_processes auto; > без ручной правки LimitNOFILE через systemctl edit nginx > на сервере с процессором AMD EPYC 7502P 32-Core Processor? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Jun 25 16:02:21 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 25 Jun 2020 19:02:21 +0300 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: References: <96df6d8a-8232-31cb-747d-a6cd41bfe7ea@csdoc.com> <20200625142341.GK12747@mdounin.ru> <4ac55d3c-3e41-6fdc-50c7-850ac7f09d93@csdoc.com> Message-ID: On 25.06.2020 18:13, Илья Шипицин wrote: > интересно посмотреть, что у вас в /proc//fd , это файлы открытые > мастером При worker_processes 32: # cat /proc/909/cmdline nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf # ls -l /proc/909/fd/ всего там 72 дескриптора, 0 -> /dev/null 1 -> /dev/null 2 -> /var/log/nginx/error.log 3 -> socket:[1142765] 4 -> /var/log/nginx/error.log 5 -> /var/log/nginx/access.log 6 -> socket:[1148452] ... остальные указывают на сокеты. (мастер слушает на 80 и 443 порту) P.S. Но это сервер с 0-й нагрузкой, там ничего не пишется и не читается, он сейчас находится как раз в процессе настройки. P.P.S. Там еще один очень неприятный глюк с systemd проявился, не имеющий отношения к nginx: https://lists.freedesktop.org/archives/systemd-devel/2020-June/044763.html -- Best regards, Gena From mdounin на mdounin.ru Thu Jun 25 16:08:30 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 25 Jun 2020 19:08:30 +0300 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: <4ac55d3c-3e41-6fdc-50c7-850ac7f09d93@csdoc.com> References: <96df6d8a-8232-31cb-747d-a6cd41bfe7ea@csdoc.com> <20200625142341.GK12747@mdounin.ru> <4ac55d3c-3e41-6fdc-50c7-850ac7f09d93@csdoc.com> Message-ID: <20200625160830.GN12747@mdounin.ru> Hello! On Thu, Jun 25, 2020 at 05:59:33PM +0300, Gena Makhomed wrote: > On 25.06.2020 17:23, Maxim Dounin wrote: > > > > > в этом месте вы думаете, что воркер сам себе проставил такой лимит на > > > > количество файлов. > > > > > > > посмотрите в /proc//limits , действительно ли там значения, которые вы > > > > ожидаете или нет > > > > у нас было, что systemd применял свои лимиты поверх > > > > > > # cat /proc/205/cmdline > > > nginx: worker process > > > > > > # grep "Max open files" /proc/205/limits > > > Max open files 262144 262144 files > > > > А у master-процесса что? > > # cat /proc/182/cmdline > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > > # grep "Max open files" /proc/182/limits > Max open files 1024 262144 files > > С помощью директив конфига nginx, насколько я понимаю, > 1024 нельзя увеличить до какого-нибудь большего значения. > > с помощью systemctl edit nginx сделал > > /etc/systemd/system/nginx.service.d/override.conf > > [Service] > LimitNOFILE=infinity > > так что теперь, после перезапуска у мастера такие параметры: > > # cat /proc/690/cmdline > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > > # grep "Max open files" /proc/690/limits > Max open files 262144 262144 files > > И nginx теперь нормально запускается даже при worker_processes 128; > > Спасибо! > > > Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает, > > что количество одновременно отправляемых файловых дескрипторов > > превышает лимит на количество дескрипторов в отправляющем > > процессе, в данном случае - в мастере, ибо никто больше файловые > > дескрипторы с помощью sendmsg() не шлёт. > > > Ну и отвечая на исходный вопрос про "насколько критична эта > > ошибка": приведённая ошибка как минимум означает, что система > > общения между мастером и рабочими процессами больше не работает. > > То есть отвечать на запросы nginx будет, а скажем reload сделать - > > уже нормально не сможет. То есть приблизительно как и со всеми > > ошибками уровня alert: "что-то развалилось и непредсказуемо > > глючит, сделайте что-нибудь". > > Если я правильно понял Ваш ответ - nginx шлет файловые дескрипторы > из мастера в воркеры только в процессе старта и в процессе релоада, > то есть, эта ошибка > > sendmsg() failed (109: Too many references: cannot splice) > > не должна повториться в дальнейшем, в процессе работы nginx > под большой нагрузкой, если в процессе запуска и релоада > подобных ошибок не было. Да, какие-либо дескрипторы отсылаются (сейчас) только при создании новых рабочих процессов. В дальнейшем, вероятно, будут отсылаться ещё и дескрипторы лог-файлов при их переоткрытии. > P.S. > > На том сервере процессор AMD EPYC 7502P 32-Core Processor > так что 32 worker-процесса nginx вполне должно быть достаточно, > по количеству физических ядер и без правки LimitNOFILE для мастера. > > Но при настройке worker_processes auto; глюки есть уже сейчас, > потому что в auto считаются виртуальные а не физические ядра. > > Со стороны nginx этот глюк никак нельзя обойти/устранить, > чтобы все работало при настройке worker_processes auto; > без ручной правки LimitNOFILE через systemctl edit nginx > на сервере с процессором AMD EPYC 7502P 32-Core Processor? В данном конкретном случае наиболее правильным решением, наверное, будет переработка инфраструктуры каналов и, видимо, устранение возможности прямого общения между рабочими процессами - эта функциональность всё равно сейчас не используется, и в то же время приводит к тому, что одновременно может отправляться много файловых дескрипторов (в каждый рабочий процесс отправляются дескрипторы для общения с каждым рабочим процессом, то есть всего дескрипторов - количество рабочих процессов в квадрате). Но вообще настройка "worker_processes auto;" не является настройкой по умолчанию именно потому, что на серверах с большим количеством ядер/потоков может потребовать большого количества различных ресурсов, и применять её без соответствующего тюнинга системных ограничений - не очень хорошая идея. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Thu Jun 25 16:32:07 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 25 Jun 2020 19:32:07 +0300 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: References: <96df6d8a-8232-31cb-747d-a6cd41bfe7ea@csdoc.com> <20200625142341.GK12747@mdounin.ru> <4ac55d3c-3e41-6fdc-50c7-850ac7f09d93@csdoc.com> Message-ID: <20200625163207.GO12747@mdounin.ru> Hello! On Thu, Jun 25, 2020 at 08:13:06PM +0500, Илья Шипицин wrote: > чт, 25 июн. 2020 г. в 19:59, Gena Makhomed : > > > On 25.06.2020 17:23, Maxim Dounin wrote: > > > > >>> в этом месте вы думаете, что воркер сам себе проставил такой лимит на > > >>> количество файлов. > > >> > > >>> посмотрите в /proc//limits , действительно ли там значения, > > которые вы > > >>> ожидаете или нет > > >>> у нас было, что systemd применял свои лимиты поверх > > >> > > >> # cat /proc/205/cmdline > > >> nginx: worker process > > >> > > >> # grep "Max open files" /proc/205/limits > > >> Max open files 262144 262144 files > > > > > > А у master-процесса что? > > > > # cat /proc/182/cmdline > > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > > > > # grep "Max open files" /proc/182/limits > > Max open files 1024 262144 files > > > > С помощью директив конфига nginx, насколько я понимаю, > > 1024 нельзя увеличить до какого-нибудь большего значения. > > > > с помощью systemctl edit nginx сделал > > > > /etc/systemd/system/nginx.service.d/override.conf > > > > [Service] > > LimitNOFILE=infinity > > > > так что теперь, после перезапуска у мастера такие параметры: > > > > # cat /proc/690/cmdline > > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > > > > # grep "Max open files" /proc/690/limits > > Max open files 262144 262144 files > > > > И nginx теперь нормально запускается даже при worker_processes 128; > > > > Спасибо! > > > > > Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает, > > > что количество одновременно отправляемых файловых дескрипторов > > > превышает лимит на количество дескрипторов в отправляющем > > > процессе, в данном случае - в мастере, ибо никто больше файловые > > > дескрипторы с помощью sendmsg() не шлёт. > > > > > Ну и отвечая на исходный вопрос про "насколько критична эта > > > ошибка": приведённая ошибка как минимум означает, что система > > > общения между мастером и рабочими процессами больше не работает. > > > То есть отвечать на запросы nginx будет, а скажем reload сделать - > > > уже нормально не сможет. То есть приблизительно как и со всеми > > > ошибками уровня alert: "что-то развалилось и непредсказуемо > > > глючит, сделайте что-нибудь". > > > > Если я правильно понял Ваш ответ - nginx шлет файловые дескрипторы > > из мастера в воркеры только в процессе старта и в процессе релоада, > > то есть, эта ошибка > > > > насколько я помню, в принципе разная работа с дескрипторами может быть, > например, если логи открыты в буферизированном варианте. В данном случае речь не про открытые файловые дескрипторы, а про дескрипторы, одновременно отправляемые через unix-сокеты с помощью системного вызова sendmsg(). Там тоже применяется NOFILE-лимит, но счётчик при этом совершенно отдельный. > (если небуферизированные, то воркер открывает, записывает и закрывает. если > буферизированные, то дескриптор хранится в мастере) Нет. Паттерн "воркер открывает, записывает и закрывает" применяется только для access-логов с переменными в имени. В остальных случаях - то есть когда переменных в имени лога нет - лог-файл открывается мастером и остаётся открытым всегда, от настроек буферизации это не зависит. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Jun 25 18:23:35 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 25 Jun 2020 21:23:35 +0300 Subject: ssl_protocols Message-ID: Максим, а почему такое значение по-умолчанию у директивы ssl_protocols? В частности, протокол TLSv1.3 выключен, но вместо него включены протоколы TLSv1 и TLSv1.1 - сейчас ведь наоборот рекомендуют делать. Даже RFC вышел соответствующий еще в мае 2015 года, https://tools.ietf.org/html/rfc7525#section-3.1.1 И такие же настройки рекомендуются https://ssl-config.mozilla.org/ Почему бы не сделать ssl_protocols TLSv1.2 TLSv1.3; значением по-умолчанию в nginx? -- Best regards, Gena From mdounin на mdounin.ru Thu Jun 25 19:27:07 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 25 Jun 2020 22:27:07 +0300 Subject: ssl_protocols In-Reply-To: References: Message-ID: <20200625192707.GT12747@mdounin.ru> Hello! On Thu, Jun 25, 2020 at 09:23:35PM +0300, Gena Makhomed wrote: > Максим, а почему такое значение по-умолчанию у директивы ssl_protocols? > > В частности, протокол TLSv1.3 выключен, но вместо него включены > протоколы TLSv1 и TLSv1.1 - сейчас ведь наоборот рекомендуют делать. > > Даже RFC вышел соответствующий еще в мае 2015 года, > https://tools.ietf.org/html/rfc7525#section-3.1.1 Just in case, по ссылке для TLSv1.0 и TLSv1.1 чётко сказано: "the only exception is when no higher version is available in the negotiation". Именно так nginx и работает по умолчанию. > И такие же настройки рекомендуются https://ssl-config.mozilla.org/ > > Почему бы не сделать ssl_protocols TLSv1.2 TLSv1.3; значением по-умолчанию в nginx? Тут, на самом деле, два вопроса: 1. А не запретить ли TLSv1.0 и TLSv1.1 по умолчанию. Мне это пока кажется плохой идеей, ибо клиентов, не умеющих TLSv1.2 всё ещё много. Подробный ответ тут: https://trac.nginx.org/nginx/ticket/1911#comment:2 2. А не разрешить ли TLSv1.3 по умолчанию. Сейчас для этого как минимум один блокер - в TLSv1.3 не настраиваются шифры и в результате сломаются конфиги с "ssl_ciphers aNULL;", подробнее тут: http://mailman.nginx.org/pipermail/nginx/2018-November/057194.html -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Jun 25 19:52:47 2020 From: nginx-forum на forum.nginx.org (edo1) Date: Thu, 25 Jun 2020 15:52:47 -0400 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUg0Lgg0LLRi9GB0L7QutC40LUg0YHQutC+0YDQvtGB0YI=?= =?UTF-8?B?0Lg=?= In-Reply-To: <20200622102558.GB12747@mdounin.ru> References: <20200622102558.GB12747@mdounin.ru> Message-ID: <2902f8e40503cb199967e65275a5798c.NginxMailingListRussian@forum.nginx.org> > https://trac.nginx.org/nginx/ticket/1678#comment:1 читал > Подкрутить можно размеры буферов и/или включить sendfile, размеры крутил (без них было сильно хуже), sendfile тоже пробовал включать (точнее отключать aio). с "output_buffers 2 10m" получается около 80Мб/с, но 20Мб на клиента как-то перебор (и опять же это не ровно 100, как в указано через limit_rate) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288429,288466#msg-288466 From nginx-forum на forum.nginx.org Thu Jun 25 20:04:55 2020 From: nginx-forum на forum.nginx.org (edo1) Date: Thu, 25 Jun 2020 16:04:55 -0400 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: <20200625160830.GN12747@mdounin.ru> References: <20200625160830.GN12747@mdounin.ru> Message-ID: <66acafc24da57cafa5712dd13568d6f8.NginxMailingListRussian@forum.nginx.org> BTW, а как работает worker_cpu_affinity auto если воркеров меньше, чем ядер? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288449,288467#msg-288467 From mdounin на mdounin.ru Thu Jun 25 22:19:21 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 26 Jun 2020 01:19:21 +0300 Subject: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice) In-Reply-To: <66acafc24da57cafa5712dd13568d6f8.NginxMailingListRussian@forum.nginx.org> References: <20200625160830.GN12747@mdounin.ru> <66acafc24da57cafa5712dd13568d6f8.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200625221921.GU12747@mdounin.ru> Hello! On Thu, Jun 25, 2020 at 04:04:55PM -0400, edo1 wrote: > BTW, а как работает worker_cpu_affinity auto если воркеров меньше, чем > ядер? Воркеры будут привязаны к первым ядрам, лишние ядра - останутся свободными. Если нужно, чтобы остались свободными другие ядра - это можно сделать с помощью дополнительной маски. -- Maxim Dounin http://mdounin.ru/ From zend.karabanov на gmail.com Fri Jun 26 12:40:33 2020 From: zend.karabanov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LDRgNCw0LHQsNC90L7Qsg==?=) Date: Fri, 26 Jun 2020 15:40:33 +0300 Subject: =?UTF-8?B?0JrQsNC6INC+0LHRgNCw0LHQvtGC0LDRgtGMINGA0LXQtNC40YDQtdC60YIg0Lgg?= =?UTF-8?B?0L/RgNC+0LrRgdC40YDQvtCy0LDRgtGMINGA0LXQt9GD0LvRjNGC0LDRgiA=?= =?UTF-8?B?0L/RgNC40LvQvtC20LXQvdC40Y4/?= Message-ID: Здравствуйте. Приложению запрещено самостоятельно открывать соединения с внешним миром. Приложение отправляет запрос на proxykipalive.lan, а Nginx проксирует этот запрос на целевой хост (это сделано, чтобы переиспользовать соединение за счёт keepalive и не открывать новое соединение на каждый запрос от приложения). Возникла ситуация, когда целевой хост стал отвечать 301 редиректом, естественно приложение, получив вместо ожидаемого контента, 301 редирект сломалось. Есть ли способ заставить Nginx обработать редирект самостоятельно и отдать приложению готовый контент? -- С уважением, Александр Карабанов ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Jun 26 12:57:01 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 26 Jun 2020 17:57:01 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtCx0YDQsNCx0L7RgtCw0YLRjCDRgNC10LTQuNGA0LXQutGC?= =?UTF-8?B?INC4INC/0YDQvtC60YHQuNGA0L7QstCw0YLRjCDRgNC10LfRg9C70YzRgtCw?= =?UTF-8?B?0YIg0L/RgNC40LvQvtC20LXQvdC40Y4/?= In-Reply-To: References: Message-ID: это не во всех случаях можно сделать корректно. например, 301 по RFC можно отвечать только на GET. а если сервер ответил 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или GET ? вот именно этот выбор и доносится до клиента, когда 301 транслируется один в один. теоретически, вы можете накостылить обработчик 301-ошибки, назначить его на локейшен, и в локейшене сделать proxy_pass но это очень скользкая дорожка пт, 26 июн. 2020 г. в 17:41, Александр Карабанов : > Здравствуйте. > > Приложению запрещено самостоятельно открывать соединения с внешним миром. > Приложение отправляет запрос на proxykipalive.lan, а Nginx проксирует этот > запрос на целевой хост (это сделано, чтобы переиспользовать соединение за > счёт keepalive и не открывать новое соединение на каждый запрос от > приложения). > Возникла ситуация, когда целевой хост стал отвечать 301 редиректом, > естественно приложение, получив вместо ожидаемого контента, 301 редирект > сломалось. > Есть ли способ заставить Nginx обработать редирект самостоятельно и отдать > приложению готовый контент? > -- > С уважением, > Александр Карабанов > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Jun 26 16:31:52 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 26 Jun 2020 19:31:52 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUg0Lgg0LLRi9GB0L7QutC40LUg0YHQutC+0YDQvtGB0YI=?= =?UTF-8?B?0Lg=?= In-Reply-To: <2902f8e40503cb199967e65275a5798c.NginxMailingListRussian@forum.nginx.org> References: <20200622102558.GB12747@mdounin.ru> <2902f8e40503cb199967e65275a5798c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200626163152.GW12747@mdounin.ru> Hello! On Thu, Jun 25, 2020 at 03:52:47PM -0400, edo1 wrote: > > https://trac.nginx.org/nginx/ticket/1678#comment:1 > > читал > > > Подкрутить можно размеры буферов и/или включить sendfile, > > размеры крутил (без них было сильно хуже), sendfile тоже пробовал включать > (точнее отключать aio). > > с "output_buffers 2 10m" получается около 80Мб/с, но 20Мб на клиента как-то > перебор (и опять же это не ровно 100, как в указано через limit_rate) Ну так и гигабит на клиента - это немало. Там достаточно простой алгоритм, для ограничения мгновенной скорости считающий время, положенное на отправку конкретного набора буферов. И если погрешности вычислений велики - результат оказывается, скажем так, не идеальным. При скорости в 100 мегабайт в секунду - характерным размером будет 102 килобайта, объём данных, отправляемый за 1 миллисекунду. Суммарный размер буферов меньше - мгновенная скорость ограничиваться не будет. А если больше - то будет, и при типичном значении CONFIG_HZ=250 задержки в 1 миллисекунду будут превращаться в 4 миллисекунды, то есть скорость имеет все шансы оказаться в четыре раза меньше заданной (а если CONFIG_HZ вдруг меньше, как в тикете по ссылке - то будет и того хуже). Погрешность процентов в 10 получим где-то ближе к 4 мегабайтам буферов суммарно, но тут уже скорее всего будут другие ограничивающие факторы - как то особенности шедулинга, размеры буферов сокетов и другие задержки в ходе обработки. Пытаться с этим бороться и напрограммировать алгоритм, не подверженный ошибкам при "плохих" размерах буферов - можно, но смысла в этом не очень много, так как для ограничений в гигабиты limit_rate обычно не используют, AFAIK. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Sun Jun 28 18:26:46 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 28 Jun 2020 21:26:46 +0300 Subject: ssl_protocols In-Reply-To: <20200625192707.GT12747@mdounin.ru> References: <20200625192707.GT12747@mdounin.ru> Message-ID: On 25.06.2020 22:27, Maxim Dounin wrote: > А не разрешить ли TLSv1.3 по умолчанию. Сейчас для этого как > минимум один блокер - в TLSv1.3 не настраиваются шифры и в > результате сломаются конфиги с "ssl_ciphers aNULL;", подробнее > тут: > > http://mailman.nginx.org/pipermail/nginx/2018-November/057194.html В ответе https://trac.nginx.org/nginx/ticket/195#comment:6 можно же дописать, что этот workaround не работает для протокола TLSv1.3, потому что протокол TLSv1.3 вообще не поддерживает ssl_ciphers aNULL; Хотя, в этом тикете https://trac.nginx.org/nginx/ticket/195 просили совсем о другом - просили сделать возможность refuse_connections в том случае, если приходит HTTPS-запрос в nginx на HTTP-only сайт, то есть просят сделать "strict SNI should really be implemented. It's just a few if statements, is this too much for a long-standing issue?" Не смотря на то, что этот тикет был создан 8 лет тому назад - такая проблема актуальна и сегодня, потому что, насколько мне известно, Google индексирует сайты по HTTPS не обращая внимания на ошибки несоответствия сертификата. В резхультате в его поисковой выдаче будет очень много страниц, которые дают ошибку TLS/SSL в браузере. > в TLSv1.3 не настраиваются шифры И если быть уж совсем точным, шифры в TLSv1.3 настраиваются. Точнее в OpenSSL шифры для TLSv1.3 можно настроить. Проблема только в том, что вот разработчики nginx не могут договориться с разработчиками OpenSSL о том, как эти шифры необходимо настраивать. В том же Apache можно без проблем настроить шифры для TLSv1.3: https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite Если никак не получается договориться с разработчиками OpenSSL, может быть имеет сделать смысл форк OpenSSL иил написать с нуля свою собственную библиотеку? Ведь когда-то так и nginx появился, когда стало понятно, что apache не подходит для некоторых задач. Или пойти по пути Apache, сделав возможность раздельной настройки шифров для TLSv1.2 и для TLSv1.3 ? Ведь по прошествии такого количества времени уже стало понятно, что разработчики OpenSSL свою точку зрения по этому вопросу менять не собираются и в OpenSSL все будет так же. -- Best regards, Gena From gmm на csdoc.com Sun Jun 28 18:46:14 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 28 Jun 2020 21:46:14 +0300 Subject: proxy_ssl_server_name Message-ID: Максим, а зачем по-умолчанию сделано proxy_ssl_server_name off; ? Что-то сломается, если сделать по-умолчанию proxy_ssl_server_name on; ? Применил на одном из серверов workaround https://trac.nginx.org/nginx/ticket/195#comment:6 В результате - один из сервисов защиты от DDoS прислал уведомление, что сайт не работает, потому что у них, по всей видимости в конфиге все настроено по-умолчанию proxy_ssl_server_name off; и это стало причиной проблем. Подробнее об этом написано в том же 195 тикете: https://trac.nginx.org/nginx/ticket/195#comment:11 -- Best regards, Gena From zend.karabanov на gmail.com Mon Jun 29 07:03:20 2020 From: zend.karabanov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LDRgNCw0LHQsNC90L7Qsg==?=) Date: Mon, 29 Jun 2020 10:03:20 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtCx0YDQsNCx0L7RgtCw0YLRjCDRgNC10LTQuNGA0LXQutGC?= =?UTF-8?B?INC4INC/0YDQvtC60YHQuNGA0L7QstCw0YLRjCDRgNC10LfRg9C70YzRgtCw?= =?UTF-8?B?0YIg0L/RgNC40LvQvtC20LXQvdC40Y4/?= In-Reply-To: References: Message-ID: Вот такое решение нашёл: https://serverfault.com/questions/423265/how-to-follow-http-redirects-inside-nginx server { ... location / { proxy_pass http://backend; # You may need to uncomment the following line if your redirects are relative, e.g. /foo/bar #proxy_redirect / /; proxy_intercept_errors on; error_page 301 302 307 = @handle_redirect; } location @handle_redirect { set $saved_redirect_location '$upstream_http_location'; proxy_pass $saved_redirect_location; }} пт, 26 июн. 2020 г. в 15:57, Илья Шипицин : > это не во всех случаях можно сделать корректно. > > например, 301 по RFC можно отвечать только на GET. а если сервер ответил > 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или > GET ? > вот именно этот выбор и доносится до клиента, когда 301 транслируется один > в один. > > теоретически, вы можете накостылить обработчик 301-ошибки, назначить его > на локейшен, и в локейшене сделать proxy_pass > но это очень скользкая дорожка > > пт, 26 июн. 2020 г. в 17:41, Александр Карабанов >: > >> Здравствуйте. >> >> Приложению запрещено самостоятельно открывать соединения с внешним миром. >> Приложение отправляет запрос на proxykipalive.lan, а Nginx проксирует этот >> запрос на целевой хост (это сделано, чтобы переиспользовать соединение за >> счёт keepalive и не открывать новое соединение на каждый запрос от >> приложения). >> Возникла ситуация, когда целевой хост стал отвечать 301 редиректом, >> естественно приложение, получив вместо ожидаемого контента, 301 редирект >> сломалось. >> Есть ли способ заставить Nginx обработать редирект самостоятельно и >> отдать приложению готовый контент? >> -- >> С уважением, >> Александр Карабанов >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Александр Карабанов ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Jun 29 07:48:10 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 29 Jun 2020 12:48:10 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtCx0YDQsNCx0L7RgtCw0YLRjCDRgNC10LTQuNGA0LXQutGC?= =?UTF-8?B?INC4INC/0YDQvtC60YHQuNGA0L7QstCw0YLRjCDRgNC10LfRg9C70YzRgtCw?= =?UTF-8?B?0YIg0L/RgNC40LvQvtC20LXQvdC40Y4/?= In-Reply-To: References: Message-ID: я примерно такое имел в виду. а вот расскажите, как будет работать, если на POST запрос будет 301, вы в @handle_redirect отправите тоже POST ? пн, 29 июн. 2020 г. в 12:03, Александр Карабанов : > Вот такое решение нашёл: > > https://serverfault.com/questions/423265/how-to-follow-http-redirects-inside-nginx > > server { > ... > > location / { > proxy_pass http://backend; > # You may need to uncomment the following line if your redirects are relative, e.g. /foo/bar #proxy_redirect / /; proxy_intercept_errors on; > error_page 301 302 307 = @handle_redirect; > } > > location @handle_redirect { > set $saved_redirect_location '$upstream_http_location'; > proxy_pass $saved_redirect_location; > }} > > > пт, 26 июн. 2020 г. в 15:57, Илья Шипицин : > >> это не во всех случаях можно сделать корректно. >> >> например, 301 по RFC можно отвечать только на GET. а если сервер ответил >> 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или >> GET ? >> вот именно этот выбор и доносится до клиента, когда 301 транслируется >> один в один. >> >> теоретически, вы можете накостылить обработчик 301-ошибки, назначить его >> на локейшен, и в локейшене сделать proxy_pass >> но это очень скользкая дорожка >> >> пт, 26 июн. 2020 г. в 17:41, Александр Карабанов < >> zend.karabanov на gmail.com>: >> >>> Здравствуйте. >>> >>> Приложению запрещено самостоятельно открывать соединения с внешним >>> миром. Приложение отправляет запрос на proxykipalive.lan, а Nginx >>> проксирует этот запрос на целевой хост (это сделано, чтобы переиспользовать >>> соединение за счёт keepalive и не открывать новое соединение на каждый >>> запрос от приложения). >>> Возникла ситуация, когда целевой хост стал отвечать 301 редиректом, >>> естественно приложение, получив вместо ожидаемого контента, 301 редирект >>> сломалось. >>> Есть ли способ заставить Nginx обработать редирект самостоятельно и >>> отдать приложению готовый контент? >>> -- >>> С уважением, >>> Александр Карабанов >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > С уважением, > Александр Карабанов > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Jun 29 14:07:56 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Jun 2020 17:07:56 +0300 Subject: ssl_protocols In-Reply-To: References: <20200625192707.GT12747@mdounin.ru> Message-ID: <20200629140756.GZ12747@mdounin.ru> Hello! On Sun, Jun 28, 2020 at 09:26:46PM +0300, Gena Makhomed wrote: > On 25.06.2020 22:27, Maxim Dounin wrote: > > > А не разрешить ли TLSv1.3 по умолчанию. Сейчас для этого как > > минимум один блокер - в TLSv1.3 не настраиваются шифры и в > > результате сломаются конфиги с "ssl_ciphers aNULL;", подробнее > > тут: > > > > http://mailman.nginx.org/pipermail/nginx/2018-November/057194.html > > В ответе https://trac.nginx.org/nginx/ticket/195#comment:6 можно > же дописать, что этот workaround не работает для протокола TLSv1.3, > потому что протокол TLSv1.3 вообще не поддерживает ssl_ciphers aNULL; > > Хотя, в этом тикете https://trac.nginx.org/nginx/ticket/195 просили > совсем о другом - просили сделать возможность refuse_connections > в том случае, если приходит HTTPS-запрос в nginx на HTTP-only сайт, > то есть просят сделать "strict SNI should really be implemented. It's just a few if statements, is this too much for a long-standing issue?" > > Не смотря на то, что этот тикет был создан 8 лет тому назад - такая > проблема актуальна и сегодня, потому что, насколько мне известно, > Google индексирует сайты по HTTPS не обращая внимания на ошибки > несоответствия сертификата. В резхультате в его поисковой выдаче > будет очень много страниц, которые дают ошибку TLS/SSL в браузере. Проблем с гуглом при использовании "ssl_ciphers aNULL; return 444;" - не обнаружено, да и быть не может: соединение так или иначе закрывается, даже если гугл вдруг готов общаться по шифрам aNULL. Семантически эта конструкция делает именно то, что нужно: отказывается общаться, не предъявляя сертификата. То есть в отсутствии TLSv1.3 этот workaround работает именно так, как надо. Включение TLSv1.3 - его ломает. Соответственно для включения TLSv1.3 по умолчанию надо решить две проблемы: 1. Сделать решение, которое бы позволило реализовать ту же семантику "отазаться общаться, не предъявляя сертификата" в условиях наличия TLSv1.3. 2. Придумать решение для существующих конфигураций с "ssl_ciphers aNULL; return 444;". > > в TLSv1.3 не настраиваются шифры > > И если быть уж совсем точным, шифры в TLSv1.3 настраиваются. > Точнее в OpenSSL шифры для TLSv1.3 можно настроить. Проблема > только в том, что вот разработчики nginx не могут договориться > с разработчиками OpenSSL о том, как эти шифры необходимо настраивать. > > В том же Apache можно без проблем настроить шифры для TLSv1.3: > https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite > > Если никак не получается договориться с разработчиками OpenSSL, > может быть имеет сделать смысл форк OpenSSL иил написать с нуля > свою собственную библиотеку? Ведь когда-то так и nginx появился, > когда стало понятно, что apache не подходит для некоторых задач. > > Или пойти по пути Apache, сделав возможность раздельной настройки > шифров для TLSv1.2 и для TLSv1.3 ? Ведь по прошествии такого количества > времени уже стало понятно, что разработчики OpenSSL свою точку зрения > по этому вопросу менять не собираются и в OpenSSL все будет так же. В тикете тут: https://trac.nginx.org/nginx/ticket/1529 и связанных тикетах - достаточно подробно расписано, что настраивается, что не настраивается (в BoringSSL, например, для TLSv1.3 не настраивается вообще ничего), и что именно я думаю по этому поводу. Не вижу смысла тут повторяться. Сама по себе невозможность насраивать шифры - не является препятствием для включения TLSv1.3 по умолчанию, препятствием являются возникающие в результае проблемы в конфигурациях с "ssl_ciphers aNULL;". -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Jun 29 15:00:12 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Jun 2020 18:00:12 +0300 Subject: proxy_ssl_server_name In-Reply-To: References: Message-ID: <20200629150012.GB12747@mdounin.ru> Hello! On Sun, Jun 28, 2020 at 09:46:14PM +0300, Gena Makhomed wrote: > Максим, а зачем по-умолчанию сделано proxy_ssl_server_name off; ? На то есть две причины: 1. Исторически nginx не умел SNI в соединениях с бэкендами. Когда поддержка была добавлена - поведение по умолчанию было оставлено "как есть", дабы не ломать существующие конфигурации, где это может оказаться важно. 2. Использование SNI означает передачу имени сервера открытым текстом, что в общем случае - утечка данных. Если мы хотим шифровать трафик с бэкендами - странно допускать подобную утечку по умолчанию. > Что-то сломается, если сделать по-умолчанию proxy_ssl_server_name on; ? Скорее всего нет, но может. > Применил на одном из серверов workaround > https://trac.nginx.org/nginx/ticket/195#comment:6 > > В результате - один из сервисов защиты от DDoS прислал уведомление, > что сайт не работает, потому что у них, по всей видимости в конфиге > все настроено по-умолчанию proxy_ssl_server_name off; и это стало > причиной проблем. Подробнее об этом написано в том же 195 тикете: > https://trac.nginx.org/nginx/ticket/195#comment:11 Если у вас среди клиентов есть те, кто не использует SNI - не надо запрещать соединения без SNI. Описанное в тикете решение с "ssl_ciphers aNULL;" совершенно не обязательно применять в сервере по умолчанию, а если всё-таки применять - то стоит понимать последствия. Что до "сервисов защиты", то почему они не используют SNI - это вопрос к ним, а не к настройкам по умолчанию nginx'а. Настройки по умолчанию расчитаны на работу с собственными бэкендами, и если там используется nginx - они так или иначе должны были много что менять. -- Maxim Dounin http://mdounin.ru/ From zend.karabanov на gmail.com Mon Jun 29 21:39:18 2020 From: zend.karabanov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LDRgNCw0LHQsNC90L7Qsg==?=) Date: Tue, 30 Jun 2020 00:39:18 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtCx0YDQsNCx0L7RgtCw0YLRjCDRgNC10LTQuNGA0LXQutGC?= =?UTF-8?B?INC4INC/0YDQvtC60YHQuNGA0L7QstCw0YLRjCDRgNC10LfRg9C70YzRgtCw?= =?UTF-8?B?0YIg0L/RgNC40LvQvtC20LXQvdC40Y4/?= In-Reply-To: References: Message-ID: Не проверял. GET работает, как ожидается. Для решения моей проблемы этого достаточно. пн, 29 июн. 2020 г. в 10:48, Илья Шипицин : > я примерно такое имел в виду. > > а вот расскажите, как будет работать, если на POST запрос будет 301, вы в > @handle_redirect отправите тоже POST ? > > пн, 29 июн. 2020 г. в 12:03, Александр Карабанов >: > >> Вот такое решение нашёл: >> >> https://serverfault.com/questions/423265/how-to-follow-http-redirects-inside-nginx >> >> server { >> ... >> >> location / { >> proxy_pass http://backend; >> # You may need to uncomment the following line if your redirects are relative, e.g. /foo/bar #proxy_redirect / /; proxy_intercept_errors on; >> error_page 301 302 307 = @handle_redirect; >> } >> >> location @handle_redirect { >> set $saved_redirect_location '$upstream_http_location'; >> proxy_pass $saved_redirect_location; >> }} >> >> >> пт, 26 июн. 2020 г. в 15:57, Илья Шипицин : >> >>> это не во всех случаях можно сделать корректно. >>> >>> например, 301 по RFC можно отвечать только на GET. а если сервер ответил >>> 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или >>> GET ? >>> вот именно этот выбор и доносится до клиента, когда 301 транслируется >>> один в один. >>> >>> теоретически, вы можете накостылить обработчик 301-ошибки, назначить его >>> на локейшен, и в локейшене сделать proxy_pass >>> но это очень скользкая дорожка >>> >>> пт, 26 июн. 2020 г. в 17:41, Александр Карабанов < >>> zend.karabanov на gmail.com>: >>> >>>> Здравствуйте. >>>> >>>> Приложению запрещено самостоятельно открывать соединения с внешним >>>> миром. Приложение отправляет запрос на proxykipalive.lan, а Nginx >>>> проксирует этот запрос на целевой хост (это сделано, чтобы переиспользовать >>>> соединение за счёт keepalive и не открывать новое соединение на каждый >>>> запрос от приложения). >>>> Возникла ситуация, когда целевой хост стал отвечать 301 редиректом, >>>> естественно приложение, получив вместо ожидаемого контента, 301 редирект >>>> сломалось. >>>> Есть ли способ заставить Nginx обработать редирект самостоятельно и >>>> отдать приложению готовый контент? >>>> -- >>>> С уважением, >>>> Александр Карабанов >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru на nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> -- >> С уважением, >> Александр Карабанов >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Александр Карабанов ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Jun 30 13:36:34 2020 From: nginx-forum на forum.nginx.org (nixxx) Date: Tue, 30 Jun 2020 09:36:34 -0400 Subject: =?UTF-8?B?0J3QsNGB0YLRgNC+0LnQutCwINGA0LXQstC10YDRgS3Qv9GA0L7QutGB0Lgg0LQ=?= =?UTF-8?B?0LvRjyDRgdCw0LnRgtCw?= Message-ID: <73cb2041ed29975081ef40790331ee34.NginxMailingListRussian@forum.nginx.org> настриваю обратный прокси для сайта https://www.on-running.com/, хочу сделать что-то типа зеркала. тренируюсь на локальной машине 192.168.56.103. сервер вечно шлет мне редиректы, когда я пытаюсь зайти на сайт. в чем может быть проблема? Вот конфиг сервера: server { listen 80; location / { proxy_pass https://on-running.com; proxy_set_header Host on-running.com; subs_filter "on-running.com" "192.168.56.103" gi; subs_filter "www.on-running.com" "192.168.56.103" gi; proxy_cookie_domain www.on-running.com 192.168.56.103; proxy_cookie_domain on-running.com 192.168.56.103; proxy_set_header Accept-Encoding ""; proxy_redirect https://on-running.com http://192.168.56.103; proxy_redirect https://www.on-running.com http://192.168.56.103; proxy_ssl_server_name on; } } Редиректы ~  curl http://192.168.56.103 -I HTTP/1.1 301 Moved Permanently Server: nginx/1.14.2 Date: Tue, 30 Jun 2020 13:31:33 GMT Connection: keep-alive Cache-Control: max-age=3600 Expires: Tue, 30 Jun 2020 14:31:33 GMT Location: http://192.168.56.103/ cf-request-id: 03a7060cb20000f2cce7b89200000001 Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" CF-RAY: 5ab83f8defeef2cc-WAW Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288500,288500#msg-288500