Re: no live upstreams while connecting to upstream
Понятно, спасибо.
> On 9 Jan 2019, at 21:43, Alexey via nginx-ru wrote:
>
> 09.01.2019 0:47, Eugene Toropov пишет:
>> proxy_http_version 1.1; и proxy_set_header Connection '' помогли, по крайней
>> мере 502 больше не вижу. Уточните, пожалуйста, можно ли еще как-то не
>> прописывать явно “proxy_set_header Host tratutu” в конфиге, чтоб он
>> правильный хост передавал на апстрим вместо tratata?
>
> Ну можно, например,
> proxy_set_header Host $host;
> тогда дальше поедет тоже имя, что передано клиентом.
>
> Вообще никто не мешает вместо
>
> proxy_pass https://www.domain.ru;
>
> написать
>
> upstream www.domain.ru {
> server www.domain.ru:443 ...;
>
> }
> и строку proxy_pass вообще не менять, тогда ничего в плане переданных имен не
> поменяется.
>
> ___
> 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
Re: no live upstreams while connecting to upstream
proxy_http_version 1.1; и proxy_set_header Connection '' помогли, по крайней
мере 502 больше не вижу. Уточните, пожалуйста, можно ли еще как-то не
прописывать явно “proxy_set_header Host tratutu” в конфиге, чтоб он правильный
хост передавал на апстрим вместо tratata?
Евгений
> On 9 Jan 2019, at 00:33, Eugene Toropov wrote:
>
> Спасибо :) Опередили меня :) Пробую proxy_http_version 1.1;
>
>> On 9 Jan 2019, at 00:29, Alexey via nginx-ru wrote:
>>
>>
>> 09.01.2019 0:08, Eugene Toropov пишет:
>>> С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL:
>>> error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL
>>> handshaking to upstream” (апстрим на httpS) - буду разбираться с SSL.
>>
>>
>> Это ошибка сразу же ? порт надо явно указать в upstream tra { server
>> x.x.x.x:443 ...} и в проксипас уже proxy_pass https://tra ; секция upstream
>> не в курсе откуда её будут звать и по умолчанию там :80, если её позвать
>> потом https то будет как Вы написали.
>>
>>
>> апстрим умеет http/1.1 и он включен со стороны нгинкса (со сбросом
>> proxy_set_header Connection '') ?
>> если нет, то новое ssl соединение устанавливается на каждое соединение с
>> апстримом. Это дорого. если апстрим умеет http/1.1 и кипалайв, то ОЧЕНЬ
>> рекомендуется их включить. (если конечно есть достаточно веские аргументы
>> для вообще использования https для связи между nginx и апстримом. SSL дорог
>> и хандшейк медленен, на новых процах и правильно собранном openssl несколько
>> быстрее, но всеравно чертовски медленнен..., но кипалайв всеравно снизит
>> нагрузку, даже без ssl, опять же количество соединений с 1 портом
>> ограничено, и учитывая что по умолчапнию реюз запрещен, то порт остается
>> занятым много дольше, чем он используется) Да и всякие лимиты nfile.
>>
>> /Алексей
>> ___
>> 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
Re: no live upstreams while connecting to upstream
Спасибо :) Опередили меня :) Пробую proxy_http_version 1.1;
> On 9 Jan 2019, at 00:29, Alexey via nginx-ru wrote:
>
>
> 09.01.2019 0:08, Eugene Toropov пишет:
>> С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL:
>> error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL
>> handshaking to upstream” (апстрим на httpS) - буду разбираться с SSL.
>
>
> Это ошибка сразу же ? порт надо явно указать в upstream tra { server
> x.x.x.x:443 ...} и в проксипас уже proxy_pass https://tra ; секция upstream
> не в курсе откуда её будут звать и по умолчанию там :80, если её позвать
> потом https то будет как Вы написали.
>
>
> апстрим умеет http/1.1 и он включен со стороны нгинкса (со сбросом
> proxy_set_header Connection '') ?
> если нет, то новое ssl соединение устанавливается на каждое соединение с
> апстримом. Это дорого. если апстрим умеет http/1.1 и кипалайв, то ОЧЕНЬ
> рекомендуется их включить. (если конечно есть достаточно веские аргументы для
> вообще использования https для связи между nginx и апстримом. SSL дорог и
> хандшейк медленен, на новых процах и правильно собранном openssl несколько
> быстрее, но всеравно чертовски медленнен..., но кипалайв всеравно снизит
> нагрузку, даже без ssl, опять же количество соединений с 1 портом ограничено,
> и учитывая что по умолчапнию реюз запрещен, то порт остается занятым много
> дольше, чем он используется) Да и всякие лимиты nfile.
>
> /Алексей
> ___
> 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
Re: no live upstreams while connecting to upstream
Я, кстати, не указал :443 порт у server в upstream-е - поэтому и такую ошибку
получил. Более подробно здесь -
https://stackoverflow.com/questions/53245818/nginx-upstream-to-https-host-ssl3-get-recordwrong-version-number
Евгений
> On 9 Jan 2019, at 00:08, Eugene Toropov wrote:
>
> С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL:
> error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL
> handshaking to upstream” (апстрим на httpS) - буду разбираться с SSL.
>
> Всем спасибо и спокойной ночи!
>
> Евгений
>
>> On 8 Jan 2019, at 23:54, Alexey via nginx-ru > <mailto:nginx-ru@nginx.org>> wrote:
>>
>> 08.01.2019 23:50, Eugene Toropov пишет:
>>> Зачем мне upstream, если я использую proxy_pass:
>>>
>>> location / {
>>> proxy_pass xx;
>>> }
>>> ?
>>
>> да, сорри, во второй случае должно было быть proxy_pass
>>
>> Еще раз, если Вы не описали апстрим для проксипаса, то это не значит что его
>> нет и в нем нет умолчаний. Если умолчания не подходят, то значит надо
>> описать таки апстрим самостоятельно с нужными параметрами.
>>
>>>> On 8 Jan 2019, at 23:48, Alexey via nginx-ru >>> <mailto:nginx-ru@nginx.org>> wrote:
>>>>
>>>> 08.01.2019 23:40, Eugene Toropov пишет:
>>>>> Я не совсем понял, при чем здесь параметр max_fails - его на странице
>>>>> proxy модуля нет нигде -
>>>>> http://nginx.org/en/docs/http/ngx_http_proxy_module.html
>>>>> <http://nginx.org/en/docs/http/ngx_http_proxy_module.html> - я что-то
>>>>> пропустил?
>>>>>
>>>> ustream tratata {
>>>>
>>>> server tratutu:80 max_fails=XXX;
>>>>
>>>> }
>>>>
>>>>
>>>> server {
>>>>
>>>> location / {
>>>>
>>>> proxy_pass http://tratata <http://tratata/>;
>>>>
>>>> ...
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> если Вы явно не указали upstream, то это не значит что там нет никаких
>>>> умолчаний... укажите явно, впишите туда max_fails=0
>>>>
>>>> ___
>>>> nginx-ru mailing list
>>>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>> <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
>>
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: no live upstreams while connecting to upstream
С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL:
error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL
handshaking to upstream” (апстрим на httpS) - буду разбираться с SSL.
Всем спасибо и спокойной ночи!
Евгений
> On 8 Jan 2019, at 23:54, Alexey via nginx-ru wrote:
>
> 08.01.2019 23:50, Eugene Toropov пишет:
>> Зачем мне upstream, если я использую proxy_pass:
>>
>> location / {
>> proxy_pass xx;
>> }
>> ?
>
> да, сорри, во второй случае должно было быть proxy_pass
>
> Еще раз, если Вы не описали апстрим для проксипаса, то это не значит что его
> нет и в нем нет умолчаний. Если умолчания не подходят, то значит надо описать
> таки апстрим самостоятельно с нужными параметрами.
>
>>> On 8 Jan 2019, at 23:48, Alexey via nginx-ru wrote:
>>>
>>> 08.01.2019 23:40, Eugene Toropov пишет:
>>>> Я не совсем понял, при чем здесь параметр max_fails - его на странице
>>>> proxy модуля нет нигде -
>>>> http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я что-то
>>>> пропустил?
>>>>
>>> ustream tratata {
>>>
>>> server tratutu:80 max_fails=XXX;
>>>
>>> }
>>>
>>>
>>> server {
>>>
>>> location / {
>>>
>>> proxy_pass http://tratata <http://tratata/>;
>>>
>>> ...
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> если Вы явно не указали upstream, то это не значит что там нет никаких
>>> умолчаний... укажите явно, впишите туда max_fails=0
>>>
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>> <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: no live upstreams while connecting to upstream
Я не совсем понял, при чем здесь параметр max_fails - его на странице proxy модуля нет нигде - http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я что-то пропустил? Евгений > On 8 Jan 2019, at 23:10, Alexey via nginx-ru wrote: > > 08.01.2019 21:01, Eugene Toropov пишет: >> Добрый вечер, >> >> Тогда получается ситуация, при которой часть запросов файрвол пропускает, а >> часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. >> Как nginx определяет, что апстрим живой? Любой статус, отличный от 200? > > > > посмотрите описание proxy_next_upstream > > > Директива также определяет, что считается неудачной попыткой работы с > сервером. Случаи error, timeout и invalid_header всегда считаются неудачными > попытками, даже если они не указаны в директиве. Случаи http_500, http_502, > http_503, http_504 и http_429 считаются неудачными попытками, только если они > указаны в директиве. Случаи http_403 и http_404 никогда не считаются > неудачными попытками. > > и директиву server из секции описания upstream > > max_fails=число > задаёт число неудачных попыток работы с сервером, которые должны > произойти в течение времени, заданного параметром fail_timeout, чтобы сервер > считался недоступным на период времени, также заданный параметром > fail_timeout. По умолчанию число попыток устанавливается равным 1. Нулевое > значение отключает учёт попыток. Что считается неудачной попыткой, > определяется директивами proxy_next_upstream, fastcgi_next_upstream, > uwsgi_next_upstream,scgi_next_upstream, memcached_next_upstream и > grpc_next_upstream. > > > если апстрим реально один, то укажите ему max_fails=0 > > А вообще смотрите запросы рядом с первым 502. там скорее всего гдето > случились таймауты, единственный апстрим отметился как фейл и на время > fail_timeout(10с по умолчанию) выпадает из работы. > > /Алексей > > ___ > 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
Re: no live upstreams while connecting to upstream
Я тестовый скрипт запускаю с того же сервера, где nginx крутится, и он всегда работает, если запрос идет напрямую на апстрим. Так что больше похоже на то, что проблема где-то в конфигурации nginx :( Евгений > On 8 Jan 2019, at 21:41, pnz.stalker--- via nginx-ru > wrote: > > 08.01.2019 21:29, Eugene Toropov пишет: > > Что значит -3 на вскидку не помню.. Над исходники смотреть. > Есть мнение, что со стороны апстрима стоят лимиты на количество подключений с > 1 IP адреса/keep-alive соединений. > Когда перезапускаете nginx "старые" соединения сбрасываются и пока лимит не > достигнут всё работает. Смотрите логи апстримов. > >> После nginx reload первые несколько запросов проходят с тестового скрипта >> через nginx к апстриму, дальше стабильно 502 вот с таким дебаг логом: >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 posix_memalign: >> 560601D430F0:4096 @16 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http cleanup add: >> 560601758258 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 get rr peer, try: 8 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http upstream connect: >> -3 >> 2019/01/08 18:21:59 [error] 23082#23082: *1842235429 no live upstreams while >> connecting to upstream, client: 192.168.42.25, server: xxx, request: "POST >> /x HTTP/1.1", upstream: “x", host: “x" >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http next upstream, >> 4000 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http upstream >> request: 502 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http proxy >> request >> Вопрос по “http upstream connect: -3” - это стандартная ошибка коннекта? > ___ > 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
Re: no live upstreams while connecting to upstream
После nginx reload первые несколько запросов проходят с тестового скрипта через nginx к апстриму, дальше стабильно 502 вот с таким дебаг логом: 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 posix_memalign: 560601D430F0:4096 @16 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http cleanup add: 560601758258 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 get rr peer, try: 8 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http upstream connect: -3 2019/01/08 18:21:59 [error] 23082#23082: *1842235429 no live upstreams while connecting to upstream, client: 192.168.42.25, server: xxx, request: "POST /x HTTP/1.1", upstream: “x", host: “x" 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http next upstream, 4000 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http upstream request: 502 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http proxy request Вопрос по “http upstream connect: -3” - это стандартная ошибка коннекта? Евгений > On 8 Jan 2019, at 21:15, pnz.stalker--- via nginx-ru > wrote: > > 08.01.2019 21:01, Eugene Toropov пишет: > >> Тогда получается ситуация, при которой часть запросов файрвол пропускает, а >> часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. >> Как nginx определяет, что апстрим живой? Любой статус, отличный от 200? > > Ну как вариант сеть перегружена или ещё какие сетевые проблемы по пути от > нигкса до апстримов. > > В общем в момент проблемы смотреть логи, проверять связность между nginx и > апстримами. Смотреть логи апстримов. Попробовать тестовым скриптом > цепануться с nginx к апстриму > ___ > 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
Re: no live upstreams while connecting to upstream
Добрый вечер, Тогда получается ситуация, при которой часть запросов файрвол пропускает, а часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. Как nginx определяет, что апстрим живой? Любой статус, отличный от 200? Евгений > On 8 Jan 2019, at 16:00, pnz.stalker--- via nginx-ru > wrote: > > > И Вас с прошедшими... > > Проверьте, что по пути от nginx до апстримов нет блокировок файрволлами или > ещё чем либо. > > То есть что апстримы доступны для nginx > > 08.01.2019 14:34, Eugene Toropov пишет: >> Добрый день, >> Всех с праздниками! >> Может кто знает - валятся ошибки "no live upstreams while connecting to >> upstream”. Если слать запрос не через nginx, а напрямую на апстрим в >> тестовом скрипте - все работает. Как только меняешь endpoint на nginx - 502 >> Bad Gateway с такой ошибкой. > ___ > 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
no live upstreams while connecting to upstream
Добрый день, Всех с праздниками! Может кто знает - валятся ошибки "no live upstreams while connecting to upstream”. Если слать запрос не через nginx, а напрямую на апстрим в тестовом скрипте - все работает. Как только меняешь endpoint на nginx - 502 Bad Gateway с такой ошибкой. # nginx -V nginx version: nginx/1.14.0 (Ubuntu) built with OpenSSL 1.1.0g 2 Nov 2017 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-FIJPpj/nginx-1.14.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module Евгений eugene.toro...@gmail.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: апстрим режет запросы?
А можно здесь поподробнее? Я не настолько крут в strace. Евгений > 31 дек. 2017 г., в 9:14, Илья Шипицин <chipits...@gmail.com> написал(а): > > SNI ? Покажите снифер? > >> On Dec 31, 2017 12:47 AM, "Eugene Toropov" <eugene.toro...@gmail.com> wrote: >> Добрый вечер, >> >> Всех с наступающим! >> >> Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и >> вижу >> >> 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream >> prematurely closed connection while reading response header from upstream, >> client: 192.168.42.32, server: gta, request: \"POST >> /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b >> HTTP/1.1\", upstream: >> \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4;..., >> 577 >> >> то это по-любому проблема апстрима или все-таки есть шанс бага на моей >> стороне? >> >> Евгений >> >> > On 7 Dec 2017, at 16:25, Eugene Toropov <eugene.toro...@gmail.com> wrote: >> > >> > Добрый день, >> > >> > Ситуация следующая: >> > >> > 1) В error логе куча ошибок вида: >> > >> > 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely >> > closed connection while reading response header from upstream, client: >> > 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: >> > “", host: “xxx:8080" >> > >> > 2) В access логе соотв запросы имеют код ответа 502 и $request_time всегда >> > около 4 секунд? >> > >> > Это похоже на то, что апстрим режет запросы rps фильтром? >> > >> > Евгений >> > >> > >> >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: апстрим режет запросы?
Добрый вечер, Всех с наступающим! Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4;..., 577 то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне? Евгений > On 7 Dec 2017, at 16:25, Eugene Toropov <eugene.toro...@gmail.com> wrote: > > Добрый день, > > Ситуация следующая: > > 1) В error логе куча ошибок вида: > > 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely closed > connection while reading response header from upstream, client: > 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “", > host: “xxx:8080" > > 2) В access логе соотв запросы имеют код ответа 502 и $request_time всегда > около 4 секунд? > > Это похоже на то, что апстрим режет запросы rps фильтром? > > Евгений > > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
апстрим режет запросы?
Добрый день, Ситуация следующая: 1) В error логе куча ошибок вида: 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “", host: “xxx:8080" 2) В access логе соотв запросы имеют код ответа 502 и $request_time всегда около 4 секунд? Это похоже на то, что апстрим режет запросы rps фильтром? Евгений ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
proxy_cache gzip
Добрый вечер, У меня странная (на мой взгляд) ситуация - есть proxy_cache_path, через который ходят POST запросы с заголовком “Accept-Encoding: gzip”. В коде клиента в ответе от nginx-а я вижу gzip-нутый body и “Content-Encoding: gzip”, но tcpflow показывает, что между nginx-ом и апстримом никакого gzip-а нет. Более того, я нашел закэшированный в папке proxy_cache_path-а файл и убедился, что контент там не gzip-нутый (хотя ключ кэша - $host$request_uri $http_accept_encoding” - и в моем примере я точно вижу “gzip” на месте $http_accept_encoding). Подскажите, пожалуйста, как заставить nginx работать с апстримом по gzip-у? Евгений ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 1 basic auth - много субдоменов
Вам сложно ответить, если знаете? Или вы его прочитали для того, что посылать всех на RTFM? On Oct 10, 2014, at 6:10 PM, Dmitry dmitry.goryai...@gmail.com wrote: А прочитать протокол? 10 окт. 2014 г. 17:55 пользователь Eugene Toropov eugene.toro...@gmail.com написал: Добрый вечер, Возможно ли настроить HTTP Basic Authentication (auth_basic/auth_basic_user_file) так чтоб однажды успешная авторизация работала на всех субдоменах? Евгений ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 1 basic auth - много субдоменов
On Oct 10, 2014, at 6:44 PM, Styopa Semenukha semenu...@gmail.com wrote: On Friday, October 10, 2014 05:55:33 PM Eugene Toropov wrote: Добрый вечер, Возможно ли настроить HTTP Basic Authentication (auth_basic/auth_basic_user_file) так чтоб однажды успешная авторизация работала на всех субдоменах? Евгений ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Насколько я понимаю, нельзя: http://stackoverflow.com/questions/339244/using-apaches-mod-auth-across-multiple-sub-domains-for-single-sign-on -- Best regards, Styopa Semenukha. Похоже на то. Спасибо. Хороших выходных :) Евгений ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
