Re: client_max_body_size inside if
On Mon, Nov 11, 2019 at 05:23:55PM +0300, Михаил Монашёв wrote:
> Здравствуйте.
>
> Оказалось, что client_max_body_size не работает внутри if-а .
>
> Хотел ограничивать размер GET- и POST-запросов, не ограничивая размер
> PUT-запросов, поступающих с доверенных ip. Конфиг планировался
> примерно такой:
>
> server {
> listen 80;
> server_name x;
>
> expires 1y;
>
> location / {
> root //y;
>
> if ($request_method == PUT ) {
> client_max_body_size 0; # disable request size checks
> }
>
> client_body_temp_path //webdav-tmp;
>
> dav_methods PUT DELETE MKCOL COPY MOVE;
> create_full_put_path on;
> dav_access user:rw group:rw all:r;
>
> limit_except GET {
> allow 127.0.0.0/8;
> allow 10.0.0.0/8;
>
> deny all;
> }
> }
> }
>
> Добавить NGX_HTTP_LIF_CONF в ngx_http_core_module.c не проблема. Но
> если есть возможность менять client_max_body_size внутри if-ов в самом
> nginx-е, было бы здорово. Если против этого, конечно же, нет никаких
> возражений.
Всё не так просто.
Сейчас для обычного (не-chunked) тела запроса проверка на данное ограничение
встроена в фазу FIND_CONFIG, обработчик которой вызывается при исходном выборе
location'а, а также каждый раз, когда location выбирается при помощи директивы
rewrite.
Можно передвинуть проверку на ограничение в фазу POST_REWRITE. От этого
становится чуть лучше, и client_max_body_size начинает работать внутри "if"
(добавления только NGX_HTTP_LIF_CONF недостаточно), но ограничение всё равно
будет проверяться по числу выборов новых location'ов, и в целом идея работать
не будет, т.к. фактически будет срабатывать наименьшее из ограничений:
location /1 {
client_max_body_size 8;
rewrite /1 /2;
}
location /2 {
client_max_body_size 9;
rewrite /2 /3;
}
location /3 {
client_max_body_size 10;
}
}
Кроме того, фазы POST_REWRITE может и не быть, так что туда нельзя.
Аналогично, не подходит и фаза POST_ACCESS (её также может не быть).
Остаётся убрать это в CONTENT-фазу, но насколько это хорошее изменение,
я пока не до конца понимаю.
Proof of concept патч:
# HG changeset patch
# User Ruslan Ermilov
# Date 1573570198 -10800
# Tue Nov 12 17:49:58 2019 +0300
# Node ID f50e2acbb576cbd699307a647da3e4ec2dbe5b48
# Parent 1ab95c51955e9c9fc9954b4d43d287c87a97fe0e
Enabled client_max_body_size inside "if".
diff --git a/src/http/ngx_http_core_module.c b/src/http/ngx_http_core_module.c
--- a/src/http/ngx_http_core_module.c
+++ b/src/http/ngx_http_core_module.c
@@ -343,7 +343,8 @@ static ngx_command_t ngx_http_core_comm
NULL },
{ ngx_string("client_max_body_size"),
- NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
+ NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF
+|NGX_CONF_TAKE1,
ngx_conf_set_off_slot,
NGX_HTTP_LOC_CONF_OFFSET,
offsetof(ngx_http_core_loc_conf_t, client_max_body_size),
@@ -961,25 +962,6 @@ ngx_http_core_find_config_phase(ngx_http
ngx_http_update_location_config(r);
-ngx_log_debug2(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
- "http cl:%O max:%O",
- r->headers_in.content_length_n, clcf->client_max_body_size);
-
-if (r->headers_in.content_length_n != -1
-&& !r->discard_body
-&& clcf->client_max_body_size
-&& clcf->client_max_body_size < r->headers_in.content_length_n)
-{
-ngx_log_error(NGX_LOG_ERR, r->connection->log, 0,
- "client intended to send too large body: %O bytes",
- r->headers_in.content_length_n);
-
-r->expect_tested = 1;
-(void) ngx_http_discard_request_body(r);
-ngx_http_finalize_request(r, NGX_HTTP_REQUEST_ENTITY_TOO_LARGE);
-return NGX_OK;
-}
-
if (rc == NGX_DONE) {
ngx_http_clear_location(r);
@@ -1160,9 +1142,31 @@ ngx_int_t
ngx_http_core_content_phase(ngx_http_request_t *r,
ngx_http_phase_handler_t *ph)
{
-size_t root;
-ngx_int_t rc;
-ngx_str_t path;
+size_t root;
+ngx_int_t rc;
+ngx_str_t path;
+ngx_http_core_loc_conf_t *clcf;
+
+clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
+
+ngx_log_debug2(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
+ "ht
Re: location vs map по скорость
On Thu, Jul 26, 2018 at 04:50:45PM +0300, Maxim Dounin wrote:
> On Thu, Jul 26, 2018 at 03:43:39PM +0300, kpoxa wrote:
>
> > Добрый день.
> >
> > А что будет по скорости быстрее работать, при ограничении доступа к
> > определенным расширениям файлов (2-3 десятка расширений):
> >
> > location ~* \.(ext1|ext2|ext3)$ {
> > deny all;
> > }
> > location / {
> > //access granted
> > }
> >
> > или
> >
> > map $uri $error {
> > ~".ext1$" 403;
> > ~".ext2$" 403;
> > ~".ext3$" 403;
> > }
> > location / {
> > if ($error = 403) {
> > return 403;
> > }
> > }
>
> Вот конкретно из этих двух примеров - быстрее будет работать
> совершенно точно первый, потому что во втором случае будет
> выполняться три разных регулярных выражения, а не одно, как в
> первом случае. В общем случае, когда используемые регулярные
> выражения одинаковы и в том и в другом варианте, наверное тоже
> location чуть выиграет за счёт отсутствия лишних операций с
> переменными и инструкций rewrite-модуля.
>
> Впрочем, я сильно сомневаюсь, что разница будет хоть как-то
> измерима по сравнению с собственно обработкой запроса даже в этом
> случае, не говоря уже про общий. Так что выбирать стоит скорее
> исходя из удобства поддержки всего этого хозяйства.
Возможно есть смысл добавить переменную?
# HG changeset patch
# User Ruslan Ermilov
# Date 1532637590 -10800
# Thu Jul 26 23:39:50 2018 +0300
# Node ID 430d80baa550a753a26b1a06d8213ca0e0030176
# Parent f7e79596baf209151682f2f7d220161c034657ac
Added $exten.
diff --git a/src/http/ngx_http_variables.c b/src/http/ngx_http_variables.c
--- a/src/http/ngx_http_variables.c
+++ b/src/http/ngx_http_variables.c
@@ -226,6 +226,10 @@ static ngx_http_variable_t ngx_http_cor
offsetof(ngx_http_request_t, uri),
NGX_HTTP_VAR_NOCACHEABLE, 0 },
+{ ngx_string("exten"), NULL, ngx_http_variable_request,
+ offsetof(ngx_http_request_t, exten),
+ NGX_HTTP_VAR_NOCACHEABLE, 0 },
+
{ ngx_string("request"), NULL, ngx_http_variable_request_line, 0, 0, 0 },
{ ngx_string("document_root"), NULL,
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Upstream zone
On Wed, May 30, 2018 at 07:52:10PM -0400, larsn wrote:
> День добрый.
> Столкнулся с высоким потреблением CPU при добавлении в конфиге апстримов
> директивы zone.
> Как было до
>
> upstream backend {
> server server1:8080 weight=860;
> server server2:8080 weight=860;
> server server3:8080 weight=860;
> .
> }
>
> Как стало после
>
> upstream backend {
> zone upstream_backend 1m;
> server server1:8080 weight=860;
> server server2:8080 weight=860;
> server server3:8080 weight=860;
> .
> }
>
> При значительной нагрузке потребление CPU взлетает неимоверно.
> Стоит отметить, что upstream серверов в данной группе достаточно много.
> Около 2000 штук.
> Может ли это быть связано с rw локами шаренной памяти?
Интересует вывод "uname -a", "cat /proc/cpuinfo", "nginx -V".
Сколько рабочих процессов в nginx?
Какой балансировщик в upstream backend?
Просьба протестировать Вашу конфигурацию с одним из балансировщиков
ip_hash или hash (неконсистентный), патч ниже должен помочь:
# HG changeset patch
# User Ruslan Ermilov
# Date 1527775383 -10800
# Thu May 31 17:03:03 2018 +0300
# Node ID 927cb2e79ea0ab79dae171325f3203601bbd0962
# Parent 760df963f0e03ff300cf1bc1a81d4745730457b0
Upstream: improved peer selection concurrency for hash and ip_hash.
diff --git a/src/http/modules/ngx_http_upstream_hash_module.c
b/src/http/modules/ngx_http_upstream_hash_module.c
--- a/src/http/modules/ngx_http_upstream_hash_module.c
+++ b/src/http/modules/ngx_http_upstream_hash_module.c
@@ -176,7 +176,7 @@ ngx_http_upstream_get_hash_peer(ngx_peer
ngx_log_debug1(NGX_LOG_DEBUG_HTTP, pc->log, 0,
"get hash peer, try: %ui", pc->tries);
-ngx_http_upstream_rr_peers_wlock(hp->rrp.peers);
+ngx_http_upstream_rr_peers_rlock(hp->rrp.peers);
if (hp->tries > 20 || hp->rrp.peers->single) {
ngx_http_upstream_rr_peers_unlock(hp->rrp.peers);
@@ -228,6 +228,8 @@ ngx_http_upstream_get_hash_peer(ngx_peer
goto next;
}
+ngx_http_upstream_rr_peer_lock(hp->rrp.peers, peer);
+
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, pc->log, 0,
"get hash peer, value:%uD, peer:%ui", hp->hash, p);
@@ -250,6 +252,8 @@ ngx_http_upstream_get_hash_peer(ngx_peer
next:
+ngx_http_upstream_rr_peer_unlock(hp->rrp.peers, peer);
+
if (++hp->tries > 20) {
ngx_http_upstream_rr_peers_unlock(hp->rrp.peers);
return hp->get_rr_peer(pc, &hp->rrp);
@@ -268,6 +272,7 @@ ngx_http_upstream_get_hash_peer(ngx_peer
peer->checked = now;
}
+ngx_http_upstream_rr_peer_unlock(hp->rrp.peers, peer);
ngx_http_upstream_rr_peers_unlock(hp->rrp.peers);
hp->rrp.tried[n] |= m;
diff --git a/src/http/modules/ngx_http_upstream_ip_hash_module.c
b/src/http/modules/ngx_http_upstream_ip_hash_module.c
--- a/src/http/modules/ngx_http_upstream_ip_hash_module.c
+++ b/src/http/modules/ngx_http_upstream_ip_hash_module.c
@@ -161,7 +161,7 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p
/* TODO: cached */
-ngx_http_upstream_rr_peers_wlock(iphp->rrp.peers);
+ngx_http_upstream_rr_peers_rlock(iphp->rrp.peers);
if (iphp->tries > 20 || iphp->rrp.peers->single) {
ngx_http_upstream_rr_peers_unlock(iphp->rrp.peers);
@@ -201,6 +201,8 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, pc->log, 0,
"get ip hash peer, hash: %ui %04XL", p, (uint64_t) m);
+ngx_http_upstream_rr_peer_lock(iphp->rrp.peers, peer);
+
if (peer->down) {
goto next;
}
@@ -220,6 +222,8 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p
next:
+ngx_http_upstream_rr_peer_unlock(iphp->rrp.peers, peer);
+
if (++iphp->tries > 20) {
ngx_http_upstream_rr_peers_unlock(iphp->rrp.peers);
return iphp->get_rr_peer(pc, &iphp->rrp);
@@ -238,6 +242,7 @@ ngx_http_upstream_get_ip_hash_peer(ngx_p
peer->checked = now;
}
+ngx_http_upstream_rr_peer_unlock(iphp->rrp.peers, peer);
ngx_http_upstream_rr_peers_unlock(iphp->rrp.peers);
iphp->rrp.tried[n] |= m;
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: поддержка IP_BIND_ADDRESS_NO_PORT на CentOS-7.4
On Mon, May 14, 2018 at 12:14:28PM +0500, Илья Шипицин wrote: > на днях зарелизился centos-7.5, в нем, к сожалению, все по прежнему > > завел тикет > > https://trac.nginx.org/nginx/ticket/1553 > > посмотрите ? > > 29 апреля 2018 г., 3:40 пользователь Валентин Бартенев > написал: > > > On Saturday, 28 April 2018 15:03:49 MSK Илья Шипицин wrote: > > > привет! > > > > > > поддержка IP_BIND_ADDRESS_NO_PORT официально началась в ядре 4.2, но ... > > > ее портировали в 3.10 на CentOS-7.4 > > > > > > однако, портировали не очень качественно. константа определена не в том > > > файле, в котором должна (и в котором ищет nginx) > > > > > > [root@xxx ~]# grep -r IP_BIND_ADDRESS_NO_PORT /usr/include/ > > > /usr/include/linux/in.h:#define IP_BIND_ADDRESS_NO_PORT24 > > > [root@xxx ~]# > > > > > > > > > т.е. если пакет собирать, как он собирается обычно, то поддержка > > > IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы). > > > > > > скажите, вы официальные пакеты собираете каким образом ? кажется, имеет > > > смысл поправить эту процедуру и дать эту крутую фичу пользователям > > > CentOS-7.4 > > > > > > > Дело же не в ядре (не только в нем). На линуксах интерфейс обеспечивает > > glibc и именно туда смотрит nginx. - это заголовочный файл ядра. - это заголовочный файл glibc. Приложения используют . В норме макрос IP_BIND_ADDRESS_NO_PORT есть в обоих файлах, что означает, что поддержка есть и в ядре, и в glibc. Утверждение о том, что "константа определена не в том файле", ошибочное. Как Вам уже пытался ранее объяснять Валентин, проблема заключается в том, что в установленной версии glibc нет поддержки этого макроса. Для себя Вы можете проблему решить так: configure --with-cc-opt=-DIP_BIND_ADDRESS_NO_PORT=24 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопросы по http2 push
On Tue, Feb 27, 2018 at 10:17:07AM +0300, Nick Lavlinsky - Method Lab wrote:
> Здравствуйте!
>
> Начал тестировать http2_push сразу после релиза. Появилось 2 вопроса.
>
> 1. Есть ли возможность пушить ресурсы до ответа на основной запрос (так
> делает у себя Fastly, называя async push)? Таким образом можно получить
> экономию не только в 1RTT, но и за счет серверного времени на генерацию
> html (https://www.fastly.com/blog/optimizing-http2-server-push-fastly).
Нет, сейчас такой возможности нет и вряд ли она появится.
Сейчас nginx дожидается заголовка ответа на основной запрос,
прежде чем отправить PUSH_PROMISE'ы и собственно начать пушить
ответы. Причин тому несколько. Во-первых, это единственный
способ при конвертации Link preload'ов в push'и. Во-вторых,
если так не делать, и ответа на основной запрос нет (например,
бэкенд неживой), то непонятно, на каком основании вообще мы
должны делать push.
> 2. При использовании директивы http2_push в конфиге сайта браузеры
> (Chrome Stable и 66, FF 58.0.2) показывают, что только 1 ресурс был
> запушен, хотя стоят сразу несколько (смотрю в DevTools с отключенным
> кэшем). Например:
>
> location / {
> proxy_pass http://127.0.0.1:9090/pcgi/index.pl?$uri?&$args;
> proxy_redirect off;
>
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>
> http2_push /css/colorbox.css;
> http2_push /img/design/logo.png;
> http2_push /js/core.js;
> http2_push /images/border.png;
> http2_push /img/no_foto.png;
> http2_push /js/jq/jquery-2.1.3.min.js;
>
> }
>
> В браузерах отображается в виде push только /img/design/logo.png, так
> как этот ресурс используется на странице (остальные - нет). Поведение
> одинаково и в Chrome и в FF.
>
> Если делать push через заголовок Link (http2_push_preload on;), то в
> Chrome все ресурсы показываются в DevTools.
При этом внизу выдаётся warning, что некоторые ресурсы не используются.
> В FF показываются только те
> ресурсы, которые используются на странице.
>
> При анализе загрузки ресурсов через nghttp -ans или Webpagetest всегда
> (и в http2_push, и в http2_push_preload) видны все push запросы.
>
> Не знаю, бага это или фича, может будет полезно.
В chrome://net-internals/#http2 видно, что они push'атся. Почему
так по-разному показывает DevTools, я лично не знаю. Но это точно
не вопрос к nginx'у.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос по access_log
On Fri, Feb 09, 2018 at 11:38:36PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 09, 2018 at 10:27:22PM +0300, Ruslan Ermilov wrote:
>
> > On Fri, Feb 09, 2018 at 04:35:05PM +0300, Slawa Olhovchenkov wrote:
> > > On Fri, Feb 09, 2018 at 04:26:42PM +0300, Ruslan Ermilov wrote:
> > >
> > > > On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> > > > > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > > > > >
> > > > > > Как и все остальные директивы, access_log наследуется с
> > > > > > предыдущих уровней тогда и только тогда, когда на данном уровне не
> > > > > > указано директив access_log.
> > > > >
> > > > > и при этом, кажется, нет возможности просто включать/выключать acceess
> > > > > log, не трогая его настройки?
> > > >
> > > > Запись в лог может быть условной при помощи параметра "if=".
> > > >
> > > > Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
> > > > а на вложенном уровне (напр., location) указать "access_log off;".
> > > > Тогда на данном вложенном уровне access_log'и будут отключены, а
> > > > на других вложенных уровнях (где не указаны свои access_log'и) будут
> > > > действовать настройки как на внешнем уровне.
> > > >
> > > > Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.
> > >
> > > ну хочется указать accesslog. с кучей параметров (ну там путь,
> > > буферезиция и все такое). а потом по дефолту его запретить. и
> > > разрешать только для отдельный location.
> > >
> > > ну вот я не вижу возможности так поступить, не повторяя в каждом
> > > location директивы access_log со всеми этими параметрами.
> >
> > Мне кажется, я уже ответил на Ваш вопрос ранее.
> >
> > access_log <много_параметров> if="$log";
> >
> > location /1 {
> > set $log 1;
> > <тут он будет работать>
> > }
> >
> > location /2 {
> > <а тут - нет>
> > }
>
> а что при этом с производительностью?
Зависит от сложности вычисления условия. В случае с "set", это будет
практически неизмеримо. Цитата из кода:
if (log[l].filter) {
if (ngx_http_complex_value(r, log[l].filter, &val) != NGX_OK) {
return NGX_ERROR;
}
if (val.len == 0 || (val.len == 1 && val.data[0] == '0')) {
continue;
}
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос по access_log
On Fri, Feb 09, 2018 at 05:37:49PM +0300, Slawa Olhovchenkov wrote: > On Fri, Feb 09, 2018 at 04:32:35PM +0200, Alex Vorona wrote: > > > Привет, > > > > 09.02.18 15:35, Slawa Olhovchenkov wrote: > > [...] > > > > > ну хочется указать accesslog. с кучей параметров (ну там путь, > > > буферезиция и все такое). а потом по дефолту его запретить. и > > > разрешать только для отдельный location. > > > > > > ну вот я не вижу возможности так поступить, не повторяя в каждом > > > location директивы access_log со всеми этими параметрами. > > Использую для похожих задач include. > > я прямо испытываю оргазм от одной мысли так делать. > нарезать все по одной строке и инклюды-инклюды-инклюды! > а уж какой кайф это редактировать или пытаться понять как конфиг > выглядит. В части понимания, с include'ов легко расправляется "nginx -T". ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос по access_log
On Fri, Feb 09, 2018 at 04:35:05PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 09, 2018 at 04:26:42PM +0300, Ruslan Ermilov wrote:
>
> > On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> > > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > > >
> > > > [...]
> > > >
> > > > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > > >
> > > > Как и все остальные директивы, access_log наследуется с
> > > > предыдущих уровней тогда и только тогда, когда на данном уровне не
> > > > указано директив access_log.
> > >
> > > и при этом, кажется, нет возможности просто включать/выключать acceess
> > > log, не трогая его настройки?
> >
> > Запись в лог может быть условной при помощи параметра "if=".
> >
> > Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
> > а на вложенном уровне (напр., location) указать "access_log off;".
> > Тогда на данном вложенном уровне access_log'и будут отключены, а
> > на других вложенных уровнях (где не указаны свои access_log'и) будут
> > действовать настройки как на внешнем уровне.
> >
> > Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.
>
> ну хочется указать accesslog. с кучей параметров (ну там путь,
> буферезиция и все такое). а потом по дефолту его запретить. и
> разрешать только для отдельный location.
>
> ну вот я не вижу возможности так поступить, не повторяя в каждом
> location директивы access_log со всеми этими параметрами.
Мне кажется, я уже ответил на Ваш вопрос ранее.
access_log <много_параметров> if="$log";
location /1 {
set $log 1;
<тут он будет работать>
}
location /2 {
<а тут - нет>
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос по access_log
On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote: > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote: > > > Hello! > > > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote: > > > > [...] > > > > > access_log в нижестоящем контексте отменяет все вышестоящие? > > > > Как и все остальные директивы, access_log наследуется с > > предыдущих уровней тогда и только тогда, когда на данном уровне не > > указано директив access_log. > > и при этом, кажется, нет возможности просто включать/выключать acceess > log, не трогая его настройки? Запись в лог может быть условной при помощи параметра "if=". Кроме того, можно на внешнем уровне (напр., server) задать access_log'и, а на вложенном уровне (напр., location) указать "access_log off;". Тогда на данном вложенном уровне access_log'и будут отключены, а на других вложенных уровнях (где не указаны свои access_log'и) будут действовать настройки как на внешнем уровне. Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно. http://nginx.org/r/access_log/ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: rate limiter and rewrite together
Привет, Дима!
On Wed, Nov 08, 2017 at 08:26:24PM +0300, Dmitry Morozovsky wrote:
> Коллеги,
>
>
> что-то мы мальца сломали мозг и явно не видим очевидного.
>
> Есть ситуация, когда все транзитные HTTP запросы клиента перехватываются и
> отправляются в специальный nginx, котогрый показывает специальную страничку.
>
> Но -- хочется этот поток ограничить, ибо иначе nginx начинает жрать
> процессор как не в себя, потому что клиент-то тупой запросов шлёт гору.
>
> и -- не получается.
>
> текущий вариант был таков:
>
>
> http {
> include mime.types;
> default_type application/octet-stream;
> sendfileon;
> keepalive_timeout 65;
> error_log /var/log/nginx-error.log notice;
> proxy_buffering off;
>
> log_format rdr '[$time_local] $remote_addr [$http_host$request_uri]
> $server_name $server_port [$rdr] $status $body_bytes_sent';
> limit_req_log_level info;
> limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
>
> server {
> listen 127.0.0.1:8001;
> server_name localhost;
> access_log /var/log/nginx-access.log rdr;
> limit_req zone=one nodelay;
> limit_req_status 444;
> return 302 http://rinet.ru/nomoney/redirect.html?;
> }
> }
>
> не лимитит.
>
> чего мы не замечаем и где тупим? ;)
А не замечаете вы директивы return модуля rewrite, которая не даёт
работать в т.ч. limit_req'у (обработка запроса попросту до нужной
фазы не доходит). Как раз недавно обсуждали подобный юзкейс, ну
и лайфхак какой-то такой будет:
location / {
limit_req zone=one nodelay;
limit_req_status 444;
try_files /nonexistent @redirect;
}
location @redirect {
return 302 http://rinet.ru/nomoney/redirect.html?;
}
P.S. Знак вопроса в конце URI в return остался от rewrite'а, или
так и задумано?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: повторная загрузка модуля
On Wed, Sep 27, 2017 at 03:19:43PM +0700, Vadim A. Misbakh-Soloviov wrote: > Прошу прощения за глупый вопрос, но, что-то, в коде у меня сходу не > получилось > найти ответ на этот вопрос... > Как NginX относится к повторной загрузке динамического модуля (если > load_module с тем же самым модулем будет вызван несколько раз)? nginx: [emerg] module "ngx_http_geoip_module" is already loaded in ./x.conf:6 А у вас не так? > Особенно, в случае, когда некоторым другим модулям важно чтобы указанный был > загружен раньше них (и первый инстанс таки был загружен до них, а потом > загружен повторно). > > Или, наоборот, если модулю важно быть загруженным как можно раньше > (mod_security, там, какой-нибудь, naxsi и иже с ними), и он таки был, а потом > был "загружен" повторно. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx crash signal 6
stream-xxx.xxx;
> proxy_set_header Host $http_host;
> client_max_body_size 40M;
> proxy_connect_timeout 300;
> proxy_read_timeout 300;
> proxy_send_timeout 300;
> send_timeout 300;
>
> }
> location =/status-node1 {
> rewrite /status-node1 /status break;
> proxy_pass http://upstream-xxx-1.xxx.xxx;
> }
> location =/status-node2 {
> rewrite /status-node2 /status break;
> proxy_pass http://upstream-xxx-2.xxx.xxx;
> }
> }
>
> # LAN answers
> server {
> listen 192.168.0.200:443;
> server_name www.xxx.xxx;
> ssl on;
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> ssl_ciphers
> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!EDH:!kEDH:!PSK:!SRP:!kECDH:!RC4;
> ssl_prefer_server_ciphers on;
> ssl_verify_client off;
> ssl_certificate /etc/nginx/ssl/www.xxx.xxx.crt;
> ssl_certificate_key /etc/nginx/ssl/www.xxx.xxx.key;
> port_in_redirect on;
>
> access_log /var/log/nginx/answer.xxx.xxx_access.log main_post;
> error_log /var/log/nginx/answer.xxx.xxx_error.log;
>
> location / {
> proxy_pass http://upstream-xxx.xxx;
> proxy_set_headerHost$host;
> proxy_set_headerX-Real-IP $realip;
> proxy_set_header X-Forwarded-For
> $proxy_add_x_forwarded_for;
> proxy_redirecthttps://$host/
> https://$host:$server_port/;
> proxy_set_header X-Forwarded-Proto https;
> proxy_connect_timeout 300;
> proxy_read_timeout 300;
> proxy_send_timeout 300;
> send_timeout 300;
> client_max_body_size40m;
> }
> }
>
> После комментирования подозрительного момента - падения прекратились.
>
> Воспроизвести ошибку на стенде не получилось. Проявляется не всегда.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,275444,275444#msg-275444
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
--
Ruslan Ermilov
Join us at nginx.conf, Sep. 6-8, Portland, OR
https://www.nginx.com/nginxconf
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос о mime-type
On Tue, Mar 07, 2017 at 07:31:58AM -0500, itcod wrote: > Добрый день! r...@nginx.com > > > > Вопрос как файлу назначить Content-Type всё ещё висит > > Для того чтобы для определённого location’а для всех ответов > > Мне НЕ нужно глобально менять Сontent-Type в location для всех ответов > Только для файлов с определёнными названиями. Задайте "файлы с определёнными названиями" при помощи location'а, внутри которого задайте нужный mime-тип. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос о mime-type
On Tue, Mar 07, 2017 at 05:50:24AM -0500, itcod wrote:
> Добрый день Роман!
> > Ну нету в никсах расширений, нету!
> В никсах нету, а в nginx есть - в файле mime-types :)
>
> Вопрос как файлу назначить Content-Type всё ещё висит
> Надеюсь есть решение:)
>
> Спасибо!
Ответ на этот вопрос есть в документации.
http://nginx.org/r/types/ru
Для того чтобы для определённого location’а для всех ответов
выдавался MIME-тип “application/octet-stream”, можно использовать
следующее:
location /download/ {
types{ }
default_type application/octet-stream;
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: подстановка переменных в имя апстрима.
On Wed, Mar 01, 2017 at 11:06:20AM -0500, syswipe wrote:
> Добрый день!
>
> хочется странного, пока не понимаю, как бы это реализовать красивей.есть
> пачка конфигов, для различных виртуальных хостов. так же есть один общий
> набор локейшенов, который они все инклюдят. локейшенов очень много, они
> одинаковые но ведут на разные апстримы в каждом виртхосте. Упрощенно это
> выглядит следующим образом:
>
> VHOST1.conf:
>
> upstream upstream_vhost1_backend {
>server host1;
>server host2;
> }
>
> server {
> server vhost1;
> ...
> set $upstream_backend upstream_vhost1_backend;
> include common_config;
> }
>
> VHOST2.conf:
>
> upstream upstream_vhost2_backend {
>server host3;
>server host4;
> }
>
> server {
> server vhost2;
> ...
> set $upstream_backend upstream_vhost2_backend;
> include common_config;
> }
>
> в common_config задается соответствующий локейшн:
> ...
> location /somelocation {
>proxy_pass http://$upstream_backend;
> }
>
> тут все хорошо. проблема начинается, когда в common_config нужно задать
> локейшены следующего вида:
> location /somelocation/module1/ {
>proxy_pass http://$upstream_module1;
> }
>
> location /somelocation/module2/ {
>proxy_pass http://$upstream_module2;
> }
>
> location /somelocation/moduleN/ {
>proxy_pass http://$upstream_moduleN;
> }
>
> проблема в том, что количество таких схожих локейшенов может расти и
> хотелось бы конфиг свернуть.
> хочется получить что-то вроде
>
> location ~ ^/somelocation/module(\d+)/ {
>proxy_pass http://$upstream_module$1;
> }
>
> как это сделать по уму?
При использовании переменных в proxy_pass nginx после раскрытия
переменных будет сначала искать среди явно описанных апстримов,
и если у вас будет блок upstream{} с таким именем, он и будет
использоваться. Никакого DNS resolving'а. Т.е. вот прямо как
вы и написали, примерно. Вопрос исключительно в том, как из
переменных получить имя апстрима. Либо явно, либо через map.
Пример:
http {
upstream u1 {
server 127.0.0.1:10001;
}
upstream u2 {
server 127.0.0.1:10002;
}
server {
listen 10001;
listen 10002;
return 200 "$server_port\n";
}
server {
listen 8000;
server_name ~^s(\d)$;
location / {
proxy_pass http://u$1;
}
}
}
$ curl -H 'Host: s1' http://127.1:8000
10001
$ curl -H 'Host: s2' http://127.1:8000
10002
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: патч для отключения заголовков "Connection: keep-alive" (еще раз)
Илья, приветствую! On Wed, Jan 18, 2017 at 09:58:36AM +0500, Илья Шипицин wrote: > 19 декабря 2016 г., 17:26 пользователь Ruslan Ermilov > написал: > > > Приветствую! > > > > On Sun, Dec 18, 2016 at 10:33:19PM +0500, Илья Шипицин wrote: > > > Руслан, добрый день! > > > > > > а может быть вы сможете закомитить ту версию патча, которую допустимо > > > закомитить ? > > > > В смысле Вы предлагаете мне закоммитить патч Максима, который явно > > обозначил (даже дважды), что не хотел бы его коммитить без тщательного > > тестирования? Боюсь, в таком случае я знаю, каким будет следующий > > коммит. :) > > > > Мне видится более правильным вариант, если Вы сообщите о результатах > > проведённого Вами уже видимо трёхлетнего тестирования патча, который > > предлагал Максим. > > > > Руслан, может быть такой вариант - дефолтное поведение оставить неизменным, > и добавить настройку, скажем "ядреная_оптимизация_кипэлайв on", энтузиасты > включат (на свой риск), протестируют, и можно будет думать о том, чтобы > поменять дефолтное поведение. Лично я в такой ручке вижу мало смысла. Есть готовый патч. Желающие могут его протестировать и сообщить о рез-тах тестирования. После чего патч будет скорее всего закоммичен. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: патч для отключения заголовков "Connection: keep-alive" (еще раз)
Приветствую! On Sun, Dec 18, 2016 at 10:33:19PM +0500, Илья Шипицин wrote: > Руслан, добрый день! > > а может быть вы сможете закомитить ту версию патча, которую допустимо > закомитить ? В смысле Вы предлагаете мне закоммитить патч Максима, который явно обозначил (даже дважды), что не хотел бы его коммитить без тщательного тестирования? Боюсь, в таком случае я знаю, каким будет следующий коммит. :) Мне видится более правильным вариант, если Вы сообщите о результатах проведённого Вами уже видимо трёхлетнего тестирования патча, который предлагал Максим. > 14 декабря 2013 г., 23:59 пользователь Ruslan Ermilov > написал: > > > On Wed, Dec 11, 2013 at 10:04:25PM +0400, Maxim Dounin wrote: > > > Да сколько угодно, я ж разве возражаю? Только тогда патч не будет > > > закоммичен из-за стилистических проблем. ;) > > > > Максим, закоммить пожалуйста свою версию патча и закроем вопрос. > > (Мне твой вариант патча нравится больше.) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: resolver: A vs AAAA
On Wed, Dec 14, 2016 at 09:38:41PM +0300, Dmitry Sivachenko wrote: > > > On 14 Dec 2016, at 20:50, Maxim Dounin wrote: > > > > Hello! > > > > On Wed, Dec 14, 2016 at 08:06:31PM +0300, Dmitry Sivachenko wrote: > > > >>> On 14 Dec 2016, at 19:59, Maxim Dounin wrote: > >>> > >>> Если в конфиге действительно proxy_pass на имя - то при чём тут > >>> resolver? Первыми будет использоваться IPv4-адреса из-за порядка > >>> сохранения записей, который случается в ngx_inet_resolve_host(). > >>> > >>> Однако как и в случае resolver'а - порядок ни на что не влияет, > >>> кроме, может быть, отдельных краевых эффектов, т.к. все полученные > >>> адреса будут использоватся и запросы между ними будут > >>> балансироваться по round-robin. > >> > >> Допустим, что nginx работает на ipv6-only сервере, а some.ip (аргумент > >> proxy_pass) -- имеет и A, и . > >> Я не хочу чтобы nginx вообще пытался устанавливать соединение к > >> ipv4-адресу. > > > > Если у вас ipv6-only сервер - так и будет, т.к. nginx использует > > getaddrinfo() с флагом AI_ADDRCONFIG, и неподдерживаемые адреса > > система просто не вернёт nginx'у. > > > В моем случае на машине настроены ipv4-over-ipv6 туннели, так что реально > ipv4-адреса на интерфейсе есть, но роутинг работает только для ipv6. > > Раз используется getaddrinfo(), то эта функция как раз возвращает адреса в > нужном порядке (учитывает ip6addrctl_policy). > > Так что кажется что проблема лишь в > -- > Первыми будет использоваться IPv4-адреса из-за порядка > сохранения записей, который случается в ngx_inet_resolve_host(). > -- > > Если сохранять порядок, возвращаемый getaddrinfo(), то будет то поведение, > которое нужно. Как уже написал Максим ранее, эти адреса используются в режиме round-robin, поэтому все они рано или поздно будут попробованы. Вот зеркальная ситуация с unroutable IPv6: 1-й запрос: 2016/12/15 09:10:07 [error] 35029#0: *1 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://88.198.44.17:12345/";, host: "127.1:8000" 2016/12/15 09:10:07 [error] 35029#0: *1 connect() to [2a01:4f8:a0:1064::2]:12345 failed (65: No route to host) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:12345/";, host: "127.1:8000" [...] 2-й запрос: 2016/12/15 09:10:21 [error] 35029#0: *4 connect() to [2a01:4f8:a0:1064::2]:12345 failed (65: No route to host) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:12345/";, host: "127.1:8000" 2016/12/15 09:10:23 [error] 35029#0: *4 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://88.198.44.17:12345/";, host: "127.1:8000" ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: resolver: A vs AAAA
On Wed, Dec 14, 2016 at 06:05:48PM +0300, Dmitry Sivachenko wrote:
> Добрый день,
>
> Использую proxy_pass http://some.ip:80 (nginx 1.6.2)
>
> some.ip имеет как A-запись, так и -запись.
>
> На машине настроен приоритет IPv6 при резолвинге
> (ip6addrctl_policy="ipv6_prefer" для FreeBSD).
> Но nginx посылает запросы на IPv4-адрес, а не IPv6.
>
> Как правильно это исправить? (не хочется к конфиг прописывать ip-адрес).
Сейчас после резолвинга сначала отдаются IPv4-адреса, а затем IPv6-адреса.
Впоследствии, если результат резолвинга закэширован, адреса ротируются.
С таким патчем становится возможным контролировать приоритет IPv6 над
IPv4 в выдаче адресов.
# HG changeset patch
# User Ruslan Ermilov
# Date 1481732592 -10800
# Wed Dec 14 19:23:12 2016 +0300
# Node ID bfebe45e2dbb952a25655ead0c7a9a80a50b34e0
# Parent 7bb061c9e1dcc160d80b81c5b07ae5ff83ff221a
Resolver: allow controlling preference of IPv6 over IPv4.
diff --git a/src/core/ngx_resolver.c b/src/core/ngx_resolver.c
--- a/src/core/ngx_resolver.c
+++ b/src/core/ngx_resolver.c
@@ -233,6 +233,12 @@ ngx_resolver_create(ngx_conf_t *cf, ngx_
} else if (ngx_strcmp(&names[i].data[5], "off") == 0) {
r->ipv6 = 0;
+} else if (ngx_strcmp(&names[i].data[5], "primary") == 0) {
+r->ipv6 = 2;
+
+} else if (ngx_strcmp(&names[i].data[5], "backup") == 0) {
+r->ipv6 = 3;
+
} else {
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
"invalid parameter: %V", &names[i]);
@@ -4177,6 +4183,16 @@ ngx_resolver_export(ngx_resolver_t *r, n
i = 0;
d = rotate ? ngx_random() % n : 0;
+#if (NGX_HAVE_INET6)
+if (r->ipv6 == 2) {
+/* prefer IPv6 */
+d = rn->naddrs6;
+} else if (r->ipv6 == 3) {
+/* prefer IPv4 */
+d = 0;
+}
+#endif
+
if (rn->naddrs) {
j = rotate ? ngx_random() % rn->naddrs : 0;
diff --git a/src/core/ngx_resolver.h b/src/core/ngx_resolver.h
--- a/src/core/ngx_resolver.h
+++ b/src/core/ngx_resolver.h
@@ -176,7 +176,7 @@ struct ngx_resolver_s {
ngx_queue_t addr_expire_queue;
#if (NGX_HAVE_INET6)
-ngx_uint_tipv6; /* unsigned ipv6:1; */
+ngx_uint_tipv6;
ngx_rbtree_t addr6_rbtree;
ngx_rbtree_node_t addr6_sentinel;
ngx_queue_t addr6_resend_queue;
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Где директива include ищет файлы?
On Thu, Feb 18, 2016 at 05:35:32AM -0500, tetramin wrote: > Добрый день. > > Разъясните, пожалуйста, где include ищет файлы? Относительно каталога nginx? > А можно ли, не указывая полный путь, подключить файл из того же каталога, > где лежит конфиг виртуального хоста? Относительно каталога основного конфигурационного файла nginx. > Допустим, конфиг виртуалхоста в sites-available/sitename/virtualhost.conf > А рядом с ним лежит файл, который хочу подключить: > sites-available/sitename/params.conf > > Могу я в virtualhost.conf указать: > include ./params.conf > ? > > Заранее благодарю. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: сравнение строк в map
On Tue, Jan 19, 2016 at 06:04:02PM +0300, Валентин Бартенев wrote: > On Tuesday 19 January 2016 14:02:36 Oleg Palij wrote: > > Добрый день! > > > > Не нашел в документации - сравнение строк (не регулярных выражений) в map > > регистрозависимое или нет? > > > > Судя по тому что я вижу на практике - оно регистронезависимое + в сорцах > > нашел: > > http/ngx_http_variables.c > > ngx_http_map_find > > key = ngx_hash_strlow(low, match->data, len); > > что вроде бы подтверждает то, что ключи приводятся к нижнему регистру. > > > > Но все-таки хотелось бы подтверждения в виде ссылки на документацию, или > > комментария от того кто в этом разбирается. > > > Да, регистронезависимое. http://hg.nginx.org/nginx.org/rev/68b647a96448 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: баг сафари на http/2
On Tue, Oct 20, 2015 at 03:13:56PM +0500, Илья Шипицин wrote: > забыл уточнить - баг воспроизводится на iOS9 и Mac OS 10.11 > > 20 октября 2015 г., 15:00 пользователь Илья Шипицин > написал: > > > Добрый день! > > > > налетели на ситуацию > > > > 1) браузер сафари (без разницы - десктопный или мобильный) > > 2) включен http2 > > 3) отправляется POST с пустым телом > > 4) запрос проксируется с nginx на http-апстрим > > > > в результате получается, что сафари, видя, что тело пустое - не добавляет > > Content-Length, а nginx, видя, что Content-Length отсутствует - возвращает > > 411 > > > > давайте с этим что-нибудь сделаем ? > > > > стенд для воспроизведения бага: https://http2.skbkontur.ru > > > > Илья Шипицин На основании чего сделан вывод о том, что это имеет какое-либо отношение к HTTP/2? С обычным HTTP POST-запросом на сайте наблюдается такое же поведение: $ curl -v --data '' -H 'content-length:' http://http2.skbkontur.ru/ * Connected to http2.skbkontur.ru (46.17.201.207) port 80 (#0) > POST / HTTP/1.1 > Host: http2.skbkontur.ru > User-Agent: curl/7.43.0 > Accept: */* > Content-Type: application/x-www-form-urlencoded > < HTTP/1.1 411 Length Required < Server: nginx < Date: Tue, 20 Oct 2015 10:35:48 GMT < Content-Type: text/html; charset=us-ascii < Content-Length: 344 nginx по собственной воле никогда не возвращает 411, так что это скорее всего проделки вашего бэкенда. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: GeoIP
On Tue, Sep 08, 2015 at 02:22:56AM -0400, agz wrote:
> map я использую. в секции http:
> geoip_country /usr/share/GeoIP/GeoIP.dat;
> map $geoip_country_code $allowed_country {
> default yes;
> US no;
> UK no;
> }
> Или что то другое Вы имели ввиду?
Можно одновременно определять страну и по списку:
geo $geo_country {
127.0.0.1 RU;
10.0.0.0/8 RU;
}
и по базе GeoIP:
map $geo_country $country {
'' $geoip_country_code;
default $geo_country;
}
Как это работает: если клиентского адреса нет в списке
geo, то страна ($country) определяется по базе GeoIP.
Blacklist по странам также можно сделать при помощи map:
map $country $restricted {
XX 1;
YY 1;
ZZ 1;
}
Останется предпринять нужные действия:
if ($restricted) {
return 403;
}
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Максимально возможные значения для fastcgi_connect_timeout и fastcgi_read_timeout
On Tue, Nov 25, 2014 at 03:25:38PM +0400, Алексей Сундуков wrote: > Т.е. согласно директиве fastcgi_connect_timeout nginx для сокета выставляет > заданный в конфиге таймаут, но эта величина будет игнорироваться если она > превышает заданную для ядра? Т.е. кроме увеличения fastcgi_connect_timeout > в конфиге nginx нужно еще изменять настройки ядра, так? > > А почему тогда в документации говорится: "что этот таймаут обычно не может > превышать 75 секунд"? Я к тому, почему именно 75? nginx изначально разрабатывался под FreeBSD, на ней (цитата из tcp(4)): : Timeout, in milliseconds, for new, non-established TCP connections. : The default is 75000 msec. > 25 ноября 2014 г., 14:17 пользователь Igor Sysoev написал: > > > On 25 Nov 2014, at 11:48, Алексей Сундуков wrote: > > > > Всем привет! > > > > Когда-то давно я помню, что было обсуждение этих директив и было > > упоминание, что > > http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_connect_timeout > > поднять выше 75 секунд нельзя и это захаркожено и исходниках. В связи с чем > > вопросы: > > > > 1) Где в коде эти 75 секунд заданы в случае, если нужно этот лимит поднять? > > 2) Есть ли для fastcgi_read_timeout подобных хардкод, и если да, то где он? > > > > > > Это ограничения ядра, а не nginx’а. > > > > Вот тут > > > > http://www.sekuda.com/overriding_the_default_linux_kernel_20_second_tcp_socket_connect_timeout > > утверждается, что на Линуксе этот таймаут максимум 20 секунд и даны > > рекомендации, > > как его увеличить. Не проверял. > > > > > > -- > > Igor Sysoev > > http://nginx.com > > > > > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- Ruslan Ermilov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.7.7
On Tue, Oct 28, 2014 at 03:15:01PM -0400, S.A.N wrote: > > Изменения в nginx 1.7.7 > > 28.10.2014 > > > > *) Изменение: теперь nginx учитывает при кэшировании строку "Vary" > > в > >заголовке ответа бэкенда. > > Где можно почитать подробности влияния Vary, на кеширования в Nginx? Какие-то подробности будут в документации, которая ещё не обновлена. Какие-то останутся в коде. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Хитрый учет скачиваемых по прямым ссылкам файлов (nginx + piwik)
On Wed, Apr 23, 2014 at 07:12:56PM -0400, iprok wrote:
> Здравствуйте!
>
> Есть сайт одной программы, на котором в частности выкладываются ее
> дистрибутивы.
> Пользователям они доступны следующими способами:
> 1) По ссылкам со страницы sitename.org/downloads/ (редактируемая авторами
> сайта html с ссылками)
> 2) Путем просмотра sitename.org/files (список файлов и папок автоматически
> генерируемый через fancyindex)
> 3) Прямые ссылки извне.
>
> Стоит задача учитывать скачивания файлов по всем трем ссылкам. Парсинг логов
> не подходит (используется piwik, а он через логи сильно меньше инфы
> получает). Поэтому выбрал способ через php скрипт с x-accel-redirect. При
> этом скачивания через пункт 1 учитываются из коробки, так что они должны
> быть исключены, чтобы избежать дублей.
>
> Посмотрите, пожалуйста, вырезку из конфигов. files.down - символическая
> ссылка на files (без этого был циклический редирект. Можно ли без нее?). Все
> ли я правильно сделал?
Можно обойтись без symlink'а, используя директиву
"alias /var/www/sitename.org/files/" вместо root внутри
"location /files.down/". Этот location также имеет
смысл пометить как внутренний директивой internal.
Справочно сообщаю, что в готовящемся к выпуску релизе
реализована [1] возможность условной записи в access_log,
как-то так:
access_log logs/access.log combined if=$direct_download;
[1] http://hg.nginx.org/nginx/rev/cb308813b453
> nginx.conf:
> http {
> ...
> map $http_referer $direct_download {
> default 1;
> ~*sitename.org/files/.* 1;
> ~*://sitename.org 0;
> }
> ...
> server {
> ...
> root /var/www/sitename.org/htdocs;
> ...
> location /files/ {
> location ~* /.*?[^/]$ { #Обрабатывает все файлы, но не
> директории, листинг которых через fancyindex (на конце uri не должен быть /
> )
> if ($direct_download) {
> rewrite ^/files/(.*) /down.php?path=$1
> last;
> }
> }
> root /var/www/sitename.org/;
>
> fancyindex on;
> fancyindex_exact_size off;
>
> aioon;
> directio 512;
> output_buffers 1 128k;
> }
> location /files.down/ {
> root /var/www/sitename.org/;
>
> aioon;
> directio 512;
> output_buffers 1 128k;
> internal;
> }
>
> }}
>
> ну и down.php:
>
> ...
> // And redirect user to internal location
> header("Content-Type: application/octet-stream");
> header("X-Accel-Redirect: /files.down/" . $path);
> ?>
>
> Заранее спасибо всем откликнувшимся.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: chunkin сломан?
On Wed, Feb 12, 2014 at 10:21:48AM +0400, denis wrote: > 12.02.2014 8:49, Sargas пишет: > > Этот модуль уже не нужен, причем давно. Так же не нужно что-то в > > конфиге прописывать. Это просто работает :) > А где про это офдоки? > и кто знает, с каких версий nginx оно было рабочее и в каких выпилено. http://nginx.org/ru/CHANGES.ru-1.4 : Изменения в nginx 1.3.9 27.11.2012 : : *) Добавление: поддержка chunked transfer encoding при получении тела :запроса. : : [...] ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fastcgi cache - не кеширует
On Tue, Dec 17, 2013 at 10:58:11AM -0500, gigabyte wrote:
> Здравствуйте уважаемые знатоки. Помогите пожалуйста
> Проблема в следующем: Хочу закешировать ответ от php-fpm. И точно знаю что
> он работал но теперь непонятно почему - не хочет работать (файлы в
> /tmp/nginx - папка кеша) не создаются.
> Конфиг обработки php выглядит следующим образом:
> location ~ \.php$ {
> add_header "X-Debug-cachekey"
> $request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_key|$cookie_phpsessid;
> fastcgi_index index.php;
> fastcgi_pass 127.0.0.1:9000;
> fastcgi_cache_bypass $skip_cache;
> fastcgi_cache gk;
> fastcgi_cache_valid 200 301 302 304 10s;
> fastcgi_cache_min_uses 1;
> fastcgi_hide_header "Set-Cookie";
Может быть в ответе есть Set-Cookie?
> fastcgi_ignore_headers "Cache-Control" "Expires";
http://nginx.org/r/fastcgi_cache_valid/ru
: Ответ, в заголовке которого есть поле “Set-Cookie”, не будет кэшироваться.
: Обработка одного или более из этих полей заголовка может быть отключена
: при помощи директивы fastcgi_ignore_headers.
> fastcgi_cache_key
> "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_key|$cookie_phpsessid";
>
> include fastcgi_params;
>
> fastcgi_param DOCUMENT_ROOT$document_root;
> fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
> fastcgi_param PATH_TRANSLATED
> $document_root$fastcgi_script_name;
> fastcgi_param PATH_INFO$fastcgi_path_info;
> fastcgi_param QUERY_STRING $query_string;
> fastcgi_param REQUEST_METHOD $request_method;
> fastcgi_param CONTENT_TYPE $content_type;
> fastcgi_param CONTENT_LENGTH $content_length;
> fastcgi_intercept_errorson;
> fastcgi_ignore_client_abort off;
> fastcgi_connect_timeout 60;
> fastcgi_send_timeout 180;
> fastcgi_read_timeout 180;
> fastcgi_buffer_size 128k;
> fastcgi_buffers 4 256k;
> fastcgi_busy_buffers_size 256k;
> fastcgi_temp_file_write_size 256k;
> }
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.5.8
On Tue, Dec 17, 2013 at 06:34:54PM +0400, Никита Козлов wrote: > 17 декабря 2013 г., 18:08 пользователь Maxim Dounin > написал: > > Изменения в nginx 1.5.8 17.12.2013 > > *) Исправление: параметр setfib директивы listen мог не работать. > > А при каких условиях setfib мог не работать? nginx экономит на listen-сокетах, когда можнa (см. описание параметра bind тут: http://nginx.org/r/listen/ru) Наличие в директиве listen параметра setfib означает, что для этого нужно создать отдельный сокет. Если других причин создавать отдельный сокет код nginx не усматривал, этого не происходило, и соотв. параметр setfib фактически игнорировался. Для первой по порядку listen для данного IP-адреса:порта это работало, для не первой - могло не работать. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: патч для отключения заголовков "Connection: keep-alive" (еще раз)
On Wed, Dec 11, 2013 at 10:04:25PM +0400, Maxim Dounin wrote: > Да сколько угодно, я ж разве возражаю? Только тогда патч не будет > закоммичен из-за стилистических проблем. ;) Максим, закоммить пожалуйста свою версию патча и закроем вопрос. (Мне твой вариант патча нравится больше.) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: REST response
On Fri, Dec 13, 2013 at 10:12:54AM +0400, Илья Страхов wrote:
>Здравствуйте.
>Подскажите пожалуйста, можно в лог nginx
>вывести REST response?
>
>
> {"response":{"status":200,"message":"OK","data":{"id":"70","name":"..
>.."}}}
http://nginx.org/r/log_format/ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx keep-alive ipv6 6in4
On Sat, Oct 19, 2013 at 02:07:26PM +0400, Maxim Dounin wrote: > On Fri, Oct 18, 2013 at 04:05:14PM -0400, actionmanager wrote: > > > >>А другие сайты могут открываться по более чем одной причине, например - > > если используют MTU меньше, чем к вам в тоннель пролезает. > > > > Вот именно это и есть решение проблемы. MTU 1420 на сервере и всё работает > > ))) > > > > Спасибо большое ;) > > Пожалуйста, но имейте ввиду, что это - не решение, а грязный хак > "чтоб заработало". Проблема - как была, так и осталась, просто > больше не проявляется при общении с вашим сервером. К сожалению в реальной жизни только это и решение. Именно так родились http://svnweb.freebsd.org/ports/head/net/tcpmssd/pkg-descr?revision=HEAD опция mssfixup в ppp(8) на FreeBSD, -clamp_mss в natd(8) на OS X, и многое др. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: allow/deny and return
On Wed, Oct 16, 2013 at 01:12:29PM +0400, Anton Yuzhaninov wrote:
> On 10/15/13 16:45, Maxim Dounin wrote:
> > On Tue, Oct 15, 2013 at 04:26:32PM +0400, Anton Yuzhaninov wrote:
> >
> >> В такой конфигурации:
> >>
> >> location /closed {
> >>allow 10.1.1.1;
> >>deny all;
> >>return 200 "secret\n";
> >> }
>
> > Я, например, хорошего способа не знаю. Потому что не с первого
> > взгляда - момент в общем-то очевидный (у прочитавших документацию
> > на модуль rewrite вопросов, как мне кажется, возникнуть не
> > должно), а как это корректно рассказать не читавшим...
>
> В документации на rewrite:
> http://nginx.org/en/docs/http/ngx_http_rewrite_module.html не нашел явное
> указание на то, что директивы этого модуля выполняются до модулей access-фазы
> (ngx_http_access_module,ngx_http_auth_basic_module,
> ngx_http_auth_request_module).
>
> Если знать внутреннюю архитектуру nginx то это очевидно, но прочитав только
> документацию на ngx_http_rewrite_module и ngx_http_access_module догадаться
> будет сложно.
То, что в описанном тобой случае директива access "не выполняется",
можно понять, прочитав раздел "Внутреннее устройство", нюанс про
директиву limit_rate.
> Думаю можно просто добавить в начало описания ngx_http_rewrite_module
> маленький
> абзац про это.
Написать, что директивы модуля rewrite выполняются до директив модуля
access - это плохая идея, т.к. это не отразит сути и только запутает.
Надо донести мысль о том, что rewrite (включая ВСЕ его директивы) -
это процесс поиска location'а. При обработке запроса сначала выполняется
поиск location'а по URI, затем выполняются директивы модуля rewrite (и
только они!) для данного location'а (*), в рез-те location может измениться,
процесс повторяется. Также в процессе поиска location'а выполнение
запроса может и вовсе завершиться (return, rewrite redirect).
И лишь потом, когда найден конечный location, "выполняются" остальные
директивы, включая access-модули.
(*) Я специально выше опустил пункт про директивы rewrite на уровне
server, дабы не загромождать.
Возможно достаточно будет переформулировать это так:
< Директивы модуля ngx_http_rewrite_module обрабатываются в следующем порядке:
> Обработка запроса начинается с выполнения директив модуля
> ngx_http_rewrite_module.
> Директивы обрабатываются в следующем порядке:
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: allow/deny and return
On Tue, Oct 15, 2013 at 04:45:28PM +0400, Maxim Dounin wrote:
> Hello!
>
> On Tue, Oct 15, 2013 at 04:26:32PM +0400, Anton Yuzhaninov wrote:
>
> > В такой конфигурации:
> >
> > location /closed {
> > allow 10.1.1.1;
> > deny all;
> > return 200 "secret\n";
> > }
> >
> > allow/deny ни на что не влияют.
> >
> > IMHO стоит написать об этом в документации, момент не очевидный с первого
> > взгляда.
>
> Если ты готов предолжить хороший способ написать об этом - мы с
> удовольствием.
>
> Я, например, хорошего способа не знаю. Потому что не с первого
> взгляда - момент в общем-то очевидный (у прочитавших документацию
> на модуль rewrite вопросов, как мне кажется, возникнуть не
> должно), а как это корректно рассказать не читавшим...
Пока про это у нас есть такое:
http://www.aosabook.org/en/nginx.html
Читать со слов "Which brings us to the phases."
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Различия в переменных адреса
On Sat, Oct 05, 2013 at 12:26:25AM -0400, Aleus Essentia wrote: > Вопрос: в чём разница следующих переменных: > r->headers_in.host, Значение заголовка Host из запроса. > r->headers_in.server, Имя запрашиваемого хоста (определяется либо из строки запроса, либо по заголовку Host). > r->connection->addr_text? Текстовое представление адреса клиента. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Ошибка при компиляции с image filter module (libgd стоит!)
On Mon, Sep 30, 2013 at 11:05:18AM +0300, Alex Domoradov wrote: > Просто при сборке надо явно указывать путь > > # ./configure --with-http_image_filter_module > --with-cc-opt=-I/opt/libgd-2.1.0/include > --with-ld-opt=-L/opt/libgd-2.1.0/lib/ > # make > > # ldd objs/nginx | grep libgd > libgd.so.3 => /opt/libgd-2.1.0/lib/libgd.so.3 (0x7ff43af12000) > > 2 Developers > А почему nginx игнорирует CFLAGS/LDFLAGS? Т.е. если я делаю > > # export CFLAGS=-I/opt/libgd-2.1.0/include/ > # export LDFLAGS=-L/opt/libgd-2.1.0/lib/ > > а потом пробую собрать, то получаю ошибку > > # ./configure --with-http_image_filter_module > ... > checking for GD library ... not found > checking for GD library in /usr/local/ ... not found > checking for GD library in /usr/pkg/ ... not found > checking for GD library in /opt/local/ ... not found Потому что configure nginx'а не поддерживает LDFLAGS. > 2013/9/30 Alex Domoradov : > >> У вас заголовочные файлы стоят - libgd-dev? > > ТС из исходников ставил libgd. > > > > 2013/9/30 Aleksandr Sytar : > >> > >> > >> > >> 29 сентября 2013 г., 12:08 пользователь MaxNikitin > >> написал: > >> > >>> Здравствуйте. Скачал последнюю версию libgd (2.1.0), скомпилировал > >>> (настройки по умолчанию), запускаю ./configire > >>> --with-http_image_filter_module (версия исходников nginx - 1.5.5) - ошибок > >>> не выдает (checking for GD library ... found), однако, при запуске make > >>> вылезает ошибка: > >>> objs/ngx_modules.o \ > >>> -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lgd > >>> objs/src/http/modules/ngx_http_image_filter_module.o: In function > >>> `ngx_http_image_source': > >>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1030: > >>> undefined > >>> reference to `gdImageCreateFromJpegPtr' > >>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1040: > >>> undefined > >>> reference to `gdImageCreateFromPngPtr' > >>> objs/src/http/modules/ngx_http_image_filter_module.o: In function > >>> `ngx_http_image_out': > >>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1106: > >>> undefined > >>> reference to `gdImageJpegPtr' > >>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1116: > >>> undefined > >>> reference to `gdImagePngPtr' > >>> collect2: ld returned 1 exit status > >>> > >>> Что я не так делаю? > >> > >> > >> > >> У вас заголовочные файлы стоят - libgd-dev? > >> > >> ___ > >> 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 > -- Ruslan Ermilov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Учитывает ли nginx-прокси кэш-заголовки с бэкенда?
On Wed, Sep 25, 2013 at 06:12:34AM -0400, Dymytry wrote: > Спасибо, Руслан! С первыми двумя вопросами все-таки не совсем понятно. > > Я хочу понять: сохраняет ли nginx proxy внутри себя кэш-заголовки ответа > бэкенда для последующего использования? > То есть, имеется ли внутри nginx proxy таблица вида... > > URL-- Cache Header- > /logo.png expires 12-10-2013 > /icom.pngexpires 01-01-1970 > > ... которая используется для того, чтобы получив запрос на /logo.png прокси > отдал кэш, а на /icon.png - полез бы в бэкенд, несмотря на то что кэш есть. > > В описании директивы proxy_use_stale не указано, к сожалению, как именно > nginx proxy решает, является ли данный ресурс stale. Это именно то, что я > хочу понять: он решает это на основании заголовков предыдущих ответов > бэкенда на данный запрос, или ТОЛЬКО на основании proxy_cache_valid? По тем ссылкам, что я дал, есть все ответы на все ваши вопросы. Ниже соотв. цитаты. http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid [...] Параметры кэширования могут также быть заданы непосредственно в заголовке ответа. Такой способ приоритетнее, чем задание времени кэширования с помощью директивы. http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers [...] Если не запрещено, обработка этих полей заголовка заключается в следующем: - “X-Accel-Expires”, “Expires”, “Cache-Control” и “Set-Cookie” задают параметры кэширования ответа; ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Учитывает ли nginx-прокси кэш-заголовки с бэкенда?
On Wed, Sep 25, 2013 at 04:58:31AM -0400, Dymytry wrote: > День добрый! > Изучаю nginx, разбираюсь в кэшировании, имею browser + nginx reverse proxy + > nginx web-server. > > Допустим клиент сделал запрос, прокси перевел его на бэкенд, тот ответил и > прокси отдал ответ клиенту. Допустим бэкенд проставил какие-то заголовки, > связанные с кэшем, например: > Cache-Control: no-cache (или) > Cache-Control: max-age=10 (или) > Expires: 'Next Friday' > > Вопрос 1: следующий запрос клиента к этому ресурсу будет обработан с учетом > этих заголовков? Ответ на этот вопрос есть в документации: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers > Вопрос 2: как nginx-proxy понимает что ресурс stale и его не надо отдавать > клиенту, а надо спросить бэкенд? (кроме директивы proxy_cache_valid) Может > ли он понять это из заголовков ответа бэкенда? Ответ на этот вопрос есть в документации: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_use_stale > Вопрос 3: может ли клиент заставить прокси закрузить свежую версию ресурса, > которая еще не истекла согласно proxy_cache_valid? Может, если администратор nginx сочтёт нужным: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_bypass > Я пробую играть с заголовками Cache-Control прокси и бэкенда, и насколько я > могу судить, если ресурс закэшировался в прокси ничто не поможет мне > получить его свежую версию кроме удаления кэша или истечения > proxy_cache_valid. То есть "модель" кэша nginx reverse proxy это просто > веб-сервер с контентом, равным тому, что удалось закэшировать, а что именно > кэшировать определяется тем, не ставит ли бэкенд Cache-Control: no-cache или > no-store; заголовки Expired, Cache-Control: max-age бэкенда не учитываются. > > Я правильно понимаю, или нет? > Так работают все прокси, и squid, и разные публичные прокси в интернете? > Изменить ли что-то, если nginx-proxy соединяется с клиентом по SSL? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вызов map variable дважды
On Thu, Aug 15, 2013 at 03:18:43AM -0400, lekrus wrote:
> Здравствуйте,
>
> У меня используется переменная
> map $v_host $backend {
> default 1;
> test 2;
> test2 3;
> }
>
> Далее идет
>
> location / {
> set $v_host test;
> proxy_pass $backend #(тут переменная $backend правильно определяется, равна
> 2)
> }
>
> в процессе, upstream возвращает X-Accel-Redirect который вызывает другой
> location /int {
> internal;
> set $v_host test2;
> rewrite (.*) $backend
> }
>
> и при таком вызове $backend остается равен 2, должен быть 3.
>
> Я правильно понимаю, что в процессе одного вызова, если переменная map хоть
> раз была вычислена, далее все остальные вызовы используют это значение,
> независимо от того, меняется ли переменная, по которой определяется
> значение?
Правильно понимаете. Определяться кстати она может не только
по одной переменной, а по произвольному выражению, содержащему
как строки, так и переменные.
> Есть ли возможность как-то заставить перевычислить это значение?
Можно, но только пропатчив nginx:
diff --git a/src/http/modules/ngx_http_map_module.c
b/src/http/modules/ngx_http_map_module.c
--- a/src/http/modules/ngx_http_map_module.c
+++ b/src/http/modules/ngx_http_map_module.c
@@ -477,7 +477,7 @@ ngx_http_map(ngx_conf_t *cf, ngx_command
}
var->valid = 1;
-var->no_cacheable = 0;
+var->no_cacheable = 1;
var->not_found = 0;
vp = ngx_array_push(&ctx->values_hash[key]);
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx использует IPv6 в proxy pass, даже если он отключен
On Wed, Jul 31, 2013 at 04:06:27AM -0400, Antohat wrote: > Добрый день, > > На сервере отключен IPv6. На nginx настроено проксирование на upstream c > поддержкой IPv4 и IPv6. > > Nginx периодически (раз в 5 секунд) пытается отправлять запросы на IPv6 и > соответственно обламывается с ошибками: > > 2013/07/30 00:25:06 [error] 1930#0: *1482670 connect() to > [::C:DDD:E:F:GGG:HHH]:443 failed (101: Network is unreachable) while > connecting to upstream, client: AA.BB.CC.DD, server: example.com, request: > "GET /download/file HTTP/1.0", upstream: > "https://[::C:DDD:E:F:GGG:HHH]:443/download/file";, host: > "example.com" > > Как можно отключить IPv6 для proxy_pass? http://hg.nginx.org/nginx/rev/ec8594b9bf11 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx использует IPv6 в proxy pass, даже если он отключен
On Thu, Aug 01, 2013 at 04:13:32AM -0400, Antohat wrote:
> Ruslan Ermilov Wrote:
> > Что ж бедному nginx, на каждый чих это проверять? Ведь сейчас
> > может быть не настроен, а через минуту уже настроен.
>
> Проксирование на домен (без апстрима) вроде бы работает корректно (по
> крайней мере ошибки в лог больше не пишутся). Т.е. не такая уж это большая
> проблема, определять поддержку IPv6.
Вы имеете в виду вариант proxy_pass http://download.exmaple.com ?
Если да, та разницы никакой нет.
В этом случае все IP-адреса (включая IPv6) будут также определены
единожды на этапе чтения конфигурации, после чего все адреса будут
использоваться в режиме round-robin, как и документировано [1]:
: Если доменному имени соответствует несколько адресов, то
: все они будут использоваться по очереди (round-robin).
: Кроме того, в качестве адреса можно указать группу серверов.
[1] http://nginx.org/r/proxy_pass/ru
Вот живой пример:
server {
location / {
proxy_pass http://lo0.su;
}
}
Из error_log'а, запросы раз в секунду:
2013/08/01 11:05:22 [error] 12561#0: *3 connect() to [2a01:4f8:a0:1064::2]:80
failed (101: Network is unreachable) while connecting to upstream, client:
127.0.0.1, server: , request: "HEAD / HTTP/1.1", upstream:
"http://[2a01:4f8:a0:1064::2]:80/";, host: "127.0.0.1:8000"
2013/08/01 11:05:35 [error] 12561#0: *30 connect() to [2a01:4f8:a0:1064::2]:80
failed (101: Network is unreachable) while connecting to upstream, client:
127.0.0.1, server: , request: "HEAD / HTTP/1.1", upstream:
"http://[2a01:4f8:a0:1064::2]:80/";, host: "127.0.0.1:8000"
2013/08/01 11:05:48 [error] 12561#0: *55 connect() to [2a01:4f8:a0:1064::2]:80
failed (101: Network is unreachable) while connecting to upstream, client:
127.0.0.1, server: , request: "HEAD / HTTP/1.1", upstream:
"http://[2a01:4f8:a0:1064::2]:80/";, host: "127.0.0.1:8000"
То есть 1-й запрос идёт на IPv4-адрес, 2-й - на IPv6, далее начинает
действовать max_fails=1 и fail_timeout=10 для неявных апстримов и
IPv6-адрес временно не используется, спустя ~10 секунд снова пробный
запрос на IPv6, и т.д.
nginx version: nginx/1.4.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
configure arguments: --with-debug --with-ipv6
> С распространением IPv6 описанная в топике проблема, когда апстрим
> поддерживает IPv6, а сервер с Nginx'ом нет, будет все более актуальна.
Проблема, если она и есть, не в nginx. Ваш nginx собран с поддержкой
IPv6, значит при резолвинге имён, как и любая другая прикладная
программа, он получает и IPv4-, и IPv6-адреса.
> Проблема конечно решается самостоятельной сборкой nginx, но это решение не
> соответствует стратегии более широкого распространения продукта.
Не существует универсального способа узнать, что на системе
выключен IPv6. Кроме того, выключенность IPv6 - это не постоянное
состояние.
Не возвращать IPv6-адреса при резолвинге имён, если в системе не
сконфигурирован IPv6, это в общем случае неправильное поведение.
С другой стороны, во многих прикладных программах доступны опции
командной строки -4 и -6, которые заставляют программу использовать
только IPv4- или только IPv6-адреса. Я подумаю в эту сторону.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx использует IPv6 в proxy pass, даже если он отключен
On Wed, Jul 31, 2013 at 06:10:55AM -0400, Antohat wrote: > Ruslan Ermilov Wrote: > --- > > Как-то заставить системный resolver(3) не возвращать IPv6-адреса > > (ответы > > типа ) для хоста, на котором отключен IPv6. Попробуйте добиться > > желаемого эффекта с командой > > > > telnet download.example.com > Не уверен, что так можно сделать... > Может быть было бы правильнее, чтобы nginx определял, что IPv6 не настроен и > не пытался использовать записи ? Что ж бедному nginx, на каждый чих это проверять? Ведь сейчас может быть не настроен, а через минуту уже настроен. > По крайней мере такой параметр в конфиге точно не был бы лишним. А ещё хорошо иметь настройку в nginx.conf, которая проверяет, что утюг дома не забыли выключить. :) > > Или же использовать IPv4-адреса в конфигурации nginx. Кстати, в > > приведенной конфигурации директива resolver не нужна. > К сожалению не можем, т.к. IP апстрима могут меняться без предварительного > уведомления. Ну соберите nginx без --with-ipv6, и будет вам счастье. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx использует IPv6 в proxy pass, даже если он отключен
On Wed, Jul 31, 2013 at 04:06:27AM -0400, Antohat wrote:
> Добрый день,
>
> На сервере отключен IPv6. На nginx настроено проксирование на upstream c
> поддержкой IPv4 и IPv6.
>
> Nginx периодически (раз в 5 секунд) пытается отправлять запросы на IPv6 и
> соответственно обламывается с ошибками:
>
> 2013/07/30 00:25:06 [error] 1930#0: *1482670 connect() to
> [::C:DDD:E:F:GGG:HHH]:443 failed (101: Network is unreachable) while
> connecting to upstream, client: AA.BB.CC.DD, server: example.com, request:
> "GET /download/file HTTP/1.0", upstream:
> "https://[::C:DDD:E:F:GGG:HHH]:443/download/file";, host:
> "example.com"
>
> Как можно отключить IPv6 для proxy_pass?
Как-то заставить системный resolver(3) не возвращать IPv6-адреса (ответы
типа ) для хоста, на котором отключен IPv6. Попробуйте добиться
желаемого эффекта с командой
telnet download.example.com
Или же использовать IPv4-адреса в конфигурации nginx. Кстати, в
приведенной конфигурации директива resolver не нужна.
> # nginx.conf:
> upstream download {
> server download.example.com:443;
> keepalive 8;
> }
>
> location /download {
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Connection "";
> proxy_ignore_headers X-Accel-Redirect;
> proxy_http_version1.1;
> resolver 8.8.8.8;
> resolver_timeout 5s;
> proxy_passhttps://download;
> }
>
> nginx -V:
> nginx version: nginx/1.4.2
> built by gcc 4.7.2 (Debian 4.7.2-5)
> TLS SNI support enabled
> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
> --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
> --lock-path=/var/run/nginx.lock
> --http-client-body-temp-path=/var/cache/nginx/client_temp
> --http-proxy-temp-path=/var/cache/nginx/proxy_temp
> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
> --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx
> --with-http_ssl_module --with-http_realip_module --with-http_addition_module
> --with-http_sub_module --with-http_dav_module --with-http_flv_module
> --with-http_mp4_module --with-http_gunzip_module
> --with-http_gzip_static_module --with-http_random_index_module
> --with-http_secure_link_module --with-http_stub_status_module --with-mail
> --with-mail_ssl_module --with-file-aio --with-http_spdy_module
> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt=-Wl,-z,relro
> --with-ipv6
>
> uname -a:
> Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,241403,241403#msg-241403
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: load balancer backend failed condition
On Thu, Mar 28, 2013 at 04:57:29AM -0400, tolikkk wrote:
> Добрый день.
>
> Имеется nginx версии 1.2.7. Использую его в качестве HTTP-балансировщика с
> модулем upstream (HttpUpstreamModule).
>
> Кусок конфига:
>
> upstream lb_units {
> server app01:51001 max_fails=3 fail_timeout=30s;
> server app01:51002 max_fails=3 fail_timeout=30s;
> server app02:51001 max_fails=3 fail_timeout=30s;
> server app02:51002 max_fails=3 fail_timeout=30s;
> }
>
> server {
> listen 51000;
> server_name localhost;
>
> location / {
> proxy_pass http://lb_units;
> }
> }
>
> На основе чего server помечается, как недоступный и на него перестают
> направляться запросы?
> В документации сказано "If an error occurs when communicating with the
> server, a request will be passed to the next server". Достаточным условием
> работоспособности является факт установки TCP-соединения на server:port?
http://nginx.org/r/proxy_next_upstream/ru
> Собственно мой вопрос - можно ли прикрутить какую-то прикладную логику к
> проверке доступности backend-серверов? Я хотел бы отправлять вполне
> конкретный POST-запрос и уже на основе разбора полученного ответа принимать
> решение надо ли помечать backend-сервер, как failed - подскажите пожалуйста,
> такое возможно? Если да - где можно почитать описание и примеры?
Штатными средствами нельзя.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx as TCP proxy
On Tue, Mar 26, 2013 at 08:23:51PM +0700, Victor Sudakov wrote:
> Коллеги,
>
> Пытаюсь использовать nginx-devel-1.3.14 (из портов FreeBSD) как tcp load
> balancer. Почему-то тест конфига не проходит с сообщением:
>
> Performing sanity check on nginx configuration:
> nginx: [warn] upstream "test" may not have port 80 in
> /usr/local/etc/nginx/nginx.conf:34
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
>
> Что я делаю не так? Заранее спасибо. Полный конфиг приведён ниже.
>
>
> worker_processes 1;
>
> events {
> worker_connections 1024;
> }
>
> tcp {
> upstream test {
> # simple round-robin
> server localhost:783;
> server murka:783;
> check interval=3000 rise=2 fall=5 timeout=1000;
> }
>
> server {
> listen 7783;
> proxy_pass test ;
> }
> }
tcp_proxy - это сторонний модуль.
В -devel иногда случаются API-несовместимые изменения, это было одно
из них: http://trac.nginx.org/nginx/changeset/5006/nginx.
Автор модуля отреагировал спустя всего лишь три дня после выхода
nginx 1.3.11 с этим изменением:
https://github.com/yaoweibin/nginx_tcp_proxy_module/commit/f1d5c627fc3a25c3fd36c0850ffb40470bee9d90
Однако, порт FreeBSD использует версию 0.26 этого модуля,
которой уже 10 месяцев:
https://github.com/yaoweibin/nginx_tcp_proxy_module/tags
Правильная последовательность действий видимо такая:
- попросить автора модуля (Weibin Yao ) выпустить
новую версию модуля;
- попросить ответственного за порт www/nginx-devel обновить порт.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Шейпер в Nginx не работает
On Tue, Mar 26, 2013 at 12:04:04AM +0400, sdfasdf asdfasdf wrote: > Да, у меня linux и sendfile включен. Отключил sendfile, выключил-включил > nginx и эффекта ноль. Так что sendfile тут видимо непричем. http://nginx.org/r/sendfile_max_chunk/ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Отключение буферизации ответов fastcgi
On Sat, Mar 23, 2013 at 03:07:58PM +0400, Постоваров Павел wrote: > Добрый день! > > Скажите, как можно сделать, чтобы ответы от fastcgi сервера > направлялись сразу клиенту, не дожидаясь разрыва соединения с > бекэндом? Пробовал ставить заголовок X-Accel-Buffering: no, как > сказано в документации - почему-то не помогает. Нашел инфу про > патч, который может помочь - > http://www.ruby-forum.com/topic/2387715#1017453 , это > единственный выход, или можно как-то решить проблему штатными > средствами? Отключить буферизацию ответов для FastCGI полностью в настоящий момент нельзя: http://mailman.nginx.org/pipermail/nginx-ru/2011-September/042870.html https://trac.nginx.org/nginx/ticket/159 Можно отключить буферизацию ответов на диск: http://nginx.org/r/fastcgi_max_temp_file_size/ru При включении "fastcgi_keep_conn on", побочным эффектом будет то, что nginx будет отправлять данные клиенту как только он получит FastCGI record целиком. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: map и limit req
On Wed, Mar 20, 2013 at 06:38:17PM -0400, sergey_s wrote:
> странные вилы, либо я что-то опять не понимаю, если прописано
>
> http {
> ..
> map $http_user_agent $var {
> default "";
> }
>
> limit_req_zone $var zone=limit:10m rate=10r/m;
>
> limit_req_zone $binary_remote_addr zone=testzone:10m rate=10r/m;
> limit_req zone=testzone burst=1;
> }
>
> server {
> ...
> limit_req zone=limit burst=1
> }
>
> зона testzone не срабатывает
> а если убрать строку
> limit_req zone=limit burst=1
> из блока server и прописать ее в http
>
> http {
> ...
> map $http_user_agent $var {
> default "";
> }
>
> limit_req_zone $var zone=limit:10m rate=10r/m;
> limit_req zone=limit burst=1
>
> limit_req_zone $binary_remote_addr zone=testzone:10m rate=10r/m;
> limit_req zone=testzone burst=1;
> ..
> }
>
> то начинает работать
> никто не сталкивался с такой странностью ?
Это не странность. Так устроено наследование директив в
nginx. limit_req на уровне server{} отменяет limit_req
на уровне http{}. Если вам нужно одновременно несколько
limit_req (поддерживается начиная с версии nginx 1.1.14),
их следует указывать на одном уровне.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: map и limit req
On Wed, Mar 20, 2013 at 02:46:20PM -0400, sergey_s wrote:
> Здравствуйте
> Друзья, растолкуйте пожалуйста такой кусок конфига, найден тут, в рассылке
>
> map $http_user_agent $bot_ua {
> ~bot bot;
> }
>
> limit_req_zone $bot_ua zone=bot:10m rate=1r/s;
> limit_req zone=bot burst=120;
>
> я понимаю как работает map, но хоть убей не понимаю как она связана тут с
> limit_req_zone ( дока тоже мне как-то свет не проливает на это )
> что в $http_user_agent на начальном этапе понятно, в $bot_ua - пустая
> строка
> далее, при нахождении в $http_user_agent подстроки bot, $bot_ua,
> присваивается значение bot
> правильно ?
> а далее, меня сбивает с толку
>
> limit_req_zone $bot_ua... ..
Переменная $bot_ua, значение которой (bot или пустая строка) зависит
от запроса, и является ключом в зоне "bot". Пустые значения (см. доку)
в зоне не учитываются, другими словами, ограничиваться будут только
боты.
> предположим нужная подстрока найдена, тогда переменная $bot_ua = bot
> в итоге получается:
>
> limit_req_zone bot zone=bot:10m rate=1r/s;
> limit_req zone=bot burst=120;
>
> правильно ?
> тогда как это вообще работает ?
>
> расскажите если не трудно
Смысл в том, что там по синтаксису переменная, а они в nginx зависят
от запроса.
> и вопрос связанный со всем этим
> нужно резать канал конкретным юзерагентам из определенного списка, ( либо
> через инклуд списка, либо просто перечисленыым в директиве map )
Не услышал тут вопроса. Пример с User-Agent есть в документации к
модулю map: http://nginx.org/ru/docs/http/ngx_http_map_module.html
В зависимости от того, что нужно конкретно, значениям User-Agent из
нужного списка в map могут соответствовать либо одно и то же непустое
значение (например, "1", как выше для ботов), либо разные (если их
ограничивать нужно по отдельности). Переменная задаёт ключ, по которому
ведётся учёт и производится ограничение. Запросы с одинаковым значением
ключа учитываются вместе. Я советую ещё раз вдумчиво прочитать
документацию на map и limit_{req,conn} на http://nginx.org.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: could not build the proxy_headers_hash
On Mon, Mar 11, 2013 at 05:24:38AM -0400, recived wrote:
> Здравствуйте. Не могу понять как решить проблему с ошибкой:
> nginx: [emerg] could not build the proxy_headers_hash, you should increase
> either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size:
> 64
> (nginx/1.1.19)
> Подскажите пожалуйста.
У вас дважды задана передача заголовка X-Forwarded-For на
проксируемый сервер, из-за этого и ошибка. (Сообщение об
ошибке возможно следует сделать более явным.)
>
> nginx.conf
>
> user www-data;
> worker_processes 4;
> pid /var/run/nginx.pid;
>
> events {
> worker_connections 768;
> # multi_accept on;
> }
>
> http {
> ##
> # Basic Settings
> ##
> sendfile on;
> tcp_nopush on;
> tcp_nodelay on;
> keepalive_timeout 65;
> types_hash_max_size 2048;
> # server_tokens off;
>
> include /etc/nginx/mime.types;
> default_type application/octet-stream;
> server_names_hash_bucket_size 64;
> server_names_hash_max_size 512;
> ##
> # Logging Settings
> ##
> log_format main '$host $remote_addr [$time_local] "$request" $status
> $body_bytes_sent "$http_referer" "$http_user_agent"';
> access_log /var/log/nginx/access.log;
> error_log /var/log/nginx/error.log;
>
> ##
> # Gzip Settings
> ##
>
> gzip on;
> gzip_disable "msie6";
>
> ##
> # Virtual Host Configs
> ##
> include /etc/nginx/conf.d/*.conf;
> include /etc/nginx/sites-enabled/*;
> }
>
>
> mysite.tpl
>
> server {
> listen 80;
> server_name mysite.tpl;
> access_log /var/www/mysite.tpl/logs/access_ng.log;
> error_log /var/wwwsite/mysite.tpl/logs/error_ng.log;
>
> location ~* \.(gif|png|css|zip|swf|ico|flv|jpg)$ {
> root /var/wwwsite/mysite.tpl/www/;
> #index index.html index.php;
> access_log off;
> expires max;
>
> gzip on;
> gzip_comp_level 5;
> gzip_vary on;
> gzip_static on;
> gzip_types text/css text/plain application/json application/x-javascript
> text/xml application/xml application/xml+rss text/javascript
> application/javascript text/x-js application/x-shockwave-flash;
> gzip_min_length 1024;
> gzip_disable "msie6";
> gzip_proxied any;
>
> }
> location / {
> proxy_pass http://192.168.4.250:82/;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header Host $host;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-for $remote_addr;
> proxy_set_header Host $host;
> proxy_connect_timeout 60;
> proxy_send_timeout 90;
> proxy_read_timeout 90;
> proxy_redirect off;
> }
> }
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: WebSocket проксирование
On Mon, Mar 11, 2013 at 03:10:24AM -0400, Modigar wrote:
> Необходимо спроксировать вебсокет через nginx по следующей схеме:
> Клиент -> HTTPS (WSS) -> nginx -> Local Server (WS).
> Т.е. если описать словами, то необходимо авторизироваться по SSL (в т.ч. и
> вебсокету) на nginx, а последний в свою очередь должен спроксировать
> вебсокет клиента на локальный вебсокет сервер без SSL.
> вопросы:
> 1. Возможно ли такое?
Да, почему нет.
> 2. Как это сделать?
Настроить HTTPS:
http://nginx.org/ru/docs/http/configuring_https_servers.html
Настроить проксирование WebSocket:
http://nginx.org/ru/docs/http/websocket.html
> 3. Если не возможно, то как быть с сертификатом для локального вебсокет
> сервера?
> 4. Как реализовать это в рамках одной машины (nginx, локальный вебсокет
> сервер и клиент на одной машине стоят), и при этом убедиться, что nginx
> проксирует?
http {
server {
listen 8000 ssl;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
location = /test {
proxy_pass http://echo.websocket.org/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
}
http://www.websocket.org/echo.html
Введите там адрес вашего настроенного сервера. Я с вышеприведенной
конфигурацией тестировал так: wss://127.0.0.1:8000/test.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не срабатывает limit_conn и limit_req?
On Mon, Mar 04, 2013 at 01:24:34PM +0400, denis wrote:
> 04.03.2013 11:24, Ruslan Ermilov пишет:
> > Обработка запросов в nginx происходит в разных фазах.
> > Директивы модуля ngx_http_rewrite_module (директива return в т.ч.)
> > срабатывают на более ранних фазах, чем модули ngx_http_limit_*.
> >
> > Описанное выше поведение ожидаемо.
> А как тогда быть? try_files?
Как вариант, можно определить отдельный URI для 302, который
будет представлен статическим файлом, и задать желаемое ограничение
там:
http {
limit_req_zone $server_name zone=lreq:10m rate=1r/m;
server {
server_name test;
location = /redir.php {
error_page 302 /302.html;
return http://ext-site.ru/content;
}
location = /302.html {
internal;
limit_req zone=lreq burst=1;
}
}
}
(Что положить внутрь файла 302.html - дело вкуса.)
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не срабатывает limit_conn и limit_req?
On Mon, Mar 04, 2013 at 02:57:49AM +0400, denis wrote:
> debian 6, nginx 1.2.7
> ...
> http {
>limit_conn_zone $binary_remote_addr zone=perip:10m;
>limit_conn_zone $server_name zone=perserver:10m;
>
>limit_req_zone $server_name zone=lreq:10m rate=1r/m;
>
>server {
> location = /redir.php {
>#limit_conn perserver 1; #(1)
>limit_req zone=lreq burst=1; #(2)
>#error_page 503 =302 /redir-503.php;
>error_page 503 =302 https://ext-site.ru/under_construction.html;
>
>limit_conn_log_level info;
>
>return http://ext-site.ru/content;
> }
> }}
>
> Сама секция работает, редирект всегда на ext-site.ru/content работает, а
> вот ограничение не срабатывает. Также с вариантом, когда
> раскомментирован (1) и закомментирован (2).
> Что не так?
Обработка запросов в nginx происходит в разных фазах.
Директивы модуля ngx_http_rewrite_module (директива return в т.ч.)
срабатывают на более ранних фазах, чем модули ngx_http_limit_*.
Описанное выше поведение ожидаемо.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: IPv6 forward proxy
On Thu, Feb 28, 2013 at 11:33:07AM +0200, Alexander Moskalenko wrote:
> Пытаюсь сделать forward proxy для IPv4 & IPv6.
>
> Для 4 все работает отлично, для 6 пытается ходить по 4.
> Если указать хост у которого только 6 адрес - не резолвит.
>
> В логе следующее:
> 2013/02/28 12:24:09 [debug] 5397#0: resolver qs:ipv6.l.google.com
> 2013/02/28 12:24:09 [error] 5397#0: *15 ipv6.l.google.com could not be
> resolved (3: Host not found), client: 2607:f878:3:314::42b3:e975,
> server: , request: "GET http://ipv6.google.com/ HTTP/1.0", host:
> "ipv6.google.com"
>
> 2013/02/28 12:23:09 [debug] 5397#0: resolve: "www.google.com"
> 2013/02/28 12:23:09 [debug] 5397#0: resolve cached
> 2013/02/28 12:23:09 [debug] 5397#0: malloc: 08D883E8:20
> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to 74.125.239.17
> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to 74.125.239.16
> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to 74.125.239.18
> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to 74.125.239.19
> 2013/02/28 12:23:09 [debug] 5397#0: *13 name was resolved to 74.125.239.20
> 2013/02/28 12:23:09 [debug] 5397#0: resolve name done: 0
> 2013/02/28 12:23:09 [debug] 5397#0: resolver expire
> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, try: 5
> 2013/02/28 12:23:09 [debug] 5397#0: *13 get rr peer, current: 0 -4
> 2013/02/28 12:23:09 [debug] 5397#0: *13 socket 11
> 2013/02/28 12:23:09 [debug] 5397#0: *13 epoll add connection: fd:11
> ev:8005
> 2013/02/28 12:23:09 [debug] 5397#0: *13 connect to 74.125.239.17:80, fd:11 #14
> 2013/02/28 12:23:09 [debug] 5397#0: *13 http upstream connect: -2
>
> В обоих случаях коннект идет на сервер:
>
> server {
> listen [::]:8080 ipv6only=on default bind;
> resolver [2001:4860:4860::];
>
> location / {
> proxy_pass $scheme://$http_host$uri$is_args$args;
> proxy_bind $server_addr;
> }
> }
>
>
> Это баг или фича?
В настоящий момент резолвер в nginx не умеет резолвить IPv6-адреса.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx-1.3.13
On Tue, Feb 19, 2013 at 08:02:06PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > *) Добавление: поддержка проксирования WebSocket-соединений. > >Спасибо Apcera и CloudBees за спонсирование разработки. > > Посмотрел комит http://trac.nginx.org/nginx/changeset/5073/nginx , но > не понял всю схему того, как оно работает. Обновляется соединение > между nginx и бэкендом что ли? Пощупать как это работает можно через http://www.websocket.org/echo.html, натравив его на настроенный согласно упомянутому Максимом примеру конфигурации nginx, проксирующий на echo.websocket.org. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
