From corochoone на gmail.com Sun Dec 2 20:18:05 2018 From: corochoone на gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCS0LjRgdC70L7QsdC+0LrQvtCy?=) Date: Sun, 2 Dec 2018 23:18:05 +0300 Subject: =?UTF-8?B?cHJveHlfc3RvcmUg0L/QtdGA0LjQvtC00LjRh9C10YHQutC4INGB0L7RhdGA0LA=?= =?UTF-8?B?0L3Rj9C10YIg0YLQvtC70YzQutC+INGH0LDRgdGC0Ywg0L7RgtCy0LXRgtCw?= =?UTF-8?B?IDoo?= Message-ID: Схема такая: nginx(1) -> nginx(2) -> httpd На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. Почти работает, но в произвольный момент времени сохраняет на диск не всю страницу с ответом, а только её часть! Это именно происходит периодически и не зависит ни от IP адреса ни от клиента (тот же Zabbix у меня то получает фрагмент и ругается на малый размер страницы, то в следующий повтор всё получает нормально - стоит чистка файлов, сохранённых proxy_store каждую минуту). Всю голову сломал - не могу понять что за ерунда! Судя по логам nginx(2) всегда отдаёт полный ответ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngnx8810773a83 на avksrv.org Sun Dec 2 21:14:51 2018 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Mon, 3 Dec 2018 00:14:51 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlINC/0LXRgNC40L7QtNC40YfQtdGB0LrQuCDRgdC+0YU=?= =?UTF-8?B?0YDQsNC90Y/QtdGCINGC0L7Qu9GM0LrQviDRh9Cw0YHRgtGMINC+0YLQstC1?= =?UTF-8?B?0YLQsCA6KA==?= In-Reply-To: References: Message-ID: <325d47c4-3953-c46f-78ad-c491243c8107@avksrv.org> 02.12.2018 23:18, Виктор Вислобоков пишет: > Схема такая: nginx(1) -> nginx(2) -> httpd > На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. > Почти работает, но в произвольный момент времени сохраняет на диск не > всю страницу с ответом, а только её часть! Это именно происходит > периодически и не зависит ни от IP адреса ни от клиента (тот же Zabbix > у меня то получает фрагмент и ругается на малый размер страницы, то в > следующий повтор всё получает нормально - стоит чистка файлов, > сохранённых proxy_store каждую минуту). > А чем proxy_cache не устраивает ? прокси стор, это больше для "на века", а Вы трете его зачемто постоянно У Вас proxy_temp_path и место куда сторится на одном разделе ? Если на разных, то, скорее всего, пока файл от одного запроса копируется, успевает прийти другой запрос и видя файл на месте его и отдает, ну сколько успело скопироваться на момент второго запроса столько и отдает. From corochoone на gmail.com Mon Dec 3 05:52:53 2018 From: corochoone на gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCS0LjRgdC70L7QsdC+0LrQvtCy?=) Date: Mon, 3 Dec 2018 08:52:53 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlINC/0LXRgNC40L7QtNC40YfQtdGB0LrQuCDRgdC+0YU=?= =?UTF-8?B?0YDQsNC90Y/QtdGCINGC0L7Qu9GM0LrQviDRh9Cw0YHRgtGMINC+0YLQstC1?= =?UTF-8?B?0YLQsCA6KA==?= In-Reply-To: <325d47c4-3953-c46f-78ad-c491243c8107@avksrv.org> References: <325d47c4-3953-c46f-78ad-c491243c8107@avksrv.org> Message-ID: >> А чем proxy_cache не устраивает ? прокси стор, это больше для "на века", а Вы трете его зачемто постоянно Куда и что сохраняет proxy_cache знает только сам proxy_cache. Найти что-то сохранённое им на диске очень большая проблема, да и посмотреть что там тоже не так просто. А в proxy_store можно задать вполне себе понятный и человеко-читаемый путь и содержимое тоже вполне себе понятно. >> У Вас proxy_temp_path и место куда сторится на одном разделе ? На одном. пн, 3 дек. 2018 г. в 00:15, Alexey via nginx-ru : > 02.12.2018 23:18, Виктор Вислобоков пишет: > > Схема такая: nginx(1) -> nginx(2) -> httpd > > На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. > > Почти работает, но в произвольный момент времени сохраняет на диск не > > всю страницу с ответом, а только её часть! Это именно происходит > > периодически и не зависит ни от IP адреса ни от клиента (тот же Zabbix > > у меня то получает фрагмент и ругается на малый размер страницы, то в > > следующий повтор всё получает нормально - стоит чистка файлов, > > сохранённых proxy_store каждую минуту). > > > А чем proxy_cache не устраивает ? прокси стор, это больше для "на века", > а Вы трете его зачемто постоянно > > У Вас proxy_temp_path и место куда сторится на одном разделе ? Если на > разных, то, скорее всего, пока файл от одного запроса копируется, > успевает прийти другой запрос и видя файл на месте его и отдает, ну > сколько успело скопироваться на момент второго запроса столько и отдает. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From constantine на mellodesign.ru Mon Dec 3 09:03:14 2018 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Mon, 3 Dec 2018 12:03:14 +0300 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQuiDQtNC40YDQtdC60YLQuNCy?= =?UTF-8?B?0LUgZmFzdGNnaV9jYWNoZV9rZXk=?= In-Reply-To: References: <65806589-b909-0ae2-fa6a-dfaf6e2920a3@csdoc.com> <20181129163017.GL99070@mdounin.ru> <08f691cf-3d76-9223-6d23-4a83c20ff585@csdoc.com> <20181129190257.GO99070@mdounin.ru> <32393d60-7cdf-a3fe-2ad1-3de6c82ec2a0@csdoc.com> Message-ID: пт, 30 нояб. 2018 г. в 13:36, Илья Шипицин : > протоколы действительно разные. > но выглядит так, что предложение Гены поможет написать документацию, более > устойчивую к тупому копипасту (есть такой патерн, что глядя на пример > документации на авторитетном сайте, его копируют) > > пт, 30 нояб. 2018 г. в 14:30, Gena Makhomed : > >> On 29.11.2018 21:02, Maxim Dounin wrote: >> >> > CGI и HTTP - это два разных протокола. В последних вариациях на >> > тему спецификации CGI записано, что на HEAD-запросы тело >> > возвращать не надо (а если вдруг вернули - то сервер его должен >> > поскипать), https://tools.ietf.org/html/rfc3875#section-4.3.3: >> > >> > The HEAD method requests the script to do sufficient processing to >> > return the response header fields, without providing a response >> > message-body. The script MUST NOT provide a response message-body >> > for a HEAD request. If it does, then the server MUST discard the >> > message-body when reading the response from the script. >> > >> > Однако на момент собственно появления и активного распространения >> > CGI никаких подобных требований не существовало, см. >> > https://www.w3.org/CGI/ и в частности >> > https://tools.ietf.org/html/draft-robinson-www-interface-00. >> >> Там написано: >> >> REQUEST_METHOD >> >> This variable is specific to requests made with HTTP. >> >> The method with which the request was made, as described in >> section 5.1.1 of the HTTP/1.0 specification [3]. >> >> http-method = "GET" | "HEAD" | "POST" | extension-method >> >> "described in HTTP/1.0 specification" - написано где смотреть семантику. >> А в HTTP/1.0 specification написано, что "server must not return any >> Entity-Body in the response". >> >> CGI и HTTP - это два разных протокола, но первый ссылается на второй. >> При этом CGI протокол не запрещает бекенду отвечать на HEAD-запросы >> так, как этого требует от веб-сервера спецификация HTTP протокола. >> >> > И на >> > практике я не встречал скрипты, которые бы отдельно обрабатывали >> > HEAD-запросы. >> >> Но они есть. >> И их поведение ничем не противоречит спецификации FastCGI протокола. >> >> >>> Речь про какие-то фреймворки, которые обрабатывают >> >>> HEAD автоматически, не донося соответствующую информацию до кода? >> >>> Или про какой-то стандартный софт, который не возвращает тело для >> >>> HEAD-запросов? >> >> >> >> Какая разница, сам софт или фрейморк используемый софтом в каждом >> >> конкретном случае обрабатывает HEAD запросы согласно требований RFC? >> > >> > Никакой. Но с этой точки зрения так же нет разницы, что именно >> > написано в примерах в описании директивы fastcgi_cache_key. >> >> Вы не против, если я создам на хабре статью, в которой напишу >> про эту проблему с ошибочными примерами в документации nginx >> к директиве fastcgi_cache_key и ее аналогам? >> >> -- >> Best regards, >> Gena >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Прошу прощения, что влезаю. Есть статья Дмитрия Котерова от октября 2009 года, посвещенная кешированию в nginx http://dklab.ru/chicken/nablas/56.html Если механизм кеширование не сильно изменился, то данные там акутальные. На хабре, конечно, охват аудитории больше будет, если там появится подобная статья. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From corochoone на gmail.com Mon Dec 3 09:17:34 2018 From: corochoone на gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCS0LjRgdC70L7QsdC+0LrQvtCy?=) Date: Mon, 3 Dec 2018 12:17:34 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlINC/0LXRgNC40L7QtNC40YfQtdGB0LrQuCDRgdC+0YU=?= =?UTF-8?B?0YDQsNC90Y/QtdGCINGC0L7Qu9GM0LrQviDRh9Cw0YHRgtGMINC+0YLQstC1?= =?UTF-8?B?0YLQsCA6KA==?= In-Reply-To: References: <325d47c4-3953-c46f-78ad-c491243c8107@avksrv.org> Message-ID: Кажется нашёл. У меня в настройках стояло так, что если файл кэша есть, то отавать его, если нет, то создавать. Но было ещё одно условие: если запрос POST то не отдавать, а создавать. Видимо при одновременном приходе GET и POST запросов ответ писался в один и тот же файл и возникала проблема. Пустил POST запросы вообще мимо кэша и файл перестал быть фрагментарным. Спасибо за участие всем, кто ответил! :) пн, 3 дек. 2018 г. в 08:52, Виктор Вислобоков : > >> А чем proxy_cache не устраивает ? прокси стор, это больше для "на > века", а Вы трете его зачемто постоянно > Куда и что сохраняет proxy_cache знает только сам proxy_cache. Найти > что-то сохранённое им на диске очень большая проблема, да и посмотреть что > там тоже не так просто. А в proxy_store можно задать вполне себе понятный и > человеко-читаемый путь и содержимое тоже вполне себе понятно. > > >> У Вас proxy_temp_path и место куда сторится на одном разделе ? > На одном. > > пн, 3 дек. 2018 г. в 00:15, Alexey via nginx-ru : > >> 02.12.2018 23:18, Виктор Вислобоков пишет: >> > Схема такая: nginx(1) -> nginx(2) -> httpd >> > На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. >> > Почти работает, но в произвольный момент времени сохраняет на диск не >> > всю страницу с ответом, а только её часть! Это именно происходит >> > периодически и не зависит ни от IP адреса ни от клиента (тот же Zabbix >> > у меня то получает фрагмент и ругается на малый размер страницы, то в >> > следующий повтор всё получает нормально - стоит чистка файлов, >> > сохранённых proxy_store каждую минуту). >> > >> А чем proxy_cache не устраивает ? прокси стор, это больше для "на века", >> а Вы трете его зачемто постоянно >> >> У Вас proxy_temp_path и место куда сторится на одном разделе ? Если на >> разных, то, скорее всего, пока файл от одного запроса копируется, >> успевает прийти другой запрос и видя файл на месте его и отдает, ну >> сколько успело скопироваться на момент второго запроса столько и отдает. >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Mon Dec 3 14:39:15 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Dec 2018 17:39:15 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlINC/0LXRgNC40L7QtNC40YfQtdGB0LrQuCDRgdC+0YU=?= =?UTF-8?B?0YDQsNC90Y/QtdGCINGC0L7Qu9GM0LrQviDRh9Cw0YHRgtGMINC+0YLQstC1?= =?UTF-8?B?0YLQsCA6KA==?= In-Reply-To: References: Message-ID: <20181203143914.GY99070@mdounin.ru> Hello! On Sun, Dec 02, 2018 at 11:18:05PM +0300, Виктор Вислобоков wrote: > Схема такая: nginx(1) -> nginx(2) -> httpd > На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. Почти > работает, но в произвольный момент времени сохраняет на диск не всю > страницу с ответом, а только её часть! Это именно происходит периодически и > не зависит ни от IP адреса ни от клиента (тот же Zabbix у меня то получает > фрагмент и ругается на малый размер страницы, то в следующий повтор всё > получает нормально - стоит чистка файлов, сохранённых proxy_store каждую > минуту). > > Всю голову сломал - не могу понять что за ерунда! > Судя по логам nginx(2) всегда отдаёт полный ответ. Content-Length при этом в ответах бэкенда есть? А "только её часть" - это именно часть, или просто пустой файл? В случае, если именно пустой файл - проблема может быть связана с тем, что в ответах нет Content-Length и сохраняются ответы на HEAD-запросы. Кроме того, опять же в случае отсутствия Content-Length, стоит убедиться, что между nginx(1) и nginx(2), а равно между nginx(2) и httpd - отсутствуют сетевые проблемы, и никто не пытается преждевременно завершать процессы серверной стороны. Либо же просто попробовать включить HTTP/1.1 с помощью директивы proxy_http_version (http://nginx.org/r/proxy_http_version) и посмотреть, поможет ли. Проблема в том, что в HTTP/1.0, который nginx использует для общения с бэкендами по умолчанию, в отсутствии Content-Length нет какого-либо контроля целостности ответа кроме собственно информации с уровня TCP, и если в какой-то момент бэкенд закроет соединение (например, потому что процессу сказали завершиться, или он решил, что случился таймаут) - то с точки зрения клиента ответ будет полным. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Dec 3 14:41:29 2018 From: nginx-forum на forum.nginx.org (firedragon) Date: Mon, 03 Dec 2018 09:41:29 -0500 Subject: =?UTF-8?B?0JHQsNC70LDQvdGBINCY0YDQvtGH0LrQsCDQv9C+INC40LzQtdC90Lgg0YXQvtGB?= =?UTF-8?B?0YLQsA==?= Message-ID: Привет, всем. Я только начал изучать nginx, может кто-нибудь мне подсказать. Имеется несколько сайтов на одном IIS все через ssl https://www.xxx.ru https://www.yyy.ru https://www.zzz.ru , соответственно чтобы получить доступ к нужному сайту нужно обратиться обязательно по имени сайта, например www.xxx.ru. Создал несколько серверов , пытаюсь делать балансировку, nginx не может открыть страницу. Как я понял при получении запроса nginx дальше балансирует запрос на сервер iis по IP адресу. Можете подсказать как решить проблему? Заранее спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282240,282240#msg-282240 From shadow.tehb на gmail.com Mon Dec 3 14:48:51 2018 From: shadow.tehb на gmail.com (=?utf-8?Q?=D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9_=D0=9E=D0=BB=D0=B5=D0=B3=D0=BE=D0=B2=D0=B8=D1=87?=) Date: Mon, 3 Dec 2018 17:48:51 +0300 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgSDQmNGA0L7Rh9C60LAg0L/QviDQuNC80LXQvdC4INGF?= =?UTF-8?B?0L7RgdGC0LA=?= In-Reply-To: References: Message-ID: <70d23c72-1ef3-4177-8ca6-b84720b1ecb3@Spark> Прикладывайте конфиг С уважением, Сергей 3 дек. 2018 г., 17:41 +0300, firedragon , писал: > Привет, всем. > > Я только начал изучать nginx, может кто-нибудь мне подсказать. > Имеется несколько сайтов на одном IIS все через ssl > https://www.xxx.ru > https://www.yyy.ru > https://www.zzz.ru > > , соответственно чтобы получить доступ к нужному сайту нужно обратиться > обязательно по имени сайта, например www.xxx.ru. > > Создал несколько серверов , пытаюсь делать балансировку, nginx не может > открыть страницу. > > Как я понял при получении запроса nginx дальше балансирует запрос на сервер > iis по IP адресу. > > > Можете подсказать как решить проблему? > > Заранее спасибо. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282240,282240#msg-282240 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pavel2000 на ngs.ru Mon Dec 3 14:51:02 2018 From: pavel2000 на ngs.ru (Pavel) Date: Mon, 03 Dec 2018 21:51:02 +0700 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgSDQmNGA0L7Rh9C60LAg0L/QviDQuNC80LXQvdC4INGF?= =?UTF-8?B?0L7RgdGC0LA=?= In-Reply-To: References: Message-ID: On Mon, 03 Dec 2018 09:41:29 -0500 "firedragon" wrote: > Привет, всем. > Как я понял при получении запроса nginx дальше > балансирует запрос на сервер iis по IP адресу. > > Можете подсказать как решить проблему? > Привет. Вам нужно использовать директиву proxy_set_header Host $host; http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header Разберитесь с этим. From mdounin на mdounin.ru Tue Dec 4 15:07:39 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 4 Dec 2018 18:07:39 +0300 Subject: nginx-1.14.2 Message-ID: <20181204150739.GF99070@mdounin.ru> Изменения в nginx 1.14.2 04.12.2018 *) Исправление: nginx не собирался gcc 8.1. *) Исправление: nginx не собирался на Fedora 28 Linux. *) Исправление: в обработке адресов клиентов при использовании unix domain listen-сокетов для работы с датаграммами на Linux. *) Изменение: уровень логгирования ошибок SSL "http request", "https proxy request", "unsupported protocol", "version too low", "no suitable key share" и "no suitable signature algorithm" понижен с уровня crit до info. *) Исправление: при использовании OpenSSL 1.1.0 и новее директиву ssl_prefer_server_ciphers нельзя было выключить в виртуальном сервере, если она была включена в сервере по умолчанию. *) Исправление: nginx не собирался с LibreSSL 2.8.0. *) Исправление: если nginx был собран с OpenSSL 1.1.0, а использовался с OpenSSL 1.1.1, протокол TLS 1.3 всегда был разрешён. *) Исправление: при отправке сохранённого на диск тела запроса на gRPC-бэкенд могли возникать ошибки. *) Исправление: соединения к некоторым gRPC-бэкендам могли не кэшироваться при использовании директивы keepalive. *) Исправление: в рабочем процессе мог произойти segmentation fault, если использовался модуль ngx_http_mp4_module на 32-битных платформах. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Dec 5 10:39:41 2018 From: nginx-forum на forum.nginx.org (dlavrov) Date: Wed, 05 Dec 2018 05:39:41 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgU1Ns?= In-Reply-To: References: Message-ID: Ошибку нашли в gostengy и исправили - https://www.cryptopro.ru/forum2/default.aspx?g=posts&m=97875#post97875 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281647,282284#msg-282284 From nginx-forum на forum.nginx.org Mon Dec 10 11:53:32 2018 From: nginx-forum на forum.nginx.org (suffix) Date: Mon, 10 Dec 2018 06:53:32 -0500 Subject: proxy_socket_keepalive on; Message-ID: <20911ef1ab94213734d1898fc6aabc1f.NginxMailingListRussian@forum.nginx.org> В версии 1.15.6 появилась эта опция. Вставляю в location - не работает. Подозреваю что по аналогии с fastcgi_pass нужно вместо: location @fallback { proxy_pass http://127.0.0.1:8080; proxy_socket_keepalive on; } Нужно так сделать: upstream proxy_backend { server 127.0.0.1:8080; keepalive 32; } location / { proxy_pass proxy_backend; proxy_socket_keepalive on; } Правильно я понимаю ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282318,282318#msg-282318 From mdounin на mdounin.ru Mon Dec 10 13:36:45 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 10 Dec 2018 16:36:45 +0300 Subject: proxy_socket_keepalive on; In-Reply-To: <20911ef1ab94213734d1898fc6aabc1f.NginxMailingListRussian@forum.nginx.org> References: <20911ef1ab94213734d1898fc6aabc1f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181210133645.GO99070@mdounin.ru> Hello! On Mon, Dec 10, 2018 at 06:53:32AM -0500, suffix wrote: > В версии 1.15.6 появилась эта опция. > > Вставляю в location - не работает. > > Подозреваю что по аналогии с fastcgi_pass нужно вместо: > > location @fallback { > proxy_pass http://127.0.0.1:8080; > proxy_socket_keepalive on; > } > Нужно так сделать: > > upstream proxy_backend { > server 127.0.0.1:8080; > keepalive 32; > } > > location / { > proxy_pass proxy_backend; > proxy_socket_keepalive on; > } > > Правильно я понимаю ? Судя по всему, вы неправильно понимаете, зачем нужна эта опция. Эта опция - чтобы выставить SO_KEEPALIVE на сокете соединения с бэкендом, аналогично параметру "so_keepalive" для listen-сокетов. Это нужно, чтобы даже по неактивному соединению периодически ходили пакеты, и соответственно а) если та сторона не отвечает - то nginx об этом узнал по возможности раньше, и б) если между nginx'ом и бэкендом стоит statefull firewall, то он видел, что соединение - активно, и соответствующий ему state не надо выкидывать. Если вы хотите просто хотите использовать постоянные соединения с бэкендами - вам эта опция не нужна, а нужно настроить keepalive в соответствии с инструкциями тут: http://nginx.org/r/keepalive Процедура не менялась с момента появления соответствующей фичи в nginx 1.1.4. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Dec 11 08:54:47 2018 From: nginx-forum на forum.nginx.org (suffix) Date: Tue, 11 Dec 2018 03:54:47 -0500 Subject: proxy_socket_keepalive on; In-Reply-To: <20181210133645.GO99070@mdounin.ru> References: <20181210133645.GO99070@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Если вы хотите просто хотите использовать постоянные соединения с > бэкендами - вам эта опция не нужна, а нужно настроить keepalive в > соответствии с инструкциями тут: > > http://nginx.org/r/keepalive > Большое спасибо ! Да, я тормоз и непрвильно всё понимал. Настроил по ссылке + добавил в логи апач %k и убедился что keep-alive и между nginx и apache заработал ! И если я правильно понял то в моём случае опция proxy_socket_keepalive on; просто вредна будет. Ещё раз спасибо ! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282318,282334#msg-282334 From oleg на mamontov.net Tue Dec 11 10:42:21 2018 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Tue, 11 Dec 2018 13:42:21 +0300 Subject: proxy_socket_keepalive on; In-Reply-To: References: <20181210133645.GO99070@mdounin.ru> Message-ID: <20181211104221.aaxaaoshy5bslonh@xenon.mamontov.net> On Tue, Dec 11, 2018 at 03:54:47AM -0500, suffix wrote: >Maxim Dounin Wrote: >------------------------------------------------------- >> Если вы хотите просто хотите использовать постоянные соединения с >> бэкендами - вам эта опция не нужна, а нужно настроить keepalive в >> соответствии с инструкциями тут: >> >> http://nginx.org/r/keepalive >> > >Большое спасибо ! Да, я тормоз и непрвильно всё понимал. > >Настроил по ссылке + добавил в логи апач %k и убедился что keep-alive и >между nginx и apache заработал ! > >И если я правильно понял то в моём случае опция proxy_socket_keepalive on; >просто вредна будет. Трудно представить случай, когда она будет вредна. Максимум - бесполезна. >Ещё раз спасибо ! > >Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282318,282334#msg-282334 > >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From nginx-forum на forum.nginx.org Tue Dec 11 11:25:58 2018 From: nginx-forum на forum.nginx.org (suffix) Date: Tue, 11 Dec 2018 06:25:58 -0500 Subject: proxy_socket_keepalive on; In-Reply-To: <20181211104221.aaxaaoshy5bslonh@xenon.mamontov.net> References: <20181211104221.aaxaaoshy5bslonh@xenon.mamontov.net> Message-ID: > Трудно представить случай, когда она будет вредна. Максимум - > бесполезна. Боюсь ошибиться по незнанию. Но зачем она может быть нужна между nginx и apache расположенных на одном сервере ? Накладные расходы от её включения разве не вред ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282318,282340#msg-282340 From maxim на nginx.com Tue Dec 11 11:33:39 2018 From: maxim на nginx.com (Maxim Konovalov) Date: Tue, 11 Dec 2018 14:33:39 +0300 Subject: proxy_socket_keepalive on; In-Reply-To: References: <20181211104221.aaxaaoshy5bslonh@xenon.mamontov.net> Message-ID: On 11/12/2018 14:25, suffix wrote: >> Трудно представить случай, когда она будет вредна. Максимум - >> бесполезна. > > > Боюсь ошибиться по незнанию. Но зачем она может быть нужна между nginx и > apache расположенных на одном сервере ? Накладные расходы от её включения > разве не вред ? > Накладные расходы вряд ли поддаются измерению. Для чего фича нужна -- Максим пояснил в первом письме. http://mailman.nginx.org/pipermail/nginx-ru/2018-December/061721.html Если между nginx и бэкендом стоит не самый умный стейтфул файрволл, который неаккуратно обращается с сессиями, то это может приводить удалению сессии из его таблицы и как следствие закрытию установленного соединения между nginx и бэкендом, что может быть более или менее нежелательно. Включение этой опции в nginx и настройка таймеров tcp keepalive на уровне ядра позволяет снизить вероятность возникновения такой проблемы, не трогая настройки файрволла. Вред от включения этой ручки вряд ли будет. Крутить ее (и любые другие ручки) бездумно тоже не стоит. -- Maxim Konovalov From nginx-forum на forum.nginx.org Tue Dec 11 13:43:16 2018 From: nginx-forum на forum.nginx.org (ingtar) Date: Tue, 11 Dec 2018 08:43:16 -0500 Subject: =?UTF-8?B?T3BlbnNzbCAxLjEuMSArIG5naW54IDEuMTQuMCDQvdC1INGA0LDQsdC+0YLQsNC1?= =?UTF-8?B?0YIgdGxzMS4x?= Message-ID: <263e60349ab500c1883f3de57446b208.NginxMailingListRussian@forum.nginx.org> Добрый день! Подскажите, пожалуйста, решение следующей проблемы: собран openssl 1.1.1a из исходников, собран nginx 1.14.0 из исходников. В конфиге включена поддержка tls1.3 и некоторые шифры для него Конфиг для ssl такой: ssl_session_timeout 10m; ssl_session_cache shared:SSL:100m; ssl_dhparam /etc/nginx/dhparam.2048.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers 'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; Поддержка tls1.3 работает, клиенты подключаются. Так же работает 1.2. А вот 1 и 1.1 перестали работать с ошибкой: CONNECTED(00000003) 139733715125760:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1528:SSL alert number 70 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 125 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1544535599 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- В логах соответственно: 2018/12/11 15:57:15 [crit] 26894#0: *460747266 SSL_do_handshake() failed (SSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol) while SSL handshaking, client: 10.9.211.224, server: 0.0.0.0:443 2018/12/11 16:18:06 [crit] 26894#0: *460752738 SSL_do_handshake() failed (SSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol) while SSL handshaking, client: 10.9.211.224, server: 0.0.0.0:443 2018/12/11 16:21:55 [crit] 26894#0: *460753742 SSL_do_handshake() failed (SSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol) while SSL handshaking, client: 10.9.211.224, server: 0.0.0.0:443 2018/12/11 16:39:59 [crit] 26894#0: *460758488 SSL_do_handshake() failed (SSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol) while SSL handshaking, client: 185.89.12.132, server: 0.0.0.0:443 openssl показывает поддержку tls1.1: openssl ciphers -v | awk '{print $2}' | sort | uniq SSLv3 TLSv1 TLSv1.2 TLSv1.3 Помогите, пожалуйста. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282343,282343#msg-282343 From nginx-forum на forum.nginx.org Tue Dec 11 13:44:01 2018 From: nginx-forum на forum.nginx.org (ingtar) Date: Tue, 11 Dec 2018 08:44:01 -0500 Subject: =?UTF-8?B?UmU6IE9wZW5zc2wgMS4xLjEgKyBuZ2lueCAxLjE0LjAg0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHRsczEuMQ==?= In-Reply-To: <263e60349ab500c1883f3de57446b208.NginxMailingListRussian@forum.nginx.org> References: <263e60349ab500c1883f3de57446b208.NginxMailingListRussian@forum.nginx.org> Message-ID: <0a85f4e098c50bdecb10dbab5ac568b0.NginxMailingListRussian@forum.nginx.org> Забыл версию nginx указать: nginx version: nginx/1.14.0 built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) built with OpenSSL 1.1.1a 20 Nov 2018 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --http-client-body-temp-path=/run/shm/body_temp --http-proxy-temp-path=/run/shm/proxy_temp --http-fastcgi-temp-path=/run/shm/fastcgi_temp --http-uwsgi-temp-path=/run/shm/uwsgi_temp --http-scgi-temp-path=/run/shm/scgi_temp --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_dav_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_stub_status_module --with-mail --with-http_v2_module --with-http_geoip_module --with-select_module --with-http_auth_request_module --with-poll_module --with-debug Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282343,282344#msg-282344 From bgx на protva.ru Tue Dec 11 13:52:21 2018 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 11 Dec 2018 16:52:21 +0300 Subject: =?UTF-8?B?UmU6IE9wZW5zc2wgMS4xLjEgKyBuZ2lueCAxLjE0LjAg0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHRsczEuMQ==?= In-Reply-To: <0a85f4e098c50bdecb10dbab5ac568b0.NginxMailingListRussian@forum.nginx.org> References: <263e60349ab500c1883f3de57446b208.NginxMailingListRussian@forum.nginx.org> <0a85f4e098c50bdecb10dbab5ac568b0.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181211135221.GG25685@protva.ru> On Tue, Dec 11, 2018 at 08:44:01AM -0500, ingtar wrote: > Забыл версию nginx указать: > > nginx version: nginx/1.14.0 > built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) > built with OpenSSL 1.1.1a 20 Nov 2018 Возможно, причина в глобальном отключении старых шифров в дебиане: http://mailman.nginx.org/pipermail/nginx-ru/2018-November/061673.html -- Eugene Berdnikov From chipitsine на gmail.com Tue Dec 11 13:55:51 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 11 Dec 2018 18:55:51 +0500 Subject: =?UTF-8?B?UmU6IE9wZW5zc2wgMS4xLjEgKyBuZ2lueCAxLjE0LjAg0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHRsczEuMQ==?= In-Reply-To: <0a85f4e098c50bdecb10dbab5ac568b0.NginxMailingListRussian@forum.nginx.org> References: <263e60349ab500c1883f3de57446b208.NginxMailingListRussian@forum.nginx.org> <0a85f4e098c50bdecb10dbab5ac568b0.NginxMailingListRussian@forum.nginx.org> Message-ID: Можно поступить так 1) срисовать опции через 'nginx -V' 2) собрать из исходников с этим набором опций и указать в configure путь до исходников openssl Статически слинкуется с вновь скомпилированной openssl On Tue, Dec 11, 2018, 6:44 PM ingtar Забыл версию nginx указать: > > nginx version: nginx/1.14.0 > built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) > built with OpenSSL 1.1.1a 20 Nov 2018 > TLS SNI support enabled > configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid > --lock-path=/run/lock/nginx.lock > --http-client-body-temp-path=/run/shm/body_temp > --http-proxy-temp-path=/run/shm/proxy_temp > --http-fastcgi-temp-path=/run/shm/fastcgi_temp > --http-uwsgi-temp-path=/run/shm/uwsgi_temp > --http-scgi-temp-path=/run/shm/scgi_temp --with-http_ssl_module > --with-http_realip_module --with-http_sub_module --with-http_dav_module > --with-http_gunzip_module --with-http_gzip_static_module > --with-http_stub_status_module --with-mail --with-http_v2_module > --with-http_geoip_module --with-select_module > --with-http_auth_request_module --with-poll_module --with-debug > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,282343,282344#msg-282344 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Dec 11 14:42:41 2018 From: nginx-forum на forum.nginx.org (suffix) Date: Tue, 11 Dec 2018 09:42:41 -0500 Subject: proxy_socket_keepalive on; In-Reply-To: References: Message-ID: Maxim Konovalov Wrote: ------------------------------------------------------- > Вред от включения этой ручки вряд ли будет. Можно тогда последний идиотский вопрос - конкретно в моём случае (вебсервер из связки nginx + apache) vhost .conf nginx: upstream http_backend { server 127.0.0.1:8080; keepalive 100; } location / { proxy_pass http://http_backend; proxy_redirect http://http_backend /; proxy_http_version 1.1; proxy_set_header Connection ""; } nginx.conf : keepalive_timeout 65; vhost .conf httpd: KeepAlive On KeepAliveTimeout 65 Проблем с нехваткой оперативки нет - free -h: total used free shared buff/cache available Mem: 62G 2,6G 50G 325M 9,1G 59G Swap: 0B 0B 0B Таки стоит в vhost .conf nginx в секцию location добавить proxy_socket_keepalive on; или нет (при условии что неизвестно "умный стейтфул файрволл" или "не самый умный" :) ) ? И извините за мою очевидную ламернутость :) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282318,282347#msg-282347 From nginx-forum на forum.nginx.org Tue Dec 11 14:47:53 2018 From: nginx-forum на forum.nginx.org (ingtar) Date: Tue, 11 Dec 2018 09:47:53 -0500 Subject: =?UTF-8?B?UmU6IE9wZW5zc2wgMS4xLjEgKyBuZ2lueCAxLjE0LjAg0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHRsczEuMQ==?= In-Reply-To: <20181211135221.GG25685@protva.ru> References: <20181211135221.GG25685@protva.ru> Message-ID: <18180dfe3568b23e15cd6ac40029a021.NginxMailingListRussian@forum.nginx.org> Не в бровь, а в глаз! [system_default_sect] MinProtocol = TLSv1.2 CipherString = DEFAULT на SECLEVEL=2 После исправления на TLSv1 все заработало Спасибо большое! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282343,282348#msg-282348 From mdounin на mdounin.ru Tue Dec 11 15:02:55 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 11 Dec 2018 18:02:55 +0300 Subject: proxy_socket_keepalive on; In-Reply-To: References: Message-ID: <20181211150254.GX99070@mdounin.ru> Hello! On Tue, Dec 11, 2018 at 09:42:41AM -0500, suffix wrote: > Maxim Konovalov Wrote: > ------------------------------------------------------- > > > Вред от включения этой ручки вряд ли будет. > > Можно тогда последний идиотский вопрос - конкретно в моём случае (вебсервер > из связки nginx + apache) > > vhost .conf nginx: > > upstream http_backend { > server 127.0.0.1:8080; > keepalive 100; > } > location / { > proxy_pass http://http_backend; > proxy_redirect http://http_backend /; > proxy_http_version 1.1; > proxy_set_header Connection ""; > } [...] > Таки стоит в vhost .conf nginx в секцию location добавить > proxy_socket_keepalive on; или нет (при условии что неизвестно "умный > стейтфул файрволл" или "не самый умный" :) ) ? Если у вас на локалхосте между nginx'ом и бэкендом statefull firewall - в первую голову стоит его выключить. Включать proxy_socket_keepalive имеет смысл тогда, когда вы firewall не котроллируете, знаете о проблеме с firewall'ом, и ничего с этой проблемой сделать не можете. Вреда от включения proxy_socket_keepalive в остальных случаях скорее всего не будет (с точностью до минимальных затрат процессора на setsockopt()), но и смысла в этом приблизительно никакого. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Dec 11 19:54:29 2018 From: nginx-forum на forum.nginx.org (suffix) Date: Tue, 11 Dec 2018 14:54:29 -0500 Subject: =?UTF-8?B?dXBzdHJlYW0gcHJlbWF0dXJlbHkgY2xvc2VkIGNvbm5lY3Rpb24gKNC90L4g0Lo=?= =?UTF-8?B?0LDQui3RgtC+INGB0YLRgNCw0L3QvdC+KQ==?= Message-ID: <64721727a5f9b1c9f1e57f850033623c.NginxMailingListRussian@forum.nginx.org> Смотрю error.log nginx: 2018/12/11 16:38:51 [error] 2893#2893: *45224 upstream prematurely closed connection while reading response header from upstream, client: 66.249.76.90, server: www.babai.ru, request: "GET /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1", upstream: "http://127.0.0.1:8080/articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes", host: "www.babai.ru" Однако в это же время в access.log apache: 66.249.76.90 - - [11/Dec/2018:16:38:51 +0300] 0 "GET /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1" 200 45443 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" Код 200 И в это же время в access.log nginx: 66.249.76.90 - - [11/Dec/2018:16:38:51 +0300] "GET /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1" 200 12664 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" Тоже код 200 Откуда тогда ошибка то ? Крайне редко встречается и только с amp страницами. И в сёчконсоли раз в 3-4 месяца появляется ошибка что какая то страница amp недоступна. Потом ошибка исчезает. Кто виноват ? Почему так ? И надо ли что-то с этим делать ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282352,282352#msg-282352 From bgx на protva.ru Tue Dec 11 20:24:55 2018 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 11 Dec 2018 23:24:55 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIHByZW1hdHVyZWx5IGNsb3NlZCBjb25uZWN0aW9uICjQvdC+?= =?UTF-8?B?INC60LDQui3RgtC+INGB0YLRgNCw0L3QvdC+KQ==?= In-Reply-To: <64721727a5f9b1c9f1e57f850033623c.NginxMailingListRussian@forum.nginx.org> References: <64721727a5f9b1c9f1e57f850033623c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181211202455.GJ25685@protva.ru> On Tue, Dec 11, 2018 at 02:54:29PM -0500, suffix wrote: > Смотрю error.log nginx: > > 2018/12/11 16:38:51 [error] 2893#2893: *45224 upstream prematurely closed > connection while reading response header from upstream, client: > 66.249.76.90, server: www.babai.ru, request: "GET > /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1", > upstream: > "http://127.0.0.1:8080/articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes", > host: "www.babai.ru" > > Однако в это же время в access.log apache: > > 66.249.76.90 - - [11/Dec/2018:16:38:51 +0300] 0 "GET > /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1" 200 > 45443 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile > Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" > > Код 200 > > И в это же время в access.log nginx: > > 66.249.76.90 - - [11/Dec/2018:16:38:51 +0300] "GET > /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1" 200 > 12664 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile > Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" > > Тоже код 200 > > Откуда тогда ошибка то ? В лог-формате "combined" после статус-кода (200) идёт body_bytes_sent. Видно, что апач отдал nginx-у 45443 байта, а ngnix клиенту 12664, так что обоснованное подозрение на то, что nginx недополучил данные. В HTTP/1.1 есть механизм контроля целостности данных, и nginx может видеть, что ему прислали ответ короче, чем должно быть по его заголовку. Я бы прежде всего подумал, нет ли между апачем и nginx-ом statefull файрвола, который из-за какой-то ошибки в своей логике иногда обрывает коннекции, например, содержащие этот "amp". -- Eugene Berdnikov From nginx-forum на forum.nginx.org Tue Dec 11 21:10:32 2018 From: nginx-forum на forum.nginx.org (suffix) Date: Tue, 11 Dec 2018 16:10:32 -0500 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIHByZW1hdHVyZWx5IGNsb3NlZCBjb25uZWN0aW9uICjQvdC+?= =?UTF-8?B?INC60LDQui3RgtC+INGB0YLRgNCw0L3QvdC+KQ==?= In-Reply-To: <20181211202455.GJ25685@protva.ru> References: <20181211202455.GJ25685@protva.ru> Message-ID: Evgeniy Berdnikov Wrote: ------------------------------------------------------- > Видно, что апач отдал nginx-у 45443 байта, а ngnix клиенту 12664, так > что > обоснованное подозрение на то, что nginx недополучил данные. > В HTTP/1.1 есть механизм контроля целостности данных, и nginx может > видеть, > что ему прислали ответ короче, чем должно быть по его заголовку. > Прошу прощения - наверное туплю - а разница в размере не может быть из включенных в nginx всяких там brotli и gzip ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282352,282356#msg-282356 From nginx-forum на forum.nginx.org Wed Dec 12 04:11:06 2018 From: nginx-forum на forum.nginx.org (suffix) Date: Tue, 11 Dec 2018 23:11:06 -0500 Subject: proxy_socket_keepalive on; In-Reply-To: <20181211150254.GX99070@mdounin.ru> References: <20181211150254.GX99070@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Tue, Dec 11, 2018 at 09:42:41AM -0500, suffix wrote: > > > Maxim Konovalov Wrote: > > ------------------------------------------------------- > Если у вас на локалхосте между nginx'ом и бэкендом statefull > firewall - в первую голову стоит его выключить. > У меня между nginx и apache только apache modsecurity - он считается за statefull ? Его надо отключить ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282318,282357#msg-282357 From nginx-forum на forum.nginx.org Wed Dec 12 10:45:14 2018 From: nginx-forum на forum.nginx.org (Siava) Date: Wed, 12 Dec 2018 05:45:14 -0500 Subject: =?UTF-8?B?aHR0cHMgKyByZXZlcnNlIHByb3h5ICsg0LfQsNC60YDRi9Cw0Y7RidC40Lkg0YE=?= =?UTF-8?B?0LvQtdGI?= Message-ID: <6a994a65cdfda0ab6653d90014f29d36.NginxMailingListRussian@forum.nginx.org> Второй день ломаю голову. Используется reverse proxy схема. Сайт работает по https. Все запросы на http перенаправляются на https. На сайте есть каталог. Если в запросе к каталогу не указывать закрывающий слеш, то происходит два редиректа: 1. сначала на сайт с http с тем же путём но с закрывающим слешем 2. а после обратно на https с закрывающим слешем. Как сделать, чтобы редирект вёл сразу на https с закрывающим слешем? В качестве примера создал поддомен, где это можно посмотреть. https://apstenu.siava.ru/test > http://apstenu.siava.ru/test/ > https://apstenu.siava.ru/test/ Редиректы проверял с помощью сервисов https://showredirects.com/ http://www.redirect-checker.org/ Конфиг reverse proxy: http { ... server { listen 80; server_name apstenu.siava.ru; return 301 https://apstenu.siava.ru$request_uri; } server { listen 443 ssl http2; server_name apstenu.siava.ru; include /etc/nginx/ssl-siava.ru; access_log off; location / { proxy_pass http://192.168.0.2; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } } Конфиг backend-сервера 192.168.0.2: server { listen 80; server_name apstenu.siava.ru; access_log off; log_not_found off; root /home/apstenu.siava.ru; location / { try_files $uri $uri/ =404; index index.jpg; } location ~* ^.+\.(jpg|htm)$ { expires 30d; } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282360,282360#msg-282360 From mdounin на mdounin.ru Wed Dec 12 12:55:41 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 12 Dec 2018 15:55:41 +0300 Subject: proxy_socket_keepalive on; In-Reply-To: References: <20181211150254.GX99070@mdounin.ru> Message-ID: <20181212125541.GA99070@mdounin.ru> Hello! On Tue, Dec 11, 2018 at 11:11:06PM -0500, suffix wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Hello! > > > > On Tue, Dec 11, 2018 at 09:42:41AM -0500, suffix wrote: > > > > > Maxim Konovalov Wrote: > > > ------------------------------------------------------- > > > Если у вас на локалхосте между nginx'ом и бэкендом statefull > > firewall - в первую голову стоит его выключить. > > > > У меня между nginx и apache только apache modsecurity - он считается за > statefull ? Его надо отключить ? ModSecurity - это не firewall, а так называемый "web application firewall", WAF. Он не имеет никакого отношения к тому, что происходит на уровне TCP-соединений, а анализирует HTTP-запросы, уже полученные web-сервером. Соответственно к директиве proxy_socket_keepalive - тоже не имеет отношения. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Dec 12 13:40:38 2018 From: nginx-forum на forum.nginx.org (suffix) Date: Wed, 12 Dec 2018 08:40:38 -0500 Subject: proxy_socket_keepalive on; In-Reply-To: <20181212125541.GA99070@mdounin.ru> References: <20181212125541.GA99070@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > ModSecurity - это не firewall, а так называемый "web application > firewall", WAF. Он не имеет никакого отношения к тому, что > происходит на уровне TCP-соединений, а анализирует HTTP-запросы, > уже полученные web-сервером. Соответственно к директиве > proxy_socket_keepalive - тоже не имеет отношения. Большое спасибо ! P.S. Случайно не подскажете чем может быть вызвана такая ситуация ?: 2018/12/12 11:29:24 [error] 2898#2898: *78776 upstream prematurely closed connection while reading response header from upstream, client: 5.101.180.206, server: www.babai.ru, request: "GET /articles/pismo-malenkogo-porosenka.html HTTP/2.0", upstream: "http://127.0.0.1:8080/articles/pismo-malenkogo-porosenka.html", host: "www.babai.ru", referrer: "https://www.babai.ru/" Причем это именно я по счастливой случайности заходил на сайт и страница открылась нормально да и в accesslog код 200: apache: 5.101.180.206 - - [12/Dec/2018:11:29:24 +0300] 0 "GET /articles/pismo-malenkogo-porosenka.html HTTP/1.1" 200 29930 "https://www.babai.ru/" "Mozilla/5.0 (Linux; Android 8.0.0; SAMSUNG SM-G960F Build/R16NW) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/7.4 Chrome/59.0.3071.125 Mobile Safari/537.36" nginx: 5.101.180.206 - - [12/Dec/2018:11:29:24 +0300] "GET /articles/pismo-malenkogo-porosenka.html HTTP/2.0" 200 7786 "https://www.babai.ru/" "Mozilla/5.0 (Linux; Android 8.0.0; SAMSUNG SM-G960F Build/R16NW) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/7.4 Chrome/59.0.3071.125 Mobile Safari/537.36" ошибка редкая очень но напрягает ... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282318,282363#msg-282363 From mdounin на mdounin.ru Wed Dec 12 14:23:02 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 12 Dec 2018 17:23:02 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIHByZW1hdHVyZWx5IGNsb3NlZCBjb25uZWN0aW9uICjQvdC+?= =?UTF-8?B?INC60LDQui3RgtC+INGB0YLRgNCw0L3QvdC+KQ==?= In-Reply-To: <64721727a5f9b1c9f1e57f850033623c.NginxMailingListRussian@forum.nginx.org> References: <64721727a5f9b1c9f1e57f850033623c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181212142302.GB99070@mdounin.ru> Hello! On Tue, Dec 11, 2018 at 02:54:29PM -0500, suffix wrote: > Смотрю error.log nginx: > > 2018/12/11 16:38:51 [error] 2893#2893: *45224 upstream prematurely closed > connection while reading response header from upstream, client: > 66.249.76.90, server: www.babai.ru, request: "GET > /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1", > upstream: > "http://127.0.0.1:8080/articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes", > host: "www.babai.ru" > > Однако в это же время в access.log apache: > > 66.249.76.90 - - [11/Dec/2018:16:38:51 +0300] 0 "GET > /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1" 200 > 45443 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile > Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" > > Код 200 > > И в это же время в access.log nginx: > > 66.249.76.90 - - [11/Dec/2018:16:38:51 +0300] "GET > /articles/prezhde-chem-prinesti-svinyu-domoj.html?amp=yes HTTP/1.1" 200 > 12664 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile > Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" > > Тоже код 200 > > Откуда тогда ошибка то ? Скорее всего, ошибка - от первой попытки отправить запрос на бэкенд. Вторая, видимо, была успешной. Залоггируйте переменные $upstream_addr и $upstream_status, там будут подробности. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Wed Dec 12 15:41:29 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 12 Dec 2018 18:41:29 +0300 Subject: proxy_socket_keepalive on; In-Reply-To: References: <20181212125541.GA99070@mdounin.ru> Message-ID: <20181212154129.GF99070@mdounin.ru> Hello! On Wed, Dec 12, 2018 at 08:40:38AM -0500, suffix wrote: > P.S. > > Случайно не подскажете чем может быть вызвана такая ситуация ?: > > 2018/12/12 11:29:24 [error] 2898#2898: *78776 upstream prematurely closed > connection while reading response header from upstream, client: > 5.101.180.206, server: www.babai.ru, request: "GET > /articles/pismo-malenkogo-porosenka.html HTTP/2.0", upstream: > "http://127.0.0.1:8080/articles/pismo-malenkogo-porosenka.html", host: > "www.babai.ru", referrer: "https://www.babai.ru/" > > Причем это именно я по счастливой случайности заходил на сайт и страница > открылась нормально да и в accesslog код 200: http://mailman.nginx.org/pipermail/nginx-ru/2018-December/061740.html -- Maxim Dounin http://mdounin.ru/ From vbart на nginx.com Wed Dec 12 16:59:35 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 12 Dec 2018 19:59:35 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <4577595.qXaYJQFISI@note> References: <1547311.QE54pxguhk@vbart-workstation> <5416237.0ZquYHsRLQ@vbart-workstation> <4577595.qXaYJQFISI@note> Message-ID: <3269135.ulkEcgTsCX@vbart-workstation> On Tuesday 20 November 2018 00:17:41 Vadim A. Misbakh-Soloviov wrote: > > Думаю, что нужно просто добавить туда --unsafe-perm. > > Ну, тут уж вам там, как апстриму виднее :) > Вы только маякните, пожалуйста, когда можно будет манки-патч седовый убирать > :) [..] Начиная с сегодняшнего коммита можно убрать: http://hg.nginx.org/unit/rev/ec44091ce04a -- Валентин Бартенев From nginx-forum на forum.nginx.org Thu Dec 13 12:37:41 2018 From: nginx-forum на forum.nginx.org (Siava) Date: Thu, 13 Dec 2018 07:37:41 -0500 Subject: =?UTF-8?B?UmU6IGh0dHBzICsgcmV2ZXJzZSBwcm94eSArINC30LDQutGA0YvQsNGO0YnQuNC5?= =?UTF-8?B?INGB0LvQtdGI?= In-Reply-To: <6a994a65cdfda0ab6653d90014f29d36.NginxMailingListRussian@forum.nginx.org> References: <6a994a65cdfda0ab6653d90014f29d36.NginxMailingListRussian@forum.nginx.org> Message-ID: <6ad2f84111d0c7d95fde3149349dbfcd.NginxMailingListRussian@forum.nginx.org> Кажется помогло использование proxy_redirect: proxy_redirect http://apstenu.siava.ru/ /; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282360,282376#msg-282376 From nginx на kinetiksoft.com Sat Dec 15 11:04:21 2018 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Sat, 15 Dec 2018 14:04:21 +0300 Subject: =?UTF-8?B?dW5pdDog0L7RiNC40LHQutCwIHNlbmQ=?= Message-ID: <2a7cd85f-9aa1-692d-b8be-39bdbf3e5e37@kinetiksoft.com> Здравствуйте. Что в предыдущих версиях unit, что в свежей 1.6 практически сразу после запуска в unit.log появилась запись: 2018/12/15 13:58:24 [error] 6403#6452 *1393 send(54, 7F2D37600000, 43) failed (32: Broken pipe) Кроме как сама по себе в логах ошибка вроде нигде не проявилась. debian stretch, unit 1.6 из репов с модулем php 7.0.27-0+deb9u1  . php-приложение под очень высоким rps. Мы хотели бы мониторить логи unit на появление ошибок, следовательно любые подобные непонятки смущают. С уважением, Иван. From vbart на nginx.com Sat Dec 15 13:07:38 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 15 Dec 2018 16:07:38 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6INC+0YjQuNCx0LrQsCBzZW5k?= In-Reply-To: <2a7cd85f-9aa1-692d-b8be-39bdbf3e5e37@kinetiksoft.com> References: <2a7cd85f-9aa1-692d-b8be-39bdbf3e5e37@kinetiksoft.com> Message-ID: <7024309.ohRTxO47r8@vbart-laptop> On Saturday, 15 December 2018 14:04:21 MSK Иван wrote: > Здравствуйте. > > Что в предыдущих версиях unit, что в свежей 1.6 практически сразу после > запуска в unit.log появилась запись: > > 2018/12/15 13:58:24 [error] 6403#6452 *1393 send(54, 7F2D37600000, 43) > failed (32: Broken pipe) > > Кроме как сама по себе в логах ошибка вроде нигде не проявилась. > > debian stretch, unit 1.6 из репов с модулем php 7.0.27-0+deb9u1 . > php-приложение под очень высоким rps. > > Мы хотели бы мониторить логи unit на появление ошибок, следовательно > любые подобные непонятки смущают. > Добрый день. Дебаг-лог бы хотелось увидеть с этой ошибкой. Иструкция как включить: https://unit.nginx.org/troubleshooting/ -- Валентин Бартенев From nginx-forum на forum.nginx.org Sat Dec 15 19:59:57 2018 From: nginx-forum на forum.nginx.org (SpongeRobert) Date: Sat, 15 Dec 2018 14:59:57 -0500 Subject: =?UTF-8?B?UmU6IHVuaXQ6INC+0YjQuNCx0LrQsCBzZW5k?= In-Reply-To: <7024309.ohRTxO47r8@vbart-laptop> References: <7024309.ohRTxO47r8@vbart-laptop> Message-ID: <7f3e946f2bb313b0b0dd7f3c5a292d02.NginxMailingListRussian@forum.nginx.org> Дебаг-лог идея хорошая, однако есть небольшая загвоздка: похожие ошибки появляются всего несколько раз в день и отлавливаем мы их по сочетанию [alert] или [error] + "failed" дальше в строке. В дебаг-режиме ведь формат лога отличается, не так ли? А внешних проявлений нет. Подскажете, как быть? Вот примеры: 2018/10/22 23:47:03 [alert] 26478#26478 sendmsg(14, -1, 2) failed (32: Broken pipe) 2018/12/15 16:57:45 [error] 6403#6452 *361223 send(54, 7F2D37604000, 43) failed (32: Broken pipe) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282394,282396#msg-282396 From vbart на nginx.com Sat Dec 15 21:48:26 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 16 Dec 2018 00:48:26 +0300 Subject: =?UTF-8?B?UmU6IHVuaXQ6INC+0YjQuNCx0LrQsCBzZW5k?= In-Reply-To: <7f3e946f2bb313b0b0dd7f3c5a292d02.NginxMailingListRussian@forum.nginx.org> References: <7024309.ohRTxO47r8@vbart-laptop> <7f3e946f2bb313b0b0dd7f3c5a292d02.NginxMailingListRussian@forum.nginx.org> Message-ID: <2821247.lJKMtYeOHW@vbart-laptop> On Saturday, 15 December 2018 22:59:57 MSK SpongeRobert wrote: > Дебаг-лог идея хорошая, однако есть небольшая загвоздка: похожие ошибки > появляются всего несколько раз в день и отлавливаем мы их по сочетанию > [alert] или [error] + "failed" дальше в строке. В дебаг-режиме ведь формат > лога отличается, не так ли? А внешних проявлений нет. Подскажете, как быть? > > Вот примеры: > 2018/10/22 23:47:03 [alert] 26478#26478 sendmsg(14, -1, 2) failed (32: > Broken pipe) > 2018/12/15 16:57:45 [error] 6403#6452 *361223 send(54, 7F2D37604000, 43) > failed (32: Broken pipe) > А можно увидеть конфигурацию? Если не хотите публиковать, то можно выслать мне на почту: vbart на nginx.com -- Валентин Бартенев From nginx-forum на forum.nginx.org Thu Dec 20 13:18:40 2018 From: nginx-forum на forum.nginx.org (darksmoke) Date: Thu, 20 Dec 2018 08:18:40 -0500 Subject: upstream timed out (60: Operation timed out) Message-ID: Добрый день Время от времени в логах Nginx наблюдаю такие записи 2018/12/20 14:53:05 [error] 67589#0: *26303544 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 10.1.110.74, server: site.loc, request: "POST /transactions/credit/ HTTP/1.1", upstream: "http://10.62.145.96:33084/transactions/credit/", host: "site.loc" В момент таких ошибок, я проверял бэк, он работает, до порта досткуиваюсь. Есть предположения что апстри становитс не рабочим из-за ошибок. Мол Nginx вывел его сам. Как можно это залогировать что бы точно знать причину таких ошибок? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282422,282422#msg-282422 From shadow.tehb на gmail.com Thu Dec 20 13:21:27 2018 From: shadow.tehb на gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCe0LvQtdCz0L7QstC40Yc=?=) Date: Thu, 20 Dec 2018 16:21:27 +0300 Subject: upstream timed out (60: Operation timed out) In-Reply-To: References: Message-ID: https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_read_timeout С этим всё впорядке? чт, 20 дек. 2018 г. в 16:18, darksmoke : > Добрый день > Время от времени в логах Nginx наблюдаю такие записи > > 2018/12/20 14:53:05 [error] 67589#0: *26303544 upstream timed out (60: > Operation timed out) while reading response header from upstream, client: > 10.1.110.74, server: site.loc, request: "POST /transactions/credit/ > HTTP/1.1", upstream: "http://10.62.145.96:33084/transactions/credit/", > host: > "site.loc" > > В момент таких ошибок, я проверял бэк, он работает, до порта досткуиваюсь. > Есть предположения что апстри становитс не рабочим из-за ошибок. Мол Nginx > вывел его сам. > Как можно это залогировать что бы точно знать причину таких ошибок? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,282422,282422#msg-282422 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Dec 20 13:53:01 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 20 Dec 2018 16:53:01 +0300 Subject: upstream timed out (60: Operation timed out) In-Reply-To: References: Message-ID: <20181220135301.GB99070@mdounin.ru> Hello! On Thu, Dec 20, 2018 at 08:18:40AM -0500, darksmoke wrote: > Добрый день > Время от времени в логах Nginx наблюдаю такие записи > > 2018/12/20 14:53:05 [error] 67589#0: *26303544 upstream timed out (60: > Operation timed out) while reading response header from upstream, client: > 10.1.110.74, server: site.loc, request: "POST /transactions/credit/ > HTTP/1.1", upstream: "http://10.62.145.96:33084/transactions/credit/", host: > "site.loc" > > В момент таких ошибок, я проверял бэк, он работает, до порта досткуиваюсь. > Есть предположения что апстри становитс не рабочим из-за ошибок. Мол Nginx > вывел его сам. > Как можно это залогировать что бы точно знать причину таких ошибок? Причина ошибки заллогирована: nginx сделал запрос на бэкенд, и ждал ответа от бэкенда в течении proxy_read_timeout. Не дождался, о чём и сообщает. Почему именно у вас бэкенд долго отвечает - смотрите в логах бэкенда. Ну или залоггируйте $upstream_header_time / $upstream_response_time, это должно помочь разобраться, на какие запросы бэкенд отвечает медленно. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Dec 20 13:54:25 2018 From: nginx-forum на forum.nginx.org (darksmoke) Date: Thu, 20 Dec 2018 08:54:25 -0500 Subject: upstream timed out (60: Operation timed out) In-Reply-To: References: Message-ID: <9b9f5b1e4205491a9a9355951b52023c.NginxMailingListRussian@forum.nginx.org> upstream site { server xx.xx.xx.185:33084 max_fails=20 fail_timeout=1; server xx.xx.xx.96:33084 max_fails=20 fail_timeout=1; server xx.xx.xx.94:7070 max_fails=20 fail_timeout=1; serverxx.xx.xx.167:7070 max_fails=20 fail_timeout=1; } server { server_name site.loc; listen 80; access_log /opt/nginx/logs/now/site.access.log; error_log /opt/nginx/logs/site.error.log error; location / { proxy_pass http://site; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Request-Id $request_id; proxy_read_timeout 3s; proxy_send_timeout 3s; proxy_next_upstream error http_502 http_500 http_503 http_504 timeout; } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282422,282426#msg-282426 From nginx-forum на forum.nginx.org Thu Dec 20 14:02:31 2018 From: nginx-forum на forum.nginx.org (darksmoke) Date: Thu, 20 Dec 2018 09:02:31 -0500 Subject: upstream timed out (60: Operation timed out) In-Reply-To: <20181220135301.GB99070@mdounin.ru> References: <20181220135301.GB99070@mdounin.ru> Message-ID: А как залогировать upstream_header_time и upstream_response_time если это error лог. Я не нашел как изменить формат error лога. :( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282422,282427#msg-282427 From mdounin на mdounin.ru Thu Dec 20 14:29:01 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 20 Dec 2018 17:29:01 +0300 Subject: upstream timed out (60: Operation timed out) In-Reply-To: References: <20181220135301.GB99070@mdounin.ru> Message-ID: <20181220142901.GC99070@mdounin.ru> Hello! On Thu, Dec 20, 2018 at 09:02:31AM -0500, darksmoke wrote: > А как залогировать upstream_header_time и upstream_response_time если это > error лог. Я не нашел как изменить формат error лога. :( Переменные $upstream_header_time и $upstream_response_time можно залоггировать в access log. Так вы будете видеть не только фатальные ошибки, когда nginx не смог дождаться ответа за отведённое время и соответственно ругается в error log, но и просто "тормоза" бэкенда, даже если в отведённый таймаут он смог уложиться. (А в случае ошибки их как раз логгировать более или менее бесполезно - мы и так знаем, что proxy_read_timeout случился, и после этого мы ждать заголовок от бэкенда перестали.) Подробнее о том, как настроить access log, можно почитать тут: http://nginx.org/ru/docs/http/ngx_http_log_module.html -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Dec 20 16:21:12 2018 From: nginx-forum на forum.nginx.org (darksmoke) Date: Thu, 20 Dec 2018 11:21:12 -0500 Subject: upstream timed out (60: Operation timed out) In-Reply-To: References: Message-ID: <270fe54d699ca904c7fc5b1cd49d8069.NginxMailingListRussian@forum.nginx.org> А как можно сопоставить запрос от клиента с записью в error логе. В access логе все четко и ясно. Там есть время, есть реквест ИД. А в эррор логе ничего такого нет. А мне хотелось бы нати этот запрос который не отработал в отведенное ему время и провести над ним работы. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282422,282429#msg-282429 From mdounin на mdounin.ru Thu Dec 20 17:22:25 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 20 Dec 2018 20:22:25 +0300 Subject: upstream timed out (60: Operation timed out) In-Reply-To: <270fe54d699ca904c7fc5b1cd49d8069.NginxMailingListRussian@forum.nginx.org> References: <270fe54d699ca904c7fc5b1cd49d8069.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181220172225.GE99070@mdounin.ru> Hello! On Thu, Dec 20, 2018 at 11:21:12AM -0500, darksmoke wrote: > А как можно сопоставить запрос от клиента с записью в error логе. > В access логе все четко и ясно. Там есть время, есть реквест ИД. А в эррор > логе ничего такого нет. > А мне хотелось бы нати этот запрос который не отработал в отведенное ему > время и провести над ним работы. В любой записи error log'а есть: 1. Время: 2018/12/20 14:53:05 2. Идентификатор процесса (в access log можно записать $pid): 67589# 3. Идентификатор соединения (в access log можно записать $connection): *26303544 4. IP-адрес клиента: client: 10.1.110.74 5. Запрос полностью: request: "POST /transactions/credit/ HTTP/1.1" Кроме того, там же есть ещё и upstream, к которому обращались в момент возникновения ошибки (он же будет в $upstream_addr, если вы его залоггируете в access log), и сервер, к которому обращались. В access log с настройками по умолчанию попадает как минимум IP-адрес клиента, время окончания обработки запроса (то есть время ошибки - гарантировано находится в интервале $request_time до этого времени), и запрос полностью. Обычно этого достаточно, чтобы идентифицировать запрос в access log'е. Если вдруг нет - можно добавить в access log переменные $connection и $pid. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Dec 21 05:34:39 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Fri, 21 Dec 2018 00:34:39 -0500 Subject: drop connection Message-ID: Доброго времени суток! Кейс такой, на NS прописан 'wildcard *.exemple.com', директивой server_name разгуливаю на бэкенды. При наборе разной белиберды - 'asdfgasdg.exemple.com' отправляет на первый server_name. Сделал заглушку типа 'server_name _;' которая кидает на 404. Как совсем дропать имена которые не заданы в конфиге? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282435,282435#msg-282435 From fe на hamilton.rinet.ru Fri Dec 21 08:58:03 2018 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Fri, 21 Dec 2018 11:58:03 +0300 Subject: drop connection In-Reply-To: References: Message-ID: 21.12.2018 8:34, inkognito0609 пишет: > Доброго времени суток! > > Кейс такой, на NS прописан 'wildcard *.exemple.com', директивой server_name > разгуливаю на бэкенды. > > При наборе разной белиберды - 'asdfgasdg.exemple.com' отправляет на первый > server_name. > Сделал заглушку типа 'server_name _;' которая кидает на 404. > Как совсем дропать имена которые не заданы в конфиге? return 444; ? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282435,282435#msg-282435 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From vbart на nginx.com Fri Dec 21 14:05:28 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 21 Dec 2018 17:05:28 +0300 Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuNw==?= Message-ID: <5386737.VHhKR9LZL6@vbart-laptop> Здравствуйте. Рад сообщить о выпуске новой версии NGINX Unit. Это корректирующий выпуск, который нацелен на повышение стабильности Node.js модуля. Нам удалось добиться существенных результатов и теперь поддержка Node.js в лучшем состоянии. Изменения в Unit 1.7 20.12.2018 *) Изменение: теперь rpath задается в модуле Ruby, только если библиотека не найдена в путях по умолчанию; это позволяет соблюсти требования к пакетированию в некоторых системах. *) Исправление: не работали опции PHP "disable_functions" и "disable_classes", заданные через управляющий API. *) Исправление: не срабатывали Promises для данных из запросов в Node.js. *) Исправление: различные проблемы совместимости с приложениями Node.js. *) Исправление: в модуле Node.js происходила ошибка сегментации, если приложение читало тело запроса после вызова request.end(). *) Исправление: в модуле Node.js происходила ошибка сегментации, если приложение пыталось дважды отправить заголовок. *) Исправление: при манипуляциях с полями заголовка ответа в модуле Node.js не принималось во внимание, что регистр их имен не должен учитываться. *) Исправление: неперехваченные исключения в Node.js не записывались в лог. *) Исправление: глобальная установка модуля Node.js из исходников не работала в некоторых окружениях; ошибка появилась в версии 1.6. *) Исправление: обратная трассировка исключений при инициализации приложений на Python не записывалась в лог. *) Исправление: модуль PHP не собирался, если интерпретатор PHP был собран с включенной потокобезопасностью. Хайли лайкли, данный релиз станет последним в 2018 году. И от всей нашей команды Unit-а я поздравляю вас с наступающим Новым Годом. 2018 год получился очень насыщенным с точки зрения развития проекта Unit. Множество важных нововведений удалось реализовать, включая: - Расширенное управление процессами, что позволяет динамически масштабировать приложение в зависимости от нагрузки. Спасибо Максиму Романову, который преимущественно работал над этой возможностью. Документация: https://unit.nginx.org/configuration/#process-management - Поддержка приложений на Perl, Ruby и Node.js. Спасибо Александру Борисову, который занимался разработкой этих языковых модулей. - TLS и интерфейс для управления хранилищем сертификатов, который позволяет динамически загружать и перенастраивать сертификаты. Спасибо Игорю Сысоеву, который работал вместе со мной над этой возможностью. Документация: https://unit.nginx.org/configuration/#ssl-tls-and-certificates - C API для языковых модулей был вынесен в отдельную библиотеку, что сильно облегчило интеграцию с Node.js и помогло с предстоящим внедрением поддержки Java приложений. Ещё раз спасибо Максиму Романову за эту работу. - Начальная поддержка логирования доступа. Документация: https://unit.nginx.org/configuration/#access-log - Расширенные настройки приложений, включая переменные окружения, аргументы запуска, опции PHP и путей к php.ini. Не могу вообразить выпуск всей этой функциональности без кропотливой работы нашего инженера по качеству Андрея Зеленкова. Он беспрестанно повышал покрытие кода Unit-а функциональными тестами, проводил различное фаззинг-тестирование и оповещал разработчиков о любом подозрительном поведении сервера. Также одним из ключевых достижений этого года стало существенное улучшение полноты и качества документации. Сайт unit.nginx.org теперь полностью актуализирован и содержит информацию обо всех появившихся возможностях, как в самых последних, так и во всех более ранних версиях Unit-а. С этой задачей успешно справился наш технический писатель Артем Конев. Кроме того, он продолжает перерабатывать документацию и планирует серию Howto по настройке Unit-а в различных ситуациях и для запуска разных приложений. Если у вас есть пожелания по конкретным приложениям, которые вы хотели бы запускать в Unit-е, то, пожалуйста, создайте запрос по документации на GitHub: - https://github.com/nginx/unit-docs/issues Спасибо нашим системным инженерам: Андрею Белову и Константину Павлову, которые обеспечивали свежими пакетами репозитории для различных дистрибутивов и подготавливали образы для Docker-а. Спасибо нашему продуктовому менеджеру Николаю Шадрину, который помогал со стратегией развития и блестяще выступал на конференциях по всему миру. Вы можете увидеть его в записи с недавней конференции NGINX Conf 2018, где он демонстрировал последние возможности Unit-а: - https://www.youtube.com/watch?v=JQZKbIG3uro Безусловно всё, что я упомянул, было бы невозможно без нашего замечательного сообщества пользователей. Они по достоинству оценили перспективы Unit-а и начали постепенно переносить на него свои проекты. Благодарю всех, кто сообщал о найденных ошибках и предлагал различные интересные идеи к реализации, оставлял ценные пожелания по дальнейшему развитию проекта, которые безусловно будут учтены по мере возможности. Мы приглашаем каждого принять участие через список рассылки: - http://mailman.nginx.org/mailman/listinfo/unit или в GitHub: - https://github.com/nginx/unit Особенно хочется отметить 洪志道 (Hong Zhi Dao), как одного из самых активных участников сообщества, который не только сообщает об ошибках, но и регулярно вычитывает код, задает наводящие вопросы и присылает различные патчи с улучшениями. Спасибо ему огромное за вклад в проект. Отдельное спасибо ответственным за пакеты Unit-а в различных системах, среди которых: Сергей Осокин (FreeBSD), Ralph Seichter (Gentoo), André Klitzing (Alpine Linux) и Julian Brost (Arch Linux). Извините, если кто-то поддерживает репозиторий с пакетами Unit-а в одном из дистрибутивов и не был упомянут. Вы можете открыть запрос на GitHub для внесения вашего репозитория в секцию Installation сайта unit.nginx.org: - https://github.com/nginx/unit-docs/issues К сожалению, нам не удалось достигнуть всех наших грандиозных целей на этот год. Разработку некоторой функциональности пришлось перенести на будущий год. Сейчас продолжается работа над поддержкой WebSocket, модулем Java, маршрутизацией запросов и раздачей статики. Мы уже достигли неплохого прогресса в поддержке Java. Эта разработка ведется в отдельном публичном репозитории на GitHub: - https://github.com/mar0x/unit Таким образом, если вы заинтересованы в запуске приложений на Java, то уже можете принять участие и пробовать. Множество других интересных возможностей и анонсов ждет Unit в 2019 году. Спасибо всем, кто следит за проектом, и желаю всего наилучшего. -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri Dec 21 18:31:17 2018 From: nginx-forum на forum.nginx.org (darksmoke) Date: Fri, 21 Dec 2018 13:31:17 -0500 Subject: upstream timed out (60: Operation timed out) In-Reply-To: <20181220172225.GE99070@mdounin.ru> References: <20181220172225.GE99070@mdounin.ru> Message-ID: Сапсибо помогло очень. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282422,282441#msg-282441 From nginx-forum на forum.nginx.org Mon Dec 24 10:20:17 2018 From: nginx-forum на forum.nginx.org (SmakPHP) Date: Mon, 24 Dec 2018 05:20:17 -0500 Subject: map + access log = bug Message-ID: Есть конфигурация http { ... # The map is bot browsers map $http_user_agent $bot { default 0; "~Chrome" 1; } ... } server { ... # Logging access to the site access_log /var/log/nginx/recipes.log main if=!$bot; access_log /var/log/nginx/recipes.bot.log main if=$bot; ... } смысл задумки разделить лог на два файла, но почему-то пишется сразу в два файла если браузер Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 хотя по идеи должно писаться только в файл recipes.bot.log Может кто-нибудь сталкивался с подобной проблемой? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282446,282446#msg-282446 From raven_kg на megaline.kg Mon Dec 24 10:24:35 2018 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Mon, 24 Dec 2018 16:24:35 +0600 Subject: map + access log = bug In-Reply-To: References: Message-ID: <2d67318a-dc3d-3055-4f13-7695e36a6ca6@megaline.kg> Криво, но суть думаю ясна: map $bot $not_bot { default 1 1 0; } ... access_log /var/log/nginx/recipes.log main if=$not_bot; if в access_log понимает только 1 (true) 24.12.2018 16:20, SmakPHP пишет: > Есть конфигурация > > http { > ... > # The map is bot browsers > map $http_user_agent $bot { > default 0; > "~Chrome" 1; > } > ... > } > > server { > ... > # Logging access to the site > access_log /var/log/nginx/recipes.log main if=!$bot; > access_log /var/log/nginx/recipes.bot.log main if=$bot; > ... > } > > смысл задумки разделить лог на два файла, но почему-то пишется сразу в два > файла если браузер > > Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like > Gecko) Chrome/71.0.3578.98 Safari/537.36 > > хотя по идеи должно писаться только в файл recipes.bot.log > > Может кто-нибудь сталкивался с подобной проблемой? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282446,282446#msg-282446 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin на mdounin.ru Tue Dec 25 15:08:39 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 Dec 2018 18:08:39 +0300 Subject: nginx-1.15.8 Message-ID: <20181225150838.GA99070@mdounin.ru> Изменения в nginx 1.15.8 25.12.2018 *) Добавление: переменная $upstream_bytes_sent. Спасибо Piotr Sikora. *) Добавление: новые директивы в скриптах подсветки синтаксиса для vim. Спасибо Геннадию Махомеду. *) Исправление: в директиве proxy_cache_background_update. *) Исправление: в директиве geo при использовании unix domain listen-сокетов. *) Изменение: при использовании директивы ssl_early_data с OpenSSL в логах могли появляться сообщения "ignoring stale global SSL error ... bad length". *) Исправление: в nginx/Windows. *) Исправление: в модуле ngx_http_autoindex_module на 32-битных платформах. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Thu Dec 27 06:35:48 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Thu, 27 Dec 2018 01:35:48 -0500 Subject: request_time Message-ID: Из чего получается request_time? Прочитав данную доку: https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/, сделал для себя вывод что : $request_time = $upstream_connect_time + $upstream_header_time + $upstream_response_time+$вермя_передачи_до_клиента При увеличении трафика в логах балансера вижу следующее: request_time = 5.009 upstream_connect_time=0.000 upstream_header_time=0.008 upstream_response_time=0.009 Кейс воспроизводится на разных проектах при увеличении нагрузки (50-100ps в зависимости от проекта). Что происходит 5 секунд? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282485,282485#msg-282485 From nginx-forum на forum.nginx.org Thu Dec 27 09:30:05 2018 From: nginx-forum на forum.nginx.org (yanda.a) Date: Thu, 27 Dec 2018 04:30:05 -0500 Subject: request_time In-Reply-To: References: Message-ID: Вероятно, размер ответа большой и клиент долго его получает. Тут либо у клиента медленный канал, либо у сервера, если это наблюдается под нагрузкой. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282485,282488#msg-282488 From chipitsine на gmail.com Thu Dec 27 09:58:42 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 27 Dec 2018 14:58:42 +0500 Subject: request_time In-Reply-To: References: Message-ID: посмотрите, включена ли у вас буферизация запросов и ответов ? чт, 27 дек. 2018 г. в 11:35, inkognito0609 : > Из чего получается request_time? Прочитав данную доку: > > https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/ > , > сделал для себя вывод что : > $request_time = $upstream_connect_time + $upstream_header_time + > $upstream_response_time+$вермя_передачи_до_клиента > > При увеличении трафика в логах балансера вижу следующее: > request_time = 5.009 > upstream_connect_time=0.000 > upstream_header_time=0.008 > upstream_response_time=0.009 > > Кейс воспроизводится на разных проектах при увеличении нагрузки (50-100ps в > зависимости от проекта). Что происходит 5 секунд? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,282485,282485#msg-282485 > > _______________________________________________ > 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 Dec 27 10:47:09 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Thu, 27 Dec 2018 05:47:09 -0500 Subject: request_time In-Reply-To: References: Message-ID: <3c248ea985c92e7290913910b9aec4ef.NginxMailingListRussian@forum.nginx.org> Нагрузка производится Яндекс танком из локальной сети. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282485,282490#msg-282490 From nginx-forum на forum.nginx.org Thu Dec 27 10:52:00 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Thu, 27 Dec 2018 05:52:00 -0500 Subject: request_time In-Reply-To: References: Message-ID: ... proxy_buffering on; ... Да включена Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282485,282491#msg-282491 From nginx-forum на forum.nginx.org Thu Dec 27 12:21:24 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Thu, 27 Dec 2018 07:21:24 -0500 Subject: request_time In-Reply-To: References: Message-ID: <499a3e86a714527649489e284f15af37.NginxMailingListRussian@forum.nginx.org> Отрубил, таже ситуация... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282485,282492#msg-282492 From mdounin на mdounin.ru Thu Dec 27 15:23:25 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 27 Dec 2018 18:23:25 +0300 Subject: request_time In-Reply-To: References: Message-ID: <20181227152325.GG99070@mdounin.ru> Hello! On Thu, Dec 27, 2018 at 01:35:48AM -0500, inkognito0609 wrote: > Из чего получается request_time? Прочитав данную доку: > https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/, > сделал для себя вывод что : > $request_time = $upstream_connect_time + $upstream_header_time + > $upstream_response_time+$вермя_передачи_до_клиента Это неправильный вывод. Во-первых, $upstream_connect_time и $upstream_header_time - это составные части $upstream_response_time, складывать их вместе не нужно. Во-вторых, $request_time - это не только время общения с бэкендом и время досылки ответа после того, как бэкенд полностью прислал ответ, но также и время чтения запроса от бэкенда. То есть $request_time = <время чтения запроса> + $upstream_response_time + <время досылки ответа> Кроме того, в зависимости от конфигруации могут добавляться и всякие другие задержки, например: - если в конфигурации есть auth_request - то и время выполнения auth-подзапроса надо будет добавить; - если в конфигурации используется проксирование с переменными, то нужно ещё добавить время резолвинга соответствующего имени. > При увеличении трафика в логах балансера вижу следующее: > request_time = 5.009 > upstream_connect_time=0.000 > upstream_header_time=0.008 > upstream_response_time=0.009 > > Кейс воспроизводится на разных проектах при увеличении нагрузки (50-100ps в > зависимости от проекта). Что происходит 5 секунд? Исходя из цифры в 5 секунд - подозреваю, что речь про proxy_pass с переменными и теряющиеся пакеты к DNS-серверу. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Dec 28 06:07:40 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Fri, 28 Dec 2018 01:07:40 -0500 Subject: request_time In-Reply-To: <20181227152325.GG99070@mdounin.ru> References: <20181227152325.GG99070@mdounin.ru> Message-ID: Спасибо за развернутый ответ. Переменных нет. upstream nodes_40021 { server 10.59.4.11:40021; server 10.59.4.12:40021; server 10.59.4.13:40021; server 10.59.4.14:40021; } } server { listen 443 ssl http2; server_name smth.exepmle.com; location / { proxy_pass http://nodes_40021; } } Существуют ли какие то средства дебага, на котором этапе происходит деградация? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282485,282497#msg-282497 From andrey на kopeyko.ru Fri Dec 28 10:56:55 2018 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Fri, 28 Dec 2018 13:56:55 +0300 (MSK) Subject: request_time In-Reply-To: References: <20181227152325.GG99070@mdounin.ru> Message-ID: On Fri, 28 Dec 2018, inkognito0609 wrote: > Существуют ли какие то средства дебага, на котором этапе происходит > деградация? Запустите nginx с дебаг-логом и сконфигурите debug_connection http://nginx.org/ru/docs/debugging_log.html В логе будет подробнейшим образом расписано как именно обрабатывался ваш запрос. -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Sat Dec 29 04:10:34 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Fri, 28 Dec 2018 23:10:34 -0500 Subject: request_time In-Reply-To: References: Message-ID: Andrey Kopeyko, спасибо Найдена причина: "36176#36176: *15479 cache lock timeout". Так как proxy_cache_lock_timeout не указан, по умолчанию берет 5сек Дока для страждущих : https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock_timeout На данный момент конфиг кэша следующий. Задам значение proxy_cache_lock_timeout 1. ``` proxy_cache common_cache; proxy_cache_revalidate on; proxy_cache_min_uses 1; proxy_cache_use_stale error timeout; proxy_cache_lock on; ``` Возможно есть какие-то бестпрактикс по тюнингу кэша? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282485,282507#msg-282507 From nginx-forum на forum.nginx.org Sat Dec 29 05:14:56 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Sat, 29 Dec 2018 00:14:56 -0500 Subject: request_time In-Reply-To: References: Message-ID: proxy_cache_lock off; Отключил, при 200 RPS request_time ~ 0.41 Какие минусы при отключенном? proxy_cache_lock on; proxy_cache_lock_timeout 1s; при 200 RPS среднее request_time ~ 0.95 proxy_cache_lock on; proxy_cache_lock_timeout 500ms; при 200 RPS среднее request_time ~ 0.489 Примерно так же как и при отключенном Какие минусы при снижение времени таймаута? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282485,282508#msg-282508 From nginx-forum на forum.nginx.org Sat Dec 29 10:41:38 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Sat, 29 Dec 2018 05:41:38 -0500 Subject: s-maxage Message-ID: В конфигурации балансировщика настроен кэш proxy_cache_methods не указан явно, вследствии чего методы “GET” и “HEAD” всегда кэшируются. Каким образом реализовать кэширование только по заголовку s-maxage Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282512,282512#msg-282512 From mdounin на mdounin.ru Sat Dec 29 14:39:24 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 29 Dec 2018 17:39:24 +0300 Subject: s-maxage In-Reply-To: References: Message-ID: <20181229143924.GI99070@mdounin.ru> Hello! On Sat, Dec 29, 2018 at 05:41:38AM -0500, inkognito0609 wrote: > В конфигурации балансировщика настроен кэш > proxy_cache_methods не указан явно, вследствии чего методы “GET” и “HEAD” > всегда кэшируются. > > Каким образом реализовать кэширование только по заголовку s-maxage Выключить кэширование для всего, где этого заголовка нет? Подробнее тут: http://nginx.org/r/proxy_no_cache -- Maxim Dounin http://mdounin.ru/