Hello!
On Thu, Jan 12, 2023 at 04:37:40PM +0300, Sergey K wrote:
> В документации сказано, что можно использовать upstream с переменными
> (stream module).
>
>
> proxy_pass $upstream;
> В этом случае имя сервера ищется среди описанных групп серверов и если не
> найде
Это, видимо, неточность документации, надо днс имя + пустую переменную
непосредственно в proxy_pass, а upstream по крайней мере в опенсорс
варианте днс ресолвтт на момент релоада
On Thu, Jan 12, 2023, 7:37 PM Sergey K wrote:
> В документации сказано, что можно использовать upstrea
В документации сказано, что можно использовать upstream с переменными
(stream module).
proxy_pass $upstream;
В этом случае имя сервера ищется среди описанных групп серверов и если не
найдено, то определяется с помощью resolver’а.
Однако, в случае изменения айпи адреса для
Hello!
On Tue, Sep 20, 2022 at 08:51:30PM +0300, Igor Savenko wrote:
> Сама проблема в том, что nginx да, ругается в логе, но при этом он еще и
> отдает 502 ошибку. Поэтому просто искали способ хотя бы игнорировать
> некорректные заголовки, но пропускать ответ бекэнда клиенту
Сообщение в логе
нные, как в директиве proxy_ignore_headers
> > <
> http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers
> >
> > ?
>
> Судя по выводу curl'а, между предыдущим заголовком и expires
> вместо CRLF или LF стоит просто CR. В логах nginx'а при это
tml#proxy_ignore_headers>
> ?
Судя по выводу curl'а, между предыдущим заголовком и expires
вместо CRLF или LF стоит просто CR. В логах nginx'а при этом
должна быть какая-то такая ошибка:
2022/09/20 12:59:16 [error] 2866#100147: *1 upstream sent invalid header:
"X-Foo: foo\x0d..." wh
Добрый день! Странная ситуация, апстримом для nginx является лайтспид, и
вот этот лайтспид на http2 отдает нормальные заголовки ответа, а для
http/1.1 некорректные, например, вот это выводит curl:
curl -s -v --http1.1 -o /dev/null https://domain.com/images/12345.png
--resolve
Ух! забористо :)
спасибо за подробное описание - правда я, как чайник, сразу все не осилю:
скажу что сложности в понимании и настройки keepAlive для связки
браузер-nginx-гupstreams стало больше
Хорошо бы если было бы описание на примере разбора и установки параметров
для всей цепочки
Со стороны
может и лучше есть.
>
>
> в принципе пасьянс складывается примерно из следующих компонентов (киньте
> ссылку, если есть готовая документация, сохраню себе)
>
> 1) если вы описываете upstream без keepalive, то соединение закрывается
> каждый раз
> 2) максимальное число запро
я не совсем про порты. это скорее был пример, какая документация
вспомнилась про эту тему. может и лучше есть.
в принципе пасьянс складывается примерно из следующих компонентов (киньте
ссылку, если есть готовая документация, сохраню себе)
1) если вы описываете upstream без keepalive, то
с эфимерными портами все понятно
вопрос в другом: Nginx имеет настройку keepAliveTimeout для браузера, при
этом он устанавливает соединение с upstream сервером у которого есть свои
настройки keepAliveTimeout - как все это связано между собой? как Nginx
работает с соединениями в upstream (также
t; для Nginx так и для серверов в upstream.
>
> Каково вообще оптимальное значение этого параметра для клиента в браузере
> для обычного web-приложения в Nginx?
>
> Удерживает ли Nginx alive соединение с серверами в upstream?
>
> Какими должны быть эти значения чтобы оптимал
Добрый день!
Хотелось бы понять суть и установить верные значения keepAliveTimeout как
для Nginx так и для серверов в upstream.
Каково вообще оптимальное значение этого параметра для клиента в браузере
для обычного web-приложения в Nginx?
Удерживает ли Nginx alive соединение с серверами в
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 стоит 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
Hello!
On Tue, May 25, 2021 at 12:15:54PM +0300, Gena Makhomed wrote:
> On 24.05.2021 6:05, Maxim Dounin wrote:
>
> >>> Можете поставить haproxy - он как раз будет держать клиента секунд 10,
> >>> пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд,
> >>> но зато он не получит
On Tue, May 25, 2021 at 12:15:54PM +0300, Gena Makhomed wrote:
> >Но вообще если перезапуск php-бэкенда под боевой нагрузкой
> >считается нормальным рабочим действием, то браузер так или иначе
> >имеет шанс получить неполный ответ же. Пытаться в подобной
> >ситуации ещё и ошибки обрабатывать - как
On 24.05.2021 6:05, Maxim Dounin wrote:
Можете поставить haproxy - он как раз будет держать клиента секунд 10,
пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд,
но зато он не получит 5хх ошибку.
Могу поставить haproxy, но haproxy - это не веб-сервер, он не умеет
отдавать
Hello!
On Sat, May 22, 2021 at 03:49:01PM +0300, Gena Makhomed wrote:
> On 22.05.2021 15:31, fox wrote:
>
> > Можете поставить haproxy - он как раз будет держать клиента секунд 10,
> > пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд,
> > но зато он не получит 5хх ошибку.
>
On 22.05.2021 18:22, Oleg A. Mamontov wrote:
Функциональность, позволяющая реализовать подобную логику,
имеется в коммерческой версии:
http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#queue
Хостинг сайтов на PHP - это не тот бизнес, который даст возможность
купить коммерческую
On Sat, May 22, 2021 at 03:49:01PM +0300, Gena Makhomed wrote:
On 22.05.2021 15:31, fox wrote:
Можете поставить haproxy - он как раз будет держать клиента секунд
10, пока бекэнды перезагружаются. Браузеру придётся ждать эти 10
секунд,
но зато он не получит 5хх ошибку.
Могу поставить
On 22.05.2021 15:31, fox wrote:
Можете поставить haproxy - он как раз будет держать клиента секунд 10,
пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд,
но зато он не получит 5хх ошибку.
Могу поставить haproxy, но haproxy - это не веб-сервер, он не умеет
отдавать статику.
зывается в нерабочем состоянии,
поэтому использую именно "systemctl restart php-fpm" для изменения
конфигурации php-fpm, тогда и случаются 502 ошибки с сайтами.
В таком случае, может быть, сконфигурить 2 бэкенда, отличающиеся лишь
сокетами (и какими-нибудь pid-файлами), описать их в одном upstrea
отличающиеся лишь
сокетами (и какими-нибудь pid-файлами), описать их в одном upstream{}
и не перезапускать php-fpm, а поднимать 2й и гасить 1й?
Да, так работает. Но поднимать на сервере два бэкенда -
это - в два раза больше работы. Поэтому очень хочется
этой лишней работы избежать и обойтись о
есть несколько лайфхаков, которые упрощают жизнь, когда у вас единственный
бекенд (но ответа на ваш вопрос у меня нет)
1) можно, и пожалуй, нужно указывать max_fails=0 (чтобы не держать бекенд в
грейлисте, а максимально пытаться отправлять на него запросы)
2) можно продублировать бекенд
В таком случае, может быть, сконфигурить 2 бэкенда, отличающиеся лишь
сокетами (и какими-нибудь pid-файлами), описать их в одном upstream{}
и не перезапускать php-fpm, а поднимать 2й и гасить 1й?
--
Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.
m/www.sock failed (2: No such file or
directory) while connecting to upstream
Сокет /run/php-fpm/www.sock отсутствует во время перезапуска php-fpm.
Если же речь о ребуте хоста php-fpm, то либо бэкенд в локальной сети и
оказывается недоступен по arp-у, тогда EHOSTUNREACH возвращается п
On Fri, May 21, 2021 at 12:05:45AM +0300, Gena Makhomed wrote:
> Есть nginx, который проксирует запросы на единственный бекенд php-fpm.
> Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки.
>
> Каким образом можно настроить nginx так, чтобы он в случае ошибки
> связи с бекендом
Здравствуйте, All!
Есть nginx, который проксирует запросы на единственный бекенд php-fpm.
Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки.
Каким образом можно настроить nginx так, чтобы он в случае ошибки
связи с бекендом пытался достучаться до него в течении N секунд
(например,
Здравствуйте.
Создал балансировщик на 10 кэширующих серверов.
Использовал consistent hash по $request_uri
upstream cacheserver {
hash $request_uri consistent;
server 10.0.0.2:8080 max_fails=0;
server 10.0.0.3:8080 max_fails=0;
server 10.0.0.4:8080 max_fails=0;
server 10.0.0.5:8080 max_fails=0
вую.
>
> Как запустить nginx. при условии, если часть серверов в upstream
> недоступны?
>
> upstream upstream-agw {
> ip_hash;
> server i18s-a-agw1:8080 max_fails=0;
> server i18s-a-agw3:8080 max_fails=0;
> }
>
> i18s-a-agw1:8080 - доступен!
> i18s-a-agw3
Приветствую.
Как запустить nginx. при условии, если часть серверов в upstream
недоступны?
upstream upstream-agw {
ip_hash;
server i18s-a-agw1:8080 max_fails=0;
server i18s-a-agw3:8080 max_fails=0;
}
i18s-a-agw1:8080 - доступен!
i18s-a-agw3:8080 - На момент запуска не резолвится
анных ключей
> > Вот конфигурация
> > upstream backend {
> > hash 'balance';
> > server [::1]:81 weight=100 fail_timeout=60;
> > server [::1]:82 weight=100 fail_timeout=60;
> > server [::1]:83 weight=1 fail_timeout=60;
> > server [::1]:84 wei
Hello!
On Fri, Nov 06, 2020 at 11:28:16AM -0800, Nikita Koshikov wrote:
> Спасибо больше, Максим
>
> Хотелось бы уточнить насчет перехешированных ключей
> Вот конфигурация
> upstream backend {
> hash 'balance';
> server [::1]:81 weight=100 fail_timeout=60;
>
Спасибо больше, Максим
Хотелось бы уточнить насчет перехешированных ключей
Вот конфигурация
upstream backend {
hash 'balance';
server [::1]:81 weight=100 fail_timeout=60;
server [::1]:82 weight=100 fail_timeout=60;
server [::1]:83 weight=1 fail_timeout=60;
server [::1]:84
Hello!
On Fri, Nov 06, 2020 at 09:40:14AM -0800, Nikita Koshikov wrote:
> Доброго всем времени суток
>
> Подскажите как можно сделать что-то максимально подобное для выбора
> backend сервера по приоритету, в идеале нужно что-то
>
> upstream backend {
> serve
сибо,
>> Имеется ввиду два бекенда один из который с backup ?
>>
>> upstream c1 {
>> server [::1]:81 ;
>> server [::1]:82 backup;
>> }
>>
>> upstream c2 {
>> server [::1]:83 ;
>> server [::1]:84 backup;
>> }
&
, Nikita Koshikov :
> Спасибо,
> Имеется ввиду два бекенда один из который с backup ?
>
> upstream c1 {
> server [::1]:81 ;
> server [::1]:82 backup;
> }
>
> upstream c2 {
> server [::1]:83 ;
> server [::1]:84 backup;
> }
>
> server {
Спасибо,
Имеется ввиду два бекенда один из который с backup ?
upstream c1 {
server [::1]:81 ;
server [::1]:82 backup;
}
upstream c2 {
server [::1]:83 ;
server [::1]:84 backup;
}
server {
location {
proxy_pass http://c1
error_page @c2
}
}
Или что-то другое
можно проксировать на самого себя каскадом.
на каждом каскаде 2 бекенда
пт, 6 нояб. 2020 г. в 22:40, Nikita Koshikov :
> Доброго всем времени суток
>
> Подскажите как можно сделать что-то максимально подобное для выбора
> backend сервера по приоритету, в идеале нужно что-то
&g
Доброго всем времени суток
Подскажите как можно сделать что-то максимально подобное для выбора
backend сервера по приоритету, в идеале нужно что-то
upstream backend {
server [::1]:81 priority=1;
server [::1]:82 priority=2;
server [::1]:83 priority=3;
server [::1]:84 priority=4
Спасибо, Максим!
Да, тестово получилось повторить, дело действительно в delayed Ack.
On 9/4/20 6:38 PM, Maxim Dounin wrote:
Hello!
On Fri, Sep 04, 2020 at 01:33:18PM +0300, Panichev Oleg wrote:
При включении keepalive в секции upstream для fastcgi серверов
upstream_response_time
Hello!
On Fri, Sep 04, 2020 at 01:33:18PM +0300, Panichev Oleg wrote:
> При включении keepalive в секции upstream для fastcgi серверов
> upstream_response_time увеличивается на 40мс при нагрузке. Это
> достаточно четкий шаг,
> реальный ответ бэкендову нас - единицы миллисеку
. в 13:33, Panichev Oleg mailto:panic...@rutarget.ru>>:
Добрый день.
При включении keepalive в секции upstream для fastcgi серверов
upstream_response_time увеличивается на 40мс при нагрузке. Это
достаточно четкий шаг, реальный ответ бэкендову нас - единицы
миллисеку
95% 44
> 98% 44
> 99% 45
>
> 100% 47 (longest request)
>
>
>
> On 9/4/20 2:07 PM, Сергей Олегович wrote:
>> Интересно, а есть ли зависимость между количеством keepalive и временем?
>>
>> пт, 4 сент. 2020 г. в 13:33, Panichev Oleg > &
13:33, Panichev Oleg <mailto:panic...@rutarget.ru>>:
Добрый день.
При включении keepalive в секции upstream для fastcgi серверов
upstream_response_time увеличивается на 40мс при нагрузке. Это
достаточно четкий шаг, реальный ответ бэкендову нас - единицы
миллисекунд,
Интересно, а есть ли зависимость между количеством keepalive и временем?
пт, 4 сент. 2020 г. в 13:33, Panichev Oleg :
> Добрый день.
>
>
> При включении keepalive в секции upstream для fastcgi серверов
> upstream_response_time увеличивается на 40мс при нагрузке. Это
> дос
Добрый день.
При включении keepalive в секции upstream для fastcgi серверов
upstream_response_time увеличивается на 40мс при нагрузке. Это
достаточно четкий шаг, реальный ответ бэкендову нас - единицы
миллисекунд, но nginx показывает на 40мс больше. Apache benchmark tool
показывает тоже
> Если уж страдать под виндой, то по полной! Докер уже давно завезли, а там
> глядишь и линукс внутри есть.
Завезли и докер с линуксом, завезли
WSL(https://docs.microsoft.com/ru-ru/windows/wsl/install-win10), завезли
идущую в комплекте виртуальную машину, но иногда не завозят мозги
заказчикам.
чт, 30 апр. 2020 г. в 13:47, gewisser :
>
> Под линуксом, я могу закрыть соединение отправив мессадж в FPM выполнив
> метод "fastcgi_finish_request()". Дайте мне "такое же" под Windows, чтобы
> проект мог хоть как-то одинаково работать и под этой ОС.
>
>
Если уж страдать под виндой, то по полной!
> Я об этом писал в самом первом ответе - в конфиге nginx'а
> выключить keepalive с помощью директивы keepalive_timeout
> (http://nginx.org/r/keepalive_timeout/ru).
Это не есть решение вопроса. Если выключу, то выключу для всех соединений.
Мне нужен работающий keepalive.
Так же не подходит:
Hello!
On Wed, Apr 29, 2020 at 12:46:23PM -0400, gewisser wrote:
> Есть какая-нибудь возможность отправить "Connection: close"?
Я об этом писал в самом первом ответе - в конфиге nginx'а
выключить keepalive с помощью директивы keepalive_timeout
(http://nginx.org/r/keepalive_timeout/ru).
--
Есть какая-нибудь возможность отправить "Connection: close"?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,287560,287884#msg-287884
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
On Wed, Apr 22, 2020 at 12:55:02PM +0500, Илья Шипицин wrote:
>ср, 22 апр. 2020 г. в 12:51, Evgeniy Berdnikov <[1]b...@protva.ru>:
>
> On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
> > но вы понимаете, что речь идет о stream-проксировании, т.е. вы
> просто
ср, 22 апр. 2020 г. в 12:51, Evgeniy Berdnikov :
> On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
> >но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто
> tcp
> >поток отправляете на тот или иной бекенд и терминация SSL будет уже на
> >бекенде?
>
>
On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
>но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто tcp
>поток отправляете на тот или иной бекенд и терминация SSL будет уже на
>бекенде?
Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello
и
да, на этом можно попробовать собрать map.
но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто tcp
поток отправляете на тот или иной бекенд и терминация SSL будет уже на
бекенде?
ср, 22 апр. 2020 г. в 12:19, nerkas :
> Илья.
> Да, верно. Например, браузер Chromium GOST
Илья.
Да, верно. Например, браузер Chromium GOST отправляет аж 22 шифра на выбор
(https://imgur.com/a/YdFmCld).Из них 4 это ГОСТ.
Я думал о варианте, что если какой-нибудь из GOST_ есть, то сразу отправлять
на ГОСТ_ вебсервер, а там где ГОСТ-а нет, слать на другой.
Posted at Nginx Forum:
ьзя получить Cipher suites, и на основе его
> выбрать upstream.
> У нас имеется два вебсервера, на которых надо терменировать SSL-трафик,
> один
> из них поддерживает ГОСТ-ое шифрование (TLS_GOSTR341001_WITH_28147_CNT_IMIT
> и ему подобные).
> Необходимо на основе Client Hello (гд
Добрый день,
У nginx есть отличный модуль ngx_stream_ssl_preread_module, позволяющий
информацию из ClientHello.
К сожалению с его помощью нельзя получить Cipher suites, и на основе его
выбрать upstream.
У нас имеется два вебсервера, на которых надо терменировать SSL-трафик, один
из них
> Проблема не в том, что nginx "последующий запрос ставит в очередь
> на этот апстрим и не выбирает другой", проблема в том, что запрос
> к бекенду - не завершён, и соответственно обработка запроса от
> клиента - не завершена. Очередной запрос от клиента в том же
> соединении по HTTP/1.1 - не
php.ini
> run php-cgi.exe -b 127.0.0.1:9005-c php.ini
>
> upstream backend {
> server 127.0.0.1:9001;
> server 127.0.0.1:9002;
> server 127.0.0.1:9003;
> server 127.0.0.1:9004;
> server 127.0.0.1
Всем привет. Имеем под windows:
run php-cgi.exe -b 127.0.0.1:9001-c php.ini
run php-cgi.exe -b 127.0.0.1:9002-c php.ini
run php-cgi.exe -b 127.0.0.1:9003-c php.ini
run php-cgi.exe -b 127.0.0.1:9004-c php.ini
run php-cgi.exe -b 127.0.0.1:9005-c php.ini
upstream backend
Hello!
On Mon, Jan 13, 2020 at 03:07:20PM -0500, yanda.a wrote:
> Maxim Dounin Wrote:
> ---
> > Hello!
> >
> > Где-то тут общение с бекендом завершено, однако ответ ещё не
> > полностью отправлен клиенту. В процессе отправки клиенте
> >
Maxim Dounin Wrote:
---
> Hello!
>
> Где-то тут общение с бекендом завершено, однако ответ ещё не
> полностью отправлен клиенту. В процессе отправки клиенте
> закрывает HTTP/2 stream:
Кстати да, я немного не досмотрел. В этом server {} не
ebug] 17855#17855: *29319057 event timer: 92, old:
> 7043363034, new: 7043363039
> 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 78, old:
> 704034, new: 704039
> 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http upstream exit:
>
>
r: 78, old:
704034, new: 704039
2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http upstream exit:
2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http upstream
request: 0
2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http proxy
request
2020/01/1
7855#17855: *29319057 http upstream exit:
2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http upstream
request: 0
2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http proxy
request
2020/01/13 02:28:13 [debug] 17855#17855: *29319057 free rr peer 2 0
2020/01/1
Hello!
On Mon, Jan 13, 2020 at 04:46:22AM -0500, yanda.a wrote:
> Maxim Dounin Wrote:
> ---
> > Hello!
> >
> > On Mon, Dec 30, 2019 at 03:22:01AM -0500, yanda.a wrote:
> >
> > > Добрался до конфигурации, скину почти полную конфигурацию:
> >
и:
if (!u->cacheable && u->peer.connection) {
ngx_log_error(NGX_LOG_INFO, ev->log, err,
"client prematurely closed connection, "
"so upstream connection is closed too");
ngx_h
Hello!
On Thu, Jan 09, 2020 at 02:53:53AM -0500, andrei_abc wrote:
> у меня есть конфигурация nignx v1.17.6 c oauth2_proxy v4.1.0-12-g7663565
> авторизация проходит через Azure.
[...]
> location / {
> auth_request /oauth2/auth;
> error_page 401 =
у меня есть конфигурация nignx v1.17.6 c oauth2_proxy v4.1.0-12-g7663565
авторизация проходит через Azure.
server {
listen 443 ssl;
server_name 127.0.0.1;
ssl_certificate ../nginx-selfsigned.crt;
ssl_certificate_key ../nginx-selfsigned.key;
Hello!
On Mon, Dec 30, 2019 at 03:22:01AM -0500, yanda.a wrote:
> Добрался до конфигурации, скину почти полную конфигурацию:
[...]
Смысла в "почти полной" конфигурации не очень много. Нужна
конфигурация, с которой воспроизводится то, на что вы жалуетесь.
Попробуйте воспроизвести проблемное
ive=40s;
open_file_cache_valid 60s;
open_file_cache_min_uses2;
open_file_cache_errors on;
open_log_file_cache max=500 inactive=30m
valid=10m min_uses=1;
variables_hash_max_size
rker_processes 1;
events {
worker_connections 1024;
}
http {
log_format test "status: $status\n"
"upstream_addr: $upstream_addr\n"
"upstream_status: $upstream_status";
access_log /dev/stderr test;
upstr
e
$scheme;
}
}
map $remote_addr $httpd {
default httpd;
}
upstream httpd {
server backend-01-1:8081 max_fails=5;
server backend-01-2:8081 max_fails=5;
}
}
Posted at
Maxim Dounin Wrote:
---
> Hello!
>
> При "proxy_ignore_client_abort on;" статуса 499 быть вообще не
> должно.
>
> Что показывает "nginx -V" и что в конфиге?
>
> --
> Maxim Dounin
> http://mdounin.ru/
>
Hello!
On Thu, Dec 26, 2019 at 02:20:37PM -0500, yanda.a wrote:
> Есть upstream с несколькими серверами. На этом upstream'е бывают очень
> долгие запросы (это уже другая история). Если клиент разорвал соединение, в
> логах будет $status = 499, но продолжаем ждать ответа от бекен
Добрый день!
Есть upstream с несколькими серверами. На этом upstream'е бывают очень
долгие запросы (это уже другая история). Если клиент разорвал соединение, в
логах будет $status = 499, но продолжаем ждать ответа от бекенда (опция
proxy_ignore_client_abort on), и если бекенд не отвалился по
z,now -pie'
> --with-ngx_http_upstream_module
> В итоге получаю
> ./configure: error: invalid option "--with-ngx_http_upstream_module"
> Пожалуйста помогите.
Уберите эту опцию, её не существует. Модуль upstream собирается
всегда, и каких-либо специальных опций для его сбор
Попробуй --with-http_upstream_module
19.12.2019 17:14, kurov.sergei пишет:
> Добрый день. Пытаюсь собрать nginx c модулем ngx_http_upstream_module
> добавил репозиторий, как описано в инструкции
> http://nginx.org/en/linux_packages.html#RHEL-CentOS
> Пробовал на CentOS6 и CentOS7
> Переустановил
Добрый день. Пытаюсь собрать nginx c модулем ngx_http_upstream_module
добавил репозиторий, как описано в инструкции
http://nginx.org/en/linux_packages.html#RHEL-CentOS
Пробовал на CentOS6 и CentOS7
Переустановил nginx, становиться версия 1.17.6, после исполняю
./configure --prefix=/etc/nginx
смотреть исходники
> >
> > вывод сообщения об ошибке встречается три раза
> >
> > ./nginx-1.17.4/src/http/ngx_http_upstream.c:
> > "upstream prematurely closed connection");
> > ./nginx-1.17.4/src/http/ngx_http_upstream.c:
> >"upstream
200, ему хорошо, все,
> что он хотел считать, он вычитал. повторяем несколько раз, в большинстве
> случаев ситуация повторяется, в логах ошибка, у клиента все хорошо.
>
> ок. идем смотреть исходники
>
> вывод сообщения об ошибке встречается три раза
>
> ./nginx-1.17.4/src
не мимо темы. мы просим из recv столько то данных, возвращается ноль.
дальнейшую отладку попробую собрать
пн, 14 окт. 2019 г. в 12:33, Evgeniy Berdnikov :
> On Mon, Oct 14, 2019 at 11:59:44AM +0500, Илья Шипицин wrote:
> >добавил отладку.
> >в recv передается не ноль. из recv
On Mon, Oct 14, 2019 at 11:59:44AM +0500, Илья Шипицин wrote:
>добавил отладку.
>в recv передается не ноль. из recv возвращается ноль.
Значит процитированный фрагмент man recv и все домыслы вокруг него
(насчёт специфики реализации в каком-то центосе) оказались мимо темы.
Теперь самое
gt; возможно, что 0 возращается по каким-то другим причинам, связанным с
> особенностью recv под centos
>
>
>
>> >собственно, в этом месте меняем текст. и, чудо, после этого
>> залогированные
>> > "upstream prematurely closed connection" идеально
ваться 0 в
recv (я попробую в это место отладку добавить),
возможно, что 0 возращается по каким-то другим причинам, связанным с
особенностью recv под centos
> >собственно, в этом месте меняем текст. и, чудо, после этого
> залогированные
> >"upstream prematurely closed con
нглийском, "requested number of bytes" -- это
значение аргумента len, т.е. ситуация, когда в recv() передают длину
буфера равную нулю, т.е. из сокета запрашивается чтение нуля байт.
Nginx действительно так делает?
>собственно, в этом месте меняем текст. и, чудо, после этого залогиров
случаев ситуация повторяется, в логах ошибка, у клиента все хорошо.
ок. идем смотреть исходники
вывод сообщения об ошибке встречается три раза
./nginx-1.17.4/src/http/ngx_http_upstream.c:
"upstream prematurely closed connection");
./nginx-1.17.4/src/http/ngx_http_upstream.c:
"upstr
добрый день,
вы можете не очень сложным образом собрать стенд (и пострелять по нему
curl-ом в режиме POST)
ответы на ваши вопросы зависят от многих "если". такие вещи лучше
обкатывать на стенде. что-то типа TDD (test driven development)
upstream upstream1 {
server 127.0.0.1:81;
Спасибо, а логируется ли в таких случаях в error log? Или только если все
апстримы фейлнули?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,285751,285753#msg-285753
___
nginx-ru mailing list
nginx-ru@nginx.org
> On 30 Sep 2019, at 07:40, rihad wrote:
>
> В случае если proxy апстрим не доступен на уровне сокета (ECONNREFUSED, а не
> просто вернулось HTTP 5хх), будет ли nginx ретраить POST запрос на следующих
> апстримах? По идее должен т.к. запрос никем не был принят и обработан.
В данном случае по
В случае если proxy апстрим не доступен на уровне сокета (ECONNREFUSED, а не
просто вернулось HTTP 5хх), будет ли nginx ретраить POST запрос на следующих
апстримах? По идее должен т.к. запрос никем не был принят и обработан.
Posted at Nginx Forum:
Тестирую использование кэша соединений для группы серверов.
Настройка дефолтная:
keepalive 32;
keepalive_timeout 30;
keepalive_requests 100;
proxy_connect_timeout 1;
proxy_send_timeout 60;
proxy_read_timeout 60;
При отключении одного бекенда из апстрима, ловим порядка 6-8
> Не совсем так. Если у вас один из N возвращаемых из DNS бэкендов
> нерабочий - то при исползовании переменных с вероятностью 1/N
> nginx попытается сначала отправить запрос именно на него, и
> получит ошибку. После чего пойдёт на другой бэкенд в соответствии
> с proxy_next_upstream.
На другой
; > я бы проверил это в первую очередь.
>
> Да, в моем случае в переменной DNS адрес, который резолвится с помощью
> резолвера и адрес точно резолвится в несколько адресов.
> Таким образом получается, что при каждом запросе создается новый upstream с
> адресом в который разрезолв
рес, который резолвится с помощью
резолвера и адрес точно резолвится в несколько адресов.
Таким образом получается, что при каждом запросе создается новый upstream с
адресом в который разрезолвилась переменная и пока этот адрес есть в
резолвере, каждый новый запрос будет фейлить?
Кажется крутым реше
и
> запросы на бэкенд, но быстро запросы восстановились. Поискал в логах, в
> итоге нашел такие ошибки:
>
> 2019/05/24 08:40:26 [warn] 308#308: *1978088914 upstream server temporarily
> disabled while reading response header from upstream, client: x.x.x.x,
> server: , req
Не Nginx, но бесплатно:
https://www.haproxy.com/blog/dns-service-discovery-haproxy/
С уважением,
Александр
вт, 19 мар. 2019 г. в 17:30, Иван :
> Здравствуйте!
>
>
> Есть необходимость выбирать апстрим для проксирования на основании
> информации из mysql-базы. Есть мысль задействовать для этого
Результаты 1 - 100 из 377 matches
Mail list logo
