From universite на ukr.net  Sun Apr  1 22:11:59 2018
From: universite на ukr.net (Vladislav Prodan)
Date: Mon, 02 Apr 2018 01:11:59 +0300
Subject: =?UTF-8?B?0JrQsNC6INC/0YDQuNC90Y/RgtGMINC/0YDQvtC60YHQuNGA0L7QstCw0L3QvdGL?=
 =?UTF-8?B?0LkgaHR0cHMg0YEg0L3QtdGB0LrQvtC70YzQutC40YUg0LjRgdGC0L7Rh9C9?=
 =?UTF-8?B?0LjQutC+0LIsINCyINGC0L7QvCDRh9C40YHQu9C1INGBIENsb3VkRmxhcmUg?=
 =?UTF-8?B?Pw==?=
Message-ID: <1522620354.361900096.krzplbj9@frv37.fwdcdn.com>


Здравствуйте.

Subj.
nginx/1.12.1

На основном сервере соорудил такой конфиг:

server {
	server_name .domain.com ;
	...
	listen 443 ssl;
	listen 444 ssl proxy_protocol;
	...
	# Real IP from CloudFlare
	include /etc/nginx/cloudflare.conf;
        real_ip_header CF-Connecting-IP;
	...
	set_real_ip_from 1.1.1.1/32;
	real_ip_header proxy_protocol;
	...

}

Проблема в том, что у CloudFlare одно значение real_ip_header, а для обычной tcp прокси (haproxy) - другое значение. 

Попытался такой вставить блок,
if ($remote_addr = 1.1.1.1) {
     set_real_ip_from 1.1.1.1/32;
     real_ip_header proxy_protocol; 
}
Но тут можно использовать только редиректы и real_ip_header нельзя переназначить...

Подскажите решение.

--
 Vladislav V. Prodan
 System & Network Administrator
 support.od.ua

From chipitsine на gmail.com  Mon Apr  2 06:39:52 2018
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 2 Apr 2018 11:39:52 +0500
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQvdGP0YLRjCDQv9GA0L7QutGB0LjRgNC+0LLQsNC9?=
 =?UTF-8?B?0L3Ri9C5IGh0dHBzINGBINC90LXRgdC60L7Qu9GM0LrQuNGFINC40YHRgtC+?=
 =?UTF-8?B?0YfQvdC40LrQvtCyLCDQsiDRgtC+0Lwg0YfQuNGB0LvQtSDRgSBDbG91ZEZs?=
 =?UTF-8?B?YXJlID8=?=
In-Reply-To: <1522620354.361900096.krzplbj9@frv37.fwdcdn.com>
References: <1522620354.361900096.krzplbj9@frv37.fwdcdn.com>
Message-ID: <CAFHpkQE55xae884XmizSYwmS+CiWG7+wmrPirZBDzfvdTcXOnQ@mail.gmail.com>

мы вот так извлекаем

map $http_cf_connecting_ip $x_real_ip {
'' $remote_addr;
default $http_cf_connecting_ip;
}


2 апреля 2018 г., 3:11 пользователь Vladislav Prodan <universite на ukr.net>
написал:

>
> Здравствуйте.
>
> Subj.
> nginx/1.12.1
>
> На основном сервере соорудил такой конфиг:
>
> server {
>         server_name .domain.com ;
>         ...
>         listen 443 ssl;
>         listen 444 ssl proxy_protocol;
>         ...
>         # Real IP from CloudFlare
>         include /etc/nginx/cloudflare.conf;
>         real_ip_header CF-Connecting-IP;
>         ...
>         set_real_ip_from 1.1.1.1/32;
>         real_ip_header proxy_protocol;
>         ...
>
> }
>
> Проблема в том, что у CloudFlare одно значение real_ip_header, а для
> обычной tcp прокси (haproxy) - другое значение.
>
> Попытался такой вставить блок,
> if ($remote_addr = 1.1.1.1) {
>      set_real_ip_from 1.1.1.1/32;
>      real_ip_header proxy_protocol;
> }
> Но тут можно использовать только редиректы и real_ip_header нельзя
> переназначить...
>
> Подскажите решение.
>
> --
>  Vladislav V. Prodan
>  System & Network Administrator
>  support.od.ua
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180402/aaec2fc0/attachment.html>

From gmm на csdoc.com  Mon Apr  2 08:12:39 2018
From: gmm на csdoc.com (Gena Makhomed)
Date: Mon, 2 Apr 2018 11:12:39 +0300
Subject: contrib/vim
In-Reply-To: <20171226182725.GH34136@mdounin.ru>
References: <5d43d2bd-8a0f-3025-8431-a8b718ca44f8@csdoc.com>
 <79712f9d-af6a-bfe9-a7a0-bffe9b7dbac4@nginx.com>
 <7e29fa3a-1787-c31d-09c9-9473fb508481@csdoc.com>
 <20171011134247.GV75166@mdounin.ru>
 <2d167819-f789-3387-8cf6-680210c1f25c@csdoc.com>
 <20171226182725.GH34136@mdounin.ru>
Message-ID: <bead8214-ce5a-8c77-fe39-a9a1664abfc0@csdoc.com>

On 26.12.2017 20:27, Maxim Dounin wrote:

>>>> В tar.gz дистрибутиве есть каталог contrib/vim - можно ли сделать так,
>>>> чтобы содержимое этого каталога при установке пакета ложилось в каталог
>>>> /usr/share/vim/vimfiles ? Это было бы очень удобно для пользователей vim
>>>> - тогда vim будет автоматически похватывать эти конфигурационные файлы.

>>> Содержимое contrib/ ни коим образом не поддерживается
>>> разработчиками, и ставить это в рамках пакетов, IMHO, было бы странно.

Почему странно? Ведь редактировать конфиги nginx с включенной подсветкой
синтаксиса гораздо удобнее, чем без нее. Тем более, что у этих файлов
есть поддержка by community - для open source проекта это нормально.

>> Странно, что не поддерживается, ведь файл contrib/vim/syntax/nginx.vim
>> можно автоматически проверять на актуальность небольшим скриптом,
>> который сканирует исходники nginx и показывает, какие директивы
>> отсутствуют в файле nginx.vim, такой скрипт пишется за 15 минут.
> 
> Это, скажем так, не совсем соответствует действительности.  Потому
> что директивы стандартных модулей - не единственное содержимое
> contrib/vim/, и уж тем более contrib/.

Хорошо. Добавил в скрипт https://github.com/makhomed/nginx-vim
также проверку актуальности и для 3rd party module directives.
Такой скрипт пишется не за 15 минут, а за несколько дней.

Кстати, держать в contrib файл contrib/geo2nginx.pl не имеет смысла,
потому что MaxMind уже полностью прекратили поддержку базы GeoLite:
https://dev.maxmind.com/geoip/legacy/geolite/

> Но даже если бы это было так - это не отменяет того факта, что
> содержимое contrib/ не поддерживается разработчиками. Никто,
> впрочем, не мешает присылать нам патчи, мы их без проблем
> принимаем.

В таком случае - кому какая разница, кто именно поддерживает содержимое
каталога contrib/vim в актуальном состоянии, я или сотрудники Nginx Inc?
Тем более, что это не код, а всего лишь подсветка синтаксиса для конфига

>> Если ставить содержимое contrib/vim в /usr/share/vim/vimfiles/
>> с помощью официального пакета из репозитория nginx нельзя,
>> то каким тогда способом нам актуализировать конфиги vim?
> 
> Как по мне, наиболее правильным решением было бы добавить
> соответствующий syntax-файл в дистрибутив собственно vim'а, и там
> его периодически обновлять.

Пакет с vim обновляется в дистрибутивах очень редко, например, в среднем
раз в 5 лет, если говорить про дистрибутив CentOS. Каталог contrib/vim
обновляется в среднем раз в месяц, а бывает что и несколько раз в месяц.

-- 
Best regards,
  Gena


From nordicdyno на yandex.ru  Tue Apr  3 14:56:03 2018
From: nordicdyno на yandex.ru (Orlovsky Alexander)
Date: Tue, 03 Apr 2018 17:56:03 +0300
Subject: =?UTF-8?B?0J/QtdGA0LXQvNC10L3QvdCw0Y8g0LIgbG9nX2Zvcm1hdA==?=
Message-ID: <1797571522767363@web42o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180403/d557e3da/attachment.html>

From mdounin на mdounin.ru  Tue Apr  3 14:56:19 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 3 Apr 2018 17:56:19 +0300
Subject: nginx-1.13.11
Message-ID: <20180403145619.GF77253@mdounin.ru>

Изменения в nginx 1.13.11                                         03.04.2018

    *) Добавление: параметр proxy_protocol директивы listen теперь
       поддерживает протокол PROXY версии 2.

    *) Исправление: nginx не собирался с OpenSSL 1.1.1 статически на Linux.

    *) Исправление: в параметрах http_404, http_500 и им подобных директивы
       proxy_next_upstream.


-- 
Maxim Dounin
http://nginx.org/

From artem.povaluhin на gmail.com  Tue Apr  3 15:00:37 2018
From: artem.povaluhin на gmail.com (Artem S. Povalyukhin)
Date: Tue, 3 Apr 2018 18:00:37 +0300
Subject: [njs] read request body
Message-ID: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>

Добрый день!

Хотел узнать планируется ли добавить возможность чтения тела запроса в
модуле ngx_http_js_module?
Пока приходится городить костыли через ngx_stream_js_module.

задача: праверить на валидность входящий json

wbr,

Artem


From xeioex на nginx.com  Tue Apr  3 15:17:08 2018
From: xeioex на nginx.com (Dmitry Volyntsev)
Date: Tue, 3 Apr 2018 18:17:08 +0300
Subject: [njs] read request body
In-Reply-To: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>
References: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>
Message-ID: <f70bf63b-d5c4-fbae-25bf-bf0f1f7a6a51@nginx.com>



On 03.04.2018 18:00, Artem S. Povalyukhin wrote:
> Добрый день!
> 
> Хотел узнать планируется ли добавить возможность чтения тела запроса в
> модуле ngx_http_js_module?
> Пока приходится городить костыли через ngx_stream_js_module.
> 
> задача: праверить на валидность входящий json
> 

Добрый день,

Тело запроса доступно в виде переменной: req.variables.request_body.


From artem.povaluhin на gmail.com  Tue Apr  3 15:26:57 2018
From: artem.povaluhin на gmail.com (Artem S. Povalyukhin)
Date: Tue, 3 Apr 2018 18:26:57 +0300
Subject: [njs] read request body
In-Reply-To: <f70bf63b-d5c4-fbae-25bf-bf0f1f7a6a51@nginx.com>
References: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>
 <f70bf63b-d5c4-fbae-25bf-bf0f1f7a6a51@nginx.com>
Message-ID: <c682fb05-1d61-f577-8389-f1e140d7d008@gmail.com>


On 04/03/2018 06:17 PM, Dmitry Volyntsev wrote:
>
>
> On 03.04.2018 18:00, Artem S. Povalyukhin wrote:
>> Добрый день!
>>
>> Хотел узнать планируется ли добавить возможность чтения тела запроса в
>> модуле ngx_http_js_module?
>> Пока приходится городить костыли через ngx_stream_js_module.
>>
>> задача: праверить на валидность входящий json
>>
>
> Добрый день,
>
> Тело запроса доступно в виде переменной: req.variables.request_body.
>
Огромное спасибо.
Не совсем очевидно это.
Может быть стоит сделать shortcut req.body -> req.variables.request_body ?

wbr,
Artem

From xeioex на nginx.com  Tue Apr  3 20:08:55 2018
From: xeioex на nginx.com (Dmitry Volyntsev)
Date: Tue, 3 Apr 2018 23:08:55 +0300
Subject: [njs] read request body
In-Reply-To: <c682fb05-1d61-f577-8389-f1e140d7d008@gmail.com>
References: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>
 <f70bf63b-d5c4-fbae-25bf-bf0f1f7a6a51@nginx.com>
 <c682fb05-1d61-f577-8389-f1e140d7d008@gmail.com>
Message-ID: <D4B770B1-6AD4-4E65-B489-5CAA9453AEAB@nginx.com>



> On 3 Apr 2018, at 18:26, Artem S. Povalyukhin <artem.povaluhin на gmail.com> wrote:
> 
> 
> On 04/03/2018 06:17 PM, Dmitry Volyntsev wrote:
>> 
>> 
>> On 03.04.2018 18:00, Artem S. Povalyukhin wrote:
>>> Добрый день!
>>> 
>>> Хотел узнать планируется ли добавить возможность чтения тела запроса в
>>> модуле ngx_http_js_module?
>>> Пока приходится городить костыли через ngx_stream_js_module.
>>> 
>>> задача: праверить на валидность входящий json
>>> 
>> 
>> Добрый день,
>> 
>> Тело запроса доступно в виде переменной: req.variables.request_body.
>> 
> Огромное спасибо.
> Не совсем очевидно это.
> Может быть стоит сделать shortcut req.body -> req.variables.request_body ?

Да, есть планы это добавить в ближайших релизах.

> 
> wbr,
> Artem


From nginx-forum на forum.nginx.org  Sun Apr  8 07:19:09 2018
From: nginx-forum на forum.nginx.org (guteelefant)
Date: Sun, 08 Apr 2018 03:19:09 -0400
Subject: =?UTF-8?B?0JLRi9Cx0L7RgCDQutC+0L3RhNC40LPRg9GA0LDRhtC40LggVlBTINGB0LXRgNCy?=
 =?UTF-8?B?0LXRgNCw?=
Message-ID: <e5ff1875d0720e8efc910d2165629dde.NginxMailingListRussian@forum.nginx.org>

Есть большие проблемы с загруженностью сервера nginx.

Развернута следующая конфигурация:
1. Основной сервер, который распределяет нагрузку между 4 серверами.
nginx + php-fpm + mariadb. 3 ядра, 3 гигабайта ОЗУ
2. Сервер для раздачи результатов php и картинок
nginx + php-fpm + mariadb. 1 ядро, 1 гигабайт ОЗУ
3. Сервер для раздачи результатов php и картинок
nginx + php-fpm + mariadb. 1 ядро, 1 гигабайт ОЗУ
4. Сервер для раздачи исключительно картинок
nginx. 1 ядро, 1 гигабайт ОЗУ
5. Сервер для раздачи исключительно картинок
nginx. 1 ядро, 1 гигабайт ОЗУ

На основном nginx распределение такое:
по php:
upstream http_php {
        server Сервер2 weight=2 max_fails=2 fail_timeout=2s;
        server Сервер3  weight=2 max_fails=2 fail_timeout=2s;
        server localhost:81 weight=1 max_fails=2 fail_timeout=2s;
}

по картинкам:
        server Сервер4        weight=4 max_fails=2 fail_timeout=2s;
        server Сервер5        weight=4 max_fails=2 fail_timeout=2s;
        server Сервер2         weight=1 max_fails=2 fail_timeout=2s;
        server Сервер3          weight=1 max_fails=2 fail_timeout=2s;
}

То есть динамический контент отдается серверам 2 и 3 с большим приоритетом,
с меньшим - обрабатывает сам основной сервер

Статический контент отдается серверам 4 и 5 с большим приоритетом, с меньшим
серверам 2 и 3

Проблемы возникают в праздники, когда большой наплыв посетителей.
Тормозит основной сервер. Даже в терминальном окне команды вводятся с
замедлением.
Второстепенные сервера не сильно нагружены почему-то.

Модуль nginx_status_page на основном сервере показывает около 6000
соединений.

Вопрос: в какую сторону расширяться?
Увеличивать мощность основного сервера или увеличивать количество
второстепенных серверов?

Спасибо.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279343,279343#msg-279343


From gmm на csdoc.com  Sun Apr  8 09:10:13 2018
From: gmm на csdoc.com (Gena Makhomed)
Date: Sun, 8 Apr 2018 12:10:13 +0300
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAg0LrQvtC90YTQuNCz0YPRgNCw0YbQuNC4IFZQUyDRgdC1?=
 =?UTF-8?B?0YDQstC10YDQsA==?=
In-Reply-To: <e5ff1875d0720e8efc910d2165629dde.NginxMailingListRussian@forum.nginx.org>
References: <e5ff1875d0720e8efc910d2165629dde.NginxMailingListRussian@forum.nginx.org>
Message-ID: <ffebe411-3377-7b53-f9c5-eda50b3de0e4@csdoc.com>

On 08.04.2018 10:19, guteelefant wrote:

> Развернута следующая конфигурация:
> 1. Основной сервер, который распределяет нагрузку между 4 серверами.
> nginx + php-fpm + mariadb. 3 ядра, 3 гигабайта ОЗУ

[...]

> Проблемы возникают в праздники, когда большой наплыв посетителей.
> Тормозит основной сервер. Даже в терминальном окне команды вводятся с
> замедлением.
> Второстепенные сервера не сильно нагружены почему-то.

Какого именно ресурса не хватает на основном сервере - памяти,
мощности процессора или производительности дисковой подсистемы?

> Модуль nginx_status_page на основном сервере показывает около 6000
> соединений.
> 
> Вопрос: в какую сторону расширяться?
> Увеличивать мощность основного сервера или увеличивать количество
> второстепенных серверов?

Следует убедиться что на основном сервере достаточно памяти и он
не уходит в swapping. mariadb может использовать очень много памяти.

Лучше всего сделать отдельный nginx frontend, который будет
заниматься только балансировкой запросов между backend`ами.

Имеет смысл на основном сервере поставить в конфиге

     # If you want nginx to don't touch disk, use
     # This will still allow in-memory buffering and wouldn't touch disk.
     proxy_max_temp_file_size 0;

в результате nginx frontend не будет тормозить на дисковых операциях.

Также имеет на nginx frontend включить ssl_session_cache,
и прописать настройки

     ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1 TLSv1;
     ssl_prefer_server_ciphers on;
     # OpenSSL, ssl_ciphers и nginx: прокачиваем на 100%
     # https://habrahabr.ru/post/325230/
     ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4;

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Sun Apr  8 09:31:34 2018
From: nginx-forum на forum.nginx.org (guteelefant)
Date: Sun, 08 Apr 2018 05:31:34 -0400
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAg0LrQvtC90YTQuNCz0YPRgNCw0YbQuNC4IFZQUyDRgdC1?=
 =?UTF-8?B?0YDQstC10YDQsA==?=
In-Reply-To: <ffebe411-3377-7b53-f9c5-eda50b3de0e4@csdoc.com>
References: <ffebe411-3377-7b53-f9c5-eda50b3de0e4@csdoc.com>
Message-ID: <009459d6d76b9aa60b7b347920b49e63.NginxMailingListRussian@forum.nginx.org>

Спасибо за ответы!

Какого именно ресурса не хватает на основном сервере - памяти,
мощности процессора или производительности дисковой подсистемы?

Если смотреть top, то не видно недостатка ресурсов.
процессы nginx забирают около 30% CPU, но так как ядер три - это не должно
быть много.
Память свободная так же отражается.

Как посмотреть загруженность дисковой подсистемы?
iotop показывает:
 Total DISK WRITE : 2 Mb/sec
Не думаю, что это много.

Возникли мысли, что не хватает толщины канала (сейчас 100 Мб/с)

proxy_max_temp_file_size 0;
Это отключит проксирование с использованием диска?

Что касается SSL - пока все идет только через http - с ним бы разобраться.

Спасибо!

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279343,279345#msg-279345


From gmm на csdoc.com  Sun Apr  8 10:02:14 2018
From: gmm на csdoc.com (Gena Makhomed)
Date: Sun, 8 Apr 2018 13:02:14 +0300
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAg0LrQvtC90YTQuNCz0YPRgNCw0YbQuNC4IFZQUyDRgdC1?=
 =?UTF-8?B?0YDQstC10YDQsA==?=
In-Reply-To: <009459d6d76b9aa60b7b347920b49e63.NginxMailingListRussian@forum.nginx.org>
References: <ffebe411-3377-7b53-f9c5-eda50b3de0e4@csdoc.com>
 <009459d6d76b9aa60b7b347920b49e63.NginxMailingListRussian@forum.nginx.org>
Message-ID: <ae290c9e-8909-8fc5-214d-5c7626570161@csdoc.com>

On 08.04.2018 12:31, guteelefant wrote:

> Как посмотреть загруженность дисковой подсистемы?

atop
iostat -mx 1

> Возникли мысли, что не хватает толщины канала (сейчас 100 Мб/с)

Это можно проверить, например, с помощью утилиты nload

Вполне может быть. Тогда может помочь использование Cloudflare
в качестве CDN для раздачи статики или переключение на гигабитную сеть.

> proxy_max_temp_file_size 0;
> Это отключит проксирование с использованием диска?

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size

Это отключит использование диска при проксировании ответов.
В результате nginx не будет блокироваться на дисковых операциях.

Но эта настройка имеет смысл только на балансировщике nginx frontend,
на nginx backend наоборот, имеет смысл оставить значение по умолчанию.

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Sun Apr  8 10:10:25 2018
From: nginx-forum на forum.nginx.org (guteelefant)
Date: Sun, 08 Apr 2018 06:10:25 -0400
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAg0LrQvtC90YTQuNCz0YPRgNCw0YbQuNC4IFZQUyDRgdC1?=
 =?UTF-8?B?0YDQstC10YDQsA==?=
In-Reply-To: <ae290c9e-8909-8fc5-214d-5c7626570161@csdoc.com>
References: <ae290c9e-8909-8fc5-214d-5c7626570161@csdoc.com>
Message-ID: <41a71571998cf52c4533f58cc792c538.NginxMailingListRussian@forum.nginx.org>

Спасибо за помощь!
Будем работать и тестировать.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279343,279347#msg-279347


From nginx-forum на forum.nginx.org  Sun Apr  8 23:50:42 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Sun, 08 Apr 2018 19:50:42 -0400
Subject: =?UTF-8?B?0J3QtdC60L7RgNGA0LXQutGC0L3Ri9C5INC+0YLQstC10YIg0L/RgNC4INC40YE=?=
 =?UTF-8?B?0L/QvtC70YzQt9C+0LLQsNC90LjQuCBmYXN0Y2dpIGNhY2hlIGJhY2tncm91?=
 =?UTF-8?B?bmQgdXBkYXRlIG9u?=
Message-ID: <43eebb6cc6452e58fc719bc72281f66c.NginxMailingListRussian@forum.nginx.org>

Добрый вечер.

При использовании fastcgi_cache_background_update наблюдаю странное
поведение nginx.
Адрес недоступен, в кэше лежит ответ со статусом 404.

По истечении времени жизни кэша вместо обращения к апстриму и сохранения
ответа со статусом 404 в кэш и отдачи его клиенту выдаётся ответ нулевой
длины со статусом 200, который попадает в кэш.

0.0.0.0 - - [09/Apr/2018:01:31:32 +0300] "GET /missing/ HTTP/1.1" 404 3464
"-" "Mozilla/5.0"
0.0.0.0 - - [09/Apr/2018:01:33:32 +0300] "GET /missing/ HTTP/1.1" 404 3464
"-" "Mozilla/5.0"
0.0.0.0 - - [09/Apr/2018:01:35:33 +0300] "GET /missing/ HTTP/1.1" 404 3464
"-" "Mozilla/5.0"
0.0.0.0 - - [09/Apr/2018:01:37:32 +0300] "GET /missing/ HTTP/1.1" 404 3464
"-" "Mozilla/5.0"
0.0.0.0 - - [09/Apr/2018:01:37:52 +0300] "GET /missing/ HTTP/1.1" 200 0 "-"
"Mozilla/5.0"
0.0.0.0 - - [09/Apr/2018:01:41:32 +0300] "GET /missing/ HTTP/1.1" 200 0 "-"
"Mozilla/5.0"
0.0.0.0 - - [09/Apr/2018:01:43:32 +0300] "GET /missing/ HTTP/1.1" 200 0 "-"
"Mozilla/5.0"
0.0.0.0 - - [09/Apr/2018:01:45:32 +0300] "GET /missing/ HTTP/1.1" 200 0 "-"
"Mozilla/5.0"
0.0.0.0 - - [09/Apr/2018:01:47:33 +0300] "GET /missing/ HTTP/1.1" 200 0 "-"
"Mozilla/5.0"

Стоит отключить fastcgi_cache_background_update — проблема исчезает.

Выдержка из конфигурации.
fastcgi_cache_lock              on;
fastcgi_cache_lock_age          15s;
fastcgi_cache_use_stale         error timeout updating http_500;
fastcgi_cache_background_update on;
…
fastcgi_cache_valid             404 410 5m;

----------
Ubuntu 16.04.4 LTS

nginx version: nginx/1.13.9
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong
-Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2'
--with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now
-fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
--pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit
--with-http_ssl_module --with-http_stub_status_module
--with-http_realip_module --with-http_auth_request_module
--with-http_v2_module --with-http_dav_module --with-http_slice_module
--with-threads --with-http_addition_module --with-http_geoip_module=dynamic
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_image_filter_module=dynamic --with-http_sub_module
--with-http_xslt_module=dynamic --with-stream=dynamic
--with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279350,279350#msg-279350


From nginx-forum на forum.nginx.org  Mon Apr  9 00:54:12 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Sun, 08 Apr 2018 20:54:12 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <43eebb6cc6452e58fc719bc72281f66c.NginxMailingListRussian@forum.nginx.org>
References: <43eebb6cc6452e58fc719bc72281f66c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3ed255a146f77399e82a318fb9d6cbc8.NginxMailingListRussian@forum.nginx.org>

Что характерно, при этом до апстрима запрос вообще не доходит.
Включил логирование в приложении: смену статуса в логе nginx вижу, генерации
ответа fastcgi-приложением не происходит.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279350,279351#msg-279351


From mdounin на mdounin.ru  Mon Apr  9 14:36:18 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 9 Apr 2018 17:36:18 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <3ed255a146f77399e82a318fb9d6cbc8.NginxMailingListRussian@forum.nginx.org>
References: <43eebb6cc6452e58fc719bc72281f66c.NginxMailingListRussian@forum.nginx.org>
 <3ed255a146f77399e82a318fb9d6cbc8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180409143618.GB77253@mdounin.ru>

Hello!

On Sun, Apr 08, 2018 at 08:54:12PM -0400, gz wrote:

> Что характерно, при этом до апстрима запрос вообще не доходит.
> Включил логирование в приложении: смену статуса в логе nginx вижу, генерации
> ответа fastcgi-приложением не происходит.

Попробуйте включить debug log в nginx'е, возможно происходящее 
станет понятнее.  Подробнее тут:

http://nginx.org/ru/docs/debugging_log.html

Кроме того, имеет смысл показать полную минимальную конфигурацию, 
с которой воспроизводится проблема.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Mon Apr  9 17:43:33 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 09 Apr 2018 13:43:33 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <20180409143618.GB77253@mdounin.ru>
References: <20180409143618.GB77253@mdounin.ru>
Message-ID: <2b80030a70aa44645e07ffbc34e322c7.NginxMailingListRussian@forum.nginx.org>

> Попробуйте включить debug log в nginx'е, возможно происходящее 
станет понятнее.

Понятнее не стало.

-------------------------------------------------
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 using configuration "/"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http cl:-1 max:104857600
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 rewrite phase: 3
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 post rewrite phase: 4
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 5
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 6
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 7
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 8
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 9
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 10
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 post access phase: 11
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 12
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 try files handler
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 trying to use file:
"@backend" "/var/www/site/www на backend"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 test location: "@backend"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 using location: @backend
"/missing/?"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 rewrite phase: 3
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script value:
"_ind.html"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script set $handler
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script complex value
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy:
"_action="
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var:
"/missing/"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "&"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script set
$querystring
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 post rewrite phase: 4
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 5
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 6
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 7
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 8
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 9
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 10
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 post access phase: 11
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 12
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 13
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http init upstream, client
timer: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 epoll add event: fd:51
op:3 ev:80002005
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map started
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "http"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "GET"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var:
"/missing/"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http cache key:
"http|GET||||/missing/"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map started
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var:
"/missing/"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map started
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map: "||" ""
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: ""
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map: "/missing/" ""
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: ""
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup:
00005594C08CB230
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache exists: 0
e:1
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 cache file:
"/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup:
00005594C08CB288
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache fd: 52
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 read: 52,
00005594C08CB308, 475, 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http upstream cache: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 posix_memalign:
00005594C08CB660:4096 @16
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record byte:
01
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record byte:
06
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record byte:
00
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record byte:
01
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record byte:
00
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record byte:
4A
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record byte:
06
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record byte:
00
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record
length: 74
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header:
"Content-Type: text/html; charset=UTF-8"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header:
"Status: 200"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header:
"Content-Length: 0"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 1
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header done
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache send:
/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 HTTP/1.1 200
Server: nginx
Date: Mon, 09 Apr 2018 15:21:23 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Expires: Mon, 09 Apr 2018 16:21:23 GMT
Cache-Control: max-age=3600
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

2018/04/09 18:21:23 [debug] 29576#29576: *3395329 write new buf t:1 f:0
00005594C08CB8E0, pos 00005594C08CB8E0, size: 354 file: 0, size: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http write filter: l:0 f:0
s:354
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http output filter
"/missing/?"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http copy filter:
"/missing/?"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http postpone filter
"/missing/?" 00007FFF2E0EA068
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 write old buf t:1 f:0
00005594C08CB8E0, pos 00005594C08CB8E0, size: 354 file: 0, size: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 write new buf t:0 f:0
0000000000000000, pos 0000000000000000, size: 0 file: 475, size: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http write filter: l:1 f:0
s:354
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http write filter limit 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 writev: 354 of 354
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http write filter
0000000000000000
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http copy filter: 0
"/missing/?"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http finalize request: 0,
"/missing/?" a:1, c:3
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http request count:3
blk:0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http finalize request: -4,
"/missing/?" a:1, c:2
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http request count:2
blk:0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http finalize request: -4,
"/missing/?" a:1, c:1
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 set http keepalive
handler
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http close request
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http log handler
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 run cleanup:
00005594C08CB288
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 file cleanup: fd:52
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 run cleanup:
00005594C08CB230
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache cleanup
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache free, fd:
52
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 free: 00005594BE9D5CA0,
unused: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 free: 00005594BE9D6CB0,
unused: 3
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 free: 00005594C08CA650,
unused: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 free: 00005594C08CB660,
unused: 2715
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 free: 00005594BE9D5890
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 hc free: 0000000000000000
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 hc busy: 0000000000000000
0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 tcp_nodelay
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 reusable connection: 1
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 event timer add: 51:
65000:1523287348578
-------------------------------------------------

> Кроме того, имеет смысл показать полную минимальную конфигурацию, с
которой воспроизводится проблема.

Попробую, конечно.
Пока надеюсь выяснить причину на боевой конфигурации.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279357#msg-279357


From mdounin на mdounin.ru  Mon Apr  9 18:08:02 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 9 Apr 2018 21:08:02 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <2b80030a70aa44645e07ffbc34e322c7.NginxMailingListRussian@forum.nginx.org>
References: <20180409143618.GB77253@mdounin.ru>
 <2b80030a70aa44645e07ffbc34e322c7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180409180802.GE77253@mdounin.ru>

Hello!

On Mon, Apr 09, 2018 at 01:43:33PM -0400, gz wrote:

> > Попробуйте включить debug log в nginx'е, возможно происходящее 
> станет понятнее.
> 
> Понятнее не стало.

[...]

> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache exists: 0 e:1
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 cache file: "/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49"
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup: 00005594C08CB288
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache fd: 52
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 read: 52, 00005594C08CB308, 475, 0

[...]

> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record length: 74
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Content-Type: text/html; charset=UTF-8"
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Status: 200"
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Content-Length: 0"
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 1
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header done
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache send: /var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49
> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 HTTP/1.1 200

[...]

Судя по приведённому debug log'у, в кэше лежит валидный ответ 
бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся 
клиенту.

Очевидно, что ответ этот nginx не сам придумал, а получил от 
бэкенда.  Почему бэкенд прислал именно такой ответ - надо смотреть 
в debug log'е в тот момент, когда это произошло.

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Mon Apr  9 18:42:53 2018
From: gmm на csdoc.com (Gena Makhomed)
Date: Mon, 9 Apr 2018 21:42:53 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <20180409180802.GE77253@mdounin.ru>
References: <20180409143618.GB77253@mdounin.ru>
 <2b80030a70aa44645e07ffbc34e322c7.NginxMailingListRussian@forum.nginx.org>
 <20180409180802.GE77253@mdounin.ru>
Message-ID: <863c960f-110d-594a-66b7-22ff113e4927@csdoc.com>

On 09.04.2018 21:08, Maxim Dounin wrote:

>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache exists: 0 e:1
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 cache file: "/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49"
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup: 00005594C08CB288
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache fd: 52
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 read: 52, 00005594C08CB308, 475, 0
> 
> [...]
> 
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record length: 74
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Content-Type: text/html; charset=UTF-8"
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Status: 200"
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Content-Length: 0"
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 1
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header done
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache send: /var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49
>> 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 HTTP/1.1 200
> 
> [...]
> 
> Судя по приведённому debug log'у, в кэше лежит валидный ответ
> бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся
> клиенту.
> 
> Очевидно, что ответ этот nginx не сам придумал, а получил от
> бэкенда.  Почему бэкенд прислал именно такой ответ - надо смотреть
> в debug log'е в тот момент, когда это произошло.

С бэкендом все нормально. Это глюк на стороне nginx.

Такой глюк происходит в том случае, когда из интернета на сайт
отправляется запрос HEAD - есть очень много роботов, которые сначала
отправляют HEAD запрос, и потом только делают нормальный GET запрос.

Причина в том, что в документации для директивы fastcgi_cache_key
указано некорректное с точки зрения протокола HTTP значение
localhost:9000$request_uri - так оно нормально работать не будет.

Даже если добавить туда $scheme и $host, например, так:
fastcgi_cache_key "$scheme://$host$request_uri";
- этот глюк с пустыми ответами все равно останется.

Пока что существует только один workaround:
добавить $request_method в fastcgi_cache_key
Например, вот так:

fastcgi_cache_key "$request_method $scheme://$host$request_uri";

Подозреваю что сейчас в интернете есть очень много сайтов, которые
используют модуль fastcgi, на которых включено кеширование в nginx
и значение директивы fastcgi_cache_key скопировано из документации.

Идеальным вариантом решения проблемы было бы добавление директивы
fastcgi_cache_convert_head со значением "on" по умолчанию,
по аналогии с имеющейся директивой proxy_cache_convert_head.

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Mon Apr  9 18:50:30 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 09 Apr 2018 14:50:30 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <863c960f-110d-594a-66b7-22ff113e4927@csdoc.com>
References: <863c960f-110d-594a-66b7-22ff113e4927@csdoc.com>
Message-ID: <84d0d4ce67709ec85aff6fdafee6dead.NginxMailingListRussian@forum.nginx.org>

> Причина в том, что в документации для директивы fastcgi_cache_key
> указано некорректное с точки зрения протокола HTTP значение
> localhost:9000$request_uri - так оно нормально работать не будет.

Я использую сокет:
upstream fcgiwrap {
	server    unix:/var/run/fcgiwrap.socket;
	keepalive 32;
}
…
fastcgi_pass     fcgiwrap;

> Пока что существует только один workaround:
> добавить $request_method в fastcgi_cache_key
> Например, вот так:
> fastcgi_cache_key "$request_method $scheme://$host$request_uri";

Именно для того, чтобы разные HTTP-методы не перезаписывали кэш я использую
такой ключ:
fastcgi_cache_key     
'$scheme|$request_method|$http_if_none_match|$http_vary|$http_x_requested_with|$request_uri';

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279362#msg-279362


From nginx-forum на forum.nginx.org  Mon Apr  9 19:09:39 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 09 Apr 2018 15:09:39 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <20180409180802.GE77253@mdounin.ru>
References: <20180409180802.GE77253@mdounin.ru>
Message-ID: <b2b9670cbfa59635d742206b6e0b62d4.NginxMailingListRussian@forum.nginx.org>

> Судя по приведённому debug log'у, в кэше лежит валидный ответ 
> бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся 
> клиенту.

> Очевидно, что ответ этот nginx не сам придумал, а получил от 
> бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть 
> в debug log'е в тот момент, когда это произошло.

Понемногу картина проясняется.
Ответ действительно генерирует приложение, но это не основной бэкенд, а
бэкенд для SSI-вставки баннеров.

У меня были подозрения, что подзапрос на фоновое обновление кэша уходит
куда-то не туда и они подтвердились.
Добавил метку при генерации ответа и вижу её в файле кэша, когда вместо 404
начинает отдаваться 200.

Отдача баннеров производится из отдельного internal-локейшна, который
вызывается только при обработке SSI.
На странице 404 есть SSI баннеров.
Баннеры кэшируются отдельно, у них не только своя директория кэша, но и свой
ключ:
fastcgi_cache_path              /var/www/site/cache/banners     levels=   
keys_zone=banner:5m        inactive=1m  max_size=5m;
…
location /banner/ {
	internal;

	fastcgi_cache       banner;
	fastcgi_cache_valid 200 24h;
	fastcgi_cache_key   '$uri$is_args$args';

	set $handler        banner.html;
	set $querystring    $args;

	fastcgi_param REQUEST_URI $uri$is_args$args;
	fastcgi_param SCRIPT_NAME $uri$is_args$args;
	fastcgi_param PATH_INFO   $uri$is_args$args;

	include             parser;
	fastcgi_pass        fcgiwrap;
}

Могу лишь предположить, что подзапрос фонового обновления кэша наследует
fastcgi_cache_path и fastcgi_cache_key от основного запроса, а значения,
указанные в соответствующем локейшне, игнорируются, что приводит к
перезаписи содержимого кэша.

Памятуя о сохранении request_uri в подзапросах, специально использую в ключе
кэша подзапроса $uri.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279363#msg-279363


From mdounin на mdounin.ru  Mon Apr  9 20:03:47 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 9 Apr 2018 23:03:47 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <b2b9670cbfa59635d742206b6e0b62d4.NginxMailingListRussian@forum.nginx.org>
References: <20180409180802.GE77253@mdounin.ru>
 <b2b9670cbfa59635d742206b6e0b62d4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180409200347.GF77253@mdounin.ru>

Hello!

On Mon, Apr 09, 2018 at 03:09:39PM -0400, gz wrote:

> > Судя по приведённому debug log'у, в кэше лежит валидный ответ 
> > бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся 
> > клиенту.
> 
> > Очевидно, что ответ этот nginx не сам придумал, а получил от 
> > бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть 
> > в debug log'е в тот момент, когда это произошло.
> 
> Понемногу картина проясняется.
> Ответ действительно генерирует приложение, но это не основной бэкенд, а
> бэкенд для SSI-вставки баннеров.
> 
> У меня были подозрения, что подзапрос на фоновое обновление кэша уходит
> куда-то не туда и они подтвердились.
> Добавил метку при генерации ответа и вижу её в файле кэша, когда вместо 404
> начинает отдаваться 200.
> 
> Отдача баннеров производится из отдельного internal-локейшна, который
> вызывается только при обработке SSI.
> На странице 404 есть SSI баннеров.
> Баннеры кэшируются отдельно, у них не только своя директория кэша, но и свой
> ключ:
> fastcgi_cache_path              /var/www/site/cache/banners     levels=   
> keys_zone=banner:5m        inactive=1m  max_size=5m;
> …
> location /banner/ {
> 	internal;
> 
> 	fastcgi_cache       banner;
> 	fastcgi_cache_valid 200 24h;
> 	fastcgi_cache_key   '$uri$is_args$args';
> 
> 	set $handler        banner.html;
> 	set $querystring    $args;
> 
> 	fastcgi_param REQUEST_URI $uri$is_args$args;
> 	fastcgi_param SCRIPT_NAME $uri$is_args$args;
> 	fastcgi_param PATH_INFO   $uri$is_args$args;
> 
> 	include             parser;
> 	fastcgi_pass        fcgiwrap;
> }
> 
> Могу лишь предположить, что подзапрос фонового обновления кэша наследует
> fastcgi_cache_path и fastcgi_cache_key от основного запроса, а значения,
> указанные в соответствующем локейшне, игнорируются, что приводит к
> перезаписи содержимого кэша.
> 
> Памятуя о сохранении request_uri в подзапросах, специально использую в ключе
> кэша подзапроса $uri.

А как используются переменные $handler и $querystring?

Потому что в подзапросах и основном запросе пространство 
переменных общее, отличаются только значения, получаемые 
непосредственно из запроса, как например $uri и $args.  И 
соответственно после выполнения подзапроса в /banner/ - переменная 
$handler в основном запросе в том числе будет иметь значение 
"banner.html".  Если потом эта переменная как-то передаются на 
бэкенд, и на основании их генерируется ответ - то результат будет 
именно такой, как у вас получается, потому что в момент создания 
запроса на бэкенд для обновления кэша у переменной будет значение 
"banner.html".

-- 
Maxim Dounin
http://mdounin.ru/

From xeioex на nginx.com  Tue Apr 10 12:33:54 2018
From: xeioex на nginx.com (Dmitry Volyntsev)
Date: Tue, 10 Apr 2018 15:33:54 +0300
Subject: [njs] read request body
In-Reply-To: <c682fb05-1d61-f577-8389-f1e140d7d008@gmail.com>
References: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>
 <f70bf63b-d5c4-fbae-25bf-bf0f1f7a6a51@nginx.com>
 <c682fb05-1d61-f577-8389-f1e140d7d008@gmail.com>
Message-ID: <a3e572d8-a5b6-58bb-f04b-b9d5883edc80@nginx.com>



On 03.04.2018 18:26, Artem S. Povalyukhin wrote:
> 
> On 04/03/2018 06:17 PM, Dmitry Volyntsev wrote:
>>
>>
>> On 03.04.2018 18:00, Artem S. Povalyukhin wrote:
>>> Добрый день!
>>>
>>> Хотел узнать планируется ли добавить возможность чтения тела запроса в
>>> модуле ngx_http_js_module?
>>> Пока приходится городить костыли через ngx_stream_js_module.
>>>
>>> задача: праверить на валидность входящий json
>>>
>>
>> Добрый день,
>>
>> Тело запроса доступно в виде переменной: req.variables.request_body.
>>
> Огромное спасибо.
> Не совсем очевидно это.
> Может быть стоит сделать shortcut req.body -> req.variables.request_body ?
> 

данная функциональность будет доступна в следующем релизе (0.2.1)


> wbr,
> Artem
> 

From mdounin на mdounin.ru  Tue Apr 10 14:23:58 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 10 Apr 2018 17:23:58 +0300
Subject: nginx-1.13.12
Message-ID: <20180410142358.GJ77253@mdounin.ru>

Изменения в nginx 1.13.12                                         10.04.2018

    *) Исправление: при возврате большого ответа соединения с gRPC-бэкендами
       могли неожиданно закрываться.


-- 
Maxim Dounin
http://nginx.org/

From artem.povaluhin на gmail.com  Tue Apr 10 17:57:58 2018
From: artem.povaluhin на gmail.com (Artem S. Povalyukhin)
Date: Tue, 10 Apr 2018 20:57:58 +0300
Subject: [njs] read request body
In-Reply-To: <a3e572d8-a5b6-58bb-f04b-b9d5883edc80@nginx.com>
References: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>
 <f70bf63b-d5c4-fbae-25bf-bf0f1f7a6a51@nginx.com>
 <c682fb05-1d61-f577-8389-f1e140d7d008@gmail.com>
 <a3e572d8-a5b6-58bb-f04b-b9d5883edc80@nginx.com>
Message-ID: <6ddaecee-dc94-d4f7-7d80-d49447a4e1df@gmail.com>

On 04/10/2018 03:33 PM, Dmitry Volyntsev wrote:
>
>
> On 03.04.2018 18:26, Artem S. Povalyukhin wrote:
>>
>> On 04/03/2018 06:17 PM, Dmitry Volyntsev wrote:
>>>
>>>
>>> On 03.04.2018 18:00, Artem S. Povalyukhin wrote:
>>>> Добрый день!
>>>>
>>>> Хотел узнать планируется ли добавить возможность чтения тела запроса в
>>>> модуле ngx_http_js_module?
>>>> Пока приходится городить костыли через ngx_stream_js_module.
>>>>
>>>> задача: праверить на валидность входящий json
>>>>
>>>
>>> Добрый день,
>>>
>>> Тело запроса доступно в виде переменной: req.variables.request_body.
>>>
>> Огромное спасибо.
>> Не совсем очевидно это.
>> Может быть стоит сделать shortcut req.body ->
>> req.variables.request_body ?
>>
>
> данная функциональность будет доступна в следующем релизе (0.2.1)
>
Спасибо!

А куда можно скидывать feature request'ы?

хотелось бы base64decode для строк.

wbr,
Artem

From xeioex на nginx.com  Tue Apr 10 18:08:06 2018
From: xeioex на nginx.com (Dmitry Volyntsev)
Date: Tue, 10 Apr 2018 21:08:06 +0300
Subject: [njs] read request body
In-Reply-To: <6ddaecee-dc94-d4f7-7d80-d49447a4e1df@gmail.com>
References: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>
 <f70bf63b-d5c4-fbae-25bf-bf0f1f7a6a51@nginx.com>
 <c682fb05-1d61-f577-8389-f1e140d7d008@gmail.com>
 <a3e572d8-a5b6-58bb-f04b-b9d5883edc80@nginx.com>
 <6ddaecee-dc94-d4f7-7d80-d49447a4e1df@gmail.com>
Message-ID: <8b925c82-c441-e451-bd55-32aaafadd239@nginx.com>



On 10.04.2018 20:57, Artem S. Povalyukhin wrote:
> On 04/10/2018 03:33 PM, Dmitry Volyntsev wrote:
>>
>>
>> On 03.04.2018 18:26, Artem S. Povalyukhin wrote:
>>>
>>> On 04/03/2018 06:17 PM, Dmitry Volyntsev wrote:
>>>>
>>>>
>>>> On 03.04.2018 18:00, Artem S. Povalyukhin wrote:
>>>>> Добрый день!
>>>>>
>>>>> Хотел узнать планируется ли добавить возможность чтения тела запроса в
>>>>> модуле ngx_http_js_module?
>>>>> Пока приходится городить костыли через ngx_stream_js_module.
>>>>>
>>>>> задача: праверить на валидность входящий json
>>>>>
>>>>
>>>> Добрый день,
>>>>
>>>> Тело запроса доступно в виде переменной: req.variables.request_body.
>>>>
>>> Огромное спасибо.
>>> Не совсем очевидно это.
>>> Может быть стоит сделать shortcut req.body ->
>>> req.variables.request_body ?
>>>
>>
>> данная функциональность будет доступна в следующем релизе (0.2.1)
>>
> Спасибо!
> 
> А куда можно скидывать feature request'ы?
> 
> хотелось бы base64decode для строк.
> 

base64decode планируется добавить в ближайших релизах.

По вопросу куда скидывать feature request отвечу позже.

> wbr,
> Artem
> 

From xeioex на nginx.com  Wed Apr 11 14:52:04 2018
From: xeioex на nginx.com (Dmitry Volyntsev)
Date: Wed, 11 Apr 2018 17:52:04 +0300
Subject: [njs] read request body
In-Reply-To: <6ddaecee-dc94-d4f7-7d80-d49447a4e1df@gmail.com>
References: <eccb3cfd-dc3e-fbbb-a49d-4a8e11277461@gmail.com>
 <f70bf63b-d5c4-fbae-25bf-bf0f1f7a6a51@nginx.com>
 <c682fb05-1d61-f577-8389-f1e140d7d008@gmail.com>
 <a3e572d8-a5b6-58bb-f04b-b9d5883edc80@nginx.com>
 <6ddaecee-dc94-d4f7-7d80-d49447a4e1df@gmail.com>
Message-ID: <35cd5b98-b4a5-230f-1dcc-16e5e65d633c@nginx.com>



On 10.04.2018 20:57, Artem S. Povalyukhin wrote:
> On 04/10/2018 03:33 PM, Dmitry Volyntsev wrote:
>>
>>
>> On 03.04.2018 18:26, Artem S. Povalyukhin wrote:
>>>
>>> On 04/03/2018 06:17 PM, Dmitry Volyntsev wrote:
>>>>
>>>>
>>>> On 03.04.2018 18:00, Artem S. Povalyukhin wrote:
>>>>> Добрый день!
>>>>>
>>>>> Хотел узнать планируется ли добавить возможность чтения тела запроса в
>>>>> модуле ngx_http_js_module?
>>>>> Пока приходится городить костыли через ngx_stream_js_module.
>>>>>
>>>>> задача: праверить на валидность входящий json
>>>>>
>>>>
>>>> Добрый день,
>>>>
>>>> Тело запроса доступно в виде переменной: req.variables.request_body.
>>>>
>>> Огромное спасибо.
>>> Не совсем очевидно это.
>>> Может быть стоит сделать shortcut req.body ->
>>> req.variables.request_body ?
>>>
>>
>> данная функциональность будет доступна в следующем релизе (0.2.1)
>>
> Спасибо!
> 
> А куда можно скидывать feature request'ы?
> 

Скидывать feature request'ы можно сюда https://github.com/nginx/njs

> хотелось бы base64decode для строк.
> 
> wbr,
> Artem
> 

From yorick на ya.ru  Wed Apr 11 17:00:17 2018
From: yorick на ya.ru (Yury Lyakh)
Date: Wed, 11 Apr 2018 19:00:17 +0200
Subject: =?UTF-8?Q?max=5Ffails=3D0_=D0=B8_no_live_upstreams_while_connecting_to_ups?=
 =?UTF-8?Q?tream?=
Message-ID: <F8105BF4-6D98-423F-A21E-88D8676EA5DA@ya.ru>

Господа, подскажите пожалуйста,

В документации сказано что max_fais=0 отключает попадание апстрима в блэклист на время из-за проблем с ним.

То есть, как я понимаю постучались на бэкенд, получили 502 или еще что, отдали клиенту. И дальше стучимся на бэкенд, а не замораживаем его с сообщением в лог "no live upstreams while connecting to upstream".


upstream games-storage-ru {
  zone games-storage-ru 64k;
  server games.syd.origin.ru <http://games.syd.origin.ru/> max_fails=0;
  keepalive 4;
}


"46.116.106.159" "-" "-" "[11/Apr/2018:16:37:29 +0000]" "HEAD /Logo.png HTTP/1.1" "502" "0" "-" "curl/7.54.0" "169" "-" "http" "games-storage.ru <http://games-storage.ru/>" "0.000" "0.000" "99" "-" "[fr5]" "MISS" "0" "games-storage-ru" "2052" "4468" "-" "-"

2018/04/11 16:37:29 [error] 34796#34796: *672751767 no live upstreams while connecting to upstream, client: 46.116.106.159, server: games-storage.ru <http://games-storage.ru/>, request: "HEAD /Logo.png HTTP/1.1", upstream: "http://games-storage-ru/Logo.png <http://games-storage-ru/Logo.png>", host: "games-storage.ru <http://games-storage.ru/>"

Или я что-то упустил?
Или при max_fails=0 это сообщение чисто информационное и данный server в апстрим не блэклистится на самом деле?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180411/6edf9f35/attachment.html>

From nginx-forum на forum.nginx.org  Thu Apr 12 02:40:02 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Wed, 11 Apr 2018 22:40:02 -0400
Subject: =?UTF-8?B?cHJveHkgcGFzcyDQuCDQutC+0LTQuNGA0L7QstCw0L3QuNC1IEdFVC3Qv9Cw0YA=?=
 =?UTF-8?B?0LDQvNC10YLRgNC+0LI=?=
Message-ID: <d941bfb9d6788e2df575e8e216ecb91a.NginxMailingListRussian@forum.nginx.org>

Добрый день.

Использую SSI для включения ответа стороннего сервера.

<!--#include virtual="/include/"-->

location /include {
	internal;

	proxy_pass
http://example.com/endpoint?server=$server_name&uri=$request_uri&ua=$http_user_agent;
}

Серверу нужно передать ряд GET-параметров (не заголовков).
Однако, при передаче того же $http_user_agent сервер отвечает ошибкой 400.
Судя по всему, параметры, указанные в URI proxy_pass не URI-кодируются.

Есть ли способы сформировать корректный запрос с произвольными параметрами?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279410,279410#msg-279410


From alex на vorona.com.ua  Thu Apr 12 06:07:53 2018
From: alex на vorona.com.ua (Alex Vorona)
Date: Thu, 12 Apr 2018 09:07:53 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0Lgg0LrQvtC00LjRgNC+0LLQsNC90LjQtSBHRVQt0L8=?=
 =?UTF-8?B?0LDRgNCw0LzQtdGC0YDQvtCy?=
In-Reply-To: <d941bfb9d6788e2df575e8e216ecb91a.NginxMailingListRussian@forum.nginx.org>
References: <d941bfb9d6788e2df575e8e216ecb91a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <50a9a2d9-3ce6-0738-4d85-dc54e0daca47@vorona.com.ua>



12.04.18 05:40, gz wrote:
> Добрый день.
[...]
> Судя по всему, параметры, указанные в URI proxy_pass не URI-кодируются.
> 
> Есть ли способы сформировать корректный запрос с произвольными параметрами?
> 
Попробуйте https://github.com/openresty/set-misc-nginx-module

--
Alex Vorona

From nginx-forum на forum.nginx.org  Thu Apr 12 15:15:44 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Thu, 12 Apr 2018 11:15:44 -0400
Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0Lgg0LrQvtC00LjRgNC+0LLQsNC90LjQtSBHRVQt0L8=?=
 =?UTF-8?B?0LDRgNCw0LzQtdGC0YDQvtCy?=
In-Reply-To: <50a9a2d9-3ce6-0738-4d85-dc54e0daca47@vorona.com.ua>
References: <50a9a2d9-3ce6-0738-4d85-dc54e0daca47@vorona.com.ua>
Message-ID: <512e83803f56f9de3f55d63a50265318.NginxMailingListRussian@forum.nginx.org>

> Попробуйте https://github.com/openresty/set-misc-nginx-module

Спасибо.

Странно, что nginx не делает такой простой вещи.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279411,279420#msg-279420


From mdounin на mdounin.ru  Thu Apr 12 15:27:45 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 12 Apr 2018 18:27:45 +0300
Subject: =?UTF-8?Q?Re=3A_max=5Ffails=3D0_=D0=B8_no_live_upstreams_while_connecting_?=
 =?UTF-8?Q?to_upstream?=
In-Reply-To: <F8105BF4-6D98-423F-A21E-88D8676EA5DA@ya.ru>
References: <F8105BF4-6D98-423F-A21E-88D8676EA5DA@ya.ru>
Message-ID: <20180412152745.GO77253@mdounin.ru>

Hello!

On Wed, Apr 11, 2018 at 07:00:17PM +0200, Yury Lyakh wrote:

> Господа, подскажите пожалуйста,
> 
> В документации сказано что max_fais=0 отключает попадание апстрима в блэклист на время из-за проблем с ним.
> 
> То есть, как я понимаю постучались на бэкенд, получили 502 или еще что, отдали клиенту. И дальше стучимся на бэкенд, а не замораживаем его с сообщением в лог "no live upstreams while connecting to upstream".
> 
> 
> upstream games-storage-ru {
>   zone games-storage-ru 64k;
>   server games.syd.origin.ru <http://games.syd.origin.ru/> max_fails=0;
>   keepalive 4;
> }
> 
> 
> "46.116.106.159" "-" "-" "[11/Apr/2018:16:37:29 +0000]" "HEAD /Logo.png HTTP/1.1" "502" "0" "-" "curl/7.54.0" "169" "-" "http" "games-storage.ru <http://games-storage.ru/>" "0.000" "0.000" "99" "-" "[fr5]" "MISS" "0" "games-storage-ru" "2052" "4468" "-" "-"
> 
> 2018/04/11 16:37:29 [error] 34796#34796: *672751767 no live upstreams while connecting to upstream, client: 46.116.106.159, server: games-storage.ru <http://games-storage.ru/>, request: "HEAD /Logo.png HTTP/1.1", upstream: "http://games-storage-ru/Logo.png <http://games-storage-ru/Logo.png>", host: "games-storage.ru <http://games-storage.ru/>"
> 
> Или я что-то упустил?
> Или при max_fails=0 это сообщение чисто информационное и данный server в апстрим не блэклистится на самом деле?

Сообщение "no live upstreams..." означает, что nginx пытался 
выбрать бэкенд, но не смог, потому что все сконфигурированные 
бэкенды либо выключены, либо уже были попробованы в рамках данного 
запроса.

Обычно это сообщение не появляется, если учёт ошибок выключен, 
потому что количество попыток переключения на следующий бэкенд 
ограничено количеством бэкендов.  Однако это может быть не так в 
случае использования keepalive'а к бэкендам - попытки использования 
закэшированных соединений не учитываются, и суммарное количество 
попыток в результате может превышать общее количество бэкендов, 
приводя к сообщению "no live upstreams...", когда на все бэкенды 
уже попытались сходить.  Судя по всему у вас просходит именно это.

Какого-либо выключения бэкендов при этом не происходит, сообщение 
относится именно к конкретному запросу.

-- 
Maxim Dounin
http://mdounin.ru/

From vbart на nginx.com  Thu Apr 12 18:41:20 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 12 Apr 2018 21:41:20 +0300
Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuMA==?=
Message-ID: <2468785.UYU1bi8WO5@vbart-workstation>

Здравствуйте.

Поздравляю всех с Днём космонавтики и рад сообщить, что сегодня состоялся
релиз NGINX Unit 1.0.

Изменения в Unit 1.0                                              12.04.2018

    *) Изменение: объект конфигурации теперь расположен по пути "/config/".

    *) Добавление: базовая поддержка логирования доступа (access log).

    *) Исправление: если приложение на Go не писало заголовков или тела ответа,
       то случалась ошибка 503.

    *) Исправление: приложения на Ruby, которые использовали преобразования
       кодировок, могли не работать.

    *) Исправлены различные проблемы со стабильностью.


С данным выпуском Unit заканчивает стадию бета-тестирования.  Более подробно
о текущем состоянии проекта и планах на будущее можно узнать из анонса:

 - https://www.nginx.com/blog/nginx-unit-1-0-released/

--
Валентин Бартенев

From xeioex на nginx.com  Fri Apr 13 15:24:56 2018
From: xeioex на nginx.com (Dmitry Volyntsev)
Date: Fri, 13 Apr 2018 18:24:56 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0Lgg0LrQvtC00LjRgNC+0LLQsNC90LjQtSBHRVQt0L8=?=
 =?UTF-8?B?0LDRgNCw0LzQtdGC0YDQvtCy?=
In-Reply-To: <d941bfb9d6788e2df575e8e216ecb91a.NginxMailingListRussian@forum.nginx.org>
References: <d941bfb9d6788e2df575e8e216ecb91a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <98a952be-eb5b-3309-82bb-fc601f3a342e@nginx.com>



On 12.04.2018 05:40, gz wrote:
> Добрый день.
> 
> Использую SSI для включения ответа стороннего сервера.
> 
> <!--#include virtual="/include/"-->
> 
> location /include {
> 	internal;
> 
> 	proxy_pass
> http://example.com/endpoint?server=$server_name&uri=$request_uri&ua=$http_user_agent;
> }
> 
> Серверу нужно передать ряд GET-параметров (не заголовков).
> Однако, при передаче того же $http_user_agent сервер отвечает ошибкой 400.
> Судя по всему, параметры, указанные в URI proxy_pass не URI-кодируются.
> 
> Есть ли способы сформировать корректный запрос с произвольными параметрами?

Есть возможность использовать функциональность njs для сериализации 
аргументов запроса.


http://nginx.org/en/docs/http/ngx_http_js_module.html

nginx.conf:

http { 

     	js_include http.njs;
	js_set $encoded_request_uri     encoded_request_uri;
         ...
	<use $encoded_request_uri>
}


http.njs:

function encoded_request_uri(req) {
	return encodeURIComponent(req.variables.request_uri);
}


Однако, в общем случае задача усложняется тем что содержимое 
$request_uri может быть уже url-encoded.





> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279410,279410#msg-279410
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 

From nginx-forum на forum.nginx.org  Sat Apr 14 19:19:24 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Sat, 14 Apr 2018 15:19:24 -0400
Subject: =?UTF-8?B?UmU6IHByb3h5IHBhc3Mg0Lgg0LrQvtC00LjRgNC+0LLQsNC90LjQtSBHRVQt0L8=?=
 =?UTF-8?B?0LDRgNCw0LzQtdGC0YDQvtCy?=
In-Reply-To: <98a952be-eb5b-3309-82bb-fc601f3a342e@nginx.com>
References: <98a952be-eb5b-3309-82bb-fc601f3a342e@nginx.com>
Message-ID: <3a22521386b8ce9c788fff04c0f7cfe0.NginxMailingListRussian@forum.nginx.org>

> Есть возможность использовать функциональность njs для сериализации 
аргументов запроса.

Спасибо, посмотрю.

Но, всё же, считаю, что nginx'у стоило был самому делать uri-encoding
параметров запроса.

> Однако, в общем случае задача усложняется тем что содержимое $request_uri
может быть уже url-encoded.

Не беда, можно использовать декодированную $uri.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279436,279443#msg-279443


From nginx-forum на forum.nginx.org  Sun Apr 15 17:51:53 2018
From: nginx-forum на forum.nginx.org (Edward Gaba)
Date: Sun, 15 Apr 2018 13:51:53 -0400
Subject: =?UTF-8?B?0J7RgtCy0LXRgiDQv9C+INC40LzQtdC90Lgg0Lgg0L/QvtGA0YLRgyDQvdC1INGD?=
 =?UTF-8?B?0LrQsNC30LDQvdC90L7QvNGDINCyIHNlcnZlcg==?=
Message-ID: <15cbe91c5b0e3fa5a428d4fd1e6556f4.NginxMailingListRussian@forum.nginx.org>

Доброго!

Ситуация:

nginx 1.12.2 (gentoo)

На сервере (1 ip адрес) несколько доменов.
конфиги каждого домена в своем файле, подключаются через include
/etc/nginx/sites-enabled/*.conf;
Для некоторых доменов настроен SSL, а другие без SSL.

Суть в том, что все домены без SSL (слушают только порт 80, части конфига с
SSL нет) отвечают на SSL порту, с сертификатом другого домена.
Вот пример, domain1 отвечает на https и отображает контент domain2 с
сертификатом domain2.
Как это возможно и как исправить? Не могу понять, в чем ошибка.

Полные 2 конфига:

########### DOMAIN1.RU ##########

	server {
		listen 80;
		set $root_path '/var/www/sites/gaba/www/domain1.ru/www';
		set $root_php_chroot '/www/domain1.ru/www';
		root $root_path;
		server_name domain1.ru n.domain1.ru www.domain1.ru;
		
		if ($host = 'n.domain1.ru') {
		    rewrite  ^/(.*)$  http://domain1.ru/$1  permanent;
		}
		
		if ($host = 'www.domain1.ru') {
		    rewrite  ^/(.*)$  http://domain1.ru/$1  permanent;
		}
		
		access_log /var/www/sites/gaba/logs/domain1.ru_access.log;
		error_log /var/www/sites/gaba/logs/domain1.ru_error.log;
		
		index index.php index.html index.htm default.html default.htm;
		
		add_header X-Frame-Options "ALLOW-FROM: webvisor.com";
		
		location / {
			root $root_path;
			try_files $uri @dmrewrite;
		}
		
		location @dmrewrite {
			include /var/www/sites/gaba/www/domain1.ru/www/rewrite.dat;
		}
		
		##### Pagespeed config #####
		pagespeed LoadFromFile "http://domain1.ru/themes/dm/"
"/var/www/sites/gaba/www/domain1.ru/www/themes/dm/";
		pagespeed LoadFromFile "http://domain1.ru/plugins/ratings/"
"/var/www/sites/gaba/www/domain1.ru/www/plugins/ratings/";
		pagespeed LoadFromFile "http://domain1.ru/plugins/tags/"
"/var/www/sites/gaba/www/domain1.ru/www/plugins/tags/";
		pagespeed LoadFromFile "http://domain1.ru/plugins/search/"
"/var/www/sites/gaba/www/domain1.ru/www/plugins/search/";
		pagespeed LoadFromFile "http://domain1.ru/js/"
"/var/www/sites/gaba/www/domain1.ru/www/js/";
		pagespeed LoadFromFile "http://domain1.ru/images/"
"/var/www/sites/gaba/www/domain1.ru/www/images/";
		pagespeed LoadFromFileRuleMatch disallow \.*;
		pagespeed LoadFromFileRuleMatch allow \.(css|js|jpg|jpeg|png)$;
		location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
		    add_header "" "";
		}
		location ~ "^/ngx_pagespeed_static/" { }
		location ~ "^/ngx_pagespeed_beacon$" { }
		location /ngx_pagespeed_statistics { allow 127.0.0.1; deny all; }
		location /ngx_pagespeed_global_statistics { allow 127.0.0.1; deny all; }
		location /ngx_pagespeed_message { allow 127.0.0.1; deny all; }
		##### Pagespeed config end #####
		
		location ~*
^.+\.(jpg|jpeg|gif|png|svg|swf|flv|js|ico|css|mp3|ogg|mpe?g|avi|zip|tgz|gz|bz2?|rar|doc|xls|rtf|pdf|exe|ppt|txt|tar|mid|midi|wav|html|htm)$
{
		root $root_path;
		access_log off;
		expires 15d;
		}
		
		location ~ \.php$ {
		fastcgi_pass 127.0.0.1:9000;
		
		# set root path for php-fpm in chroot mode
		root $root_php_chroot;
		
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;
		fastcgi_intercept_errors on;
		
		}
		
		location ~ \.(htpasswd|htaccess|tpl|dat|sqlite|svn|git)$ {
			deny all;
		}
		
		autoindex off;
	}

########## DOMAIN2.RU ##############

	server{
		listen 80;
		server_name www.domain2.ru domain2.ru;
		return 301 https://domain2.ru$request_uri;
	}

	server {
		listen 443 ssl http2;
		set $root_path '/var/www/sites/gaba/www/domain2.ru/www';
		set $root_php_chroot '/www/domain2.ru/www';
		root $root_path;
		server_name domain2.ru;
		
		if ($host = 'www.domain2.ru') {
		    rewrite  ^/(.*)$  https://domain2.ru/$1  permanent;
		}
		
		ssl_certificate /etc/letsencrypt/live/domain2.ru/fullchain.pem;
		ssl_certificate_key /etc/letsencrypt/live/domain2.ru/privkey.pem;
		ssl_trusted_certificate /etc/letsencrypt/live/domain2.ru/chain.pem;
		
		resolver 127.0.0.1 8.8.8.8  valid=300s;
		resolver_timeout 5s;
		ssl_stapling on;
		ssl_stapling_verify on;
		ssl_session_timeout 5m;
		ssl_session_cache shared:SSL:10m;
		ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
		ssl_prefer_server_ciphers on;
		ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:RSA+3DES:!NULL:!RC4;
		ssl_dhparam /etc/ssl/certs/dhparam.pem;
		add_header Strict-Transport-Security "max-age=31536000";
		
		access_log /var/www/sites/gaba/logs/domain2.ru_access.log;
		error_log /var/www/sites/gaba/logs/domain2.ru_error.log;
		
		index index.php index.html index.htm;
		
		add_header X-Frame-Options "ALLOW-FROM: webvisor.com";
		
		location / {
			root $root_path;
			try_files $uri @a2r;
		}
		
		location @a2r {
			include /var/www/sites/gaba/www/domain2.ru/www/rewrite.dat;
		}
		
		location ~ /.well-known {
			allow all;
			root $root_path;
		}
		
		##### Pagespeed config #####
		pagespeed LoadFromFile "https://domain2.ru/themes/a2r/"
"/var/www/sites/gaba/www/domain2.ru/www/themes/a2r/";
		pagespeed LoadFromFile "https://domain2.ru/js/"
"/var/www/sites/gaba/www/domain2.ru/www/js/";
		pagespeed LoadFromFile "https://domain2.ru/modules/fileAPI/css/"
"/var/www/sites/gaba/www/domain2.ru/www/modules/fileAPI/css/";
		pagespeed LoadFromFileRuleMatch disallow \.*;
		pagespeed LoadFromFileRuleMatch allow \.(css|js)$;
		location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
		    add_header "" "";
		}
		location ~ "^/ngx_pagespeed_static/" { }
		location ~ "^/ngx_pagespeed_beacon$" { }
		location /ngx_pagespeed_statistics { allow 127.0.0.1; deny all; }
		location /ngx_pagespeed_global_statistics { allow 127.0.0.1; deny all; }
		location /ngx_pagespeed_message { allow 127.0.0.1; deny all; }
		##### Pagespeed config end #####
		
		location ~*
^.+\.(jpg|jpeg|gif|png|svg|swf|flv|js|ico|css|mp3|ogg|mpe?g|avi|zip|tgz|gz|bz2?|rar|doc|xls|rtf|pdf|exe|ppt|txt|tar|mid|midi|wav|woff|woff2|html|htm)$
{
		root $root_path;
		access_log off;
		expires 8d;
		}
		
		location ~ \.php$ {
		fastcgi_pass 127.0.0.1:9000;
		
		# set root path for php-fpm in chroot mode
		root $root_php_chroot;
		
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;
		fastcgi_intercept_errors off;
		}
		
		location ~ \.(htpasswd|htaccess|tpl|dat|sqlite|svn|git)$ {
			deny all;
		}
		
		autoindex off;
	}

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279446,279446#msg-279446


From shadow.tehb на gmail.com  Sun Apr 15 19:39:13 2018
From: shadow.tehb на gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCe0LvQtdCz0L7QstC40Yc=?=)
Date: Sun, 15 Apr 2018 22:39:13 +0300
Subject: =?UTF-8?B?UmU6INCe0YLQstC10YIg0L/QviDQuNC80LXQvdC4INC4INC/0L7RgNGC0YMg0L0=?=
 =?UTF-8?B?0LUg0YPQutCw0LfQsNC90L3QvtC80YMg0LIgc2VydmVy?=
In-Reply-To: <15cbe91c5b0e3fa5a428d4fd1e6556f4.NginxMailingListRussian@forum.nginx.org>
References: <15cbe91c5b0e3fa5a428d4fd1e6556f4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CACP=zQJiVR4kt5YNtbzQWMax+QhRKCN0kXLEQpkYizj=G29VnQ@mail.gmail.com>

Что в логах пишется?
fastcgi_pass у вас в обоих конфигах один, что отдаёт?

if'ы с rewrite лучше заменить отдельными server
root достаточно один раз задавать в секции server, дальше наследование
происходит

2018-04-15 20:51 GMT+03:00 Edward Gaba <nginx-forum на forum.nginx.org>:

> Доброго!
>
> Ситуация:
>
> nginx 1.12.2 (gentoo)
>
> На сервере (1 ip адрес) несколько доменов.
> конфиги каждого домена в своем файле, подключаются через include
> /etc/nginx/sites-enabled/*.conf;
> Для некоторых доменов настроен SSL, а другие без SSL.
>
> Суть в том, что все домены без SSL (слушают только порт 80, части конфига с
> SSL нет) отвечают на SSL порту, с сертификатом другого домена.
> Вот пример, domain1 отвечает на https и отображает контент domain2 с
> сертификатом domain2.
> Как это возможно и как исправить? Не могу понять, в чем ошибка.
>
> Полные 2 конфига:
>
> ########### DOMAIN1.RU ##########
>
>         server {
>                 listen 80;
>                 set $root_path '/var/www/sites/gaba/www/domain1.ru/www';
>                 set $root_php_chroot '/www/domain1.ru/www';
>                 root $root_path;
>                 server_name domain1.ru n.domain1.ru www.domain1.ru;
>
>                 if ($host = 'n.domain1.ru') {
>                     rewrite  ^/(.*)$  http://domain1.ru/$1  permanent;
>                 }
>
>                 if ($host = 'www.domain1.ru') {
>                     rewrite  ^/(.*)$  http://domain1.ru/$1  permanent;
>                 }
>
>                 access_log /var/www/sites/gaba/logs/domain1.ru_access.log;
>                 error_log /var/www/sites/gaba/logs/domain1.ru_error.log;
>
>                 index index.php index.html index.htm default.html
> default.htm;
>
>                 add_header X-Frame-Options "ALLOW-FROM: webvisor.com";
>
>                 location / {
>                         root $root_path;
>                         try_files $uri @dmrewrite;
>                 }
>
>                 location @dmrewrite {
>                         include /var/www/sites/gaba/www/domain
> 1.ru/www/rewrite.dat;
>                 }
>
>                 ##### Pagespeed config #####
>                 pagespeed LoadFromFile "http://domain1.ru/themes/dm/"
> "/var/www/sites/gaba/www/domain1.ru/www/themes/dm/";
>                 pagespeed LoadFromFile "http://domain1.ru/plugins/ratings/
> "
> "/var/www/sites/gaba/www/domain1.ru/www/plugins/ratings/";
>                 pagespeed LoadFromFile "http://domain1.ru/plugins/tags/"
> "/var/www/sites/gaba/www/domain1.ru/www/plugins/tags/";
>                 pagespeed LoadFromFile "http://domain1.ru/plugins/search/"
> "/var/www/sites/gaba/www/domain1.ru/www/plugins/search/";
>                 pagespeed LoadFromFile "http://domain1.ru/js/"
> "/var/www/sites/gaba/www/domain1.ru/www/js/";
>                 pagespeed LoadFromFile "http://domain1.ru/images/"
> "/var/www/sites/gaba/www/domain1.ru/www/images/";
>                 pagespeed LoadFromFileRuleMatch disallow \.*;
>                 pagespeed LoadFromFileRuleMatch allow
> \.(css|js|jpg|jpeg|png)$;
>                 location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+"
> {
>                     add_header "" "";
>                 }
>                 location ~ "^/ngx_pagespeed_static/" { }
>                 location ~ "^/ngx_pagespeed_beacon$" { }
>                 location /ngx_pagespeed_statistics { allow 127.0.0.1; deny
> all; }
>                 location /ngx_pagespeed_global_statistics { allow
> 127.0.0.1; deny all; }
>                 location /ngx_pagespeed_message { allow 127.0.0.1; deny
> all; }
>                 ##### Pagespeed config end #####
>
>                 location ~*
> ^.+\.(jpg|jpeg|gif|png|svg|swf|flv|js|ico|css|mp3|ogg|
> mpe?g|avi|zip|tgz|gz|bz2?|rar|doc|xls|rtf|pdf|exe|ppt|txt|
> tar|mid|midi|wav|html|htm)$
> {
>                 root $root_path;
>                 access_log off;
>                 expires 15d;
>                 }
>
>                 location ~ \.php$ {
>                 fastcgi_pass 127.0.0.1:9000;
>
>                 # set root path for php-fpm in chroot mode
>                 root $root_php_chroot;
>
>                 fastcgi_index index.php;
>                 include /etc/nginx/fastcgi_params;
>                 fastcgi_intercept_errors on;
>
>                 }
>
>                 location ~ \.(htpasswd|htaccess|tpl|dat|sqlite|svn|git)$ {
>                         deny all;
>                 }
>
>                 autoindex off;
>         }
>
> ########## DOMAIN2.RU ##############
>
>         server{
>                 listen 80;
>                 server_name www.domain2.ru domain2.ru;
>                 return 301 https://domain2.ru$request_uri;
>         }
>
>         server {
>                 listen 443 ssl http2;
>                 set $root_path '/var/www/sites/gaba/www/domain2.ru/www';
>                 set $root_php_chroot '/www/domain2.ru/www';
>                 root $root_path;
>                 server_name domain2.ru;
>
>                 if ($host = 'www.domain2.ru') {
>                     rewrite  ^/(.*)$  https://domain2.ru/$1  permanent;
>                 }
>
>                 ssl_certificate /etc/letsencrypt/live/domain2.
> ru/fullchain.pem;
>                 ssl_certificate_key /etc/letsencrypt/live/domain2.
> ru/privkey.pem;
>                 ssl_trusted_certificate /etc/letsencrypt/live/domain2.
> ru/chain.pem;
>
>                 resolver 127.0.0.1 8.8.8.8  valid=300s;
>                 resolver_timeout 5s;
>                 ssl_stapling on;
>                 ssl_stapling_verify on;
>                 ssl_session_timeout 5m;
>                 ssl_session_cache shared:SSL:10m;
>                 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
>                 ssl_prefer_server_ciphers on;
>                 ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:
> RSA+3DES:!NULL:!RC4;
>                 ssl_dhparam /etc/ssl/certs/dhparam.pem;
>                 add_header Strict-Transport-Security "max-age=31536000";
>
>                 access_log /var/www/sites/gaba/logs/domain2.ru_access.log;
>                 error_log /var/www/sites/gaba/logs/domain2.ru_error.log;
>
>                 index index.php index.html index.htm;
>
>                 add_header X-Frame-Options "ALLOW-FROM: webvisor.com";
>
>                 location / {
>                         root $root_path;
>                         try_files $uri @a2r;
>                 }
>
>                 location @a2r {
>                         include /var/www/sites/gaba/www/domain
> 2.ru/www/rewrite.dat;
>                 }
>
>                 location ~ /.well-known {
>                         allow all;
>                         root $root_path;
>                 }
>
>                 ##### Pagespeed config #####
>                 pagespeed LoadFromFile "https://domain2.ru/themes/a2r/"
> "/var/www/sites/gaba/www/domain2.ru/www/themes/a2r/";
>                 pagespeed LoadFromFile "https://domain2.ru/js/"
> "/var/www/sites/gaba/www/domain2.ru/www/js/";
>                 pagespeed LoadFromFile "https://domain2.ru/modules/
> fileAPI/css/"
> "/var/www/sites/gaba/www/domain2.ru/www/modules/fileAPI/css/";
>                 pagespeed LoadFromFileRuleMatch disallow \.*;
>                 pagespeed LoadFromFileRuleMatch allow \.(css|js)$;
>                 location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+"
> {
>                     add_header "" "";
>                 }
>                 location ~ "^/ngx_pagespeed_static/" { }
>                 location ~ "^/ngx_pagespeed_beacon$" { }
>                 location /ngx_pagespeed_statistics { allow 127.0.0.1; deny
> all; }
>                 location /ngx_pagespeed_global_statistics { allow
> 127.0.0.1; deny all; }
>                 location /ngx_pagespeed_message { allow 127.0.0.1; deny
> all; }
>                 ##### Pagespeed config end #####
>
>                 location ~*
> ^.+\.(jpg|jpeg|gif|png|svg|swf|flv|js|ico|css|mp3|ogg|
> mpe?g|avi|zip|tgz|gz|bz2?|rar|doc|xls|rtf|pdf|exe|ppt|txt|
> tar|mid|midi|wav|woff|woff2|html|htm)$
> {
>                 root $root_path;
>                 access_log off;
>                 expires 8d;
>                 }
>
>                 location ~ \.php$ {
>                 fastcgi_pass 127.0.0.1:9000;
>
>                 # set root path for php-fpm in chroot mode
>                 root $root_php_chroot;
>
>                 fastcgi_index index.php;
>                 include /etc/nginx/fastcgi_params;
>                 fastcgi_intercept_errors off;
>                 }
>
>                 location ~ \.(htpasswd|htaccess|tpl|dat|sqlite|svn|git)$ {
>                         deny all;
>                 }
>
>                 autoindex off;
>         }
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,279446,279446#msg-279446
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180415/bd0a4f67/attachment-0001.html>

From andrey на kopeyko.ru  Sun Apr 15 23:37:52 2018
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Mon, 16 Apr 2018 02:37:52 +0300
Subject: =?UTF-8?B?UmU6INCe0YLQstC10YIg0L/QviDQuNC80LXQvdC4INC4INC/0L7RgNGC0YMg0L0=?=
 =?UTF-8?B?0LUg0YPQutCw0LfQsNC90L3QvtC80YMg0LIgc2VydmVy?=
In-Reply-To: <15cbe91c5b0e3fa5a428d4fd1e6556f4.NginxMailingListRussian@forum.nginx.org>
References: <15cbe91c5b0e3fa5a428d4fd1e6556f4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e549b3388f8b2205c186f21170d5d485@kopeyko.ru>

Edward Gaba писал 2018-04-15 20:51:
> Доброго!

Добрый день, Эдвард!

> На сервере (1 ip адрес) несколько доменов.
> конфиги каждого домена в своем файле, подключаются через include
> /etc/nginx/sites-enabled/*.conf;
> Для некоторых доменов настроен SSL, а другие без SSL.
> 
> Суть в том, что все домены без SSL (слушают только порт 80, части 
> конфига с
> SSL нет) отвечают на SSL порту, с сертификатом другого домена.
> Вот пример, domain1 отвечает на https и отображает контент domain2 с
> сертификатом domain2.
> Как это возможно и как исправить? Не могу понять, в чем ошибка.

Ошибки нет - так работает TLS в случае name-based виртуальных серверов: 
отдаётся первый описанный в конфиге сертификат для этого IP:port

Исправить можно двумя путями:

1. заведите и сконфигурите TLS-сертификат для домена domain1

2. заведите на сервере второй IP-адрес, не конфигурите для него HTTPS, и 
перенесите на него все HTTP-only домены.

-- 
Best regards,
Andrey A. Kopeyko <andrey на kopeyko.ru>

From nginx-forum на forum.nginx.org  Mon Apr 16 06:05:31 2018
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Mon, 16 Apr 2018 02:05:31 -0400
Subject: =?UTF-8?B?UmU6INCe0YLQstC10YIg0L/QviDQuNC80LXQvdC4INC4INC/0L7RgNGC0YMg0L0=?=
 =?UTF-8?B?0LUg0YPQutCw0LfQsNC90L3QvtC80YMg0LIgc2VydmVy?=
In-Reply-To: <15cbe91c5b0e3fa5a428d4fd1e6556f4.NginxMailingListRussian@forum.nginx.org>
References: <15cbe91c5b0e3fa5a428d4fd1e6556f4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <fc4e1c4c63d86f578a325ff275b62db9.NginxMailingListRussian@forum.nginx.org>

if ($host != 'domain2.ru') { ... 

далее, думаю, понятно...

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279446,279449#msg-279449


From nginx-forum на forum.nginx.org  Mon Apr 16 11:25:43 2018
From: nginx-forum на forum.nginx.org (tresor.fk)
Date: Mon, 16 Apr 2018 07:25:43 -0400
Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgc3NsINGB0LXRgNGC0LjRhNC40Lo=?=
 =?UTF-8?B?0LDRgtCwINC4INC60LvRjtGH0LA=?=
Message-ID: <3448a931b968a64923874e8eaa3f94d5.NginxMailingListRussian@forum.nginx.org>

Помогите разобраться со следующей ситуацией:

Есть веб сервер подрядчика, доступ к которому осуществляется по выделенному
каналу и при указании сертификата и приватного ключа

То есть у нас есть линуксовый сервер, с которого мы инициализируем
подключение. Для этого на нем настроен дополнительный сетевой интерфейс.

Например если запустить:

wget --bind-address=<Secondary IP>
--certificate=/etc/nginx/ssl/private_online.crt
--private-key=/etc/nginx/ssl/private_online.key  https://<URL of website>

То подключение успешное - "HTTP request sent, awaiting response... 200 OK"

Но нам нужно на этом сервере настроить nginx, чтобы мы со своих компьютеров
открывали в браузере IP нашего сервера и попадали на сервер подрядчика

Как настроить NGINX, чтобы он делал bind_adress и передавал для авторизации
сертификат и ключ по аналогии с wget?

Пробовал использовать следующее, но не помогает

    proxy_bind XX.XX.XX.XX;
    proxy_pass https://<URL of website>;
    proxy_ssl_certificate /etc/nginx/ssl/private_online.pem;
    proxy_ssl_certificate_key /etc/nginx/ssl/private_online_key.pem;

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279454,279454#msg-279454


From uncleandyv на gmail.com  Mon Apr 16 11:48:27 2018
From: uncleandyv на gmail.com (Andrey Velikoredchanin)
Date: Mon, 16 Apr 2018 14:48:27 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IHNzbCDRgdC10YDRgtC40YQ=?=
 =?UTF-8?B?0LjQutCw0YLQsCDQuCDQutC70Y7Rh9Cw?=
In-Reply-To: <3448a931b968a64923874e8eaa3f94d5.NginxMailingListRussian@forum.nginx.org>
References: <3448a931b968a64923874e8eaa3f94d5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAOrB69NkxyrB25ORXKPf83X-L3wGS+obd--p9sU+k7zh0hSSJw@mail.gmail.com>

Делал как-то такое. Это вам надо tcp-proxy на nginx настроить. Подробности
вот тут -
https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/

16 апреля 2018 г., 14:25 пользователь tresor.fk <nginx-forum на forum.nginx.org
> написал:

> Помогите разобраться со следующей ситуацией:
>
> Есть веб сервер подрядчика, доступ к которому осуществляется по выделенному
> каналу и при указании сертификата и приватного ключа
>
> То есть у нас есть линуксовый сервер, с которого мы инициализируем
> подключение. Для этого на нем настроен дополнительный сетевой интерфейс.
>
> Например если запустить:
>
> wget --bind-address=<Secondary IP>
> --certificate=/etc/nginx/ssl/private_online.crt
> --private-key=/etc/nginx/ssl/private_online.key  https://<URL of website>
>
> То подключение успешное - "HTTP request sent, awaiting response... 200 OK"
>
> Но нам нужно на этом сервере настроить nginx, чтобы мы со своих компьютеров
> открывали в браузере IP нашего сервера и попадали на сервер подрядчика
>
> Как настроить NGINX, чтобы он делал bind_adress и передавал для авторизации
> сертификат и ключ по аналогии с wget?
>
> Пробовал использовать следующее, но не помогает
>
>     proxy_bind XX.XX.XX.XX;
>     proxy_pass https://<URL of website>;
>     proxy_ssl_certificate /etc/nginx/ssl/private_online.pem;
>     proxy_ssl_certificate_key /etc/nginx/ssl/private_online_key.pem;
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,279454,279454#msg-279454
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180416/6cfc4599/attachment.html>

From nginx-forum на forum.nginx.org  Mon Apr 16 17:50:12 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 16 Apr 2018 13:50:12 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <20180409143618.GB77253@mdounin.ru>
References: <20180409143618.GB77253@mdounin.ru>
Message-ID: <158adc4f26a2956900f11824afbad266.NginxMailingListRussian@forum.nginx.org>

Коллеги, каковы дальнейшие действия, чтобы исправить причину ошибки?
От меня требуется пример конфигурации или лога достаточно для выявления
причины перезаписи файла кэша основного запроса из подзапроса?

Всё корректно работает при схеме request → SSI subrequest, но ломается при
background subrequest → SSI subrequest.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279463#msg-279463


From mdounin на mdounin.ru  Mon Apr 16 18:54:41 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 16 Apr 2018 21:54:41 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <158adc4f26a2956900f11824afbad266.NginxMailingListRussian@forum.nginx.org>
References: <20180409143618.GB77253@mdounin.ru>
 <158adc4f26a2956900f11824afbad266.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180416185441.GZ77253@mdounin.ru>

Hello!

On Mon, Apr 16, 2018 at 01:50:12PM -0400, gz wrote:

> Коллеги, каковы дальнейшие действия, чтобы исправить причину ошибки?
> От меня требуется пример конфигурации или лога достаточно для выявления
> причины перезаписи файла кэша основного запроса из подзапроса?
> 
> Всё корректно работает при схеме request → SSI subrequest, но ломается при
> background subrequest → SSI subrequest.

Наиболее вероятную причину я озвучил тут:

http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html

Если предположение верно, то исправлять нужно конфигурацию.

(А, ну и судя по всему форум опять промотал письмо.  Не 
пользуйтесь им, мы не просто так выпилили на него ссылки с 
nginx.org.)

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Mon Apr 16 19:17:36 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 16 Apr 2018 15:17:36 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <20180416185441.GZ77253@mdounin.ru>
References: <20180416185441.GZ77253@mdounin.ru>
Message-ID: <553911e4afa4776e802d6a3a060ab8c9.NginxMailingListRussian@forum.nginx.org>

> Наиболее вероятную причину я озвучил тут:
> http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html
> Если предположение верно, то исправлять нужно конфигурацию.

Я спустя двадцать минут ответил —
https://forum.nginx.org/read.php?21,279356,279365#msg-279365
Не думаю, что дело в переменных $handler и $querystring они в ключе
кэширования не используются.

В ключе кэширования используется $uri, который, как известно, в
SSI-подзапросе не равен $request_uri, а указывает на URI подзапроса.
И пока дело не доходит до фонового обновления кэша всё в порядке.

Но, перезапись происходит ещё и в другой cache_path!
Основной запрос использует путь /cache/pages/, а SSI-подзапрос использует
путь /cache/banners/.
И последний умудряется перезаписать файл первого.

Думаю, что это всё же ошибка в nginx, а не в моей конфигурации.

> (А, ну и судя по всему форум опять промотал письмо. Не пользуйтесь им, мы
не просто так выпилили на него ссылки с nginx.org.)

К сожалению, иными способами пользоваться этим форумом я не умею.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279465#msg-279465


From mdounin на mdounin.ru  Mon Apr 16 20:35:26 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 16 Apr 2018 23:35:26 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <553911e4afa4776e802d6a3a060ab8c9.NginxMailingListRussian@forum.nginx.org>
References: <20180416185441.GZ77253@mdounin.ru>
 <553911e4afa4776e802d6a3a060ab8c9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180416203525.GA77253@mdounin.ru>

Hello!

On Mon, Apr 16, 2018 at 03:17:36PM -0400, gz wrote:

> > Наиболее вероятную причину я озвучил тут:
> > http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html
> > Если предположение верно, то исправлять нужно конфигурацию.
> 
> Я спустя двадцать минут ответил —
> https://forum.nginx.org/read.php?21,279356,279365#msg-279365

А, то есть форум промотал не мой ответ, а ответ на него.
Разница, впрочем, небольшая.

> Не думаю, что дело в переменных $handler и $querystring они в ключе
> кэширования не используются.

Вопрос не в том, что используется в ключе кэширования, а в том, 
что отправляется на бэкенд.  И на бэкенд у вас при перезаписи как 
раз отправляется $handler, установленный в другом подзапросе:

2018/04/09 21:29:34 [debug] 16867#16867: *1901 fastcgi param: "PATH_TRANSLATED: /var/www/site/www/banner.html"

Бэкенд возвращает пустой ответ, и этот ответ попадает в кэш.  То 
есть всё ровно так, как я и предполагал.  Нужно исправлять 
конфигурацию так, чтобы запрос на бэкенд не использовал 
переменных, которые могут быть переписаны другими подзапросами.

[...]

> > (А, ну и судя по всему форум опять промотал письмо. Не пользуйтесь им, мы
> не просто так выпилили на него ссылки с nginx.org.)
> 
> К сожалению, иными способами пользоваться этим форумом я не умею.

Вы пишите в список рассылки.  Пишете в него напрямую, не надо для 
это пользоваться горе-поделками любителей форумов.  Подписаться 
можно тут:

http://nginx.org/ru/support.html

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Mon Apr 16 20:52:20 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 16 Apr 2018 16:52:20 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <20180416203525.GA77253@mdounin.ru>
References: <20180416203525.GA77253@mdounin.ru>
Message-ID: <3761fe5a541cb207b6077b580c72d564.NginxMailingListRussian@forum.nginx.org>

> Вопрос не в том, что используется в ключе кэширования, а в том, 
> что отправляется на бэкенд. И на бэкенд у вас при перезаписи как 
> раз отправляется $handler, установленный в другом подзапросе:

> 2018/04/09 21:29:34 [debug] 16867#16867: *1901 fastcgi param:
"PATH_TRANSLATED: /var/www/site/www/banner.html"

Не совсем понимаю как результат работы подзапроса, пусть и с перезаписанными
переменными окружения, может быть помещён в кэш основного запроса.
Если кэши запроса и подзапроса разные (разные cache_path) да к тому же
используют разные ключи кэширования.
То есть, подзапрос баннера вдруг перезаписывает ответ всей страницы.

То, куда попадёт ответ подзапроса зависит от PATH_TRANSLATED?

> Бэкенд возвращает пустой ответ, и этот ответ попадает в кэш. То 
> есть всё ровно так, как я и предполагал. Нужно исправлять 
> конфигурацию так, чтобы запрос на бэкенд не использовал 
> переменных, которые могут быть переписаны другими подзапросами.

Не уверен, что это возможно.
FCGI-приложение требует этих переменных для своей работы.

> Вы пишите в список рассылки.

Ясно, изучу.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279467#msg-279467


From nginx-forum на forum.nginx.org  Mon Apr 16 21:53:56 2018
From: nginx-forum на forum.nginx.org (dim1)
Date: Mon, 16 Apr 2018 17:53:56 -0400
Subject: =?UTF-8?B?0J7QsdGA0LDQsdC+0YLQutCwIDQwNCDQvtGI0LjQsdC+0Log0L3QsCBwZXJsINC4?=
 =?UTF-8?B?IDMwMSDRgNC10LTQuNGA0LXQutGC?=
Message-ID: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>

Проект часто цитируют со ссылкой и иногда обрезают часть URL. В большинстве
случаев можно восстановить полный URL из его части и сделать редирект на
правильную страницу. 


error_page 404 @404e;
fastcgi_intercept_errors on; # указал уже дважды
#error_page 404 /cgi-bin/re.pl?in=$uri; #пробовал и так

 @404e{
                        fastcgi_intercept_errors on;
                        rewrite . /cgi-bin/re.pl?in=$uri last;
                        proxy_pass http://7.7.7.7:8080;
                        proxy_redirect http://domen.com:8080/ /;
                        proxy_set_header Host $host;
                        proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
                        proxy_set_header X-Real-IP $remote_addr;
                        include fastcgi_params;
                        internal;

}

НЕ ХОЧЕТ со скрипта передавать 301 заголовок. 

_

При отдаче скриптом:
print "HTTP/1.1 301 Moved Permanently\n";
print "Location: http://url.ru\n\n";

получаю:
HTTP/1.1 404 Not Found
Server: nginx
...

При:
print "Status: 301 Moved Permanently\n";
print "Location: http://url.ru\n\n";

HTTP/1.1 404 Not Found
Server: nginx
...
Location:	http://url.ru/

_

## nginx version: nginx/1.8.0

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279469,279469#msg-279469


From nginx-forum на forum.nginx.org  Mon Apr 16 22:36:53 2018
From: nginx-forum на forum.nginx.org (Edward Gaba)
Date: Mon, 16 Apr 2018 18:36:53 -0400
Subject: =?UTF-8?B?UmU6INCe0YLQstC10YIg0L/QviDQuNC80LXQvdC4INC4INC/0L7RgNGC0YMg0L0=?=
 =?UTF-8?B?0LUg0YPQutCw0LfQsNC90L3QvtC80YMg0LIgc2VydmVy?=
In-Reply-To: <e549b3388f8b2205c186f21170d5d485@kopeyko.ru>
References: <e549b3388f8b2205c186f21170d5d485@kopeyko.ru>
Message-ID: <1ced1d0eed784c92afecfe288d51bd56.NginxMailingListRussian@forum.nginx.org>

Andrey, не подозревал о таком поведении.
Действительно, первый описанный в конфиге сертификат и отдается для всех не
сконфигурированных TLS.
Переведу все на SSL.
Спасибо!

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279446,279470#msg-279470


From nginx-ru на sadok.spb.ru  Tue Apr 17 07:40:47 2018
From: nginx-ru на sadok.spb.ru (Dmitry Ivanov)
Date: Tue, 17 Apr 2018 10:40:47 +0300
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCA0MDQg0L7RiNC40LHQvtC6INC90LAgcGVy?=
 =?UTF-8?B?bCDQuCAzMDEg0YDQtdC00LjRgNC10LrRgg==?=
In-Reply-To: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
References: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
Message-ID: <191874587.20180417104047@sadok.spb.ru>

Здравствуйте, dim1.

Вы писали 17 апреля 2018 г., 0:53:56:

> НЕ ХОЧЕТ со скрипта передавать 301 заголовок.

> При отдаче скриптом:
> print "HTTP/1.1 301 Moved Permanently\n";
> print "Location: http://url.ru\n\n";

А разве не "\r\n" и соответственно "\r\n\r\n" надо?


-- 
С уважением,
 Dmitry                       nginx-ru на sadok.spb.ru


From nginx-forum на forum.nginx.org  Tue Apr 17 09:50:58 2018
From: nginx-forum на forum.nginx.org (dim1)
Date: Tue, 17 Apr 2018 05:50:58 -0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCA0MDQg0L7RiNC40LHQvtC6INC90LAgcGVy?=
 =?UTF-8?B?bCDQuCAzMDEg0YDQtdC00LjRgNC10LrRgg==?=
In-Reply-To: <191874587.20180417104047@sadok.spb.ru>
References: <191874587.20180417104047@sadok.spb.ru>
Message-ID: <64828571e1f404e04d1c88f228ede9de.NginxMailingListRussian@forum.nginx.org>

"А разве не "\r\n" и соответственно "\r\n\r\n" надо?"
Пробовал и с \r\n - ничего не изменилось.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279469,279475#msg-279475


From nginx-forum на forum.nginx.org  Tue Apr 17 10:35:35 2018
From: nginx-forum на forum.nginx.org (dim1)
Date: Tue, 17 Apr 2018 06:35:35 -0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCA0MDQg0L7RiNC40LHQvtC6INC90LAgcGVy?=
 =?UTF-8?B?bCDQuCAzMDEg0YDQtdC00LjRgNC10LrRgg==?=
In-Reply-To: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
References: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
Message-ID: <f191756170730fcefab0bebd46e530bb.NginxMailingListRussian@forum.nginx.org>

Если задать вместо error_page 404 @404e; :
error_page 404 = @404e; 

301 редирект обрабатывает нормально. Но, вместо 404 отдает 200.

  print "Status: 404 Not Found\n";
  print "Content-Type: text/html\n\n";
  print "Error 404";

Отдает:
HTTP/1.1 200 OK
...
Status: 404 Not Found

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279469,279476#msg-279476


From nginx-forum на forum.nginx.org  Tue Apr 17 10:45:13 2018
From: nginx-forum на forum.nginx.org (dim1)
Date: Tue, 17 Apr 2018 06:45:13 -0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCA0MDQg0L7RiNC40LHQvtC6INC90LAgcGVy?=
 =?UTF-8?B?bCDQuCAzMDEg0YDQtdC00LjRgNC10LrRgg==?=
In-Reply-To: <f191756170730fcefab0bebd46e530bb.NginxMailingListRussian@forum.nginx.org>
References: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
 <f191756170730fcefab0bebd46e530bb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7198021d596bdebbf6d091e785d5fca4.NginxMailingListRussian@forum.nginx.org>

Разобрался. 

Новая проблема:
Если скриптом отдавать 404 ошибку и содержимое фала 404 ошибки - содержимое
не выводится. 
Просто отдает "404 Not Found nginx"

Как отдать свою 404 (со своим файлом), после обработки error_page 404 =
@404e?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279469,279477#msg-279477


From nginx-forum на forum.nginx.org  Tue Apr 17 11:01:19 2018
From: nginx-forum на forum.nginx.org (dim1)
Date: Tue, 17 Apr 2018 07:01:19 -0400
Subject: =?UTF-8?B?0KDQsNCx0L7Rh9C40Lkg0LLQsNGA0LjQsNC90YI=?=
In-Reply-To: <7198021d596bdebbf6d091e785d5fca4.NginxMailingListRussian@forum.nginx.org>
References: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
 <f191756170730fcefab0bebd46e530bb.NginxMailingListRussian@forum.nginx.org>
 <7198021d596bdebbf6d091e785d5fca4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <a831c55aa23365905c1613514c148a37.NginxMailingListRussian@forum.nginx.org>

Последнее - была моя ошибка.

Рабочий код обработчика 404 ошибок (скрипт - части ошибок отдает 301,
остальным 404 и свою 404 страницу из файла).

error_page 404 = @404e; # изменился только один знак: =

@404e{ 
rewrite . /cgi-bin/re.pl?in=$uri last; 
proxy_pass http://7.7.7.7:8080; 
proxy_redirect http://domen.com:8080/ /; 
proxy_set_header Host $host; 
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
proxy_set_header X-Real-IP $remote_addr; 
include fastcgi_params; 
internal; 
} 

# fastcgi_intercept_errors on - не нужен.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279469,279478#msg-279478


From mdounin на mdounin.ru  Tue Apr 17 12:37:59 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 17 Apr 2018 15:37:59 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <3761fe5a541cb207b6077b580c72d564.NginxMailingListRussian@forum.nginx.org>
References: <20180416203525.GA77253@mdounin.ru>
 <3761fe5a541cb207b6077b580c72d564.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180417123759.GB77253@mdounin.ru>

Hello!

On Mon, Apr 16, 2018 at 04:52:20PM -0400, gz wrote:

> > Вопрос не в том, что используется в ключе кэширования, а в том, 
> > что отправляется на бэкенд. И на бэкенд у вас при перезаписи как 
> > раз отправляется $handler, установленный в другом подзапросе:
> 
> > 2018/04/09 21:29:34 [debug] 16867#16867: *1901 fastcgi param:
> "PATH_TRANSLATED: /var/www/site/www/banner.html"
> 
> Не совсем понимаю как результат работы подзапроса, пусть и с перезаписанными
> переменными окружения, может быть помещён в кэш основного запроса.
> Если кэши запроса и подзапроса разные (разные cache_path) да к тому же
> используют разные ключи кэширования.
> То есть, подзапрос баннера вдруг перезаписывает ответ всей страницы.

Это не подзапрос баннера.  Это подзапрос 
fastcgi_cache_background_update.  Но в нём используются те же 
переменные, что уже перезаписаны подзапросом баннера, и в 
результате на бэкенд уходит неправильное значение переменной 
PATH_TRANSLATED.  И бэкенд, в свою очередь, отвечает на него в 
соответствии с этим неправильным значением.

> То, куда попадёт ответ подзапроса зависит от PATH_TRANSLATED?

Нет.  Он неё зависит, что у вас отвечает бэкенд.

> > Бэкенд возвращает пустой ответ, и этот ответ попадает в кэш. То 
> > есть всё ровно так, как я и предполагал. Нужно исправлять 
> > конфигурацию так, чтобы запрос на бэкенд не использовал 
> > переменных, которые могут быть переписаны другими подзапросами.
> 
> Не уверен, что это возможно.
> FCGI-приложение требует этих переменных для своей работы.

Наиболее простое решение - использовать отдельный location для 
баннеров с отдельными же переменными.  Наиболее правильное - 
переписать логику так, чтобы нужные бэкенду значения вычислялись 
не с помощью set, а с помощью map { volatile; ... }.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Tue Apr 17 15:41:23 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 17 Apr 2018 18:41:23 +0300
Subject: nginx-1.14.0
Message-ID: <20180417154123.GG77253@mdounin.ru>

Изменения в nginx 1.14.0                                          17.04.2018

    *) Стабильная ветка 1.14.x.


-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Tue Apr 17 16:17:29 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Tue, 17 Apr 2018 12:17:29 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <20180417123759.GB77253@mdounin.ru>
References: <20180417123759.GB77253@mdounin.ru>
Message-ID: <a5fdfcbcd1a6e1370dfe5b31f6a39504.NginxMailingListRussian@forum.nginx.org>

> Это не подзапрос баннера. Это подзапрос 
> fastcgi_cache_background_update. Но в нём используются те же 
> переменные, что уже перезаписаны подзапросом баннера, и в 
> результате на бэкенд уходит неправильное значение переменной 
> PATH_TRANSLATED. И бэкенд, в свою очередь, отвечает на него в 
> соответствии с этим неправильным значением.

Вот теперь, кажется, понимаю.
Фоновый подзапрос обновления всей страницы получает переопределённые
переменные окружения и вместо генерации страницы генерирует пустой баннер,
который сохраняется в кэш.

> Наиболее простое решение - использовать отдельный location для 
> баннеров с отдельными же переменными.

Так и сделано
(https://forum.nginx.org/read.php?21,279356,279363#msg-279363):
location /banner/ { 
internal; 

fastcgi_cache banner; 
fastcgi_cache_valid 200 24h; 
fastcgi_cache_key '$uri$is_args$args'; 

set $handler banner.html; 
set $querystring $args; 

fastcgi_param REQUEST_URI $uri$is_args$args; 
fastcgi_param SCRIPT_NAME $uri$is_args$args; 
fastcgi_param PATH_INFO $uri$is_args$args; 

include parser; 
fastcgi_pass fcgiwrap; 
}

> Наиболее правильное - 
> переписать логику так, чтобы нужные бэкенду значения вычислялись 
> не с помощью set, а с помощью map { volatile; ... }.

Ясно, значения не будут кэшироваться и можно будет получить корректные
переменные окружения для каждого подзапроса.
Спасибо, попробую.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279490#msg-279490


From mdounin на mdounin.ru  Tue Apr 17 16:30:14 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 17 Apr 2018 19:30:14 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <a5fdfcbcd1a6e1370dfe5b31f6a39504.NginxMailingListRussian@forum.nginx.org>
References: <20180417123759.GB77253@mdounin.ru>
 <a5fdfcbcd1a6e1370dfe5b31f6a39504.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180417163014.GI77253@mdounin.ru>

Hello!

On Tue, Apr 17, 2018 at 12:17:29PM -0400, gz wrote:

> > Это не подзапрос баннера. Это подзапрос 
> > fastcgi_cache_background_update. Но в нём используются те же 
> > переменные, что уже перезаписаны подзапросом баннера, и в 
> > результате на бэкенд уходит неправильное значение переменной 
> > PATH_TRANSLATED. И бэкенд, в свою очередь, отвечает на него в 
> > соответствии с этим неправильным значением.
> 
> Вот теперь, кажется, понимаю.
> Фоновый подзапрос обновления всей страницы получает переопределённые
> переменные окружения и вместо генерации страницы генерирует пустой баннер,
> который сохраняется в кэш.
> 
> > Наиболее простое решение - использовать отдельный location для 
> > баннеров с отдельными же переменными.
> 
> Так и сделано
> (https://forum.nginx.org/read.php?21,279356,279363#msg-279363):
> location /banner/ { 
> internal; 
> 
> fastcgi_cache banner; 
> fastcgi_cache_valid 200 24h; 
> fastcgi_cache_key '$uri$is_args$args'; 
> 
> set $handler banner.html; 
> set $querystring $args; 

Обращаю внимание - выше написано _с_отдельными_переменными_.  Это 
важно.

Ну или вообще выкинуть переменные из конструкции, насколько я 
понимаю - они тут не нужны, достаточно соответствующие 
fastcgi_param задать явно.

-- 
Maxim Dounin
http://mdounin.ru/

From ksafonov на rutarget.ru  Tue Apr 17 17:29:13 2018
From: ksafonov на rutarget.ru (Kirill Safonov)
Date: Tue, 17 Apr 2018 20:29:13 +0300
Subject: =?UTF-8?B?0LfQtdGA0LrQsNC70LjRgNC+0LLQsNC90LjQtSAobWlycm9yKSDRh9Cw0YHRgtC4?=
 =?UTF-8?B?INGC0YDQsNGE0LjQutCw?=
Message-ID: <9DA8CA24-3745-4B6E-9A3D-FF59362B62CA@rutarget.ru>

Добрый день,

Есть nginx и fastcgi upstream из нескольких десятков серверов, используется consistent hash. Требуется, оставаясь в рамках nginx, дополнительно отправлять по fastcgi часть трафика (3-5%) на тестовые сервера (canary), ответы с них игнорировать. Желательно с тем же hash, который работает в основном трафике.

С помощью модуля mirror можно отправить копию всего трафика на другой локейшен, для которого можно объявить отдельный upstream, в нем указать тестовые сервера. Но непонятно, куда с минимальным overhead-ом отправить оставшиеся 95% трафика (ответы на который всё равно игнорируются). Поднимать рядом fastcgi-бекенд “пустышку” бы не хотелось.

Спасибо

From mdounin на mdounin.ru  Tue Apr 17 17:50:53 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 17 Apr 2018 20:50:53 +0300
Subject: =?UTF-8?B?UmU6INC30LXRgNC60LDQu9C40YDQvtCy0LDQvdC40LUgKG1pcnJvcikg0YfQsNGB?=
 =?UTF-8?B?0YLQuCDRgtGA0LDRhNC40LrQsA==?=
In-Reply-To: <9DA8CA24-3745-4B6E-9A3D-FF59362B62CA@rutarget.ru>
References: <9DA8CA24-3745-4B6E-9A3D-FF59362B62CA@rutarget.ru>
Message-ID: <20180417175053.GJ77253@mdounin.ru>

Hello!

On Tue, Apr 17, 2018 at 08:29:13PM +0300, Kirill Safonov wrote:

> Добрый день,
> 
> Есть nginx и fastcgi upstream из нескольких десятков серверов, 
> используется consistent hash. Требуется, оставаясь в рамках 
> nginx, дополнительно отправлять по fastcgi часть трафика (3-5%) 
> на тестовые сервера (canary), ответы с них игнорировать. 
> Желательно с тем же hash, который работает в основном трафике.
> 
> С помощью модуля mirror можно отправить копию всего трафика на 
> другой локейшен, для которого можно объявить отдельный upstream, 
> в нем указать тестовые сервера. Но непонятно, куда с минимальным 
> overhead-ом отправить оставшиеся 95% трафика (ответы на который 
> всё равно игнорируются). Поднимать рядом fastcgi-бекенд 
> “пустышку” бы не хотелось.

Проще всего воспользоваться split_clients и для остальных клиентов 
сделать return 204.  Подробнее тут:

http://nginx.org/ru/docs/http/ngx_http_split_clients_module.html

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Tue Apr 17 17:56:25 2018
From: nginx-forum на forum.nginx.org (Asterics)
Date: Tue, 17 Apr 2018 13:56:25 -0400
Subject: =?UTF-8?B?0L7RiNC40LHQutCwINC/0YDQuCDRgdCx0L7RgNC60LUgTmdpbngg0LIg0YDRg9GH?=
 =?UTF-8?B?0L3Rg9GO?=
Message-ID: <3fa12bc73a3af905371bf39ccd1804c7.NginxMailingListRussian@forum.nginx.org>

./configure \
        --prefix=/usr/share/nginx \
        --sbin-path=/usr/sbin/nginx \
        --conf-path=/etc/nginx/nginx.conf \
        --pid-path=/var/run/nginx.pid \
        --lock-path=/var/lock/nginx.lock \
        --error-log-path=/var/log/nginx/error.log \
        --http-log-path=/var/log/access/access.log \
        --user=www-data \
        --group=www-data \
        --with-http_ssl_module \
        --with-http_gzip_static_module \
        --with-ngx_http_gzip_module \
        --with-ngx_http_access_module \

исход
./configure: error: invalid option "--with-ngx_http_access_module"
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.

почему не правильная опция?
например если оставить только с ней, то все ок будет. Проблема именно в
        --with-http_gzip_static_module \
        --with-ngx_http_gzip_module \
        --with-ngx_http_access_module \

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279496,279496#msg-279496


From nginx-forum на forum.nginx.org  Tue Apr 17 18:00:38 2018
From: nginx-forum на forum.nginx.org (Asterics)
Date: Tue, 17 Apr 2018 14:00:38 -0400
Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCDQv9GA0Lgg0YHQsdC+0YDQutC1IE5naW54INCyINGA?=
 =?UTF-8?B?0YPRh9C90YPRjg==?=
In-Reply-To: <3fa12bc73a3af905371bf39ccd1804c7.NginxMailingListRussian@forum.nginx.org>
References: <3fa12bc73a3af905371bf39ccd1804c7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e089e4a9e4a137c2bddee12ce6dc3d93.NginxMailingListRussian@forum.nginx.org>

забыл написать centos7

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279496,279497#msg-279497


From mdounin на mdounin.ru  Tue Apr 17 18:01:31 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 17 Apr 2018 21:01:31 +0300
Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCDQv9GA0Lgg0YHQsdC+0YDQutC1IE5naW54INCyINGA?=
 =?UTF-8?B?0YPRh9C90YPRjg==?=
In-Reply-To: <3fa12bc73a3af905371bf39ccd1804c7.NginxMailingListRussian@forum.nginx.org>
References: <3fa12bc73a3af905371bf39ccd1804c7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180417180131.GK77253@mdounin.ru>

Hello!

On Tue, Apr 17, 2018 at 01:56:25PM -0400, Asterics wrote:

> ./configure \
>         --prefix=/usr/share/nginx \
>         --sbin-path=/usr/sbin/nginx \
>         --conf-path=/etc/nginx/nginx.conf \
>         --pid-path=/var/run/nginx.pid \
>         --lock-path=/var/lock/nginx.lock \
>         --error-log-path=/var/log/nginx/error.log \
>         --http-log-path=/var/log/access/access.log \
>         --user=www-data \
>         --group=www-data \
>         --with-http_ssl_module \
>         --with-http_gzip_static_module \
>         --with-ngx_http_gzip_module \
>         --with-ngx_http_access_module \
> 
> исход
> ./configure: error: invalid option "--with-ngx_http_access_module"
> make: *** No targets specified and no makefile found.  Stop.
> make: *** No rule to make target `install'.  Stop.
> 
> почему не правильная опция?
> например если оставить только с ней, то все ок будет. Проблема именно в
>         --with-http_gzip_static_module \
>         --with-ngx_http_gzip_module \
>         --with-ngx_http_access_module \

Такой опции нет, модуль ngx_http_access_module собирается 
по умолчанию и его сборку можно только выключить с помощью 
опции --without-ngx_http_access_module.

$ ./configure --help | grep http_access
  --without-http_access_module       disable ngx_http_access_module

-- 
Maxim Dounin
http://mdounin.ru/

From vovansystems на gmail.com  Tue Apr 17 18:26:14 2018
From: vovansystems на gmail.com (VovansystemS)
Date: Tue, 17 Apr 2018 21:26:14 +0300
Subject: =?UTF-8?B?bmdpblNjcmlwdCDRh9GC0L7QsdGLINC/0L7RgdGH0LjRgtCw0YLRjCDQutC+0Ls=?=
 =?UTF-8?B?0LjRh9C10YHRgtCy0L4g0LfQsNC/0YDQvtGB0L7QsiDRgSBpcA==?=
Message-ID: <CAAwq3jwsOYcaxr79xUt+KFjuF8LemR6XC_yWAiDNTJPZ3isc2Q@mail.gmail.com>

Добрый день,

нужно посчитать количество запросов для каждого IP адреса. сейчас мы
это делаем логгируя в файл IP адрес клиента для каждого запроса и
потом считая уникальные вхождения, но это какой-то странный способ
получения этой метрики.

возможно ли использовать nginScript для этой цели создав ассоциативный
массив (kv) из айпишников и количеств запросов к ним, отдавая потом
его в каком-то локейшне?

или может быть есть более правильные способы собирать кастумные
метрики без нагромождений сторонних модулей разного качества?

From nginx-forum на forum.nginx.org  Tue Apr 17 19:12:35 2018
From: nginx-forum на forum.nginx.org (Asterics)
Date: Tue, 17 Apr 2018 15:12:35 -0400
Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCDQv9GA0Lgg0YHQsdC+0YDQutC1IE5naW54INCyINGA?=
 =?UTF-8?B?0YPRh9C90YPRjg==?=
In-Reply-To: <20180417180131.GK77253@mdounin.ru>
References: <20180417180131.GK77253@mdounin.ru>
Message-ID: <311aa0f58b87a5a646229f79dea38fb4.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin	 спасибо, да допер ... спустя 4 часа :)

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279496,279501#msg-279501


From nginx-forum на forum.nginx.org  Tue Apr 17 23:49:53 2018
From: nginx-forum на forum.nginx.org (dim1)
Date: Tue, 17 Apr 2018 19:49:53 -0400
Subject: =?UTF-8?B?0J/RgNC+0LHQtdC7INCyIFVSSSAt0KLQldCg0K/QldCi0KHQryDQstGB0LUsINGH?=
 =?UTF-8?B?0YLQviDQv9C+0YHQu9C1INC/0YDQvtCx0LXQu9Cw?=
In-Reply-To: <a831c55aa23365905c1613514c148a37.NginxMailingListRussian@forum.nginx.org>
References: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
 <f191756170730fcefab0bebd46e530bb.NginxMailingListRussian@forum.nginx.org>
 <7198021d596bdebbf6d091e785d5fca4.NginxMailingListRussian@forum.nginx.org>
 <a831c55aa23365905c1613514c148a37.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2764c7fc585f9861f7f8cee911c48b4b.NginxMailingListRussian@forum.nginx.org>

rewrite . /cgi-bin/re.pl?in=$uri last; 

При подстановке в $uri урл с пробелом http://domen.ru/sub/dir/%20word -
теряется %20word.

Проверил окружение скрипта, реально теряется:
REQUEST_URI = /cgi-bin/re.pl?in=/sub/dir/

Возможно ли это исправить?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279469,279507#msg-279507


From alex на vorona.com.ua  Wed Apr 18 06:47:45 2018
From: alex на vorona.com.ua (Alex Vorona)
Date: Wed, 18 Apr 2018 09:47:45 +0300
Subject: =?UTF-8?B?0JvQvtCz0LjRgNC+0LLQsNC90LjQtSDQuNGB0YXQvtC00Y/RidC10LPQviDQv9C+?=
 =?UTF-8?B?0YDRgtCwINC00LvRjyAqX3Bhc3M=?=
Message-ID: <0bcd143e-9d06-abab-a14e-5522663a867b@vorona.com.ua>

Здравствуйте,

Хочется логировать иcходящий ip:port, который используется при 
подключении nginx к бекенду при использовании *_pass директив и который 
можно жестко задать например через proxy_bind. Не нашёл в документации 
подходящих переменных. Это осуществимо?

--
Alex Vorona

From nginx-forum на forum.nginx.org  Wed Apr 18 10:04:25 2018
From: nginx-forum на forum.nginx.org (dim1)
Date: Wed, 18 Apr 2018 06:04:25 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LXQuyDQsiBVUkkgLdCi0JXQoNCv0JXQotCh0K8g0LLRgdC1?=
 =?UTF-8?B?LCDRh9GC0L4g0L/QvtGB0LvQtSDQv9GA0L7QsdC10LvQsA==?=
In-Reply-To: <2764c7fc585f9861f7f8cee911c48b4b.NginxMailingListRussian@forum.nginx.org>
References: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
 <f191756170730fcefab0bebd46e530bb.NginxMailingListRussian@forum.nginx.org>
 <7198021d596bdebbf6d091e785d5fca4.NginxMailingListRussian@forum.nginx.org>
 <a831c55aa23365905c1613514c148a37.NginxMailingListRussian@forum.nginx.org>
 <2764c7fc585f9861f7f8cee911c48b4b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <dc4f46ecd1de983f90c0cfb3cc663b03.NginxMailingListRussian@forum.nginx.org>

Еще нашел: 
остаток строки (после пробела) из урл находится в переменной окружения =
$ENV{SERVER_PROTOCOL}

SERVER_PROTOCOL = word HTTP/1.0

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279469,279514#msg-279514


From nginx-forum на forum.nginx.org  Wed Apr 18 11:13:57 2018
From: nginx-forum на forum.nginx.org (dim1)
Date: Wed, 18 Apr 2018 07:13:57 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LXQuyDQsiBVUkkgLdCi0JXQoNCv0JXQotCh0K8g0LLRgdC1?=
 =?UTF-8?B?LCDRh9GC0L4g0L/QvtGB0LvQtSDQv9GA0L7QsdC10LvQsA==?=
In-Reply-To: <dc4f46ecd1de983f90c0cfb3cc663b03.NginxMailingListRussian@forum.nginx.org>
References: <6e4dfc58d08b30506e7d39c378c97a59.NginxMailingListRussian@forum.nginx.org>
 <f191756170730fcefab0bebd46e530bb.NginxMailingListRussian@forum.nginx.org>
 <7198021d596bdebbf6d091e785d5fca4.NginxMailingListRussian@forum.nginx.org>
 <a831c55aa23365905c1613514c148a37.NginxMailingListRussian@forum.nginx.org>
 <2764c7fc585f9861f7f8cee911c48b4b.NginxMailingListRussian@forum.nginx.org>
 <dc4f46ecd1de983f90c0cfb3cc663b03.NginxMailingListRussian@forum.nginx.org>
Message-ID: <44025a3c3c3f4e2d199894f32e10a350.NginxMailingListRussian@forum.nginx.org>

Поборол, используя $request_uri вместо $uri

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279469,279515#msg-279515


From mdounin на mdounin.ru  Wed Apr 18 12:30:11 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 18 Apr 2018 15:30:11 +0300
Subject: =?UTF-8?B?UmU6INCb0L7Qs9C40YDQvtCy0LDQvdC40LUg0LjRgdGF0L7QtNGP0YnQtdCz0L4g?=
 =?UTF-8?B?0L/QvtGA0YLQsCDQtNC70Y8gKl9wYXNz?=
In-Reply-To: <0bcd143e-9d06-abab-a14e-5522663a867b@vorona.com.ua>
References: <0bcd143e-9d06-abab-a14e-5522663a867b@vorona.com.ua>
Message-ID: <20180418123011.GL77253@mdounin.ru>

Hello!

On Wed, Apr 18, 2018 at 09:47:45AM +0300, Alex Vorona wrote:

> Хочется логировать иcходящий ip:port, который используется при 
> подключении nginx к бекенду при использовании *_pass директив и который 
> можно жестко задать например через proxy_bind. Не нашёл в документации 
> подходящих переменных. Это осуществимо?

Нет, сейчас таких переменных нет.

-- 
Maxim Dounin
http://mdounin.ru/

From xeioex на nginx.com  Wed Apr 18 15:11:43 2018
From: xeioex на nginx.com (Dmitry Volyntsev)
Date: Wed, 18 Apr 2018 18:11:43 +0300
Subject: =?UTF-8?B?UmU6IG5naW5TY3JpcHQg0YfRgtC+0LHRiyDQv9C+0YHRh9C40YLQsNGC0Ywg0Lo=?=
 =?UTF-8?B?0L7Qu9C40YfQtdGB0YLQstC+INC30LDQv9GA0L7RgdC+0LIg0YEgaXA=?=
In-Reply-To: <CAAwq3jwsOYcaxr79xUt+KFjuF8LemR6XC_yWAiDNTJPZ3isc2Q@mail.gmail.com>
References: <CAAwq3jwsOYcaxr79xUt+KFjuF8LemR6XC_yWAiDNTJPZ3isc2Q@mail.gmail.com>
Message-ID: <a17e0f98-d173-2446-5fdb-fd3fa6252626@nginx.com>



On 17.04.2018 21:26, VovansystemS wrote:
> Добрый день,
> возможно ли использовать nginScript для этой цели создав ассоциативный
> массив (kv) из айпишников и количеств запросов к ним, отдавая потом
> его в каком-то локейшне?
 > ...


В текущей реализации время жизни njs объектов это время жизни объекта 
запроса, поэтому сбор статистики организовать таким образом не получится.

В данный момент работа по добавлению в njs функциональности по 
взаимодействию с персистентным хранилищем в разделяемой памяти находится 
в стадии R&D.


From vovansystems на gmail.com  Wed Apr 18 16:08:18 2018
From: vovansystems на gmail.com (VovansystemS)
Date: Wed, 18 Apr 2018 19:08:18 +0300
Subject: =?UTF-8?B?UmU6IG5naW5TY3JpcHQg0YfRgtC+0LHRiyDQv9C+0YHRh9C40YLQsNGC0Ywg0Lo=?=
 =?UTF-8?B?0L7Qu9C40YfQtdGB0YLQstC+INC30LDQv9GA0L7RgdC+0LIg0YEgaXA=?=
In-Reply-To: <a17e0f98-d173-2446-5fdb-fd3fa6252626@nginx.com>
References: <CAAwq3jwsOYcaxr79xUt+KFjuF8LemR6XC_yWAiDNTJPZ3isc2Q@mail.gmail.com>
 <a17e0f98-d173-2446-5fdb-fd3fa6252626@nginx.com>
Message-ID: <CAAwq3jyMX19QFsiSM3z9cfOFNP9x7ufJC0rwKeXNBhfm_fsL4Q@mail.gmail.com>

> В текущей реализации время жизни njs объектов это время жизни объекта
> запроса, поэтому сбор статистики организовать таким образом не получится.

хорошо, значит я правильно понял документацию

> В данный момент работа по добавлению в njs функциональности по
> взаимодействию с персистентным хранилищем в разделяемой памяти находится в
> стадии R&D.

спасибо за ответ! буду следить за обновлениями

From nginx-forum на forum.nginx.org  Wed Apr 18 19:20:11 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Wed, 18 Apr 2018 15:20:11 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90YvQuSDQvtGC0LLQtdGCINC/0YDQuCA=?=
 =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggZmFzdGNnaSBjYWNoZSBiYWNr?=
 =?UTF-8?B?Z3JvdW5kIHVwZGF0ZSBvbg==?=
In-Reply-To: <20180417163014.GI77253@mdounin.ru>
References: <20180417163014.GI77253@mdounin.ru>
Message-ID: <14c68e268f8bfe74819151f42d8cddd4.NginxMailingListRussian@forum.nginx.org>

> Обращаю внимание - выше написано _с_отдельными_переменными_. Это важно.

> Ну или вообще выкинуть переменные из конструкции, насколько я 
> понимаю - они тут не нужны, достаточно соответствующие 
> fastcgi_param задать явно.

Ясно.
С переменными удобно включать один файл, конструкции установки переменных
окружения получаются компактнее.

Про кэширование значений map без volatile знал, а вот о возможном
кэширование rewrite-переменных не задумывался.

Переделал на прямую установку fastcgi_param, пока перезапись не
повторяется.
Буду наблюдать.

Благодарю за помощь!

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279527#msg-279527


From nginx-forum на forum.nginx.org  Wed Apr 18 21:36:24 2018
From: nginx-forum на forum.nginx.org (tresor.fk)
Date: Wed, 18 Apr 2018 17:36:24 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IHNzbCDRgdC10YDRgtC40YQ=?=
 =?UTF-8?B?0LjQutCw0YLQsCDQuCDQutC70Y7Rh9Cw?=
In-Reply-To: <CAOrB69NkxyrB25ORXKPf83X-L3wGS+obd--p9sU+k7zh0hSSJw@mail.gmail.com>
References: <CAOrB69NkxyrB25ORXKPf83X-L3wGS+obd--p9sU+k7zh0hSSJw@mail.gmail.com>
Message-ID: <a486447722fa6d69949d4023bbb662d5.NginxMailingListRussian@forum.nginx.org>

Пробовал этот метод, но есть нюанс. У меня проксирование должно идти на
четкий URL - https://website.com

а в параметрах stream нужно бекенд указывать в формате host:port

stream {
    # ...
    server {
        listen     <Secondary IP>:443;
        proxy_pass website.com:443;
        proxy_bind <Secondary IP>:443;
    }
}

Но если открывать website.com:443 -это не работает, так как видно на стороне
подрядчика вебсервер так не принимает запрос

Также в логах пишет следующее

bind(<Secondary IP>:443) failed (98: Address already in use) while
connecting to upstream, client: backendIP, server: 0.0.0.0:443, upstream:
"backendIP:443", bytes from/to client:0/0, bytes from/to upstream:0/0

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279454,279530#msg-279530


From nginx-forum на forum.nginx.org  Fri Apr 20 14:29:39 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Fri, 20 Apr 2018 10:29:39 -0400
Subject: =?UTF-8?B?0JjRgdGF0L7QtNC90LjQutC4LCDRhNCw0LnQuyBuZ2lueC5pbml0Lmlu?=
Message-ID: <102f6710b2a20e9cbf8894f5a8bda2d6.NginxMailingListRussian@forum.nginx.org>

Здравствуйте.
Собирают nginx в докере из исходников и столкнулся с непониманием.
Есть файл ./nginx-1.xx/debian/nginx.init.in в нём задаются переменные:

DESC=${DESC:-%%PROVIDES%%}
NAME=${NAME:-%%PROVIDES%%}
DAEMON=${DAEMON:-/usr/sbin/%%PROVIDES%%}
..
Так вот вопрос, что за %%PROVIDES%% такой и откуда он берётся?
Если ставить через apt-get install nginx и смотреть скрипт в
/etc/init.d/nginx , то %%PROVIDES%% является nginx, т.е.
DESC=${DESC:-nginx}

Когда конфигурирую и собираю nginx, скрипт не падает в папку /etc/init.d/ и
я его копирую соответственно

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279542,279542#msg-279542


From fe на hamilton.rinet.ru  Sun Apr 22 15:12:37 2018
From: fe на hamilton.rinet.ru (Fedor Dikarev)
Date: Sun, 22 Apr 2018 18:12:37 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IHNzbCDRgdC10YDRgtC40YQ=?=
 =?UTF-8?B?0LjQutCw0YLQsCDQuCDQutC70Y7Rh9Cw?=
In-Reply-To: <3448a931b968a64923874e8eaa3f94d5.NginxMailingListRussian@forum.nginx.org>
References: <3448a931b968a64923874e8eaa3f94d5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <b75f9d8f-9a1b-b1c9-be48-c00ae8b7dd94@hamilton.rinet.ru>

Попробуйте добавить `proxy_ssl_server_name on;`
Можно еще повыставлять значения в `proxy_ssl_name` и `proxy_set_header
Host` если просто с `proxy_ssl_server_name on` не сработает.

16.04.18 14:25, tresor.fk пишет:
> Помогите разобраться со следующей ситуацией:
> 
> Есть веб сервер подрядчика, доступ к которому осуществляется по выделенному
> каналу и при указании сертификата и приватного ключа
> 
> То есть у нас есть линуксовый сервер, с которого мы инициализируем
> подключение. Для этого на нем настроен дополнительный сетевой интерфейс.
> 
> Например если запустить:
> 
> wget --bind-address=<Secondary IP>
> --certificate=/etc/nginx/ssl/private_online.crt
> --private-key=/etc/nginx/ssl/private_online.key  https://<URL of website>
> 
> То подключение успешное - "HTTP request sent, awaiting response... 200 OK"
> 
> Но нам нужно на этом сервере настроить nginx, чтобы мы со своих компьютеров
> открывали в браузере IP нашего сервера и попадали на сервер подрядчика
> 
> Как настроить NGINX, чтобы он делал bind_adress и передавал для авторизации
> сертификат и ключ по аналогии с wget?
> 
> Пробовал использовать следующее, но не помогает
> 
>     proxy_bind XX.XX.XX.XX;
>     proxy_pass https://<URL of website>;
>     proxy_ssl_certificate /etc/nginx/ssl/private_online.pem;
>     proxy_ssl_certificate_key /etc/nginx/ssl/private_online_key.pem;
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279454,279454#msg-279454
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 

-- 
Fedor Dikarev

From nginx-forum на forum.nginx.org  Mon Apr 23 21:22:51 2018
From: nginx-forum на forum.nginx.org (tresor.fk)
Date: Mon, 23 Apr 2018 17:22:51 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IHNzbCDRgdC10YDRgtC40YQ=?=
 =?UTF-8?B?0LjQutCw0YLQsCDQuCDQutC70Y7Rh9Cw?=
In-Reply-To: <b75f9d8f-9a1b-b1c9-be48-c00ae8b7dd94@hamilton.rinet.ru>
References: <b75f9d8f-9a1b-b1c9-be48-c00ae8b7dd94@hamilton.rinet.ru>
Message-ID: <81185f92c977577665a59284e70fbc8a.NginxMailingListRussian@forum.nginx.org>

Fedor Dikarev Wrote:
-------------------------------------------------------
> Попробуйте добавить `proxy_ssl_server_name on;`
> Можно еще повыставлять значения в `proxy_ssl_name` и `proxy_set_header
> Host` если просто с `proxy_ssl_server_name on` не сработает.
> 
> 16.04.18 14:25, tresor.fk пишет:
> > Помогите разобраться со следующей ситуацией:
> > 
> > Есть веб сервер подрядчика, доступ к которому осуществляется по
> выделенному
> > каналу и при указании сертификата и приватного ключа
> > 
> > То есть у нас есть линуксовый сервер, с которого мы инициализируем
> > подключение. Для этого на нем настроен дополнительный сетевой
> интерфейс.
> > 
> > Например если запустить:
> > 
> > wget --bind-address=<Secondary IP>
> > --certificate=/etc/nginx/ssl/private_online.crt
> > --private-key=/etc/nginx/ssl/private_online.key  https://<URL of
> website>
> > 
> > То подключение успешное - "HTTP request sent, awaiting response...
> 200 OK"
> > 
> > Но нам нужно на этом сервере настроить nginx, чтобы мы со своих
> компьютеров
> > открывали в браузере IP нашего сервера и попадали на сервер
> подрядчика
> > 
> > Как настроить NGINX, чтобы он делал bind_adress и передавал для
> авторизации
> > сертификат и ключ по аналогии с wget?
> > 
> > Пробовал использовать следующее, но не помогает
> > 
> >     proxy_bind XX.XX.XX.XX;
> >     proxy_pass https://<URL of website>;
> >     proxy_ssl_certificate /etc/nginx/ssl/private_online.pem;
> >     proxy_ssl_certificate_key /etc/nginx/ssl/private_online_key.pem;
> > 
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,279454,279454#msg-279454
> > 
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > 
> 
> -- 
> Fedor Dikarev
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Спасибо!!! Помогло

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279454,279555#msg-279555


From vbart на nginx.com  Thu Apr 26 16:47:55 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 26 Apr 2018 19:47:55 +0300
Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuMQ==?=
Message-ID: <2896689.fE7TLWxabH@vbart-workstation>

Здравствуйте.

Рад сообщить о выпуске новой версии NGINX Unit.  Данный выпуск главным образом
сосредоточен на исправлении ошибок, улучшении стабильности и совместимости.

Изменения в Unit 1.1                                              26.04.2018

    *) Исправление: приложения на Python, которые использовали вызов write(),
       не работали.

    *) Исправление: виртуальные окружения, созданные с помощью Python 3.3 или
       выше, могли не работать.

    *) Исправление: функция request.Read() в приложениях на Go не возвращала
       EOF, когда всё тело было прочитано.

    *) Исправление: переоткрытие логов доступа могло приводить к аварийному
       завершению.

    *) Исправление: в разборе IPv6 адресов управляющего сокета.

    *) Исправление: загрузка модулей приложений была сломана на OpenBSD.

    *) Исправление: наличие двух модулей одинакового типа и версии могло
       приводить к аварийному завершению; ошибка появилась в 1.0.

    *) Исправление: предупреждения "freed pointer points to non-freeble page"
       могли появляться в логе на 32-битных платформах.

О половине из этих проблем сообщили наши пользователи через GitHub.
Большое спасибо всем за то, что помогаете нам совершенствовать Unit.

Если столкнулись с проблемой или у вас есть идеи по усовершенствованию
функциональности Unit'а, то не стесняйтесь рассказать нам об этом через:

 - Список рассылки: http://mailman.nginx.org/mailman/listinfo/unit
 - GitHub: https://github.com/nginx/unit/issues

--
Валентин Бартенев

From nginx-forum на forum.nginx.org  Fri Apr 27 19:31:18 2018
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Fri, 27 Apr 2018 15:31:18 -0400
Subject: =?UTF-8?B?0JrQvtCz0LTQsCDQv9C70LDQvdC40YDRg9C10YLRgdGPIFJQTSDQtNC70Y8gTmdp?=
 =?UTF-8?B?bnggMS4xND8=?=
Message-ID: <459a2069cd972b4c9d24099578b70f48.NginxMailingListRussian@forum.nginx.org>

Обычно RPM появляется сразу, но 1.14 вышел 10 дней назад, а RPM до сих пор
нет.

Когда ориентировочно он появится?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279622,279622#msg-279622


From vbart на nginx.com  Fri Apr 27 20:18:24 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 27 Apr 2018 23:18:24 +0300
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyBSUE0g0LTQu9GP?=
 =?UTF-8?B?IE5naW54IDEuMTQ/?=
In-Reply-To: <459a2069cd972b4c9d24099578b70f48.NginxMailingListRussian@forum.nginx.org>
References: <459a2069cd972b4c9d24099578b70f48.NginxMailingListRussian@forum.nginx.org>
Message-ID: <10893980.tB147CN0dh@vbart-laptop>

On Friday, 27 April 2018 22:31:18 MSK Ilya Evseev wrote:
> Обычно RPM появляется сразу, но 1.14 вышел 10 дней назад, а RPM до сих пор
> нет.
> 
> Когда ориентировочно он появится?
> 

Все есть.

Например:
http://nginx.org/packages/centos/7/x86_64/RPMS/

--
Валентин Бартенев

From panichev на segmento.ru  Sat Apr 28 10:19:17 2018
From: panichev на segmento.ru (Panichev Oleg)
Date: Sat, 28 Apr 2018 13:19:17 +0300
Subject: =?UTF-8?B?0KTQuNC70YzRgtGA0LDRhtC40Y8gZXJyb3JfbG9n?=
Message-ID: <749ddd9d-3810-ab42-449d-6366f6ebd6fc@segmento.ru>

Добрый день,

У нас есть задача часть трафика отправлять на тестовый стенд. Решили
этот вопрос таким образом:

  split_clients "${shard_key}" $test_or_204 {
     5%  test;
     *   mirror_204;
   }

   upstream test {
     server test:1234;
   }

   location /original {
    ...
    mirror /mirror
    ...
    }

   location /mirror {

     if ( $test_or_204 = "mirror_204" ) {
         return 204;
     }

     fastcgi_pass $test_or_204;

   }

     Это решение работает прекрасно за исключением того момента, что
когда выключается upstream, на который мы шлем часть тестового трафика,
error_log оригинального локейшена /orig сразу заполняется ошибками вида:

  2018/04/26 09:37:15 [error] 24047#0: *395993 connect() failed (111:
Connection refused) while connecting to upstream, client: x.x.x.x,
server: xxxx.ru, request: "GET / HTTP/1.1", subrequest: "/mirror",
upstream: "fastcgi://127.0.0.1:1234", host: "xxxx"

  Можно как-то избавиться от этих сообщений?


-- 

Спасибо.


From chipitsine на gmail.com  Sat Apr 28 12:03:49 2018
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 28 Apr 2018 17:03:49 +0500
Subject: =?UTF-8?B?0L/QvtC00LTQtdGA0LbQutCwIElQX0JJTkRfQUREUkVTU19OT19QT1JUINC90LAg?=
 =?UTF-8?B?Q2VudE9TLTcuNA==?=
Message-ID: <CAFHpkQHm0mjoBTy-TfXer4=yMhmCuopSiBBJ0g4Qs_wkE6Ac6g@mail.gmail.com>

привет!

поддержка 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_PORT    24
[root на xxx ~]#


т.е. если пакет собирать, как он собирается обычно, то поддержка
IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы).

скажите, вы официальные пакеты собираете каким образом ? кажется, имеет
смысл поправить эту процедуру и дать эту крутую фичу пользователям
CentOS-7.4


Илья Шипицин
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180428/dd46f0bd/attachment.html>

From vbart на nginx.com  Sat Apr 28 22:40:57 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Sun, 29 Apr 2018 01:40:57 +0300
Subject: =?UTF-8?B?UmU6INC/0L7QtNC00LXRgNC20LrQsCBJUF9CSU5EX0FERFJFU1NfTk9fUE9SVCA=?=
 =?UTF-8?B?0L3QsCBDZW50T1MtNy40?=
In-Reply-To: <CAFHpkQHm0mjoBTy-TfXer4=yMhmCuopSiBBJ0g4Qs_wkE6Ac6g@mail.gmail.com>
References: <CAFHpkQHm0mjoBTy-TfXer4=yMhmCuopSiBBJ0g4Qs_wkE6Ac6g@mail.gmail.com>
Message-ID: <1705981.ux17j1kC72@vbart-laptop>

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_PORT    24
> [root на xxx ~]#
> 
> 
> т.е. если пакет собирать, как он собирается обычно, то поддержка
> IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы).
> 
> скажите, вы официальные пакеты собираете каким образом ? кажется, имеет
> смысл поправить эту процедуру и дать эту крутую фичу пользователям
> CentOS-7.4
> 

Дело же не в ядре (не только в нем).  На линуксах интерфейс обеспечивает glibc
и именно туда смотрит nginx.

--
Валентин Бартенев

From chipitsine на gmail.com  Sun Apr 29 06:06:26 2018
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sun, 29 Apr 2018 11:06:26 +0500
Subject: =?UTF-8?B?UmU6INC/0L7QtNC00LXRgNC20LrQsCBJUF9CSU5EX0FERFJFU1NfTk9fUE9SVCA=?=
 =?UTF-8?B?0L3QsCBDZW50T1MtNy40?=
In-Reply-To: <1705981.ux17j1kC72@vbart-laptop>
References: <CAFHpkQHm0mjoBTy-TfXer4=yMhmCuopSiBBJ0g4Qs_wkE6Ac6g@mail.gmail.com>
 <1705981.ux17j1kC72@vbart-laptop>
Message-ID: <CAFHpkQH7Tom83XtqDa0z2snE=0Fo8FVC_QKVSGnCut8TFEdxhA@mail.gmail.com>

29 апреля 2018 г., 3:40 пользователь Валентин Бартенев <vbart на nginx.com>
написал:

> 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_PORT    24
> > [root на xxx ~]#
> >
> >
> > т.е. если пакет собирать, как он собирается обычно, то поддержка
> > IP_BIND_ADDRESS_NO_PORT не включается (хотя могла бы).
> >
> > скажите, вы официальные пакеты собираете каким образом ? кажется, имеет
> > смысл поправить эту процедуру и дать эту крутую фичу пользователям
> > CentOS-7.4
> >
>
> Дело же не в ядре (не только в нем).  На линуксах интерфейс обеспечивает
> glibc
> и именно туда смотрит nginx.
>


я про это и имел в виду. "туда смотрит nginx" и "туда спрятали в centos
7.4" - это отличается.
в glibc - да, есть. а хедер другой, не тот, который проверяет nginx


>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180429/d1678e05/attachment.html>