Re: nginx открывает не ту директорию
Добрый день. > On 5 Feb 2020, at 11:41, artesah wrote: > > Доброго времени суток, Господа. > Ситуация следующая, после обновления сервера веб сервер начал направлять не > в ту директорию. > Лог: > 2020/02/05 11:28:23 [error] 2329#2329: *7 open() > "/usr/share/nginx/html/zabbix.php" failed (2: No such file or directory), > client: мой ip1, server: localhost, request: "GET /zabbix.php HTTP/1.1", > host: "хост" > > В то время как директория сайта находиться на /usr/share/zabbix > В конфиге /etc/nginx/conf.d/zabbix.conf прописан set $webroot > '/usr/share/zabbix'; > А в основном /etc/nginx/nginx.conf записан include > /etc/nginx/conf.d/zabbix.conf; > > В чем может быть проблема? Скорее всего при обновлении приехал /etc/nginx/conf.d/default.conf Лучше закомментировать его содержимое, а не удалять весь файл. Иначе он будет опять приезжать при каждом апдейте nginx. > Заранее спасибо > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,286943,286943#msg-286943 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Ekaterina Kukushkina ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_next_upstream & HTTP 502
Добрый день, > On 12 May 2019, at 10:28, rihad wrote: > > У нас стоит: > proxy_next_upstream error timeout http_500 http_502 http_503 http_504; > > Иногда в случае если один из апстримов в дауне в access.log появляются > подобные строчки: > > > 10.10.10.10 - S387DE34EI-1557637722 [12/May/2019:05:08:42 +] "GET > /blah/blah HTTP/1.1" 502 12001 "-" "- example.com" "-" > > nginx логирует запрос только если попробовал все апстримы, или после > каждого? Здесь больше похоже на второе. Можно ли как-то настроить чтобы > логировался только результат последнего попробованного апстрима? Он и будет > результатом запроса. > В большинстве случаев, в access лог логгируется один раз на клиентский запрос независимо от того, сколько апстримов потрогано. Несколько записей может быть, если nginx делает подзапросы (ssi, njs, etc) и log_subrequest установлен в on. Либо при использовании нескольких уровней проксирований на nginx. Полагаю, что это не ваш случай. В access log имеет логгировать следующие переменные: $status - итоговый ответ клиету (есть в дефолных форматах) $upstream_addr - все потрогранные апстримы $upstream_status - статусы потроганных апстримов http://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables -- Ekaterina Kukushkina ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как ускорить переключение апстримов?
Добрый день. > On 22 Sep 2017, at 15:02, Eugene Chaykin <eugene.chay...@i-a-t.net> wrote: > > Стоит выключить один из них и скорость резко падает, примерно до минуты. > > Пробовал прописывать max_fails=1 fail_timeout=30s, но особого эффекта не > ощутил. > Если в конфиге к отключенному апстриму дописать down, то всё снова работает > быстро. > > Вопрос: ЧЯДНТ и как добиться нормального фэйловера? fail_timeout влияет на то, как долго сервер будет считаться недоступным после фейла. А max_fails=1 так и вовсе дефолтное значение. А для того, чтобы ускорить переключение, нужно крутить proxy_*_timeout директивы. По умолчанию все они выставлены в 60 секунд. http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_read_timeout http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_send_timeout > > -- > С уважением, > Евгений > -- Ekaterina Kukushkina NGINX, Inc. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_*_timeout меньше секунды
Привет. Да, конечно. http://nginx.org/ru/docs/syntax.html > On 14 Mar 2016, at 22:12, ZZZ <karamb...@ukr.net> wrote: > > Привет всем. > > Возможно ли установить proxy_read_timeout, proxy_send_timeout, > proxy_connect_timeout меньше секунды ? -- Ekaterina Kukushkina Support Engineer | NGINX, Inc. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: geoip_isp
Здравствуйте. > On 24 Feb 2016, at 12:45, madman <nginx-fo...@forum.nginx.org> wrote: > > А в текущем модуле geoip нет поддержки isp базы, только org? Есть. Обе базы поддерживаются через geoip_org > > Нашел трид https://forum.nginx.org/read.php?21,188488,196961, но в текущем > модуле дерективы geoip_isp нет. > > А отличия между базами все же есть > https://dev.maxmind.com/faq/what-is-the-difference-between-the-geoip-isp-and-organization-databases/ Отличия баз в содержимом полей (либо провайдер, либо название организации), но никак не в структуре > > Как сейчас можно использовать geoip_isp в nginx? Подключить ISP базу через 'geoip_org /path/to/isp.file;' и получать провайдера через $geoip_org -- wbr, Ekaterina Kukushkina ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: geo2nginx.pl
Здравствуйте, Михаил. Боже, это скрипт 10-ти летней давности, для того, чтобы впихнуть MaxMind в geo модуль. Давно уже есть geoip модуль, который и надо использовать для таких целей http://nginx.org/en/docs/http/ngx_http_geoip_module.html Он полностью совместим с Legacy форматом MaxMind. > On 02 Feb 2016, at 22:03, Михаил Монашёв <postmas...@softsearch.ru> wrote: > > Не встречали, а он есть! :-) > https://trac.nginx.org/nginx/browser/nginx/contrib/geo2nginx.pl > -- Ekaterina Kukushkina NGINX, Inc. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кэширование статики
Здравствуйте. Для начала имеет смысл добавить в конфигурацию log_format переменную $upstream_cache_status и убедиться, что кэширования файлов действительно не происходит или происходит не так, как ожидается. Также имеет смысл удалить переменны $http_if_modified_since и $http_if_none_match из ключа кэширования. Потому что запросы от разных клиентов, имеющих у себя разные версии файлов, будут приводить к тому, что на один файл будет создаваться несколько закэшированных версий, т.е. бэкэнд будет дергаться значительно большее количество раз. Чтобы в этом убедиться, можно добавить и эти переменные к log_format посмотреть, как кэшируются запросы к одному url. > On 27 Oct 2015, at 20:13, vitcool <nginx-fo...@nginx.us> wrote: > > Доброго всем времени суток > > имеем nginx-1.9.5 запущенный на Windows Server 2012 R2 > плюс RAM диск на 512Mb > > nginx должен кэшировать статик файлы при получении ответа 200 на срок 60 > минут > но судя по бекенду этого не происходит, но и нет 100% нагрузки на статику. > причем файлы js и css почему то чаще ретривятся прокси nginx чем файлы > картинок (gif, png, jpg) > диск на котором расположен кэш заполнен на 50% > подскажите пожалуйста в чем причина? > > > конфиг (кусочек) [...] > proxy_cache_key > "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; [...] > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,262499,262499#msg-262499 > -- Ekaterina Kukushkina ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Отдача статики
Добрый день. proxy_cache же. https://www.nginx.com/resources/admin-guide/content-caching/ > On 22 Oct 2015, at 16:10, vitcool <nginx-fo...@nginx.us> wrote: > > Есть ли элегантное решение при использовании nginx как прокси + для отдачи > статики, для случая если фронтенд это отдельная машина ? > > Понятно что если хранить статику на сервере фронтенда, то проблемы нет, > но то это означает что придется дорабатывать бекенд (который на отдельной > машине) так чтобы > контент редакторы могли управлять статикой (картинки и документы) на внешнем > сервере фронтенда. > > Может существуют какие либо элегантные решения? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,262402,262402#msg-262402 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Ekaterina Kukushkina Support Engineer | NGINX, Inc. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как сделать два вложенных условия в map или if
Добрый день.
А можно еще раз? А то непонятно. То "для 2 стран сделать на https с
обязательным редиректом", то "надо заредиректить всех кто не 2".
А если отлвечься от непонятного описания, то такие условные мапы можно делать
двумя способами.
1) с использованием регулярных выражений. Частично похоже на обработку
регулярных выражений в локейшенах - сначала проверяется полное соответствие
строковых значений, если ничего не совпало - проверяются регулярные выражения
до первого совпадения.
В данном примере, если схема - https, а код RU или UA, то $redirect_var будет
равно "0", для всех остальных https значение будет "1"
map "$scheme:$geoip_country_code" $redirect_var {
https:RU 0;
https:UA 0;
~https: 1;
}
2) без использования регулярных выражений (ищется полное соответствие
независимо от его расположения в map)
map $scheme $redirect_var {
https $check_country;
}
map $geoip_country_code $check_country {
RU 0;
UA 0;
default 1;
}
А дальше уже можно писать if ($redirect_var) { ...; }. Это условие будет
срабатывать в том случае, если перменная $redirect_var существует и не равна
нулю.
Т.е.
для http - эта переменная не определена, поэтому условие на выполняется
для https (RU|UA) - эта переменная равна "0", поэтому условие не выполняется
остальные https - эта перменная равно "1", условие выполнится.
> On 05 Oct 2015, at 14:40, Anton Kuznetsov <ma...@arjlover.net> wrote:
>
> Добрый день!
>
> Есть server {} общий для http & https
>
> Появилась необходимость для 2 стран сделать его только на https с
> обязательным редиректом. Но всех остальных так же обязательно оставить на
> http. Так не хочется дублировать этот server {} длинный. А сделать редиректы
> внутри одного - истина где-то рядом, но никак не дотянуться...
> Попытался сделать как в лучших домах:
>
> http{
> map "$scheme:$geoip_country_code" $tossl {
> "https:RU" "1";
> "https:UA" "1";
> "http:RU" "2";
> "http:UA" "2";
> }}
>
> server{}
> if ($tossl = "1") {rewrite ^(.*)$ https://example.com$1 permanent;}
>
> Но вот второе правило должно работать от обратного. Надо заредиректить всех
> кто не "2", но внутри одного server{} это так же будет и 1. А как в map
> пометить все страны кроме этих двух, но с учетом схемы? Нужна снова
> последовательная вложенность if.
>
> Есть известный костыль:
>
> if ( $geoip_country_code !~ "RU|UA") { set $lock1 1; }
> if ( $scheme = "https" ) { set $lock2 1; }
> set $lock3 "$lock1$lock2";
> if ( $lock3 = "11" ) { rewrite ^/(.*)$ http://example.com/$1 last ; }
>
> Но он такой уродский...
>
> --
> Best regards,
> Anton Kuznetsov.
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Ekaterina Kukushkina
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Редирект на выбранный порт
Привет!
У вас в конфигурации четко сказано:
location /iweb/ {
...
deny all;
}
Никаких разрешающих правил я не вижу. При таком раскладе у
nginx'а нет выбора и он обязан отдавать 403. Предположу что
раньше были allow записи.
> On 29 Sep 2015, at 12:14, OZzzy <nginx-fo...@nginx.us> wrote:
>
> Прошло 2 года , а я наступаю на те же грабли.
> не могу никак сделать редирект с порта 8080 на порт 44410
>
> тот же конфиг что и был:
>
> server {
> listen 95.65.37.90:44410;
>
> location ~
> /\.(ht|svn|cvs|hg|txt|log|class|cgi|xml|conf|config|properties|jar) {
> deny all;
> }
>
> location /iweb/ {
> proxy_pass http://localhost:8080;
> proxy_redirect http://localhost:8080/ http://95.65.37.90:44410/;
> proxy_set_header Host $host;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Real-IP $remote_addr;
> access_log /var/log/iweb/admin_access.log;
> error_log /var/log/iweb/admin_error.log notice;
>
> deny all;
> }
> }
>
>
> получаю ошибку 403 nginx
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,234597,261914#msg-261914
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Ekaterina Kukushkina
NGINX, Inc.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Добавление заголовка после upstream
On Wed, Jul 29, 2015 at 05:56:40AM -0400, Budulianin wrote: Т.е. в блоке в котором выполняется proxy_pass на запрос повлиять можно, а в блоке upstream уже нет? Именно так. http://forum.nginx.org/read.php?21,260591,260611#msg-260611 Скажите, пожалуйста, а какое поведение ожидается от nginx в случае недоступности одной из нод? Должны ли запросы, ранее маршрутизируемые на нее, быть переданы другой ноде (на время или постоянно), либо допустимо ответить клиенту, что Сервис временно недоступен? -- Ekaterina Kukushkina ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Добавление заголовка после upstream
Привет.
On Wed, Jul 29, 2015 at 01:34:59AM -0400, Budulianin wrote:
В ответ клиенту добавить?
Добавить в запрос, который перенаправится какой-то ноде, после того, как она
будет выбрана в upstream.
Т.е. upstream уже выбран, мы его только теперь знаем(адрес ноды) и тогда мы
добавляем его в header и он отправляется в ноду.
Запрос для передачи на апстрим формируется один раз и после этого не
меняется. И в этом неизменном виде передается на выбранный апстрим. Если
выбранный не отвечает, тот же самый запрос, сформированный ранее, может
передаваться на другой апстрим (в зависимости от настроек
proxy_next_upstream). Таким образом, эта переменная может содержать не
только IP адрес, но и список IP адресов всех потыканных серверов.
Вообще, использование upstream предполагает и требует использование
идентично настроенных бэкэндов. Если они у вас различаются, то надо
разносить их по разным группам и проксировать на разные группы в разных
локейшенах.
Есть несолько решений, которые позволяют добиться желаемого.
1. Для каждого бэкэнда определить отдельный виртуальный сервер и повесить
его на какой-нибудь 127.0.0.1:9995 и т.д. В нем можно указать желаемые
заголовки, специфичные для данного сервера. И в upstream определять не сами
бэкэнды, а эти виртуальные сервера. (Но не забудьте сохранить все кастомные
заголовки)
2. Отказываться от алгоритмов баллансировки nginx и мутить свой лунапарк,
например, через map задавать используемый апстрим для группы ипользуемых
key. Все key перечислять не надо, можно воспоользоваться регулярными
выражениями. И после этого в proxy_pass указывать значение полученное в
map. В этом случае на бэкэнды будет прилеть хидер Host, в котором будет
указан желаемый IP адрес.
Но, увы, это полностью убьет все плюшки upstream (такие как, next_upstream,
weight и т.д)
Но зачем все это?
Если ставить proxy_set_header рядом с proxy_pass, то заголовок не
добавляется, я так понимаю, что переменная ещё пустая, поэтому
заголовок не ставится. Но где уже известна эта переменная? Только в блоке
upstream? Но там нельзя устанавливать заголовок.
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream tornado {
hash $arg_key;
server 127.0.0.1:9995;
server 127.0.0.1:9996;
server 127.0.0.1:9997;
server 127.0.0.1:9998;
server 127.0.0.1:;
}
server {
listen 8080 default_server;
access_log /var/log/nginx/prototypes-nginx-access.log;
error_log /var/log/nginx/prototypes-nginx-error.log;
location /ws/ {
proxy_pass http://tornado;
proxy_set_header Test-Header1 123;
proxy_set_header Test-Header2 $upstream_addr;
proxy_set_header Test-Header3 $host;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
--
Ekaterina Kukushkina
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Маршрутизация запросов
Привет. On Wed, Jul 29, 2015 at 01:43:11AM -0400, Budulianin wrote: Но hash же не гарантирует равномерного распределения запросов по бэкендам, он как раз гарантирует, что запросы с одинаковым id будут идти на одну и ту же ноду. А где-то описывается алгоритм работы hash? Чтобы можно было понять наверняка, всегда ли с одним id на одну и туже ноду или нет. Я конечно проверю, но ещё хотелось бы что-то в документации прочитать по этому поводу. Hash (как и другие алгоритмы баллансировки) учитывает состояние апстрима. И если апстрим не доступен, то для маршрутизации запроса будет выбран один из оставшихся. Недоступным апстрим может считаться по нескольким причинам: не ответил в течение заданного таймаута, ответил, но nginx оценил его ответ как невалидный. Это конфигурируется с помощью директивы proxy_next_upstream. Также обратите внимание на директиву max_fails. Хоть она и не фигурирует в вашей конструкции, но тем не менее присутствует в виде 'max_fails=1'. При каждом неуспешном ответе (или неответе в установленное время) nginx будет помечать указанный сервер как недоступный (на 10 секунд по умолчанию). И в этом случае nginx заново выберет актуальный апстрим для указанного хэша и будет использовать его до тех пор пока он жив. Для того чтобы это подтвердить, рекомендую посмотреть error_log на предмет таймаутов от апстрима (они видны на уровне error). Также можно в access_log добавить пременные $upstream_status и $upstream_addr. В этом случае в access_log'е будут видны переходы с следующему апстриму. -- Ekaterina Kukushkina ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вернуть 444 по рефереру
Nick,
В общем и целом указанная конфигурация работоспособна.
Мне не удалось воспроизвести на ней Вашу проблему.
Конфигурацию применяете через 'service nginx reload/kill -HUP'? Nginx успешно
применил ее? В error.log есть ошибки?
Укажите ещё, пожалуйста, используемую версию nginx.
On Thu, Jul 23, 2015 at 03:19:12PM +0300, Nick wrote:
Konsole output
Спасибо за ответ.
В location, в принципе ничего военного:
location / {
proxy_pass http://backends;
limit_conn lz_global32;
limit_req zone=lz_req_global burst=10;
limit_req zone=auth burst=5 nodelay;
# for checking auth page connection:
if ($request_uri ~* ^/auth/login$)
{
access_log
/var/log/nginx/server-auth.log;
}
if ($http_referer ~* 111\.111\.111\.111) {
access_log
/var/log/nginx/111.111.111.111_referer.log;
return 444;
}
# return 444 to fake googlebot
if ($http_user_agent ~* 'googlebot$')
{
access_log
/var/log/nginx/fake-google-bot.ua.log;
return 444;
}
}
On 07/23/2015 01:42 PM, Ekaterina Kukushkina wrote:
Добрый день.
Конструкция вполне себе работоспособная. Показывайте больше деталей.
Например, конфигурацию всего локейшена, в котором этот if фигурирует.
On Thu, Jul 23, 2015 at 11:55:53AM +0300, Nick wrote:
Добрый день.
Нужно вернуть 444 по рефереру
Вот такая конструкция не работает:
--
Konsole output
if ($http_referer ~* 111\.111\.111\.111) {
access_log
/var/log/nginx/111.111.111.111_referer.log;
return 444;
}
--
Спасибо.
___
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
--
Ekaterina Kukushkina
Support Engineer | NGINX, Inc.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вернуть 444 по рефереру
Добрый день.
Конструкция вполне себе работоспособная. Показывайте больше деталей.
Например, конфигурацию всего локейшена, в котором этот if фигурирует.
On Thu, Jul 23, 2015 at 11:55:53AM +0300, Nick wrote:
Добрый день.
Нужно вернуть 444 по рефереру
Вот такая конструкция не работает:
--
Konsole output
if ($http_referer ~* 111\.111\.111\.111) {
access_log
/var/log/nginx/111.111.111.111_referer.log;
return 444;
}
--
Спасибо.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Ekaterina Kukushkina
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
