From vas на sibptus.ru Sun Apr 10 04:03:58 2022 From: vas на sibptus.ru (Victor Sudakov) Date: Sun, 10 Apr 2022 04:03:58 +0000 Subject: =?utf-8?B?0JLQvtC/0YDQvtGBINC/0YA=?= =?utf-8?B?0L4=?= ngx_http_upstream_module Message-ID: Коллеги, Когда серверу в блоке upstream ставишь параметр backup или down и делаешь nginx reload, существующие соединения к данному серверу сразу сбрасываются или им дают доработать? Можно эксперимент поставить, но вдруг кто знает ответ или документировано (а я не нашел). Заранее спасибо за ответ. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From oleg на mamontov.net Sun Apr 10 08:18:24 2022 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Sun, 10 Apr 2022 11:18:24 +0300 Subject: =?utf-8?B?0JLQvtC/0YDQvtGBINC/0YA=?= =?utf-8?B?0L4=?= ngx_http_upstream_module In-Reply-To: References: Message-ID: <20220410081824.k6g2hugnkkmxcq3m@xenon.mamontov.net> On Sun, Apr 10, 2022 at 04:03:58AM +0000, Victor Sudakov wrote: >Коллеги, > >Когда серверу в блоке upstream ставишь параметр backup или down и >делаешь nginx reload, существующие соединения к данному серверу сразу >сбрасываются или им дают доработать? После nginx reload, будут запущены новые рабочие процессы, принимающие новые соединения. Соединения, обслуживаемые старыми процессами будут жить до закрытия или до наступления worker_shutdown_timeout. >Можно эксперимент поставить, но вдруг кто знает ответ или >документировано (а я не нашел). > >Заранее спасибо за ответ. > >-- >Victor Sudakov VAS4-RIPE >http://vas.tomsk.ru/ >2:5005/49 на fidonet >_______________________________________________ >nginx-ru mailing list -- nginx-ru на nginx.org >To unsubscribe send an email to nginx-ru-leave на nginx.org -- Cheers, Oleg A. Mamontov From vas на sibptus.ru Mon Apr 11 17:35:48 2022 From: vas на sibptus.ru (Victor Sudakov) Date: Mon, 11 Apr 2022 17:35:48 +0000 Subject: =?utf-8?B?0JLQvtC/0YDQvtGBINC/0YA=?= =?utf-8?B?0L4=?= ngx_http_upstream_module In-Reply-To: <20220410081824.k6g2hugnkkmxcq3m@xenon.mamontov.net> References: <20220410081824.k6g2hugnkkmxcq3m@xenon.mamontov.net> Message-ID: Oleg A. Mamontov wrote: > > > >Когда серверу в блоке upstream ставишь параметр backup или down и > >делаешь nginx reload, существующие соединения к данному серверу сразу > >сбрасываются или им дают доработать? > > После nginx reload, будут запущены новые рабочие процессы, принимающие > новые соединения. Соединения, обслуживаемые старыми процессами будут > жить до закрытия или до наступления worker_shutdown_timeout. Спасибо большое. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49 на fidonet From izorkin на gmail.com Thu Apr 14 10:00:03 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 14 Apr 2022 13:00:03 +0300 Subject: =?windows-1251?Q?nginxQuic:_=EE=F8=E8=E1=EA=E0_ERR=5FQUIC=5FPROTOCOL=5FERROR_200?= Message-ID: <475140760.20220414130003@gmail.com> Здравствуйте На последней ревизии nginxQuic (rev 55b38514729b) столкнулся с частыми ошибками: net::ERR_QUIC_PROTOCOL_ERROR 200: [info] 29411#29411: *397 quic unknown transport param id:0x20, skipped while handling frames, client: 2600:...:123, server: [::]:443 [info] 29411#29411: *397 quic reserved transport param id:0x1c222fa830ef1ccf, skipped while handling frames, client: 2600:...:123, server: [::]:443 [info] 29411#29411: *397 quic unknown transport param id:0x3127, skipped while handling frames, client: 2600:...:123, server: [::]:443 [info] 29411#29411: *397 quic unknown transport param id:0x4752, skipped while handling frames, client: 2600:...:123, server: [::]:443 [info] 29411#29411: *397 quic unknown transport param id:0xff73db, skipped while handling frames, client: 2600:...:123, server: [::]:443 net::ERR_CONNECTION_CLOSED: [info] 29411#29411: *618 quic client timed out (110: Connection timed out) while handling quic input, client: 2600:...:123, server: [::]:443 [info] 29411#29411: *618 quic client timed out (110: Connection timed out) while handling quic input, client: 2600:...:123, server: [::]:443 Возможно, из-за большой активности на странице сайта. Если собрать nginxQuic в debug режиме, то ошибку поямать не удаётся - сайт прогружается медленно и ошибка не проявляется. nginx-ru на nginx.org -- С уважением, Izorkin mailto:izorkin на gmail.com From arut на nginx.com Thu Apr 14 13:07:03 2022 From: arut на nginx.com (Roman Arutyunyan) Date: Thu, 14 Apr 2022 17:07:03 +0400 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BS?= =?utf-8?B?T1RPQ09MX0VSUk9SIDIwMA==?= In-Reply-To: <475140760.20220414130003@gmail.com> References: <475140760.20220414130003@gmail.com> Message-ID: <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> Здравствуйте, > On 14 Apr 2022, at 2:00 PM, izorkin на gmail.com wrote: > > Здравствуйте > На последней ревизии nginxQuic (rev 55b38514729b) столкнулся с частыми ошибками: > net::ERR_QUIC_PROTOCOL_ERROR 200: > [info] 29411#29411: *397 quic unknown transport param id:0x20, skipped while handling frames, client: 2600:...:123, server: [::]:443 > [info] 29411#29411: *397 quic reserved transport param id:0x1c222fa830ef1ccf, skipped while handling frames, client: 2600:...:123, server: [::]:443 > [info] 29411#29411: *397 quic unknown transport param id:0x3127, skipped while handling frames, client: 2600:...:123, server: [::]:443 > [info] 29411#29411: *397 quic unknown transport param id:0x4752, skipped while handling frames, client: 2600:...:123, server: [::]:443 > [info] 29411#29411: *397 quic unknown transport param id:0xff73db, skipped while handling frames, client: 2600:...:123, server: [::]:443 Это не ошибки. Браузер шлет неизвестные серверу либо зарезервированные протоколом специальные транспортные параметры, что нормально. > net::ERR_CONNECTION_CLOSED: > [info] 29411#29411: *618 quic client timed out (110: Connection timed out) while handling quic input, client: 2600:...:123, server: [::]:443 > [info] 29411#29411: *618 quic client timed out (110: Connection timed out) while handling quic input, client: 2600:...:123, server: [::]:443 Это таймаут на квиковом соединении, что тоже не ошибка. > Возможно, из-за большой активности на странице сайта. Думаю, это не связано с нагрузкой. А раньше такого не было? > Если собрать nginxQuic в debug режиме, то ошибку поямать не удаётся - сайт прогружается медленно и ошибка не проявляется. > > > nginx-ru на nginx.org > > -- > С уважением, > Izorkin mailto:izorkin на gmail.com > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org ---- Roman Arutyunyan arut на nginx.com From izorkin на gmail.com Thu Apr 14 13:43:43 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 14 Apr 2022 16:43:43 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BST1RPQ09MX0VSUk9SIDIw?= =?utf-8?B?MA==?= In-Reply-To: <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> References: <475140760.20220414130003@gmail.com> <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> Message-ID: <1368421569.20220414164343@gmail.com> Здравствуйте, Roman. Раньше проверить небыло возможности, так как не работал вход на сайт с использованием HTTP3 - возникала ошибка с cookies. В основном ошибка возникает на файлах с картинками. Так же, после активном промотки страницы браузер переключается на HTTP2 протокол. Через некоторое врмя запросы по HTTP3 протоколу возобновляются. Конфигурация сайта: upstream backend-mastodon-streaming { server unix:/run/mastodon-streaming/streaming.socket; } upstream backend-mastodon-web { server unix:/run/mastodon-web/web.socket; } ... server { server_name ...; listen 0.0.0.0:443 http3 ; listen 0.0.0.0:443 http2 ssl ; listen [::0]:443 http3 ; listen [::0]:443 http2 ssl ; ssl_certificate /var/lib/acme/.../fullchain.pem; ssl_certificate_key /var/lib/acme/.../key.pem; ssl_trusted_certificate /var/lib/acme/.../chain.pem; ssl_conf_command Options KTLS; add_header Alt-Svc 'h3=":443"; ma=86400' always; add_header Strict-Transport-Security "max-age=31536000" always; vhost_traffic_status_filter_by_set_key $uri uris::$server_name; root /nix/store/4rk22387ml1d48kjcgralhlq0wbzqkly-mastodon-3.5.1/public/; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; location / { try_files $uri @proxy; } location /emoji/ { try_files $uri @proxy; add_header Cache-Control "public, max-age=604800, immutable"; add_header Strict-Transport-Security "max-age=31536000"; add_header Alt-Svc 'h3=":443"; ma=86400'; } location /packs/ { try_files $uri @proxy; add_header Cache-Control "public, max-age=604800, immutable"; add_header Strict-Transport-Security "max-age=31536000"; add_header Alt-Svc 'h3=":443"; ma=86400'; } location /system/ { try_files $uri @proxy; add_header Cache-Control "public, max-age=604800, immutable"; add_header Strict-Transport-Security "max-age=31536000"; add_header Alt-Svc 'h3=":443"; ma=86400'; alias /var/lib/mastodon/public-system/; } location /sw.js { try_files $uri @proxy; add_header Cache-Control "public, max-age=0"; add_header Strict-Transport-Security "max-age=31536000"; add_header Alt-Svc 'h3=":443"; ma=86400'; } location /api/v1/streaming/ { proxy_pass http://backend-mastodon-streaming; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Proxy ""; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_buffering off; proxy_redirect off; proxy_http_version 1.1; proxy_send_timeout 90s; proxy_read_timeout 90s; vhost_traffic_status_filter_by_set_key $upstream_addr upstream::backend-mastodon-streaming; } location /.well-known/acme-challenge { root /var/lib/acme/acme-challenge; auth_basic off; } location @proxy { proxy_pass http://backend-mastodon-web; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Proxy ""; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_pass_header Server; proxy_buffering on; proxy_redirect off; proxy_http_version 1.1; proxy_cache CACHE; proxy_cache_valid 200 7d; proxy_cache_valid 410 24h; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_hide_header Vary; proxy_hide_header Strict-Transport-Security; add_header X-Cached $upstream_cache_status; add_header Strict-Transport-Security "max-age=31536000" always; add_header Alt-Svc 'h3=":443"; ma=86400'; vhost_traffic_status_filter_by_set_key $upstream_addr upstream::backend-mastodon-web; } error_page 500 501 502 503 504 /500.html; } -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Sun Apr 17 09:33:18 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sun, 17 Apr 2022 12:33:18 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BST1RPQ09MX0VSUk9SIDIw?= =?utf-8?B?MA==?= In-Reply-To: <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> References: <475140760.20220414130003@gmail.com> <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> Message-ID: <1027043822.20220417123318@gmail.com> Здравствуйте, Roman. Проверил на ревизиях c37ea624c307, 10522e8dea41, 118a34e32121 - проблема сохраняется. По HTTP3 протоколу иногда не загружаются картинки и перриодически сбрасываются соединения до HTTP2 протокола. Может найдётся ещё один вариант дебага, без пересборки nginxQuic? -- С уважением, Izorkin mailto:izorkin на gmail.com From arut на nginx.com Sun Apr 17 12:11:38 2022 From: arut на nginx.com (Roman Arutyunyan) Date: Sun, 17 Apr 2022 16:11:38 +0400 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BS?= =?utf-8?B?T1RPQ09MX0VSUk9SIDIwMA==?= In-Reply-To: <1027043822.20220417123318@gmail.com> References: <475140760.20220414130003@gmail.com> <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> <1027043822.20220417123318@gmail.com> Message-ID: <53B44739-29CE-4E7D-BEFD-139F2CE10527@nginx.com> Добрый день, А вы можете прислать (можно мне лично) полный error.log всего соединения? А также, если есть, кусок лога Хрома - может там есть какие-то подробности по первой ошибке. Вторая (таймаут) вопросов не вызывает. > On 17 Apr 2022, at 13:33, izorkin на gmail.com wrote: > > Здравствуйте, Roman. > > Проверил на ревизиях c37ea624c307, 10522e8dea41, 118a34e32121 - проблема сохраняется. > По HTTP3 протоколу иногда не загружаются картинки и перриодически сбрасываются соединения до HTTP2 протокола. > > Может найдётся ещё один вариант дебага, без пересборки nginxQuic? > > > -- > С уважением, > Izorkin mailto:izorkin на gmail.com > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org — Roman Arutyunyan arut на nginx.com ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From izorkin на gmail.com Sun Apr 17 16:13:18 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sun, 17 Apr 2022 19:13:18 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BST1RPQ09MX0VSUk9SIDIw?= =?utf-8?B?MA==?= In-Reply-To: <53B44739-29CE-4E7D-BEFD-139F2CE10527@nginx.com> References: <475140760.20220414130003@gmail.com> <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> <1027043822.20220417123318@gmail.com> <53B44739-29CE-4E7D-BEFD-139F2CE10527@nginx.com> Message-ID: <309525270.20220417191318@gmail.com> Вложение в формате HTML было извлечено… URL: From arut на nginx.com Mon Apr 18 12:06:16 2022 From: arut на nginx.com (Roman Arutyunyan) Date: Mon, 18 Apr 2022 16:06:16 +0400 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BS?= =?utf-8?B?T1RPQ09MX0VSUk9SIDIwMA==?= In-Reply-To: <309525270.20220417191318@gmail.com> References: <475140760.20220414130003@gmail.com> <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> <1027043822.20220417123318@gmail.com> <53B44739-29CE-4E7D-BEFD-139F2CE10527@nginx.com> <309525270.20220417191318@gmail.com> Message-ID: <5822067E-AB86-4075-BEA4-0AF6484B6174@nginx.com> Добрый день, Судя по логу, у вас задан keepalive_requests 128. В http/3 это значение ограничивает число реквест-стримов на одно квиковое соединение. В вашем случае Хром в него упирается. Далее сервер шлет goaway и режектит последующие стримы. Это совершенно нормальное поведение, клиент должен такое понимать. Ожидаемое поведение клиента - пересоздание соединения и стримов. Вероятно, Хром недоволен такими режектами. Попробуйте увеличить keepalive_requests для http/3. При этом важно учесть, что эту директиву надо задать на уровне server или выше, иначе на http/3 она не подействует. > On 17 Apr 2022, at 8:13 PM, izorkin на gmail.com wrote: > > Здравствуйте, Roman. > > Отправил ссылку на файл с логами на личную почту. > > Вы писали 17 апреля 2022 г., 15:11:38: > > > Добрый день, > > А вы можете прислать (можно мне лично) полный error.log всего соединения? > А также, если есть, кусок лога Хрома - может там есть какие-то подробности по первой ошибке. > Вторая (таймаут) вопросов не вызывает. > > > — > Roman Arutyunyan > arut на nginx.com > > -- > С уважением, > Izorkin mailto:izorkin на gmail.com _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org ---- Roman Arutyunyan arut на nginx.com ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Apr 18 12:20:50 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 18 Apr 2022 17:20:50 +0500 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BST1RPQ09MX0VSUk9SIA==?= =?UTF-8?B?MjAw?= In-Reply-To: <5822067E-AB86-4075-BEA4-0AF6484B6174@nginx.com> References: <475140760.20220414130003@gmail.com> <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> <1027043822.20220417123318@gmail.com> <53B44739-29CE-4E7D-BEFD-139F2CE10527@nginx.com> <309525270.20220417191318@gmail.com> <5822067E-AB86-4075-BEA4-0AF6484B6174@nginx.com> Message-ID: есть вот такие conformance tests QUIC Interop Runner (seemann.io) интересно, кейс с хромом и 128 кипэлайв запросами покрывается ими ? может им зарепортить ? пн, 18 апр. 2022 г. в 17:07, Roman Arutyunyan : > Добрый день, > > Судя по логу, у вас задан keepalive_requests 128. В http/3 это значение > ограничивает число реквест-стримов на одно квиковое соединение. В вашем > случае Хром в него упирается. Далее сервер шлет goaway и режектит > последующие стримы. Это совершенно нормальное поведение, клиент должен > такое понимать. Ожидаемое поведение клиента - пересоздание соединения и > стримов. Вероятно, Хром недоволен такими режектами. Попробуйте увеличить > keepalive_requests для http/3. При этом важно учесть, что эту директиву > надо задать на уровне server или выше, иначе на http/3 она не подействует. > > On 17 Apr 2022, at 8:13 PM, izorkin на gmail.com wrote: > > Здравствуйте, Roman. > > Отправил ссылку на файл с логами на личную почту. > > Вы писали 17 апреля 2022 г., 15:11:38: > > > Добрый день, > > А вы можете прислать (можно мне лично) полный error.log всего соединения? > А также, если есть, кусок лога Хрома - может там есть какие-то подробности > по первой ошибке. > Вторая (таймаут) вопросов не вызывает. > > > — > Roman Arutyunyan > arut на nginx.com > > > > *-- С уважением, Izorkin * > mailto:izorkin на gmail.com > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > ---- > Roman Arutyunyan > arut на nginx.com > > > > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From izorkin на gmail.com Mon Apr 18 13:38:55 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Mon, 18 Apr 2022 16:38:55 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BST1RPQ09MX0VSUk9SIDIw?= =?utf-8?B?MA==?= In-Reply-To: References: <475140760.20220414130003@gmail.com> <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> <1027043822.20220417123318@gmail.com> <53B44739-29CE-4E7D-BEFD-139F2CE10527@nginx.com> <309525270.20220417191318@gmail.com> <5822067E-AB86-4075-BEA4-0AF6484B6174@nginx.com> Message-ID: <6775578.20220418163855@gmail.com> Вложение в формате HTML было извлечено… URL: From izorkin на gmail.com Tue Apr 19 12:37:51 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Tue, 19 Apr 2022 15:37:51 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L7RiNC40LHQutCwIEVSUl9RVUlDX1BST1RPQ09MX0VSUk9SIDIw?= =?utf-8?B?MA==?= In-Reply-To: <5822067E-AB86-4075-BEA4-0AF6484B6174@nginx.com> References: <475140760.20220414130003@gmail.com> <7BDA24B8-A49F-420A-8126-8C8F2F3C39B1@nginx.com> <1027043822.20220417123318@gmail.com> <53B44739-29CE-4E7D-BEFD-139F2CE10527@nginx.com> <309525270.20220417191318@gmail.com> <5822067E-AB86-4075-BEA4-0AF6484B6174@nginx.com> Message-ID: <614057233.20220419153751@gmail.com> Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Apr 23 22:56:35 2022 From: nginx-forum на forum.nginx.org (budarin) Date: Sat, 23 Apr 2022 18:56:35 -0400 Subject: =?UTF-8?Q?keepAliveTimeout=20=D0=B4=D0=BB=D1=8F=20Nginx=20=D0=B8=20?= =?UTF-8?Q?=D0=B4=D0=BB=D1=8F=20=D1=81=D0=B5=D1=80=D0=B2=D0=B5=D1=80?= =?UTF-8?Q?=D0=B0=20=D0=B2=20upstream?= Message-ID: <57ddefd3aef53f5ee4558dfc1263ee4c.NginxMailingListRussian@forum.nginx.org> Добрый день! Хотелось бы понять суть и установить верные значения keepAliveTimeout как для Nginx так и для серверов в upstream. Каково вообще оптимальное значение этого параметра для клиента в браузере для обычного web-приложения в Nginx? Удерживает ли Nginx alive соединение с серверами в upstream? Какими должны быть эти значения чтобы оптимально - держать открытыми только "живые соединения" и оперативно закрывать не активные чтобы не держать кучу соединений - оптимально позволять загружать запросами инстансы в upstream если Nginx не держит постоянного соединения с конкретным upstream, то понятно что параметр keepAliveTimeout в инстансе сервиса должен быть минимальным чтобы Nginx мог равномерно распределить нагрузку между несколькими серверами upstream если же Nginx держит постоянное соединение с сервером upstream то насколько я понимаю параметр keepAliveTimeout у них должен быть одинаковым? или может не париться и держать все соединения живыми максимально долго? Проясните пожалуйста ситуацию. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294036,294036#msg-294036 From chipitsine на gmail.com Sun Apr 24 03:51:41 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 24 Apr 2022 08:51:41 +0500 Subject: =?UTF-8?B?UmU6IGtlZXBBbGl2ZVRpbWVvdXQg0LTQu9GPIE5naW54INC4INC00LvRjyDRgdC10YDQsg==?= =?UTF-8?B?0LXRgNCwINCyIHVwc3RyZWFt?= In-Reply-To: <57ddefd3aef53f5ee4558dfc1263ee4c.NginxMailingListRussian@forum.nginx.org> References: <57ddefd3aef53f5ee4558dfc1263ee4c.NginxMailingListRussian@forum.nginx.org> Message-ID: можно начать с Overcoming Ephemeral Port Exhaustion in NGINX Plus вс, 24 апр. 2022 г. в 03:57, budarin : > Добрый день! > > Хотелось бы понять суть и установить верные значения keepAliveTimeout как > для Nginx так и для серверов в upstream. > > Каково вообще оптимальное значение этого параметра для клиента в браузере > для обычного web-приложения в Nginx? > > Удерживает ли Nginx alive соединение с серверами в upstream? > > Какими должны быть эти значения чтобы оптимально > - держать открытыми только "живые соединения" и оперативно закрывать не > активные чтобы не держать кучу соединений > - оптимально позволять загружать запросами инстансы в upstream > > если Nginx не держит постоянного соединения с конкретным upstream, то > понятно что параметр keepAliveTimeout в инстансе сервиса должен быть > минимальным чтобы Nginx мог равномерно распределить нагрузку между > несколькими серверами upstream > > если же Nginx держит постоянное соединение с сервером upstream то насколько > я понимаю параметр keepAliveTimeout у них должен быть одинаковым? > > или может не париться и держать все соединения живыми максимально долго? > > Проясните пожалуйста ситуацию. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,294036,294036#msg-294036 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Apr 24 21:30:26 2022 From: nginx-forum на forum.nginx.org (budarin) Date: Sun, 24 Apr 2022 17:30:26 -0400 Subject: =?UTF-8?Q?Re:=20keepAliveTimeout=20=D0=B4=D0=BB=D1=8F=20Nginx=20=D0?= =?UTF-8?Q?=B8=20=D0=B4=D0=BB=D1=8F=20=D1=81=D0=B5=D1=80=D0=B2=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=20=D0=B2=20upstream?= In-Reply-To: References: Message-ID: <2bdb92d4792a1b3ebb6f5d04eed0bb77.NginxMailingListRussian@forum.nginx.org> с эфимерными портами все понятно вопрос в другом: Nginx имеет настройку keepAliveTimeout для браузера, при этом он устанавливает соединение с upstream сервером у которого есть свои настройки keepAliveTimeout - как все это связано между собой? как Nginx работает с соединениями в upstream (также как браузер с сервером т.е. держит его до истечения keepAliveTimeout или закрывает его сразу по завершению запроса)? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294036,294041#msg-294041 From chipitsine на gmail.com Mon Apr 25 05:09:32 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 25 Apr 2022 10:09:32 +0500 Subject: =?UTF-8?B?UmU6IGtlZXBBbGl2ZVRpbWVvdXQg0LTQu9GPIE5naW54INC4INC00LvRjyDRgdC10YDQsg==?= =?UTF-8?B?0LXRgNCwINCyIHVwc3RyZWFt?= In-Reply-To: <2bdb92d4792a1b3ebb6f5d04eed0bb77.NginxMailingListRussian@forum.nginx.org> References: <2bdb92d4792a1b3ebb6f5d04eed0bb77.NginxMailingListRussian@forum.nginx.org> Message-ID: я не совсем про порты. это скорее был пример, какая документация вспомнилась про эту тему. может и лучше есть. в принципе пасьянс складывается примерно из следующих компонентов (киньте ссылку, если есть готовая документация, сохраню себе) 1) если вы описываете upstream без keepalive, то соединение закрывается каждый раз 2) максимальное число запросов в рамках одного соединения до апстрима Модуль ngx_http_core_module (nginx.org) - если вы пишете тут миллиард, будьте готовы, что на релоаде у вас старые воркеры будут честно пытаться доработать миллиард запросов, и, вероятно, вам придется их гасить через Основная функциональность (nginx.org) (но эта штука порвет прямо на лету, лучше все таки честно доработать 1000 и аккуратно погасить воркер) 3) в апстрим есть параметр keepalive, это размер пула поддерживаемых соединений. скажем, вы указали 10, если одновременно уже открыто 5, и все заняты, то открывается еще одно, и после запроса оно добавляется в пул. держать в пуле имеет смысл размер burst-а, на сколько вы можете прирасти запросами. укажете миллиард, будет держать миллиард. смысла, как правило, нет. 5-10 обычно норм 4) по умолчанию (с отключенным keepalive и на http/1.0), nginx правильно отрабатывает linger-соединения. это когда апстрим закрывает соединение RST, и порт освобождается мгновенно (актуально при reconnect storm-ах). с включенным keepalive порт на стороне nginx отрабатывает в логике, как если бы пришел FIN. может быть больно на штормах 5) с точки зрения большой картинки, на долговыполняющихся запросах надо аккуратно согласовывать таймауты по всей цепочке- чтобы браузер/ajax ждал дольше, чем nginx, nginx дольше, чем апстрим. это примерно proxy_read_timeout 6) если у вас в апстриме несколько бекендов, то дефолтный 60-секундный proxy_connect_timeout наверное, неоптимален, можно уменьшать до 5мс (на 100 мегабитной сети RTT менее 1мс) 7) если бекенды равноправны, то max_fails можно и нужно делать равным нулю. эта настройка предназначена, чтобы на какое-то время внести бекенд в грейлист. если у вас к примеру 1% сетевых потерь, то на относительно невысоком рейте все бекенды кроме последнего будут (не по своей вине) в грейлисте. текстом это тяжело воспринимать. буду благодарен, если где-то это уже документировано с картинками и примерами (ну или надо заняться и сделать) пн, 25 апр. 2022 г. в 02:31, budarin : > с эфимерными портами все понятно > > вопрос в другом: Nginx имеет настройку keepAliveTimeout для браузера, при > этом он устанавливает соединение с upstream сервером у которого есть свои > настройки keepAliveTimeout - как все это связано между собой? как Nginx > работает с соединениями в upstream (также как браузер с сервером т.е. > держит > его до истечения keepAliveTimeout или закрывает его сразу по завершению > запроса)? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,294036,294041#msg-294041 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Apr 25 05:16:02 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 25 Apr 2022 10:16:02 +0500 Subject: =?UTF-8?B?UmU6IGtlZXBBbGl2ZVRpbWVvdXQg0LTQu9GPIE5naW54INC4INC00LvRjyDRgdC10YDQsg==?= =?UTF-8?B?0LXRgNCwINCyIHVwc3RyZWFt?= In-Reply-To: References: <2bdb92d4792a1b3ebb6f5d04eed0bb77.NginxMailingListRussian@forum.nginx.org> Message-ID: я сознательно опустил моменты, описанные в ephemeral ports exhaustion. в большой картине мира с кипэлайвами, та часть документации тоже имеет значение пн, 25 апр. 2022 г. в 10:09, Илья Шипицин : > я не совсем про порты. это скорее был пример, какая документация > вспомнилась про эту тему. может и лучше есть. > > > в принципе пасьянс складывается примерно из следующих компонентов (киньте > ссылку, если есть готовая документация, сохраню себе) > > 1) если вы описываете upstream без keepalive, то соединение закрывается > каждый раз > 2) максимальное число запросов в рамках одного соединения до апстрима Модуль > ngx_http_core_module (nginx.org) > - > если вы пишете тут миллиард, будьте готовы, что на релоаде у вас старые > воркеры будут честно пытаться доработать миллиард запросов, и, вероятно, > вам придется их гасить через Основная функциональность (nginx.org) > (но > эта штука порвет прямо на лету, лучше все таки честно доработать 1000 и > аккуратно погасить воркер) > 3) в апстрим есть параметр keepalive, это размер пула поддерживаемых > соединений. скажем, вы указали 10, если одновременно уже открыто 5, и все > заняты, то открывается еще одно, и после запроса оно добавляется в пул. > держать в пуле имеет смысл размер burst-а, на сколько вы можете прирасти > запросами. укажете миллиард, будет держать миллиард. смысла, как правило, > нет. 5-10 обычно норм > 4) по умолчанию (с отключенным keepalive и на http/1.0), nginx правильно > отрабатывает linger-соединения. это когда апстрим закрывает соединение RST, > и порт освобождается мгновенно (актуально при reconnect storm-ах). с > включенным keepalive порт на стороне nginx отрабатывает в логике, как если > бы пришел FIN. может быть больно на штормах > 5) с точки зрения большой картинки, на долговыполняющихся запросах надо > аккуратно согласовывать таймауты по всей цепочке- чтобы браузер/ajax ждал > дольше, чем nginx, nginx дольше, чем апстрим. это примерно > proxy_read_timeout > 6) если у вас в апстриме несколько бекендов, то дефолтный 60-секундный > proxy_connect_timeout наверное, неоптимален, можно уменьшать до 5мс (на 100 > мегабитной сети RTT менее 1мс) > 7) если бекенды равноправны, то max_fails можно и нужно делать равным > нулю. эта настройка предназначена, чтобы на какое-то время внести бекенд в > грейлист. если у вас к примеру 1% сетевых потерь, то на относительно > невысоком рейте все бекенды кроме последнего будут (не по своей вине) в > грейлисте. > > текстом это тяжело воспринимать. буду благодарен, если где-то это уже > документировано с картинками и примерами (ну или надо заняться и сделать) > > пн, 25 апр. 2022 г. в 02:31, budarin : > >> с эфимерными портами все понятно >> >> вопрос в другом: Nginx имеет настройку keepAliveTimeout для браузера, при >> этом он устанавливает соединение с upstream сервером у которого есть свои >> настройки keepAliveTimeout - как все это связано между собой? как Nginx >> работает с соединениями в upstream (также как браузер с сервером т.е. >> держит >> его до истечения keepAliveTimeout или закрывает его сразу по завершению >> запроса)? >> >> Posted at Nginx Forum: >> https://forum.nginx.org/read.php?21,294036,294041#msg-294041 >> >> _______________________________________________ >> nginx-ru mailing list -- nginx-ru на nginx.org >> To unsubscribe send an email to nginx-ru-leave на nginx.org >> > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Apr 26 20:03:27 2022 From: nginx-forum на forum.nginx.org (budarin) Date: Tue, 26 Apr 2022 16:03:27 -0400 Subject: =?UTF-8?Q?Re:=20keepAliveTimeout=20=D0=B4=D0=BB=D1=8F=20Nginx=20=D0?= =?UTF-8?Q?=B8=20=D0=B4=D0=BB=D1=8F=20=D1=81=D0=B5=D1=80=D0=B2=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=20=D0=B2=20upstream?= In-Reply-To: References: Message-ID: <3e225b6804e7e5141ae94465fd184338.NginxMailingListRussian@forum.nginx.org> Ух! забористо :) спасибо за подробное описание - правда я, как чайник, сразу все не осилю: скажу что сложности в понимании и настройки keepAlive для связки браузер-nginx-гupstreams стало больше Хорошо бы если было бы описание на примере разбора и установки параметров для всей цепочки Со стороны браузера хотелось бы разумного keepAlive, а на бэкэнде хочется равномерного распределения нагрузки между всеми хостами в апстриме без удержания постоянных соединений Был бы очень благодарен за разбор на примере - можно было бы оформить потом в статью чтобы было полезно всем - я думаю многие с этим сталкиваются но мало кто реально понимает и правильно настраивает такую связку для keepAlive Тема нигде толком не освещена - перечитал весь интернет Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294036,294053#msg-294053 From nginx-forum на forum.nginx.org Wed Apr 27 07:17:50 2022 From: nginx-forum на forum.nginx.org (alexander_st) Date: Wed, 27 Apr 2022 03:17:50 -0400 Subject: =?UTF-8?Q?=D0=9C=D1=83=D1=81=D0=BE=D1=80=D0=BD=D1=8B=D0=B5=20=D0=B7?= =?UTF-8?Q?=D0=B0=D0=BF=D1=80=D0=BE=D1=81=D1=8B?= Message-ID: Добрый день. Можно ли на основе лога типа такого 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: "*" 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: "*" 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: "*" 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: "*" 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: "*" отправлять адреса в бан? Только сторонним парсингом лога? Понятно, что правилом на такие запросы (не GET, не POST) отдаю 444. Плюс настроены ограничения зон. Плюс стоит fail2ban. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294057,294057#msg-294057 From bgx на protva.ru Wed Apr 27 07:27:07 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 27 Apr 2022 10:27:07 +0300 Subject: =?utf-8?B?0JzRg9GB0L7RgNC90YvQtSDQt9Cw?= =?utf-8?B?0L/RgNC+0YHRiw==?= In-Reply-To: References: Message-ID: On Wed, Apr 27, 2022 at 03:17:50AM -0400, alexander_st wrote: > Добрый день. > Можно ли на основе лога типа такого > > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: > "*" ... > отправлять адреса в бан? Только сторонним парсингом лога? > Понятно, что правилом на такие запросы (не GET, не POST) отдаю 444. Плюс > настроены ограничения зон. Плюс стоит fail2ban. Вы уж определитесь, о чём хотите спросить... Если "на основе лога", то да, парсингом и сторонней утилитой, типа fail2ban. Если на лету, то сначала нужно сформулировать критерии, по которым следует включать блокировку, а потом для выбранных запросов сделать перенаправление в обработчик запроса и написать сам обработчик, делающий блокировку. -- Eugene Berdnikov From raven_kg на megaline.kg Wed Apr 27 07:37:17 2022 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Wed, 27 Apr 2022 13:37:17 +0600 Subject: =?UTF-8?B?UmU6INCc0YPRgdC+0YDQvdGL0LUg0LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: References: Message-ID: <14517499-0094-62b3-bbef-2974c0b9b1fc@megaline.kg> Если "на основе лога", то да - fail2ban самое оно. Выписать эти запросы в отдельный лог и скормить его специально обученному fail2ban-ну))) А если не "на основе лога", то либо 444 возвращать, либо внедрять в конфиг логику (например на lua) 27.04.2022 13:17, alexander_st пишет: > Добрый день. > Можно ли на основе лога типа такого > > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: > "*" > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: > "*" > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: > "*" > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: > "*" > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", host: > "*" > > отправлять адреса в бан? Только сторонним парсингом лога? > Понятно, что правилом на такие запросы (не GET, не POST) отдаю 444. Плюс > настроены ограничения зон. Плюс стоит fail2ban. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294057,294057#msg-294057 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From chipitsine на gmail.com Wed Apr 27 08:18:33 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 27 Apr 2022 13:18:33 +0500 Subject: =?UTF-8?B?UmU6INCc0YPRgdC+0YDQvdGL0LUg0LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: References: Message-ID: если у вас "access forbidden by rule", то по сути вы и так эти запросы блокируете (на уровне nginx, не iptables). можно сделать "access_log off;" и забыть ср, 27 апр. 2022 г. в 12:18, alexander_st : > Добрый день. > Можно ли на основе лога типа такого > > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", > host: > "*" > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", > host: > "*" > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", > host: > "*" > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", > host: > "*" > 2022/04/11 10:43:38 [error] 4465#4465: *969587 access forbidden by rule, > client: 45.160.168.238, server: *, request: "ST /category-s HTTP/1.1", > host: > "*" > > отправлять адреса в бан? Только сторонним парсингом лога? > Понятно, что правилом на такие запросы (не GET, не POST) отдаю 444. Плюс > настроены ограничения зон. Плюс стоит fail2ban. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,294057,294057#msg-294057 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Apr 27 08:48:04 2022 From: nginx-forum на forum.nginx.org (alexander_st) Date: Wed, 27 Apr 2022 04:48:04 -0400 Subject: =?UTF-8?Q?Re:=20=D0=9C=D1=83=D1=81=D0=BE=D1=80=D0=BD=D1=8B=D0=B5=20?= =?UTF-8?Q?=D0=B7=D0=B0=D0=BF=D1=80=D0=BE=D1=81=D1=8B?= In-Reply-To: References: Message-ID: <523e5ca0e9af11f78abf0bf8fa59a3fd.NginxMailingListRussian@forum.nginx.org> Всем спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294057,294061#msg-294061 From nginx-forum на forum.nginx.org Wed Apr 27 08:52:59 2022 From: nginx-forum на forum.nginx.org (alexander_st) Date: Wed, 27 Apr 2022 04:52:59 -0400 Subject: =?UTF-8?Q?Re:=20=D0=9C=D1=83=D1=81=D0=BE=D1=80=D0=BD=D1=8B=D0=B5=20?= =?UTF-8?Q?=D0=B7=D0=B0=D0=BF=D1=80=D0=BE=D1=81=D1=8B?= In-Reply-To: References: Message-ID: <6c38ce433c60b6f38c317fb63cac9c87.NginxMailingListRussian@forum.nginx.org> Илья Шипицин Wrote: ------------------------------------------------------- > если у вас "access forbidden by rule", то по сути вы и так эти > запросы > блокируете (на уровне nginx, не iptables). > можно сделать "access_log off;" и забыть g > > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org Есть желание именно на уровне iptables это сделать. Все равно, когда до nginx эти запросы долетают, тратятся его ресурсы. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294057,294062#msg-294062 From chipitsine на gmail.com Wed Apr 27 09:17:52 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 27 Apr 2022 14:17:52 +0500 Subject: =?UTF-8?B?UmU6INCc0YPRgdC+0YDQvdGL0LUg0LfQsNC/0YDQvtGB0Ys=?= In-Reply-To: <6c38ce433c60b6f38c317fb63cac9c87.NginxMailingListRussian@forum.nginx.org> References: <6c38ce433c60b6f38c317fb63cac9c87.NginxMailingListRussian@forum.nginx.org> Message-ID: ср, 27 апр. 2022 г. в 13:53, alexander_st : > Илья Шипицин Wrote: > ------------------------------------------------------- > > если у вас "access forbidden by rule", то по сути вы и так эти > > запросы > > блокируете (на уровне nginx, не iptables). > > можно сделать "access_log off;" и забыть > g > > > > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > Есть желание именно на уровне iptables это сделать. Все равно, когда до > nginx эти запросы долетают, тратятся его ресурсы. > теоретически на машинерию, которая парсит логи и управляет iptables может уйти больше ресурсов. ну и, всякий ISP NAT, когда домашний провайдер с одного адреса выпускает целый город. вы весь город отправите в бан. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,294057,294062#msg-294062 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Wed Apr 27 13:12:59 2022 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 27 Apr 2022 16:12:59 +0300 Subject: =?utf-8?B?0JzRg9GB0L7RgNC90YvQtSDQt9Cw?= =?utf-8?B?0L/RgNC+0YHRiw==?= In-Reply-To: References: <6c38ce433c60b6f38c317fb63cac9c87.NginxMailingListRussian@forum.nginx.org> Message-ID: <20220427131259.GA1464@zxy.spb.ru> On Wed, Apr 27, 2022 at 02:17:52PM +0500, Илья Шипицин wrote: > ср, 27 апр. 2022 г. в 13:53, alexander_st : > > > Илья Шипицин Wrote: > > ------------------------------------------------------- > > > если у вас "access forbidden by rule", то по сути вы и так эти > > > запросы > > > блокируете (на уровне nginx, не iptables). > > > можно сделать "access_log off;" и забыть > > g > > > > > > > _______________________________________________ > > > nginx-ru mailing list -- nginx-ru на nginx.org > > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > > Есть желание именно на уровне iptables это сделать. Все равно, когда до > > nginx эти запросы долетают, тратятся его ресурсы. > > > > теоретически на машинерию, которая парсит логи и управляет iptables может > уйти больше ресурсов. > ну и, всякий ISP NAT, когда домашний провайдер с одного адреса выпускает > целый город. вы весь город отправите в бан. ну ты сравнил, тут на кону стоит судьба двух микроватов, которые сожрет нгинкс, не время беспокоится о судьбе городов. From nginx-forum на forum.nginx.org Thu Apr 28 03:18:46 2022 From: nginx-forum на forum.nginx.org (alexander_st) Date: Wed, 27 Apr 2022 23:18:46 -0400 Subject: =?UTF-8?Q?Re:=20=D0=9C=D1=83=D1=81=D0=BE=D1=80=D0=BD=D1=8B=D0=B5=20?= =?UTF-8?Q?=D0=B7=D0=B0=D0=BF=D1=80=D0=BE=D1=81=D1=8B?= In-Reply-To: <20220427131259.GA1464@zxy.spb.ru> References: <20220427131259.GA1464@zxy.spb.ru> Message-ID: <85807d3cd88dbe992f5d5f054063c465.NginxMailingListRussian@forum.nginx.org> Ну вы приколисты, ага. Я баню на небольшое время и учел NAT. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294057,294067#msg-294067