Доброго времени суток! Передаю в php два заголовка: proxy_set_header 'User-IP' $remote_addr; proxy_set_header 'BIN-IP' $binary_remote_addr; Соответственно, на стороне php ловлю их: $_SERVER ['HTTP_USER_IP'] $_SERVER ['HTTP_BIN_IP'] Параллельно пишу значение $binary_remote_addr в лог nginx.by CoDDoC - Nginx Mailing List - Russian
Да, спасибо. До переименования зоны я уже догадался. Но не сразу заметил. Экспериментировал с довольно сложным SSI, пришлось часто заглядывать в кэш, многоуровневый оказался неудобен, переключил в один уровень, вот толькby CoDDoC - Nginx Mailing List - Russian
nginx-debug -v nginx version: nginx/1.15.6 Специально обновился, до этого была версия 1.13.12, там то же самое. Изменение levels в proxy_cache_path применяется только после полного рестарта (service nginx-debug restart) nginx-debug -s reload ожидаемого результата не дает Каby CoDDoC - Nginx Mailing List - Russian
Не знаю насчет бредовости, но такое ощущение. что вы не совсем четко ее понимаете для себя. 1. Пользак - админ на своем ВПС. Вы - админ хоста. 2. Если пользак имеет доступ ФТП к директории /home/admin на ВПС, он может слить себе люby CoDDoC - Nginx Mailing List - Russian
Как-то все больше запутывается. Если речь о ВПС - так это один сервер на одного пользака, остальные туда доступа не имеют. https://ru.wikipedia.org/wiki/VPS Или речь о нескольких пользаках в рамках одной ЦМС на одном физическом серверby CoDDoC - Nginx Mailing List - Russian
По-моему, вы слишком усложняете. При чем здесь вообще фтп? И какие файлы пользак не должен скачивать? ПХП? Так в данном случае у него как раз есть такая возможность. ХТМЛ? - А как иначе у пользака должен работать веб интерфby CoDDoC - Nginx Mailing List - Russian
И вам не хворать. УФФ... Во-первых, конструкция if не содержит ветки else. В ПРИНЦИПЕ! Во-вторых, если не понимаете, как работает if, лучше не юзайте, словите кучу проблем. То же самое относится к try_files. В-третьих, как минимум, вамby CoDDoC - Nginx Mailing List - Russian
Ааааа... голова дырявая. Забыл про types. Спасибо. >Понедельник, 19 февраля 2018, 19:26 +03:00 от Maxim Dounin <mdounin@mdounin.ru>: > >Hello! > >On Mon, Feb 19, 2018 at 06:18:52PM +0300, CoDDoC wrote: > >> Доброе время суток! >> >> Есть такой локейшен: >> locatioby CoDDoC - Nginx Mailing List - Russian
Доброе время суток! Есть такой локейшен: location ~ "^/img/" { internal; } Естественно, прямой запрос 'GET /img/file.jpg' получает 404 Все хорошо, но нужно вместо стандартной nginx страницы отдать кастомную. Можно решать разными способами,by CoDDoC - Nginx Mailing List - Russian
Третий и последний раз повторяю, хотите, чтобы вам помогли - обозначайте ВСЕ части конфига, отвечающие за проблему. То, что по вашему мнению должно работать, но не работает. Вы видите разницу в ваших локейшенах? Апстрим bacby CoDDoC - Nginx Mailing List - Russian
Да, сопоставима. Просто вы об этом ничего не сказали. Насчет опции -s и прочих можете посмотреть nginx -h Будет что-то типа: nginx version: nginx/1.13.8 Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives] Options: -?,-h : this help -v : shby CoDDoC - Nginx Mailing List - Russian
Вам обязательно 'service nginx restart'? 'nginx -s reload' пробовали? Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже пофиксили? >> Два интерфейса внешний и локальный. Везде ip - внешний ip. >> Проксирование идёт по локалке. >by CoDDoC - Nginx Mailing List - Russian
А..., вон оно как... А я голову сломал, почему локейшены откуда-то с середины выдергиваются. Еще раз спасибо. >Понедельник, 12 февраля 2018, 17:17 +03:00 от Maxim Dounin <mdounin@mdounin.ru>: > >Hello! > >On Mon, Feb 12, 2018 at 04:58:32PM +0300, CoDDoC wrote: > >>by CoDDoC - Nginx Mailing List - Russian
>> location /456/ оказался в корне дерева, и поэтому проверяется первым. А почему именно этот? Можно поподробнее? Спасибо. >Понедельник, 12 февраля 2018, 16:52 +03:00 от Maxim Dounin <mdounin@mdounin.ru>: > >Hello! > >On Mon, Feb 12, 2018 at 04:31:18PM +0300, CoDDoCby CoDDoC - Nginx Mailing List - Russian
Доброе время суток! Слегка запутался в порядке обработки локейшенов. Такая структура: /1/index.html /23/index.html /456/index.html /7890/index.html Все файлы index.html, естественно, разные. Соответственно, тестовый конфиг: server { .... location = /1/ { reby CoDDoC - Nginx Mailing List - Russian
Насчет уровня location не проверял, но точно проверено, что 'access_log off' в уровне server глушит все access_log уровня http Думаю, с location будет то же самое >Пятница, 9 февраля 2018, 16:26 +03:00 от Ruslan Ermilov <ru@nginx.com>: > >On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slby CoDDoC - Nginx Mailing List - Russian
Да, спасибо, уже разобрался "методом научного тыка". ИМХО, неплохо было бы это в доках указать >Пятница, 9 февраля 2018, 16:01 +03:00 от Maxim Dounin <mdounin@mdounin.ru>: > >Hello! > >On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote: > >[...] > >> accessby CoDDoC - Nginx Mailing List - Russian
Доброе время суток! nginx/1.13.8 Случайно обнаружилась непонятка. Конфиг 1: http { .... log_format f1 '[$time_local - 1]'; log_format f2 '[$time_local - 2]'; access_log /var/log/nginx/1.log f1; access_log /var/log/nginx/2.log f2; server {by CoDDoC - Nginx Mailing List - Russian
Доброго времени суток! nginx/1.13.8 Тестовый сервер, 2 ядра. В конфиге 'worker_processes auto' или 'worker_processes 2' - без разницы pstree дает такую картину: nginx───2*] 32 воркера на каждый из двух Куда копать? --_______________________________________________ nginx-ru mailing lby CoDDoC - Nginx Mailing List - Russian
Доброе время суток! nginx -V показывает вкомпиленные модули. А как, без просмотра конфига, оперативно посмотреть, какие динамические модули загружены директивой load_module? Что-то типа php -m, apachectl -M. --_______________________________________________ ngby CoDDoC - Nginx Mailing List - Russian
Вот в той документации-то я как-раз и запутался. Спасибо. Вопросов нет. >Понедельник, 20 ноября 2017, 17:24 +03:00 от Maxim Dounin <mdounin@mdounin.ru>: > >Hello! > >On Mon, Nov 20, 2017 at 04:43:05PM +0300, CoDDoC wrote: > >> Ладно, с этим разберусь. >> Еще толby CoDDoC - Nginx Mailing List - Russian
Ладно, с этим разберусь. Еще толику Вашего времени... Не совсем в тему, но почти. О выборе секции server для обработки запроса. Я слегка запутался, что от чего зависит: $host от $server_name или наоборот? Вот как я это понимаю. 1. Сначалby CoDDoC - Nginx Mailing List - Russian
Это я понял. Бот дернул запрос и быстро сбежал, чтобы не попасть в бан. Однако-же попал :) Как мне эмулировать такую ситуацию? >Понедельник, 20 ноября 2017, 15:34 +03:00 от Maxim Dounin <mdounin@mdounin.ru>: > >Hello! > >On Mon, Nov 20, 2017 at 02:57:13PM +030by CoDDoC - Nginx Mailing List - Russian
Доброго дня! Собственно, классическая секция server, принимающая запросы с неправильным $host: server { listen <IP сервера>:80 default_server; listen <IP сервера>:443 default_server; server_name _; return 444; access_log .... здесь лог, что попадетby CoDDoC - Nginx Mailing List - Russian
Доброго времени суток! Подскажите, плиз, где можно почитать нормальную документацию про сообщения в дебаг логе. Перерыл весь гугол, ничего толком нет. Честно, надоело играть в угадайку. Например, что означают такие запиby CoDDoC - Nginx Mailing List - Russian
А вот интересно, от ботов тоже будем требовать соблюдения RFC? Я воспроизвел ситуацию, как создать бесполезную нагрузку на сервер при бесконечном редиректе. Правильно я делаю запрос или нет - в данном случае не важно. Важby CoDDoC - Nginx Mailing List - Russian
Ну, хорошо. Пусть в моем примере вообще нет хоста. Тогда что такое https://test.com ? Давайте назовем строкой запроса, суть проблемы от этого не меняется. В документации так: " $host в порядке приоритета: имя хоста изby CoDDoC - Nginx Mailing List - Russian
Спасибо. Только Вы говорите об URI "/", а вопрос был об URL, точнее - о зацикливании, связанном с неправильной (ИМХО) интерпретацией в ngx переменной $host. Как она ДОЛЖНА обрабатываться - сказано в доке, что имеем ПО ФАКТУ - вby CoDDoC - Nginx Mailing List - Russian
Доброго дня сообществу! Прошу совета по проблеме. Собственно, редирект с www на https без-www server { #1 http to https without www listen 1.2.3.4:80; server_name www.test.com test.com; rewrite ^ https://test.com$request_uri? permanent; } server { #2 https with www to https without www listby CoDDoC - Nginx Mailing List - Russian