From n.boldin на gmail.com Mon Dec 2 08:32:13 2019 From: n.boldin на gmail.com (Nikolay Boldin) Date: Mon, 2 Dec 2019 10:32:13 +0200 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgdC70YPQttC10LHQvdGL0YUg0L/QvtC00LTQvtC8?= =?UTF-8?B?0LXQvdC+0LIg0LIgRW5naW50cm9u?= Message-ID: Здравствуйте, по умолчанию в конфиге прописано перенаправление дефолтных хостов на localhost, в связи с чем основной сайт доступен по адресам поддоменов типа ns1.домен, ns2.домен, mail.домен etc. Изменяю конфиг таким образом, чтобы возвращалась ошибка 403, все работает, но конфиг регулярно перезаписывается, как этого избежать? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From kulmaks на gmail.com Mon Dec 2 10:23:06 2019 From: kulmaks на gmail.com (Maksim Kulik) Date: Mon, 2 Dec 2019 13:23:06 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YHQu9GD0LbQtdCx0L3Ri9GFINC/0L7QtNC0?= =?UTF-8?B?0L7QvNC10L3QvtCyINCyIEVuZ2ludHJvbg==?= In-Reply-To: References: Message-ID: Добрый день. А почему вы решили спросить это у разработчиков nginx, а не у разработчиков engintron? Всегда можно запретить перезапись файлов "в лоб" при помощи chattr +i для необходимых файлов. Но для начала следует разобраться все ли будет работать корректно в таком случае. пн, 2 дек. 2019 г. в 11:32, Nikolay Boldin : > Здравствуйте, по умолчанию в конфиге прописано перенаправление дефолтных > хостов на localhost, в связи с чем основной сайт доступен по адресам > поддоменов типа ns1.домен, ns2.домен, mail.домен etc. > Изменяю конфиг таким образом, чтобы возвращалась ошибка 403, все работает, > но конфиг регулярно перезаписывается, как этого избежать? > _______________________________________________ > 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 3 18:50:57 2019 From: nginx-forum на forum.nginx.org (Klark) Date: Tue, 03 Dec 2019 13:50:57 -0500 Subject: =?UTF-8?B?UHJveHkgY2FjaGUg0YEg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LXQvCBTbGlj?= =?UTF-8?B?ZSDQtNC70Y8gTVA0INC80LXQtNC70LXQvdC90L4g0L7RgtC00LDQtdGC0YE=?= =?UTF-8?B?0Y8g0LrQu9C40LXQvdGC0YM=?= Message-ID: Не могу понять в чем же дело. Есть 2 простеньких сервера (Core i3,16GB Озу) на одном из них несколько HDD а на втором только SSD которые сделаны для кеша соединенны они через локальную сеть 1gbit. На кеш сервере через второй порт сетевой карты идет подача внешнего интернета. Конфиг кеш сервера proxy_cache_path /var/www/html/cache levels=1:2:2 loader_threshold=300 loader_files=300 keys_zone=ssd_cache:300m max_size=150G inactive=12h use_temp_path=off; server { listen *:80; location / { aio threads=default; aio_write on; proxy_http_version 1.1; proxy_set_header Connection ""; slice 3m; proxy_set_header Range $slice_range; proxy_cache_valid 200 206 24h; proxy_cache ssd_cache; proxy_cache_key $uri$slice_range; proxy_pass http://10.0.0.1:80; proxy_cache_lock on; proxy_cache_lock_age 50s; proxy_cache_lock_timeout 0s; proxy_cache_use_stale updating; proxy_connect_timeout 30; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 8k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; } } Конфиг файлового сервера server { listen 80 reuseport; root /var/www/video/public_html/; location / { access_log on; aio threads; directio 256k; #512 output_buffers 16 8m; keepalive_timeout 10s; expires max; sendfile on; sendfile_max_chunk 512k; open_file_cache max=100000 inactive=10m; open_file_cache_valid 5m; open_file_cache_min_uses 1; open_file_cache_errors on; } } При включении онлайн видео 1мб видео скачивается почти 1.5-2 секунды соответстено видео обычно начинается секунд через 10-15 перемотка тоже проходит секунды 4-6. Самое что не понятное интернет канал (Интернет канал тоже 1Gb) даже на половину не нагружен, смотрят видео в этот момент около 50-70 человек. Понять не могу почему же так происходит, как решить подобную проблему? P.S диски на файловом сервере тоже не нагружены если делать скачивание без кеша то скорость скачивания максимальная какая доступна дома (11мб при соединение с интернетом 100мбит) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286394,286394#msg-286394 From andrey на kopeyko.ru Tue Dec 3 23:26:23 2019 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 04 Dec 2019 02:26:23 +0300 Subject: =?UTF-8?B?UmU6IFByb3h5IGNhY2hlINGBINC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg?= =?UTF-8?B?U2xpY2Ug0LTQu9GPIE1QNCDQvNC10LTQu9C10L3QvdC+INC+0YLQtNCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LvQuNC10L3RgtGD?= In-Reply-To: References: Message-ID: <96e5c647594775c104c9d8e60ef1c7f1@kopeyko.ru> Klark писал 2019-12-03 21:50: > При включении онлайн видео 1мб видео скачивается почти 1.5-2 секунды > соответстено видео обычно начинается секунд через 10-15 > перемотка тоже проходит секунды 4-6. Самое что не понятное интернет > канал > (Интернет канал тоже 1Gb) даже на половину не нагружен, смотрят видео в > этот > момент около 50-70 человек. Понять не могу почему же так происходит, Включите на кеш-сервере логирование запросов вот с таким примерно форматом log_format timed '$remote_addr - $remote_user [$time_local]' ' "$request" $status $body_bytes_sent' ' "$http_referer" "$http_user_agent"' ' rt=$request_time ucs="$upstream_cache_status"' ' us="$upstream_status" ua="$upstream_addr"' ' uct="$upstream_connect_time" urt="$upstream_response_time"' ; и наблюдайте за временами upstream_*_time -- Best regards, Andrey A. Kopeyko From coddoc на mail.ru Wed Dec 4 06:50:19 2019 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Wed, 04 Dec 2019 09:50:19 +0300 Subject: =?UTF-8?B?0J3QtdC/0L7QvdGP0YLQutC4INGBIGJpbmFyeV9yZW1vdGVfYWRkcg==?= Message-ID: <1575442219.752942300@f281.i.mail.ru> Доброго времени суток!   Передаю в php два заголовка: proxy_set_header 'User-IP' $remote_addr; proxy_set_header 'BIN-IP'   $binary_remote_addr;   Соответственно, на стороне php ловлю их: $_SERVER ['HTTP_USER_IP'] $_SERVER ['HTTP_BIN_IP']   Параллельно пишу значение $binary_remote_addr в лог nginx.   В логе nginx все правильно: \xC0\xA8\x00\xC8 (мой IP 192.168.0.200)   В php: * Конвертирую первый заголовок в bin, затем в hex. На выходе правильно: string(8) "c0a800c8" * Конвертирую второй заголовок в hex (т.к. он уже bin). На выходе: string(4) "c0a8" Собственно, все. Тупняк. Ткните носом, плз, куда делась половина второго заголовка? Спасибо.   -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Wed Dec 4 07:27:14 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 4 Dec 2019 10:27:14 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0LrQuCDRgSBiaW5hcnlfcmVtb3RlX2FkZHI=?= In-Reply-To: <1575442219.752942300@f281.i.mail.ru> References: <1575442219.752942300@f281.i.mail.ru> Message-ID: <20191204072714.GP16049@sie.protva.ru> On Wed, Dec 04, 2019 at 09:50:19AM +0300, CoDDoC wrote: > В логе nginx все правильно: \xC0\xA8\x00\xC8 (мой IP 192.168.0.200) >   > В php: > >  1. Конвертирую первый заголовок в bin, затем в hex. На выходе правильно: > string(8) "c0a800c8" >  2. Конвертирую второй заголовок в hex (т.к. он уже bin). На выходе: > string(4) "c0a8" > > Собственно, все. Тупняк. Ткните носом, плз, куда делась половина второго > заголовка? Если конвертор думает, что у него на входе c-string (asciz), то естественно нулевой байт он считает концом строки. Возможно, обрезание делается на уровень выше, на выходе из php-шного парсера заголовка. -- Eugene Berdnikov From tolmachev.vlad на gmail.com Wed Dec 4 14:58:09 2019 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Wed, 4 Dec 2019 17:58:09 +0300 Subject: proxy_cache_min_uses time window In-Reply-To: <20191129145430.GR12894@mdounin.ru> References: <20191129131030.GP12894@mdounin.ru> <20191129142138.GQ12894@mdounin.ru> <20191129145430.GR12894@mdounin.ru> Message-ID: Может быть натолкнете, как можно реализовать такую схему: хранить в кэше файлы год, даже без обращения, а заливать их в кэш если есть 2 запроса в сутки? пт, 29 нояб. 2019 г. в 17:54, Maxim Dounin : > Hello! > > On Fri, Nov 29, 2019 at 05:26:52PM +0300, Владислав Толмачев wrote: > > > если я создал элемент и хочу, что бы без обращения он пролежал в кэше > год, > > то всё, что будет обращаться в течении года при min_uses 2 допустим, тоже > > будет закэшировано, а мне может надо, чтоб оно кэшировалось только если > > есть 5 обращений за 5 мин... есть много разных задач для такого > поведения... > > Если исходить из постановки проблемы как "мне может надо", то, > безусловно, nginx умеет не всё. Я лишь пытался объяснить, что > директива proxy_cache_min_uses - как раз для того, чтобы > существующие элементы в кэше хранить дольше, а новые - не класть в > кэш, если к ним обращаются недостаточно часто. И если у вас нет > жёстких требований именно по времени - похожую логику можно > получить, используя существующие механизмы. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Dec 4 16:12:23 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 4 Dec 2019 21:12:23 +0500 Subject: proxy_cache_min_uses time window In-Reply-To: References: <20191129131030.GP12894@mdounin.ru> <20191129142138.GQ12894@mdounin.ru> <20191129145430.GR12894@mdounin.ru> Message-ID: можно поиграться с https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_store и try_files (файл не найден - он скачивается и сохраняется. дальше отдается уже с диска) ( try_files $uri $uri/ @store; location @store { proxy_store ... } ср, 4 дек. 2019 г. в 19:58, Владислав Толмачев : > Может быть натолкнете, как можно реализовать такую схему: хранить в кэше > файлы год, даже без обращения, а заливать их в кэш если есть 2 запроса в > сутки? > > пт, 29 нояб. 2019 г. в 17:54, Maxim Dounin : > >> Hello! >> >> On Fri, Nov 29, 2019 at 05:26:52PM +0300, Владислав Толмачев wrote: >> >> > если я создал элемент и хочу, что бы без обращения он пролежал в кэше >> год, >> > то всё, что будет обращаться в течении года при min_uses 2 допустим, >> тоже >> > будет закэшировано, а мне может надо, чтоб оно кэшировалось только если >> > есть 5 обращений за 5 мин... есть много разных задач для такого >> поведения... >> >> Если исходить из постановки проблемы как "мне может надо", то, >> безусловно, nginx умеет не всё. Я лишь пытался объяснить, что >> директива proxy_cache_min_uses - как раз для того, чтобы >> существующие элементы в кэше хранить дольше, а новые - не класть в >> кэш, если к ним обращаются недостаточно часто. И если у вас нет >> жёстких требований именно по времени - похожую логику можно >> получить, используя существующие механизмы. >> >> -- >> Maxim Dounin >> http://mdounin.ru/ >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > > С уважением Толмачев Владислав. > tolmachev.vlad на gmail.com > skype: vladislaviki > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From tolmachev.vlad на gmail.com Wed Dec 4 16:15:11 2019 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Wed, 4 Dec 2019 19:15:11 +0300 Subject: proxy_cache_min_uses time window In-Reply-To: References: <20191129131030.GP12894@mdounin.ru> <20191129142138.GQ12894@mdounin.ru> <20191129145430.GR12894@mdounin.ru> Message-ID: В этом случае автоочистки, в случае переполнения диска уже не будет? И удаления наименее редко используемых при добавлении новых тоже не будет? ср, 4 дек. 2019 г. в 19:12, Илья Шипицин : > можно поиграться с > https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_store и > try_files (файл не найден - он скачивается и сохраняется. дальше отдается > уже с диска) > ( > > > try_files $uri $uri/ @store; > > location @store { > proxy_store ... > > } > > > > ср, 4 дек. 2019 г. в 19:58, Владислав Толмачев : > >> Может быть натолкнете, как можно реализовать такую схему: хранить в кэше >> файлы год, даже без обращения, а заливать их в кэш если есть 2 запроса в >> сутки? >> >> пт, 29 нояб. 2019 г. в 17:54, Maxim Dounin : >> >>> Hello! >>> >>> On Fri, Nov 29, 2019 at 05:26:52PM +0300, Владислав Толмачев wrote: >>> >>> > если я создал элемент и хочу, что бы без обращения он пролежал в кэше >>> год, >>> > то всё, что будет обращаться в течении года при min_uses 2 допустим, >>> тоже >>> > будет закэшировано, а мне может надо, чтоб оно кэшировалось только если >>> > есть 5 обращений за 5 мин... есть много разных задач для такого >>> поведения... >>> >>> Если исходить из постановки проблемы как "мне может надо", то, >>> безусловно, nginx умеет не всё. Я лишь пытался объяснить, что >>> директива proxy_cache_min_uses - как раз для того, чтобы >>> существующие элементы в кэше хранить дольше, а новые - не класть в >>> кэш, если к ним обращаются недостаточно часто. И если у вас нет >>> жёстких требований именно по времени - похожую логику можно >>> получить, используя существующие механизмы. >>> >>> -- >>> Maxim Dounin >>> http://mdounin.ru/ >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> -- >> >> С уважением Толмачев Владислав. >> tolmachev.vlad на gmail.com >> skype: vladislaviki >> _______________________________________________ >> 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 -- С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Dec 4 16:37:05 2019 From: nginx-forum на forum.nginx.org (Klark) Date: Wed, 04 Dec 2019 11:37:05 -0500 Subject: =?UTF-8?B?UmU6IFByb3h5IGNhY2hlINGBINC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg?= =?UTF-8?B?U2xpY2Ug0LTQu9GPIE1QNCDQvNC10LTQu9C10L3QvdC+INC+0YLQtNCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LvQuNC10L3RgtGD?= In-Reply-To: <96e5c647594775c104c9d8e60ef1c7f1@kopeyko.ru> References: <96e5c647594775c104c9d8e60ef1c7f1@kopeyko.ru> Message-ID: <0cc1e5405bd4601ba3a72bfbd051d72e.NginxMailingListRussian@forum.nginx.org> Почему-то upstream time везде возращают значение uct="-" urt="-"' Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286396,286404#msg-286404 From andrey на kopeyko.ru Wed Dec 4 19:30:06 2019 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 04 Dec 2019 22:30:06 +0300 Subject: =?UTF-8?B?UmU6IFByb3h5IGNhY2hlINGBINC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg?= =?UTF-8?B?U2xpY2Ug0LTQu9GPIE1QNCDQvNC10LTQu9C10L3QvdC+INC+0YLQtNCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LvQuNC10L3RgtGD?= In-Reply-To: <0cc1e5405bd4601ba3a72bfbd051d72e.NginxMailingListRussian@forum.nginx.org> References: <96e5c647594775c104c9d8e60ef1c7f1@kopeyko.ru> <0cc1e5405bd4601ba3a72bfbd051d72e.NginxMailingListRussian@forum.nginx.org> Message-ID: <2c58749bc36a3f02ee29609f57c5c180@kopeyko.ru> Klark писал 2019-12-04 19:37: > Почему-то upstream time везде возращают значение > uct="-" > urt="-" Это значит, что хождения к апстриму не было. Для этих строк смотрите значения ' rt=$request_time ucs="$upstream_cache_status"' -- Best regards, Andrey A. Kopeyko From chipitsine на gmail.com Wed Dec 4 19:40:28 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 5 Dec 2019 00:40:28 +0500 Subject: proxy_cache_min_uses time window In-Reply-To: References: <20191129131030.GP12894@mdounin.ru> <20191129142138.GQ12894@mdounin.ru> <20191129145430.GR12894@mdounin.ru> Message-ID: Не подскажу на этот счёт, к сожалению On Wed, Dec 4, 2019, 9:15 PM Владислав Толмачев wrote: > В этом случае автоочистки, в случае переполнения диска уже не будет? И > удаления наименее редко используемых при добавлении новых тоже не будет? > > ср, 4 дек. 2019 г. в 19:12, Илья Шипицин : > >> можно поиграться с >> https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_store и >> try_files (файл не найден - он скачивается и сохраняется. дальше отдается >> уже с диска) >> ( >> >> >> try_files $uri $uri/ @store; >> >> location @store { >> proxy_store ... >> >> } >> >> >> >> ср, 4 дек. 2019 г. в 19:58, Владислав Толмачев > >: >> >>> Может быть натолкнете, как можно реализовать такую схему: хранить в кэше >>> файлы год, даже без обращения, а заливать их в кэш если есть 2 запроса в >>> сутки? >>> >>> пт, 29 нояб. 2019 г. в 17:54, Maxim Dounin : >>> >>>> Hello! >>>> >>>> On Fri, Nov 29, 2019 at 05:26:52PM +0300, Владислав Толмачев wrote: >>>> >>>> > если я создал элемент и хочу, что бы без обращения он пролежал в >>>> кэше год, >>>> > то всё, что будет обращаться в течении года при min_uses 2 допустим, >>>> тоже >>>> > будет закэшировано, а мне может надо, чтоб оно кэшировалось только >>>> если >>>> > есть 5 обращений за 5 мин... есть много разных задач для такого >>>> поведения... >>>> >>>> Если исходить из постановки проблемы как "мне может надо", то, >>>> безусловно, nginx умеет не всё. Я лишь пытался объяснить, что >>>> директива proxy_cache_min_uses - как раз для того, чтобы >>>> существующие элементы в кэше хранить дольше, а новые - не класть в >>>> кэш, если к ним обращаются недостаточно часто. И если у вас нет >>>> жёстких требований именно по времени - похожую логику можно >>>> получить, используя существующие механизмы. >>>> >>>> -- >>>> Maxim Dounin >>>> http://mdounin.ru/ >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru на nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >>> -- >>> >>> С уважением Толмачев Владислав. >>> tolmachev.vlad на gmail.com >>> skype: vladislaviki >>> _______________________________________________ >>> 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 > > -- > > С уважением Толмачев Владислав. > tolmachev.vlad на gmail.com > skype: vladislaviki > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Dec 4 20:07:57 2019 From: nginx-forum на forum.nginx.org (Klark) Date: Wed, 04 Dec 2019 15:07:57 -0500 Subject: =?UTF-8?B?UmU6IFByb3h5IGNhY2hlINGBINC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg?= =?UTF-8?B?U2xpY2Ug0LTQu9GPIE1QNCDQvNC10LTQu9C10L3QvdC+INC+0YLQtNCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LvQuNC10L3RgtGD?= In-Reply-To: <2c58749bc36a3f02ee29609f57c5c180@kopeyko.ru> References: <2c58749bc36a3f02ee29609f57c5c180@kopeyko.ru> Message-ID: <6ea529bc9262d5ca1d29276efcb2064e.NginxMailingListRussian@forum.nginx.org> Так в том и странность что вообще как будто нигде не было хождения к апстриму, все записи с cache_status HIT если я правильно все понимаю то он почему-то пишет что абсолютно все файлы берутся из кеша хотя этого быть не может , для теста залили на файл сервер видео которые начал запрашивать с кеш сервера и в тоге тоже самое везде "-" а ucs = "HIT" По rt в среднем 0.02 хотя переодически появляются 30.0 и выше а ucs везде HIT абсолютно везде. Хотя быть не может чтобы все было взято из кеша , объем кеш сервера в 3 раза меньше чем файловый сервер. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286396,286410#msg-286410 From nginx-forum на forum.nginx.org Thu Dec 5 01:36:09 2019 From: nginx-forum на forum.nginx.org (Klark) Date: Wed, 04 Dec 2019 20:36:09 -0500 Subject: =?UTF-8?B?UmU6IFByb3h5IGNhY2hlINGBINC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg?= =?UTF-8?B?U2xpY2Ug0LTQu9GPIE1QNCDQvNC10LTQu9C10L3QvdC+INC+0YLQtNCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LvQuNC10L3RgtGD?= In-Reply-To: <96e5c647594775c104c9d8e60ef1c7f1@kopeyko.ru> References: <96e5c647594775c104c9d8e60ef1c7f1@kopeyko.ru> Message-ID: В общем все же разобрался. Действительно многое было в кеше но суть не в этом. Медленная отдача файлов с кеш сервера конечному клиенту была из-за указания ssl_protocols брал их из настроек сайта видимо шифрование медленно проходило или что-то вроде этого. Оставил просто ssl on; и пути до сертификатов теперь отдача работает значительно быстрее. Большое спасибо за направление в сторону логов. конфиг кеширования оставлю тут вдруг кому понадобится location = /video/ { access_log /var/log/nginx/timed.log timed; mp4; mp4_buffer_size 1M; mp4_max_buffer_size 15M; aio threads=default; aio_write on; proxy_http_version 1.1; proxy_set_header Connection ""; slice 1m; proxy_set_header Range $slice_range; proxy_cache_valid 200 206 24h; proxy_cache ssd_cache; proxy_cache_key $uri$slice_range; proxy_pass http://backend; proxy_cache_lock on; proxy_cache_lock_age 50s; proxy_cache_lock_timeout 0s; proxy_cache_use_stale updating; } Еще раз большое спасибо за правильное направление в сторону логов помогло при поиске проблем. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286396,286411#msg-286411 From mdounin на mdounin.ru Thu Dec 5 14:14:01 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 5 Dec 2019 17:14:01 +0300 Subject: =?UTF-8?B?UmU6IFByb3h5IGNhY2hlINGBINC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC10Lwg?= =?UTF-8?B?U2xpY2Ug0LTQu9GPIE1QNCDQvNC10LTQu9C10L3QvdC+INC+0YLQtNCw0LU=?= =?UTF-8?B?0YLRgdGPINC60LvQuNC10L3RgtGD?= In-Reply-To: <2c58749bc36a3f02ee29609f57c5c180@kopeyko.ru> References: <96e5c647594775c104c9d8e60ef1c7f1@kopeyko.ru> <0cc1e5405bd4601ba3a72bfbd051d72e.NginxMailingListRussian@forum.nginx.org> <2c58749bc36a3f02ee29609f57c5c180@kopeyko.ru> Message-ID: <20191205141401.GB12894@mdounin.ru> Hello! On Wed, Dec 04, 2019 at 10:30:06PM +0300, Andrey Kopeyko wrote: > Klark писал 2019-12-04 19:37: > > Почему-то upstream time везде возращают значение > > uct="-" > > urt="-" > > Это значит, что хождения к апстриму не было. Так как речь про slice - это значит, что хождения к апстриму не было в основном запросе. Что происходило в других подзапросах - можно узнать, только включив логгирование подзапросов (http://nginx.org/r/log_subrequest/ru). -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Dec 13 11:05:25 2019 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Fri, 13 Dec 2019 06:05:25 -0500 Subject: request: "CONNECT hostname:443 HTTP/1.1" Message-ID: В error логе стало появляться какое-то количество вот таких как в заголовке сообщений (вместо hostname реальное имя домена). Не могу понять что это. При чем есть предположение, что когда их набирается какое-то количество nginx перестает нормально работать. Как-то можно это отловить? Пробовал через if ( $request_method но что-то толи я не пойму как оно работает, толи это нужно делать на уровне http, а не server но там if не приемлем. Есть какой-то положительный опыт? Ну или ткните носом куда почитать... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286467,286467#msg-286467 From chipitsine на gmail.com Fri Dec 13 11:29:16 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 13 Dec 2019 16:29:16 +0500 Subject: request: "CONNECT hostname:443 HTTP/1.1" In-Reply-To: References: Message-ID: есть вероятность, что это активность по сканированию на уязвимости. у вас есть дефолт сервер (куда направляется трафик с неуказанных явно доменов) ? уязвимости часто сканируют не зная ваших доменов, просто по диапазону IP адресов (почему от этого вы ломаетесь - вопрос хороший. по идее это просто шум в логах должен быть) server { listen N.N.N.N:80 fastopen=256 default_server; server_name _; return 402; access_log off; error_log /dev/null; } пт, 13 дек. 2019 г. в 16:05, Dmytro Lavryk : > В error логе стало появляться какое-то количество вот таких как в заголовке > сообщений (вместо hostname реальное имя домена). Не могу понять что это. > При > чем есть предположение, что когда их набирается какое-то количество nginx > перестает нормально работать. Как-то можно это отловить? > Пробовал через if ( $request_method но что-то толи я не пойму как оно > работает, толи это нужно делать на уровне http, а не server но там if не > приемлем. > Есть какой-то положительный опыт? Ну или ткните носом куда почитать... > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,286467,286467#msg-286467 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From tolmachev.vlad на gmail.com Sun Dec 15 23:03:42 2019 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Mon, 16 Dec 2019 02:03:42 +0300 Subject: CPU IRQ 100% Message-ID: Добрый вечер, вопрос такой, сервер 10 гигабит, раздает мелкие статические файлы, настройки такие: user www-data www-data; worker_processes 50; (CPU 32 ядра) worker_cpu_affinity auto; timer_resolution 500ms; worker_rlimit_nofile 65535; worker_priority 5; pcre_jit on; когда час пик и сервер выдает полку 10gbps, после часов 2-3 полки - один из CPU (виртуальный, например CPU7) начинает грузиться IRQ на 100% (интераптов сетевой карты или райд массива или дисков именно на этом CPU7 нет) Лечится только полным останавливаем nginx и запуском его с начала, рестарт nginx не помогает, в чем может быть проблема? по cat /proc/interrupts на этом CPU7 вообще все счетчики по нулям. Только в atop видно, что CPU7 забит IRQ ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Mon Dec 16 17:27:17 2019 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 17 Dec 2019 00:27:17 +0700 Subject: =?UTF-8?B?W1VuaXRdINC90LDRgdGC0YDQvtC50LrQsCDRhNC+0YDQvNCw0YLQsCBhY2Nlc3Nf?= =?UTF-8?B?bG9nJ9Cw?= Message-ID: <1919243.NrgyT7ajSg@note> Дорогие разработчики, подскажите, пожалуйста, а возможно ли изменение формата access_log'а в Юните (на манер того, как это реализовано в самом NgX)? Особенно волнуют именно переменные-плейсхолдеры (например, возможность добавить какой-либо HTTP-заголовок из переданных клиентом. Например, это ОООООООООЧЕНЬ актуально для случаев когда Unit стоит за NginX'ом (соответственно, клиентские IP превращаются в тыкву). Ещё больше актуальность возрастает когда оба они в докере (и нет возможности на стороне NgX вести по-хостовые логи). // а общий сетевой сислог для сбора логов пока что не хочется использовать :'( From vbart на nginx.com Mon Dec 16 17:33:25 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 16 Dec 2019 20:33:25 +0300 Subject: =?UTF-8?B?UmU6IFtVbml0XSDQvdCw0YHRgtGA0L7QudC60LAg0YTQvtGA0LzQsNGC0LAgYWNj?= =?UTF-8?B?ZXNzX2xvZyfQsA==?= In-Reply-To: <1919243.NrgyT7ajSg@note> References: <1919243.NrgyT7ajSg@note> Message-ID: <3460684.k7IVcTxSo0@vbart-workstation> On Tuesday 17 December 2019 00:27:17 Vadim A. Misbakh-Soloviov wrote: > Дорогие разработчики, подскажите, пожалуйста, а возможно ли изменение формата > access_log'а в Юните (на манер того, как это реализовано в самом NgX)? > > Особенно волнуют именно переменные-плейсхолдеры (например, возможность > добавить какой-либо HTTP-заголовок из переданных клиентом. > > Например, это ОООООООООЧЕНЬ актуально для случаев когда Unit стоит за NginX'ом > (соответственно, клиентские IP превращаются в тыкву). > Ещё больше актуальность возрастает когда оба они в докере (и нет возможности > на стороне NgX вести по-хостовые логи). > > // а общий сетевой сислог для сбора логов пока что не хочется использовать :'( [..] Сейчас нельзя. Для этого нужно сначало напрограммировать переменные, а их пока что в Unit-е ещё нет. -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed Dec 18 08:55:38 2019 From: nginx-forum на forum.nginx.org (yanda.a) Date: Wed, 18 Dec 2019 03:55:38 -0500 Subject: =?UTF-8?B?0J/QtdGA0LXQvNC10L3QvdCw0Y8gJHByb3h5IGhvc3Qg0Lgg0LLQvdGD0YLRgNC1?= =?UTF-8?B?0L3QvdC40Lkg0YDQtdC00LjRgNC10LrRgg==?= Message-ID: Доброго времени суток! Есть небольшой вопрос по переменной $proxy_host. У нас местами используется error_page для 50х ошибок и X-Accel-Redirect. В случаях, если было выполнение внутреннее перенаправление, переменная $proxy_host оказывается пустой. При этом, на 100% известно что запрос проксировался на бекенд. Подскажите, кто знает, это нормальное поведение nginx? И есть ли способ это исправить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286491,286491#msg-286491 From mdounin на mdounin.ru Wed Dec 18 14:54:13 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 18 Dec 2019 17:54:13 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRwcm94eSBob3N0INC4INCy0L3Rg9GC?= =?UTF-8?B?0YDQtdC90L3QuNC5INGA0LXQtNC40YDQtdC60YI=?= In-Reply-To: References: Message-ID: <20191218145413.GU12894@mdounin.ru> Hello! On Wed, Dec 18, 2019 at 03:55:38AM -0500, yanda.a wrote: > Доброго времени суток! > > Есть небольшой вопрос по переменной $proxy_host. У нас местами используется > error_page для 50х ошибок и X-Accel-Redirect. В случаях, если было > выполнение внутреннее перенаправление, переменная $proxy_host оказывается > пустой. При этом, на 100% известно что запрос проксировался на бекенд. > > Подскажите, кто знает, это нормальное поведение nginx? И есть ли способ это > исправить? Да. Переменная $proxy_host указывает на имя проксируемого сервера в собственно момент проксирования (и предназначена в первую очередь для внутреннего использования - в заголовках по умолчанию), после внутренних перенаправлений она становится недоступна. Если хочется знать, куда nginx ходил в других location'ах до внутренних перенаправлений - стоит посмотреть в сторону переменной $upstream_addr. -- Maxim Dounin http://mdounin.ru/ From yanda.a на office.ekance.com Wed Dec 18 15:38:44 2019 From: yanda.a на office.ekance.com (=?UTF-8?B?0K/QvdC00LAg0JDQvdC00YDQtdC5?=) Date: Wed, 18 Dec 2019 18:38:44 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3QsNGPICRwcm94eSBob3N0INC4INCy0L3Rg9GC?= =?UTF-8?B?0YDQtdC90L3QuNC5INGA0LXQtNC40YDQtdC60YI=?= In-Reply-To: <20191218145413.GU12894@mdounin.ru> References: <20191218145413.GU12894@mdounin.ru> Message-ID: 18.12.2019 17:54, Maxim Dounin пишет: > Hello! > > On Wed, Dec 18, 2019 at 03:55:38AM -0500, yanda.a wrote: > >> Доброго времени суток! >> >> Есть небольшой вопрос по переменной $proxy_host. У нас местами используется >> error_page для 50х ошибок и X-Accel-Redirect. В случаях, если было >> выполнение внутреннее перенаправление, переменная $proxy_host оказывается >> пустой. При этом, на 100% известно что запрос проксировался на бекенд. >> >> Подскажите, кто знает, это нормальное поведение nginx? И есть ли способ это >> исправить? > Да. Переменная $proxy_host указывает на имя проксируемого сервера > в собственно момент проксирования (и предназначена в первую > очередь для внутреннего использования - в заголовках по > умолчанию), после внутренних перенаправлений она становится > недоступна. > > Если хочется знать, куда nginx ходил в других location'ах до > внутренних перенаправлений - стоит посмотреть в сторону переменной > $upstream_addr. > Спасибо большое за ответ! Я немного для других целей хотел использовать эту переменную. У меня достаточно много виртуальных хостов, и для каждого свой апстрим. В каждом виртуальном сервере может быть много различных доменов, поэтому удобнее агрегировать статистику как раз по $proxy_host, а не по доменам. Ладно, значит придется что-то колхозить. Спасибо большое еще раз! -- С уважением, Янда Андрей, системный администратор тел.: +7-863-280-01-01 (доб. 6004) From nginx-forum на forum.nginx.org Thu Dec 19 10:14:17 2019 From: nginx-forum на forum.nginx.org (kurov.sergei) Date: Thu, 19 Dec 2019 05:14:17 -0500 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDQv9GA0Lgg0YHQsdC+0YDQutC1INGBINC80L7QtNGD?= =?UTF-8?B?0LvQtdC8IG5neCBodHRwIHVwc3RyZWFtIG1vZHVsZQ==?= Message-ID: Добрый день. Пытаюсь собрать nginx c модулем ngx_http_upstream_module добавил репозиторий, как описано в инструкции http://nginx.org/en/linux_packages.html#RHEL-CentOS Пробовал на CentOS6 и CentOS7 Переустановил nginx, становиться версия 1.17.6, после исполняю ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' --with-ngx_http_upstream_module В итоге получаю ./configure: error: invalid option "--with-ngx_http_upstream_module" Пожалуйста помогите. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286510,286510#msg-286510 From red-fox0 на ya.ru Thu Dec 19 10:20:50 2019 From: red-fox0 на ya.ru (fox) Date: Thu, 19 Dec 2019 17:20:50 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0L/RgNC4INGB0LHQvtGA0LrQtSDRgSDQvNC+?= =?UTF-8?B?0LTRg9C70LXQvCBuZ3ggaHR0cCB1cHN0cmVhbSBtb2R1bGU=?= In-Reply-To: References: Message-ID: Попробуй --with-http_upstream_module 19.12.2019 17:14, kurov.sergei пишет: > Добрый день. Пытаюсь собрать nginx c модулем ngx_http_upstream_module > добавил репозиторий, как описано в инструкции > http://nginx.org/en/linux_packages.html#RHEL-CentOS > Пробовал на CentOS6 и CentOS7 > Переустановил nginx, становиться версия 1.17.6, после исполняю > ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid > --lock-path=/var/run/nginx.lock > --http-client-body-temp-path=/var/cache/nginx/client_temp > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx > --with-compat --with-file-aio --with-threads --with-http_addition_module > --with-http_auth_request_module --with-http_dav_module > --with-http_flv_module --with-http_gunzip_module > --with-http_gzip_static_module --with-http_mp4_module > --with-http_random_index_module --with-http_realip_module > --with-http_secure_link_module --with-http_slice_module > --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module > --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream > --with-stream_realip_module --with-stream_ssl_module > --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC' > --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' > --with-ngx_http_upstream_module > В итоге получаю > ./configure: error: invalid option "--with-ngx_http_upstream_module" > Пожалуйста помогите. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286510,286510#msg-286510 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From kpoxa на kpoxa.net Thu Dec 19 12:02:09 2019 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 19 Dec 2019 15:02:09 +0300 Subject: stream server by sni Message-ID: Добрый день. А есть возможность повесить на 1 ip:port 2 и более серверов тима stream с выбором сервера по sni ? -- Рустам -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Thu Dec 19 12:45:09 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 19 Dec 2019 17:45:09 +0500 Subject: stream server by sni In-Reply-To: References: Message-ID: на ssl_preread можно попробовать https://nginx.org/ru/docs/stream/ngx_stream_ssl_preread_module.html чт, 19 дек. 2019 г. в 17:02, kpoxa : > Добрый день. > > А есть возможность повесить на 1 ip:port 2 и более серверов тима stream с > выбором сервера по sni ? > > -- > Рустам > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Dec 19 12:52:26 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 19 Dec 2019 15:52:26 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0L/RgNC4INGB0LHQvtGA0LrQtSDRgSDQvNC+?= =?UTF-8?B?0LTRg9C70LXQvCBuZ3ggaHR0cCB1cHN0cmVhbSBtb2R1bGU=?= In-Reply-To: References: Message-ID: <20191219125226.GA12894@mdounin.ru> Hello! On Thu, Dec 19, 2019 at 05:14:17AM -0500, kurov.sergei wrote: > Добрый день. Пытаюсь собрать nginx c модулем ngx_http_upstream_module > добавил репозиторий, как описано в инструкции > http://nginx.org/en/linux_packages.html#RHEL-CentOS > Пробовал на CentOS6 и CentOS7 > Переустановил nginx, становиться версия 1.17.6, после исполняю > ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid > --lock-path=/var/run/nginx.lock > --http-client-body-temp-path=/var/cache/nginx/client_temp > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx > --with-compat --with-file-aio --with-threads --with-http_addition_module > --with-http_auth_request_module --with-http_dav_module > --with-http_flv_module --with-http_gunzip_module > --with-http_gzip_static_module --with-http_mp4_module > --with-http_random_index_module --with-http_realip_module > --with-http_secure_link_module --with-http_slice_module > --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module > --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream > --with-stream_realip_module --with-stream_ssl_module > --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC' > --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' > --with-ngx_http_upstream_module > В итоге получаю > ./configure: error: invalid option "--with-ngx_http_upstream_module" > Пожалуйста помогите. Уберите эту опцию, её не существует. Модуль upstream собирается всегда, и каких-либо специальных опций для его сборки - не требуется. И, кстати, список всех доступных опций можно посмотреть, запустив configure с ключём --help. -- Maxim Dounin http://mdounin.ru/ From kpoxa на kpoxa.net Fri Dec 20 08:50:48 2019 From: kpoxa на kpoxa.net (kpoxa) Date: Fri, 20 Dec 2019 11:50:48 +0300 Subject: stream server by sni In-Reply-To: References: Message-ID: Тут всё хорошо, кроме того, что не будет разных серверов с разными ssl сертификатами, как могло бы быть. чт, 19 дек. 2019 г. в 15:45, Илья Шипицин : > на ssl_preread можно попробовать > > https://nginx.org/ru/docs/stream/ngx_stream_ssl_preread_module.html > > чт, 19 дек. 2019 г. в 17:02, kpoxa : > >> Добрый день. >> >> А есть возможность повесить на 1 ip:port 2 и более серверов тима stream с >> выбором сервера по sni ? >> >> -- >> Рустам >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Fri Dec 20 08:54:48 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 20 Dec 2019 13:54:48 +0500 Subject: stream server by sni In-Reply-To: References: Message-ID: странная идея (ни разу не пробовал такое для стримов) а если впихать все серты в один сервер ? пт, 20 дек. 2019 г. в 13:51, kpoxa : > Тут всё хорошо, кроме того, что не будет разных серверов с разными ssl > сертификатами, как могло бы быть. > > чт, 19 дек. 2019 г. в 15:45, Илья Шипицин : > >> на ssl_preread можно попробовать >> >> https://nginx.org/ru/docs/stream/ngx_stream_ssl_preread_module.html >> >> чт, 19 дек. 2019 г. в 17:02, kpoxa : >> >>> Добрый день. >>> >>> А есть возможность повесить на 1 ip:port 2 и более серверов тима stream >>> с выбором сервера по sni ? >>> >>> -- >>> Рустам >>> >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Dec 24 15:14:25 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 24 Dec 2019 18:14:25 +0300 Subject: nginx-1.17.7 Message-ID: <20191224151425.GX12894@mdounin.ru> Изменения в nginx 1.17.7 24.12.2019 *) Исправление: на старте или во время переконфигурации мог произойти segmentation fault, если в конфигурации использовалась директива rewrite с пустой строкой замены. *) Исправление: в рабочем процессе мог произойти segmentation fault, если директива break использовалась совместно с директивой alias или директивой proxy_pass с URI. *) Исправление: строка Location заголовка ответа могла содержать мусор, если URI запроса был изменён на URI, содержащий нулевой символ. *) Исправление: при возврате перенаправлений с помощью директивы error_page запросы с телом обрабатывались некорректно; ошибка появилась в 0.7.12. *) Исправление: утечки сокетов при использовании HTTP/2. *) Исправление: при обработке pipelined-запросов по SSL-соединению мог произойти таймаут; ошибка появилась в 1.17.5. *) Исправление: в модуле ngx_http_dav_module. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Tue Dec 24 20:35:20 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 25 Dec 2019 01:35:20 +0500 Subject: =?UTF-8?B?0L/QvtCy0YLQvtGA0L3QsNGPINC+0YLQv9GA0LDQstC60LAgUE9TVCDQt9Cw0L8=?= =?UTF-8?B?0YDQvtGB0L7QsiA/?= Message-ID: привет! допустим, такая ситуация. есть POST запрос, у него есть хедеры и, собственно, тело запроса. мы отправили хедеры на бекенд, тело не успели отправить, и бекенд нам сделал TCP RST. должен ли такой POST повторно отправляться, если не указан non_idempotent ? (судя по моим экспериментам - не отправляется. но ведь тело не было отправлено ? значит мы должны попасть под условие, что такой запрос можно отправить повторно ?) Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Wed Dec 25 09:38:39 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 25 Dec 2019 12:38:39 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QstGC0L7RgNC90LDRjyDQvtGC0L/RgNCw0LLQutCwIFBPU1Qg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LIgPw==?= In-Reply-To: References: Message-ID: > On 24 Dec 2019, at 23:35, Илья Шипицин wrote: > > привет! > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и, собственно, тело запроса. мы отправили хедеры на бекенд, тело не успели отправить, и бекенд нам сделал TCP RST. > > должен ли такой POST повторно отправляться, если не указан non_idempotent ? (судя по моим экспериментам - не отправляется. но ведь тело не было отправлено ? значит мы должны попасть под условие, что такой запрос можно отправить повторно ?) Как только мы успешно установили соединение и перешли к отправке запроса (не важно, успели начать отправку тела или нет), запрос считается отправленным, т.к. в общем случае мы не знаем, был ли он обработан или нет. -- Sergey Kandaurov From chipitsine на gmail.com Wed Dec 25 09:58:15 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 25 Dec 2019 14:58:15 +0500 Subject: =?UTF-8?B?UmU6INC/0L7QstGC0L7RgNC90LDRjyDQvtGC0L/RgNCw0LLQutCwIFBPU1Qg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LIgPw==?= In-Reply-To: References: Message-ID: ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov : > > > On 24 Dec 2019, at 23:35, Илья Шипицин wrote: > > > > привет! > > > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и, > собственно, тело запроса. мы отправили хедеры на бекенд, тело не успели > отправить, и бекенд нам сделал TCP RST. > > > > должен ли такой POST повторно отправляться, если не указан > non_idempotent ? (судя по моим экспериментам - не отправляется. но ведь > тело не было отправлено ? значит мы должны попасть под условие, что такой > запрос можно отправить повторно ?) > > Как только мы успешно установили соединение и перешли к отправке запроса > (не важно, успели начать отправку тела или нет), запрос считается > отправленным, > т.к. в общем случае мы не знаем, был ли он обработан или нет. > я предлагаю такую логику. бекенд умеет отличать полностью полученный запрос от неполного запроса (например, по Content-Length) навряд ли бекенд будет обрабатывать неполностью полученный запрос и считать отправленными только полностью отправленные запросы > > -- > Sergey Kandaurov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Dec 25 11:01:28 2019 From: nginx-forum на forum.nginx.org (grey) Date: Wed, 25 Dec 2019 06:01:28 -0500 Subject: =?UTF-8?B?0JfQsNC00LDRgtGMIGV4cGlyZXMg0LTQu9GPINC60L7QvdC60YDQtdGC0L3QvtCz?= =?UTF-8?B?0L4g0YTQsNC50LvQsA==?= Message-ID: <4790c20bb237eb86d1059130257c92f1.NginxMailingListRussian@forum.nginx.org> Приветствую. Конфиг: map $request_uri $expires { default off; ~^/images/ 10d; /images/test.jpg 1h; } Все файлы из папки images кэшируется на 10 дней, а для одной картинке хочу установить время кэша на 1 час. Не получатся... Что я делаю не так? И сразу еще вопрос: имеет ли значение порядок строк в этом примере? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286582,286582#msg-286582 From raven_kg на megaline.kg Wed Dec 25 11:04:00 2019 From: raven_kg на megaline.kg (Andrey Korolkov) Date: Wed, 25 Dec 2019 17:04:00 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQtNCw0YLRjCBleHBpcmVzINC00LvRjyDQutC+0L3QutGA0LXRgtC9?= =?UTF-8?B?0L7Qs9C+INGE0LDQudC70LA=?= In-Reply-To: <4790c20bb237eb86d1059130257c92f1.NginxMailingListRussian@forum.nginx.org> References: <4790c20bb237eb86d1059130257c92f1.NginxMailingListRussian@forum.nginx.org> Message-ID: Строки в map местами поменять? On дек. 25 2019, at 5:01 вечера, grey wrote: > Приветствую. > > Конфиг: > map $request_uri $expires { > default off; > ~^/images/ 10d; > /images/test.jpg 1h; > } > > Все файлы из папки images кэшируется на 10 дней, а для одной картинке хочу > установить время кэша на 1 час. > > Не получатся... Что я делаю не так? > И сразу еще вопрос: имеет ли значение порядок строк в этом примере? > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286582,286582#msg-286582 > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Dec 25 11:20:28 2019 From: nginx-forum на forum.nginx.org (grey) Date: Wed, 25 Dec 2019 06:20:28 -0500 Subject: =?UTF-8?B?UmU6INCX0LDQtNCw0YLRjCBleHBpcmVzINC00LvRjyDQutC+0L3QutGA0LXRgtC9?= =?UTF-8?B?0L7Qs9C+INGE0LDQudC70LA=?= In-Reply-To: References: Message-ID: <60ac1b6593b2ee75c9624c48fdd06a8a.NginxMailingListRussian@forum.nginx.org> Конечно пробовал. Не помогло. Потому еще и спрашиваю про порядок - имеет ли он значение или нет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286582,286585#msg-286585 From chipitsine на gmail.com Wed Dec 25 11:43:43 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 25 Dec 2019 16:43:43 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQtNCw0YLRjCBleHBpcmVzINC00LvRjyDQutC+0L3QutGA0LXRgtC9?= =?UTF-8?B?0L7Qs9C+INGE0LDQudC70LA=?= In-Reply-To: <60ac1b6593b2ee75c9624c48fdd06a8a.NginxMailingListRussian@forum.nginx.org> References: <60ac1b6593b2ee75c9624c48fdd06a8a.NginxMailingListRussian@forum.nginx.org> Message-ID: https://nginx.org/ru/docs/http/ngx_http_map_module.html#map Если исходному значению соответствует несколько из указанных вариантов, например, одновременно подходят и маска, и регулярное выражение, будет выбран первый подходящий вариант в следующем порядке приоритета: 1. строковое значение без маски 2. самое длинное строковое значение с маской в начале, например “*. example.com” 3. самое длинное строковое значение с маской в конце, например “mail.*” 4. первое подходящее регулярное выражение (в порядке следования в конфигурационном файле) 5. значение по умолчанию (default) ср, 25 дек. 2019 г. в 16:20, grey : > Конечно пробовал. Не помогло. Потому еще и спрашиваю про порядок - имеет ли > он значение или нет. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,286582,286585#msg-286585 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Dec 25 18:20:05 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 25 Dec 2019 21:20:05 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QstGC0L7RgNC90LDRjyDQvtGC0L/RgNCw0LLQutCwIFBPU1Qg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LIgPw==?= In-Reply-To: References: Message-ID: <20191225182005.GH12894@mdounin.ru> Hello! On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote: > ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov : > > > > > > On 24 Dec 2019, at 23:35, Илья Шипицин wrote: > > > > > > привет! > > > > > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и, > > собственно, тело запроса. мы отправили хедеры на бекенд, тело не успели > > отправить, и бекенд нам сделал TCP RST. > > > > > > должен ли такой POST повторно отправляться, если не указан > > non_idempotent ? (судя по моим экспериментам - не отправляется. но ведь > > тело не было отправлено ? значит мы должны попасть под условие, что такой > > запрос можно отправить повторно ?) > > > > Как только мы успешно установили соединение и перешли к отправке запроса > > (не важно, успели начать отправку тела или нет), запрос считается > > отправленным, > > т.к. в общем случае мы не знаем, был ли он обработан или нет. > > > > я предлагаю такую логику. > бекенд умеет отличать полностью полученный запрос от неполного запроса > (например, по Content-Length) > навряд ли бекенд будет обрабатывать неполностью полученный запрос > > и считать отправленными только полностью отправленные запросы Считать-то можно, но у бекенда может быть своё мнение по этому вопросу. Каких-либо явных утверждений в RFC 2616 / RFC 7231, которые бы говорили о том, что так можно - я в своё время не нашёл. И по факту так скорее всего нельзя, так как на тело бекенду во многих случаях может быть наплевать. Если хочется это место оптимизировать - проще всего это делать, явно указав, что повторно отправлять неидемпотентные запросы можно, и озаботившись защитой от дублирующихся запросов на уровне приложения. Тем более, что в общем случае это в любом случае нужно делать, ибо защищаться от нажатия пользователем кнопки "отправить" по второму разу и/или кнопки refresh - тоже надо. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Wed Dec 25 19:32:04 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 26 Dec 2019 00:32:04 +0500 Subject: =?UTF-8?B?UmU6INC/0L7QstGC0L7RgNC90LDRjyDQvtGC0L/RgNCw0LLQutCwIFBPU1Qg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LIgPw==?= In-Reply-To: <20191225182005.GH12894@mdounin.ru> References: <20191225182005.GH12894@mdounin.ru> Message-ID: ср, 25 дек. 2019 г. в 23:20, Maxim Dounin : > Hello! > > On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote: > > > ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov : > > > > > > > > > On 24 Dec 2019, at 23:35, Илья Шипицин wrote: > > > > > > > > привет! > > > > > > > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и, > > > собственно, тело запроса. мы отправили хедеры на бекенд, тело не успели > > > отправить, и бекенд нам сделал TCP RST. > > > > > > > > должен ли такой POST повторно отправляться, если не указан > > > non_idempotent ? (судя по моим экспериментам - не отправляется. но ведь > > > тело не было отправлено ? значит мы должны попасть под условие, что > такой > > > запрос можно отправить повторно ?) > > > > > > Как только мы успешно установили соединение и перешли к отправке > запроса > > > (не важно, успели начать отправку тела или нет), запрос считается > > > отправленным, > > > т.к. в общем случае мы не знаем, был ли он обработан или нет. > > > > > > > я предлагаю такую логику. > > бекенд умеет отличать полностью полученный запрос от неполного запроса > > (например, по Content-Length) > > навряд ли бекенд будет обрабатывать неполностью полученный запрос > > > > и считать отправленными только полностью отправленные запросы > > Считать-то можно, но у бекенда может быть своё мнение по этому > вопросу. Каких-либо явных утверждений в RFC 2616 / RFC 7231, > которые бы говорили о том, что так можно - я в своё время не > нашёл. И по факту так скорее всего нельзя, так как на тело > бекенду во многих случаях может быть наплевать. > есть достаточно странный кейс, когда отправляется POST без тела. не конкретно в наших приложениях, а в принципе. я по некоторым разбирался, зачем так делают (ну то есть, можно же GET, но специально сделали POST). ответ меня поразил - по RFC нельзя кешировать POST. ну и чтобы наверняка без кеша, мы выбрали POST )) ну а тело ... надо не надо было в описанном выше случае, действительно, тело (запроса) не предполагалось. если тело предполагается, но не было отправлено, допустим бекенд вменяемый, что вполне может быть. он запрос не обработал. можно ретраить. каких-то явных противоречий в этом не вижу > > Если хочется это место оптимизировать - проще всего это делать, > явно указав, что повторно отправлять неидемпотентные запросы > ретрай неидемпотентных запросов, это, например, запрос мог полностью уйти, и даже обработаться (но мы не знаем этого, просто не дождались ответа). это не совсем то, чего бы хотелось. > можно, и озаботившись защитой от дублирующихся запросов на уровне > приложения. Тем более, что в общем случае это в любом случае > нужно делать, ибо защищаться от нажатия пользователем кнопки > "отправить" по второму разу и/или кнопки refresh - тоже надо. > да, вы правы. так действительно лучше. но приложения есть приложения, а разработчики есть разработчики. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Dec 25 20:13:18 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 25 Dec 2019 23:13:18 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QstGC0L7RgNC90LDRjyDQvtGC0L/RgNCw0LLQutCwIFBPU1Qg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LIgPw==?= In-Reply-To: References: <20191225182005.GH12894@mdounin.ru> Message-ID: <20191225201318.GJ12894@mdounin.ru> Hello! On Thu, Dec 26, 2019 at 12:32:04AM +0500, Илья Шипицин wrote: > ср, 25 дек. 2019 г. в 23:20, Maxim Dounin : > > > Hello! > > > > On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote: > > > > > ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov : > > > > > > > > > > > > On 24 Dec 2019, at 23:35, Илья Шипицин wrote: > > > > > > > > > > привет! > > > > > > > > > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и, > > > > собственно, тело запроса. мы отправили хедеры на бекенд, тело не успели > > > > отправить, и бекенд нам сделал TCP RST. > > > > > > > > > > должен ли такой POST повторно отправляться, если не указан > > > > non_idempotent ? (судя по моим экспериментам - не отправляется. но ведь > > > > тело не было отправлено ? значит мы должны попасть под условие, что > > такой > > > > запрос можно отправить повторно ?) > > > > > > > > Как только мы успешно установили соединение и перешли к отправке > > запроса > > > > (не важно, успели начать отправку тела или нет), запрос считается > > > > отправленным, > > > > т.к. в общем случае мы не знаем, был ли он обработан или нет. > > > > > > > > > > я предлагаю такую логику. > > > бекенд умеет отличать полностью полученный запрос от неполного запроса > > > (например, по Content-Length) > > > навряд ли бекенд будет обрабатывать неполностью полученный запрос > > > > > > и считать отправленными только полностью отправленные запросы > > > > Считать-то можно, но у бекенда может быть своё мнение по этому > > вопросу. Каких-либо явных утверждений в RFC 2616 / RFC 7231, > > которые бы говорили о том, что так можно - я в своё время не > > нашёл. И по факту так скорее всего нельзя, так как на тело > > бекенду во многих случаях может быть наплевать. > > > > есть достаточно странный кейс, когда отправляется POST без тела. не > конкретно в наших приложениях, а в принципе. > я по некоторым разбирался, зачем так делают (ну то есть, можно же GET, но > специально сделали POST). ответ меня поразил - > по RFC нельзя кешировать POST. ну и чтобы наверняка без кеша, мы выбрали > POST )) ну а тело ... надо не надо было > > в описанном выше случае, действительно, тело (запроса) не предполагалось. > > если тело предполагается, но не было отправлено, допустим бекенд вменяемый, > что вполне может быть. он запрос не обработал. > можно ретраить. > > каких-то явных противоречий в этом не вижу Явных противоречий тут и нет: скорее всего бекенд смотрит на тело, и в тех немногих случаях, когда мы точно знаем, что оно отправлено не полностью - скорее всего можно ретраить. Однако проблем тут две: - "Скорее всего можно" - не значит "точно можно", наступить на ситуацию, когда бекенд на тело не смотрит - на практике вполне можно. И каких-либо явных причин требовать от бекенда, чтобы смотрел - я, как я уже писал выше, не вижу, и если у такого бекенда вдруг что-то пойдёт не так - виноват будет nginx. (Если эти причины вдруг есть - с удовольствием ознакомлюсь с соответствующей цитатой из RFC.) - Условие "когда мы точно знаем" не выполняется приблизительно никогда: в подавляющем большинстве случаев тело вместе с запросом уже сложено в буфер сокета, и что там с ним стало дальше - узнать невозможно. То есть мы про микрооптимизацию оцень небольшого процента запросов. Вместе эти две проблемы привели меня в своё время к выводу, что не стоит тут пытаться что-то наоптимизировать, кому надо - сделают правильно с защитой на уровне приложения, кому не надо - получают гарантированно корректное поведение из коробки. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Wed Dec 25 21:05:51 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 26 Dec 2019 02:05:51 +0500 Subject: =?UTF-8?B?UmU6INC/0L7QstGC0L7RgNC90LDRjyDQvtGC0L/RgNCw0LLQutCwIFBPU1Qg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LIgPw==?= In-Reply-To: <20191225201318.GJ12894@mdounin.ru> References: <20191225182005.GH12894@mdounin.ru> <20191225201318.GJ12894@mdounin.ru> Message-ID: чт, 26 дек. 2019 г. в 01:13, Maxim Dounin : > Hello! > > On Thu, Dec 26, 2019 at 12:32:04AM +0500, Илья Шипицин wrote: > > > ср, 25 дек. 2019 г. в 23:20, Maxim Dounin : > > > > > Hello! > > > > > > On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote: > > > > > > > ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov : > > > > > > > > > > > > > > > On 24 Dec 2019, at 23:35, Илья Шипицин > wrote: > > > > > > > > > > > > привет! > > > > > > > > > > > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и, > > > > > собственно, тело запроса. мы отправили хедеры на бекенд, тело не > успели > > > > > отправить, и бекенд нам сделал TCP RST. > > > > > > > > > > > > должен ли такой POST повторно отправляться, если не указан > > > > > non_idempotent ? (судя по моим экспериментам - не отправляется. но > ведь > > > > > тело не было отправлено ? значит мы должны попасть под условие, что > > > такой > > > > > запрос можно отправить повторно ?) > > > > > > > > > > Как только мы успешно установили соединение и перешли к отправке > > > запроса > > > > > (не важно, успели начать отправку тела или нет), запрос считается > > > > > отправленным, > > > > > т.к. в общем случае мы не знаем, был ли он обработан или нет. > > > > > > > > > > > > > я предлагаю такую логику. > > > > бекенд умеет отличать полностью полученный запрос от неполного > запроса > > > > (например, по Content-Length) > > > > навряд ли бекенд будет обрабатывать неполностью полученный запрос > > > > > > > > и считать отправленными только полностью отправленные запросы > > > > > > Считать-то можно, но у бекенда может быть своё мнение по этому > > > вопросу. Каких-либо явных утверждений в RFC 2616 / RFC 7231, > > > которые бы говорили о том, что так можно - я в своё время не > > > нашёл. И по факту так скорее всего нельзя, так как на тело > > > бекенду во многих случаях может быть наплевать. > > > > > > > есть достаточно странный кейс, когда отправляется POST без тела. не > > конкретно в наших приложениях, а в принципе. > > я по некоторым разбирался, зачем так делают (ну то есть, можно же GET, но > > специально сделали POST). ответ меня поразил - > > по RFC нельзя кешировать POST. ну и чтобы наверняка без кеша, мы выбрали > > POST )) ну а тело ... надо не надо было > > > > в описанном выше случае, действительно, тело (запроса) не предполагалось. > > > > если тело предполагается, но не было отправлено, допустим бекенд > вменяемый, > > что вполне может быть. он запрос не обработал. > > можно ретраить. > > > > каких-то явных противоречий в этом не вижу > > Явных противоречий тут и нет: скорее всего бекенд смотрит на тело, > и в тех немногих случаях, когда мы точно знаем, что оно отправлено > не полностью - скорее всего можно ретраить. > > Однако проблем тут две: > > - "Скорее всего можно" - не значит "точно можно", наступить на > ситуацию, когда бекенд на тело не смотрит - на практике вполне > можно. И каких-либо явных причин требовать от бекенда, чтобы > смотрел - я, как я уже писал выше, не вижу, и если у такого > бекенда вдруг что-то пойдёт не так - виноват будет nginx. (Если эти > причины вдруг есть - с удовольствием ознакомлюсь с соответствующей > цитатой из RFC.) > > - Условие "когда мы точно знаем" не выполняется приблизительно > никогда: в подавляющем большинстве случаев тело вместе с > запросом уже сложено в буфер сокета, и что там с ним стало > дальше - узнать невозможно. То есть мы про микрооптимизацию > оцень небольшого процента запросов. > > ну вот у меня ситуация, когда я знаю, что можно. рассказываю. берем IIS. на нем хостим ASP.NET ASP.NET хостится в т.н. AppPool, у этого пула есть режим "пул остановлен" можно настроить пул на HttpLevel, либо на TcpLevel, в первом случае остановленный пул отдает 503, во втором tcp rst. вы хотели RFC ? оно есть у меня. смотрите, есть такой хидер Expect. смотрим RFC, там сказано, что он End-to-End. итак, рассмотрим цепочку Браузер --> nginx --> IIS браузер посылает Expect: 100-Continue, по RFC nginx должен его доставить до IIS ? но этого не происходит. IIS (и http.sys под капотом) ответил бы Expect, и у nginx была бы инфа, что запрос не успел отправиться но nginx не отправляет Expect. и POST улелает в остановленный пул. если пул настроен на HttpLEvel, то пул отдает 503 уже после отправки (были бы Expect-ы, отдал бы до). ок, меняем режим пула на TcpLevel, пул должен сделать tcp rst. и он его сделает. но! нюанс. после отправки хидеров. объяснение простое, на порту, на котором слушает IIS, могут быть несколько приложений (пулов), чтобы понять, в какой именно пул мы попали, нужно поле Host. но я точно знаю, что tcp rst идет до отправки тела. и nginx это точно знает. а разработчики, которые пишут идеальные приложения ... ну я тоже люблю фантазировать. > Вместе эти две проблемы привели меня в своё время к выводу, что не > стоит тут пытаться что-то наоптимизировать, кому надо - сделают > правильно с защитой на уровне приложения, кому не надо - получают > гарантированно корректное поведение из коробки. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From div на justcommunication.ru Thu Dec 26 07:49:22 2019 From: div на justcommunication.ru (Den Ivanov) Date: Thu, 26 Dec 2019 17:49:22 +1000 Subject: Chain locations Message-ID: <822C6432-EA62-4593-8ED3-EA6968DDB43E@justcommunication.ru> Имею задачу: искать запрошенный файл в N удаленных серверах по порядку. Если все сервера ответили 404 - проксировать на fallback сервер. Если делаю вот так, то файл ищется только на server1 и server2, после чего выдает клиенту 404. Почему? Как это решить? location /data/ { proxy_pass http://server1.s3.cloud.mts.ru/data/; proxy_buffering on; proxy_buffers 64 4k; proxy_intercept_errors on; error_page 404 = @proxy_to_level1; } location @proxy_to_level1 { proxy_pass http://server2.s3.cloud.mts.ru; proxy_buffering on; proxy_buffers 64 4k; proxy_intercept_errors on; error_page 404 = @proxy_to_level2; } location @proxy_to_level2 { proxy_pass http://server3.s3.cloud.mts.ru; proxy_buffering on; proxy_buffers 64 4k; proxy_intercept_errors on; error_page 404 = @proxy_to_fallback; } location @proxy_to_fallback { proxy_pass http://xxxxxx.ru; proxy_buffering on; proxy_buffers 64 4k; } From red-fox0 на ya.ru Thu Dec 26 08:14:07 2019 From: red-fox0 на ya.ru (fox) Date: Thu, 26 Dec 2019 15:14:07 +0700 Subject: Chain locations In-Reply-To: <822C6432-EA62-4593-8ED3-EA6968DDB43E@justcommunication.ru> References: <822C6432-EA62-4593-8ED3-EA6968DDB43E@justcommunication.ru> Message-ID: Попробуйте так: location /data/ { try_files @proxy1 @proxy2 @proxy3 @proxy4 @proxy_to_fallback; } location @proxy1 { proxy_pass http://server1.s3.cloud.mts.ru; } location @proxy2 { proxy_pass http://server2.s3.cloud.mts.ru; } #… location @proxy_to_fallback { proxy_pass http://xxxxxx.ru; } 26.12.2019 14:49, Den Ivanov пишет: > Имею задачу: искать запрошенный файл в N удаленных серверах по порядку. Если все сервера ответили 404 - проксировать на fallback сервер. > > Если делаю вот так, то файл ищется только на server1 и server2, после чего выдает клиенту 404. Почему? Как это решить? > > location /data/ { > proxy_pass http://server1.s3.cloud.mts.ru/data/; > proxy_buffering on; > proxy_buffers 64 4k; > > proxy_intercept_errors on; > error_page 404 = @proxy_to_level1; > } > location @proxy_to_level1 { > proxy_pass http://server2.s3.cloud.mts.ru; > proxy_buffering on; > proxy_buffers 64 4k; > > proxy_intercept_errors on; > error_page 404 = @proxy_to_level2; > } > location @proxy_to_level2 { > proxy_pass http://server3.s3.cloud.mts.ru; > proxy_buffering on; > proxy_buffers 64 4k; > > proxy_intercept_errors on; > error_page 404 = @proxy_to_fallback; > } > location @proxy_to_fallback { > proxy_pass http://xxxxxx.ru; > proxy_buffering on; > proxy_buffers 64 4k; > } > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From oleg на mamontov.net Thu Dec 26 09:32:21 2019 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Thu, 26 Dec 2019 12:32:21 +0300 Subject: Chain locations In-Reply-To: <822C6432-EA62-4593-8ED3-EA6968DDB43E@justcommunication.ru> References: <822C6432-EA62-4593-8ED3-EA6968DDB43E@justcommunication.ru> Message-ID: <20191226093221.pfcx6ogfz4pmohcv@xenon.mamontov.net> On Thu, Dec 26, 2019 at 05:49:22PM +1000, Den Ivanov wrote: >Имею задачу: искать запрошенный файл в N удаленных серверах по порядку. Если все сервера ответили 404 - проксировать на fallback сервер. > >Если делаю вот так, то файл ищется только на server1 и server2, после чего выдает клиенту 404. Почему? Как это решить? Посмотрите на директиву recursive_error_pages: http://nginx.org/ru/docs/http/ngx_http_core_module.html#recursive_error_pages > location /data/ { > proxy_pass http://server1.s3.cloud.mts.ru/data/; > proxy_buffering on; > proxy_buffers 64 4k; > > proxy_intercept_errors on; > error_page 404 = @proxy_to_level1; > } > location @proxy_to_level1 { > proxy_pass http://server2.s3.cloud.mts.ru; > proxy_buffering on; > proxy_buffers 64 4k; > > proxy_intercept_errors on; > error_page 404 = @proxy_to_level2; > } > location @proxy_to_level2 { > proxy_pass http://server3.s3.cloud.mts.ru; > proxy_buffering on; > proxy_buffers 64 4k; > > proxy_intercept_errors on; > error_page 404 = @proxy_to_fallback; > } > location @proxy_to_fallback { > proxy_pass http://xxxxxx.ru; > proxy_buffering on; > proxy_buffers 64 4k; > } >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cheers, Oleg A. Mamontov From div на justcommunication.ru Thu Dec 26 09:48:11 2019 From: div на justcommunication.ru (Den Ivanov) Date: Thu, 26 Dec 2019 19:48:11 +1000 Subject: Chain locations In-Reply-To: <20191226093221.pfcx6ogfz4pmohcv@xenon.mamontov.net> References: <822C6432-EA62-4593-8ED3-EA6968DDB43E@justcommunication.ru> <20191226093221.pfcx6ogfz4pmohcv@xenon.mamontov.net> Message-ID: <9E64DB54-C1DE-409E-A864-2E2A5BE688FF@justcommunication.ru> Работает! Спасибо тебе, добрый человек :) > 26 дек. 2019 г., в 19:32, Oleg A. Mamontov написал(а): > > On Thu, Dec 26, 2019 at 05:49:22PM +1000, Den Ivanov wrote: >> Имею задачу: искать запрошенный файл в N удаленных серверах по порядку. Если все сервера ответили 404 - проксировать на fallback сервер. >> >> Если делаю вот так, то файл ищется только на server1 и server2, после чего выдает клиенту 404. Почему? Как это решить? > > Посмотрите на директиву recursive_error_pages: > http://nginx.org/ru/docs/http/ngx_http_core_module.html#recursive_error_pages > >> location /data/ { >> proxy_pass http://server1.s3.cloud.mts.ru/data/; >> proxy_buffering on; >> proxy_buffers 64 4k; >> >> proxy_intercept_errors on; >> error_page 404 = @proxy_to_level1; >> } >> location @proxy_to_level1 { >> proxy_pass http://server2.s3.cloud.mts.ru; >> proxy_buffering on; >> proxy_buffers 64 4k; >> >> proxy_intercept_errors on; >> error_page 404 = @proxy_to_level2; >> } >> location @proxy_to_level2 { >> proxy_pass http://server3.s3.cloud.mts.ru; >> proxy_buffering on; >> proxy_buffers 64 4k; >> >> proxy_intercept_errors on; >> error_page 404 = @proxy_to_fallback; >> } >> location @proxy_to_fallback { >> proxy_pass http://xxxxxx.ru; >> proxy_buffering on; >> proxy_buffers 64 4k; >> } >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > Cheers, > Oleg A. Mamontov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Dec 26 11:56:18 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 26 Dec 2019 14:56:18 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QstGC0L7RgNC90LDRjyDQvtGC0L/RgNCw0LLQutCwIFBPU1Qg0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LIgPw==?= In-Reply-To: References: <20191225182005.GH12894@mdounin.ru> <20191225201318.GJ12894@mdounin.ru> Message-ID: <20191226115618.GL12894@mdounin.ru> Hello! On Thu, Dec 26, 2019 at 02:05:51AM +0500, Илья Шипицин wrote: > чт, 26 дек. 2019 г. в 01:13, Maxim Dounin : > > > Hello! > > > > On Thu, Dec 26, 2019 at 12:32:04AM +0500, Илья Шипицин wrote: > > > > > ср, 25 дек. 2019 г. в 23:20, Maxim Dounin : > > > > > > > Hello! > > > > > > > > On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote: > > > > > > > > > ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov : > > > > > > > > > > > > > > > > > > On 24 Dec 2019, at 23:35, Илья Шипицин > > wrote: > > > > > > > > > > > > > > привет! > > > > > > > > > > > > > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и, > > > > > > собственно, тело запроса. мы отправили хедеры на бекенд, тело не > > успели > > > > > > отправить, и бекенд нам сделал TCP RST. > > > > > > > > > > > > > > должен ли такой POST повторно отправляться, если не указан > > > > > > non_idempotent ? (судя по моим экспериментам - не отправляется. но > > ведь > > > > > > тело не было отправлено ? значит мы должны попасть под условие, что > > > > такой > > > > > > запрос можно отправить повторно ?) > > > > > > > > > > > > Как только мы успешно установили соединение и перешли к отправке > > > > запроса > > > > > > (не важно, успели начать отправку тела или нет), запрос считается > > > > > > отправленным, > > > > > > т.к. в общем случае мы не знаем, был ли он обработан или нет. > > > > > > > > > > > > > > > > я предлагаю такую логику. > > > > > бекенд умеет отличать полностью полученный запрос от неполного > > запроса > > > > > (например, по Content-Length) > > > > > навряд ли бекенд будет обрабатывать неполностью полученный запрос > > > > > > > > > > и считать отправленными только полностью отправленные запросы > > > > > > > > Считать-то можно, но у бекенда может быть своё мнение по этому > > > > вопросу. Каких-либо явных утверждений в RFC 2616 / RFC 7231, > > > > которые бы говорили о том, что так можно - я в своё время не > > > > нашёл. И по факту так скорее всего нельзя, так как на тело > > > > бекенду во многих случаях может быть наплевать. > > > > > > > > > > есть достаточно странный кейс, когда отправляется POST без тела. не > > > конкретно в наших приложениях, а в принципе. > > > я по некоторым разбирался, зачем так делают (ну то есть, можно же GET, но > > > специально сделали POST). ответ меня поразил - > > > по RFC нельзя кешировать POST. ну и чтобы наверняка без кеша, мы выбрали > > > POST )) ну а тело ... надо не надо было > > > > > > в описанном выше случае, действительно, тело (запроса) не предполагалось. > > > > > > если тело предполагается, но не было отправлено, допустим бекенд > > вменяемый, > > > что вполне может быть. он запрос не обработал. > > > можно ретраить. > > > > > > каких-то явных противоречий в этом не вижу > > > > Явных противоречий тут и нет: скорее всего бекенд смотрит на тело, > > и в тех немногих случаях, когда мы точно знаем, что оно отправлено > > не полностью - скорее всего можно ретраить. > > > > > Однако проблем тут две: > > > > - "Скорее всего можно" - не значит "точно можно", наступить на > > ситуацию, когда бекенд на тело не смотрит - на практике вполне > > можно. И каких-либо явных причин требовать от бекенда, чтобы > > смотрел - я, как я уже писал выше, не вижу, и если у такого > > бекенда вдруг что-то пойдёт не так - виноват будет nginx. (Если эти > > причины вдруг есть - с удовольствием ознакомлюсь с соответствующей > > цитатой из RFC.) > > > > - Условие "когда мы точно знаем" не выполняется приблизительно > > никогда: в подавляющем большинстве случаев тело вместе с > > запросом уже сложено в буфер сокета, и что там с ним стало > > дальше - узнать невозможно. То есть мы про микрооптимизацию > > оцень небольшого процента запросов. > > > > > ну вот у меня ситуация, когда я знаю, что можно. > рассказываю. > > берем IIS. на нем хостим ASP.NET > ASP.NET хостится в т.н. AppPool, у этого пула есть режим "пул остановлен" > > можно настроить пул на HttpLevel, либо на TcpLevel, в первом случае > остановленный пул отдает 503, во втором tcp rst. > > вы хотели RFC ? оно есть у меня. смотрите, есть такой хидер Expect. смотрим > RFC, там сказано, что он End-to-End. > итак, рассмотрим цепочку > > Браузер --> nginx --> IIS > > браузер посылает Expect: 100-Continue, по RFC nginx должен его доставить до Какой именно браузер? Из известных мне клиентов - 100-continue шлёт только curl. > IIS ? но этого не происходит. > IIS (и http.sys под капотом) ответил бы Expect, и у nginx была бы инфа, что > запрос не успел отправиться Не было бы: запрос _успел_ отправиться. Тело запроса бекенд не принял - но это вопросы к бекенду, и что он там успел сделать по этому запросу, перед тем как сломаться - вопрос к бекенду. > но nginx не отправляет Expect. И, скорее всего, в ближайшее время не будет. В частности потому, что никто, кроме curl'а этого не поддерживает. Но это отдельный разговор, и он имеет очень мало отношения к обсуждаемому вопросу. > и POST улелает в остановленный пул. если пул настроен на HttpLEvel, то пул > отдает 503 уже после отправки (были бы Expect-ы, отдал бы до). > > ок, меняем режим пула на TcpLevel, пул должен сделать tcp rst. и он его > сделает. но! нюанс. после отправки хидеров. > объяснение простое, на порту, на котором слушает IIS, могут быть несколько > приложений (пулов), чтобы понять, в какой именно пул мы попали, нужно поле > Host. > > но я точно знаю, что tcp rst идет до отправки тела. и nginx это точно знает. Как я уже говорил, в большинстве случаев nginx ничего не знает - тело и заголовки он отправляет вместе. И если connect() к бекенду успешно прошёл - то он просто запишет в буфер сокета запрос целиком. То есть так или иначе ни 503, ни закрытие соединения после его принятия - работать не будут. В большинстве случаев у nginx'а вообще нет информации о том, отправилось ли тело на бекенд, или нет, и даже если она есть - нет оснований считать, что запрос, у которого не отправилось тело, можно отправить куда-то ещё повторно. > а разработчики, которые пишут идеальные приложения ... ну я тоже люблю > фантазировать. В данном конкретном случае есть совсем простое решение: убирать бекенды из балансировки перед тем, как их ломать. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Dec 26 19:20:37 2019 From: nginx-forum на forum.nginx.org (yanda.a) Date: Thu, 26 Dec 2019 14:20:37 -0500 Subject: =?UTF-8?B?0J/Rg9GB0YLQsNGPINC/0LXRgNC10LzQtdC90L3QsNGPICR1cHN0cmVhbSBzdGF0?= =?UTF-8?B?dXMg0L/RgNC4IDQ5OQ==?= Message-ID: <7391dc69de5d8245cbe8307837f2d53d.NginxMailingListRussian@forum.nginx.org> Добрый день! Есть upstream с несколькими серверами. На этом upstream'е бывают очень долгие запросы (это уже другая история). Если клиент разорвал соединение, в логах будет $status = 499, но продолжаем ждать ответа от бекенда (опция proxy_ignore_client_abort on), и если бекенд не отвалился по таймауту, то в переменную $upstream_status пишется код его ответа. А вот если клиент отключился от нас и бекенд отвалился по таймауту, то переменная $upstream_status пустая, хотя, должна быть 504 по идее. Для сравнения, ситуация с 504 (не кусок из логов, а просто содержимое переменных, но это взято из реальных логов, которых нет в сыром виде): status: 504 upstream_addr: backend-01-1,backend-01-2 upstream_status: 504,504 upstream_response_time: 90,90 Ситуация с 499 и таймаутом бекенда: status: 499 upstream_addr: backend-01-1 upstream_status: - upstream_response_time: 90 Ситуация с 499 и без таймаута бекенда: status: 499 upstream_addr: backend-01-2 upstream_status: 200 upstream_response_time: 0.038 Собственно, вопрос, нормальное ли подобное поведение? Или это больше смахивает на баг? Используется версия 1.16.1. Заранее спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286602,286602#msg-286602 From mdounin на mdounin.ru Fri Dec 27 14:12:24 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 27 Dec 2019 17:12:24 +0300 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: <7391dc69de5d8245cbe8307837f2d53d.NginxMailingListRussian@forum.nginx.org> References: <7391dc69de5d8245cbe8307837f2d53d.NginxMailingListRussian@forum.nginx.org> Message-ID: <20191227141224.GO12894@mdounin.ru> Hello! On Thu, Dec 26, 2019 at 02:20:37PM -0500, yanda.a wrote: > Есть upstream с несколькими серверами. На этом upstream'е бывают очень > долгие запросы (это уже другая история). Если клиент разорвал соединение, в > логах будет $status = 499, но продолжаем ждать ответа от бекенда (опция > proxy_ignore_client_abort on), и если бекенд не отвалился по таймауту, то в > переменную $upstream_status пишется код его ответа. А вот если клиент > отключился от нас и бекенд отвалился по таймауту, то переменная > $upstream_status пустая, хотя, должна быть 504 по идее. > > Для сравнения, ситуация с 504 (не кусок из логов, а просто содержимое > переменных, но это взято из реальных логов, которых нет в сыром виде): > status: 504 > upstream_addr: backend-01-1,backend-01-2 > upstream_status: 504,504 > upstream_response_time: 90,90 > > Ситуация с 499 и таймаутом бекенда: > status: 499 > upstream_addr: backend-01-1 > upstream_status: - > upstream_response_time: 90 > > Ситуация с 499 и без таймаута бекенда: > status: 499 > upstream_addr: backend-01-2 > upstream_status: 200 > upstream_response_time: 0.038 > > > Собственно, вопрос, нормальное ли подобное поведение? Или это больше > смахивает на баг? Используется версия 1.16.1. При "proxy_ignore_client_abort on;" статуса 499 быть вообще не должно. Что показывает "nginx -V" и что в конфиге? -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Dec 27 15:03:51 2019 From: nginx-forum на forum.nginx.org (yanda.a) Date: Fri, 27 Dec 2019 10:03:51 -0500 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: <20191227141224.GO12894@mdounin.ru> References: <20191227141224.GO12894@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > При "proxy_ignore_client_abort on;" статуса 499 быть вообще не > должно. > > Что показывает "nginx -V" и что в конфиге? > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru nginx version: nginx/1.16.1 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) built with OpenSSL 1.1.1d 10 Sep 2019 TLS SNI support enabled configure arguments: --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/log/nginx/access.log --http-client-body-temp-path=/var/tmp/nginx/client_body --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi --http-scgi-temp-path=/var/tmp/nginx/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-file-aio --with-ipv6 --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-openssl=../third_party/openssl-1.1.1d --with-openssl-opt=enable-tls1_3 --with-threads --add-dynamic-module=modules/ngx_brotli --add-dynamic-module=modules/xss-nginx-module-0.06 --add-dynamic-module=modules/naxsi-0.56 --add-dynamic-module=modules/incubator-pagespeed-ngx-1.13.35.2-stable --add-dynamic-module=modules/lua-nginx-module-0.10.15 --add-dynamic-module=modules/ngx_devel_kit-0.3.1 --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie -Wl,-rpath,/usr/lib64 -ljemalloc' Что именно нужно из конфига? Просто он очень большой, не думаю что это хорошая идея Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286609#msg-286609 From nginx-forum на forum.nginx.org Fri Dec 27 15:10:00 2019 From: nginx-forum на forum.nginx.org (yanda.a) Date: Fri, 27 Dec 2019 10:10:00 -0500 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: References: <20191227141224.GO12894@mdounin.ru> Message-ID: <301c09f0c45ca3716005369b14bbfba2.NginxMailingListRussian@forum.nginx.org> Предварительно, могу показать как оно проксируется, не знаю хватит ли этого: http { proxy_http_version 1.1; proxy_redirect off; proxy_intercept_errors on; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffering on; proxy_buffer_size 64k; proxy_buffers 128 128k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 128k; proxy_ignore_headers Set-Cookie; proxy_hide_header X-Powered-By; proxy_ignore_client_abort on; proxy_temp_path /var/tmp/nginx/vhosts_proxy_temp; server { ... location / { try_files $uri @proxy_upstream; } location ~ \.php$ { proxy_pass http://$httpd_upstream; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Server $server_addr; proxy_set_header X-Url-Scheme $scheme; } location @proxy_upstream { proxy_pass http://$httpd_upstream; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Server $server_addr; proxy_set_header X-Url-Scheme $scheme; } } map $remote_addr $httpd { default httpd; } upstream httpd { server backend-01-1:8081 max_fails=5; server backend-01-2:8081 max_fails=5; } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286610#msg-286610 From mdounin на mdounin.ru Fri Dec 27 17:02:53 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 27 Dec 2019 20:02:53 +0300 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: References: <20191227141224.GO12894@mdounin.ru> Message-ID: <20191227170253.GP12894@mdounin.ru> Hello! On Fri, Dec 27, 2019 at 10:03:51AM -0500, yanda.a wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Hello! > > > > При "proxy_ignore_client_abort on;" статуса 499 быть вообще не > > должно. > > > > Что показывает "nginx -V" и что в конфиге? > > > > -- > > Maxim Dounin > > http://mdounin.ru/ > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > nginx version: nginx/1.16.1 > built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) > built with OpenSSL 1.1.1d 10 Sep 2019 > TLS SNI support enabled > configure arguments: --sbin-path=/usr/sbin/nginx > --modules-path=/usr/lib64/nginx/modules --prefix=/etc/nginx > --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/log/nginx/access.log > --http-client-body-temp-path=/var/tmp/nginx/client_body > --http-proxy-temp-path=/var/tmp/nginx/proxy > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi > --http-scgi-temp-path=/var/tmp/nginx/scgi --pid-path=/run/nginx.pid > --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat > --with-file-aio --with-ipv6 --with-http_addition_module > --with-http_auth_request_module --with-http_dav_module > --with-http_degradation_module --with-http_flv_module > --with-http_geoip_module=dynamic --with-http_gunzip_module > --with-http_gzip_static_module --with-http_image_filter_module=dynamic > --with-http_mp4_module --with-http_perl_module=dynamic > --with-http_random_index_module --with-http_realip_module > --with-http_secure_link_module --with-http_slice_module > --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module > --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic > --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic > --with-stream_realip_module --with-stream_ssl_module > --with-stream_ssl_preread_module > --with-openssl=../third_party/openssl-1.1.1d > --with-openssl-opt=enable-tls1_3 --with-threads > --add-dynamic-module=modules/ngx_brotli > --add-dynamic-module=modules/xss-nginx-module-0.06 > --add-dynamic-module=modules/naxsi-0.56 > --add-dynamic-module=modules/incubator-pagespeed-ngx-1.13.35.2-stable > --add-dynamic-module=modules/lua-nginx-module-0.10.15 > --add-dynamic-module=modules/ngx_devel_kit-0.3.1 --with-cc-opt='-O2 -g -pipe > -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong > --param=ssp-buffer-size=4 -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fPIC' > --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie -Wl,-rpath,/usr/lib64 > -ljemalloc' > > Что именно нужно из конфига? Просто он очень большой, не думаю что это > хорошая идея В идеале - из конфига нужен полный минимальный конфиг, на котором видно описанное поведение. Вот, скажем, на таком - не видно: daemon off; master_process on; error_log stderr info; worker_processes 1; events { worker_connections 1024; } http { log_format test "status: $status\n" "upstream_addr: $upstream_addr\n" "upstream_status: $upstream_status"; access_log /dev/stderr test; upstream u { server 127.0.0.1:8081; server 127.0.0.1:8082; } server { listen 8080; location / { proxy_pass http://u; proxy_ignore_client_abort on; proxy_read_timeout 3s; } } server { listen 8081; listen 8082; delay 5s; access_log off; } } (Директива delay - от ngx_http_delay_module, http://mdounin.ru/hg/ngx_http_delay_module/, вместо неё можно использовать любой бекенд, который отвечает долго.) Делаем запрос и сбрасываем соединение: $ curl -k "http://127.0.0.1:8080/foo" ^C На выходе получаем: status: 504 upstream_addr: 127.0.0.1:8081, 127.0.0.1:8082 upstream_status: 504, 504 -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Dec 30 07:14:05 2019 From: nginx-forum на forum.nginx.org (grey) Date: Mon, 30 Dec 2019 02:14:05 -0500 Subject: CPU IRQ 100% In-Reply-To: References: Message-ID: <8109cc9d0d2202fded168de339be997f.NginxMailingListRussian@forum.nginx.org> Не пробовали обновиться до последней версии 1.17.7? Помогло? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286474,286630#msg-286630 From nginx-forum на forum.nginx.org Mon Dec 30 08:22:01 2019 From: nginx-forum на forum.nginx.org (yanda.a) Date: Mon, 30 Dec 2019 03:22:01 -0500 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: <20191227170253.GP12894@mdounin.ru> References: <20191227170253.GP12894@mdounin.ru> Message-ID: <8b91ef08b7d2d94ff1d6198c2e3d5270.NginxMailingListRussian@forum.nginx.org> Добрался до конфигурации, скину почти полную конфигурацию: load_module "/usr/lib64/nginx/modules/ngx_http_geoip_module.so"; load_module "/usr/lib64/nginx/modules/ndk_http_module.so"; load_module "/usr/lib64/nginx/modules/ngx_http_lua_module.so"; load_module "/usr/lib64/nginx/modules/ngx_http_brotli_filter_module.so"; load_module "/usr/lib64/nginx/modules/ngx_http_brotli_static_module.so"; user nginx nginx; worker_rlimit_nofile 245760; worker_processes 24; worker_priority -10; worker_cpu_affinity auto 000000000000111111111111000000000000111111111111; pid /var/run/nginx.pid; pcre_jit on; thread_pool local_pool threads=8; # Pool for local filesystem thread_pool nfs_pool threads=8; # Pool for NFS-share events { worker_connections 10240; use epoll; multi_accept on; accept_mutex off; } http { include mime.types; default_type application/octet-stream; log_format json escape=json '{' '"request_id":"$request_id",' '"remote_addr":"$remote_addr",' '"http_host":"$http_host",' '"server_name":"$server_name",' '"domain_tags":"$domain_tags",' '"ssl_auth":"$ssl_client_verify",' '"ssl_cn":"$ssl_client_s_dn",' '"timestamp":"$time_local",' '"status":"$status",' '"request_time":"$request_time",' '"upstream_name":"$upstream_name",' # custom variable '"upstream_status":"$upstream_status",' '"upstream_queue_time":"$upstream_response_time",' '"upstream_connect_time":"$upstream_response_time",' '"upstream_header_time":"$upstream_response_time",' '"upstream_response_time":"$upstream_response_time",' '"upstream_cache_status":"$upstream_cache_status",' '"upstream_addr":"$upstream_addr",' '"request_method":"$request_method",' '"request_uri":"$request_uri",' '"protocol":"$server_protocol",' '"bytes_received":"$request_length",' '"bytes_sent":"$body_bytes_sent",' '"referer":"$http_referer",' '"user_agent":"$http_user_agent",' '"x_requested_with":"$http_x_requested_with",' '"scheme":"$scheme"' '}'; access_log syslog:server=unix:/dev/log,tag=access_log,facility=local6 json; error_log syslog:server=unix:/dev/log,tag=error_log,facility=local7 warn; # Disk read settings sendfile on; sendfile_max_chunk 256k; aio threads=local_pool; aio_write on; directio 4m; # this is disabled in location where are used files from NFS-share output_buffers 1 2m; read_ahead 512k; # ignored in Linux # Buffers large_client_header_buffers 4 32k; client_body_buffer_size 128k; # TCP-socket settings keepalive_timeout 15 15; keepalive_requests 1000; tcp_nopush on; tcp_nodelay on; reset_timedout_connection on; # Internal memory structures open_file_cache max=1000000 inactive=40s; open_file_cache_valid 60s; open_file_cache_min_uses 2; open_file_cache_errors on; open_log_file_cache max=500 inactive=30m valid=10m min_uses=1; variables_hash_max_size 2048; variables_hash_bucket_size 128; server_names_hash_max_size 1024; server_names_hash_bucket_size 128; map_hash_bucket_size 128; # Response settings server_tokens off; # Internal behavior settings uninitialized_variable_warn on; # Proxy settings proxy_http_version 1.1; # for keepalive to upstream # Proxy errors and redirects behavior proxy_redirect off; # Rewrite header location on redirect proxy_intercept_errors on; # Intercept and handle errors by nginx proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; # Proxy timeouts proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; # Proxy buffers proxy_buffering on; proxy_buffer_size 64k; proxy_buffers 128 128k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 128k; proxy_ignore_headers Set-Cookie; proxy_hide_header X-Powered-By; proxy_ignore_client_abort on; # Proxy temp path proxy_temp_path /var/tmp/nginx/vhosts_proxy_temp; client_body_temp_path /var/tmp/nginx/vhosts_client_body_temp; # GZip and Brotli configuration was here # GeoIP settings geoip_country /usr/share/GeoIP/GeoIP.dat; geoip_city /usr/share/GeoIP/GeoIPCity.dat; # Request limit client_max_body_size 10m; # Req and conn zones limit_req_log_level info; # Loglevel for request limit exceeded. Currently unused. limit_conn_log_level info; # Loglevel for connection limit exceeded. Currently unused. # Lua settings lua_code_cache on; # Disable only for debug! # UserID settings userid on; userid_expires max; userid_name __utmd; userid_path /; userid_p3p 'CP="CUR ADM OUR NOR STA NID"'; # SSL configuration was here resolver 127.0.0.1 ipv6=off; resolver_timeout 5s; # Map for client split, use $httpd_testing_upstream in proxy_pass for use this upstream map $remote_addr $httpd_testing_upstream { default httpd_testing; } # Upstream server-list upstream httpd_comboplayer { server backend-01-1:8081 max_fails=5; server backend-01-2:8081 max_fails=5; } server { # listen, server_name and SSL configuration was here # Static files caching was here # Root and last location location / { try_files $uri @proxy_upstream; } # Location for php files location ~ \.php$ { set $upstream_name $httpd_testing_upstream; proxy_pass http://$httpd_testing_upstream; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Server $server_addr; proxy_set_header X-Url-Scheme $scheme; } # Upstream location location @proxy_upstream { set $upstream_name $httpd_testing_upstream; proxy_pass http://$httpd_testing_upstream; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Port $server_port; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Server $server_addr; proxy_set_header X-Url-Scheme $scheme; } } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286631#msg-286631 From tolmachev.vlad на gmail.com Mon Dec 30 12:19:32 2019 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Mon, 30 Dec 2019 15:19:32 +0300 Subject: CPU IRQ 100% In-Reply-To: <8109cc9d0d2202fded168de339be997f.NginxMailingListRussian@forum.nginx.org> References: <8109cc9d0d2202fded168de339be997f.NginxMailingListRussian@forum.nginx.org> Message-ID: Нет, не помогает пн, 30 дек. 2019 г. в 10:14, grey : > Не пробовали обновиться до последней версии 1.17.7? Помогло? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,286474,286630#msg-286630 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Dec 31 10:44:14 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 31 Dec 2019 13:44:14 +0300 Subject: CPU IRQ 100% In-Reply-To: <8109cc9d0d2202fded168de339be997f.NginxMailingListRussian@forum.nginx.org> References: <8109cc9d0d2202fded168de339be997f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20191231104414.GR12894@mdounin.ru> Hello! On Mon, Dec 30, 2019 at 02:14:05AM -0500, grey wrote: > Не пробовали обновиться до последней версии 1.17.7? Помогло? С учётом того, что процессор потребляет не nginx, а IRQ - это выглядит как проблема системы, и шансов, что обновление nginx'а что-то исправит - приблизительно никаких. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Dec 31 10:58:12 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 31 Dec 2019 13:58:12 +0300 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: <8b91ef08b7d2d94ff1d6198c2e3d5270.NginxMailingListRussian@forum.nginx.org> References: <20191227170253.GP12894@mdounin.ru> <8b91ef08b7d2d94ff1d6198c2e3d5270.NginxMailingListRussian@forum.nginx.org> Message-ID: <20191231105812.GS12894@mdounin.ru> Hello! On Mon, Dec 30, 2019 at 03:22:01AM -0500, yanda.a wrote: > Добрался до конфигурации, скину почти полную конфигурацию: [...] Смысла в "почти полной" конфигурации не очень много. Нужна конфигурация, с которой воспроизводится то, на что вы жалуетесь. Попробуйте воспроизвести проблемное поведение в песочнице, с использованием минимальной конфигурации. Скорее всего в процессе станет понятно, в чём именно проблема. -- Maxim Dounin http://mdounin.ru/