From pluknet на nginx.com Thu Dec 2 10:44:02 2021 From: pluknet на nginx.com (Sergey Kandaurov) Date: Thu, 2 Dec 2021 13:44:02 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: <1707287570.20211124225840@gmail.com> References: <1707287570.20211124225840@gmail.com> Message-ID: <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> > On 24 Nov 2021, at 22:58, izorkin на gmail.com wrote: > > Здравствуйте. > > Собрал nginx с библиотекой QuicTLS - https://github.com/quictls/openssl > При активации протокола HTTP3 на нескольких хостах в лог начинаются сыпаться такие ошибки: > ``` > 2021/11/24 22:52:45 [error] 40152#40152: *51 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 > 2021/11/24 22:52:45 [error] 40151#40151: *52 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 > 2021/11/24 22:52:45 [error] 40153#40153: *53 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 > ``` > Если использовать BoringSSL с аналогичной конфигурацией, то такой ошибки нету. > Попробуйте этот патч: # HG changeset patch # User Sergey Kandaurov # Date 1638441718 -10800 # Thu Dec 02 13:41:58 2021 +0300 # Branch quic # Node ID 45c2b34248365f63bcec694a8587d11f52441ac9 # Parent aa0bd5f3127f6a27669b9e6f8362ba9254785193 QUIC: clear SSL_OP_ENABLE_MIDDLEBOX_COMPAT on SSL context switch. The SSL_OP_ENABLE_MIDDLEBOX_COMPAT option is provided by QuicTLS and enabled by default in the newly created SSL contexts. SSL_set_quic_method() is used to clear it, which is required for SSL handshake to work on QUIC connections. Switching context in the ngx_http_ssl_servername() SNI callback overrides SSL options from the new SSL context. This results in the option set again. Fix is to explicitly clear it when switching to another SSL context. Initially reported here (in Russian): http://mailman.nginx.org/pipermail/nginx-ru/2021-November/063989.html diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c --- a/src/http/ngx_http_request.c +++ b/src/http/ngx_http_request.c @@ -962,7 +962,14 @@ ngx_http_ssl_servername(ngx_ssl_conn_t * #ifdef SSL_OP_NO_RENEGOTIATION SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION); #endif + +#ifdef SSL_OP_ENABLE_MIDDLEBOX_COMPAT +#if (NGX_QUIC) + if (c->listening->quic) { + SSL_clear_options(ssl_conn, SSL_OP_ENABLE_MIDDLEBOX_COMPAT); } +#endif +#endif done: -- Sergey Kandaurov From mdounin на mdounin.ru Thu Dec 2 13:30:22 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 2 Dec 2021 16:30:22 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> Message-ID: Hello! On Thu, Dec 02, 2021 at 01:44:02PM +0300, Sergey Kandaurov wrote: > > On 24 Nov 2021, at 22:58, izorkin на gmail.com wrote: > > > > Здравствуйте. > > > > Собрал nginx с библиотекой QuicTLS - https://github.com/quictls/openssl > > При активации протокола HTTP3 на нескольких хостах в лог начинаются сыпаться такие ошибки: > > ``` > > 2021/11/24 22:52:45 [error] 40152#40152: *51 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 > > 2021/11/24 22:52:45 [error] 40151#40151: *52 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 > > 2021/11/24 22:52:45 [error] 40153#40153: *53 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 > > ``` > > Если использовать BoringSSL с аналогичной конфигурацией, то такой ошибки нету. > > > > Попробуйте этот патч: > > # HG changeset patch > # User Sergey Kandaurov > # Date 1638441718 -10800 > # Thu Dec 02 13:41:58 2021 +0300 > # Branch quic > # Node ID 45c2b34248365f63bcec694a8587d11f52441ac9 > # Parent aa0bd5f3127f6a27669b9e6f8362ba9254785193 > QUIC: clear SSL_OP_ENABLE_MIDDLEBOX_COMPAT on SSL context switch. > > The SSL_OP_ENABLE_MIDDLEBOX_COMPAT option is provided by QuicTLS and enabled > by default in the newly created SSL contexts. SSL_set_quic_method() is used > to clear it, which is required for SSL handshake to work on QUIC connections. > Switching context in the ngx_http_ssl_servername() SNI callback overrides SSL > options from the new SSL context. This results in the option set again. > Fix is to explicitly clear it when switching to another SSL context. > > Initially reported here (in Russian): > http://mailman.nginx.org/pipermail/nginx-ru/2021-November/063989.html > > diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c > --- a/src/http/ngx_http_request.c > +++ b/src/http/ngx_http_request.c > @@ -962,7 +962,14 @@ ngx_http_ssl_servername(ngx_ssl_conn_t * > #ifdef SSL_OP_NO_RENEGOTIATION > SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION); > #endif > + > +#ifdef SSL_OP_ENABLE_MIDDLEBOX_COMPAT > +#if (NGX_QUIC) > + if (c->listening->quic) { > + SSL_clear_options(ssl_conn, SSL_OP_ENABLE_MIDDLEBOX_COMPAT); > } > +#endif > +#endif > > done: На взгляд кажется, что индентация неверна и забыта закрывающая фигурная скобка. -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Thu Dec 2 13:50:30 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 2 Dec 2021 16:50:30 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> Message-ID: <258250823.20211202165030@gmail.com> Здравствуйте, Maxim. Да, не собирается у меня nginx. Думал у меня где-то ошибка. Вы писали 2 декабря 2021 г., 16:30:22: > Hello! > On Thu, Dec 02, 2021 at 01:44:02PM +0300, Sergey Kandaurov wrote: > На взгляд кажется, что индентация неверна и забыта закрывающая > фигурная скобка. -- С уважением, Izorkin mailto:izorkin на gmail.com From pluknet на nginx.com Thu Dec 2 14:01:57 2021 From: pluknet на nginx.com (Sergey Kandaurov) Date: Thu, 2 Dec 2021 17:01:57 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> Message-ID: > On 2 Dec 2021, at 16:30, Maxim Dounin wrote: > > Hello! > > On Thu, Dec 02, 2021 at 01:44:02PM +0300, Sergey Kandaurov wrote: > >>> On 24 Nov 2021, at 22:58, izorkin на gmail.com wrote: >>> >>> Здравствуйте. >>> >>> Собрал nginx с библиотекой QuicTLS - https://github.com/quictls/openssl >>> При активации протокола HTTP3 на нескольких хостах в лог начинаются сыпаться такие ошибки: >>> ``` >>> 2021/11/24 22:52:45 [error] 40152#40152: *51 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 >>> 2021/11/24 22:52:45 [error] 40151#40151: *52 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 >>> 2021/11/24 22:52:45 [error] 40153#40153: *53 SSL_do_handshake() failed (SSL: error:0A0C0101:SSL routines::called a function you should not call) while handling frames, client: 91...., server: 0.0.0.0:443 >>> ``` >>> Если использовать BoringSSL с аналогичной конфигурацией, то такой ошибки нету. >>> >> >> Попробуйте этот патч: >> >> # HG changeset patch >> # User Sergey Kandaurov >> # Date 1638441718 -10800 >> # Thu Dec 02 13:41:58 2021 +0300 >> # Branch quic >> # Node ID 45c2b34248365f63bcec694a8587d11f52441ac9 >> # Parent aa0bd5f3127f6a27669b9e6f8362ba9254785193 >> QUIC: clear SSL_OP_ENABLE_MIDDLEBOX_COMPAT on SSL context switch. >> >> The SSL_OP_ENABLE_MIDDLEBOX_COMPAT option is provided by QuicTLS and enabled >> by default in the newly created SSL contexts. SSL_set_quic_method() is used >> to clear it, which is required for SSL handshake to work on QUIC connections. >> Switching context in the ngx_http_ssl_servername() SNI callback overrides SSL >> options from the new SSL context. This results in the option set again. >> Fix is to explicitly clear it when switching to another SSL context. >> >> Initially reported here (in Russian): >> http://mailman.nginx.org/pipermail/nginx-ru/2021-November/063989.html >> >> diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c >> --- a/src/http/ngx_http_request.c >> +++ b/src/http/ngx_http_request.c >> @@ -962,7 +962,14 @@ ngx_http_ssl_servername(ngx_ssl_conn_t * >> #ifdef SSL_OP_NO_RENEGOTIATION >> SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION); >> #endif >> + >> +#ifdef SSL_OP_ENABLE_MIDDLEBOX_COMPAT >> +#if (NGX_QUIC) >> + if (c->listening->quic) { >> + SSL_clear_options(ssl_conn, SSL_OP_ENABLE_MIDDLEBOX_COMPAT); >> } >> +#endif >> +#endif >> >> done: > > На взгляд кажется, что индентация неверна и забыта закрывающая > фигурная скобка. > Tnx, видимо отвлёкся, пока переносил из ngx_ssl_create(). diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c --- a/src/http/ngx_http_request.c +++ b/src/http/ngx_http_request.c @@ -962,6 +962,14 @@ ngx_http_ssl_servername(ngx_ssl_conn_t * #ifdef SSL_OP_NO_RENEGOTIATION SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION); #endif + +#ifdef SSL_OP_ENABLE_MIDDLEBOX_COMPAT +#if (NGX_HTTP_QUIC) + if (c->listening->quic) { + SSL_clear_options(ssl_conn, SSL_OP_ENABLE_MIDDLEBOX_COMPAT); + } +#endif +#endif } done: -- Sergey Kandaurov From izorkin на gmail.com Thu Dec 2 14:03:00 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 2 Dec 2021 17:03:00 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> Message-ID: <349465175.20211202170300@gmail.com> Здравствуйте, Sergey. Спасибо, патч сработал, только там скобки одной не хватает. -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Thu Dec 2 14:18:09 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 2 Dec 2021 17:18:09 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> Message-ID: <928827627.20211202171809@gmail.com> Здравствуйте, Sergey. Проверил - работает. Спасибо! Вы писали 2 декабря 2021 г., 17:01:57: > Tnx, видимо отвлёкся, пока переносил из ngx_ssl_create(). > diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c > --- a/src/http/ngx_http_request.c > +++ b/src/http/ngx_http_request.c > @@ -962,6 +962,14 @@ ngx_http_ssl_servername(ngx_ssl_conn_t * > #ifdef SSL_OP_NO_RENEGOTIATION > SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION); > #endif > + > +#ifdef SSL_OP_ENABLE_MIDDLEBOX_COMPAT > +#if (NGX_HTTP_QUIC) + if (c->>listening->quic) { > + SSL_clear_options(ssl_conn, SSL_OP_ENABLE_MIDDLEBOX_COMPAT); > + } > +#endif > +#endif > } > > done: -- С уважением, Izorkin mailto:izorkin на gmail.com From pluknet на nginx.com Tue Dec 7 13:53:48 2021 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 7 Dec 2021 16:53:48 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: <928827627.20211202171809@gmail.com> References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> <928827627.20211202171809@gmail.com> Message-ID: <81E4D196-AB2E-462C-AB7A-E36BCF9BBC0E@nginx.com> > On 2 Dec 2021, at 17:18, izorkin на gmail.com wrote: > > Здравствуйте, Sergey. > > Проверил - работает. > Спасибо! > https://hg.nginx.org/nginx-quic/rev/e06283038ec8 -- Sergey Kandaurov From izorkin на gmail.com Wed Dec 8 14:34:24 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 8 Dec 2021 17:34:24 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: <81E4D196-AB2E-462C-AB7A-E36BCF9BBC0E@nginx.com> References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> <928827627.20211202171809@gmail.com> <81E4D196-AB2E-462C-AB7A-E36BCF9BBC0E@nginx.com> Message-ID: <1869172875.20211208173424@gmail.com> Здравствуйте, Sergey. Спасибо, обновил у себя пакет. Но столкнулся со следующей ошибкой - не работает параметр `add_header QUIC-Status $quic;` Он вообще нужен? Вы писали 7 декабря 2021 г., 16:53:48: > https://hg.nginx.org/nginx-quic/rev/e06283038ec8 -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Wed Dec 8 18:25:56 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 8 Dec 2021 21:25:56 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: <81E4D196-AB2E-462C-AB7A-E36BCF9BBC0E@nginx.com> References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> <928827627.20211202171809@gmail.com> <81E4D196-AB2E-462C-AB7A-E36BCF9BBC0E@nginx.com> Message-ID: <73105194.20211208212556@gmail.com> Здравствуйте, Sergey. Во время проверки выяснил, что на последней ревизии 2c5e2a106952 ошибка снова проявляется. Выяснил, что перестаёт работать после этого коммита - 33226ac61076. Если использовать патч на ревизии 9680f0badc95 и ниже, то работает. Вы писали 7 декабря 2021 г., 16:53:48: > https://hg.nginx.org/nginx-quic/rev/e06283038ec8 -- С уважением, Izorkin mailto:izorkin на gmail.com From pluknet на nginx.com Thu Dec 9 08:24:08 2021 From: pluknet на nginx.com (Sergey Kandaurov) Date: Thu, 9 Dec 2021 11:24:08 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: <1869172875.20211208173424@gmail.com> References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> <928827627.20211202171809@gmail.com> <81E4D196-AB2E-462C-AB7A-E36BCF9BBC0E@nginx.com> <1869172875.20211208173424@gmail.com> Message-ID: <19C1B8AF-F827-4571-9BE6-1B798E3D2B42@nginx.com> > On 8 Dec 2021, at 17:34, izorkin на gmail.com wrote: > > Здравствуйте, Sergey. > Спасибо, обновил у себя пакет. Но столкнулся со следующей ошибкой - не работает параметр `add_header QUIC-Status $quic;` > Он вообще нужен? Переменную в таком качестве можно использовать для отладки. В рамках рефакторинга переменная $quic была удалена: https://hg.nginx.org/nginx-quic/rev/651cc905b7c2 В качестве замены можно использовать переменную $http3, семантика которой аналогична переменной $http2, см. подробнее здесь: https://quic.nginx.org/readme.html. -- Sergey Kandaurov From pluknet на nginx.com Thu Dec 9 08:25:12 2021 From: pluknet на nginx.com (Sergey Kandaurov) Date: Thu, 9 Dec 2021 11:25:12 +0300 Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0L/QvtC00LTQtdGA0LbQutCwIE9wZW5zc2wg0LHQuNCx?= =?UTF-8?B?0LvQuNC+0YLQtdC60LggcXVpY2t0bHM=?= In-Reply-To: <73105194.20211208212556@gmail.com> References: <1707287570.20211124225840@gmail.com> <6502C3B6-A717-45E5-A956-4F4EEE7B805C@nginx.com> <928827627.20211202171809@gmail.com> <81E4D196-AB2E-462C-AB7A-E36BCF9BBC0E@nginx.com> <73105194.20211208212556@gmail.com> Message-ID: <9CC76B3B-94C8-4D2B-A5DE-9410BB2DA699@nginx.com> > On 8 Dec 2021, at 21:25, izorkin на gmail.com wrote: > > Здравствуйте, Sergey. > > Во время проверки выяснил, что на последней ревизии 2c5e2a106952 ошибка снова проявляется. > Выяснил, что перестаёт работать после этого коммита - 33226ac61076. > Если использовать патч на ревизии 9680f0badc95 и ниже, то работает. > Да, действительно не попал в шарик. Спасибо. https://hg.nginx.org/nginx-quic/rev/0ee56d2eac44 -- Sergey Kandaurov From izorkin на gmail.com Thu Dec 9 19:16:05 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 9 Dec 2021 22:16:05 +0300 Subject: =?UTF-8?B?UmU6IG5naW54OiDQt9Cw0L/Rg9GB0LogSFRUUDMg0L/RgNC+0YLQvtC60L7Qu9Cw?= =?UTF-8?B?INC90LAg0L3QtdGB0LrQvtC70YzQutC40YUg0YXQvtGB0YLQsNGFLg==?= In-Reply-To: References: <146876086.20211115120158@gmail.com> <1046996365.20211117194849@gmail.com> <371ccf41-594c-59a9-83cf-5eb3311501b4@ya.ru> <735998192.20211121001708@gmail.com> <16310501390.20211121145238@gmail.com> Message-ID: <278418753.20211209221605@gmail.com> Здравствуйте, Evgeniy. Попробовал собрать debug log 1) https://pastebin.com/3r1jPhhD - с использованием proxy_set_header Host $host 2) https://pastebin.com/XiRjCreZ - без использования В 1 варианте не работает вход на сайт, ругается на ошибку с аутентификацией. Во 2 варианте соединение переключается на http2 протокол и уже заходит на сайт. -- С уважением, Izorkin mailto:izorkin на gmail.com From nginx-forum на forum.nginx.org Tue Dec 14 08:52:22 2021 From: nginx-forum на forum.nginx.org (akarabanov) Date: Tue, 14 Dec 2021 03:52:22 -0500 Subject: =?UTF-8?B?0JTRgNC10LrRgtC40LLQsCBpZiDQuCDQv9GA0L7QstC10YDQutCwINGB0YPRidC1?= =?UTF-8?B?0YHRgtCy0L7QsNC90LjRjyDRhNCw0LnQu9Cw?= Message-ID: Здравствуйте. Мне необходимо проверить существует ли сокет. Я использую такую конструкцию: location / { if ( -f /www/php_sockets/${app}.sock ) { set $sock "/www/php_sockets/${app}.sock"; } return 220 "${sock}"; } И получаю ошибку 'open() "/www/php_sockets/test.sock" failed (6: No such device or address)' Если заменить сокет на простой файл с теми же правами, то всё отрабатывает корректно. Скажите пожалуйста с помощью директивы if нельзя проверить существование сокета или я что-то делаю не так? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293064,293064#msg-293064 From gmm на csdoc.com Tue Dec 14 21:26:42 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 14 Dec 2021 23:26:42 +0200 Subject: nginx BUG ? unexpected redirect from https://example.com/download to https://example.com/download/ Message-ID: <152b0ec1-1814-9aa3-54be-8f2a68febddd@csdoc.com> Здравствуйте! Есть такой конфиг: location /download { proxy_pass http://unix:/run/gunicorn.sock; } location /download/ { alias /home/www/download/; charset utf-8; autoindex on; autoindex_localtime on; } при этом nginx почему-то и зачем-то делает самовольный редирект с https://example.com/download на https://example.com/download/ $ curl -i https://example.com/download HTTP/1.1 301 Moved Permanently Server: nginx Date: Tue, 14 Dec 2021 21:16:24 GMT Content-Type: text/html Content-Length: 162 Location: https://example.com/download/ Connection: keep-alive 301 Moved Permanently

301 Moved Permanently


nginx
Это баг в nginx ? Можно ли его исправить? Добавление модификатора = также не помогает: location = /download { proxy_pass http://unix:/run/gunicorn.sock; } по прежнему происходит 301 редирект на страницу /download/ Если в конфиге поменять proxy_pass location /download { #proxy_pass http://unix:/run/gunicorn.sock; proxy_pass http://127.0.0.1:5000; } тогда редиректа не происходит и запрос корректно передается на backend. Но нужно чтобы все нормально работало именно с сокетом gunicorn.sock -- Best regards, Gena From mdounin на mdounin.ru Tue Dec 14 23:33:35 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 15 Dec 2021 02:33:35 +0300 Subject: nginx BUG ? unexpected redirect from https://example.com/download to https://example.com/download/ In-Reply-To: <152b0ec1-1814-9aa3-54be-8f2a68febddd@csdoc.com> References: <152b0ec1-1814-9aa3-54be-8f2a68febddd@csdoc.com> Message-ID: Hello! On Tue, Dec 14, 2021 at 11:26:42PM +0200, Gena Makhomed wrote: > Есть такой конфиг: > > location /download { > proxy_pass http://unix:/run/gunicorn.sock; > } > > location /download/ { > alias /home/www/download/; > charset utf-8; > autoindex on; > autoindex_localtime on; > } > > при этом nginx почему-то и зачем-то делает самовольный редирект > с https://example.com/download на https://example.com/download/ Воспроизводится ли проблема на приведённом конфиге в чистом виде, без каких-либо других location'ов и/или rewrite'ов? Если да - то как выглядит минимальный конфиг, на котором проблема воспроизводится, полностью (nginx -T)? Что показывает nginx -V? Что в debug log'е? Just in case it's not clear, такая же нога - и не болит. Допускаю, что это может быть ошибка в обработке дерева локаций, но с учётом зависимости от написанного в proxy_pass - я бы скорее предположил что-нибудь банальное, вроде ошибки от бэкенда, которую error_page превращает в 301. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Wed Dec 15 02:01:02 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 15 Dec 2021 05:01:02 +0300 Subject: =?UTF-8?B?UmU6INCU0YDQtdC60YLQuNCy0LAgaWYg0Lgg0L/RgNC+0LLQtdGA0LrQsCDRgdGD?= =?UTF-8?B?0YnQtdGB0YLQstC+0LDQvdC40Y8g0YTQsNC50LvQsA==?= In-Reply-To: References: Message-ID: Hello! On Tue, Dec 14, 2021 at 03:52:22AM -0500, akarabanov wrote: > Мне необходимо проверить существует ли сокет. Я использую такую > конструкцию: > > location / { > > if ( -f /www/php_sockets/${app}.sock ) { > set $sock "/www/php_sockets/${app}.sock"; > } > > return 220 "${sock}"; > } > > И получаю ошибку 'open() "/www/php_sockets/test.sock" failed (6: No such > device or address)' > > Если заменить сокет на простой файл с теми же правами, то всё отрабатывает > корректно. > > Скажите пожалуйста с помощью директивы if нельзя проверить существование > сокета или я что-то делаю не так? Нельзя. Условие "-f" позволяет проверять существование (обычных) файлов. Также можно проверять существование каталогов ("-d") или файлов, каталогов и символических ссылок ("-e"). Возможности проверять существование сокетов и прочих специальных файлов не предусмотрено. Если нужно проверять именно сокеты - можно использовать встроенный perl или njs. А ошибка - ENXIO - видимо следствие того, что в конфигурации включён open_file_cache, и при проверках nginx пытается сразу открывать файл. В случае специальных файлов это приводит к ошибкам, т.к. nginx открывает файлы с флагом O_NONBLOCK, дабы избежать вечных блокировок при случайных попытках открытия специальных файлов. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Dec 15 06:52:56 2021 From: nginx-forum на forum.nginx.org (akarabanov) Date: Wed, 15 Dec 2021 01:52:56 -0500 Subject: =?UTF-8?B?UmU6INCU0YDQtdC60YLQuNCy0LAgaWYg0Lgg0L/RgNC+0LLQtdGA0LrQsCDRgdGD?= =?UTF-8?B?0YnQtdGB0YLQstC+0LDQvdC40Y8g0YTQsNC50LvQsA==?= In-Reply-To: References: Message-ID: <0e67a2c9bc2c52beea02d2c29d92fb8a.NginxMailingListRussian@forum.nginx.org> Понял. Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293064,293079#msg-293079 From gmm на csdoc.com Wed Dec 15 07:14:53 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 15 Dec 2021 09:14:53 +0200 Subject: nginx BUG ? unexpected redirect from https://example.com/download to https://example.com/download/ In-Reply-To: References: <152b0ec1-1814-9aa3-54be-8f2a68febddd@csdoc.com> Message-ID: Здравствуйте, Максим! On 15.12.2021 1:33, Maxim Dounin wrote: > Воспроизводится ли проблема на приведённом конфиге в чистом виде, > без каких-либо других location'ов и/или rewrite'ов? Если да - то > как выглядит минимальный конфиг, на котором проблема > воспроизводится, полностью (nginx -T)? Что показывает nginx -V? > Что в debug log'е? Воспроизводится на таком конфиге: # nginx -T error_log /var/log/nginx/error.log debug; events { use epoll; } http { server { server_name example.com; location / { proxy_pass http://127.0.0.1; } location /download/ { proxy_pass http://127.0.0.2; } } } # nginx -V показывает nginx version: nginx/1.21.4 - это официальный бинарник nginx-1.21.4-1.el8.ngx.x86_64.rpm с сайта http://nginx.org/packages/mainline/centos/8/x86_64/RPMS/ В debug log'е так: http process request line http request line: "GET /download HTTP/1.1" http uri: "/download" http args: "" http exten: "" posix_memalign: 000055D246233D50:4096 @16 http process request header line http header: "Host: example.com" http header: "User-Agent: curl/7.61.1" http header: "Accept: */*" http header done event timer del: 3: 29402186335 generic phase: 0 rewrite phase: 1 test location: "/" test location: "download/" using configuration "/download/" http cl:-1 max:1048576 http finalize request: 301, "/download?" a:1, c:1 http special response: 301, "/download?" http set discard body HTTP/1.1 301 Moved Permanently Server: nginx/1.21.4 Date: Wed, 15 Dec 2021 06:54:06 GMT Content-Type: text/html Content-Length: 169 Location: http://example.com/download/ Connection: keep-alive Перечитал еще раз документацию на сайте nginx.org - запрос "/download" должен попадать в location "/" Но запрос "/download" обрабатывается в location "/download/" это BUG в самом nginx или это BUG в документации к nginx ? Проверил на такой конфигурации: # nginx -T error_log /var/log/nginx/error.log debug; events { use epoll; } http { server { server_name example.net; location / { return 200 "main locaton\n\n"; } location /download/ { return 200 "download location\n\n"; } } } Тут все отрабатывает как и должно быть согласно документации. В debug log'е так: http process request line http request line: "GET /download HTTP/1.1" http uri: "/download" http args: "" http exten: "" posix_memalign: 000055D24625B920:4096 @16 http process request header line http header: "Host: example.net" http header: "User-Agent: curl/7.61.1" http header: "Accept: */*" http header done event timer del: 3: 29403087747 generic phase: 0 rewrite phase: 1 test location: "/" test location: "download/" using configuration "/" http cl:-1 max:1048576 rewrite phase: 3 http set discard body HTTP/1.1 200 OK Server: nginx/1.21.4 Date: Wed, 15 Dec 2021 07:09:07 GMT Content-Type: text/plain Content-Length: 14 Connection: keep-alive -- Best regards, Gena From mdounin на mdounin.ru Wed Dec 15 13:39:38 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 15 Dec 2021 16:39:38 +0300 Subject: nginx BUG ? unexpected redirect from https://example.com/download to https://example.com/download/ In-Reply-To: References: <152b0ec1-1814-9aa3-54be-8f2a68febddd@csdoc.com> Message-ID: Hello! On Wed, Dec 15, 2021 at 09:14:53AM +0200, Gena Makhomed wrote: > On 15.12.2021 1:33, Maxim Dounin wrote: > > > Воспроизводится ли проблема на приведённом конфиге в чистом виде, > > без каких-либо других location'ов и/или rewrite'ов? Если да - то > > как выглядит минимальный конфиг, на котором проблема > > воспроизводится, полностью (nginx -T)? Что показывает nginx -V? > > Что в debug log'е? > > Воспроизводится на таком конфиге: > > # nginx -T > error_log /var/log/nginx/error.log debug; > events { use epoll; } > http { > server { > server_name example.com; > location / { proxy_pass http://127.0.0.1; } > location /download/ { proxy_pass http://127.0.0.2; } > } > } На таком конфиге - воспроизводиться должно, это штатное поведение. Явно документировано в описании директивы location (http://nginx.org/r/location/ru): : Если location задан префиксной строкой со слэшом в конце и запросы : обрабатываются при помощи proxy_pass, fastcgi_pass, uwsgi_pass, : scgi_pass, memcached_pass или grpc_pass, происходит специальная : обработка. В ответ на запрос с URI равным этой строке, но без : завершающего слэша, будет возвращено постоянное перенаправление с : кодом 301 на URI с добавленным в конец слэшом. Если такое : поведение нежелательно, можно задать точное совпадение URI и : location, например: ... Вопрос исключительно о том, почему, как утверждается в исходном сообщении, не срабатывает явно заданный location без завершающего слэша, в том числе с точным совпадением. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Wed Dec 15 14:15:29 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 15 Dec 2021 16:15:29 +0200 Subject: nginx BUG ? unexpected redirect from https://example.com/download to https://example.com/download/ In-Reply-To: References: <152b0ec1-1814-9aa3-54be-8f2a68febddd@csdoc.com> Message-ID: Здравствуйте, Максим! On 15.12.2021 15:39, Maxim Dounin wrote: >>> Воспроизводится ли проблема на приведённом конфиге в чистом виде, >>> без каких-либо других location'ов и/или rewrite'ов? Если да >>> - то как выглядит минимальный конфиг, на котором проблема >>> воспроизводится, полностью (nginx -T)? >> >> Воспроизводится на таком конфиге: >> >> error_log /var/log/nginx/error.log debug; >> events { use epoll; } >> http { >> server { >> server_name example.com; >> location / { proxy_pass http://127.0.0.1; } >> location /download/ { proxy_pass http://127.0.0.2; } >> } >> } > > На таком конфиге - воспроизводиться должно, это штатное поведение. > Явно документировано в описании директивы location Теперь понял, большое спасибо! Не дочитал документацию, после слов "Проиллюстрируем вышесказанное примером" дальше уже читать не стал, а после него оказывается еще есть описание поведения директивы... > Вопрос исключительно о том, почему, как утверждается в исходном > сообщении, не срабатывает явно заданный location без завершающего > слэша, в том числе с точным совпадением. Это особенности моей локальной конфигурации. На сервере есть два контейнера, nginx-frontend и nginx-backend, запрос идет так: client => nginx-frontend => nginx-backend => proxy_pass http://app В контейнере nginx-frontend есть два сайта - example.com и dev.example.com, оба они закрыты с помощью basic_auth: location / { auth_basic "Site under development"; auth_basic_user_file /etc/nginx/safe/example.com.htpasswd; satisfy any; allow 11.22.33.44; # мой IP адрес deny all; proxy_pass http://nginx-backend; } но для сайта example.com в конфигурации nginx-frontend есть строчка location /download/ { proxy_pass http://nginx-backend; } чтобы файлы можно было скачивать из интернета без ввода логина и пароля, а в конфиге для сайта dev.example.com такой строчки нет. При этом в контейнере nginx-backend конфигурации сайтов example.com и dev.example.com идентичны между собой и отличаются только адресом куда проксируются запросы через proxy_pass. Про эту строчку в конфигурации nginx-frontend я уже и забыл, поэтому и сделал ошибочное предположение, что nginx-backend по разному обрабатывает конфигурацию в зависимости от того куда указывает proxy_pass, потому что для сайта dev.example.com урл /download уходил на proxy_pass а для example.com был 301 редирект. В будущем постараюсь быть более внимательным. -- Best regards, Gena From nginx-forum на forum.nginx.org Sat Dec 18 09:06:02 2021 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Sat, 18 Dec 2021 04:06:02 -0500 Subject: =?UTF-8?B?Z3VuemlwINC00LvRjyBicm90bGk=?= Message-ID: <0a91b5037c7c44a2c7c832519ac4d6a5.NginxMailingListRussian@forum.nginx.org> Добрый день, может быть у кого-нибудь есть модуль, подобный ngx_http_gunzip_module, что бы в proxy_cache хранить полученные с upstream сжатые c brotli ответы и отдавать клиентам без поддержки brotli разархивированные данные? Если кто хочет заняться разработкой подобного - готов стать спонсором для данной разработки. На гитхаб есть начало разработки, но модуль не работает как должен. https://github.com/splitice/ngx_brunzip_module Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293090,293090#msg-293090 From nginx-forum на forum.nginx.org Sun Dec 26 18:31:30 2021 From: nginx-forum на forum.nginx.org (parimanita) Date: Sun, 26 Dec 2021 13:31:30 -0500 Subject: =?UTF-8?B?0JfQsNC/0LjRgdC4INCyIGFjY2Vzcy5sb2cg0L3QtSDQvtGC0YHQvtGA0YLQuNGA?= =?UTF-8?B?0L7QstCw0L3RiyDQv9C+INCy0YDQtdC80LXQvdC4Lg==?= Message-ID: <8df837b7000640675ad1a487714dc97c.NginxMailingListRussian@forum.nginx.org> Приветствую всех! Использую nginx уже давно на разных серверах. Всегда с логом доступа было всё в порядке. А сейчас поднимаю новый сервер и вдруг обнаруживаю, что записи в логе access.log перемешаны - не отсортированы по времени. Пробовал включать/выключать буферизацию записи в лог - не помогло. Прямо сейчас в моём распоряжении четыре сервера с разными версиями nginx: 1.10.2, 1.14.1, 1.14.2 и 1.18.0. Первые три работают под Debian с 8 по 10 и на них всё нормально. Последний - самый свежий с версией nginx 1.18.0 - под Debian 11 и на нём вот такая проблема. Может кто-нибудь подсказать - куда копать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293143,293143#msg-293143 From chipitsine на gmail.com Mon Dec 27 11:49:15 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 27 Dec 2021 16:49:15 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQv9C40YHQuCDQsiBhY2Nlc3MubG9nINC90LUg0L7RgtGB0L7RgNGC?= =?UTF-8?B?0LjRgNC+0LLQsNC90Ysg0L/QviDQstGA0LXQvNC10L3QuC4=?= In-Reply-To: <8df837b7000640675ad1a487714dc97c.NginxMailingListRussian@forum.nginx.org> References: <8df837b7000640675ad1a487714dc97c.NginxMailingListRussian@forum.nginx.org> Message-ID: а количество worker-процессов на серверах, где порядок сохраняется, и где нет, одинаковый ? вс, 26 дек. 2021 г. в 23:34, parimanita : > Приветствую всех! > > Использую nginx уже давно на разных серверах. Всегда с логом доступа было > всё в порядке. А сейчас поднимаю новый сервер и вдруг обнаруживаю, что > записи в логе access.log перемешаны - не отсортированы по времени. > Пробовал включать/выключать буферизацию записи в лог - не помогло. > > Прямо сейчас в моём распоряжении четыре сервера с разными версиями nginx: > 1.10.2, 1.14.1, 1.14.2 и 1.18.0. Первые три работают под Debian с 8 по 10 и > на них всё нормально. Последний - самый свежий с версией nginx 1.18.0 - под > Debian 11 и на нём вот такая проблема. > > Может кто-нибудь подсказать - куда копать? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,293143,293143#msg-293143 > > _______________________________________________ > 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 Dec 27 14:09:52 2021 From: nginx-forum на forum.nginx.org (parimanita) Date: Mon, 27 Dec 2021 09:09:52 -0500 Subject: =?UTF-8?B?UmU6INCX0LDQv9C40YHQuCDQsiBhY2Nlc3MubG9nINC90LUg0L7RgtGB0L7RgNGC?= =?UTF-8?B?0LjRgNC+0LLQsNC90Ysg0L/QviDQstGA0LXQvNC10L3QuC4=?= In-Reply-To: References: Message-ID: Да, Вы абсолютно правы! Количество worker-процессов оказалось разным: у трёх предыдущих серверов было по одному, а у этого - четыре. Изменил в nginx.conf параметр worker_processes с "auto" на "1" и лог стал последовательным. Большое спасибо! Я правильно понимаю, что при количестве worker-процессов больше 1 лог будет перемешанным и нет другого простого способа это исправить? Илья Шипицин Wrote: ------------------------------------------------------- > а количество worker-процессов на серверах, где порядок сохраняется, и > где > нет, одинаковый ? > > вс, 26 дек. 2021 г. в 23:34, parimanita > : > > > Приветствую всех! > > > > Использую nginx уже давно на разных серверах. Всегда с логом доступа > было > > всё в порядке. А сейчас поднимаю новый сервер и вдруг обнаруживаю, > что > > записи в логе access.log перемешаны - не отсортированы по времени. > > Пробовал включать/выключать буферизацию записи в лог - не помогло. > > > > Прямо сейчас в моём распоряжении четыре сервера с разными версиями > nginx: > > 1.10.2, 1.14.1, 1.14.2 и 1.18.0. Первые три работают под Debian с 8 > по 10 и > > на них всё нормально. Последний - самый свежий с версией nginx > 1.18.0 - под > > Debian 11 и на нём вот такая проблема. > > > > Может кто-нибудь подсказать - куда копать? > > > > Posted at Nginx Forum: > > https://forum.nginx.org/read.php?21,293143,293143#msg-293143 > > > > _______________________________________________ > > 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,293143,293145#msg-293145 From chipitsine на gmail.com Mon Dec 27 14:22:05 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 27 Dec 2021 19:22:05 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQv9C40YHQuCDQsiBhY2Nlc3MubG9nINC90LUg0L7RgtGB0L7RgNGC?= =?UTF-8?B?0LjRgNC+0LLQsNC90Ysg0L/QviDQstGA0LXQvNC10L3QuC4=?= In-Reply-To: References: Message-ID: это, к сожалению, частый вопрос. мне казалось, что разбор был вот тут Модуль ngx_http_log_module (nginx.org) но увы. показалось. давайте попросим Деда Мороза добавить его ? (так то на разных форумах ответ на ваш вопрос можно найти, если поискать) пн, 27 дек. 2021 г. в 19:10, parimanita : > Да, Вы абсолютно правы! Количество worker-процессов оказалось разным: у > трёх > предыдущих серверов было по одному, а у этого - четыре. Изменил в > nginx.conf > параметр worker_processes с "auto" на "1" и лог стал последовательным. > Большое спасибо! > > Я правильно понимаю, что при количестве worker-процессов больше 1 лог будет > перемешанным и нет другого простого способа это исправить? > > > Илья Шипицин Wrote: > ------------------------------------------------------- > > а количество worker-процессов на серверах, где порядок сохраняется, и > > где > > нет, одинаковый ? > > > > вс, 26 дек. 2021 г. в 23:34, parimanita > > : > > > > > Приветствую всех! > > > > > > Использую nginx уже давно на разных серверах. Всегда с логом доступа > > было > > > всё в порядке. А сейчас поднимаю новый сервер и вдруг обнаруживаю, > > что > > > записи в логе access.log перемешаны - не отсортированы по времени. > > > Пробовал включать/выключать буферизацию записи в лог - не помогло. > > > > > > Прямо сейчас в моём распоряжении четыре сервера с разными версиями > > nginx: > > > 1.10.2, 1.14.1, 1.14.2 и 1.18.0. Первые три работают под Debian с 8 > > по 10 и > > > на них всё нормально. Последний - самый свежий с версией nginx > > 1.18.0 - под > > > Debian 11 и на нём вот такая проблема. > > > > > > Может кто-нибудь подсказать - куда копать? > > > > > > Posted at Nginx Forum: > > > https://forum.nginx.org/read.php?21,293143,293143#msg-293143 > > > > > > _______________________________________________ > > > 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,293143,293145#msg-293145 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon Dec 27 14:25:35 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 27 Dec 2021 19:25:35 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQv9C40YHQuCDQsiBhY2Nlc3MubG9nINC90LUg0L7RgtGB0L7RgNGC?= =?UTF-8?B?0LjRgNC+0LLQsNC90Ysg0L/QviDQstGA0LXQvNC10L3QuC4=?= In-Reply-To: References: Message-ID: nginx logs are out of order, probably due to buffered logging - Stack Overflow пн, 27 дек. 2021 г. в 19:22, Илья Шипицин : > это, к сожалению, частый вопрос. > мне казалось, что разбор был вот тут Модуль ngx_http_log_module > (nginx.org) > > но увы. показалось. > давайте попросим Деда Мороза добавить его ? > > (так то на разных форумах ответ на ваш вопрос можно найти, если поискать) > > пн, 27 дек. 2021 г. в 19:10, parimanita : > >> Да, Вы абсолютно правы! Количество worker-процессов оказалось разным: у >> трёх >> предыдущих серверов было по одному, а у этого - четыре. Изменил в >> nginx.conf >> параметр worker_processes с "auto" на "1" и лог стал последовательным. >> Большое спасибо! >> >> Я правильно понимаю, что при количестве worker-процессов больше 1 лог >> будет >> перемешанным и нет другого простого способа это исправить? >> >> >> Илья Шипицин Wrote: >> ------------------------------------------------------- >> > а количество worker-процессов на серверах, где порядок сохраняется, и >> > где >> > нет, одинаковый ? >> > >> > вс, 26 дек. 2021 г. в 23:34, parimanita >> > : >> > >> > > Приветствую всех! >> > > >> > > Использую nginx уже давно на разных серверах. Всегда с логом доступа >> > было >> > > всё в порядке. А сейчас поднимаю новый сервер и вдруг обнаруживаю, >> > что >> > > записи в логе access.log перемешаны - не отсортированы по времени. >> > > Пробовал включать/выключать буферизацию записи в лог - не помогло. >> > > >> > > Прямо сейчас в моём распоряжении четыре сервера с разными версиями >> > nginx: >> > > 1.10.2, 1.14.1, 1.14.2 и 1.18.0. Первые три работают под Debian с 8 >> > по 10 и >> > > на них всё нормально. Последний - самый свежий с версией nginx >> > 1.18.0 - под >> > > Debian 11 и на нём вот такая проблема. >> > > >> > > Может кто-нибудь подсказать - куда копать? >> > > >> > > Posted at Nginx Forum: >> > > https://forum.nginx.org/read.php?21,293143,293143#msg-293143 >> > > >> > > _______________________________________________ >> > > 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,293143,293145#msg-293145 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Dec 27 14:56:34 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 27 Dec 2021 17:56:34 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQv9C40YHQuCDQsiBhY2Nlc3MubG9nINC90LUg0L7RgtGB0L7RgNGC?= =?UTF-8?B?0LjRgNC+0LLQsNC90Ysg0L/QviDQstGA0LXQvNC10L3QuC4=?= In-Reply-To: References: Message-ID: Hello! On Mon, Dec 27, 2021 at 09:09:52AM -0500, parimanita wrote: > Да, Вы абсолютно правы! Количество worker-процессов оказалось разным: у трёх > предыдущих серверов было по одному, а у этого - четыре. Изменил в nginx.conf > параметр worker_processes с "auto" на "1" и лог стал последовательным. > Большое спасибо! > > Я правильно понимаю, что при количестве worker-процессов больше 1 лог будет > перемешанным и нет другого простого способа это исправить? Рабочие процессы пишут в лог-файл независимо, соответственно порядок записей в лог-файле может быть не последовательным по времени. (Даже если предложить, что каждый рабочий процесс пишет в лог строго последовательно по времени - что вообще-то тоже не гарантируется, например потому, что время может меняться.) Наиболее заметно это при использовании буферизации, так как буфер у каждого процесса свой. При использовании буферизации может быть полезно использование параметра "flush=...", дабы ограничить использование буфера по времени. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Dec 28 08:49:59 2021 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Tue, 28 Dec 2021 03:49:59 -0500 Subject: =?UTF-8?Q?ipv6=3Doff_=D0=B2_upstream?= Message-ID: Добрый день, подскажите, почему когда в resolver стоит ipv6=off и в upstream доменное имя с ipv6 и ipv4 то nginx присваивает ему и ipv6 и ipv4 ip адреса, почему ipv6=off в resolver не работает в этом случае? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293160,293160#msg-293160 From mdounin на mdounin.ru Tue Dec 28 13:42:52 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 28 Dec 2021 16:42:52 +0300 Subject: =?UTF-8?Q?Re=3A_ipv6=3Doff_=D0=B2_upstream?= In-Reply-To: References: Message-ID: Hello! On Tue, Dec 28, 2021 at 03:49:59AM -0500, Vladislavik wrote: > Добрый день, подскажите, почему когда в resolver стоит ipv6=off и в upstream > доменное имя с ipv6 и ipv4 то nginx присваивает ему и ipv6 и ipv4 ip адреса, > почему ipv6=off в resolver не работает в этом случае? Директива resolver используется только при динамическом разрешении имён в процессе работы, то есть при использовании переменных в директиве proxy_pass (а также fastcgi_pass, uwsgi_pass, scgi_pass, grpc_pass). Если proxy_pass используется без переменных, а равно если используются имена серверов в других местах - преобразование имён в адреса происходит при чтении конфигурации, и для этого используется системный резолвер. Соответственно, если хочется, чтобы все имена преобразовывались только в IPv4-адреса - в первую очередь нужно настроить системный резолвер. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Dec 28 15:42:01 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 28 Dec 2021 18:42:01 +0300 Subject: nginx-1.21.5 Message-ID: Изменения в nginx 1.21.5 28.12.2021 *) Изменение: теперь nginx по умолчанию собирается с библиотекой PCRE2. *) Изменение: теперь nginx всегда использует sendfile(SF_NODISKIO) на FreeBSD. *) Добавление: поддержка sendfile(SF_NOCACHE) на FreeBSD. *) Добавление: переменная $ssl_curve. *) Исправление: при использовании HTTP/2 без SSL вместе с директивами sendfile и aio соединения могли зависать. -- Maxim Dounin http://nginx.org/