Re: Изменения в блоке if
у меня вот так работает:
map $request_uri $bad {
default '';
/string '1';
/number 1;
/zero_one '01';
/one_space '1 ';
/space_one ' 1';
/zero '0';
}
...
if ($bad) { return 403 "$bad"; }
[fe@hamilton ~]$ for loc in string number zero_one one_space space_one; do curl -w "
%{http_code}\n" https://test.host/$loc; done
1 403
1 403
01 403
1 403
1 403
Как-раз на части случаев тут if ($bad = '1') перестает работать. Но
придумать кейс в обратную сторону у меня пока не получилось.
Я бы ради дебага добавил бы локейшен, где бы поставил return 202
"$very_bad" и посмотрел какое значение там получается.
p.s.
nginx version: nginx/1.19.2 built with OpenSSL 1.1.1g 21 Apr 2020
30.09.2020 10:03, skeletor пишет:
Всем привет.
Начал замечать, что с недавних пор, (на версии 1.19.1 точно, и, скорее всего
на 1.17.Х) поведение if поменялось. При этом в документации (что en, что ru
- одинаково) сказано, что такая конструкция будет работать:
if ($slow) {
limit_rate 10k;
}
но на практике нужно писать
if ($slow = 1) {
limit_rate 10k;
}
иначе не работает.
Могу привести конкретный пример, где у меня не работает "упрощенный" (то
есть без сравнения с 1) if:
map $is_bot:$uri:$http_referer $very_bad {
default '';
"~*0:(\/api):(.*bad\.html)" '1';
}
...
if ($very_bad = 1) {return 403;}
Именно так работает. Если же указать
if ($very_bad) {return 403;}
то не работает.
Есть такие, у которых нормально работает "упрощённый" if на новых версиях?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,289612,289612#msg-289612
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Домены 3-го уровня - best practices
map $host $x_company_header {
default default.example.com;
www.example.com "";
sub1.example.comsub1.example.com
~ "^alt\d+.example.com" $host;
}
server {
listen 80;
listen 443 ssl; # не забыть wildcard cert
server_name example.com www.example.com *.example.com;
location / {
proxy_set_header Host "example.com";
proxy_set_header X-Company-Header $x_company_header;
proxy_pass http://upstream;
}
}
вот как-то так.
25.05.2019 0:10, vitcool пишет:
> Добрый день.
>
> Есть ли какие-либо примеры лучших практик на тему "как лучше организовать
> обслуживание доменов 3-го уровня" при условии, что их количество будет не
> более 20..30, максимум 40, включая основной www. ?
>
> По факту все они должны вести на 1 апстрим, но в случае домена 3-го уровня,
> нужно будет установить кастомный заголовок со значением равным этому домену
> и подменить заголовок Host на основной.
>
> Доступ к коду бекенда есть, но весьма ограниченный. Эти 2 хидера бы спасли
> ситуацию.
>
> Что посоветуете? Пиковая нагрузка порядка 50..75 RPS , ожидается рост до
> 100. С if-ми я так понимаю, нам не выжить.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,284307,284307#msg-284307
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Получить ключ limit_rate в логе rate_limit-а
18.04.2019 11:16, Oleg A. Mamontov пишет: > On Wed, Apr 17, 2019 at 10:42:37PM +0300, Fedor Dikarev wrote: >> Привет! >> >> Возникла задача rate_limit-итить обращения к api при помощи Nginx-а и >> таким образом защититься от DDOS-а. >> Авторизация к api идет через jwt, в ключе есть логин пользователя. >> Поэтому я уже заказал demo nginx plus, планирую воспользоваться >> функционалом jwt и rate limit-ить по логину, примерно так: >>> auth_jwt_claim_set $login info login; >>> limit_req_zone $login zone=one:10m rate=1r/s; >> >> а дальше хочется получить список нехороших логинов, через которые нас >> пытаются досить. >> Прочитал доку https://www.nginx.com/blog/rate-limiting-nginx/ -- там >> написано что я получу адрес клиента, request и хостнейм в слуяае >> превышения лимита. И это здорово. >> А можно как-то получить значение ключа (в моем случае это логин >> пользователя), который привысил rate limit? >> >> Пока есть гипотеза логгировать логин в access.log и потом >> коррелировать access.log и error.log, но выглядит немного странно. И >> вдруг можно получить результат сильно проще. > > Перехватить 503 с помощью error_page и обработать в специальном location > с кастомизированным log_format ? Привет, Олег! Спасибо за совет: да, все просто и логично, я почему-то не подумал в эту сторону. Сегодня-завтра попробуем поднять этот вариант на QA, понагружаем немного и отпишусь о результатах. -- Fedor Dikarev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Получить ключ limit_rate в логе rate_limit-а
Привет! Возникла задача rate_limit-итить обращения к api при помощи Nginx-а и таким образом защититься от DDOS-а. Авторизация к api идет через jwt, в ключе есть логин пользователя. Поэтому я уже заказал demo nginx plus, планирую воспользоваться функционалом jwt и rate limit-ить по логину, примерно так: auth_jwt_claim_set $login info login; > limit_req_zone $login zone=one:10m rate=1r/s; а дальше хочется получить список нехороших логинов, через которые нас пытаются досить. Прочитал доку https://www.nginx.com/blog/rate-limiting-nginx/ -- там написано что я получу адрес клиента, request и хостнейм в слуяае превышения лимита. И это здорово. А можно как-то получить значение ключа (в моем случае это логин пользователя), который привысил rate limit? Пока есть гипотеза логгировать логин в access.log и потом коррелировать access.log и error.log, но выглядит немного странно. И вдруг можно получить результат сильно проще. -- Fedor Dikarev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
custom 404 для разных запросов
Всем добрый день! Решил поинтересоваться: может кто-то уже решал подобную задачу и может поделиться идеей как лучше сделать. Суть задачи: есть сайт, контент максимально статичен, большая часть это html + js + css + png, плюс api на отдельном домене. Положить все asset-ы (js, css, png) в отдельный каталог и отдельный location не получается, пока все лежит в разнобой. Возникла задача отдавать красивую страницу, когда пользователь опечатался или пришел по ссылке, которой больше нет. Под это нарисовали single-page-application на 80kb, которое надо отдавать на 404-ый код. Но при этом есть еще какое-то количество запросов на уже не существующие js, css и api которые когда-то были на этом домене. И на эти запросы не хочется отдавать 80kb на запрос, хочется ограничиться чем-то попроще. Пока идея только сделать map $request_uri $error_page, в нем по regexp-у отловить расширения файлов и дописать location-ы где были раньше api. Но эта идея мне не очень нравится, и хуже всего: даже не могу понять что именно в ней меня не устраивает. Просто есть ощущение, что что-то не учел и будут какие-то подводные камни. Делал ли кто-то уже подобную штуку? Можете поделиться опытом использования и подводными камнями, что были? -- Fedor Dikarev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: local IP address
В общем я подумал еще раз, и понял что или не понимаю исходную задачу,
или не понимаю пути ее решения.
Но вдруг это поможет:
у нас тоже есть задача, что разные сервисы должны слушаться на разных
адресах: один адрес для public-сервисов, второй для ограниченного круга
лиц, третий для другого круга и т.д.
Решаем это так: в конфиге nginx-а для каждого сервера пишем listen ip:80
для каждого уровня доступа свой ip адрес, дальше server_name нужный для
сервиса. А сервисы уже в docker-е, и в nginx-е просто proxy_pass на
expose-нутый порт. И все работает. (понятно что эти конфиги пишем не
руками, но как идея. хотя могу и программой поделиться, если задача
такая же)
28.02.19 23:00, Fedor Dikarev пишет:
А это точно тестируемый конфиг приведен? Может там еще что-то есть?
Тут получается что nginx проксирует сам на себя, и я даже не поленился
это попробовать и получил ожидаемое:
# cat localhost.conf server {
listen 80;
access_log /var/log/nginx/local-access.log;
location / { return 200 "$server_addr\n"; }
location /one {
proxy_set_header X-Server-IP $server_addr;
proxy_pass $scheme://$server_addr;
}
}
# grep -c /one /var/log/nginx/local-access.log ; curl
http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log
909
502 Bad Gateway
502 Bad Gateway
nginx/1.15.8
1813
grep -c /one /var/log/nginx/local-access.log ; curl
http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log
1813
502 Bad Gateway
502 Bad Gateway
nginx/1.15.8
2820
28.02.19 21:35, Igor Savenko пишет:
Хм. Интересно получается.
Интерфейсы на хосте (поскольку это, видимо, KVM guest, то все они,
наверное, выставлены в один бридж, но это не имеет отношения к делу):
[root@blissstagingserver1 imunify360-webshield]# ip -o -4 ad | grep eth
2: eth0 inet 10.0.0.143/26 <http://10.0.0.143/26> brd 10.0.0.191
scope global eth0\ valid_lft forever preferred_lft forever
3: eth1 inet 10.0.0.146/26 <http://10.0.0.146/26> brd 10.0.0.191
scope global eth1\ valid_lft forever preferred_lft forever
4: eth2 inet 10.0.0.147/26 <http://10.0.0.147/26> brd 10.0.0.191
scope global eth2\ valid_lft forever preferred_lft forever
server {
listen *:80;
location / {
proxy_set_header X-Server-IP $server_addr;
proxy_pass $scheme://$server_addr;
}
}
Бекэндом выступает питоновский http.server, который просто выводит в
консоль заголовки Host и X-Server-IP
$ curl -L -v http://10.0.0.146
* Rebuilt URL to: http://10.0.0.146/
* Trying 10.0.0.146...
* TCP_NODELAY set
* Connected to 10.0.0.146 (10.0.0.146) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.0.0.146
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 200 OK
На это питоновский сервер пишет
Host: 10.0.0.146, IP: 10.0.0.143
То есть $server_addr -- 10.0.0.143, a не 146, как ожидалось...
То есть в $server_add
чт, 28 февр. 2019 г. в 18:37, Fedor Dikarev <mailto:f...@hamilton.rinet.ru>>:
28.02.2019 19:20, Igor Savenko пишет:
> Доброе время суток!
> Подскажите, есть ли вообще способ определить, на какой именно
адрес был
> послан запрос (хост имеет несколько интерфейсов с разными
адресами или
> несколько secondary адресов на одном интерфейсе), чтобы
спроксировать
> этот запрос на корректный адрес upstream. который тоже слушает на
localhost.
> Схема проста:
> server {
> listen *:80;
> server_name _;
> location / {
> proxy_pass http://$server_addr;
> }
> }
>
> При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и
5.6.7.8.
> Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не
1.2.3.4
> (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить
> программно (в каком-нибудь модуле, то подскажите, пожалуйста.
Спасибо!
Про правильный server_addr не понял, а сейчас что не так?
> # ifconfig lo0
> lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> inet 127.0.0.1 netmask 0xff00
> inet 192.168.255.1 netmask 0x
> inet 192.168.255.2 netmask 0x
> inet 192.168.255.3 netmask 0x
> inet 192.168.255.4 netmask 0x
> inet 192.168.255.5 netmask 0x
> nd6 options=21
> groups: lo
> # cat localhost.conf
> server {
> listen 80;
>
> location / { return 200 "$server_addr\n"; }
> }
> # for h in 2 3 4; do curl 192.168.255.$h; done
> 192.168.2
Re: local IP address
А это точно тестируемый конфиг приведен? Может там еще что-то есть?
Тут получается что nginx проксирует сам на себя, и я даже не поленился
это попробовать и получил ожидаемое:
# cat localhost.conf
server {
listen 80;
access_log /var/log/nginx/local-access.log;
location / { return 200 "$server_addr\n"; }
location /one {
proxy_set_headerX-Server-IP $server_addr;
proxy_pass $scheme://$server_addr;
}
}
# grep -c /one /var/log/nginx/local-access.log ; curl http://192.168.255.5/one
; grep -c /one /var/log/nginx/local-access.log
909
502 Bad Gateway
502 Bad Gateway
nginx/1.15.8
1813
grep -c /one /var/log/nginx/local-access.log ; curl http://192.168.255.5/one ;
grep -c /one /var/log/nginx/local-access.log
1813
502 Bad Gateway
502 Bad Gateway
nginx/1.15.8
2820
28.02.19 21:35, Igor Savenko пишет:
Хм. Интересно получается.
Интерфейсы на хосте (поскольку это, видимо, KVM guest, то все они,
наверное, выставлены в один бридж, но это не имеет отношения к делу):
[root@blissstagingserver1 imunify360-webshield]# ip -o -4 ad | grep eth
2: eth0 inet 10.0.0.143/26 <http://10.0.0.143/26> brd 10.0.0.191
scope global eth0\ valid_lft forever preferred_lft forever
3: eth1 inet 10.0.0.146/26 <http://10.0.0.146/26> brd 10.0.0.191
scope global eth1\ valid_lft forever preferred_lft forever
4: eth2 inet 10.0.0.147/26 <http://10.0.0.147/26> brd 10.0.0.191
scope global eth2\ valid_lft forever preferred_lft forever
server {
listen *:80;
location / {
proxy_set_header X-Server-IP $server_addr;
proxy_pass $scheme://$server_addr;
}
}
Бекэндом выступает питоновский http.server, который просто выводит в
консоль заголовки Host и X-Server-IP
$ curl -L -v http://10.0.0.146
* Rebuilt URL to: http://10.0.0.146/
* Trying 10.0.0.146...
* TCP_NODELAY set
* Connected to 10.0.0.146 (10.0.0.146) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.0.0.146
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 200 OK
На это питоновский сервер пишет
Host: 10.0.0.146, IP: 10.0.0.143
То есть $server_addr -- 10.0.0.143, a не 146, как ожидалось...
То есть в $server_add
чт, 28 февр. 2019 г. в 18:37, Fedor Dikarev <mailto:f...@hamilton.rinet.ru>>:
28.02.2019 19:20, Igor Savenko пишет:
> Доброе время суток!
> Подскажите, есть ли вообще способ определить, на какой именно
адрес был
> послан запрос (хост имеет несколько интерфейсов с разными
адресами или
> несколько secondary адресов на одном интерфейсе), чтобы спроксировать
> этот запрос на корректный адрес upstream. который тоже слушает на
localhost.
> Схема проста:
> server {
> listen *:80;
> server_name _;
> location / {
> proxy_pass http://$server_addr;
> }
> }
>
> При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и 5.6.7.8.
> Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не
1.2.3.4
> (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить
> программно (в каком-нибудь модуле, то подскажите, пожалуйста.
Спасибо!
Про правильный server_addr не понял, а сейчас что не так?
> # ifconfig lo0
> lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> inet 127.0.0.1 netmask 0xff00
> inet 192.168.255.1 netmask 0x
> inet 192.168.255.2 netmask 0x
> inet 192.168.255.3 netmask 0x
> inet 192.168.255.4 netmask 0x
> inet 192.168.255.5 netmask 0x
> nd6 options=21
> groups: lo
> # cat localhost.conf
> server {
> listen 80;
>
> location / { return 200 "$server_addr\n"; }
> }
> # for h in 2 3 4; do curl 192.168.255.$h; done
> 192.168.255.2
> 192.168.255.3
> 192.168.255.4
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
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
Re: local IP address
28.02.2019 19:20, Igor Savenko пишет:
> Доброе время суток!
> Подскажите, есть ли вообще способ определить, на какой именно адрес был
> послан запрос (хост имеет несколько интерфейсов с разными адресами или
> несколько secondary адресов на одном интерфейсе), чтобы спроксировать
> этот запрос на корректный адрес upstream. который тоже слушает на localhost.
> Схема проста:
> server {
> listen *:80;
> server_name _;
> location / {
> proxy_pass http://$server_addr;
> }
> }
>
> При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и 5.6.7.8.
> Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не 1.2.3.4
> (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить
> программно (в каком-нибудь модуле, то подскажите, пожалуйста. Спасибо!
Про правильный server_addr не понял, а сейчас что не так?
> # ifconfig lo0
> lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> inet 127.0.0.1 netmask 0xff00
> inet 192.168.255.1 netmask 0x
> inet 192.168.255.2 netmask 0x
> inet 192.168.255.3 netmask 0x
> inet 192.168.255.4 netmask 0x
> inet 192.168.255.5 netmask 0x
> nd6 options=21
> groups: lo
> # cat localhost.conf
> server {
> listen 80;
>
> location / { return 200 "$server_addr\n"; }
> }
> # for h in 2 3 4; do curl 192.168.255.$h; done
> 192.168.255.2
> 192.168.255.3
> 192.168.255.4
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: GET-параметры как статическая страница
08.01.2019 3:23, valet пишет:
> Здравствуйте.
>
> Вопрос такой: на сервере лежат статические html-файлы с именами типа
> index.html?id=1 index.html?id=2 и т.д. - то есть это их имена именно в таком
> виде.
> Как заставить nginx отдавать собственно именно эти файлы?
>
> стандартный кусок конфига
> location / {
> root/data/www/site.ru/;
> index index.html;
> }
> на запросы типа http://site.ru/index.html?id=1 отдает просто
> http://site.ru/index.html, то есть параметры отбрасываются.
>
> Я так подозреваю нужен какой-то правиьлный rewite, но гугление пока не
> помогает, знаний тоже не хватает, помогите разобраться.
можно попробовать try_files, например так:
> location /args_test/ { try_files $uri$is_args$args =404; }
или так:
> location /args_test/ { try_files $uri$is_args$args $uri; }
И тогда:
> root@hamilton:/st/hosting/hamilton/htdocs/args_test # ls
> index.html index.html?id=1
> root@hamilton:/st/hosting/hamilton/htdocs/args_test # cat *
> none
> one
> curl 'http://hamilton.rinet.ru/args_test/index.html?id=1'
> one
возможно это решит конкретно эту задачу. Но надо помнить, что добавление
любого другого параметра в запрос все сломает, и если их будет
несколько, то важен будет и порядок в котором они передаются в запросе.
Если надо будет и такие случаи разобрать, то уже надо будет правильный
map строить от аргументов map-ить в имя файла на диске.
>
> С уважением, Леонид.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,282565,282565#msg-282565
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: GeoIP
05.01.19 13:57, Gena Makhomed пишет: On 05.01.2019 12:18, Vladimir Getmanshchuk wrote: Гена, с City скрипт тоже корректно работает? В файле http://geolite.maxmind.com/download/geoip/database/GeoLite2-Country-CSV.zip нет городов, там есть только код континента, название континента, код страны и название страны. Поле is_in_european_union у них выставляется очень странным образом. Например, страна 3579143,en,NA,"North America",GP,Guadeloupe,1 которая находится в Америке считается входящей в Евросоюз. Или вот эти африканские страны 935317,en,AF,Africa,RE,Réunion,1 1024031,en,AF,Africa,YT,Mayotte,1 у них тоже являются членами Евросоюза. И это правильно: Гваделупа – французская заморская территория, расположенная на островах в южной части Карибского моря. Реюньон – французский заморский департамент на одноименном острове в Индийском океане Майотта – заморский регион и департамент Франции, а также архипелаг, который относится к Коморским островам и находится между северным Мадагаскаром и северным Мозамбиком. и эти территории соответственно принадлежат к Евросоюзу. И там, например, надо соблюдать законы и требования EU. P.S. Лицензия на код BSD 2-Clause License, так что Вы легко можете сделать форк и подправить этот скрипт под свои потребности, например, добавив туда поддержку City для платных баз maxmind. On Fri, Jan 4, 2019 at 5:58 PM Gena Makhomed wrote: Какие есть альтернативы maxmind и/или этому модулю? Есть альтернативы модулю ngx_http_geoip_module. Я просто конвертирую GeoLite2 в формат, который понимает nginx с помощью своего скрипта https://github.com/makhomed/nginx-geo запускаемого через крон раз в сутки, так что таким образом у меня в nginx используется всегда самая свежая база GeoLite2 через модуль http://nginx.org/en/docs/http/ngx_http_geo_module.html Встроенный в nginx модуль ngx_http_geo_module не использует никаких сторонних библиотек, так что он работает максимально стабильно и надежно, при этом использует минимальное количество памяти. -- Fedor Dikarev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: drop connection
21.12.2018 8:34, inkognito0609 пишет: > Доброго времени суток! > > Кейс такой, на NS прописан 'wildcard *.exemple.com', директивой server_name > разгуливаю на бэкенды. > > При наборе разной белиберды - 'asdfgasdg.exemple.com' отправляет на первый > server_name. > Сделал заглушку типа 'server_name _;' которая кидает на 404. > Как совсем дропать имена которые не заданы в конфиге? return 444; ? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,282435,282435#msg-282435 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Variables в add_after_body или передача параметров в njs subrequest
Привет!
Продолжаю свой вопрос про построение динамического бинарника и
использование для этого add_afer_body и njs
> http://mailman.nginx.org/pipermail/nginx-ru/2018-September/061454.html
> http://mailman.nginx.org/pipermail/nginx-ru/2018-September/061461.html
В итоге сейчас собрали такую конструкцию:
> location ~ /new4game-qa/web-installer/(.*).exe {
> add_after_body /exe_payload/$is_args$args;
> alias /files/new4game-qa/web-installer/4game-setup.exe
> }
> location /exe_payload {
> internal;
> # rewrite ^/exe_payload/
> /exe_payload/2/$gameKey/$gamekey/$arg_gameKey/$arg_gamekey/ break;
> proxy_set_header X-GameKey "2/$gameKey/$arg_gameKey";
> set $gameKey $arg_gameKey;
> js_content exe_payload;
> }
(как видим тут я пробую разные варианты передать $arg_gameKey в
обработчик и все безуспешно) меня тут даже спасет если в njs будет
передаваться оригинальный url запроса, но этого я тоже не смог добиться :(
И сама функция:
> function exe_payload(r) {
> ...
> var config = {
> "gameKey": r.variables['gameKey'],
> "r.vars": r.variables,
> "r.uri": r.uri,
> "r.headers": r.headersIn,
> "r.key": r.headersIn["X-GameKey"]
> };
> var configStr = JSON.stringify(config);
И на выходе получаю:
> 0079d9c0 61 6d 65 4b 65 79 22 3a 22 22 2c 22 72 2e 76 61 |ameKey":"","r.va|
> 0079d9d0 72 73 22 3a 6e 75 6c 6c 2c 22 72 2e 75 72 69 22 |rs":null,"r.uri"|
> 0079d9e0 3a 22 2f 65 78 65 5f 70 61 79 6c 6f 61 64 2f 24 |:"/exe_payload/$|
> 0079d9f0 69 73 5f 61 72 67 73 24 61 72 67 73 22 2c 22 72 |is_args$args","r|
> 0079da00 2e 68 65 61 64 65 72 73 22 3a 6e 75 6c 6c 2c 22 |.headers":null,"|
Собственно можно как-то раскрывать variables в location add_after_body?
Ну или может есть какой-то более правильный способ передать параметр в
njs функцию вызываемую внутри этого subrequest-а?
--
Fedor Dikarev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSI для бинарных данных или аналог
Сейчас примерно так и сделали: > add_header Content-Disposition $header_content_disposition; > set $header_content_disposition 'attachment; > filename="$request_basename.$cnf_map.exe"'; Но маркетинг жалуется, что пользователей пугают такие имена. Плюс брэндирование таким методом не запихнешь: картинки слишком большие :-( 11.09.2018 15:52, Vladislav Shabanov пишет: > Проще всего передавать параметры в имени exe-файла. Браузеры его не > портят, сохраняют так, как сервер сказал. > Поэтому можно закатать в хвост имени 10-20 байт закодированные в base36. > А файл пусть посмотрит, как он называется, и решит, он сегодня gcc или > clang :) > И докачает остальную инфу по этим 10-20 байтам с сервера. > > >> 11 сент. 2018 г., в 15:45, Илья Шипицин > <mailto:chipits...@gmail.com>> написал(а): >> >> >> >> вт, 11 сент. 2018 г. в 14:02, Fedor Dikarev > <mailto:f...@hamilton.rinet.ru>>: >> >> 11.09.2018 10:08, Илья Шипицин пишет: >>> >>> >>> вт, 11 сент. 2018 г. в 9:42, Fedor Dikarev >> <mailto:f...@hamilton.rinet.ru>>: >>> >>> Привет! >>> >>> Столкнулся с задачей: хотим чтобы nginx собирал бинарный >>> ответ из >>> частей. Пример задачи: клиент скачивает из личного кабинета >>> установщик >>> (exe файл), а мы в конец этого exe файла дописываем json с >>> конфигурацией >>> >>> >>> установщики в виде exe считаются небезопасными из-за dll hijacking >>> (например, вот тут разобрано: https://portableapps.com/node/54917 ) >>> >>> >>> если у вас exe с цифровой подписью, то дописать в конец не >>> получится. >>> если без подписи - вас пользователи замучают "у меня виндовс >>> ругается на недоверенный файл" >> > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSI для бинарных данных или аналог
11.09.2018 15:45, Илья Шипицин пишет: > ... > > И плюс там не только настройки, но еще брэндирование: в > зависимости то того, из какого раздела пользователь скачал > установщик, надо подкладывать разные иконки и background-ы. > > > а после того, как вы зарелизите, к вам придут разработчики с просьбой > "придумай, как сделать, чтобы клиенты обновились" > > имхо, можно смотреть в сторону ClickOnce или аналогов Вопрос автообновления клиентов проработан и с ним пока сложностей нет, насколько я знаю. А за ClickOnce спасибо, закину разработчикам: я сам не очень хорошо разбираюсь в теме деплоя windows приложений, мне сложно сказать какие у нас требования и сценарии в этой части. > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSI для бинарных данных или аналог
11.09.2018 10:08, Илья Шипицин пишет: > > > вт, 11 сент. 2018 г. в 9:42, Fedor Dikarev <mailto:f...@hamilton.rinet.ru>>: > > Привет! > > Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из > частей. Пример задачи: клиент скачивает из личного кабинета установщик > (exe файл), а мы в конец этого exe файла дописываем json с > конфигурацией > > > установщики в виде exe считаются небезопасными из-за dll hijacking > (например, вот тут разобрано: https://portableapps.com/node/54917 ) > > > если у вас exe с цифровой подписью, то дописать в конец не получится. > если без подписи - вас пользователи замучают "у меня виндовс ругается > на недоверенный файл" Файл с подписью. И разработчики утверждают, что подписывается не весь файл целиком, а только ключевые части, которые меняться не будут. И вот тут утверждают тоже самое: > https://stackoverflow.com/questions/47646135/where-is-the-digital-signature-stored-when-code-signing-a-exe-file-in-windows А здесь это подтверждают: > http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx но в любом случае проверю что все ок. Если нет, то придется выносить логику в отдельную программу и переподписывать. > > кажется, лучшим вариантом было бы привязка программы к некому feed, > откуда бы программа > скачивала настройки ну там не только настройки, хотя даже в случае настроек доступ к feed-у, в общем случае, надо как-то авторизовать, да и доступа к интернету может не быть в момент установки. И плюс там не только настройки, но еще брэндирование: в зависимости то того, из какого раздела пользователь скачал установщик, надо подкладывать разные иконки и background-ы. > > > > для этого клиента. И собственно при первом запуске пользователю не > надо > вбивать адреса серверов и другие базовые настройки, все уже на месте. > > Собственно можно ли через SSI собирать бинарные ответы? > > Или можно ли как-то из своего скрипта сделать chunked ответ, где через > X-Accel-Redirect отдать первую бинарную часть ответа, а потом выдать > контент с конфигурацией? > -- > Fedor Dikarev > ___ > nginx-ru mailing list > nginx-ru@nginx.org <mailto:nginx-ru@nginx.org> > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
SSI для бинарных данных или аналог
Привет! Столкнулся с задачей: хотим чтобы nginx собирал бинарный ответ из частей. Пример задачи: клиент скачивает из личного кабинета установщик (exe файл), а мы в конец этого exe файла дописываем json с конфигурацией для этого клиента. И собственно при первом запуске пользователю не надо вбивать адреса серверов и другие базовые настройки, все уже на месте. Собственно можно ли через SSI собирать бинарные ответы? Или можно ли как-то из своего скрипта сделать chunked ответ, где через X-Accel-Redirect отдать первую бинарную часть ответа, а потом выдать контент с конфигурацией? -- Fedor Dikarev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование ssl сертификата и ключа
Попробуйте добавить `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= > --certificate=/etc/nginx/ssl/private_online.crt > --private-key=/etc/nginx/ssl/private_online.key https:// > > То подключение успешное - "HTTP request sent, awaiting response... 200 OK" > > Но нам нужно на этом сервере настроить nginx, чтобы мы со своих компьютеров > открывали в браузере IP нашего сервера и попадали на сервер подрядчика > > Как настроить NGINX, чтобы он делал bind_adress и передавал для авторизации > сертификат и ключ по аналогии с wget? > > Пробовал использовать следующее, но не помогает > > proxy_bind XX.XX.XX.XX; > proxy_pass https://; > 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
Re: Условие по времени - так можно?
В cron что-то подобное: > cp -f /etc/nginx/includes/condition.conf.day > /etc/nginx/includes/condition.conf > nginx -t && pkill -HUP nginx И симметричную строчку на вечер. 21.12.17 11:00, softshape пишет: > Всем привет, > > задача - закрыть ботам доступ на сайт днем и открыть ночью. Сейчас условие > отсечки ботов простое - > > if ($http_user_agent ~ > Linguee|statdom|SemrushBot|AhrefsBot|Reefeedbot|bingbot|SputnikBot|Crowsnest|MegaIndex|. > return 403; > } > > Что нужно в него добавить, чтобы возвращать 403ю только, допустим, с 6:00 до > 23:00 ? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,277867,277867#msg-277867 > > ___ > 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
Re: https upstream server и локальный backup http upstream
Суть задачи в том числе и во втором "но":
> Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то
> сделать fallback опять на локальную node.
то есть если у меня есть:
> upstream remote { server 127.0.0.1:8081; }
> upstream local { server 127.0.0.1:7070; }
> server { listen 8081; return 200 remote\n; }
> server { listen 7070; return 200 local\n; }
то по заголовку я хожу в remote сервер:
> curl -fs -H "X-Some-Header: yes" hamilton.rinet.ru/some_header
> remote
Если же remote 500-тит, или вообще закоментировать его, то чтобы ходил в
local:
> curl -fs -H "X-Some-Header: yes" hamilton.rinet.ru/some_header
> local
и да, эта конструкция ведет себя как надо:
> location =/some_header {
> proxy_intercept_errors on;
> if ($remote) {
> proxy_pass http://remote;
> error_page 500 502 504 = @local;
> }
> proxy_pass http://local;
> }
> location @local {
> internal;
> proxy_pass http://local;
> }
Но в большой оригинальной задаче и так уже много if-ов, поэтому и
хочется получить решение без использования if-а.
В идеале: собственно в виде backup_proto=http :) поскольку эта же задача
максимально элегантно решалась через
> upstream remote {
> server remote;
> server local backup;
> }
пока не появилось требование к https у upstream-а
16.12.17 22:52, Aziz Rozyev пишет:
> может я, конечно, не уловил сути задачи, но и без error_page переключается:
>
> 39map $http_x_myheader $remote {
> 40"" 0;
> 41"test" 1;
> 42}
> 43
> 44upstream remote_up {
> 45server nginx.org:443;
> 46}
> 47
> 48upstream local_up {
> 49server localhost:7070;
> 50}
>
> 58server {
> 59listen 8085;
> 60location / {
>
> 62proxy_set_header Host $host;
> 63proxy_set_header Connection "";
> 64proxy_http_version 1.1;
> 65
> 66if ($remote) {
> 67 proxy_pass https://remote_up;
> 68}
> 69proxy_pass http://local_up;
> 70}
> 71}
>
> 73server {
> 74listen 7070;
> 75return 200 "OK";
> 76}
>
>
> [root@tc ~]# curl http://localhost:8085/
> OK
>
> [root@tc ~]# curl -H 'X-Myheader: test' http://localhost:8085/
>
> "http://www.w3.org/TR/html4/loose.dtd;>
> type="application/rss+xml" title="nginx news"
> href="http://nginx.org/index.rss;>nginx news
> [ … ]
>
>
> без if-a что-то не придумал, как обойтись.
>
> br,
> Aziz.
>
>
>
>
>
>> On 16 Dec 2017, at 19:28, Fedor Dikarev <f...@hamilton.rinet.ru> wrote:
>>
>> Попробовал этот вариант, и без error_page он не переключается на local.
>> Но если вписать error_page внутрь if-а, то вроде как работает как нужно.
>> Осталось убедить самого себя, что без if-а тут не обойтись. Хотя и очень
>> хочется.
>>
>> 16.12.17 15:21, Aziz Rozyev пишет:
>>> а вариант с 2 апстримами не подходит?
>>>
>>> upstream remote_up {
>>>remote_upstream:443;
>>> }
>>>
>>> upstream local_up {
>>>localhost:7070;
>>> }
>>>
>>> map $http_x_some_header $remote {
>>> “”0;
>>> “default” 1;
>>> }
>>>
>>> if ($remote) {
>>> proxy_pass https://remote;
>>> }
>>> proxy_pass http://local;
>>>
>>>
>>> br,
>>> Aziz.
>>>
>>>
>>>
>>>
>>>
>>>> On 16 Dec 2017, at 12:50, Fedor Dikarev <f...@hamilton.rinet.ru> wrote:
>>>>
>>>> Привет!
>>>>
>>>> Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока
>>>> совсем беда :-(
>>>>
>>>> Формулировка, правда, изначально довольно извращенная:
>>>> есть Nginx, по-умолчанию проксирует запрос в локально работающую node.
>>>> Но если в запросе есть заголовок X-Some-Header, то запрос
>>>> нужно спроксировать на другой сервер по https.
>>>> Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то
>>>> сделать fallback опять на локальную node.
>>>>
>>>> первая мысль была:
>>>> map $http_x_some_header $use_backend {
>>&g
Re: https upstream server и локальный backup http upstream
Попробовал этот вариант, и без error_page он не переключается на local.
Но если вписать error_page внутрь if-а, то вроде как работает как нужно.
Осталось убедить самого себя, что без if-а тут не обойтись. Хотя и очень
хочется.
16.12.17 15:21, Aziz Rozyev пишет:
> а вариант с 2 апстримами не подходит?
>
> upstream remote_up {
> remote_upstream:443;
> }
>
> upstream local_up {
> localhost:7070;
> }
>
> map $http_x_some_header $remote {
> “”0;
> “default” 1;
> }
>
> if ($remote) {
> proxy_pass https://remote;
> }
> proxy_pass http://local;
>
>
> br,
> Aziz.
>
>
>
>
>
>> On 16 Dec 2017, at 12:50, Fedor Dikarev <f...@hamilton.rinet.ru> wrote:
>>
>> Привет!
>>
>> Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока
>> совсем беда :-(
>>
>> Формулировка, правда, изначально довольно извращенная:
>> есть Nginx, по-умолчанию проксирует запрос в локально работающую node.
>> Но если в запросе есть заголовок X-Some-Header, то запрос
>> нужно спроксировать на другой сервер по https.
>> Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то
>> сделать fallback опять на локальную node.
>>
>> первая мысль была:
>> map $http_x_some_header $use_backend {
>> "" http://localhost:7070;
>> default https://remote_upstream;
>> }
>> upstream remote_upstream {
>> server remote:443;
>> server localhost:7070 backup;
>> }
>>
>> но локальный сервер не https, и все не очень красиво :-(
>> думал тут еще поднять на этом же nginx локальный https на порту 7073,
>> проксировать в него как backup, но тут начинаются сложности с
>> сертификатами.
>>
>> Опять же думал о другом варианте:
>> proxy_pass $use_backend;
>> error_page 500 502 504 = @fallback_local_node;
>>
>> location @fallback_local_node {
>> internal;
>> proxy_pass http://localhost:7070;
>> }
>>
>> но тут получается что если заголовка не было, node ответил 502, то мы
>> пойдем в node еще раз. Не то, чтобы прям ужас, но некрасиво
>> получается...
>>
>> Может кто подскажет тут красивое решение?
>>
>> Ну и как feature request: может можно добавить к опции backup для
>> директивы server в upstream еще какой-нибудь параметр backup_proto=http
>> или другую опцию backup_http, чтобы при переключении на backup сервер
>> менялся и протокол обращения.
>> --
>> Fedor Dikarev
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
--
Fedor Dikarev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
https upstream server и локальный backup http upstream
Привет!
Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока
совсем беда :-(
Формулировка, правда, изначально довольно извращенная:
есть Nginx, по-умолчанию проксирует запрос в локально работающую node.
Но если в запросе есть заголовок X-Some-Header, то запрос
нужно спроксировать на другой сервер по https.
Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то
сделать fallback опять на локальную node.
первая мысль была:
map $http_x_some_header $use_backend {
"" http://localhost:7070;
default https://remote_upstream;
}
upstream remote_upstream {
server remote:443;
server localhost:7070 backup;
}
но локальный сервер не https, и все не очень красиво :-(
думал тут еще поднять на этом же nginx локальный https на порту 7073,
проксировать в него как backup, но тут начинаются сложности с
сертификатами.
Опять же думал о другом варианте:
proxy_pass $use_backend;
error_page 500 502 504 = @fallback_local_node;
location @fallback_local_node {
internal;
proxy_pass http://localhost:7070;
}
но тут получается что если заголовка не было, node ответил 502, то мы
пойдем в node еще раз. Не то, чтобы прям ужас, но некрасиво
получается...
Может кто подскажет тут красивое решение?
Ну и как feature request: может можно добавить к опции backup для
директивы server в upstream еще какой-нибудь параметр backup_proto=http
или другую опцию backup_http, чтобы при переключении на backup сервер
менялся и протокол обращения.
--
Fedor Dikarev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Странное с set_real_ip_from
И можно поделиться с общественностью: а) помогло ли включение real_ip_recursive? б) что приезжало в заголовке X-Forwarded-For? On 04/07/16 15:28, Vladimir Sopot wrote: Внезапно, подозреваю отсутствие в конфиге real_ip_recursive on; Сегодня буду тестировать. On 02 Jul 2016, at 19:24, Vladimir Sopot <j...@jdwuzhere.ru> wrote: Да, конечно, есть и real_ip_header X-Forwarded-For; В конфиге есть ещё куча других сетей оперы и с ними, кажется, нет проблем. On 02 Jul 2016, at 13:39, Fedor Dikarev <f...@nginx.com> wrote: Opera использует заголовок X-Forwarded-For для передачи адреса клиента, а не X-Real-IP как nginx ожидает по-умолчанию. Добавьте: real_ip_headerX-Forwarded-For; http://nginx.org/ru/docs/http/ngx_http_realip_module.html#real_ip_header 02.07.16 12:45, Vladimir Sopot пишет: Привет! В nginx.conf есть set_real_ip_from 185.26.180.0/22; fastcgi_param REMOTE_ADDR $remote_addr; Но при этом до php-fpm доходит $_SERVER["REMOTE_ADDR”]=185.26.182.31 nginx version: nginx/1.10.1 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled configure arguments: --without-http_uwsgi_module --without-http_scgi_module --with-http_ssl_module --with-http_stub_status_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_geoip_module --add-module=../ngx_cache_purge-2.3/ --with-file-aio --with-http_image_filter_module --with-http_realip_module Чего не хватает котенку? ___ 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 ___ 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
Re: Странное с set_real_ip_from
А что в заголовках запроса приезжает?
Вот, например, мой эксперимент:
fe@hamilton:~ % nc -kl
GET / HTTP/1.1
Host: hamilton.example.com:
...
x-lb-local: 82.145.209.252 80
X-Forwarded-For: 141.0.15.155
X-Content-Opt: Turbo/4.42.224
То есть видно, что запрос пришел с прокси Оперы, но в X-Forwarded-For
совсем не мой ip адрес, а адрес из сети Оперы.
А если тут будет видно, что все правильно приезжает, то можно
попробовать в nginx-е поднять еще один сервер, например, на том же порту
, проверить подставляет ли Nginx $remote_addr правильно.
Если подставляет, тогда искать в конфигах где переписывается
fastcgi_param или где не include-ится.
А если не подставляет, то тогда уже включать debug на эти коннекты:
events {
debug_connection 185.26.180.0/22;
> }
http://nginx.org/ru/docs/debugging_log.html
Запускать Nginx в debug-е, и либо станет понятно что происходит, либо
сюда уже постить конфиг этого сервера и debug log этих соединенй.
On 02/07/16 19:24, Vladimir Sopot wrote:
Да, конечно, есть и real_ip_header X-Forwarded-For;
В конфиге есть ещё куча других сетей оперы и с ними, кажется, нет проблем.
On 02 Jul 2016, at 13:39, Fedor Dikarev <f...@nginx.com> wrote:
Opera использует заголовок X-Forwarded-For для передачи адреса клиента,
а не X-Real-IP как nginx ожидает по-умолчанию. Добавьте:
real_ip_headerX-Forwarded-For;
http://nginx.org/ru/docs/http/ngx_http_realip_module.html#real_ip_header
02.07.16 12:45, Vladimir Sopot пишет:
Привет!
В nginx.conf есть
set_real_ip_from 185.26.180.0/22;
fastcgi_param REMOTE_ADDR $remote_addr;
Но при этом до php-fpm доходит
$_SERVER["REMOTE_ADDR”]=185.26.182.31
nginx version: nginx/1.10.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --without-http_uwsgi_module --without-http_scgi_module
--with-http_ssl_module --with-http_stub_status_module
--without-mail_pop3_module --without-mail_imap_module
--without-mail_smtp_module --with-http_geoip_module
--add-module=../ngx_cache_purge-2.3/ --with-file-aio
--with-http_image_filter_module --with-http_realip_module
Чего не хватает котенку?
___
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
___
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
Re: Странное с set_real_ip_from
Opera использует заголовок X-Forwarded-For для передачи адреса клиента, а не X-Real-IP как nginx ожидает по-умолчанию. Добавьте: > real_ip_headerX-Forwarded-For; > http://nginx.org/ru/docs/http/ngx_http_realip_module.html#real_ip_header 02.07.16 12:45, Vladimir Sopot пишет: > Привет! > > В nginx.conf есть > > set_real_ip_from 185.26.180.0/22; > fastcgi_param REMOTE_ADDR $remote_addr; > > Но при этом до php-fpm доходит > > $_SERVER["REMOTE_ADDR”]=185.26.182.31 > > nginx version: nginx/1.10.1 > built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) > built with OpenSSL 1.0.1e-fips 11 Feb 2013 > TLS SNI support enabled > configure arguments: --without-http_uwsgi_module --without-http_scgi_module > --with-http_ssl_module --with-http_stub_status_module > --without-mail_pop3_module --without-mail_imap_module > --without-mail_smtp_module --with-http_geoip_module > --add-module=../ngx_cache_purge-2.3/ --with-file-aio > --with-http_image_filter_module --with-http_realip_module > > Чего не хватает котенку? > > ___ > 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
