From simplebox66 на gmail.com Fri Aug 2 15:29:05 2019 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 2 Aug 2019 18:29:05 +0300 Subject: =?UTF-8?B?0J/QsNC00LDQtdGCIG5naW54INCyINGB0LvRg9GH0LDQtSDQuNGB0YLQtdGH0LU=?= =?UTF-8?B?0L3QuNGPINGB0YDQvtC60LAg0LTQtdC50YHRgtCy0LjRjyDRgdC10YDRgtC4?= =?UTF-8?B?0YTQuNC60LDRgtCw?= Message-ID: Добрый день. Есть множество хостов вида: > server { > listen 80; > server_name example.com; > location / { > proxy_ssl_session_reuse off; > proxy_ssl_certificate /etc/nginx/include/client/client.cer; > proxy_ssl_certificate_key > 'engine:gostengy:n6e6e829f94729896d0e38a814354dcdec4e456'; > proxy_ssl_ciphers > GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH; > proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > proxy_pass https://world.cnet; > proxy_set_header Host world.net; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > } > } В случае если у одного из хостов истекает срок действия сертификата, то отказывается работать nginx. Т.е. перестают работать абсолютно все вирт хосты. В логах ошибка вида: ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Fri Aug 2 15:36:06 2019 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 2 Aug 2019 18:36:06 +0300 Subject: =?UTF-8?B?UmU6INCf0LDQtNCw0LXRgiBuZ2lueCDQsiDRgdC70YPRh9Cw0LUg0LjRgdGC0LU=?= =?UTF-8?B?0YfQtdC90LjRjyDRgdGA0L7QutCwINC00LXQudGB0YLQstC40Y8g0YHQtdGA?= =?UTF-8?B?0YLQuNGE0LjQutCw0YLQsA==?= In-Reply-To: References: Message-ID: Добрый день. Есть множество хостов вида: > server { > listen 80; > server_name example.com; > location / { > proxy_ssl_session_reuse off; > proxy_ssl_certificate /etc/nginx/include/client/client.cer; > proxy_ssl_certificate_key > 'engine:gostengy:n6e6e829f94729896d0e38a814354dcdec4e456'; > proxy_ssl_ciphers > GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH; > proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > proxy_pass https://world.cnet; > proxy_set_header Host world.net; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > } > } В случае если у одного из хостов истекает срок действия сертификата, то отказывается работать nginx. Т.е. перестают работать абсолютно все вирт хосты. В логах ошибка вида: > [emerg] 2169#2169: > ENGINE_load_private_key("9867b5ab2b2c88342766gg5e99a6a7c6ddc7e324") failed > (SSL: error:80015033:lib(128):gng_support_getuserkey:GNG_ERR_LICENSE > error:26096080:engine routines:ENGINE_load_private_key:failed loading > private key) хеши сертов в примерах изменил на ненастоящие. Как сделать так чтобы nginx не ронял все хосты из-за того что на одном хосте просрочился серт? Может есть какая-то деректива специальная чтобы отключить например проверку срока годности сертификатов? пт, 2 авг. 2019 г. в 18:29, Иван Мишин : > Добрый день. Есть множество хостов вида: > >> server { >> listen 80; >> server_name example.com; >> location / { >> proxy_ssl_session_reuse off; >> proxy_ssl_certificate /etc/nginx/include/client/client.cer; >> proxy_ssl_certificate_key >> 'engine:gostengy:n6e6e829f94729896d0e38a814354dcdec4e456'; >> proxy_ssl_ciphers >> GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH; >> proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; >> proxy_pass https://world.cnet; >> proxy_set_header Host world.net; >> proxy_set_header X-Real-IP $remote_addr; >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> } >> } > > > В случае если у одного из хостов истекает срок действия сертификата, то > отказывается работать nginx. Т.е. перестают работать абсолютно все вирт > хосты. > В логах ошибка вида: > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Aug 2 18:46:24 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 2 Aug 2019 21:46:24 +0300 Subject: =?UTF-8?B?UmU6INCf0LDQtNCw0LXRgiBuZ2lueCDQsiDRgdC70YPRh9Cw0LUg0LjRgdGC0LU=?= =?UTF-8?B?0YfQtdC90LjRjyDRgdGA0L7QutCwINC00LXQudGB0YLQstC40Y8g0YHQtdGA?= =?UTF-8?B?0YLQuNGE0LjQutCw0YLQsA==?= In-Reply-To: References: Message-ID: <20190802184623.GR1877@mdounin.ru> Hello! On Fri, Aug 02, 2019 at 06:36:06PM +0300, Иван Мишин wrote: > Добрый день. Есть множество хостов вида: > > > server { > > listen 80; > > server_name example.com; > > location / { > > proxy_ssl_session_reuse off; > > proxy_ssl_certificate /etc/nginx/include/client/client.cer; > > proxy_ssl_certificate_key > > 'engine:gostengy:n6e6e829f94729896d0e38a814354dcdec4e456'; > > proxy_ssl_ciphers > > GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH; > > proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > > proxy_pass https://world.cnet; > > proxy_set_header Host world.net; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > } > > } > > > В случае если у одного из хостов истекает срок действия сертификата, то > отказывается работать nginx. Т.е. перестают работать абсолютно все вирт > хосты. > В логах ошибка вида: > > > [emerg] 2169#2169: > > ENGINE_load_private_key("9867b5ab2b2c88342766gg5e99a6a7c6ddc7e324") failed > > (SSL: error:80015033:lib(128):gng_support_getuserkey:GNG_ERR_LICENSE > > error:26096080:engine routines:ENGINE_load_private_key:failed loading > > private key) > > > хеши сертов в примерах изменил на ненастоящие. > > Как сделать так чтобы nginx не ронял все хосты из-за того что на одном > хосте просрочился серт? Может есть какая-то деректива специальная чтобы > отключить например проверку срока годности сертификатов? Судя по ошибке - nginx не падает, а отказывается запускаться из-за ошибки, которая возникает при загрузке сертификата . Если вы nginx при этом не останавливали зачем-то сами - всё продолжит работать. А вообще - вам к авторам engine'а, который вы используете для загрузки сертификатов, ошибка случается именно там. Если бы вместо ошибки был загружен-таки просроченный сертификат, как это происходит при загрузке сертификатов из файлов - проблемы бы вообще не было. Ну или просто переходите на файлы, и будет вам счастье. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Aug 5 16:14:49 2019 From: nginx-forum на forum.nginx.org (grey) Date: Mon, 05 Aug 2019 12:14:49 -0400 Subject: =?UTF-8?B?0JjQvdC+0LPQtNCwINCyINC70L7Qs9Cw0YUg0L/RgNC+0YHQutCw0LrQuNCy0LA=?= =?UTF-8?B?0LXRgiBTU0wgd3JpdGUoKSBmYWlsZWQ=?= Message-ID: <2156144001daba78f7ced0136e6af0ef.NginxMailingListRussian@forum.nginx.org> Приветствую всех. Прикрутил к одному сайту защищенный протокол. Не сразу заметил, что во время наплыва посетителей сайт стал сильно тормозить, а в логах появляется ошибка: 2019/08/05 17:32:57 [crit] 1832#2988: *131089 SSL_write() failed (10053: Программа на вашем хост-компьютере разорвала установленное подключение) while sending response to client, client: 5.18.*.*, server: ***.ru, request: "GET /logo.jpg HTTP/1.1", upstream: "http://127.0.0.1:81/logo.jpg", host: "www.***.ru" Версия nginx под Windows последняя 1.17.2. Сервер физический, но слабенький. Если отключить шифрование, то все летает. upstream: "http://127.0.0.1:81" - это Апач. Может не хватает ресурсов процессора на шифрование трафика или я где-то накосячил? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285121,285121#msg-285121 From nginx-forum на forum.nginx.org Wed Aug 7 05:56:43 2019 From: nginx-forum на forum.nginx.org (rvk) Date: Wed, 07 Aug 2019 01:56:43 -0400 Subject: =?UTF-8?B?0J3QtSDQv9C10YDQtdC00LDQtdGC0YHRjyBMYXN0IE1vZGlmaWVk?= Message-ID: <5e696b188871b0e07b9e224c16398700.NginxMailingListRussian@forum.nginx.org> Пытаюсь передавать из PHP заголовок Last Modified по времени изменения статьи В ответе сервера передается Last Modified но всегда с текущим временем. Это если делаю запрос на SSL версию сайта. Если запрашиваю обычную страницу, то возвращается Last Modified с, я так понимаю, с временем помещения страницы в кэш (в связи с чем подозреваю, что SSL страницы вообще не кешируются). Если кэширование выключить, то снова возвращается текущее время, но никак не то которое я устанавливаю в php с помощью функции header Рядом стоит тестовый сервер, без ssl без кэширования, все работает как должно. Как сделать, что бы сервер отдавал именно тот заголовок, который я установил в PHP? PHP стоит как модуль apache Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285137,285137#msg-285137 From nginx-forum на forum.nginx.org Wed Aug 7 07:27:39 2019 From: nginx-forum на forum.nginx.org (rvk) Date: Wed, 07 Aug 2019 03:27:39 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QtdGA0LXQtNCw0LXRgtGB0Y8gTGFzdCBNb2RpZmllZA==?= In-Reply-To: <5e696b188871b0e07b9e224c16398700.NginxMailingListRussian@forum.nginx.org> References: <5e696b188871b0e07b9e224c16398700.NginxMailingListRussian@forum.nginx.org> Message-ID: <6b6ebfd6b035807faacfa2096fe9d92c.NginxMailingListRussian@forum.nginx.org> Разобрался. Оказалось далеко в коде этот заголовок устанавливался на текущую дату. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285137,285139#msg-285139 From mdounin на mdounin.ru Wed Aug 7 13:12:08 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 7 Aug 2019 16:12:08 +0300 Subject: =?UTF-8?B?UmU6INCY0L3QvtCz0LTQsCDQsiDQu9C+0LPQsNGFINC/0YDQvtGB0LrQsNC60Lg=?= =?UTF-8?B?0LLQsNC10YIgU1NMIHdyaXRlKCkgZmFpbGVk?= In-Reply-To: <2156144001daba78f7ced0136e6af0ef.NginxMailingListRussian@forum.nginx.org> References: <2156144001daba78f7ced0136e6af0ef.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190807131207.GX1877@mdounin.ru> Hello! On Mon, Aug 05, 2019 at 12:14:49PM -0400, grey wrote: > Приветствую всех. > > > Прикрутил к одному сайту защищенный протокол. Не сразу заметил, что во время > наплыва посетителей сайт стал сильно тормозить, а в логах появляется > ошибка: > > 2019/08/05 17:32:57 [crit] 1832#2988: *131089 SSL_write() failed (10053: > Программа на вашем хост-компьютере разорвала установленное подключение) > while sending response to client, client: 5.18.*.*, server: ***.ru, request: > "GET /logo.jpg HTTP/1.1", upstream: "http://127.0.0.1:81/logo.jpg", host: > "www.***.ru" > > Версия nginx под Windows последняя 1.17.2. Сервер физический, но слабенький. > Если отключить шифрование, то все летает. > upstream: "http://127.0.0.1:81" - это Апач. Может не хватает ресурсов > процессора на шифрование трафика или я где-то накосячил? Если я правильно понимаю, такая ошибка может (и должна) возникать, если клиент закрывает соединение в процессе получения ответа. Уровень логгирования в данном случае завышен в случае SSL-соединений, так как SSL-код не учитывает особенности виндов. Какой-то такой патч должен проблему закрыть, снизив уровень логгирования до стандартного в подобных ситуациях: # HG changeset patch # User Maxim Dounin # Date 1565182777 -10800 # Wed Aug 07 15:59:37 2019 +0300 # Node ID 50a68c37eb3b399aca25ffa06527f263d1961e07 # Parent fcd92ad76b7bb04b46c4b8fdfe14b6065acadf7d SSL: lowered log level for WSAECONNABORTED errors on Windows. Winsock uses ECONNABORTED instead of ECONNRESET, for normal connections this is already handled since baad3036086e. Reported at http://mailman.nginx.org/pipermail/nginx-ru/2019-August/062363.html. diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c --- a/src/event/ngx_event_openssl.c +++ b/src/event/ngx_event_openssl.c @@ -2814,6 +2814,9 @@ ngx_ssl_connection_error(ngx_connection_ if (sslerr == SSL_ERROR_SYSCALL) { if (err == NGX_ECONNRESET +#if (NGX_WIN32) + || err == NGX_ECONNABORTED +#endif || err == NGX_EPIPE || err == NGX_ENOTCONN || err == NGX_ETIMEDOUT -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Aug 7 13:59:17 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Wed, 07 Aug 2019 09:59:17 -0400 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUsINCx0YPRhNC10YAsINC70LDQs9C4?= Message-ID: <3a5d76cf5be9fe02be324f9702e45042.NginxMailingListRussian@forum.nginx.org> Допустим если включено кеширование через proxy_cache, а также включено proxy_buffering (по умолчанию). Что происходит когда клиент запрашивает ресурс которого нет в кеше? Он сначала полностью скачивается из апстрима, кешируется, и только потом начинает отдаваться клиенту? И если таких уровней апстримов 2 или более, то лаг получения контента клиентом увеличивается грубо говоря в 2 или более раз? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285149#msg-285149 From nginx-forum на forum.nginx.org Wed Aug 7 14:09:02 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Wed, 07 Aug 2019 10:09:02 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1LCDQsdGD0YTQtdGALCDQu9Cw?= =?UTF-8?B?0LPQuA==?= In-Reply-To: <3a5d76cf5be9fe02be324f9702e45042.NginxMailingListRussian@forum.nginx.org> References: <3a5d76cf5be9fe02be324f9702e45042.NginxMailingListRussian@forum.nginx.org> Message-ID: <6dcf0d0d4c80991367d499741d1a1a0c.NginxMailingListRussian@forum.nginx.org> Меня вот это немного смутило: "When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. " http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering Получается когда buffering включен, то наоборот, контент читается полностью перед началом отдачи клиенту. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285150#msg-285150 From andrey на kopeyko.ru Wed Aug 7 16:43:51 2019 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 07 Aug 2019 19:43:51 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1LCDQsdGD0YTQtdGALCDQu9Cw?= =?UTF-8?B?0LPQuA==?= In-Reply-To: <6dcf0d0d4c80991367d499741d1a1a0c.NginxMailingListRussian@forum.nginx.org> References: <3a5d76cf5be9fe02be324f9702e45042.NginxMailingListRussian@forum.nginx.org> <6dcf0d0d4c80991367d499741d1a1a0c.NginxMailingListRussian@forum.nginx.org> Message-ID: <6ba881ce431da0d10b8c671c801bef7c@kopeyko.ru> rihad писал 2019-08-07 17:09: > Меня вот это немного смутило: > > "When buffering is disabled, the response is passed to a client > synchronously, immediately as it is received. nginx will not try to > read the > whole response from the proxied server. " > > http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering > > Получается когда buffering включен, то наоборот, контент читается > полностью > перед началом отдачи клиенту. Нет. Ответ начинает отдаваться клиенту сразу по получении его от бэкенда. Зачем ждать конца? Это 2 независимых процесса, работающих с максимально возможной скоростью * ответ от бэкенда вычитывается быстро * полученный от бэкенда ответ - передаётся клиенту по мере готовности клиента его принять. -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Wed Aug 7 16:56:18 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Wed, 07 Aug 2019 12:56:18 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1LCDQsdGD0YTQtdGALCDQu9Cw?= =?UTF-8?B?0LPQuA==?= In-Reply-To: <6ba881ce431da0d10b8c671c801bef7c@kopeyko.ru> References: <6ba881ce431da0d10b8c671c801bef7c@kopeyko.ru> Message-ID: Просто эта цитата в доках на английском говорит, что такое бывает при выключенном буферинге. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285153#msg-285153 From mdounin на mdounin.ru Wed Aug 7 17:48:19 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 7 Aug 2019 20:48:19 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1LCDQsdGD0YTQtdGALCDQu9Cw?= =?UTF-8?B?0LPQuA==?= In-Reply-To: References: <6ba881ce431da0d10b8c671c801bef7c@kopeyko.ru> Message-ID: <20190807174818.GY1877@mdounin.ru> Hello! On Wed, Aug 07, 2019 at 12:56:18PM -0400, rihad wrote: > Просто эта цитата в доках на английском говорит, что такое бывает при > выключенном буферинге. Приведённая цитата говорит, что бывает при _выключенной_ буферизации. Что бывает при включённой - написано в предыдущем абзаце. Принципиальный момент, на самом деле, приблизительно один: - В случае выключенной буферизации отправка будет происходить сразу после получения данных от бэкенда. Включая сброс буферов всяких других уровней, как то gzip или SSL. Если же буферизация включена - nginx будет ждать заполнения очередного буфера, и только после его заполнения будет пытаться отправить его содержимое клиенту. Поэтому буферизированное проксирование эффективнее, но может быть непригодно, если HTTP-ответы используются для потоковой отправки данных с небольшой скоростью (и тогда буферизацию имеет смысл отключать). Кроме того, стоит помнить, что: - В случае выключенной буферизации nginx не будет пытаться прочитать целиком ответ от бэкенда, а вместо этого прекратит чтение, как только у него закончится буфер и не будет возможности отправить содержимое этого буфера клиенту. В случае со включённой буферизацией - похожего поведения можно добиться, установив proxy_max_temp_file_size в 0 (с точностью до того, что при этом будет используется не один буфер, а много). - При выключенной буферизации невозможно сохранения ответа на диск, и соответственно не будет работать кэширование и proxy_store. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Aug 7 18:07:57 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Wed, 07 Aug 2019 14:07:57 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1LCDQsdGD0YTQtdGALCDQu9Cw?= =?UTF-8?B?0LPQuA==?= In-Reply-To: <20190807174818.GY1877@mdounin.ru> References: <20190807174818.GY1877@mdounin.ru> Message-ID: <641f43ba9d30b63cc9cadf0172989bb1.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ. Буферизация конечно включена, мне просто показалось что желаемое поведение (одновременный прием от апстрима и отправка клиенту) происходит только при выключенной буферизации. Размер буфера в несколько десятков кб роли не играет, это почти одновременно. У нас в основном картинки по несколько сот кб. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285155#msg-285155 From public-mail на alekciy.ru Thu Aug 8 07:17:17 2019 From: public-mail на alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Thu, 8 Aug 2019 11:17:17 +0400 Subject: =?UTF-8?B?ItCf0YDQuNC00LXRgNC20LDRgtGMIiDRgdC+0LXQtNC40L3QtdC90LjRjyDQvdCw?= =?UTF-8?B?INCy0YDQtdC80Y8=?= Message-ID: Есть ли возможность при недоступности бэка (временной, буквально на пару секунд) на клиент не отдавать сразу '502 Bad Gateway', а повторить попытку через Х секунд удерживаю при этом коннект с клиентом? Я так понимаю из коробки такой возможности нет, но может это можно сделать через lua/nginJs? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgx на protva.ru Thu Aug 8 07:59:16 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 8 Aug 2019 10:59:16 +0300 Subject: =?UTF-8?B?UmU6ICLQn9GA0LjQtNC10YDQttCw0YLRjCIg0YHQvtC10LTQuNC90LXQvdC40Y8g?= =?UTF-8?B?0L3QsCDQstGA0LXQvNGP?= In-Reply-To: References: Message-ID: <20190808075916.GB3068@protva.ru> On Thu, Aug 08, 2019 at 11:17:17AM +0400, Алексей Сундуков wrote: > Есть ли возможность при недоступности бэка (временной, буквально на пару > секунд) на клиент не отдавать сразу '502 Bad Gateway', а повторить попытку > через Х секунд удерживаю при этом коннект с клиентом? Какой именно недоступности? Если бэкенд не отвечает, то ядро ОС продолжает ретрасмиссии, до таймаута. Увеличьте таймаут. Если бэкенд отвечает RST, потому что сервис на нём не запущен, то подумайте, как правильно поднимать сервис, чтобы такого не было. Если же он отвечает RST из-за перегрузки (переполнение backlog'a), лучше всего выбросить винду с её кривой сетью и поставить бэкенд на юникс. В крайнем случае можно просто зарубить все RST от виндового сервиса пакетным фильтром, тогда обрывы коннекций превратятся в таймауты. > Я так понимаю из коробки такой возможности нет, но может это можно сделать > через lua/nginJs? -- Eugene Berdnikov From chipitsine на gmail.com Thu Aug 8 08:08:02 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 8 Aug 2019 13:08:02 +0500 Subject: =?UTF-8?B?UmU6ICLQn9GA0LjQtNC10YDQttCw0YLRjCIg0YHQvtC10LTQuNC90LXQvdC40Y8g?= =?UTF-8?B?0L3QsCDQstGA0LXQvNGP?= In-Reply-To: References: Message-ID: видимо, речь идет про https://nginx.org/ru/docs/http/ngx_http_upstream_module.html#queue аналогичный механизм есть в haproxy https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4.2-maxconn чт, 8 авг. 2019 г. в 12:17, Алексей Сундуков : > Есть ли возможность при недоступности бэка (временной, буквально на пару > секунд) на клиент не отдавать сразу '502 Bad Gateway', а повторить попытку > через Х секунд удерживаю при этом коннект с клиентом? > > Я так понимаю из коробки такой возможности нет, но может это можно сделать > через lua/nginJs? > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Aug 11 07:04:21 2019 From: nginx-forum на forum.nginx.org (mmmisha) Date: Sun, 11 Aug 2019 03:04:21 -0400 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90L7RgdGC0Ywg0L/RgNC4INC+0LHQvdC+0LLQu9C10L3QuNC4?= =?UTF-8?B?INGBIERlYmlhbiA5INC00L4gRGViaWFuIDEw?= Message-ID: <5b4287b651e6581808381a14a18e252e.NginxMailingListRussian@forum.nginx.org> При обновлении с Debian 9 Stretch до Debian 10 Buster nginx с официального репозитория (http://nginx.org/packages/mainline/debian/) не обновляется Суть проблемы в том, что при стандартном обновлении системы (замена "stretch" на "buster" в sources.list, затем apt update, apt upgrade, apt dist-upgrage) пакет nginx остаётся на версии для stretch sources.list # nginx mainline # http://nginx.org/ru/linux_packages.html deb http://nginx.org/packages/mainline/debian/ buster nginx deb-src http://nginx.org/packages/mainline/debian/ buster nginx Все действия ниже делались на уже полностью обновлённой системе cat /etc/*release* PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" uname -a Linux fanat1k.ru 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 GNU/Linux aptitude show nginx Package: nginx Version: 1.17.2-1~stretch State: installed Automatically installed: no Priority: optional Section: httpd Maintainer: Sergey Budnevitch apt reinstall nginx Reading package lists... Done Building dependency tree Reading state information... Done Reinstallation of nginx is not possible, it cannot be downloaded. 0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded. aptitude update W: Package nginx had been marked to reinstall, but the file for the current installed version 1.17.2-1~stretch is not available Hit http://mirror.timeweb.ru/mariadb/repo/10.4/debian buster InRelease Hit http://security.debian.org buster/updates InRelease Hit http://ftp.ru.debian.org/debian buster InRelease Hit http://ftp.ru.debian.org/debian buster-backports InRelease Hit http://ftp.ru.debian.org/debian buster-updates InRelease Hit http://nginx.org/packages/mainline/debian buster InRelease Hit https://packages.sury.org/php buster InRelease aptitude install nginx nginx is already installed at the requested version (1.17.2-1~stretch) nginx is already installed at the requested version (1.17.2-1~stretch) No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. И помогло лишь aptitude install nginx-module-image-filter The following NEW packages will be installed: nginx-module-image-filter{b} 0 packages upgraded, 1 newly installed, 0 to remove and 3 not upgraded. Need to get 80.1 kB of archives. After unpacking 133 kB will be used. The following packages have unmet dependencies: nginx-module-image-filter : Depends: nginx (= 1.17.2-1~buster) but 1.17.2-1~stretch is installed The following actions will resolve these dependencies: Keep the following packages at their current version: 1) nginx-module-image-filter [Not Installed] Accept this solution? [Y/n/q/?] n The following actions will resolve these dependencies: Downgrade the following packages: 1) nginx [1.17.2-1~stretch (now) -> 1.17.2-1~buster (stable)] 2) nginx-module-geoip [1.17.2-1~stretch (now) -> 1.17.2-1~buster (stable)] Accept this solution? [Y/n/q/?] Y The following packages will be DOWNGRADED: nginx nginx-module-geoip The following NEW packages will be installed: nginx-module-image-filter 0 packages upgraded, 1 newly installed, 2 downgraded, 0 to remove and 3 not upgraded. Need to get 1,008 kB of archives. After unpacking 150 kB will be used. Do you want to continue? [Y/n/?] Get: 1 http://nginx.org/packages/mainline/debian buster/nginx amd64 nginx-module-geoip amd64 1.17.2-1~buster [75.9 kB] Get: 2 http://nginx.org/packages/mainline/debian buster/nginx amd64 nginx amd64 1.17.2-1~buster [852 kB] Get: 3 http://nginx.org/packages/mainline/debian buster/nginx amd64 nginx-module-image-filter amd64 1.17.2-1~buster [80.1 kB] Fetched 1,008 kB in 1s (1,565 kB/s) dpkg: warning: downgrading nginx-module-geoip from 1.17.2-1~stretch to 1.17.2-1~buster (Reading database ... 75606 files and directories currently installed.) Preparing to unpack .../nginx-module-geoip_1.17.2-1~buster_amd64.deb ... Unpacking nginx-module-geoip (1.17.2-1~buster) over (1.17.2-1~stretch) ... dpkg: warning: downgrading nginx from 1.17.2-1~stretch to 1.17.2-1~buster Preparing to unpack .../nginx_1.17.2-1~buster_amd64.deb ... Unpacking nginx (1.17.2-1~buster) over (1.17.2-1~stretch) ... Selecting previously unselected package nginx-module-image-filter. Preparing to unpack .../nginx-module-image-filter_1.17.2-1~buster_amd64.deb ... Unpacking nginx-module-image-filter (1.17.2-1~buster) ... Setting up nginx (1.17.2-1~buster) ... Setting up nginx-module-geoip (1.17.2-1~buster) ... ---------------------------------------------------------------------- The GeoIP dynamic modules for nginx have been installed. To enable these modules, add the following to /etc/nginx/nginx.conf and reload nginx: load_module modules/ngx_http_geoip_module.so; load_module modules/ngx_stream_geoip_module.so; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285184,285184#msg-285184 From mdounin на mdounin.ru Tue Aug 13 17:04:04 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 13 Aug 2019 20:04:04 +0300 Subject: nginx-1.17.3 Message-ID: <20190813170404.GP1877@mdounin.ru> Изменения в nginx 1.17.3 13.08.2019 *) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное потребление памяти и ресурсов процессора (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516). *) Исправление: при использовании сжатия в логах могли появляться сообщения "zero size buf"; ошибка появилась в 1.17.2. *) Исправление: при использовании директивы resolver в SMTP прокси-сервере в рабочем процессе мог произойти segmentation fault. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Aug 13 17:04:28 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 13 Aug 2019 20:04:28 +0300 Subject: nginx-1.16.1 Message-ID: <20190813170428.GT1877@mdounin.ru> Изменения в nginx 1.16.1 13.08.2019 *) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное потребление памяти и ресурсов процессора (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516). -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Aug 13 17:04:53 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 13 Aug 2019 20:04:53 +0300 Subject: nginx security advisory (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516) Message-ID: <20190813170453.GX1877@mdounin.ru> Hello! В реализации HTTP/2 в nginx было обнаружено несколько проблем безопасности, которые могут приводить к чрезмерному потреблению памяти и ресурсов процессора (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516). Проблемам подвержен nginx, собранный с модулем ngx_http_v2_module (по умолчанию не собирается), если в конфигурационном файле используется параметр http2 директивы listen. Проблемам подвержен nginx 1.9.5 - 1.17.2. Проблемы исправлены в nginx 1.17.3, 1.16.1. Спасибо Jonathan Looney из Netflix за обнаружение проблем. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Aug 13 18:06:11 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 13 Aug 2019 14:06:11 -0400 Subject: nginx-1.17.3 In-Reply-To: <20190813170404.GP1877@mdounin.ru> References: <20190813170404.GP1877@mdounin.ru> Message-ID: В вашей дорожней карте, для ветки 1,17 есть в планах имплементация QUIC (HTTP/3), какие ваши оценки по времени это будет готово в этом году. И если не сложно скажите как вам QUIC там реально много профита для мобил клиентов, у нас очень много мобил HTTP клиентов и нам эта тема очень интересна. Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285238,285245#msg-285245 From nginx-forum на forum.nginx.org Tue Aug 13 18:10:11 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 13 Aug 2019 14:10:11 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?= In-Reply-To: References: Message-ID: Возможно я не нашел, но в данной версии нет возможности broadcast каналов? Когда одно сообщения передается множеству WebSocket клиентов и как одного клиента подписать на множество каналов? Этого нет в текущей версии или вы не планируете этого делать и данный функционал нужно будет писать самому на Node.js? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284362,285246#msg-285246 From chipitsine на gmail.com Tue Aug 13 18:47:00 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 13 Aug 2019 23:47:00 +0500 Subject: nginx-1.17.3 In-Reply-To: References: <20190813170404.GP1877@mdounin.ru> Message-ID: вт, 13 авг. 2019 г. в 23:06, S.A.N : > В вашей дорожней карте, для ветки 1,17 есть в планах имплементация QUIC > (HTTP/3), какие ваши оценки по времени это будет готово в этом году. > И если не сложно скажите как вам QUIC там реально много профита для мобил > клиентов, у нас очень много мобил HTTP клиентов и нам эта тема очень > интересна. > для мобильных клиентов есть (уже) TLS1.3 + early data, TFO (tcp fast open). пользуетесь ? > Спасибо. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,285238,285245#msg-285245 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From tolmachev.vlad на gmail.com Tue Aug 13 18:52:16 2019 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Tue, 13 Aug 2019 21:52:16 +0300 Subject: =?UTF-8?B?0JHQuNGC0YvQtSDRhNCw0LnQu9GLINCyINC60LXRiNC1INC/0YDQuCBnemlwINC+?= =?UTF-8?B?0YLQstC10YLQsNGF?= Message-ID: Добрый день, не пойму как исправить ситуацию, nginx иногда хранит в proxy кеше битые обрезанные файлы, при использовании на бэкенде gzip, тот же баг замечен на клаудфлер, иногда в его кеше лешит обрезанный файл, например половина js файла и помогает только сброс кеша и запрос файла еще раз, что бы файл стал полный. Что подкрутить, что бы не выключать gzip и http1.1? В клаудфлере даже замечено то, что половина кэш серверов сохраняет полный файл, половина хранит его обрезанную версию и выдает ее как правильную.... -- С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki icq: 274888266 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Aug 13 18:55:11 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 13 Aug 2019 14:55:11 -0400 Subject: nginx-1.17.3 In-Reply-To: References: Message-ID: <229f9d4bc278a8746b8aeea539b9bdbb.NginxMailingListRussian@forum.nginx.org> > для мобильных клиентов есть (уже) TLS1.3 + early data, TFO (tcp fast > open). > пользуетесь ? TLS1.3 - да early data, TFO - нет, у нас проблема с частыми обрывами конекта в WebSocket, мобил клиенты этому сильно подвержены, из-за TCP... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285238,285251#msg-285251 From vbart на nginx.com Tue Aug 13 18:56:25 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 13 Aug 2019 21:56:25 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?= In-Reply-To: References: Message-ID: <8200919.v06zj0A6T6@vbart-workstation> On Tuesday 13 August 2019 14:10:11 S.A.N wrote: > Возможно я не нашел, но в данной версии нет возможности broadcast каналов? > Когда одно сообщения передается множеству WebSocket клиентов и как одного > клиента подписать на множество каналов? > Этого нет в текущей версии или вы не планируете этого делать и данный > функционал нужно будет писать самому на Node.js? > [..] Пока не планируем. -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue Aug 13 19:16:56 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 13 Aug 2019 15:16:56 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?= In-Reply-To: <8200919.v06zj0A6T6@vbart-workstation> References: <8200919.v06zj0A6T6@vbart-workstation> Message-ID: <108474cb36f3c254b9a4b627a569ca5f.NginxMailingListRussian@forum.nginx.org> > Пока не планируем. Ясно, но тогда вот что выходит, тем кому нужен WebSocket, как правило нужен broadcast и возможностость подписать одного клиента к множеству каналов. Эти задачи уже успешно решены в nchan (модуль Nginx) и для Node.js есть uWebSockets.js (сишный модуль) к сожалению это означает что Unit в этом стеке технологий не нужен. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284362,285254#msg-285254 From nginx-forum на forum.nginx.org Tue Aug 13 19:20:08 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 13 Aug 2019 15:20:08 -0400 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: References: Message-ID: <357e6d418624b0d78cd43bde0d69c409.NginxMailingListRussian@forum.nginx.org> > кеше битые обрезанные файлы, при использовании на бэкенде gzip, тот же > баг Попробуйте выключить настройку в конфигt Nginx sendfile off; Нам это помогло. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285255#msg-285255 From vbart на nginx.com Tue Aug 13 19:49:38 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 13 Aug 2019 22:49:38 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?= In-Reply-To: <108474cb36f3c254b9a4b627a569ca5f.NginxMailingListRussian@forum.nginx.org> References: <8200919.v06zj0A6T6@vbart-workstation> <108474cb36f3c254b9a4b627a569ca5f.NginxMailingListRussian@forum.nginx.org> Message-ID: <4189851.7uOB5VPmde@vbart-workstation> On Tuesday 13 August 2019 15:16:56 S.A.N wrote: > > Пока не планируем. > > Ясно, но тогда вот что выходит, тем кому нужен WebSocket, как правило нужен > broadcast и возможностость подписать одного клиента к множеству каналов. > Эти задачи уже успешно решены в nchan (модуль Nginx) и для Node.js есть > uWebSockets.js (сишный модуль) к сожалению это означает что Unit в этом > стеке технологий не нужен. [..] Что мешает реализовать данную функциональность в приложении? Например, используя тот же упомянутый uWebSockets.js? Дело в том, что задача достаточно узкоспециализированная, но в то же время требует заметных ресурсов, если взяться реализовывать это внутри Unit-а. Тот же nchan модуль для nginx монструозен. Для сравнения: nchan содержит 34755 строк кода на Си, что составляет почти половину от всей (!) HTTP части nginx c ~60 модулями (75959 строк). -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue Aug 13 22:00:46 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 13 Aug 2019 18:00:46 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?= In-Reply-To: <4189851.7uOB5VPmde@vbart-workstation> References: <4189851.7uOB5VPmde@vbart-workstation> Message-ID: > Что мешает реализовать данную функциональность в приложении? > Например, используя тот же упомянутый uWebSockets.js? Нам мешают те же причины что у вас, бизнесу выгодно чтобы мы писали больше бизнес логики и меньше писали инфрастуктурного кода. Да, можно сделать распределеную систему на Pub/Sub от Redis и uWebSockets.js будет раздавать клиентам сообщения, но это медленей и в лучшем случаи мы сделаем тоже что уже написано в nchan. > Дело в том, что задача достаточно узкоспециализированная Не уверен, из своего опыта даже сложно вспомнить какие задачи помещались в рамки связи один к одному, обычно один ко многим. Даже если у нас один сервер, у него будет множество процессов, два клиента WebSocket законектися к разным процессам, вот уже связь один ко многим. Киллер фича Unit, которой нет в nchan, заключается в том что Unit знает про все application и умеет с ними общатся без сети, это большой потенциал, я бы очень хотел чтобы мои процессы внутри сервера могли общатся через Unit без сети. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284362,285258#msg-285258 From valery+nginxru на grid.net.ru Tue Aug 13 22:38:04 2019 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Wed, 14 Aug 2019 00:38:04 +0200 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?= In-Reply-To: References: <4189851.7uOB5VPmde@vbart-workstation> Message-ID: <7ea0e2a4-35f1-ddc7-c194-993d818aaa91@grid.net.ru> On 14-08-19 00:00, S.A.N wrote: > Нам мешают те же причины что у вас, бизнесу выгодно чтобы мы писали больше > бизнес логики и меньше писали инфрастуктурного кода. Есть сервис Pusher, который позволяет раздавать потоки по WebSocket. Никакой инфраструктуры не нужно. Подозреваю там есть прямые и обратные каналы. -- Val From nginx-forum на forum.nginx.org Tue Aug 13 22:53:55 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 13 Aug 2019 18:53:55 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjkuMA==?= In-Reply-To: <7ea0e2a4-35f1-ddc7-c194-993d818aaa91@grid.net.ru> References: <7ea0e2a4-35f1-ddc7-c194-993d818aaa91@grid.net.ru> Message-ID: > Есть сервис Pusher, который позволяет раздавать потоки по WebSocket. > Никакой инфраструктуры не нужно. Подозреваю там есть прямые и обратные Так мы тоже самое получаем безплатно и без сторонних сервисов, простой надстройкой nchan + uWebSockets.js Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284362,285260#msg-285260 From mdounin на mdounin.ru Wed Aug 14 11:24:17 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Aug 2019 14:24:17 +0300 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: References: Message-ID: <20190814112417.GZ1877@mdounin.ru> Hello! On Tue, Aug 13, 2019 at 09:52:16PM +0300, Владислав Толмачев wrote: > Добрый день, не пойму как исправить ситуацию, nginx иногда хранит в proxy > кеше битые обрезанные файлы, при использовании на бэкенде gzip, тот же баг > замечен на клаудфлер, иногда в его кеше лешит обрезанный файл, например > половина js файла и помогает только сброс кеша и запрос файла еще раз, что > бы файл стал полный. Что подкрутить, что бы не выключать gzip и http1.1? В > клаудфлере даже замечено то, что половина кэш серверов сохраняет полный > файл, половина хранит его обрезанную версию и выдает ее как правильную.... Использование сжатия на бэкенде обычно означает, что заголовка Content-Length в ответах бэкенда не будет. Соответственно в HTTP/1.0 окончание ответа будет определяться по закрытию соединения, и если бэкенд по каким-то причинам закрывает соединение, не дослав ответ полностью, то такой ответ имеет шансы быть сохранённым в кэш частично. Лучше всего в подобной ситуации - разобраться, почему таки закрываются соединения, и полечить. Но в качестве workaround'а скорее всего сработает "proxy_http_version 1.1;" в конфиге. Подробнее тут: http://nginx.org/r/proxy_http_version/ru -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Aug 14 11:30:41 2019 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Wed, 14 Aug 2019 07:30:41 -0400 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <20190814112417.GZ1877@mdounin.ru> References: <20190814112417.GZ1877@mdounin.ru> Message-ID: <174738b6a8f95acd7728ddcc5e7e442e.NginxMailingListRussian@forum.nginx.org> Максим, прокси версии 1.1 итак установлен, битые файлы на нем и получаются. Клаудфлер тоже использует 1.1 у них так же битые файлы часто лежат в кеше, проверял лично. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285267#msg-285267 From mdounin на mdounin.ru Wed Aug 14 11:50:53 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Aug 2019 14:50:53 +0300 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <174738b6a8f95acd7728ddcc5e7e442e.NginxMailingListRussian@forum.nginx.org> References: <20190814112417.GZ1877@mdounin.ru> <174738b6a8f95acd7728ddcc5e7e442e.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190814115053.GB1877@mdounin.ru> Hello! On Wed, Aug 14, 2019 at 07:30:41AM -0400, Vladislavik wrote: > Максим, прокси версии 1.1 итак установлен, битые файлы на нем и получаются. > Клаудфлер тоже использует 1.1 у них так же битые файлы часто лежат в кеше, > проверял лично. Если так, то наиболее вероятная причина - бэкенд так прислал. Почему и как вылечить - уже, видимо, вопрос к бэкенду. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Aug 14 11:53:54 2019 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Wed, 14 Aug 2019 07:53:54 -0400 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <20190814115053.GB1877@mdounin.ru> References: <20190814115053.GB1877@mdounin.ru> Message-ID: <6bec3d2232b3aa0d07df31682bb0d37a.NginxMailingListRussian@forum.nginx.org> Бэкэенд это nginx который шлет обычные файлы js сжатые с помощью встроенного gzip Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285269#msg-285269 From mdounin на mdounin.ru Wed Aug 14 12:31:40 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Aug 2019 15:31:40 +0300 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <6bec3d2232b3aa0d07df31682bb0d37a.NginxMailingListRussian@forum.nginx.org> References: <20190814115053.GB1877@mdounin.ru> <6bec3d2232b3aa0d07df31682bb0d37a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190814123140.GC1877@mdounin.ru> Hello! On Wed, Aug 14, 2019 at 07:53:54AM -0400, Vladislavik wrote: > Бэкэенд это nginx который шлет обычные файлы js сжатые с помощью встроенного > gzip Так, а "обычные файлы js", случайно, не перегенерятся (и/или редактируюстся) регулярно? Ну и отступая на пару шагов назад: битые файлы - это что? Обрезанный gzip-контейнер, при распаковке возникает ошибка? Или структура gzip-контейнера не нарушена, всё штатно распаковывается без ошибок, но по результатом распаковки получается только часть того, что ожидалось в файле? Если второе - то это выглядит как проблема с генерацией файлов. Такое бывает, если генерить файлы "по месту" - если к файлу обрататься, пока пишется новая версия, то из него прочитается только часть, уже записанная, но никто не обещал, что это будет ожидаемый файл полностью. Соответственно эта часть и будет отправлена клиенту и закэширована. Чтобы такого не было - надо менять файлы атомарно: написать новый файл рядом с временным именем, потом сделать rename() / mv в нужное имя. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Aug 14 12:43:39 2019 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Wed, 14 Aug 2019 08:43:39 -0400 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <20190814123140.GC1877@mdounin.ru> References: <20190814123140.GC1877@mdounin.ru> Message-ID: <74a76f2c577f039b03c9e974fb4118c9.NginxMailingListRussian@forum.nginx.org> Ничего не генерится, файлы лежат на диске, созданы один раз и записаны на диск. Nginx должен сжать его на лету и отдать, вот, что от него требуется, он это выполняет, но иногда в кэше браузера/клаудфлера лежит обрезанный файл, например половина его (уже разжатый, тупо не весь, не хватает куска кода в конце файла) возникает ли ошибка при разжатии я не знаю, видно только, что файл читаемый, но код не полный, чаще только половина его) я так понял, что в процессе передачи или упаковки возникает какая-то проблема и nginx принимает файл от другого nginx/браузера без проверки его на целостность...Размеры файлов не более 20кб. Вопрос такой: возможно ли распаковать архив, если он получен не полностью? (Тк тест в js файла читаемый, но файл состоит только из половины того, что должно быть) Если gzip архив можно распаковать, получив только половину файла, то может быть проблема в передаче и не удостоверении, что файл передан полностью. Если архив невозможно распаковать, не получив полностью, значит проблема в упаковщике. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285271#msg-285271 From mdounin на mdounin.ru Wed Aug 14 13:25:39 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Aug 2019 16:25:39 +0300 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <74a76f2c577f039b03c9e974fb4118c9.NginxMailingListRussian@forum.nginx.org> References: <20190814123140.GC1877@mdounin.ru> <74a76f2c577f039b03c9e974fb4118c9.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190814132539.GE1877@mdounin.ru> Hello! On Wed, Aug 14, 2019 at 08:43:39AM -0400, Vladislavik wrote: > Ничего не генерится, файлы лежат на диске, созданы один раз и записаны на > диск. Nginx должен сжать его на лету и отдать, вот, что от него требуется, > он это выполняет, но иногда в кэше браузера/клаудфлера лежит обрезанный Что лежит в кэшах браузера и клаудфлера - вопрос к браузеру и клаудфлеру соответственно. Исходный вопрос был про proxy cache - что лежит в нём, когда наблюдается проблема? > файл, например половина его (уже разжатый, тупо не весь, не хватает куска > кода в конце файла) возникает ли ошибка при разжатии я не знаю, видно > только, что файл читаемый, но код не полный, чаще только половина его) я так > понял, что в процессе передачи или упаковки возникает какая-то проблема и > nginx принимает файл от другого nginx/браузера без проверки его на > целостность...Размеры файлов не более 20кб. > Вопрос такой: возможно ли распаковать архив, если он получен не полностью? > (Тк тест в js файла читаемый, но файл состоит только из половины того, что > должно быть) Распаковать - возможно. При распаковке будет известно, полностью получен ответ или нет - по наличию/отсутствию gzip trailer'а (8 байт с CRC32 и размером несжатого ответа). Что делает с этой информацией конкретный распаковщик - тайна сия великая есть, да и не важно. Смотреть надо строго на то, что лежит в кэше nginx'а, см. выше. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Wed Aug 14 14:17:25 2019 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 14 Aug 2019 17:17:25 +0300 Subject: nginx.service start operation timed out. Terminating. Message-ID: <4c7038a9-b58a-f602-817c-fe8ce9b4468f@csdoc.com> Здравствуйте, All! Столкнулся с проблемой nginx.service start operation timed out. Terminating. Конфигурация: есть два физических сервера px62-nvme https://www.hetzner.com/dedicated-rootserver/px62-nvme на каждом из них установлена операционная система Linux, KVM и ZFS. Есть виртуальная машина vm, для которой получен Failover IP https://wiki.hetzner.de/index.php/Failover/en На первом физическом сервере создан виртуальный диск размером 1 терабайт для этой виртуальной машины zfs create -s -b 4K -V 1T tank/kvm-vm Внутри виртуальной машины установлена операционная система Linux, весь необходимый софт, в том числе и nginx. Failover IP привязан к первому физическому серверу и проброшен внутрь виртуальной машины, все нормально работает, как и ожидалось. С помощью утилиты https://github.com/makhomed/autosnap на первом физическом сервере периодически делаются snapshot`ы zvol с образом диска виртуальной машины и с помощью утилиты https://github.com/makhomed/autosync эти snapshot`ы в постоянном режиме реплицируются на второй физический сервер. на втором физическом сервере настроена идентичная конфигурация виртуальной машины и с помощью zfs send и zfs receive из локального зеркала создана локальная копия виртуального диска tank/kvm-vm Failover IP привязан к первому физическому серверу, поэтому если запустить эту же виртуальную машину на втором физическом сервере - у нее не будет доступа в интернет. тем не менее, виртуальная машина нормально стартует и все работает. кроме nginx. который падает с такой ошибкой в логах: Aug 14 16:22:35 vm nginx: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x3.letsencrypt .org" in the certificate "/etc/letsencrypt/live/example.com/fullchain.pem" Aug 14 16:23:03 vm systemd: nginx.service start operation timed out. Terminating. Aug 14 16:23:03 vm systemd: Failed to start nginx - high performance web server. Aug 14 16:23:03 vm systemd: Unit nginx.service entered failed state. Aug 14 16:23:03 vm systemd: nginx.service failed. Подскажите пожалуйста, каким образом можно сконфигурировать nginx, чтобы он нормально запускался и работал на втором узле кластера даже в том случае, когда Failover IP указывает на первый физический сервер и виртуальная машина, запускаемая на втором физическом сервере не имеет доступа в интернет? Таким способом, как описано выше я пытаюсь сделать high availability кластер из двух физических серверов, которые размещены в двух различных датацентрах - один в Германии, второй в Финляндии. Кластер работает по схеме active/passive, в случае выхода из строя первого физического сервера - Failover IP переключается на второй физический сервер. Порядок переключения на второй узел кластера такой: 1. На втором физическом сервере из локальной копии сделать виртуальный диск tank/kvm-vm 2. На втором физическом сервере запустить виртуальную машину 3. Переключить Failover IP таким образом, чтобы он указывал на второй физический сервер. И второй вопрос, если он не является в этом списке рассылки оффтопиком: Я все правильно делаю, когда таким способом строю high availability кластер, или я совершил какие-то ошибки и что-то можно сделать еще проще, еще лучше и еще надежнее? Про Proxmox и VMware я читал, но мне сейчас гораздо интереснее сделать high availability кластер самому, используя только CentOS, KVM, ZFS и немного скриптов на Python. -- Best regards, Gena From mdounin на mdounin.ru Wed Aug 14 15:01:17 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Aug 2019 18:01:17 +0300 Subject: nginx.service start operation timed out. Terminating. In-Reply-To: <4c7038a9-b58a-f602-817c-fe8ce9b4468f@csdoc.com> References: <4c7038a9-b58a-f602-817c-fe8ce9b4468f@csdoc.com> Message-ID: <20190814150117.GF1877@mdounin.ru> Hello! On Wed, Aug 14, 2019 at 05:17:25PM +0300, Gena Makhomed wrote: > Здравствуйте, All! > > Столкнулся с проблемой > > nginx.service start operation timed out. Terminating. [...] > Failover IP привязан к первому физическому серверу, > поэтому если запустить эту же виртуальную машину на втором > физическом сервере - у нее не будет доступа в интернет. > > тем не менее, виртуальная машина нормально стартует и все работает. > > кроме nginx. > > который падает с такой ошибкой в логах: > > Aug 14 16:22:35 vm nginx: nginx: [warn] "ssl_stapling" ignored, host not > found in OCSP responder "ocsp.int-x3.letsencrypt .org" in the > certificate "/etc/letsencrypt/live/example.com/fullchain.pem" > Aug 14 16:23:03 vm systemd: nginx.service start operation timed out. > Terminating. > Aug 14 16:23:03 vm systemd: Failed to start nginx - high performance web > server. > Aug 14 16:23:03 vm systemd: Unit nginx.service entered failed state. > Aug 14 16:23:03 vm systemd: nginx.service failed. > > Подскажите пожалуйста, каким образом можно сконфигурировать nginx, чтобы > он нормально запускался и работал на втором узле кластера даже в том > случае, когда Failover IP указывает на первый физический сервер и > виртуальная машина, запускаемая на втором физическом сервере не имеет > доступа в интернет? Нужно либо убрать из из конфигурации всё, что требует резолвинга имён, и соответственно требует доступа в интернет, либо сделать этот резолвинг возможным (добавив соответствующие имена в /etc/hosts или обеспечив работу DNS). Включённый OCSP stapling - пытается резолвить имена OCSP-серверов из сертификатов на старте. Он, при этом, умеет автоматически выключаться, если разрезолвить имя не удаётся, но, судя по всему, сертификатов больше одного, а системный резолвер про отсутствие интернета не в курсе и тупо ждёт таймаутов, так что случается уже таймаут на запуск nginx'а в systemd. -- Maxim Dounin http://mdounin.ru/ From tit на irk.ru Wed Aug 14 16:48:56 2019 From: tit на irk.ru (Alexander Titaev) Date: Thu, 15 Aug 2019 00:48:56 +0800 Subject: nginx error_page 200 Message-ID: <1426621421.20190815004856@irk.ru> Здравствуйте, Nginx-ru. у клиента nginx проксирует запросы на tomcat. tomcat должен возвращать 301 с хитрым url, но у него регулярно затекает мозг и он периодически начинает возвращать 200. Помогает рестарт. Клиент просит временно, пока они разбираются с явой, сделать перехват этих 200 с преобразованием в 301, подобного тому что делает tomcat, но по упрощенной схеме. Вот никак не соображу как этот перехват сделать. Возможно-ли это в принципе? -- С уважением, Alexander mailto:tit на irk.ru From gmm на csdoc.com Wed Aug 14 17:02:53 2019 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 14 Aug 2019 20:02:53 +0300 Subject: nginx.service start operation timed out. Terminating. In-Reply-To: <20190814150117.GF1877@mdounin.ru> References: <4c7038a9-b58a-f602-817c-fe8ce9b4468f@csdoc.com> <20190814150117.GF1877@mdounin.ru> Message-ID: <04bfdea4-cd88-5fc1-9e43-64a182aafd31@csdoc.com> On 14.08.2019 18:01, Maxim Dounin wrote: >> Aug 14 16:22:35 vm nginx: nginx: [warn] "ssl_stapling" ignored, host not >> found in OCSP responder "ocsp.int-x3.letsencrypt .org" in the >> certificate "/etc/letsencrypt/live/example.com/fullchain.pem" >> Aug 14 16:23:03 vm systemd: nginx.service start operation timed out. >> Terminating. >> Aug 14 16:23:03 vm systemd: Failed to start nginx - high performance web >> server. >> Aug 14 16:23:03 vm systemd: Unit nginx.service entered failed state. >> Aug 14 16:23:03 vm systemd: nginx.service failed. >> >> Подскажите пожалуйста, каким образом можно сконфигурировать nginx, чтобы >> он нормально запускался и работал на втором узле кластера даже в том >> случае, когда Failover IP указывает на первый физический сервер и >> виртуальная машина, запускаемая на втором физическом сервере не имеет >> доступа в интернет? > Нужно либо убрать из из конфигурации всё, что требует резолвинга > имён, и соответственно требует доступа в интернет, либо сделать > этот резолвинг возможным (добавив соответствующие имена в > /etc/hosts или обеспечив работу DNS). > > Включённый OCSP stapling - пытается резолвить имена OCSP-серверов > из сертификатов на старте. Он, при этом, умеет автоматически > выключаться, если разрезолвить имя не удаётся, но, судя по всему, > сертификатов больше одного, а системный резолвер про отсутствие > интернета не в курсе и тупо ждёт таймаутов, так что случается уже > таймаут на запуск nginx'а в systemd. Да, Вы правы, сертификатов больше одного. Выключил ssl_stapling - теперь все запускается и работает нормально. Спасибо! Разве есть возможность системный резолвер научить понимать что нет интернета, если IP адрес сконфигурирован статически на CentOS 7.6? Как это можно сделать? (Подозреваю что такой возможности нет и не будет) Может быть можно научить nginx не использовать системный резолвер при старте для резолвинга имен хостов OCSP responder'ов из загружаемых им SSL сертификатов? Не понятно, зачем nginx это делает, если в конфиге указана директива resolver и наличие ответа от OCSP responder не является необходимым для нормального запуска и последующей нормальной работы веб-сервера. Может лучше было бы резолвить имена OCSP-серверов из сертификатов не при старте а в момент первого запроса к серверу, или делать автоматический preload ответов OCSP-серверов уже после того, как nginx будет полностью сконфигурирован и запущен? Потому что сейчас без интернета или при сбоях в работе системного резолвера при включенном в конфиге OCSP stapling - nginx вообще не запускается и это самым катастрофическим образом сказывается на надежности работы сервера - запуск nginx завершается ошибкой и все сайты становятся нерабочими. Это хуже чем OCSP Must-Staple. -- Best regards, Gena From bgx на protva.ru Wed Aug 14 17:33:21 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 14 Aug 2019 20:33:21 +0300 Subject: nginx error_page 200 In-Reply-To: <1426621421.20190815004856@irk.ru> References: <1426621421.20190815004856@irk.ru> Message-ID: <20190814173321.GQ3175@sie.protva.ru> On Thu, Aug 15, 2019 at 12:48:56AM +0800, Alexander Titaev wrote: > у клиента nginx проксирует запросы на tomcat. tomcat должен возвращать 301 с хитрым url, но у него регулярно затекает > мозг и он периодически начинает возвращать 200. Помогает рестарт. Клиент просит временно, пока они разбираются с > явой, сделать перехват этих 200 с преобразованием в 301, подобного тому что делает tomcat, но по упрощенной схеме. Вот > никак не соображу как этот перехват сделать. Возможно-ли это в принципе? Приложение отдаёт 200 с правильным содержимым Location: в заголовке? Без nginx: пропустите его выдачу через netsed ... "s/200 /301 /". -- Eugene Berdnikov From bgx на protva.ru Wed Aug 14 18:22:28 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 14 Aug 2019 21:22:28 +0300 Subject: nginx.service start operation timed out. Terminating. In-Reply-To: <04bfdea4-cd88-5fc1-9e43-64a182aafd31@csdoc.com> References: <4c7038a9-b58a-f602-817c-fe8ce9b4468f@csdoc.com> <20190814150117.GF1877@mdounin.ru> <04bfdea4-cd88-5fc1-9e43-64a182aafd31@csdoc.com> Message-ID: <20190814182228.GR3175@sie.protva.ru> On Wed, Aug 14, 2019 at 08:02:53PM +0300, Gena Makhomed wrote: > Разве есть возможность системный резолвер научить понимать что нет > интернета, если IP адрес сконфигурирован статически на CentOS 7.6? > Как это можно сделать? (Подозреваю что такой возможности нет и не будет) Не надо так делать. Типичный шаблон для построения HA-кластера: у каждого узла свой собственный ip-адрес, по которому узел всегда доступен из сети, и есть переходящий ip-адрес, служащий для доступа клиентов к сервису. Переходящий ip-шник поднимает у себя узел, принимающий роль мастера, а слейв его освобождает. Это самый простой вариант, есть масса вариаций. Например, сеть можно построить так, что все узлы кластера будут выходить в интернет через один белый ip-адрес (с nat-ом, разумеется), поэтому перенаправление входящих соединений на один из узлов кластера (мастер) никак не будет ограничивать исходящие, в том числе для слейва. -- Eugene Berdnikov From chipitsine на gmail.com Wed Aug 14 19:59:41 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 15 Aug 2019 00:59:41 +0500 Subject: nginx.service start operation timed out. Terminating. In-Reply-To: <20190814182228.GR3175@sie.protva.ru> References: <4c7038a9-b58a-f602-817c-fe8ce9b4468f@csdoc.com> <20190814150117.GF1877@mdounin.ru> <04bfdea4-cd88-5fc1-9e43-64a182aafd31@csdoc.com> <20190814182228.GR3175@sie.protva.ru> Message-ID: ср, 14 авг. 2019 г. в 23:22, Evgeniy Berdnikov : > On Wed, Aug 14, 2019 at 08:02:53PM +0300, Gena Makhomed wrote: > > Разве есть возможность системный резолвер научить понимать что нет > > интернета, если IP адрес сконфигурирован статически на CentOS 7.6? > > Как это можно сделать? (Подозреваю что такой возможности нет и не будет) > > Не надо так делать. Типичный шаблон для построения HA-кластера: > у каждого узла свой собственный ip-адрес, по которому узел всегда > доступен из сети, и есть переходящий ip-адрес, служащий для доступа > клиентов к сервису. Переходящий ip-шник поднимает у себя узел, > принимающий роль мастера, а слейв его освобождает. > необязательно мастер-слейв. можно и мастер-мастер: https://github.com/Exa-Networks/exabgp (похожую схему используем, просто у ExaBGP документация наглядная) > > Это самый простой вариант, есть масса вариаций. Например, сеть можно > построить так, что все узлы кластера будут выходить в интернет через > один белый ip-адрес (с nat-ом, разумеется), поэтому перенаправление > входящих соединений на один из узлов кластера (мастер) никак не будет > ограничивать исходящие, в том числе для слейва. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From tit на irk.ru Thu Aug 15 07:08:05 2019 From: tit на irk.ru (Alexander Titaev) Date: Thu, 15 Aug 2019 15:08:05 +0800 Subject: nginx error_page 200 In-Reply-To: <20190814173321.GQ3175@sie.protva.ru> References: <1426621421.20190815004856@irk.ru> <20190814173321.GQ3175@sie.protva.ru> Message-ID: <10710489306.20190815150805@irk.ru> Здравствуйте, Evgeniy. Вы писали 15 августа 2019 г., 1:33:21: > On Thu, Aug 15, 2019 at 12:48:56AM +0800, Alexander Titaev wrote: >> у клиента nginx проксирует запросы на tomcat. tomcat должен возвращать 301 с хитрым url, но у него регулярно затекает >> мозг и он периодически начинает возвращать 200. Помогает рестарт. Клиент просит временно, пока они разбираются с >> явой, сделать перехват этих 200 с преобразованием в 301, подобного тому что делает tomcat, но по упрощенной схеме. Вот >> никак не соображу как этот перехват сделать. Возможно-ли это в принципе? > Приложение отдаёт 200 с правильным содержимым Location: в заголовке? > Без nginx: пропустите его выдачу через netsed ... "s/200 /301 /". так это одно самое нагруженное location 301 должно отдавать, есть другие для которых 200 норма -- С уважением, Alexander mailto:tit на irk.ru From bgx на protva.ru Thu Aug 15 07:41:58 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 15 Aug 2019 10:41:58 +0300 Subject: nginx error_page 200 In-Reply-To: <10710489306.20190815150805@irk.ru> References: <1426621421.20190815004856@irk.ru> <20190814173321.GQ3175@sie.protva.ru> <10710489306.20190815150805@irk.ru> Message-ID: <20190815074158.GA3083@protva.ru> On Thu, Aug 15, 2019 at 03:08:05PM +0800, Alexander Titaev wrote: > Здравствуйте, Evgeniy. > > Вы писали 15 августа 2019 г., 1:33:21: > > > On Thu, Aug 15, 2019 at 12:48:56AM +0800, Alexander Titaev wrote: > >> у клиента nginx проксирует запросы на tomcat. tomcat должен возвращать 301 с хитрым url, но у него регулярно затекает > >> мозг и он периодически начинает возвращать 200. Помогает рестарт. Клиент просит временно, пока они разбираются с > >> явой, сделать перехват этих 200 с преобразованием в 301, подобного тому что делает tomcat, но по упрощенной схеме. Вот > >> никак не соображу как этот перехват сделать. Возможно-ли это в принципе? > > > Приложение отдаёт 200 с правильным содержимым Location: в заголовке? > > Без nginx: пропустите его выдачу через netsed ... "s/200 /301 /". > > так это одно самое нагруженное location 301 должно отдавать, есть другие для которых 200 норма В чём проблема разные location на разные бэкенды раздать? А увеличение нагрузки включите в счёт клиенту, может он зашевелится. -- Eugene Berdnikov From iippolitov на nginx.com Thu Aug 15 09:40:50 2019 From: iippolitov на nginx.com (Igor A. Ippolitov) Date: Thu, 15 Aug 2019 12:40:50 +0300 Subject: nginx error_page 200 In-Reply-To: <1426621421.20190815004856@irk.ru> References: <1426621421.20190815004856@irk.ru> Message-ID: Можно делать "предзапрос" в томкат с помощью auth_request По результатам запроса менять бэкенд в который пойдёт запрос: либо в томкат, либо в "заглушку". Вероятно, можно даже кэшировать ответы, чтобы не насиловать томкат двойной нагрузкой. On 14.08.2019 19:48, Alexander Titaev wrote: > Здравствуйте, Nginx-ru. > > у клиента nginx проксирует запросы на tomcat. tomcat должен возвращать 301 с хитрым url, но у него регулярно затекает > мозг и он периодически начинает возвращать 200. Помогает рестарт. Клиент просит временно, пока они разбираются с > явой, сделать перехват этих 200 с преобразованием в 301, подобного тому что делает tomcat, но по упрощенной схеме. Вот > никак не соображу как этот перехват сделать. Возможно-ли это в принципе? > From nginx-forum на forum.nginx.org Thu Aug 15 15:37:55 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Thu, 15 Aug 2019 11:37:55 -0400 Subject: =?UTF-8?B?UmU6IHNpZ25lciBjZXJ0aWZpY2F0ZSBub3QgZm91bmQg0L/QvtGB0LvQtSDQvtCx?= =?UTF-8?B?0L3QvtCy0LvQtdC90LjRjw==?= In-Reply-To: <20190517125011.GC1877@mdounin.ru> References: <20190517125011.GC1877@mdounin.ru> Message-ID: Не знаете есть ли обновления? Сейчас в nginx вышла дырка в http2 и пришлось обновляться с 1.16.0 до 1.16.1, но ворнинги от ssl_stapling вернулись. Дело в том что сайтов много, релоад в рамках общей задачи мы делаем довольно часто и это видит каждый пользователь, это засоряет экран и неизбежно приведет к увеличению вопросов в саппорт, т.е. ко мне ) Не хотелось бы переходить на openssl пока это есть. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285297#msg-285297 From nginx-forum на forum.nginx.org Thu Aug 15 15:45:32 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Thu, 15 Aug 2019 11:45:32 -0400 Subject: =?UTF-8?B?UmU6IHNpZ25lciBjZXJ0aWZpY2F0ZSBub3QgZm91bmQg0L/QvtGB0LvQtSDQvtCx?= =?UTF-8?B?0L3QvtCy0LvQtdC90LjRjw==?= In-Reply-To: References: <20190517125011.GC1877@mdounin.ru> Message-ID: Я избавился от ворнингов временно просто перестроив с openssl :( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285298#msg-285298 From nginx-forum на forum.nginx.org Thu Aug 15 15:52:28 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Thu, 15 Aug 2019 11:52:28 -0400 Subject: =?UTF-8?B?UmU6IHNpZ25lciBjZXJ0aWZpY2F0ZSBub3QgZm91bmQg0L/QvtGB0LvQtSDQvtCx?= =?UTF-8?B?0L3QvtCy0LvQtdC90LjRjw==?= In-Reply-To: References: <20190517125011.GC1877@mdounin.ru> Message-ID: В портах фришки есть еще libressl-devel, там версия 3.0.0, пересобрал nginx с ней - то же самое. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285299#msg-285299 From nginx-forum на forum.nginx.org Thu Aug 15 15:59:53 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Thu, 15 Aug 2019 11:59:53 -0400 Subject: =?UTF-8?B?UmU6IHNpZ25lciBjZXJ0aWZpY2F0ZSBub3QgZm91bmQg0L/QvtGB0LvQtSDQvtCx?= =?UTF-8?B?0L3QvtCy0LvQtdC90LjRjw==?= In-Reply-To: References: <20190517125011.GC1877@mdounin.ru> Message-ID: <085efdbbf02cce877ec7fca32bedce66.NginxMailingListRussian@forum.nginx.org> А можно вообще вернуться на родную openssl из фришки 11.х? Как она, стабильна? Вопросы лицензии и разного уровня "свободы" между "open" и "libre" мне безразличны. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284203,285300#msg-285300 From oleg на mamontov.net Thu Aug 15 16:36:04 2019 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Thu, 15 Aug 2019 19:36:04 +0300 Subject: nginx error_page 200 In-Reply-To: <10710489306.20190815150805@irk.ru> References: <1426621421.20190815004856@irk.ru> <20190814173321.GQ3175@sie.protva.ru> <10710489306.20190815150805@irk.ru> Message-ID: <20190815163604.nye5vubaisht6lbo@xenon.mamontov.net> On Thu, Aug 15, 2019 at 03:08:05PM +0800, Alexander Titaev wrote: >Здравствуйте, Evgeniy. > >Вы писали 15 августа 2019 г., 1:33:21: > >> On Thu, Aug 15, 2019 at 12:48:56AM +0800, Alexander Titaev wrote: >>> у клиента nginx проксирует запросы на tomcat. tomcat должен возвращать 301 с хитрым url, но у него регулярно затекает >>> мозг и он периодически начинает возвращать 200. Помогает рестарт. Клиент просит временно, пока они разбираются с >>> явой, сделать перехват этих 200 с преобразованием в 301, подобного тому что делает tomcat, но по упрощенной схеме. Вот >>> никак не соображу как этот перехват сделать. Возможно-ли это в принципе? > >> Приложение отдаёт 200 с правильным содержимым Location: в заголовке? >> Без nginx: пропустите его выдачу через netsed ... "s/200 /301 /". > >так это одно самое нагруженное location 301 должно отдавать, есть другие для которых 200 норма Если не боитесь Lua, то все просто: location /foo/ { proxy_pass http://tomcat; header_filter_by_lua_block { ngx.status = 301 } } -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From chipitsine на gmail.com Fri Aug 16 08:27:34 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 16 Aug 2019 13:27:34 +0500 Subject: =?UTF-8?B?IndvcmtpbmdfZGlyZWN0b3J5IC9yb290OyIgLSDQvtGI0LjQsdC60LAg0L3QtSA=?= =?UTF-8?B?0LTQtdGC0LXQutGC0LjRgtGB0Y8g0YfQtdGA0LXQtyAibmdpbnggLXQiID8=?= Message-ID: привет! беру nginx-1.17.3 делаю вот такой конфиг user nginx; worker_processes auto; working_directory /root; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { default_type application/octet-stream; access_log off; server { listen 80; server_name localhost; location / { return 200; } } } проверка проходит [root на working ~]# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful [root на working ~]# при запуске есть только мастер, ни одного воркера [root на working ~]# ps auxw | grep nginx root 1225 0.0 0.0 46456 1100 ? Ss 08:23 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 1442 0.0 0.0 112704 972 pts/0 S+ 08:26 0:00 grep --color=auto nginx [root на working ~]# в логе вот такая ошибка 2019/08/16 08:23:28 [alert] 1227#1227: chdir("/root") failed (13: Permission denied) 2019/08/16 08:23:28 [alert] 1225#1225: worker process 1227 exited with fatal code 2 and cannot be respawned 2019/08/16 08:23:28 [alert] 1226#1226: chdir("/root") failed (13: Permission denied) 2019/08/16 08:23:28 [alert] 1225#1225: worker process 1226 exited with fatal code 2 and cannot be respawned можно как-то сделать, чтобы видеть эту ошибку на "nginx -t" ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Aug 18 11:04:32 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Sun, 18 Aug 2019 07:04:32 -0400 Subject: =?UTF-8?B?0JDQutGC0YPQsNC70YzQvdCwINC70LggcHJveHkgY2FjaGUgcGF0aCBpbmFjdGl2?= =?UTF-8?B?ZT1OTk4g0LzQtdC20LTRgyDRgNC10YHRgtCw0YDRgtCw0LzQuD8=?= Message-ID: <4cfc450587c47b21b1f950dcc7e7da31.NginxMailingListRussian@forum.nginx.org> У нас на некоторых серверах inactive стоит 90 дней, что будет если nginx перезагрузить до этого времени, сохранится ли время последнего запроса к кешированному ресурсу? Я попытался сам разобраться по коду но там сложно. file->accessed = now; в ./src/core/ngx_open_file_cache.c И потом в ngx_http_file_cache_update() не увидел что поле acessed пишется. Может в другом месте где-то? Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285333,285333#msg-285333 From nginx-forum на forum.nginx.org Sun Aug 18 14:59:26 2019 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Sun, 18 Aug 2019 10:59:26 -0400 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <20190814132539.GE1877@mdounin.ru> References: <20190814132539.GE1877@mdounin.ru> Message-ID: <5d75c635a2813e1902d83ddd66044975.NginxMailingListRussian@forum.nginx.org> когда битый файл в кэше лежит, в заголовках в файле кэша указан его не полный размер, а так же сам файл обрезан L]]O?Y]WY]zŘy"5d593f4f-da4"Accept-Encoding¶,܋° OW6ì KEY: server.com/js/1.js?44 HTTP/1.1 200 OK Server: nginx Date: Sun, 18 Aug 2019 13:50:05 GMT Content-Type: application/javascript; charset=UTF-8 Content-Length: 3492 Last-Modified: Sun, 18 Aug 2019 12:06:39 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "5d593f4f-da4" Cache-Control: public, max-age=31536000, stale-while-revalidate=31536000, stale-if-error=31536000 Pragma: cache Accept-Ranges: bytes когда файл целый, в кэше лежит уже полный файл, в заголовках в файле кэша указан полный размер S]]yWY]_Y]õyy"5d595779-dbe"Accept-EncodingѦ@6¡S q5¿N KEY: server.com/js/1.js?45 HTTP/1.1 200 OK Server: nginx Date: Sun, 18 Aug 2019 14:22:02 GMT Content-Type: application/javascript; charset=UTF-8 Content-Length: 3518 Last-Modified: Sun, 18 Aug 2019 13:49:45 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "5d595779-dbe" Cache-Control: public, max-age=31536000, stale-while-revalidate=31536000, stale-if-error=31536000 Pragma: cache Accept-Ranges: bytes Файл без упаковки так и весит, 3518 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285334#msg-285334 From nginx-forum на forum.nginx.org Sun Aug 18 15:12:31 2019 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Sun, 18 Aug 2019 11:12:31 -0400 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <5d75c635a2813e1902d83ddd66044975.NginxMailingListRussian@forum.nginx.org> References: <20190814132539.GE1877@mdounin.ru> <5d75c635a2813e1902d83ddd66044975.NginxMailingListRussian@forum.nginx.org> Message-ID: этот запрос был без gzip, файл каким-то образом nginx был отдан не полностью, с указанием размера 3492 вместо 3518, как это может быть? Файл лежит на диске, Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285335#msg-285335 From mdounin на mdounin.ru Mon Aug 19 21:29:52 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Aug 2019 00:29:52 +0300 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: References: <20190814132539.GE1877@mdounin.ru> <5d75c635a2813e1902d83ddd66044975.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190819212951.GP1877@mdounin.ru> Hello! On Sun, Aug 18, 2019 at 11:12:31AM -0400, Vladislavik wrote: > этот запрос был без gzip, файл каким-то образом nginx был отдан не > полностью, с указанием размера 3492 вместо 3518, как это может быть? Файл > лежит на диске, Как уже говорилось - если файл отдаёт nginx, то наиболее вероятная причина - файл на диске кто-то переписывает по месту. Если файл не меняется - это может быть какая-нибудь забытая синхронизация, которая просто копирует все файлы с другой машины / из другого каталога. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Aug 19 21:32:55 2019 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Mon, 19 Aug 2019 17:32:55 -0400 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <20190819212951.GP1877@mdounin.ru> References: <20190819212951.GP1877@mdounin.ru> Message-ID: chunked_transfer_encoding on; Не может быть причиной? Файл никто не переписывает, лежит и никак не меняется не обновляется, а nginx порой отдает его обрезанным... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285342#msg-285342 From mdounin на mdounin.ru Mon Aug 19 21:50:10 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Aug 2019 00:50:10 +0300 Subject: =?UTF-8?B?UmU6INCQ0LrRgtGD0LDQu9GM0L3QsCDQu9C4IHByb3h5IGNhY2hlIHBhdGggaW5h?= =?UTF-8?B?Y3RpdmU9Tk5OINC80LXQttC00YMg0YDQtdGB0YLQsNGA0YLQsNC80Lg/?= In-Reply-To: <4cfc450587c47b21b1f950dcc7e7da31.NginxMailingListRussian@forum.nginx.org> References: <4cfc450587c47b21b1f950dcc7e7da31.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190819215010.GQ1877@mdounin.ru> Hello! On Sun, Aug 18, 2019 at 07:04:32AM -0400, rihad wrote: > У нас на некоторых серверах inactive стоит 90 дней, что будет если nginx > перезагрузить до этого времени, сохранится ли время последнего запроса к > кешированному ресурсу? Я попытался сам разобраться по коду но там сложно. > > file->accessed = now; > > в ./src/core/ngx_open_file_cache.c > > И потом в ngx_http_file_cache_update() не увидел что поле acessed пишется. > Может в другом месте где-то? Нет, при загрузке кэша с диска - в качестве времени последнего обращения будет использоватся время загрузки соответствующего элемента кэша. Соответственно не имеет особого смысла использовать время inactive, превышающее среднее время между перезапусками nginx'а. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Aug 19 23:02:21 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Aug 2019 02:02:21 +0300 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: References: <20190819212951.GP1877@mdounin.ru> Message-ID: <20190819230221.GT1877@mdounin.ru> Hello! On Mon, Aug 19, 2019 at 05:32:55PM -0400, Vladislavik wrote: > chunked_transfer_encoding on; > > Не может быть причиной? Нет - как видно из ответа в кэше, используется Content-Length, chunked transfer encoding не используется вообще. Не говоря уже о том, что эта директива со значением "on" не имеет смысла, это поведение по умолчанию. > Файл никто не переписывает, лежит и никак не меняется не обновляется, а > nginx порой отдает его обрезанным... Опять же из заголовков ответов в кэше очевидно, что это не так: Last-Modified: Sun, 18 Aug 2019 12:06:39 GMT Last-Modified: Sun, 18 Aug 2019 13:49:45 GMT То есть у файла менялся не только размер, но и дата последнего изменения. В файл явно кто-то лазил, как и чем - искать вам. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Aug 20 00:08:21 2019 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Mon, 19 Aug 2019 20:08:21 -0400 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: <20190819212951.GP1877@mdounin.ru> References: <20190819212951.GP1877@mdounin.ru> Message-ID: В общем, более менее разобрался, виноват был open_file_cache, интересная ситуация с ним выходит: у нас есть файл 10 кбайт, мы его запросили единожды и он попал в этот кэш. (если срок жизни кэша большой) Далее файл изменился, стал 15 кбайт и nginx при запросе файла отдает с диска уже измененный файл, НО обрезает его до длины, данные о которой все еще лежат в open_file_cache (10 кбайт) в итоге мы получаем обрезанный / не полный файл на выходе. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285346#msg-285346 From mdounin на mdounin.ru Tue Aug 20 09:44:30 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Aug 2019 12:44:30 +0300 Subject: =?UTF-8?B?UmU6INCR0LjRgtGL0LUg0YTQsNC50LvRiyDQsiDQutC10YjQtSDQv9GA0LggZ3pp?= =?UTF-8?B?cCDQvtGC0LLQtdGC0LDRhQ==?= In-Reply-To: References: <20190819212951.GP1877@mdounin.ru> Message-ID: <20190820094430.GU1877@mdounin.ru> Hello! On Mon, Aug 19, 2019 at 08:08:21PM -0400, Vladislavik wrote: > В общем, более менее разобрался, виноват был open_file_cache, интересная > ситуация с ним выходит: > у нас есть файл 10 кбайт, мы его запросили единожды и он попал в этот кэш. > (если срок жизни кэша большой) Далее файл изменился, стал 15 кбайт и nginx > при запросе файла отдает с диска уже измененный файл, НО обрезает его до > длины, данные о которой все еще лежат в open_file_cache (10 кбайт) в итоге > мы получаем обрезанный / не полный файл на выходе. "Виноват" open_file_cache быть не может - он может лишь сделать проблему, которую вы себе создали, изменяя файлы неатомарно, более видимой. А даты изменений приведены в предыдущем письме, речь явно не идёт о единичном случае. То есть у вас явно процесс, который наступает на одни и те же грабли раз за разом. Выключение open_file_cache проблему, скорее всего, спрячет до сложнонаблюдаемых масштабов, но не решит. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Aug 21 05:57:10 2019 From: nginx-forum на forum.nginx.org (glareboa) Date: Wed, 21 Aug 2019 01:57:10 -0400 Subject: =?UTF-8?B?0JrQvtC70LjRh9C10YHRgtCy0L4g0L7QtNC90L7QstGA0LXQvNC10L3QvdC+INC4?= =?UTF-8?B?0L/QvtC70YzQt9GD0LXQvNGL0YUgcHJveHkgcGFzcyDQsiDQsiDQvdC10YE=?= =?UTF-8?B?0LrQvtC70YzQutC40YUgIGxvY2F0aW9u?= Message-ID: <718b8f7aa0c67f2b08688744f74ba8df.NginxMailingListRussian@forum.nginx.org> Приветствую. Использую такую конструкцию. http { ... server { listen 80 default_server; ... location /qwe/ { proxy_pass "http://192.168.1.2:9000"; } location /qwe/ { proxy_pass "http://192.168.1.2:9001"; } location /rty/ { proxy_pass "http://192.168.1.2:9002"; } ... location /uio/ { proxy_pass "http://192.168.1.2:9012"; } } } Но в браузере отображаются только для 6 или меньше источников(http://192.168.1.2:90хх). Если вставить адреса http://192.168.1.2:9012 непосредственно в html-файл, отображаются все источники. Получается, что есть ограничение в nginx? Подскажите, плиз, есть какой-то параметр либо в настройках конфига, либо в опциях при компиляции nginx. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285357,285357#msg-285357 From vbart на nginx.com Fri Aug 23 20:16:39 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 23 Aug 2019 23:16:39 +0300 Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuMTAuMA==?= Message-ID: <2081103.AVSnKMb9BT@vbart-workstation> Всем привет. Рад сообщить о выпуске новой версии NGINX Unit. Этот релиз в основном включает ряд улучшений в поддержке приложений на разных языках; в частности, добавлена поддержка входящих соединений по протоколу WebSocket. Пока это коснулось только Node.js. На очереди - поддержка в Java-модуле, которая уже почти завершена. Чтобы принимать WebSocket-соединения в приложениях Node.js, вместо родного объекта сервера воспользуйтесь объектом из нашего модуля unit-http: var webSocketServer = require('unit-http/websocket').server; Другой ожидаемой возможностью в этом релизе стало вычленение PATH_INFO из пути запроса в PHP-модуле. Теперь Unit самостоятельно обрабатывает запросы вида /app.php/some/path?some=args, которые иногда по старинке используются для реализации семантических URL-ов. Изменения в Unit 1.10.0 22.08.2019 *) Изменение: cookies в маршрутах теперь сопоставляются с учетом регистра. *) Изменение: уменьшен уровень логирования распространенных ошибок, возникающих, когда клиенты закрывают соединения. *) Изменение: невостребованная опция "--include=" удалена из скрипта ./configure для Perl-модуля. *) Добавление: встроенная реализация WebSocket-сервера для Node.js. *) Добавление: вычленение PATH_INFO из URI запроса в PHP. *) Добавление: маршрутизация запросов на основе схемы (HTTP или HTTPS). *) Добавление: улучшена совместимость API c Node.js 11.10 и выше. *) Исправление: ошибка переконфигурации при отсутствии объекта "listeners" или "applications". *) Исправление: возможный сбой при применении конфигурации большого объема. Кроме того, с удовольствием отмечаю, что к работе над проектом подключились два новых разработчика: Axel Duch и Tiago de Bem Natel de Moura. Аксель уже реализовал для этого релиза сопоставление схемы и сейчас трудится над дальнейшим расширением возможностей маршрутизации запросов по адресам отправителя и получателя. Параллельно Тьяго добился заметных успехов, работая над изоляцией процессов приложений. За его трудом над поддержкой пространств имен Linux в Unit можно наблюдать на GitHub: - https://github.com/nginx/unit/pull/289 Также смотрите его сообщение с описанием предлагаемой функциональности: - https://mailman.nginx.org/pipermail/nginx/2019-August/058321.html Тем временем мы практически закончили работу над первичной поддержкой проксирования и раздачи статики; с большой вероятностью новые возможности (для начала в самом базовом виде) выйдут уже в следующем релизе, который намечен на эту осень. Следите за обновлениями. -- Валентин Бартенев From nginx-forum на forum.nginx.org Mon Aug 26 01:54:01 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sun, 25 Aug 2019 21:54:01 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjEwLjA=?= In-Reply-To: <2081103.AVSnKMb9BT@vbart-workstation> References: <2081103.AVSnKMb9BT@vbart-workstation> Message-ID: <4a7a42c5d4790d33d01636a0c2c22dd7.NginxMailingListRussian@forum.nginx.org> Сделал простой бенчмарк (wrk -c 50 -d 30s -t 50 http://127.0.0.1) вашего Hello World примера https://www.nginx.com/blog/nginx-unit-1-5-available-now/#go-node-js-applications И сравнил с HTTP сервером что мы юзаем (uWebSockets) Результаты: Unit - Requests/sec: 17384 uWebSockets - Requests/sec: 112328 Я это пишу не ради тролинга и понимаю что тесты Hello World мало что говорят, но не нашел ваших сравнительных тестов с конкурентами. Но ваши конкуренты тесты проводят и делают себе релкаму: https://github.com/uNetworking/uWebSockets/tree/master/benchmarks Я думаю вам нужно проф тесты провести и выложить результаты. Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285390,285400#msg-285400 From vbart на nginx.com Mon Aug 26 12:25:11 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 26 Aug 2019 15:25:11 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjEwLjA=?= In-Reply-To: <4a7a42c5d4790d33d01636a0c2c22dd7.NginxMailingListRussian@forum.nginx.org> References: <2081103.AVSnKMb9BT@vbart-workstation> <4a7a42c5d4790d33d01636a0c2c22dd7.NginxMailingListRussian@forum.nginx.org> Message-ID: <2145153.Qye9C7YK05@vbart-laptop> On Monday, 26 August 2019 04:54:01 MSK S.A.N wrote: > Сделал простой бенчмарк (wrk -c 50 -d 30s -t 50 http://127.0.0.1) вашего > Hello World примера > https://www.nginx.com/blog/nginx-unit-1-5-available-now/#go-node-js-applications > > И сравнил с HTTP сервером что мы юзаем (uWebSockets) > > Результаты: > Unit - Requests/sec: 17384 > uWebSockets - Requests/sec: 112328 Ну что ж, будем значит Hello World разгонять. =) > > Я это пишу не ради тролинга и понимаю что тесты Hello World мало что > говорят, но не нашел ваших сравнительных тестов с конкурентами. > Но ваши конкуренты тесты проводят и делают себе релкаму: > https://github.com/uNetworking/uWebSockets/tree/master/benchmarks > Я думаю вам нужно проф тесты провести и выложить результаты. > > Спасибо. > [..] Каждый разработчик может провести таким образом тест, чтобы его детище было на первом месте. При этом даже при желании сделать тест максимально объективным - это не получится, поскольку заметно различается уровень знаний о своем продукте, его нюансах, и о конкурентах. Есть тут один очень популярный сервер, который (исключительно по утверждениям автора) в хеллоу ворлд тестах затыкает всех за пояс: http://gwan.com/benchmark/babel.html#allservers Ему уже лет 10, но что-то про живых пользователей практически ничего не слышно. Если мы будем тратить время на публикацию подобных тестов и рисование красивых графиков, то вот с учетом сказанного выше - это как-то реально поможет? Единственный правильный способ тестирования - тестирование на реальных нагрузках со своими собственными приложениями и задачами. P.S. Чаще всего главное вовсе не RPS на 50 соединениях, а кто быстрее начнет умирать под нагрузкой. И это не обязательно будет тот, кто больше всех RPS показывает: https://habr.com/ru/post/431818/ -- Валентин Бартенев From nginx-forum на forum.nginx.org Mon Aug 26 13:11:21 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Mon, 26 Aug 2019 09:11:21 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjEwLjA=?= In-Reply-To: <2145153.Qye9C7YK05@vbart-laptop> References: <2145153.Qye9C7YK05@vbart-laptop> Message-ID: > Единственный правильный способ тестирования - тестирование на реальных > нагрузках со своими собственными приложениями и задачами. Согласен, но это делают потом, на ранней стадии тестят синтетикой, просто чтобы примерно оценить оверхед, когда они увидят 6х замедления, это может отбить желания тестить реально. Меня смутил такой большой оверхед, я потом вместо Unit поставил Nginx, получил результат в ~2x лучше по сравнению с Unit. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285390,285404#msg-285404 From valery+nginxru на grid.net.ru Mon Aug 26 15:54:57 2019 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Mon, 26 Aug 2019 17:54:57 +0200 Subject: =?UTF-8?B?UmU6ICoqKioqU1BBTSoqKioqIFJlOiDQoNC10LvQuNC3IFVuaXQgMS4xMC4w?= In-Reply-To: <2145153.Qye9C7YK05@vbart-laptop> References: <2145153.Qye9C7YK05@vbart-laptop> Message-ID: <02089111-cf4e-3c85-92f1-57ff3773c79b@grid.net.ru> On 26-08-19 14:25, Валентин Бартенев wrote: > Ему уже лет 10, но что-то про живых пользователей практически ничего > не слышно. Ну как же, Пьер писал об этом: http://gwan.com/blog/20140901.html > Если мы будем тратить время на публикацию подобных тестов и рисование > красивых графиков, то вот с учетом сказанного выше - это как-то > реально поможет? Каждый вправе продвигать свой продукт любым способом, если это не наносит ущерб другим участникам рынка, среде и потребителям. А вот ты как раз ходишь по серой линии применяя ожидания от nginx к G-WAN. G-WAN не предназначен для масс-маркета (или наоборот?). Масс-маркет не понимает его сильные стороны. Ровно так же как в nginx нет достаточного уровня расширяемости, поддержка HTTP/2.0 (а также 1.1) не полная и т.д. Да, графики субъективны, но не нужно из-за этого записывать в андердоги. -- Val From identw на gmail.com Tue Aug 27 10:24:03 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Tue, 27 Aug 2019 15:24:03 +0500 Subject: =?UTF-8?B?bmdpbngg0L/QvtC70L3QvtGB0YLRjNGOINC30LDQs9GA0YPQttCw0LXRgiDQstC1?= =?UTF-8?B?0YHRjCDQv9GA0L7RhtC10YHRgdC+0YAg0L/RgNC4IHJlbG9hZCdl?= Message-ID: <16c001b3-fdf2-155c-e9b9-bf1604ccfd14@gmail.com> Версия: 1.14.2 ОС: ubuntu 16.04 Процессор: Intel Core i7-6700 CPU 3.40GHz Средняя нагрузка: 5 000 rps, пиковые значения 12 000 rps.  Статики практически нет, все запросы проксируются либо на бэкенды с nodejs через proxy_pass либо на php-fpm через fastcgi_pass. Виртуальных хостов 16, несколько из них имеют среднюю нагрузку 2K rps, остальные 500 rps. С бэкендами nodejs включен keepalive, с php отключен. Кроме nginx на сервере ничего нет. Проблема в том, что при reload'e конфигурации, несколько минут nginx начинает жрать весь процессор, все ядра под 100%, и запросы начинают обрабатываться медленно либо совсем сбрасываются, отсюда куча ошибок у клиентов. Такая проблема наблюдается только на серверах, где много виртуальных хостов (15-30). На серверах с аналогичной нагрузкой, но например 1-3 виртуальными хостами. Таких проблем не наблюдаю. Может быть кто-нибудь подскажет, как можно это оптимизировать, что-то подкрутить. Может можно как-то плавнее релоадить, чтобы медленее, но при этом нагрузка на CPU как-то плавнее распределялась. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 From mdounin на mdounin.ru Tue Aug 27 11:03:21 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 27 Aug 2019 14:03:21 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <16c001b3-fdf2-155c-e9b9-bf1604ccfd14@gmail.com> References: <16c001b3-fdf2-155c-e9b9-bf1604ccfd14@gmail.com> Message-ID: <20190827110321.GZ1877@mdounin.ru> Hello! On Tue, Aug 27, 2019 at 03:24:03PM +0500, Dmitry Sergeev wrote: > Версия: 1.14.2 > ОС: ubuntu 16.04 > Процессор: Intel Core i7-6700 CPU 3.40GHz > > Средняя нагрузка: 5 000 rps, пиковые значения 12 000 rps.  Статики > практически нет, все запросы проксируются либо на бэкенды с nodejs через > proxy_pass либо на php-fpm через fastcgi_pass. Виртуальных хостов 16, > несколько из них имеют среднюю нагрузку 2K rps, остальные 500 rps. > > С бэкендами nodejs включен keepalive, с php отключен. > > Кроме nginx на сервере ничего нет. > > Проблема в том, что при reload'e конфигурации, несколько минут nginx > начинает жрать весь процессор, все ядра под 100%, и запросы начинают > обрабатываться медленно либо совсем сбрасываются, отсюда куча ошибок у > клиентов. Такая проблема наблюдается только на серверах, где много > виртуальных хостов (15-30). На серверах с аналогичной нагрузкой, но > например 1-3 виртуальными хостами. Таких проблем не наблюдаю. > > Может быть кто-нибудь подскажет, как можно это оптимизировать, что-то > подкрутить. Может можно как-то плавнее релоадить, чтобы медленее, но при > этом нагрузка на CPU как-то плавнее распределялась. Для начала - имеет смысл посмотреть на количество доступной памяти. При релоаде количество рабочих процессов увеличивается вдвое, и если памяти мало - система может уходить в свап с печальными последствиями. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Aug 27 11:17:46 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 27 Aug 2019 14:17:46 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <1ad57e3d-561d-e1b6-ef16-4a669676a64c@gmail.com> References: <16c001b3-fdf2-155c-e9b9-bf1604ccfd14@gmail.com> <20190827110321.GZ1877@mdounin.ru> <1ad57e3d-561d-e1b6-ef16-4a669676a64c@gmail.com> Message-ID: <20190827111746.GB1877@mdounin.ru> Hello! On Tue, Aug 27, 2019 at 04:10:31PM +0500, Dmitry Sergeev wrote: > Добрый день. Спасибо за ответ! Пожалуйста. Не надо отвечать мне лично, от этого карма портится. Спасибо. > На сервере всего 64GB памяти, nginx кушает обычно около 2GB при релоадет > не сильно больше - 2-3GB, swap не задействуется. Свободно памяти обычно > больше 60GB. > > Сейчас протестил. При релоаде съедает весь проц ровно 35-40 секунд. > Провел около 10 тестов, время всегда примерно такое. Значит проблема не в памяти, а в чём-то ещё. Что в конфиге? -- Maxim Dounin http://mdounin.ru/ From identw на gmail.com Tue Aug 27 11:39:48 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Tue, 27 Aug 2019 16:39:48 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <20190827111746.GB1877@mdounin.ru> References: <16c001b3-fdf2-155c-e9b9-bf1604ccfd14@gmail.com> <20190827110321.GZ1877@mdounin.ru> <1ad57e3d-561d-e1b6-ef16-4a669676a64c@gmail.com> <20190827111746.GB1877@mdounin.ru> Message-ID: Прошу прощения, особенности почтового клиента. Конфиг такой: user www-data; worker_processes auto; worker_cpu_affinity auto; worker_rlimit_nofile 65000; pid /var/run/nginx.pid; events {     worker_connections 10000;     multi_accept off; } http {     ##     # Basic Settings     ##     sendfile on;     tcp_nopush on;     tcp_nodelay on;     keepalive_timeout 10;     types_hash_max_size 2048;     server_tokens on;     include /etc/nginx/mime.types;     default_type application/octet-stream;     client_body_timeout 60;     client_header_timeout 60;     send_timeout 60;     reset_timedout_connection on;     ##     # Logging Settings     ##     access_log off;     error_log /var/log/nginx/error.log;     #     # Caching FS     #     open_file_cache max=10000;     open_file_cache_errors on;     ##     # Gzip Settings     ##     gzip on;     gzip_disable "msie6";     gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript application/octet-stream;     ##     # Maps     ##     map $status $status_error     {             "~*^(1|2|3)"      0;             default         1;     }     ##     # Virtual Host Configs     ##     include /etc/nginx/conf.d/*.conf;     include /etc/nginx/sites-enabled/*; И пример конфига виртуальных хостов для nodejs и php: upstream nodejs_backend {     ip_hash;     keepalive 32;     server server1:4201 weight=1;     server server2:4201 weight=3; } log_format file_c escape=json '{"HOST":"$host","LOCATION":"$location","IP":"$remote_addr","PROJECT":"nodejs_backend","HTTP_STATUS":"$status","RESPONSE_TIME":"$request_time","UPSTREAM_CONNECT_TIME":"$upstream_connect_time","UPSTREAM_RESPONSE_TIME":"$upstream_response_time","REQUEST_METHOD":"$request_method","REQUEST_FILE":"$uri","ARGS":"$args","BYTES_SENT":"$bytes_sent","USER_AGENT":"$http_user_agent","HTTP_REFERER":"$http_referer","ENVIRONMENT":"production","AKAMAI_IP":"$http_true_client_ip","HEADER_ACCEPT":"$http_accept","HEADER_ACCEPT_LANGUAGE":"$http_accept_language","HEADER_CONTENT_LANGUAGE":"$http_content_language","HEADER_CONTENT_TYPE":"$http_content_type","BODY":"$request_body"}'; server {     listen [::]:80;     listen 80;     # SSL     listen [::]:443 ssl http2;     listen 443 ssl http2;     ssl_certificate /etc/nginx/ssl/fullchain.pem;     ssl_certificate_key /etc/nginx/ssl/privkey.pem;     server_name nodejs_domain;     root /var/www/nodejs_domain/docroot;     ###Logs     # Local logs     access_log /var/log/nginx/nodejs_domain_access.log file_nodejs_backend if=$status_error;     error_log /var/log/nginx/nodejs_domain_error.log;     location = /robots.txt     {         set $location "robots";         return 200 "User-agent: *\nDisallow: /\n";     }     location = /https:/nodejs_domain     {         set $location "ssl_checker";         return 200 "for ssl checker\n";     }     location ~ /\.(git|svn|hg)     {             deny all;     }     location /     {         try_files /bpcZzfcaG82kpcm9Xxic8hWJ89YjqrJCRihmHGGmBqFnU6gV @backend;     }     location @backend     {         set $location "nodejs";         proxy_pass http://nodejs_backend;         proxy_http_version 1.1;         proxy_set_header Connection "";         proxy_read_timeout 10s;         proxy_set_header Host $host;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;     }     location /.well-known     {         set $location "well-known";         root   /usr/share/nginx/html;     } } пример конфига для php: upstream php_backend {     ip_hash;     server server6:4301 weight=1; } log_format file_php_domain escape=json '{"HOST":"$host","LOCATION":"$location","IP":"$remote_addr","PROJECT":"php_backend","HTTP_STATUS":"$status","RESPONSE_TIME":"$request_time","UPSTREAM_CONNECT_TIME":"$upstream_connect_time","UPSTREAM_RESPONSE_TIME":"$upstream_response_time","REQUEST_METHOD":"$request_method","REQUEST_FILE":"$uri","ARGS":"$args","BYTES_SENT":"$bytes_sent","USER_AGENT":"$http_user_agent","HTTP_REFERER":"$http_referer","ENVIRONMENT":"production","AKAMAI_IP":"$http_true_client_ip","HEADER_ACCEPT":"$http_accept","HEADER_ACCEPT_LANGUAGE":"$http_accept_language","HEADER_CONTENT_LANGUAGE":"$http_content_language","HEADER_CONTENT_TYPE":"$http_content_type","BODY":"$request_body"}'; server {     listen [::]:80;     listen 80;     listen [::]:443 ssl http2;     listen 443 ssl http2;     ssl_certificate /etc/nginx/ssl/fullchain.pem;     ssl_certificate_key /etc/nginx/ssl/privkey.pem;     server_name php_domain;     root /var/www/php_domain/docroot;     access_log /var/log/nginx/php_domain_access.log file_php_domain if=$status_error;     error_log /var/log/nginx/php_domain_error.log;     location = /robots.txt     {         set $location "robots";         return 200 "User-agent: *\nDisallow: /\n";     }     location = /https:/php_domain     {         set $location "ssl_checker";         return 200 "for ssl checker\n";     }     location ~ /\.(git|svn|hg)     {             deny all;     }     location ~* ^/.*\.php$     {         try_files /DsHs5OrKH8nAkZAYQVbWqwWN1kQmRC9rISzowfDiHPOJqJT3 @backend;     }     location /     {         index index.html index.php;         set $location "default";     }     location ~* ^/.*\.html$     {         set $location "html";         add_header P3P 'policyref="../../../common/site/p3p.xml", CP="NOI CURa ADMa DEVa TAIa"';         expires epoch;     }     location ~* ^/.*\.(eot|webp|plist|png|jpg|jpeg|ttf|otf|woff|woff2|mp3|ogg|swf|js|json|atlas)$     {         set $location "static";         add_header Access-Control-Allow-Origin *;         add_header Access-Control-Expose-Headers "Date";         expires max;     }     location ~* ^/.*\.(css|gif|ico|mpeg|mpg|mp4|svg)$     {         set $location "static";         expires max;     }     location @backend     {         set $location "php";         fastcgi_pass php_backend;         include fastcgi_params;         fastcgi_index index.php;         fastcgi_connect_timeout 10s;         fastcgi_read_timeout 10s;         fastcgi_send_timeout 10s;         fastcgi_param X_HOST $remote_addr;         fastcgi_param SCRIPT_FILENAME /docroot$fastcgi_script_name;     }     location = /main/site/index.html     {         set $location "index";         add_header P3P 'policyref="../../../common/site/p3p.xml", CP="NOI CURa ADMa DEVa TAIa"';         expires epoch;     }     location /.well-known     {         set $location "well-known";         root   /usr/share/nginx/html;     } } Остальные виртуальные хосты либо похожие либо чуть отличаются. On 27/08/2019 16:17, Maxim Dounin wrote: > Hello! > > On Tue, Aug 27, 2019 at 04:10:31PM +0500, Dmitry Sergeev wrote: > >> Добрый день. Спасибо за ответ! > Пожалуйста. Не надо отвечать мне лично, от этого карма портится. > Спасибо. > >> На сервере всего 64GB памяти, nginx кушает обычно около 2GB при релоадет >> не сильно больше - 2-3GB, swap не задействуется. Свободно памяти обычно >> больше 60GB. >> >> Сейчас протестил. При релоаде съедает весь проц ровно 35-40 секунд. >> Провел около 10 тестов, время всегда примерно такое. > Значит проблема не в памяти, а в чём-то ещё. Что в конфиге? > -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 From identw на gmail.com Tue Aug 27 11:45:35 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Tue, 27 Aug 2019 16:45:35 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: References: <16c001b3-fdf2-155c-e9b9-bf1604ccfd14@gmail.com> <20190827110321.GZ1877@mdounin.ru> <1ad57e3d-561d-e1b6-ef16-4a669676a64c@gmail.com> <20190827111746.GB1877@mdounin.ru> Message-ID: <5c4a3e7b-ea3c-10cf-ddfc-6ebc7540e908@gmail.com> Еще нюанс забыл указать. nginx компилировал с модулем vts. Возможно с ним проблема. Проверю это. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 From identw на gmail.com Tue Aug 27 13:08:20 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Tue, 27 Aug 2019 18:08:20 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <5c4a3e7b-ea3c-10cf-ddfc-6ebc7540e908@gmail.com> References: <16c001b3-fdf2-155c-e9b9-bf1604ccfd14@gmail.com> <20190827110321.GZ1877@mdounin.ru> <1ad57e3d-561d-e1b6-ef16-4a669676a64c@gmail.com> <20190827111746.GB1877@mdounin.ru> <5c4a3e7b-ea3c-10cf-ddfc-6ebc7540e908@gmail.com> Message-ID: <1f96b9d5-8827-e8cd-69e3-ebf38eea2579@gmail.com> Затестил. Без модуля vts тоже самое поведение. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 From identw на gmail.com Tue Aug 27 17:08:07 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Tue, 27 Aug 2019 22:08:07 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <1f96b9d5-8827-e8cd-69e3-ebf38eea2579@gmail.com> References: <16c001b3-fdf2-155c-e9b9-bf1604ccfd14@gmail.com> <20190827110321.GZ1877@mdounin.ru> <1ad57e3d-561d-e1b6-ef16-4a669676a64c@gmail.com> <20190827111746.GB1877@mdounin.ru> <5c4a3e7b-ea3c-10cf-ddfc-6ebc7540e908@gmail.com> <1f96b9d5-8827-e8cd-69e3-ebf38eea2579@gmail.com> Message-ID: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> Нашел причину, проблема была в старом ssl - openssl 1.0.1u. perf top показывал: http://dl3.joxi.net/drive/2019/08/27/0030/2608/1985072/72/88257baf85.jpg Попробвал обычную версию 1.0.2g и проблемы ушли. Осталось уговорить менеджеров забить на 1% старых ssl клиентов. On 27/08/2019 18:08, Dmitry Sergeev wrote: > Затестил. Без модуля vts тоже самое поведение. > > -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 From nginx-forum на forum.nginx.org Tue Aug 27 18:25:52 2019 From: nginx-forum на forum.nginx.org (ngnx8810773a83) Date: Tue, 27 Aug 2019 14:25:52 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> Message-ID: А с какими старыми клиентами не совместим 1.0.2g, который сам тоже не слишком свеж ? В мае был релиз 1.0.2s а g, это гдето в марте 16 года было. Если Вы про sslv2 то оно там есть.у меня специально для этих целей живет нгинкс собранный с 1.0.2m. если кастомный openssl собиратете через сборку nginx с --with-openssl , то ему можно пихнуть кастомные параметры в configure через --with-openssl-opt для всяких оптимизаций. если совсем какито раритеты, то пихните туда enable-weak-ssl-ciphers enable-ssl2.. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285412,285421#msg-285421 From nginx-forum на forum.nginx.org Tue Aug 27 19:00:49 2019 From: nginx-forum на forum.nginx.org (grey) Date: Tue, 27 Aug 2019 15:00:49 -0400 Subject: =?UTF-8?B?bmdpbngg0Lgg0LDQv9C/0LDRgNCw0YLQvdC+0LUg0YjQuNGE0YDQvtCy0LDQvdC4?= =?UTF-8?B?0LU=?= Message-ID: <7fcc5e02d4cdc8a9ea0a1c20ed80e935.NginxMailingListRussian@forum.nginx.org> Привет! Сорри, если спрошу глупость, но... выбираю между двумя серверами - в одном установлен процессор с поддержкой аппаратного шифрования. Подскажите, будет ли прирост в производительности для сайтов работающих на https? Умеет ли nginx исполосовать эти возможности процессора? Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285422,285422#msg-285422 From balroga3 на yandex.ru Tue Aug 27 20:50:18 2019 From: balroga3 на yandex.ru (Pavel) Date: Tue, 27 Aug 2019 23:50:18 +0300 Subject: =?UTF-8?B?0JrQsNC6INC30LDQv9C40YHQsNGC0Ywg0LrQu9GO0YfQuCBwcmUtbWFzdGVyINC+?= =?UTF-8?B?0YIgdGxzLdGB0L7QtdC00LjQvdC10L3QuNC5LCDQvtCx0YDQsNCx0LDRgtGL?= =?UTF-8?B?0LLQsNC10LzRi9GFIG5naW54Pw==?= Message-ID: <1182867115.20190827235018@yandex.ru> Здравствуйте. Мы состоим в реестре организаторов распространения информации и поэтому обязаны предоставлять в надзорный орган ключи tls сессий. Для таких случаев существует механизм по перехвату вызовов библиотеки openssl: https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/ Суть простая - перед запуском демона, обрабатывающего TLS-соединения клиентов, через LD_PRELOAD подгружается эта библиотека и она сбрасывает в текстовый файл, указанный в переменой SSLKEYLOGFILE, ключи pre-master. Эта схема срабатывает с апачем, но с энжинксом ключи не пишутся. Нет ли идей или подсказок из-за чего это может быть и как вообще можно записать эти самые pre-master keys в энжинксе? Заранее спасибо. P.S. Пример файла с записанными ключами: # SSL key logfile generated by sslkeylog.c SERVER_HANDSHAKE_TRAFFIC_SECRET 077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 080b47a6fea27728f15c4cb70bc7478aa4e9bf5b554e8018d9462a48fff90e9514ca6dc410154c730 CLIENT_HANDSHAKE_TRAFFIC_SECRET 077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 883ec12435f3d53bc0e42f5fd0a26d006955064747786e21cda18bfa4e2b5fffe147860114036881d EXPORTER_SECRET 077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 267a950066d3c4bcc2fd3bb50287b045c213737d018f15c166dc82ce7eab5f4b4dcb3939bc11db1ec7c918a321b5d9f7 SERVER_TRAFFIC_SECRET_0 077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da cdd2a750c617a721dc93595b99852a4a2436a4fb2f843617b51f7bc0de3b9a88faa5b2b5256fa4230df7fdf9f CLIENT_TRAFFIC_SECRET_0 077dca0cfc53f1ba5105d7e67e1cb8aa7fba40db73580bb0997498b3260a06da 0afb1f7f7c5d8fc9aefc8aae3111045d7e837e3f87de600fcf44a583f45a313d703235e6c80f51d1fa614d96f P.P.S. Запускаю энжинкс с этой библиотекой для записи ключей через systemd так: #cat /etc/systemd/system/nginx.service.d/override.conf [Service] Environment=SSLKEYLOGFILE=/tmp/premaster.txt Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so Через lsof видно, что эта библиотека для записи ключей энжиксом подгружается (здесь я проверяю и мастер и воркер): # lsof -n -p 10313 |grep ssl nginx 10313 root mem REG 254,1 442984 3255 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 nginx 10313 root mem REG 254,1 14224 20914 /usr/local/lib/libsslkeylog.so # lsof -n -p 10314 |grep ssl nginx 10314 www-data mem REG 254,1 442984 3255 /usr/lib/x86_64-linux-gnu/libssl.so.1.1 nginx 10314 www-data mem REG 254,1 14224 20914 /usr/local/lib/libsslkeylog.so но тем не менее ключи в файл при обращении к энжинксу по https не пишутся. From identw на gmail.com Wed Aug 28 16:18:44 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Wed, 28 Aug 2019 21:18:44 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> Message-ID: Вообще мне это конечно помогло, но  не полностью. На версии 1.0.2g во время reload'а проц грузит полностью  около 5-10 секунд (вместо 40-300 секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у клиентов. Но в целом проблема осталась, просто теперь она не так сильно беспокоит. Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с нагрузкой, и смотреть можно ли как-то повлиять на это. Если конечно тут не подскажут, что еще можно подкрутить. Насчет старых клиентов, точно не могу сказать, но есть такой кейс http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я хорошо не изучал этот вопрос, но факт остается, на старой версии openssl ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты с очень старым ssl. On 27/08/2019 23:25, ngnx8810773a83 wrote: > А с какими старыми клиентами не совместим 1.0.2g, который сам тоже не > слишком свеж ? В мае был релиз 1.0.2s а g, это гдето в марте 16 года было. > > Если Вы про sslv2 то оно там есть.у меня специально для этих целей живет > нгинкс собранный с 1.0.2m. > если кастомный openssl собиратете через сборку nginx с --with-openssl , то > ему можно пихнуть кастомные параметры в configure через --with-openssl-opt > для всяких оптимизаций. если совсем какито раритеты, то пихните туда > enable-weak-ssl-ciphers enable-ssl2.. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285412,285421#msg-285421 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 From chipitsine на gmail.com Wed Aug 28 17:34:49 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 28 Aug 2019 22:34:49 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> Message-ID: А ради интереса, можете для истории снять SSL labs server test для двух ваших версий openssl? У него есть табличка с эмуляцией хендшейков, будут в ней отличия или нет? On Wed, Aug 28, 2019, 9:19 PM Dmitry Sergeev wrote: > Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во > время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300 > секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у > клиентов. Но в целом проблема осталась, просто теперь она не так сильно > беспокоит. > > Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с > нагрузкой, и смотреть можно ли как-то повлиять на это. > Если конечно тут не подскажут, что еще можно подкрутить. > > Насчет старых клиентов, точно не могу сказать, но есть такой кейс > http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я > хорошо не изучал этот вопрос, но факт остается, на старой версии openssl > ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты > с очень старым ssl. > > On 27/08/2019 23:25, ngnx8810773a83 wrote: > > А с какими старыми клиентами не совместим 1.0.2g, который сам тоже не > > слишком свеж ? В мае был релиз 1.0.2s а g, это гдето в марте 16 года > было. > > > > Если Вы про sslv2 то оно там есть.у меня специально для этих целей живет > > нгинкс собранный с 1.0.2m. > > если кастомный openssl собиратете через сборку nginx с --with-openssl , > то > > ему можно пихнуть кастомные параметры в configure через > --with-openssl-opt > > для всяких оптимизаций. если совсем какито раритеты, то пихните туда > > enable-weak-ssl-ciphers enable-ssl2.. > > > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,285412,285421#msg-285421 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > Kind regards > Dmitry Sergeev > Tel: +7 (951) 129-75-72 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Aug 29 23:51:34 2019 From: nginx-forum на forum.nginx.org (analytic) Date: Thu, 29 Aug 2019 19:51:34 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC90LUg0LTQvtCx0LDQstC70Y/QtdGCINC90LXQvtCx0YXQvtC0?= =?UTF-8?B?0LjQvNGL0LUg0LHQuNCx0LvQuNC+0YLQtdC60Lgg0L/RgNC4INGB0LHQvtGA?= =?UTF-8?B?0LrQtSDQuNC3INC40YHRhdC+0LTQvdC40LrQvtCyINGB0L4g0YHRgtC+0YA=?= =?UTF-8?B?0L7QvdC90LjQvNC4INC80L7QtNGD0Y/QvNC40Lg=?= In-Reply-To: References: Message-ID: <28b9c73173576f7aca5ed5a7a942a2dc.NginxMailingListRussian@forum.nginx.org> Для тех у кого будет такая же проблема. Я так и не понял почему checkinstall не подтягивает при сборке все зависимости в собираемый .deb пакет, но если возникает ошибка Nginx связанная с библиотекой libbrotlidec.so.1, то ее нужно установить вручную отдельно. sudo apt install libbrotli1 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285435,285444#msg-285444 From nick на methodlab.info Fri Aug 30 06:43:55 2019 From: nick на methodlab.info (Nick Lavlinsky - Method Lab) Date: Fri, 30 Aug 2019 09:43:55 +0300 Subject: =?UTF-8?B?UmU6IE5naW54INC90LUg0LTQvtCx0LDQstC70Y/QtdGCINC90LXQvtCx0YXQvtC0?= =?UTF-8?B?0LjQvNGL0LUg0LHQuNCx0LvQuNC+0YLQtdC60Lgg0L/RgNC4INGB0LHQvtGA?= =?UTF-8?B?0LrQtSDQuNC3INC40YHRhdC+0LTQvdC40LrQvtCyINGB0L4g0YHRgtC+0YA=?= =?UTF-8?B?0L7QvdC90LjQvNC4INC80L7QtNGD0Y/QvNC40Lg=?= In-Reply-To: <28b9c73173576f7aca5ed5a7a942a2dc.NginxMailingListRussian@forum.nginx.org> References: <28b9c73173576f7aca5ed5a7a942a2dc.NginxMailingListRussian@forum.nginx.org> Message-ID: Приветствую! Если речь про сборку Nginx c модулем brotli, то как раз недавно выпустил об этом подробное видео: https://www.youtube.com/watch?v=WJUS35TQkPc 30.08.2019 2:51, analytic пишет: > Для тех у кого будет такая же проблема. Я так и не понял почему checkinstall > не подтягивает при сборке все зависимости в собираемый .deb пакет, но если > возникает ошибка Nginx связанная с библиотекой libbrotlidec.so.1, то ее > нужно установить вручную отдельно. > sudo apt install libbrotli1 > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285435,285444#msg-285444 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Лавлинский Николай, Метод Лаб: делаем правильно! www.methodlab.ru +7 (925) 507-98-19 From mdounin на mdounin.ru Fri Aug 30 12:49:12 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 30 Aug 2019 15:49:12 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> Message-ID: <20190830124912.GE1877@mdounin.ru> Hello! On Wed, Aug 28, 2019 at 09:18:44PM +0500, Dmitry Sergeev wrote: > Вообще мне это конечно помогло, но  не полностью. На версии 1.0.2g во > время reload'а проц грузит полностью  около 5-10 секунд (вместо 40-300 > секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у > клиентов. Но в целом проблема осталась, просто теперь она не так сильно > беспокоит. > > Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с > нагрузкой, и смотреть можно ли как-то повлиять на это. > Если конечно тут не подскажут, что еще можно подкрутить. Судя по perf top, проблема в том, что клиенты после reload'а переустанавливают соединения, и это выливается в полный SSL handshake - что и приводит к потреблению CPU. Посмотреть стоит на: - ssl_session_cache - в конфиге его, судя по всему, нет (или соответствующие части конфига не показаны); - сертификаты, в частности - их битность (just in case, RSA более 2048 использовать не надо, это тупо очень дорого с точки зрения процессора) и тип (лучше использовать ECDSA, но тут уже может встать вопрос совместимости; при желании можно использовать и RSA и ECDSA одновременно); - используемые шифры, особенно - шифры с классическим DH для обмена ключами (по умолчанию эти шифры не используются начиная с nginx 1.11.0, но некоторые любят указывать ssl_dhparam в конфиге, да ещё и с параметрами большой битности; не надо так); > Насчет старых клиентов, точно не могу сказать, но есть такой кейс > http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я > хорошо не изучал этот вопрос, но факт остается, на старой версии openssl > ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты > с очень старым ssl. Как уже говорилось в треде по ссылке, использование OpenSSL 1.0.1u автоматически означет, что HTTP/2 с большинством клиентов работать не будет. С учётом "listen ... http2" в конфиге - обновление до 1.0.2 могло "помочь" просто за счёт того, что HTTP/2 заработал, и количество устанавливаемых соединений соответственно уменьшилось. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Aug 30 13:10:44 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 30 Aug 2019 16:10:44 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/QuNGB0LDRgtGMINC60LvRjtGH0LggcHJlLW1hc3Rl?= =?UTF-8?B?ciDQvtGCIHRscy3RgdC+0LXQtNC40L3QtdC90LjQuSwg0L7QsdGA0LDQsdCw?= =?UTF-8?B?0YLRi9Cy0LDQtdC80YvRhSBuZ2lueD8=?= In-Reply-To: <1182867115.20190827235018@yandex.ru> References: <1182867115.20190827235018@yandex.ru> Message-ID: <20190830131044.GG1877@mdounin.ru> Hello! On Tue, Aug 27, 2019 at 11:50:18PM +0300, Pavel wrote: > Мы состоим в реестре организаторов распространения информации и > поэтому обязаны предоставлять в надзорный орган ключи tls сессий. > > Для таких случаев существует механизм по перехвату вызовов библиотеки > openssl: https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/ > Суть простая - перед запуском демона, обрабатывающего TLS-соединения > клиентов, через LD_PRELOAD подгружается эта библиотека и она > сбрасывает в текстовый файл, указанный в переменой SSLKEYLOGFILE, ключи pre-master. > > Эта схема срабатывает с апачем, но с энжинксом ключи не пишутся. Нет > ли идей или подсказок из-за чего это может быть и как вообще можно записать > эти самые pre-master keys в энжинксе? [...] > [Service] > Environment=SSLKEYLOGFILE=/tmp/premaster.txt > Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so [...] > но тем не менее ключи в файл при обращении к энжинксу по https не > пишутся. Скорее всего причина в том, что переменные окружения очищаются при запуске, подробнее тут: http://nginx.org/r/env -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Aug 30 13:45:32 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 30 Aug 2019 16:45:32 +0300 Subject: =?UTF-8?B?UmU6INCa0L7Qu9C40YfQtdGB0YLQstC+INC+0LTQvdC+0LLRgNC10LzQtdC90L0=?= =?UTF-8?B?0L4g0LjQv9C+0LvRjNC30YPQtdC80YvRhSBwcm94eSBwYXNzINCyINCyINC9?= =?UTF-8?B?0LXRgdC60L7Qu9GM0LrQuNGFICBsb2NhdGlvbg==?= In-Reply-To: <718b8f7aa0c67f2b08688744f74ba8df.NginxMailingListRussian@forum.nginx.org> References: <718b8f7aa0c67f2b08688744f74ba8df.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190830134532.GJ1877@mdounin.ru> Hello! On Wed, Aug 21, 2019 at 01:57:10AM -0400, glareboa wrote: > Приветствую. > > Использую такую конструкцию. > > http { > ... > server { > listen 80 default_server; > ... > location /qwe/ > { > proxy_pass "http://192.168.1.2:9000"; > } > > location /qwe/ > { > proxy_pass "http://192.168.1.2:9001"; > } > > location /rty/ > { > proxy_pass "http://192.168.1.2:9002"; > } > > ... > > location /uio/ > { > proxy_pass "http://192.168.1.2:9012"; > } > > > } > } > Но в браузере отображаются только для 6 или меньше > источников(http://192.168.1.2:90хх). > Если вставить адреса http://192.168.1.2:9012 непосредственно в html-файл, > отображаются все источники. > > Получается, что есть ограничение в nginx? Нет, в nginx ограничений нет. А вот в браузерах - есть ограничение на максимум 6 соединений к одному доменному имени в рамках HTTP/1.x, так что если речь идёт про какие-то потоки данных - то скорее всего вы просто упёрлись в ограничение бразуера. Обычно это обходят, используя на html-странице несколько доменных имён, указывающих на один и тот же сервер. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Aug 30 14:56:33 2019 From: nginx-forum на forum.nginx.org (classic85) Date: Fri, 30 Aug 2019 10:56:33 -0400 Subject: rewrite Message-ID: Всем привет Прошу помочь перенести редирект с IIS на NGINX Помогите плиз. как он должен выглядеть? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285459,285459#msg-285459 From nginx-forum на forum.nginx.org Fri Aug 30 15:08:54 2019 From: nginx-forum на forum.nginx.org (spanjokus) Date: Fri, 30 Aug 2019 11:08:54 -0400 Subject: =?UTF-8?B?UmU6INCY0L3QvtCz0LTQsCDQsiDQu9C+0LPQsNGFINC/0YDQvtGB0LrQsNC60Lg=?= =?UTF-8?B?0LLQsNC10YIgU1NMIHdyaXRlKCkgZmFpbGVk?= In-Reply-To: <2156144001daba78f7ced0136e6af0ef.NginxMailingListRussian@forum.nginx.org> References: <2156144001daba78f7ced0136e6af0ef.NginxMailingListRussian@forum.nginx.org> Message-ID: <16381e2350e45f6651e81c5d1723352c.NginxMailingListRussian@forum.nginx.org> У меня такое то же иногда проскакивает, был бы признателен, если бы кто-то подсказал из-за чего это Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285121,285460#msg-285460 From identw на gmail.com Sat Aug 31 07:54:06 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Sat, 31 Aug 2019 12:54:06 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <20190830124912.GE1877@mdounin.ru> References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> <20190830124912.GE1877@mdounin.ru> Message-ID: Добрый день! Спасибо за ответ. Конфиг полный, просто сократил количетсво виртуальных хостов, так как они одинаковые. ssl_session_cache - действительно не настроено. ssl_dhparam - аналогично. сертификат один общий для всех, сгенерировал его для wildcard домена от let's encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: rsaEncryption (2048 bit)). Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. В частности пробовал глобально добавлять опции: *ssl_session_cache shared:SSL:20m;* *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз конечно, и более чательно. Про ssl_dhparam не понял, с точки зрения производительности - его лучше добавлять но с небольшой битностью (2048 и меньше) или лучше совсем не использовать? Большое спасибо за советы. ** On 30/08/2019 17:49, Maxim Dounin wrote: > Hello! > > On Wed, Aug 28, 2019 at 09:18:44PM +0500, Dmitry Sergeev wrote: > >> Вообще мне это конечно помогло, но  не полностью. На версии 1.0.2g во >> время reload'а проц грузит полностью  около 5-10 секунд (вместо 40-300 >> секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у >> клиентов. Но в целом проблема осталась, просто теперь она не так сильно >> беспокоит. >> >> Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с >> нагрузкой, и смотреть можно ли как-то повлиять на это. >> Если конечно тут не подскажут, что еще можно подкрутить. > Судя по perf top, проблема в том, что клиенты после reload'а > переустанавливают соединения, и это выливается в полный SSL > handshake - что и приводит к потреблению CPU. > > Посмотреть стоит на: > > - ssl_session_cache - в конфиге его, судя по всему, нет (или > соответствующие части конфига не показаны); > > - сертификаты, в частности - их битность (just in case, RSA более > 2048 использовать не надо, это тупо очень дорого с точки зрения > процессора) и тип (лучше использовать ECDSA, но тут уже может > встать вопрос совместимости; при желании можно использовать и RSA > и ECDSA одновременно); > > - используемые шифры, особенно - шифры с классическим DH для > обмена ключами (по умолчанию эти шифры не используются начиная с > nginx 1.11.0, но некоторые любят указывать ssl_dhparam в конфиге, > да ещё и с параметрами большой битности; не надо так); > >> Насчет старых клиентов, точно не могу сказать, но есть такой кейс >> http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я >> хорошо не изучал этот вопрос, но факт остается, на старой версии openssl >> ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты >> с очень старым ssl. > Как уже говорилось в треде по ссылке, использование OpenSSL > 1.0.1u автоматически означет, что HTTP/2 с большинством клиентов > работать не будет. С учётом "listen ... http2" в конфиге - > обновление до 1.0.2 могло "помочь" просто за счёт того, что HTTP/2 > заработал, и количество устанавливаемых соединений соответственно > уменьшилось. > -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Aug 31 19:13:50 2019 From: nginx-forum на forum.nginx.org (glareboa) Date: Sat, 31 Aug 2019 15:13:50 -0400 Subject: =?UTF-8?B?UmU6INCa0L7Qu9C40YfQtdGB0YLQstC+INC+0LTQvdC+0LLRgNC10LzQtdC90L0=?= =?UTF-8?B?0L4g0LjQv9C+0LvRjNC30YPQtdC80YvRhSBwcm94eSBwYXNzINCyINCyINC9?= =?UTF-8?B?0LXRgdC60L7Qu9GM0LrQuNGFICBsb2NhdGlvbg==?= In-Reply-To: <20190830134532.GJ1877@mdounin.ru> References: <20190830134532.GJ1877@mdounin.ru> Message-ID: Да, вы правы. Попробовал сделать так. Часть location оставил с использованием rewrite, а 6 location с использованием proxy_pass. Результат впечатлил. :-) Видеопотоки отобразились в 6 соединениях. Видеопотоки, которые должны были идти через rewrite (в обход nginx) не отобразились. Браузер, отбразив 6 видеопотоков продолжал оставаться в режиме ожидания данных от сервера. Вы правы это ограничение браузера. > Обычно это обходят, используя на html-странице >несколько доменных имён, указывающих на один и тот же сервер Спасибо, попробую. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285454,285493#msg-285493