From gmm на csdoc.com Sun Mar 1 06:39:04 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 1 Mar 2020 08:39:04 +0200 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <6cd59cc47f00a9238784882612ce47ac.NginxMailingListRussian@forum.nginx.org> References: <20200229132928.GS1422@sie.protva.ru> <10971e10c1bf6767cfdf5153a9519860.NginxMailingListRussian@forum.nginx.org> <6cd59cc47f00a9238784882612ce47ac.NginxMailingListRussian@forum.nginx.org> Message-ID: On 29.02.2020 17:34, windos321 wrote: > Перебрал все возможные юниты, network-scripts... Скорее всего, у Вас там DHCP и скорее всего - Вы не пробовали https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html как Вам это рекомендовал сделать Алексей в этом списке рассылки. -------- Forwarded Message -------- Subject: Re: Проблема с перезапуском в centos 8 Date: Sat, 29 Feb 2020 00:07:42 +0300 From: Alexey Reply-To: nginx-ru на nginx.org To: nginx-ru на nginx.org cat /etc/systemd/system/multi-user.target.wants/nginx.service там точно есть After= ... network-online.target ... nss-lookup.target ... Wants= network-online.target ? systemctl daemon-reload после правки /usr/lib/systemd/system/nginx.service делался ? точно эта же проблемы была на 7 центоси пускаемой в контейнере, и жалобы на чтото типы юбунты тоже были. Проблема в том, что systemd сильна асинхронно пускает все сервисы, и нгинкс успевает стартануть до сети, и обламывается потому, что до ресловера достутчаться нельзя.. при network-online.target и nss-lookup.target ресолв должен работать бы... у вас часом адреса не по DHCP ? если DHCP, можно затычку вида https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html и зависимость от него... -- Best regards, Gena From nginx-forum на forum.nginx.org Sun Mar 1 10:52:15 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Sun, 01 Mar 2020 05:52:15 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: Был DHCP изначально, но перенастройка на static не помогает. https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html Здесь говорится о systemd-networkd-wait-online.service По умолчанию в centos 8 его нету. Зато есть NetworkManager-wait-online.service Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287210#msg-287210 From nginx-forum на forum.nginx.org Sun Mar 1 11:28:47 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Sun, 01 Mar 2020 06:28:47 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: <294520d78f5f3ba3c3fe6626af9f1791.NginxMailingListRussian@forum.nginx.org> Короче все дело было вот здесь: /usr/lib/systemd/system/NetworkManager-wait-online.service убрать параметр -s, который почему-то по умолчанию стоит в centos 8 с этим параметром centos 8 не ждет подключения к сети, ей достаточно запуска network manager Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287211#msg-287211 From chipitsine на gmail.com Mon Mar 2 07:41:58 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 2 Mar 2020 12:41:58 +0500 Subject: =?UTF-8?B?0LfQtdGA0LrQsNC70LjRgNC+0LLQsNC90LjQtSBVRFAg0YLRgNCw0YTQuNC60LA=?= Message-ID: привет! хочется странного - продублировать udp трафик на несколько ендпойтов в режиме "ответа не предполагается". придумался костыльный вариант - проксировать якобы с ожиданием ответа, и в случае, если ответа не было (а его не будет), проксировать на следующий. некостыльных вариантов нет ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From boco на ufanet.ru Mon Mar 2 07:45:17 2020 From: boco на ufanet.ru (damir bikmuhametov) Date: Mon, 2 Mar 2020 12:45:17 +0500 Subject: =?UTF-8?B?UmU6INC30LXRgNC60LDQu9C40YDQvtCy0LDQvdC40LUgVURQINGC0YDQsNGE0Lg=?= =?UTF-8?B?0LrQsA==?= In-Reply-To: References: Message-ID: <20200302074517.GP24754@ufanet.ru> On Mon, Mar 02, 2020 at 12:41:58PM +0500, Илья Шипицин wrote: > хочется странного - продублировать udp трафик на несколько ендпойтов в > режиме "ответа не предполагается". https://github.com/sleinen/samplicator =) -- boco From chipitsine на gmail.com Mon Mar 2 07:50:15 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 2 Mar 2020 12:50:15 +0500 Subject: =?UTF-8?B?UmU6INC30LXRgNC60LDQu9C40YDQvtCy0LDQvdC40LUgVURQINGC0YDQsNGE0Lg=?= =?UTF-8?B?0LrQsA==?= In-Reply-To: <20200302074517.GP24754@ufanet.ru> References: <20200302074517.GP24754@ufanet.ru> Message-ID: пн, 2 мар. 2020 г. в 12:45, damir bikmuhametov : > On Mon, Mar 02, 2020 at 12:41:58PM +0500, Илья Шипицин wrote: > > хочется странного - продублировать udp трафик на несколько ендпойтов в > > режиме "ответа не предполагается". > > https://github.com/sleinen/samplicator =) > да, эта штука в шортлисте. > > -- > boco > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Mon Mar 2 10:12:56 2020 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Mon, 02 Mar 2020 13:12:56 +0300 Subject: =?UTF-8?B?UmU6INC30LXRgNC60LDQu9C40YDQvtCy0LDQvdC40LUgVURQINGC0YDQsNGE0Lg=?= =?UTF-8?B?0LrQsA==?= In-Reply-To: References: Message-ID: Илья Шипицин писал 2020-03-02 10:41: > привет! > > хочется странного - продублировать udp > трафик на несколько ендпойтов в > режиме "ответа не предполагается". > > придумался костыльный вариант - > проксировать якобы с ожиданием > ответа, и в случае, если ответа не было > (а его не будет), проксировать на > следующий. > > некостыльных вариантов нет ? Пропатчить http://nginx.org/ru/docs/http/ngx_http_mirror_module.html на предмет работы с UDP ? -- Best regards, Andrey A. Kopeyko From kpoxa на kpoxa.net Mon Mar 2 11:02:20 2020 From: kpoxa на kpoxa.net (kpoxa) Date: Mon, 2 Mar 2020 14:02:20 +0300 Subject: =?UTF-8?B?UmU6INCb0L7Qs9Cz0LjRgNC+0LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0LHQtdC3INC30LDQv9GA0L7RgdC+0LI=?= In-Reply-To: <20200227122245.GF12894@mdounin.ru> References: <20200227122245.GF12894@mdounin.ru> Message-ID: Добрый день. Я конечно могу описать кейс, когда это нужно. А именно когда есть сохраненный трафик и надо понять, к чему он относится. Подробнее не могу, у меня подписка о неразглашении. чт, 27 февр. 2020 г. в 15:22, Maxim Dounin : > Hello! > > On Thu, Feb 27, 2020 at 01:08:47PM +0300, kpoxa wrote: > > > Браузеры часто делают коннекты без запросов, которые выглядят как "а ну > ка > > я сделаю коннект, мало ли что надо будет.. не.. не понадобилось, разрываю > > коннект" > > и информации об этом коннекте в access_log конечно же нет, но логгировать > > такие коннекты надо. Как это можно сделать? > > Если писать свой модуль, то в какой обработчик придёт подобная > информация? > > Сейчас для http эта информация есть только на уровне debug log'а. > И в своём модуле - её тоже никак не получить, модули в http > начинают работать только после получения заголовков запроса. > > Мы пару раз задумывались над вопросом "а не добавить ли строчку в > error log на уровне info?", вида "client X connected to Y", > аналогично тому, что делается в mail и stream. Но пока нет > разумного ответа на вопрос "а надо ли это вообще кому-то". > > -- > Maxim Dounin > http://mdounin.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 mdounin на mdounin.ru Tue Mar 3 15:16:20 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 3 Mar 2020 18:16:20 +0300 Subject: nginx-1.17.9 Message-ID: <20200303151620.GR12894@mdounin.ru> Изменения в nginx 1.17.9 03.03.2020 *) Изменение: теперь nginx не разрешает несколько строк "Host" в заголовке запроса. *) Исправление: nginx игнорировал дополнительные строки "Transfer-Encoding" в заголовке запроса. *) Исправление: утечки сокетов при использовании HTTP/2. *) Исправление: в рабочем процессе мог произойти segmentation fault, если использовался OCSP stapling. *) Исправление: в модуле ngx_http_mp4_module. *) Исправление: при перенаправлении ошибок с кодом 494 с помощью директивы error_page nginx возвращал ответ с кодом 494 вместо 400. *) Исправление: утечки сокетов при использовании подзапросов в модуле njs и директивы aio. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Thu Mar 5 11:30:01 2020 From: nginx-forum на forum.nginx.org (grey) Date: Thu, 05 Mar 2020 06:30:01 -0500 Subject: =?UTF-8?B?SFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0INC/0YDQuCDRgNC10YHRgtGA0LjQvNC1?= =?UTF-8?B?INCw0YPQtNC40L4g0L/QvtGC0L7QutCw?= Message-ID: Делаю рестрим с локального сервера средствами nginx: location /radio { proxy_pass http://192.168.0.3:8000/128kbit.mp3; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } Если зайти на сайт по адресу test.com/radio - радио играет как положено. Откуда тогда берется ошибка? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287264#msg-287264 From nginx-forum на forum.nginx.org Thu Mar 5 19:15:28 2020 From: nginx-forum на forum.nginx.org (mikhal123) Date: Thu, 05 Mar 2020 14:15:28 -0500 Subject: [crit] SSL_read_early_data() failed In-Reply-To: References: Message-ID: <43f96925ee960e21787a321decaff327.NginxMailingListRussian@forum.nginx.org> В коллекцию "критических" для nginx ошибок: 2020/03/05 18:52:12 [crit] 2112#2112: *1715715 SSL_write() failed while processing HTTP/2 connection, client: ip_адрес_клиента 2020/03/05 19:51:36 [crit] 2107#2107: *1814649 SSL_write() failed while sending response to client, client: ip_адрес_клиента Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287080,287270#msg-287270 From nginx-forum на forum.nginx.org Wed Mar 11 14:19:56 2020 From: nginx-forum на forum.nginx.org (grey) Date: Wed, 11 Mar 2020 10:19:56 -0400 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: References: Message-ID: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org> Может быть это поможет в локализации проблемы. На локальном сервере 192.168.0.3 вещает Icecast. Если подключиться к нему напрямую, то он отдает заголовки: HTTP/1.0 200 OK Content-Type: audio/mpeg icy-br:128 ice-audio-info: bitrate=128;channels=2;samplerate=44100 icy-description:тут описание радиостанции длиной 145 символов на английском. icy-genre:Information and music icy-name:radio test. icy-pub:0 icy-url:https://test.ru Server: Icecast 2.3.2 Cache-Control: no-cache Если же подключаться с нему через nginx-ректрансляцию, то nginx сообщает о ошибке HTTP/1.1 400 Bad Request. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287290#msg-287290 From nginx-forum на forum.nginx.org Wed Mar 11 15:13:35 2020 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Wed, 11 Mar 2020 11:13:35 -0400 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org> References: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org> Message-ID: <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org> Вы ошибку не описали... Но, подозреваю, делаете HEAD запрос. Проверил у себя на аналогичном - HEAD дает 400, а вот GET отрабатывает нормально со всеми нужными заголовками. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287291#msg-287291 From nginx-forum на forum.nginx.org Wed Mar 11 17:12:08 2020 From: nginx-forum на forum.nginx.org (suberjin) Date: Wed, 11 Mar 2020 13:12:08 -0400 Subject: =?UTF-8?B?0JHQu9C+0LrQuNGA0L7QstCw0L3QuNC1INC00L7RgdGC0YPQv9CwINGBIGN1c3Rv?= =?UTF-8?B?bSBlcnJvciBwYWdl?= Message-ID: Здравствуйте. Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, мне бы хотелось возвращать стилизированную картинку. я это вижу как-то так: if ($allowed_country = no) { return 403; error_page 403 /errors/deny.html; } В самом конфиге много location-ов. Я не хотел бы копировать этот код во все из них. Алетрнатива - указать его глобально, но тогда я не могу использовать в блоке if - "error_page 403 /pages/unavailable.html; " Эту директиву нельзя использовать в том контексте. В итоге у меня получается или указать блокирование глобально в директиве server, но без красивой ошибки или копировать код во все location-ы Конфиг выглядит примерно так: server { listen 443 ssl http2; ## listen for ipv4 listen [::]:443 ssl http2; ## listen for ipv6 server_name example.com; root /var/www/html/ location / { if ($allowed_country = no) { return 403; error_page 403 /pages/unavailable.html; } } location = /admin { try_files $uri /index.php$is_args$args; if ($allowed_country = no) { return 403; error_page 403 /pages/unavailable.html; } } location /errors/ { root /var/www/html/errors/; internal; } } Подозреваю, что я что-то не так делаю. Прошу помочь. Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287292,287292#msg-287292 From andrey на kopeyko.ru Wed Mar 11 19:25:04 2020 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 11 Mar 2020 22:25:04 +0300 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?= =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?= In-Reply-To: References: Message-ID: <8ffe3d8cd204a3047571a32cb86ab0f6@kopeyko.ru> suberjin писал 2020-03-11 20:12: > Здравствуйте. Добрый вечер! > Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, > мне бы > хотелось возвращать стилизированную картинку. > > я это вижу как-то так: > > if ($allowed_country = no) { > return 403; > error_page 403 /errors/deny.html; > } > > В самом конфиге много location-ов. Я не хотел бы копировать этот код во > все из них. Вынесите этот фрагмент в кусочек конфига, и инклудьте его в нужных местах. > Подозреваю, что я что-то не так делаю. Прошу помочь. Спасибо! -- Best regards, Andrey A. Kopeyko From andrey на kopeyko.ru Wed Mar 11 19:27:59 2020 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 11 Mar 2020 22:27:59 +0300 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?= =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?= In-Reply-To: <8ffe3d8cd204a3047571a32cb86ab0f6@kopeyko.ru> References: <8ffe3d8cd204a3047571a32cb86ab0f6@kopeyko.ru> Message-ID: <46b62fd6ab5aa4b9861814e642bf3f5c@kopeyko.ru> Andrey Kopeyko писал 2020-03-11 22:25: > suberjin писал 2020-03-11 20:12: >> Здравствуйте. > > Добрый вечер! > >> Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, >> мне бы >> хотелось возвращать стилизированную картинку. >> >> я это вижу как-то так: >> >> if ($allowed_country = no) { >> return 403; >> error_page 403 /errors/deny.html; >> } >> >> В самом конфиге много location-ов. Я не хотел бы копировать этот код >> во все из них. > > Вынесите этот фрагмент в кусочек конфига, и инклудьте его в нужных > местах. Другой вариант - генерируйте ваш конфиг с нужными проверками в каждом из локейшенов. -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Wed Mar 11 19:35:05 2020 From: nginx-forum на forum.nginx.org (suberjin) Date: Wed, 11 Mar 2020 15:35:05 -0400 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?= =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?= In-Reply-To: <46b62fd6ab5aa4b9861814e642bf3f5c@kopeyko.ru> References: <46b62fd6ab5aa4b9861814e642bf3f5c@kopeyko.ru> Message-ID: <60371d8222d33a886c232f9caf3bca93.NginxMailingListRussian@forum.nginx.org> Спасибо за совет! Похоже, что Include - оптимальный вариант. Я сначала думал, может я по незнанию упустил какой-то нативный способ. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287292,287295#msg-287295 From oleg на mamontov.net Wed Mar 11 19:52:46 2020 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Wed, 11 Mar 2020 22:52:46 +0300 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?= =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?= In-Reply-To: References: Message-ID: <20200311195246.e5yvv6jbepgwxqhz@xenon.mamontov.net> On Wed, Mar 11, 2020 at 01:12:08PM -0400, suberjin wrote: >Здравствуйте. > >Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, мне бы >хотелось возвращать стилизированную картинку. > >я это вижу как-то так: > > if ($allowed_country = no) { > return 403; > error_page 403 /errors/deny.html; > } > >В самом конфиге много location-ов. Я не хотел бы копировать этот код во все >из них. >Алетрнатива - указать его глобально, но тогда я не могу использовать в блоке >if - "error_page 403 /pages/unavailable.html; " Эту директиву нельзя >использовать в том контексте. > >В итоге у меня получается или указать блокирование глобально в директиве >server, но без красивой ошибки или копировать код во все location-ы Вот такой вариант вам не подойдет? --- server { listen 80; server_name example.com; if ( $allowed_country = no ) { set $allowed_country yes; # breaking loop rewrite ^ /deny last; } location / { proxy_pass http://backend; } location = /deny { internal; error_page 403 /errors/deny.html; return 403; } location /errors/ { internal; root /var/www/html; } } --- Может и не образец красоты, но работать должно. >Конфиг выглядит примерно так: > > >server { > listen 443 ssl http2; ## listen for ipv4 > listen [::]:443 ssl http2; ## listen for ipv6 > > server_name example.com; > > root /var/www/html/ > > location / { > if ($allowed_country = no) { > return 403; > error_page 403 /pages/unavailable.html; > } > } > > location = /admin { > try_files $uri /index.php$is_args$args; > > if ($allowed_country = no) { > return 403; > error_page 403 /pages/unavailable.html; > } > > } > > > location /errors/ { > root /var/www/html/errors/; > internal; > } > >} > >Подозреваю, что я что-то не так делаю. Прошу помочь. Спасибо! > >Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287292,287292#msg-287292 > >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From nginx-forum на forum.nginx.org Thu Mar 12 06:32:23 2020 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Thu, 12 Mar 2020 02:32:23 -0400 Subject: UDP Connection refused Message-ID: При отправке логов через syslog (udp) проскакивают ошибки 111 Connection refused, что непонятно при отправке логов по udp, так как этот протокол не подразумевает установки соединения в принципе. strace дает следующее: 30752 sendto(64, "<190>Mar 12 09:45:59 balancer nginx: { \"timestamp\": \"2020-03-12T09:45:59+05:00\", \"remote_addr\": \"91.144.134.5\", \"body_bytes_sent\": 18686, \"request_time\": 0.000, \"response_status\": 200, \"request\": \"GET /themes/default/images/flags.png HTTP/1.0\", \"request_method\": \"GET\", \"host\": \"chel.wifi.example.ru\",\"upstream_cache_status\": \"HIT\",\"upstream_addr\": \"\",\"http_x_forwarded_for\": \"10.12.199.134\",\"http_referrer\": \"https://chel.wifi.domru.ru/index.php?request_uri=http://captive.apple.com/hotspot-detect.html\", \"upstream_response_time\": \"\",\"upstream_header_time\": \"\",\"upstream_connect_time\": \"\",\"http_user_agent\": \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14) AppleWebKit/605.1.15 (KHTML, like Gecko)\",\"x-project\": \"\",\"cluster\": \"1\",\"container_id\": \"\",\"citydomain\": \"\" }", 765, 0, NULL, 0) = -1 ECONNREFUSED (Connection refused) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287308,287308#msg-287308 From nginx-forum на forum.nginx.org Thu Mar 12 08:01:57 2020 From: nginx-forum на forum.nginx.org (suberjin) Date: Thu, 12 Mar 2020 04:01:57 -0400 Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?= =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?= In-Reply-To: <20200311195246.e5yvv6jbepgwxqhz@xenon.mamontov.net> References: <20200311195246.e5yvv6jbepgwxqhz@xenon.mamontov.net> Message-ID: <7ac43d7117d92671f416e369e0dd99de.NginxMailingListRussian@forum.nginx.org> то что нужно, работает великолепно! Очень признателен за помощь! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287292,287309#msg-287309 From nginx-forum на forum.nginx.org Thu Mar 12 09:33:37 2020 From: nginx-forum на forum.nginx.org (grey) Date: Thu, 12 Mar 2020 05:33:37 -0400 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org> References: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org> <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org> Message-ID: <763781c973fac6445799e57440b8e8de.NginxMailingListRussian@forum.nginx.org> Ошибки как таковой нету, есть не верный код возврата заголовка. Делаю именно GET, получаю ответ: HTTP/1.1 400 Bad Request Server: nginx Date: Thu, 12 Mar 2020 09:31:23 GMT Content-Type: text/html Content-Length: 248 Connection: close Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287310#msg-287310 From chipitsine на gmail.com Thu Mar 12 09:44:40 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 12 Mar 2020 14:44:40 +0500 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <763781c973fac6445799e57440b8e8de.NginxMailingListRussian@forum.nginx.org> References: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org> <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org> <763781c973fac6445799e57440b8e8de.NginxMailingListRussian@forum.nginx.org> Message-ID: попробуйте дебажную сборку nginx и error.log в режиме debug чт, 12 мар. 2020 г. в 14:33, grey : > Ошибки как таковой нету, есть не верный код возврата заголовка. > > Делаю именно GET, получаю ответ: > > HTTP/1.1 400 Bad Request > Server: nginx > Date: Thu, 12 Mar 2020 09:31:23 GMT > Content-Type: text/html > Content-Length: 248 > Connection: close > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287264,287310#msg-287310 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Thu Mar 12 09:51:42 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 12 Mar 2020 12:51:42 +0300 Subject: UDP Connection refused In-Reply-To: References: Message-ID: <20200312095142.GA2894@protva.ru> On Thu, Mar 12, 2020 at 02:32:23AM -0400, inkognito0609 wrote: > При отправке логов через syslog (udp) проскакивают ошибки 111 Connection > refused, что непонятно при отправке логов по udp, так как этот протокол не > подразумевает установки соединения в принципе. Читайте man 7 udp. ECONNREFUSED может быть вызвана отображением на уровень сокетов ответов icmp[port-unreach], icmp[admin-prohib] на предыдущие пакеты от этого сокета, а также блокировкой исходящих udp локальным пакетным фильтром. Конкретика зависит от реализации (может отличаться для разных ОС). К nginx это отношения не имеет. -- Eugene Berdnikov From mdounin на mdounin.ru Thu Mar 12 12:34:03 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 12 Mar 2020 15:34:03 +0300 Subject: UDP Connection refused In-Reply-To: References: Message-ID: <20200312123403.GH12894@mdounin.ru> Hello! On Thu, Mar 12, 2020 at 02:32:23AM -0400, inkognito0609 wrote: > При отправке логов через syslog (udp) проскакивают ошибки 111 Connection > refused, что непонятно при отправке логов по udp, так как этот протокол не > подразумевает установки соединения в принципе. > > strace дает следующее: > 30752 sendto(64, "<190>Mar 12 09:45:59 balancer nginx: { \"timestamp\": > \"2020-03-12T09:45:59+05:00\", \"remote_addr\": \"91.144.134.5\", > \"body_bytes_sent\": 18686, \"request_time\": 0.000, \"response_status\": > 200, \"request\": \"GET /themes/default/images/flags.png HTTP/1.0\", > \"request_method\": \"GET\", \"host\": > \"chel.wifi.example.ru\",\"upstream_cache_status\": > \"HIT\",\"upstream_addr\": \"\",\"http_x_forwarded_for\": > \"10.12.199.134\",\"http_referrer\": > \"https://chel.wifi.domru.ru/index.php?request_uri=http://captive.apple.com/hotspot-detect.html\", > \"upstream_response_time\": \"\",\"upstream_header_time\": > \"\",\"upstream_connect_time\": \"\",\"http_user_agent\": \"Mozilla/5.0 > (Macintosh; Intel Mac OS X 10_14) AppleWebKit/605.1.15 (KHTML, like > Gecko)\",\"x-project\": \"\",\"cluster\": \"1\",\"container_id\": > \"\",\"citydomain\": \"\" }", 765, 0, NULL, 0) = -1 ECONNREFUSED (Connection > refused) Да, так бывает. Цитируя "Programming UNIX Sockets in C - Frequently Asked Questions", AKA Socket FAQ (http://web.deu.edu.tr/doc/soket/#faq57): : If the target machine discards the message because there is no : process reading on the requested port number, it sends an ICMP : message to your machine which will cause the next system call on : the socket to return ECONNREFUSED. Since delivery of ICMP messages : is not guarenteed you may not recieve this notification on the : first transaction. То есть ошибка ожидаема, и она означает, что на предыдущее сообщение в syslog прилетело ICMP-сообщение в ответ. Если вы не в курсе, что у вас часть UDP-сообщений где-то реджектится - это повод разобраться, где и почему. Если в курсе - это лишнее напоминание, что оно так. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Mar 12 16:54:31 2020 From: nginx-forum на forum.nginx.org (grey) Date: Thu, 12 Mar 2020 12:54:31 -0400 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org> References: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org> <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org> Message-ID: <0c5768569c1b8c66ee922518759ba7d4.NginxMailingListRussian@forum.nginx.org> Dmytro Lavryk Wrote: ------------------------------------------------------- > Вы ошибку не описали... Но, подозреваю, делаете HEAD запрос. Проверил > у себя на аналогичном - HEAD дает 400, а вот GET отрабатывает > нормально со всеми нужными заголовками. Да, действительно, дело в типе запроса, но понять не могу почему так происходит. Напишу тут код на php, я думаю программистам других языков он будет понятен: $fp = fsockopen("test.ru", 443, $errno, $errstr, 30); $out = "GET /radio-stream HTTP/1.1\r\n"; $out .= "Host: test.ru\r\n"; $out .= "Connection: Close\r\n\r\n"; fwrite($fp, $out); while (!feof($fp)) echo fgets($fp, 128); fclose($fp); В нем я явно указываю тип запроса GET, а nginx почему говорит что к нему пришел HEAD и возвращает ответ "400 Bad Request". Проверил на разных версиях php - результат везде одинаковый, т.к. вроде как дело не в нем. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287318#msg-287318 From bgx на protva.ru Thu Mar 12 21:29:08 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 13 Mar 2020 00:29:08 +0300 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <0c5768569c1b8c66ee922518759ba7d4.NginxMailingListRussian@forum.nginx.org> References: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org> <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org> <0c5768569c1b8c66ee922518759ba7d4.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200312212908.GH14751@sie.protva.ru> On Thu, Mar 12, 2020 at 12:54:31PM -0400, grey wrote: > Dmytro Lavryk Wrote: > ------------------------------------------------------- > > Вы ошибку не описали... Но, подозреваю, делаете HEAD запрос. Проверил > > у себя на аналогичном - HEAD дает 400, а вот GET отрабатывает > > нормально со всеми нужными заголовками. > > Да, действительно, дело в типе запроса, но понять не могу почему так > происходит. Напишу тут код на php, я думаю программистам других языков он > будет понятен: > > $fp = fsockopen("test.ru", 443, $errno, $errstr, 30); > $out = "GET /radio-stream HTTP/1.1\r\n"; > $out .= "Host: test.ru\r\n"; > $out .= "Connection: Close\r\n\r\n"; > fwrite($fp, $out); > while (!feof($fp)) echo fgets($fp, 128); > fclose($fp); > > В нем я явно указываю тип запроса GET, а nginx почему говорит что к нему > пришел HEAD Откуда вывод, что nginx якобы видит HEAD? > и возвращает ответ "400 Bad Request". > Проверил на разных версиях > php - результат везде одинаковый, т.к. вроде как дело не в нем. И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен? -- Eugene Berdnikov From nginx-forum на forum.nginx.org Fri Mar 13 07:42:03 2020 From: nginx-forum на forum.nginx.org (grey) Date: Fri, 13 Mar 2020 03:42:03 -0400 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <20200312212908.GH14751@sie.protva.ru> References: <20200312212908.GH14751@sie.protva.ru> Message-ID: <9bf4aca8d527e1691e29e16c91de00b9.NginxMailingListRussian@forum.nginx.org> > Откуда вывод, что nginx якобы видит HEAD? В логах nginx видно: 95.8.*.* - - [13/Mar/2020:10:24:59 +0300] "HEAD /radio-stream HTTP/1.1" 400 0 "-" "-" При GET запросе: 95.8.*.* - - [13/Mar/2020:10:28:45 +0300] "GET /radio-stream HTTP/1.1" 200 146900 "-" "-" Сам php-код, коим проверяю: $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://test.ru/radio-stream"); curl_setopt($ch, CURLOPT_RETURNTRANSFER,1); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_NOBODY, 0); // это GET запрос #curl_setopt($ch, CURLOPT_NOBODY, 1); // это HEAD запрос curl_setopt($ch, CURLOPT_TIMEOUT, 5); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); $content=curl_exec ($ch); curl_close ($ch); > И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен? Да или я чего-то не понимаю? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287330#msg-287330 From bgx на protva.ru Fri Mar 13 08:06:34 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 13 Mar 2020 11:06:34 +0300 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <9bf4aca8d527e1691e29e16c91de00b9.NginxMailingListRussian@forum.nginx.org> References: <20200312212908.GH14751@sie.protva.ru> <9bf4aca8d527e1691e29e16c91de00b9.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200313080634.GI14751@sie.protva.ru> On Fri, Mar 13, 2020 at 03:42:03AM -0400, grey wrote: > > Откуда вывод, что nginx якобы видит HEAD? > > В логах nginx видно: > 95.8.*.* - - [13/Mar/2020:10:24:59 +0300] "HEAD /radio-stream HTTP/1.1" 400 > 0 "-" "-" > > При GET запросе: > 95.8.*.* - - [13/Mar/2020:10:28:45 +0300] "GET /radio-stream HTTP/1.1" 200 > 146900 "-" "-" > > Сам php-код, коим проверяю: > > $ch = curl_init(); > curl_setopt($ch, CURLOPT_URL, "https://test.ru/radio-stream"); Достаточно. Расстрелять. :) Это не код приложения, а вызов посторонней программы, которая выполняет СВОЙ код (а не тот, который цитировался), и вообще делает обращение с СДРУГИМ url. То есть вообще всё другое, а результат доказывает, что nginx работает правильно. > > И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен? > > Да или я чего-то не понимаю? Ага. Из того, что curl работает и приводит к осмысленным записям в логе, следует, что plain http это совсем не то, чего ждёт nginx на этом порту. Подумайте над тем, что означает буква "s" в https://... :) -- Eugene Berdnikov From nginx-forum на forum.nginx.org Mon Mar 16 07:21:53 2020 From: nginx-forum на forum.nginx.org (grey) Date: Mon, 16 Mar 2020 03:21:53 -0400 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <20200313080634.GI14751@sie.protva.ru> References: <20200313080634.GI14751@sie.protva.ru> Message-ID: <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org> Хорошо, сделал по другому - нашел несколько сторонних сервисов, в которых можно узакать УРЛ ресурса и типа запроса. Абсолютно все возвращают "HTTP/1.1 400 Bad Request". Я конечно не знаю как они работают, но неужели все такие же косорукие как и я? :) Dmytro Lavryk тоже говорит, что у него аналогичный код ответа при HEAD запросе. Может все таки что-то не так настроено у меня в nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287355#msg-287355 From chipitsine на gmail.com Mon Mar 16 07:54:33 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 16 Mar 2020 12:54:33 +0500 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org> References: <20200313080634.GI14751@sie.protva.ru> <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org> Message-ID: в последнее время какая-то странная мода игнорировать советы (кстати, они были неплохие). еще раз - "400 bad request" во многих случаях можно подсмотреть по error.log (на всякий случай запустите отладочную сборку nginx). если у вас будет 400, но в error.log тишина, то вы сузили количество возможных вариантов - можете поискать по исходному коду, такие места, где отдается 400 втихую есть, но их мало. пн, 16 мар. 2020 г. в 12:22, grey : > Хорошо, сделал по другому - нашел несколько сторонних сервисов, в которых > можно узакать УРЛ ресурса и типа запроса. Абсолютно все возвращают > "HTTP/1.1 > 400 Bad Request". Я конечно не знаю как они работают, но неужели все такие > же косорукие как и я? :) Dmytro Lavryk тоже говорит, что у него аналогичный > код ответа при HEAD запросе. > > Может все таки что-то не так настроено у меня в nginx? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287264,287355#msg-287355 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Mar 16 11:57:14 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 16 Mar 2020 14:57:14 +0300 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: References: <20200313080634.GI14751@sie.protva.ru> <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200316115714.GM12894@mdounin.ru> Hello! On Mon, Mar 16, 2020 at 12:54:33PM +0500, Илья Шипицин wrote: > еще раз - "400 bad request" во многих случаях можно подсмотреть по > error.log (на всякий случай запустите отладочную сборку nginx). > если у вас будет 400, но в error.log тишина, то вы сузили количество > возможных вариантов - можете поискать по исходному коду, > такие места, где отдается 400 втихую есть, но их мало. Если 400 вернул nginx, то в логе ошибок на уровне info должна быть причина, отладочная сборка не нужна. Если вдруг известны ситуации, в которых это не происходит - об этом стоит сообщить, ибо это ошибка. AFAIK, на текущий момент в поддерживаемых версиях подобных ошибок нет. Последняя подобная ошибка была исправлена в nginx 1.13.6, в коде HTTP/2: *) Исправление: при использовании HTTP/2 nginx мог вернуть ошибку 400, не указав в логе причину. В данном случае я бы скорее предположил, что 400 возвращает бекенд. В отладочном логе, это, безусловно, будет явно видно, но можно обойтись и без отладочной сборки: просто залоггировать $upstream_status или вообще посмотреть tcpdump между nginx'ом и бекендом. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Mar 16 12:11:43 2020 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Mon, 16 Mar 2020 08:11:43 -0400 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <20200316115714.GM12894@mdounin.ru> References: <20200316115714.GM12894@mdounin.ru> Message-ID: <0b0f83b75e7c7384899d18a9bf423b65.NginxMailingListRussian@forum.nginx.org> да, вы правы. Проверил - 400 отдает апстрим в данном случае. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287361#msg-287361 From bgx на protva.ru Mon Mar 16 12:14:10 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 16 Mar 2020 15:14:10 +0300 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <20200316115714.GM12894@mdounin.ru> References: <20200313080634.GI14751@sie.protva.ru> <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org> <20200316115714.GM12894@mdounin.ru> Message-ID: <20200316121410.GD3939@protva.ru> On Mon, Mar 16, 2020 at 02:57:14PM +0300, Maxim Dounin wrote: > В данном случае я бы скорее предположил, что 400 возвращает > бекенд. В отладочном логе, это, безусловно, будет явно видно, но В данном случае товарищ посылает plain http на 443-й порт, который, несомненно, сконфигурён как ssl, потому что curl на него ходит по https и без проблем забирает указанный radio-stream. A nginx при запросе plain http на ssl-ном порту возвращает "400 Bad Request" таким же plain http. Проверено на первом попавшемся под руку nginx-e. -- Eugene Berdnikov From mdounin на mdounin.ru Mon Mar 16 14:57:48 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 16 Mar 2020 17:57:48 +0300 Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?= =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?= In-Reply-To: <20200316121410.GD3939@protva.ru> References: <20200313080634.GI14751@sie.protva.ru> <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org> <20200316115714.GM12894@mdounin.ru> <20200316121410.GD3939@protva.ru> Message-ID: <20200316145748.GO12894@mdounin.ru> Hello! On Mon, Mar 16, 2020 at 03:14:10PM +0300, Evgeniy Berdnikov wrote: > On Mon, Mar 16, 2020 at 02:57:14PM +0300, Maxim Dounin wrote: > > В данном случае я бы скорее предположил, что 400 возвращает > > бекенд. В отладочном логе, это, безусловно, будет явно видно, но > > В данном случае товарищ посылает plain http на 443-й порт, который, > несомненно, сконфигурён как ssl, потому что curl на него ходит по https > и без проблем забирает указанный radio-stream. A nginx при запросе > plain http на ssl-ном порту возвращает "400 Bad Request" таким же > plain http. Проверено на первом попавшемся под руку nginx-e. Там, вероятно, более одной проблемы, и главная из них легко читается в первом же сообщении данного треда: человек не способен задать вопрос. В тех немногих логах, что приводились, видно, что curl нормально получает ответ на GET, но получает 400 в ответ на HEAD. И вот это уже - явно проблема бекенда, что и подтвердил Dmytro Lavryk. Моё письмо, впрочем, не про это, а про то, что если ошибку возвращает nginx - об этом явно будет в логе ошибок на уровне info, а если вдруг кто-то знает случаи, когда не будет - об этом стоит сообщить. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Mar 19 20:03:36 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 19 Mar 2020 22:03:36 +0200 Subject: Keepalives considered harmful Message-ID: Здравствуйте, All! Интересная статья в блоге Cloudflare: https://blog.cloudflare.com/keepalives-considered-harmful/ Keepalives considered harmful -- Best regards, Gena From nginx-forum на forum.nginx.org Fri Mar 20 08:39:42 2020 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Fri, 20 Mar 2020 04:39:42 -0400 Subject: UDP Connection refused In-Reply-To: <20200312123403.GH12894@mdounin.ru> References: <20200312123403.GH12894@mdounin.ru> Message-ID: Спасибо за ссылку. Многое прояснило. Да, проблема нашлась на стороне получателя. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287308,287395#msg-287395 From nginx-forum на forum.nginx.org Fri Mar 20 09:00:36 2020 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Fri, 20 Mar 2020 05:00:36 -0400 Subject: 104: Connection reset by peer Message-ID: nginx работает в качестве tcp lb Периодически получаю 104: Connection reset by peer. --- Если причинно следственная связь в системных вызовах? writev() not ready (11: Resource temporarily unavailable) recv() failed (104: Connection reset by peer) или 104 ошибку получаем из-за того что не получили сообщений от сокета для файлового дескриптора? recv: fd:96 -1 of 16384 --- 2020/03/20 04:54:21 [debug] 37456#0: *98446240 accept: 188.187.126.40:40513 fd:96 2020/03/20 04:54:21 [info] 37456#0: *98446240 client 188.187.126.40:40513 connected to 8.8.157.49:80 2020/03/20 04:54:21 [debug] 37456#0: *98446240 posix_memalign: 00005597192FA4F0:256 @16 2020/03/20 04:54:21 [debug] 37456#0: *98446240 generic phase: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 generic phase: 1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 generic phase: 2 2020/03/20 04:54:21 [debug] 37456#0: *98446240 ssl preread handler 2020/03/20 04:54:21 [debug] 37456#0: *98446240 tcp_nodelay 2020/03/20 04:54:21 [debug] 37456#0: *98446240 proxy connection handler 2020/03/20 04:54:21 [debug] 37456#0: *98446240 malloc: 00005597192FA600:416 2020/03/20 04:54:21 [debug] 37456#0: *98446240 malloc: 000055971947AB00:16384 2020/03/20 04:54:21 [debug] 37456#0: *98446240 get rr peer, try: 8 2020/03/20 04:54:21 [debug] 37456#0: *98446240 get rr peer, current: 000055971928E448 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream socket 97 2020/03/20 04:54:21 [debug] 37456#0: *98446240 epoll add connection: fd:97 ev:80002005 2020/03/20 04:54:21 [debug] 37456#0: *98446240 connect to 10.121.15.75:31001, fd:97 #98446241 2020/03/20 04:54:21 [debug] 37456#0: *98446240 proxy connect: -2 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer add: 97: 1000:155123895 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer del: 97: 155123895 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream proxy connect upstream 2020/03/20 04:54:21 [debug] 37456#0: *98446240 tcp_nodelay 2020/03/20 04:54:21 [info] 37456#0: *98446240 proxy 10.121.15.65:3564 connected to 10.121.15.75:31001 2020/03/20 04:54:21 [debug] 37456#0: *98446240 malloc: 000055971947EB10:16384 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream proxy add PROXY protocol header 2020/03/20 04:54:21 [debug] 37456#0: *98446240 posix_memalign: 00005597192FA7B0:256 @16 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 00005597192FA820, size: 51 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:0 s:51 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 51 of 51 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 0000000000000000 2020/03/20 04:54:21 [debug] 37456#0: *98446240 epoll add event: fd:96 op:1 ev:80002001 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer add: 96: 600000:155722896 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:96 259 of 16384 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 000055971947AB00, size: 259 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1 s:259 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 259 of 259 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 0000000000000000 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722896 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 8388 of 16384 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 000055971947EB10, size: 8388 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1 s:8388 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 8388 of 8388 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 0000000000000000 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722897 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722897 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 5592 of 16384 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 000055971947EB10, size: 5592 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1 s:5592 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 5592 of 5592 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 0000000000000000 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722897 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722897 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 6990 of 16384 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 000055971947EB10, size: 6990 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1 s:6990 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 6990 of 6990 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 0000000000000000 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722897 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722897 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 6990 of 16384 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 000055971947EB10, size: 6990 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1 s:6990 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 6990 of 6990 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 0000000000000000 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722897 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722897 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 5592 of 16384 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 000055971947EB10, size: 5592 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1 s:5592 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 4160 of 5592 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: -1 of 1432 2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev() not ready (11: Resource temporarily unavailable) 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 00005597192FA890 2020/03/20 04:54:21 [debug] 37456#0: *98446240 epoll add event: fd:96 op:3 ev:80002005 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722898 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722898 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 9786 of 10792 2020/03/20 04:54:21 [debug] 37456#0: *98446240 posix_memalign: 0000559719349B70:256 @16 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write old buf t:1 f:0 0000000000000000, pos 000055971947FB50, size: 1432 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 00005597194800E8, size: 9786 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1 s:11218 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 00005597192FA890 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722898 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722898 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 1006 of 1006 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write old buf t:1 f:0 0000000000000000, pos 000055971947FB50, size: 1432 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write old buf t:1 f:0 0000000000000000, pos 00005597194800E8, size: 9786 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0 0000000000000000, pos 0000559719482722, size: 1006 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1 s:12224 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter 00005597192FA890 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722898 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722898 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722898 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old: 155722896, new: 155722898 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:1, avail:1 2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:96 -1 of 16384 2020/03/20 04:54:21 [info] 37456#0: *98446240 recv() failed (104: Connection reset by peer) while proxying and reading from client, client: 188.187.126.40, server: 8.8.157.49:80, upstream: "10.121.15.75:31001", bytes from/to client:259/32120, bytes from/to upstream:44344/310 2020/03/20 04:54:21 [debug] 37456#0: *98446240 posix_memalign: 0000559719349C80:256 @16 2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:0 f:0 0000000000000000, pos 000055971947AB00, size: 0 file: 0, size: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:1 f:1 s:0 2020/03/20 04:54:21 [info] 37456#0: *98446240 client disconnected, bytes from/to client:259/32120, bytes from/to upstream:44344/310 2020/03/20 04:54:21 [debug] 37456#0: *98446240 finalize stream proxy: 200 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free rr peer 8 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 close stream proxy upstream connection: 97 2020/03/20 04:54:21 [debug] 37456#0: *98446240 reusable connection: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 finalize stream session: 200 2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream log handler 2020/03/20 04:54:21 [debug] 37456#0: *98446240 close stream connection: 96 2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer del: 96: 155722896 2020/03/20 04:54:21 [debug] 37456#0: *98446240 reusable connection: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 000055971947EB10 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 000055971947AB00 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 00005597192FA600 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 0000559719352190, unused: 8 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 00005597193522A0, unused: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 00005597192FA4F0, unused: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 00005597192FA7B0, unused: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 0000559719349B70, unused: 0 2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 0000559719349C80, unused: 128 --- буду благодарен за объяснение для слабых. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287396,287396#msg-287396 From chipitsine на gmail.com Fri Mar 20 10:11:40 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 20 Mar 2020 15:11:40 +0500 Subject: Keepalives considered harmful In-Reply-To: References: Message-ID: Речь идёт про то, что не все воркеры одинаково хороши. Но не раскрывается, почему они могут быть нехороши. Блокирущие воркеры? On Fri, Mar 20, 2020, 1:03 AM Gena Makhomed wrote: > Здравствуйте, All! > > Интересная статья в блоге Cloudflare: > > https://blog.cloudflare.com/keepalives-considered-harmful/ > > Keepalives considered harmful > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri Mar 20 10:36:02 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 20 Mar 2020 13:36:02 +0300 Subject: 104: Connection reset by peer In-Reply-To: References: Message-ID: <20200320103602.GB13008@protva.ru> On Fri, Mar 20, 2020 at 05:00:36AM -0400, inkognito0609 wrote: > nginx работает в качестве tcp lb > Периодически получаю 104: Connection reset by peer. > --- > Если причинно следственная связь в системных вызовах? > writev() not ready (11: Resource temporarily unavailable) > recv() failed (104: Connection reset by peer) > или 104 ошибку получаем из-за того что не получили сообщений от сокета для > файлового дескриптора? ECONNRESET означает, что по сети прилетел RST, что и написано текстом. Никакой связи с EAGAIN у него нет. -- Eugene Berdnikov From valery+nginxru на grid.net.ru Fri Mar 20 11:04:58 2020 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Fri, 20 Mar 2020 12:04:58 +0100 Subject: Keepalives considered harmful In-Reply-To: References: Message-ID: Там возникает дисбаланс в загрузке воркеров из-за того что часть клиентов привязаны к своим воркерам через keep-alive. Отключая keep-alive они заставляют клиентов мигрировать на менее загруженные воркеры. Описывается комуникация внутри их стэка, про что и статья. Полагаю, заголовок, нужно читать "[In some cases] keepalives considered harmful". On 20-03-20 11:11, Илья Шипицин wrote: > Речь идёт про то, что не все воркеры одинаково хороши. Но не > раскрывается, почему они могут быть нехороши. Блокирущие воркеры? > > On Fri, Mar 20, 2020, 1:03 AM Gena Makhomed > wrote: > > Здравствуйте, All! > > Интересная статья в блоге Cloudflare: > > https://blog.cloudflare.com/keepalives-considered-harmful/ > > Keepalives considered harmful -- Val From nginx-forum на forum.nginx.org Fri Mar 20 11:17:44 2020 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Fri, 20 Mar 2020 07:17:44 -0400 Subject: 104: Connection reset by peer In-Reply-To: <20200320103602.GB13008@protva.ru> References: <20200320103602.GB13008@protva.ru> Message-ID: <46111aa7d8e21dda378d47533fb4c5d7.NginxMailingListRussian@forum.nginx.org> Странно, потому что tcpdump показывает что RST отправляет именно балансер --- 11:02:29.208274 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [S], seq 1825789029, win 29200, options [mss 1460,sackOK,TS val 4257877938 ecr 0,nop,wscale 9], length 0 11:02:29.208683 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [S.], seq 2625988586, ack 1825789030, win 27960, options [mss 1410,sackOK,TS val 1022466629 ecr 4257877938,nop,wscale 9], length 0 11:02:29.208696 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 1, win 58, options [nop,nop,TS val 4257877939 ecr 1022466629], length 0 11:02:29.208713 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [P.], seq 1:50, ack 1, win 58, options [nop,nop,TS val 4257877939 ecr 1022466629], length 49 11:02:29.208904 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [P.], seq 50:309, ack 1, win 58, options [nop,nop,TS val 4257877939 ecr 1022466629], length 259 11:02:29.209045 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], ack 50, win 55, options [nop,nop,TS val 1022466630 ecr 4257877939], length 0 11:02:29.209183 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877939], length 0 11:02:29.209639 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 1:2797, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877939], length 2796 11:02:29.209642 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 2797, win 68, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0 11:02:29.209720 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 2797:6991, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877939], length 4194 11:02:29.209731 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 6991, win 85, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0 11:02:29.209817 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 6991:11185, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877939], length 4194 11:02:29.209822 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 11185, win 101, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0 11:02:29.209915 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 11185:12583, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877939], length 1398 11:02:29.209920 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 12583, win 107, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0 11:02:29.209967 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 12583:13981, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877939], length 1398 11:02:29.209973 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 13981, win 112, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0 11:02:29.210103 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 13981:20971, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877940], length 6990 11:02:29.210110 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 20971, win 140, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0 11:02:29.210147 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 20971:25165, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877940], length 4194 11:02:29.210153 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 25165, win 156, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0 11:02:29.210184 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [P.], seq 25165:27961, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877940], length 2796 11:02:29.210189 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 27961, win 167, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0 11:02:29.210211 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 27961:36349, ack 309, win 57, options [nop,nop,TS val 1022466631 ecr 4257877940], length 8388 11:02:29.210216 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 36349, win 200, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0 11:02:29.210399 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 36349:37747, ack 309, win 57, options [nop,nop,TS val 1022466631 ecr 4257877940], length 1398 11:02:29.210406 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 37747, win 205, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0 11:02:29.210431 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq 37747:48931, ack 309, win 57, options [nop,nop,TS val 1022466631 ecr 4257877940], length 11184 11:02:29.210436 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 48931, win 249, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0 11:02:29.210508 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [FP.], seq 48931:50629, ack 309, win 57, options [nop,nop,TS val 1022466631 ecr 4257877940], length 1698 11:02:29.210528 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 50630, win 255, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0 11:02:29.215540 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [R.], seq 309, ack 50630, win 255, options [nop,nop,TS val 4257877945 ecr 1022466631], length 0 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287396,287400#msg-287400 From chipitsine на gmail.com Fri Mar 20 11:36:42 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 20 Mar 2020 16:36:42 +0500 Subject: Keepalives considered harmful In-Reply-To: References: Message-ID: пт, 20 мар. 2020 г. в 16:05, Valery Kholodkov : > Там возникает дисбаланс в загрузке воркеров из-за того что часть > клиентов привязаны к своим воркерам через keep-alive. Отключая > keep-alive они заставляют клиентов мигрировать на менее загруженные > воркеры. > это я понимаю. клиент привязан к воркеру. с чего бы воркеру, к которому я привязан, деградировать по производительности ? пусть даже он и нагружен. надо еще раз перечитать )) > > Описывается комуникация внутри их стэка, про что и статья. Полагаю, > заголовок, нужно читать "[In some cases] keepalives considered harmful". > > On 20-03-20 11:11, Илья Шипицин wrote: > > Речь идёт про то, что не все воркеры одинаково хороши. Но не > > раскрывается, почему они могут быть нехороши. Блокирущие воркеры? > > > > On Fri, Mar 20, 2020, 1:03 AM Gena Makhomed > > wrote: > > > > Здравствуйте, All! > > > > Интересная статья в блоге Cloudflare: > > > > https://blog.cloudflare.com/keepalives-considered-harmful/ > > > > Keepalives considered harmful > -- > Val > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri Mar 20 13:24:43 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 20 Mar 2020 16:24:43 +0300 Subject: 104: Connection reset by peer In-Reply-To: <46111aa7d8e21dda378d47533fb4c5d7.NginxMailingListRussian@forum.nginx.org> References: <20200320103602.GB13008@protva.ru> <46111aa7d8e21dda378d47533fb4c5d7.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200320132443.GE14751@sie.protva.ru> On Fri, Mar 20, 2020 at 07:17:44AM -0400, inkognito0609 wrote: > Странно, потому что tcpdump показывает что RST отправляет именно балансер Значит, это не тот RST, а случайно попавшийся на глаза в дампе. Неудивительно, что он оказался не от того процесса, который нужен. Чтобы найти нужный, нужно сопоставлять дамп трафика и трейс системных вызовов, в том числе по отметкам времени. > 11:02:29.210528 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 50630, > win 255, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0 > 11:02:29.215540 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [R.], seq 309, > ack 50630, win 255, options [nop,nop,TS val 4257877945 ecr 1022466631], > length 0 -- Eugene Berdnikov From nginx-forum на forum.nginx.org Mon Mar 23 09:01:12 2020 From: nginx-forum на forum.nginx.org (opan) Date: Mon, 23 Mar 2020 05:01:12 -0400 Subject: =?UTF-8?B?0KLQsNC50LzQsNGD0YLRiyBwcm94eSBwYXNz?= Message-ID: <95b6d3a414d210df80592d01a2fd1d5d.NginxMailingListRussian@forum.nginx.org> У нас есть одна площадка, нжинкс принимает запросы и проксирует на бэкенд через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс. Появилась вторая площадка, мы принимаем там трафик и отправляем все на первую площадку через proxy_pass. Так же логируем здесь upstream_reponse_time и наблюдаем очень большие значения. Мы ожидали, что добавится просто летенси между новой и старой площадкой, плюс какие-то небольшие накладные расходы nginx. Но это не так, в upstream_response_time мы видим 130-150мс ( в 3.5 раз больше, чем на площадке 1). При этом, если замерять время запросов от клиента, то total_time курла примерно одинаков для обоих площадок. Как такое может быть? Почему в логах upstream_reponse_time больше в 3-4 раза, а время ответа при этом практически не меняется? Вот фрагмент конфигурации, в которой проксируем: location = /ххх { proxy_cache off; proxy_redirect off; proxy_pass_request_body on; proxy_pass_request_headers on; proxy_next_upstream off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_pass https://second.domain/xxx; proxy_http_version 1.1; proxy_set_header Connection ""; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287422,287422#msg-287422 From chipitsine на gmail.com Mon Mar 23 11:35:46 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 23 Mar 2020 16:35:46 +0500 Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?= In-Reply-To: <95b6d3a414d210df80592d01a2fd1d5d.NginxMailingListRussian@forum.nginx.org> References: <95b6d3a414d210df80592d01a2fd1d5d.NginxMailingListRussian@forum.nginx.org> Message-ID: пара моментов 1) у вас proxy_pass на https, по крайней мере первоначальный хендшейк может быть долгим (например, если клиент захочет сделать OCSP проверку). выглядит так, как будто у вас должен быть кипэлайв до бекенда, поэтому это соображение должно касаться только редких запросов 2) возможно, у вас работает буферизация запросов-ответов. попробуйте "proxy_buffering off;" и "proxy_request_buffering off;" ? пн, 23 мар. 2020 г. в 14:01, opan : > У нас есть одна площадка, нжинкс принимает запросы и проксирует на бэкенд > через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс. > Появилась вторая площадка, мы принимаем там трафик и отправляем все на > первую площадку через proxy_pass. Так же логируем здесь > upstream_reponse_time и наблюдаем очень большие значения. Мы ожидали, что > добавится просто летенси между новой и старой площадкой, плюс какие-то > небольшие накладные расходы nginx. Но это не так, в upstream_response_time > мы видим 130-150мс ( в 3.5 раз больше, чем на площадке 1). При этом, если > замерять время запросов от клиента, то total_time курла примерно одинаков > для обоих площадок. Как такое может быть? Почему в логах > upstream_reponse_time больше в 3-4 раза, а время ответа при этом > практически > не меняется? > > Вот фрагмент конфигурации, в которой проксируем: > > location = /ххх { > > proxy_cache off; > proxy_redirect off; > proxy_pass_request_body on; > proxy_pass_request_headers on; > proxy_next_upstream off; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_pass https://second.domain/xxx; > proxy_http_version 1.1; > proxy_set_header Connection ""; > > } > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287422,287422#msg-287422 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Mar 23 12:57:12 2020 From: nginx-forum на forum.nginx.org (opan) Date: Mon, 23 Mar 2020 08:57:12 -0400 Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?= In-Reply-To: References: Message-ID: <631231b8afc7a4b6e4198952506ca8ed.NginxMailingListRussian@forum.nginx.org> 1. Про ssl верно, мы замеряли сколько времени занимает установка соединения. Это 20-30мс, не больше. 2. Пробовали, не помогает Во всем этом самое странное, что время ответа через прокси и напрямую примерно одинаковое, хотя если верить upstream_response_time оно должно быть сильно больше через прокси. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287425,287428#msg-287428 From chipitsine на gmail.com Tue Mar 24 08:50:17 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 24 Mar 2020 13:50:17 +0500 Subject: duplicate Host header Message-ID: привет, вижу 400-ки на вот такое 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent duplicate host header: "Host: example.ru ", previous value: "Host: example.ru" while reading client request headers, client: X.X.X.X хост в обоих случаях одинаковый. понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну послал клиент два раза одинаковый хост. никто ж не умер. может пропускать такие запросы ? или есть какой-то риск ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Mar 24 12:51:09 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 24 Mar 2020 15:51:09 +0300 Subject: duplicate Host header In-Reply-To: References: Message-ID: <20200324125109.GD1578@mdounin.ru> Hello! On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote: > вижу 400-ки на вот такое > > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent duplicate > host header: "Host: example.ru ", previous > value: "Host: example.ru" while reading client request headers, client: > X.X.X.X > > > хост в обоих случаях одинаковый. > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну послал > клиент два раза одинаковый хост. никто ж не умер. может пропускать такие > запросы ? или есть какой-то риск ? Есть какой-то риск, даже если хосты строго одинаковые. Например такой, что "два раза одинаковый хост" - это по RFC то же самое, что "Host: example.ru, example.ru", что совсем не то же самое, что "Host: example.ru". Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230: A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value. Если очень хочется, чтобы "может пропускать", то так было с nginx 0.7.0 и до nginx 1.17.8 включительно. Начиная с nginx 1.17.9 такие запросы отклоняются. Если есть какие-то самописные клиенты, которые нарушают RFC и шлют несколько заголовков Host - нужно исправить этих клиентов. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Mar 24 13:27:57 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 24 Mar 2020 18:27:57 +0500 Subject: duplicate Host header In-Reply-To: <20200324125109.GD1578@mdounin.ru> References: <20200324125109.GD1578@mdounin.ru> Message-ID: вт, 24 мар. 2020 г. в 17:51, Maxim Dounin : > Hello! > > On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote: > > > вижу 400-ки на вот такое > > > > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent duplicate > > host header: "Host: example.ru ", previous > > value: "Host: example.ru" while reading client request headers, client: > > X.X.X.X > > > > > > хост в обоих случаях одинаковый. > > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну послал > > клиент два раза одинаковый хост. никто ж не умер. может пропускать такие > > запросы ? или есть какой-то риск ? > > Есть какой-то риск, даже если хосты строго одинаковые. Например > такой, что "два раза одинаковый хост" - это по RFC то же самое, > что "Host: example.ru, example.ru", что совсем не то же самое, что > "Host: example.ru". > > Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230: > > A server MUST respond with a 400 (Bad Request) status code to any > HTTP/1.1 request message that lacks a Host header field and to any > request message that contains more than one Host header field or a > Host header field with an invalid field-value. > > Если очень хочется, чтобы "может пропускать", то так было с nginx > 0.7.0 и до nginx 1.17.8 включительно. Начиная с nginx 1.17.9 > такие запросы отклоняются. Если есть какие-то самописные клиенты, > которые нарушают RFC и шлют несколько заголовков Host - нужно > исправить этих клиентов. > а можно настройку сделать, чтобы можно было вернуть "как было раньше" ? клиентов править, наверное, надо, но это не наша война. > > -- > 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 Tue Mar 24 13:50:01 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 24 Mar 2020 16:50:01 +0300 Subject: duplicate Host header In-Reply-To: References: <20200324125109.GD1578@mdounin.ru> Message-ID: <20200324135001.GE1578@mdounin.ru> Hello! On Tue, Mar 24, 2020 at 06:27:57PM +0500, Илья Шипицин wrote: > вт, 24 мар. 2020 г. в 17:51, Maxim Dounin : > > > Hello! > > > > On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote: > > > > > вижу 400-ки на вот такое > > > > > > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent duplicate > > > host header: "Host: example.ru ", previous > > > value: "Host: example.ru" while reading client request headers, client: > > > X.X.X.X > > > > > > > > > хост в обоих случаях одинаковый. > > > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну послал > > > клиент два раза одинаковый хост. никто ж не умер. может пропускать такие > > > запросы ? или есть какой-то риск ? > > > > Есть какой-то риск, даже если хосты строго одинаковые. Например > > такой, что "два раза одинаковый хост" - это по RFC то же самое, > > что "Host: example.ru, example.ru", что совсем не то же самое, что > > "Host: example.ru". > > > > Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230: > > > > A server MUST respond with a 400 (Bad Request) status code to any > > HTTP/1.1 request message that lacks a Host header field and to any > > request message that contains more than one Host header field or a > > Host header field with an invalid field-value. > > > > Если очень хочется, чтобы "может пропускать", то так было с nginx > > 0.7.0 и до nginx 1.17.8 включительно. Начиная с nginx 1.17.9 > > такие запросы отклоняются. Если есть какие-то самописные клиенты, > > которые нарушают RFC и шлют несколько заголовков Host - нужно > > исправить этих клиентов. > > > > а можно настройку сделать, чтобы можно было вернуть "как было раньше" ? Нет. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Mar 24 13:56:43 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 24 Mar 2020 18:56:43 +0500 Subject: duplicate Host header In-Reply-To: <20200324135001.GE1578@mdounin.ru> References: <20200324125109.GD1578@mdounin.ru> <20200324135001.GE1578@mdounin.ru> Message-ID: так а как мы бы узнали, что у нас такое есть. никакого режима "dry run" вт, 24 мар. 2020 г. в 18:51, Maxim Dounin : > Hello! > > On Tue, Mar 24, 2020 at 06:27:57PM +0500, Илья Шипицин wrote: > > > вт, 24 мар. 2020 г. в 17:51, Maxim Dounin : > > > > > Hello! > > > > > > On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote: > > > > > > > вижу 400-ки на вот такое > > > > > > > > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent > duplicate > > > > host header: "Host: example.ru ", > previous > > > > value: "Host: example.ru" while reading client request headers, > client: > > > > X.X.X.X > > > > > > > > > > > > хост в обоих случаях одинаковый. > > > > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну > послал > > > > клиент два раза одинаковый хост. никто ж не умер. может пропускать > такие > > > > запросы ? или есть какой-то риск ? > > > > > > Есть какой-то риск, даже если хосты строго одинаковые. Например > > > такой, что "два раза одинаковый хост" - это по RFC то же самое, > > > что "Host: example.ru, example.ru", что совсем не то же самое, что > > > "Host: example.ru". > > > > > > Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230: > > > > > > A server MUST respond with a 400 (Bad Request) status code to any > > > HTTP/1.1 request message that lacks a Host header field and to any > > > request message that contains more than one Host header field or a > > > Host header field with an invalid field-value. > > > > > > Если очень хочется, чтобы "может пропускать", то так было с nginx > > > 0.7.0 и до nginx 1.17.8 включительно. Начиная с nginx 1.17.9 > > > такие запросы отклоняются. Если есть какие-то самописные клиенты, > > > которые нарушают RFC и шлют несколько заголовков Host - нужно > > > исправить этих клиентов. > > > > > > > а можно настройку сделать, чтобы можно было вернуть "как было раньше" ? > > Нет. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Mar 24 16:29:28 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 24 Mar 2020 21:29:28 +0500 Subject: duplicate Host header In-Reply-To: References: <20200324125109.GD1578@mdounin.ru> <20200324135001.GE1578@mdounin.ru> Message-ID: выглядит это примерно так. живешь, живешь, думаешь, что у тебя все ок. потом обновляешься до 1.17.9, и по логам идут 400-ки. смотришь в error.log - там duplicate Host header (про который ты ранее и знать не знал, и без понятия, в чем там вообще прблема, потому что ее нет никакой) какая-то абстрактная задача запретить такие хедера, задача ради самой задачи вт, 24 мар. 2020 г. в 18:56, Илья Шипицин : > так а как мы бы узнали, что у нас такое есть. никакого режима "dry run" > > вт, 24 мар. 2020 г. в 18:51, Maxim Dounin : > >> Hello! >> >> On Tue, Mar 24, 2020 at 06:27:57PM +0500, Илья Шипицин wrote: >> >> > вт, 24 мар. 2020 г. в 17:51, Maxim Dounin : >> > >> > > Hello! >> > > >> > > On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote: >> > > >> > > > вижу 400-ки на вот такое >> > > > >> > > > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent >> duplicate >> > > > host header: "Host: example.ru ", >> previous >> > > > value: "Host: example.ru" while reading client request headers, >> client: >> > > > X.X.X.X >> > > > >> > > > >> > > > хост в обоих случаях одинаковый. >> > > > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну >> послал >> > > > клиент два раза одинаковый хост. никто ж не умер. может пропускать >> такие >> > > > запросы ? или есть какой-то риск ? >> > > >> > > Есть какой-то риск, даже если хосты строго одинаковые. Например >> > > такой, что "два раза одинаковый хост" - это по RFC то же самое, >> > > что "Host: example.ru, example.ru", что совсем не то же самое, что >> > > "Host: example.ru". >> > > >> > > Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230: >> > > >> > > A server MUST respond with a 400 (Bad Request) status code to any >> > > HTTP/1.1 request message that lacks a Host header field and to any >> > > request message that contains more than one Host header field or a >> > > Host header field with an invalid field-value. >> > > >> > > Если очень хочется, чтобы "может пропускать", то так было с nginx >> > > 0.7.0 и до nginx 1.17.8 включительно. Начиная с nginx 1.17.9 >> > > такие запросы отклоняются. Если есть какие-то самописные клиенты, >> > > которые нарушают RFC и шлют несколько заголовков Host - нужно >> > > исправить этих клиентов. >> > > >> > >> > а можно настройку сделать, чтобы можно было вернуть "как было раньше" ? >> >> Нет. >> >> -- >> 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 Mar 25 13:21:44 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 25 Mar 2020 16:21:44 +0300 Subject: duplicate Host header In-Reply-To: References: <20200324125109.GD1578@mdounin.ru> <20200324135001.GE1578@mdounin.ru> Message-ID: <20200325132144.GF1578@mdounin.ru> Hello! On Tue, Mar 24, 2020 at 09:29:28PM +0500, Илья Шипицин wrote: > выглядит это примерно так. > > живешь, живешь, думаешь, что у тебя все ок. > потом обновляешься до 1.17.9, и по логам идут 400-ки. > > смотришь в error.log - там duplicate Host header (про который ты ранее и > знать не знал, и без понятия, в чем там вообще прблема, потому что ее нет > никакой) > > какая-то абстрактная задача запретить такие хедера, задача ради самой задачи У вас мусор в заголовках запросов, прямо запрещённый RFC и потенциально приводящий к security-проблемам. В рамках очередной серии патчей, закрывающих подобные security-проблемы - требования были ужесточены, имеющийся мусор - стал приводить к 400 ошибкам. Есть ровно одно решение - мусор вычистить, но это, как тут звучало, не ваша война. Если очень хочется сохранять совместимость с имеющимся мусором - можно продолжать пользоваться предыдущими версиями и/или наколхозить локальный патч, некоторое время это будет работать. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Mar 25 13:48:10 2020 From: nginx-forum на forum.nginx.org (opan) Date: Wed, 25 Mar 2020 09:48:10 -0400 Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?= In-Reply-To: <631231b8afc7a4b6e4198952506ca8ed.NginxMailingListRussian@forum.nginx.org> References: <631231b8afc7a4b6e4198952506ca8ed.NginxMailingListRussian@forum.nginx.org> Message-ID: <730d5bd0c34dc8c1c46b74ca5b11ae13.NginxMailingListRussian@forum.nginx.org> Добрый день. В продолжение изучения проблемы обнаружили что в логе нжинкса upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump, время ответа бэка меньше 1ms: https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0 Как такое может быть? On 23.03.2020 14:35, Илья Шипицин wrote: > пара моментов > > 1) у вас proxy_pass на https, по крайней мере первоначальный хендшейк может быть долгим (например, если клиент захочет сделать OCSP проверку). выглядит так, как будто у вас > должен быть кипэлайв до бекенда, поэтому это соображение должно касаться только редких запросов > > 2) возможно, у вас работает буферизация запросов-ответов. попробуйте "proxy_buffering off;" и "proxy_request_buffering off;" ? > > пн, 23 мар. 2020 г. в 14:01, opan : > > У нас есть одна площадка, нжинкс принимает запросы и проксирует на бэкенд > через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс. > Появилась вторая площадка, мы принимаем там трафик и отправляем все на > первую площадку через proxy_pass. Так же логируем здесь > upstream_reponse_time и наблюдаем очень большие значения. Мы ожидали, что > добавится просто летенси между новой и старой площадкой, плюс какие-то > небольшие накладные расходы nginx. Но это не так, в upstream_response_time > мы видим 130-150мс ( в 3.5 раз больше, чем на площадке 1). При этом, если > замерять время запросов от клиента, то total_time курла примерно одинаков > для обоих площадок. Как такое может быть? Почему в логах > upstream_reponse_time больше в 3-4 раза, а время ответа при этом практически > не меняется? > > Вот фрагмент конфигурации, в которой проксируем: > > location = /ххх { > > proxy_cache off; > proxy_redirect off; > proxy_pass_request_body on; > proxy_pass_request_headers on; > proxy_next_upstream off; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_pass https://second.domain/xxx; > proxy_http_version 1.1; > proxy_set_header Connection ""; > > } > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287422,287422#msg-287422 > > _______________________________________________ > 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 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287425,287456#msg-287456 From bgx на protva.ru Wed Mar 25 16:09:40 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 25 Mar 2020 19:09:40 +0300 Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?= In-Reply-To: <730d5bd0c34dc8c1c46b74ca5b11ae13.NginxMailingListRussian@forum.nginx.org> References: <631231b8afc7a4b6e4198952506ca8ed.NginxMailingListRussian@forum.nginx.org> <730d5bd0c34dc8c1c46b74ca5b11ae13.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200325160940.GS14751@sie.protva.ru> On Wed, Mar 25, 2020 at 09:48:10AM -0400, opan wrote: > Добрый день. > > В продолжение изучения проблемы обнаружили что в логе нжинкса > upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump, > время ответа бэка меньше 1ms: > > https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0 > > > Как такое может быть? Ответ апстрима не обязательно помещается в один пакет, даже если у него установлен флаг PSH. Если бы отображалось содержимое пакетов, то можно было бы проверить, передан ли ответ полностью, а при наличии в дампе ответных ACKов -- утверждать, что ответ получен сервером. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Fri Mar 27 11:11:01 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Fri, 27 Mar 2020 07:11:01 -0400 Subject: =?UTF-8?B?0LLQt9Cw0LjQvNC+0LTQtdC50YHRgtCy0LjQtSBOZ2lueCDRgSBmY2dpINCR0JU=?= =?UTF-8?B?0Jcg0L/RhdC/LdGE0LDQudC70L7Qsg==?= Message-ID: Всем привет ) тут запускаю fcgi-демона, который тупо ловит строку текста от Nginx, а в ответ шлёт ему соответствующую HTML-строку... и во всех конфигах, что я нашёл в гугле, фигурируют пхп-файлы, прям везде... Но у меня нет пхп-файла. У меня висит демон и через сокет ловит строку. И эту строку я вывожу в линух-консоль (для тестов) и вижу такой текст: (тут очевидно BB-кодов нет, так что сорри, как есть...): [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41892) count = 872 data:; QUERY_STRINGREQUEST_METHODGET CONTENT_TYPECONTENT_LENGTH SCRIPT_NAME/ REQUEST_URI/ DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 SERVER_SOFTWAREnginx/1.14.2 REMOTE_ADDR127.0.0.1 REMOTE_PORT53664 SERVER_ADDR127.0.0.1 SERVER_PORT80 SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru HTTP_CONNECTIONkeep-alive HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 HTTP_ACCEPT_ENCODINGgzip, deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 4096 count = -1 return false count = 0 [I] Close 5 [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41894) count = 832 data:▒ QUERY_STRINGREQUEST_METHODGET CONTENT_TYPECONTENT_LENGTH SCRIPT_NAME/favicon.ico REQUEST_URI/favicon.ico DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 DOCUMENT_URI/favicon.ico SERVER_SOFTWAREnginx/1.14.2 REMOTE_ADDR127.0.0.1 REMOTE_PORT53664 SERVER_ADDR127.0.0.1 SERVER_PORT80 SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru HTTP_CONNECTIONkeep-alive HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8 HTTP_ACCEPT_ENCODINGgzip, deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7 4096 count = -1 return false count = 0 [I] Close 5 ну вот к этой строке у меня и возникают вопросы... 1. как видно, тут ДВАЖДЫ практически одно и то же (port=41894 - порт разный 2 раза) это 2 запроса делает браузер, или Nginx, или мой демон? 2. нет пробела между названием переменной и значением 3. а тут ещё и переноса строк нет: HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENT 4. подразумевается эти параметры обрабатывать регекспом? 5. мне столько параметров не надо, как убрать половину? 6. ОТВЕТ, который я пытаюсь записать обратно в сокет не даёт результата... Я шлю буквально следующее: HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type: text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n Прошу знающих поделиться мудростью ) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287478,287478#msg-287478 From nginx-forum на forum.nginx.org Fri Mar 27 11:15:47 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Fri, 27 Mar 2020 07:15:47 -0400 Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?= =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?= In-Reply-To: References: Message-ID: <85e76984bdd19d8bdb7d6b728efa255c.NginxMailingListRussian@forum.nginx.org> хмм, если убрать строчку "include /etc/nginx/fastcgi.conf;", то пришлёт такое: [I] Accepted connection on descriptor 5(host=127.0.0.1, port=42028) count = 504 data:� HTTP_HOSTtest1.ru HTTP_CONNECTIONkeep-alive HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 HTTP_ACCEPT_ENCODINGgzip, deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 4096 count = -1 return false count = 0 [I] Close 5 [I] Accepted connection on descriptor 5(host=127.0.0.1, port=42030) count = 432 data:� HTTP_HOSTtest1.ru HTTP_CONNECTIONkeep-alive HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8 HTTP_ACCEPT_ENCODINGgzip, deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7 4096 count = -1 return false count = 0 [I] Close 5 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287478,287479#msg-287479 From nginx-forum на forum.nginx.org Fri Mar 27 12:18:10 2020 From: nginx-forum на forum.nginx.org (opan) Date: Fri, 27 Mar 2020 08:18:10 -0400 Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?= In-Reply-To: <20200325160940.GS14751@sie.protva.ru> References: <20200325160940.GS14751@sie.protva.ru> Message-ID: Добрый день! 1. В данном случае мы видели содержимое и ответ умещался в один пакет 2. У нас есть метрики на самом бэкенде, где мы засекаем время ответа. в 90% оно составляет меньше <1 мс, в то время как 90 персентиль по логам нжинкса получается 45мс. Не может нджинкс возвращать неправильный upstream_response_time? On 3/25/20 7:09 PM, Evgeniy Berdnikov wrote: > On Wed, Mar 25, 2020 at 09:48:10AM -0400, opan wrote: >> Добрый день. >> >> В продолжение изучения проблемы обнаружили что в логе нжинкса >> upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump, >> время ответа бэка меньше 1ms: >> >> https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0 >> >> >> Как такое может быть? > > Ответ апстрима не обязательно помещается в один пакет, даже если у него > установлен флаг PSH. Если бы отображалось содержимое пакетов, то можно > было бы проверить, передан ли ответ полностью, а при наличии в дампе > ответных ACKов -- утверждать, что ответ получен сервером. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287425,287480#msg-287480 From valery+nginxru на grid.net.ru Fri Mar 27 12:30:22 2020 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Fri, 27 Mar 2020 13:30:22 +0100 Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?= =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?= In-Reply-To: References: Message-ID: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru> fastcgi вообще-то бинарный протокол. Используй libfcgi. Вот пример: https://github.com/vkholodkov/fcgi-cpp-appserver https://github.com/vkholodkov/fcgi-cpp-appserver/blob/master/src/server/fcgi_server.cpp On 27-03-20 12:11, greenwar wrote: > Всем привет ) > тут запускаю fcgi-демона, который тупо ловит строку текста от Nginx, а в > ответ шлёт ему соответствующую HTML-строку... > и во всех конфигах, что я нашёл в гугле, фигурируют пхп-файлы, прям > везде... > Но у меня нет пхп-файла. У меня висит демон и через сокет ловит строку. > И эту строку я вывожу в линух-консоль (для тестов) и вижу такой текст: > (тут очевидно BB-кодов нет, так что сорри, как есть...): > > [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41892) > count = 872 > data:; > QUERY_STRINGREQUEST_METHODGET > CONTENT_TYPECONTENT_LENGTH > SCRIPT_NAME/ > > REQUEST_URI/ > DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 > > SERVER_SOFTWAREnginx/1.14.2 > > > REMOTE_ADDR127.0.0.1 > > > REMOTE_PORT53664 > > > SERVER_ADDR127.0.0.1 > SERVER_PORT80 > SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru > HTTP_CONNECTIONkeep-alive > HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/80.0.3987.149 Safari/537.36 > HTTP_ACCEPT_ENCODINGgzip, > deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 > 4096 > count = -1 > return false > count = 0 > [I] Close 5 > [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41894) > count = 832 > data:▒ > QUERY_STRINGREQUEST_METHODGET > CONTENT_TYPECONTENT_LENGTH > > > SCRIPT_NAME/favicon.ico > > > REQUEST_URI/favicon.ico > > DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 > DOCUMENT_URI/favicon.ico > > SERVER_SOFTWAREnginx/1.14.2 > > > REMOTE_ADDR127.0.0.1 > > > REMOTE_PORT53664 > > > SERVER_ADDR127.0.0.1 > SERVER_PORT80 > SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru > HTTP_CONNECTIONkeep-alive > > HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/80.0.3987.149 Safari/537.36 > > > > 'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8 > HTTP_ACCEPT_ENCODINGgzip, > deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7 > 4096 > count = -1 > return false > count = 0 > [I] Close 5 > > > ну вот к этой строке у меня и возникают вопросы... > 1. как видно, тут ДВАЖДЫ практически одно и то же (port=41894 - порт разный > 2 раза) > это 2 запроса делает браузер, или Nginx, или мой демон? > > 2. нет пробела между названием переменной и значением > > 3. а тут ещё и переноса строк нет: > HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENT > > 4. подразумевается эти параметры обрабатывать регекспом? > > 5. мне столько параметров не надо, как убрать половину? > > 6. ОТВЕТ, который я пытаюсь записать обратно в сокет не даёт результата... Я > шлю буквально следующее: > HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type: > text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n > > Прошу знающих поделиться мудростью ) -- Val From mdounin на mdounin.ru Fri Mar 27 12:49:56 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 27 Mar 2020 15:49:56 +0300 Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?= In-Reply-To: References: <20200325160940.GS14751@sie.protva.ru> Message-ID: <20200327124956.GC3546@mdounin.ru> Hello! On Fri, Mar 27, 2020 at 08:18:10AM -0400, opan wrote: > Добрый день! > > 1. В данном случае мы видели содержимое и ответ умещался в один пакет > 2. У нас есть метрики на самом бэкенде, где мы засекаем время ответа. в 90% > оно составляет меньше <1 мс, в то время как 90 персентиль по логам нжинкса > получается 45мс. > > Не может нджинкс возвращать неправильный upstream_response_time? Тут важно понимать, что: 1. $upstream_response_time включает в себя не только получение ответа, но и отправку запроса, а также установление соединения (а равно резолвинг адресов, если он используется, и SSL handshake, если используется SSL). 2. В зависимости от конкретной формы ответа - окончание ответа может индицироваться закрытием соединения, и даже если кажется, что весь ответ "влез" в один пакет - это может быть не так, ибо ответ не закончен, пока не пришёл FIN. А FIN может придти совсем в другое время. 3. Время получения пакетов tcpdump'ом и время, когда когда эти пакеты сможет обработать приложение - это два разных времени, и они могут кардинально различаться, если сервер сильно загружен. 4. В одном рабочем процессе nginx'а обрабатывается множество соединений, так что если в том же рабочем процессе происходит что-то ещё тяжёлое (а особенно - если что-то блокирующееся, несмотря на явные рекомендации так не делать) - до конкретного соединения дело может доходить с заметной задержкой. 5. Время в nginx'е обновляется один раз за цикл обработки соединений, и если, опять же, в том же рабочем процессе происходит что-то ещё тяжёлое - время может быть неточным, даже если конкретному запросу повезло и обработка была быстрой. Что конкретно происходит у вас - неизвестно, данных для анализа недостаточно. -- Maxim Dounin http://mdounin.ru/ From pavel2000 на ngs.ru Fri Mar 27 14:08:24 2020 From: pavel2000 на ngs.ru (Pavel) Date: Fri, 27 Mar 2020 21:08:24 +0700 Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?= =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?= In-Reply-To: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru> References: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru> Message-ID: <6ad4221e-9f85-41a4-c34c-493224c9f311@ngs.ru> 27.03.2020 19:30, Valery Kholodkov пишет: > fastcgi вообще-то бинарный протокол. Используй libfcgi. Вот пример: > > https://github.com/vkholodkov/fcgi-cpp-appserver > https://github.com/vkholodkov/fcgi-cpp-appserver/blob/master/src/server/fcgi_server.cpp > Извините за оффтоп, но не подскажет ли кто готового решения простого клиента fastcgi (отправить запрос за статистикой php fpm) на pure C (ищется для использования в  Collectd модуле php-fpm). Как-то не нахожу времени самому разобраться и написать, а готового не подвернулось. Заранее благодарен. > > On 27-03-20 12:11, greenwar wrote: >> Всем привет ) >> тут запускаю fcgi-демона, который тупо ловит строку текста от Nginx, а в >> ответ шлёт ему соответствующую HTML-строку... >> и во всех конфигах, что я нашёл в гугле, фигурируют пхп-файлы, прям >> везде... >> Но у меня нет пхп-файла. У меня висит демон и через сокет ловит строку. >> И эту строку я вывожу в линух-консоль (для тестов) и вижу такой текст: >> (тут очевидно BB-кодов нет, так что сорри, как есть...): >> >> [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41892) >> count = 872 >> data:; >>        QUERY_STRINGREQUEST_METHODGET >>                                     CONTENT_TYPECONTENT_LENGTH >> SCRIPT_NAME/ >> REQUEST_URI/ >> DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 >> >>                               SERVER_SOFTWAREnginx/1.14.2 >> REMOTE_ADDR127.0.0.1 >>    REMOTE_PORT53664 >>                        SERVER_ADDR127.0.0.1 >>      SERVER_PORT80 >>                  SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru >> HTTP_CONNECTIONkeep-alive >> HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0 >> >> (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) >> Chrome/80.0.3987.149 Safari/537.36 >> HTTP_ACCEPT_ENCODINGgzip, >> deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 >> >> 4096 >> count = -1 >> return false >> count = 0 >> [I] Close 5 >> [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41894) >> count = 832 >> data:▒ >>        QUERY_STRINGREQUEST_METHODGET >>                                     CONTENT_TYPECONTENT_LENGTH >> >> SCRIPT_NAME/favicon.ico >> >>         REQUEST_URI/favicon.ico >> >> DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 >> >> DOCUMENT_URI/favicon.ico >>                               SERVER_SOFTWAREnginx/1.14.2 >> REMOTE_ADDR127.0.0.1 >>    REMOTE_PORT53664 >>                        SERVER_ADDR127.0.0.1 >>      SERVER_PORT80 >>                  SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru >> HTTP_CONNECTIONkeep-alive >> HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0 >> (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) >> Chrome/80.0.3987.149 Safari/537.36 >> 'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8 >> HTTP_ACCEPT_ENCODINGgzip, >> deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7 >> 4096 >> count = -1 >> return false >> count = 0 >> [I] Close 5 >> >> >> ну вот к этой строке у меня и возникают вопросы... >> 1. как видно, тут ДВАЖДЫ практически одно и то же (port=41894 - порт >> разный >> 2 раза) >> это 2 запроса делает браузер, или Nginx, или мой демон? >> >> 2. нет пробела между названием переменной и значением >> >> 3. а тут ещё и переноса строк нет: >> HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENT >> >> 4. подразумевается эти параметры обрабатывать регекспом? >> >> 5. мне столько параметров не надо, как убрать половину? >> >> 6. ОТВЕТ, который я пытаюсь записать обратно в сокет не даёт >> результата... Я >> шлю буквально следующее: >> HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type: >> text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n >> >> Прошу знающих поделиться мудростью ) > > From sytar.alex на gmail.com Fri Mar 27 14:50:08 2020 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Fri, 27 Mar 2020 17:50:08 +0300 Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?= =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?= In-Reply-To: References: Message-ID: пт, 27 мар. 2020 г. в 14:11, greenwar : > > > Прошу знающих поделиться мудростью ) > > http://www.mit.edu/~yandros/doc/specs/fcgi-spec.html Не благодарите. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Mar 28 07:46:27 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Sat, 28 Mar 2020 03:46:27 -0400 Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?= =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?= In-Reply-To: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru> References: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru> Message-ID: <046bddc6089c303126d605a2cc81dcf6.NginxMailingListRussian@forum.nginx.org> > fastcgi вообще-то бинарный протокол. а что именно это означает, как взаимодействие то выглядит? в fcgi_server.cpp используются файлы: #include #include но у меня таких нет и "apt install libfcgi" - их не добавил или добавил, но хз куда Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287478,287498#msg-287498 From red-fox0 на ya.ru Sat Mar 28 07:52:49 2020 From: red-fox0 на ya.ru (fox) Date: Sat, 28 Mar 2020 14:52:49 +0700 Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?= =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?= In-Reply-To: <046bddc6089c303126d605a2cc81dcf6.NginxMailingListRussian@forum.nginx.org> References: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru> <046bddc6089c303126d605a2cc81dcf6.NginxMailingListRussian@forum.nginx.org> Message-ID: <7cd25265-765d-1ad2-3290-ebea8eb98249@ya.ru> apt install libfcgi-dev 28.03.2020 14:46, greenwar пишет: >> fastcgi вообще-то бинарный протокол. > > а что именно это означает, как взаимодействие то выглядит? > в fcgi_server.cpp используются файлы: > #include > #include > > но у меня таких нет > и "apt install libfcgi" - их не добавил > или добавил, но хз куда > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287478,287498#msg-287498 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum на forum.nginx.org Sat Mar 28 10:02:15 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Sat, 28 Mar 2020 06:02:15 -0400 Subject: =?UTF-8?Q?Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?= Message-ID: наткнулся тут на интересный тред, где предлагается реализовать что-то вроде модуля под Nginx через вебсокеты: https://www.linux.org.ru/forum/development/12702791 > В курсе. Поэтому и удивляюсь, зачем нужен FastCGI, когда есть HTTP и WebSockets и соответствующие либы. Вот и возник вопрос, нужен ли FastCGI на самом деле мне... У меня изначально была мысль реализовать через модуль Nginx, но как-то отговорили... Таки что конкретно предлагается в том треде, можете пояснить, как это будет внутри Nginx выглядеть? Сейчас чтобы Nginx передал HTTP-инфу демону нужно это делать через параметр "fastcgi_pass ..." А там что предлагается? Я запутался... чтобы вебсокет создать надо HTML-код передать с JS, который этот вебсокет создаст! хм... как это всё должно работать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287500,287500#msg-287500 From nginx-forum на forum.nginx.org Sat Mar 28 22:35:58 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Sat, 28 Mar 2020 18:35:58 -0400 Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?= =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?= In-Reply-To: References: Message-ID: <85269cad112f95dcf36d9a2b0bcbe0c5.NginxMailingListRussian@forum.nginx.org> Aleksandr Sytar Wrote: ------------------------------------------------------- > пт, 27 мар. 2020 г. в 14:11, greenwar : > > > > > > > Прошу знающих поделиться мудростью ) > > > > > http://www.mit.edu/~yandros/doc/specs/fcgi-spec.html > > Не благодарите. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru читаю там: A FastCGI application calls accept() on the socket referred to by file descriptor FCGI_LISTENSOCK_FILENO to accept a new transport connection. If the accept() succeeds, and the FCGI_WEB_SERVER_ADDRS environment variable is bound, the application application immediately performs the following special processing: потом грепаю сырцы найденных в сети fcgi-серверов (с буста, с гитхаба - у меня 3 штуки) и не нахожу там таких переменных/дескрипторов вообще... КАК это всё применить к Nginx ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287478,287501#msg-287501 From valery+nginxru на grid.net.ru Mon Mar 30 09:10:29 2020 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Mon, 30 Mar 2020 11:10:29 +0200 Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?= In-Reply-To: References: Message-ID: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru> Вот и я спрашиваю: зачем тебе FastCGI если есть HTTP? FastCGI -- древний протокол, документации толком в онлайне уже похоже нет. Нужна высокая производительность? Сделай сервер на node.js или Golang, запроксируй его и будет счастие. On 28-03-20 11:02, greenwar wrote: > наткнулся тут на интересный тред, где предлагается реализовать что-то вроде > модуля под Nginx через вебсокеты: > https://www.linux.org.ru/forum/development/12702791 > >> В курсе. Поэтому и удивляюсь, зачем нужен FastCGI, когда есть HTTP и > WebSockets и соответствующие либы. > > Вот и возник вопрос, нужен ли FastCGI на самом деле мне... > У меня изначально была мысль реализовать через модуль Nginx, но как-то > отговорили... > Таки что конкретно предлагается в том треде, можете пояснить, как это будет > внутри Nginx выглядеть? > Сейчас чтобы Nginx передал HTTP-инфу демону нужно это делать через параметр > "fastcgi_pass ..." > А там что предлагается? > Я запутался... чтобы вебсокет создать надо HTML-код передать с JS, который > этот вебсокет создаст! хм... > как это всё должно работать? -- Val From nginx-forum на forum.nginx.org Mon Mar 30 10:42:14 2020 From: nginx-forum на forum.nginx.org (greenwar) Date: Mon, 30 Mar 2020 06:42:14 -0400 Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?= In-Reply-To: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru> References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru> Message-ID: <513dbcb08d15ebb206aa097f4f5d41c4.NginxMailingListRussian@forum.nginx.org> нет, не подходит ни то, ни другое нужен C/C++ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287500,287504#msg-287504