Автогенерация Access log пути в nginx

#nginx

                    
На сервере лежит несколько файлов для скачивания, которые удовлетворяют regex location:location
~* /(en/ru)/([a-zA-Z0-9\-]+)/([a-zA-Z0-9\-]+\.exe){    access_log /var/www/logs/any.access.log}Файлов
не так много (около 10), поэтому хотелось бы для каждого скачивания иметь собственный
лог файл. Как можно использовать $1, $2, $3 из location выражения для формирования
пути к лог файлу?Например:для файла /en/disk/disk-setup.exe я хочу лог файл /var/www/logs/disk-setup.exe.access.logи
так далее.    

Ответы

Ответ 1

access_log /var/www/logs/$uriНо, учитывайте слэши в пути файла и другие дурацкие символы.

Nginx не могу настроить ЧПУ

#nginx #php #чпу

                    
Здравствуйте, у меня такая проблема. Не могу никак получить ссылки вида "/hello/world/".
Если пишу 
location {
    try_files $uri $uri/ /index.php/$request_string;
}

тогда попытка попасть на example.ru/hello/world/ вызывает 500 Internal Server Error.
если перехожу на example.ru/?hello=world тогда все проходит без ошибок.
Сколько примеров посмотрел, ничего не получается.    

Ответы

Ответ 1

location / {
        index  index.html index.php;
        try_files $uri $uri/ /index.php?$args;
    }

Это точно работает.

“/var/run/nginx.pid” failed (2: No such file or directory)

#nginx #debian

                    
Раньше NGinx работал нормально, теперь такая ошибка:

nginx: [error] open() "/var/run/nginx.pid" failed (2: No such file or directory)


Часть nginx.conf:

user debian;
worker_processes 4;
pid /var/run/nginx.pid;


Раньше всё работало, что с ним случилось?



из комментариев:

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] open() "/home/user/logs/nginx.access.log" failed (2: No such file
or directory)
nginx: configuration file /etc/nginx/nginx.conf test failed

    

Ответы

Ответ 1

ответ из комментария:


То, что не может найти nginx.pid - это не главная проблема, это ее последствия в
виде того, что nginx не смог стартовать. В .pid-файлах хранят просто идентификатор
процесса, не более.
Для nginx невозможность открыть лог является фатальной ошибкой. Он действительно
не может достучаться до файла, и поэтому отказывается стартовать. Для возвращения к
нормальной жизни надо либо создать эту папку с необходимыми разрешения доступа, либо
в конфиге поправить расположение лога.


Ответ 2

проверьте запущен ли nginx

sudo service nginx status


Если не запущен

sudo service nginx start


Команда для проверки конфигурации

sudo nginx -t


Ответ 3

Попробуйте:

sudo nginx -s quit
sudo nginx
sudo nginx -s reopen
sudo nginx -s reload

как воспользоваться сертификатами от проекта let's encrypt?

#apache #nginx #ssl #сертификат #letsencrypt

                    
с 3 декабря 2015 года проект let's encrypt перешёл в режим "public beta".

как воспользоваться сертификатами, выдаваемыми этим проектом?
    

Ответы

Ответ 1

можно воспользоваться любой из реализаций клиентов, работающих с системой let's encrypt.

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



но мне понравился минималистичный shell-скрипт из репозитория lukas2511, который
не требует ни повышенных привилегий для своей работы, ни установки дополнительных программ/пакетов
(всё необходимое обычно уже имеется в любой «серверной» установке: bash, openssl, curl
и утилиты из coreutils).

как я настроил этот клиент


для пущей безопасности я создал пользователя letsencrypt (без пароля):

$ sudo adduser --disabled-password letsencrypt

открыл сеанс оболочки от имени этого пользователя:

$ sudo -u letsencrypt -i
letsencrypt@host:~$

склонировал репозиторий со скриптом и «перешёл» в созданный каталог:

$ git clone https://github.com/lukas2511/letsencrypt.sh.git
$ cd letsencrypt.sh


если git не установлен, можно скачать архив с файлами и распаковать.
скопировал образцовый конфиг:

$ cp config.sh.example config.sh

создал файл domains.txt для домена (мне требуется, чтобы в сертификате были имена
и с www и без):

domain.tld www.domain.tld


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

$ mkdir .acme-challenges

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

в настройках http-сервера надо прописать alias для /.well-known/acme-challenge, чтобы
он указывал на созданный в предыдущем пункте каталог. ориентировочно это будет /home/letsencrypt/letsencrypt.sh/.acme-challenges.


для nginx в секцию server надо добавить location:

location /.well-known/acme-challenge {
  alias /home/letsencrypt/letsencrypt.sh/.acme-challenges;
}

для apache в секцию virtualhost надо добавить строку:

alias /.well-known/acme-challenge /home/letsencrypt/letsencrypt.sh/.acme-challenges



это надо проделать для всех доменов (точнее, отдельных строк в созданном вами файле
domains.txt).

http-сервер после этого надо перезапустить.
теперь можно запускать скрипт для генерации сертификата(-ов). вернитесь к окну, где
открыта оболочка, запущенная от имени пользователя letsencrypt (или запустите новую
и перейдите в каталог со скриптом):

$ ./letsencrypt.sh -c


если всё пойдёт нормально, последней строкой выдачи будет:

 + Done!

сертификат и ключ для домена сгенерированы и лежат в каталоге /home/letsencrypt/letsencrypt.sh/certs/domain.tld:

cert.pem
privkey.pem


в принципе, это symlink-и на актуальные версии этих файлов, которые лежат в том же
каталоге и в названии которых присутствует метка времени. типа cert-1453143084.pem.
теперь можно прописывать эти файлы в настройках http-сервера:


файл с сертификатом: /home/letsencrypt/letsencrypt.sh/certs/domain.tld/cert.pem
файл с ключом: /home/letsencrypt/letsencrypt.sh/certs/domain.tld/privkey.pem

обновление сертификатов производится точно так же, как и генерация: от имени пользователя
letsencrypt перейдите в каталог со скриптом и запустите скрипт с тем же самым параметром
— ./letsencrypt.sh -c.

можно создать соответствующую cron-задачу, которая через пару месяцев (сертификаты
генерируются на 90 дней) выполнит скрипт (от имени этого пользователя и в нужном каталоге)
и перезапустит http-сервер.


Ответ 2

Центр сертификации Let's Encrypt использует протокол Automated Certificate Management
Environment. Получать сертификат лучше с помощью одного из рекомендованных клиентов.
Моим выбором стал GetSSL. Это простой bash скрипт, который умеет сам себя обновлять.
При работе использует CLI openssl, и значит нет жесткой привязки к версии.

GetSSL автоматизирует процесс получения и продления сертификата с помощью нескольких
команд. Например, чтобы получить сертификат для домена domain.tld:

srv ~ # getssl -c domain.tld
creating main config file /root/.getssl/getssl.cfg
Making domain directory - /root/.getssl/domain.tld
creating domain config file in /root/.getssl/domain.tld/getssl.cfg
srv ~ # getssl domain.tld


Первая команда добавляет домен в список для получения (выполняется единожды), вторая
- для получения сертификата.

В этой статье можно подробнее узнать о процессе получения сертификата с помощью GetSSL.

Связка Nginx и Kestrel - где использовать https?

#c_sharp #nginx #aspnet_core #net_core #kestrel

Есть веб-приложение на .NET Core. По умолчанию в нем используется Kestrel, имеющий
всю необходимую для работы приложения базовую функциональность, в пом числе использование
https. Но сам MS советует использовать другие веб-серверы (IIS, Apache, Nginx) для
расширения возможностей взаимодействия с веб-службами, в т.ч. в качестве reverse proxy.
В связи с чем возник такой вопрос - необходимо ли включать поддержку https в Kestrel,
или же достаточно будет включить ее в Nginx и передавать запросы на Kestrel по http?
Примерный конфиг Nginx в рамках данного вопроса:

server {
    listen 80;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;

    ssl_certificate           /etc/nginx/cert.crt;
    ssl_certificate_key       /etc/nginx/cert.key;

    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    location / {

        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;

        proxy_pass          http://kestrel;
        proxy_read_timeout  90;

    }
}


    

Ответы

Ответ 1

Для работоспособности достаточно включить HTTPS на Nginx.

HTTPS между реверс-прокси и сервером приложений не обязателен, но его следует использовать
из соображений безопасности. Угрозы такие:


прослушивание TCP трафика
MITM-атаки


Если таких угроз нет, HTTPS между Nginx и Kestrel как таковой не нужен. Сюда можно
отнести такие частные случаи:


оба демона находятся на одном сервере, доступ к серверу только у доверенных
трафик ходит внутри DMZ

nginx прокси для nodeJS

#nodejs #nginx

У меня гостевая машина с установленным Debian GNU/Linux, ip-адрес вот такой 10.0.2.15.
Я хочу поставить nginx + nodeJS. Мне нужно настроить прокси так, чтобы когда я ввожу
любой адрес кроме 10.0.2.15/node отдавалась статика посредством nginx, а когда я напишу
10.0.2.15/node запрос попадал на node.

Вот конфиг nginx.conf, в директиве http:

server {
    #ip:порт который будем слушать
    listen 10.0.2.15:80;

    #перенаправление на NodeJS
    location /node {
        #ip:порт nodeJS
        proxy_pass http://10.0.2.15:8080;
        proxy_set_header Host $host;
    }

    #всё остальное отдает nginx
    location / {
        #путь к каталогу веб сервера
        root /home/dirtez/www;
    }
}


Всё работает, если набираю например 10.0.2.15/index.html - нормально(есть ли файл
есть), 10.0.2.15/foo - 404 (файла нет, всё правильно). И node работает, если набрать
10.0.2.15/node. Но проблема в том что он работает, если набрать и nodes и nodeasdas,
также node/sdad, также nodeasd/asd.

Как сделать чтобы node запускался только при 10.0.2.15/node?
    

Ответы

Ответ 1

Можно написать location = /node тогда только для запросов к /node, второй вариант:
location /node/ - но в последнем я не уверен.

Как сделать в nginx переадресацию на мобильную версию?

#nginx

Необходимо сделать переадресацию на мобильную версию сайта расположенную по адресу
site.com/m , но при этом, если заходит на site.com/full то не зависимо должен переадресовывать
на site.com/
Нашел такое решение

set $mobile_request false;
            if ($http_user_agent ~* "(windows\smobile|windows\sce|iphone|ipod|midp|symbian|series\s60|s60|nokia|аndroid|
blackberry|Android)"){
                    set $mobile_request true;
                            }
         rewrite ^(/full)(.*)$ \#$2 permanent;
            if ($mobile_request = true) {
                    return 301 /m$request_uri;
                            }


но тут если зайти с телефона, то на site.com не переадресовывает.
Подскажите какое-то решение.
    

Ответы

Ответ 1

set $mobile_rewrite do_not_perform;

if ($http_user_agent ~* "(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge
|maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows
ce|xda|xiino") {
  set $mobile_rewrite perform;
}

if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r
|s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1
u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp(
i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt(
|\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-|
|o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v
)|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-|
)|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)") {
  set $mobile_rewrite perform;
}

if ($mobile_rewrite = perform) {
  rewrite ^ http://site.com/ redirect;
  break;
}


Ответ 2

у меня получилось сделать, правда пришлось использовать для мобильной версии отдельный
домен.

   server {
listen 443 ssl;
server_name site.com;


location /full {
    set $mobile_request 0;
    rewrite ^/full(.*)$ $1 break;
}
}

location / {
    set $mobile_request 1;
    if ($http_referer ~* "https://(.*).site.com/") {
        set $mobile_request "0";
            }
    if ($http_user_agent ~* "(windows\smobile|windows\sce|iphone|ipod|midp|symbian|series\s60|s60|nokia|аndroid|
blackberry|Android)"){
        set $mobile_request "${mobile_request}1";
            }
    if ($mobile_request = 11) {
        set $mobile_request "0";
        return 302 https://m.site.com/;
            }

}


}
server {
  listen 443;
  server_name m.site.com;


location / {
    ...

}
location /full {
return 301 https://site.com$request_uri;
}
}


возможно кому-нибудь пригодится :)

Страница доступная по IP адресу сервера

#linux #apache #nginx

Есть VPS с установленной на нём Plesk панелью (хотя панель, вероятно, значения не имеет).
На сервере висит несколько сайтов, если перейти не по одному из доменов, а по IP-адресу
сервера, то открывается по-умолчанию тот сайт, который был добавлен на сервер последним.

Как установить сайт/страницу открываемую по-умолчанию при переходе напрямую по IP-адресу
сервера? Сервер Linux (Apache + Nginx)
    

Ответы

Ответ 1

В общем-то ответ в случае с Plesk прост:


Необходимо зайти в "Инструменты и настройки" (Tools & Setting)
Перейти в "IP-адреса" (вкладка "Инструменты и ресурсы")
Открыть нужный IP-адрес
Выбрать подписку по-умолчанию.


При попытке изменить конфигурацию Nginx сервер выдаст ошибку (так как в Plesk эта
настройка уже существует).


Ответ 2

Указываете конфигурацию Nginx по умолчанию для 80 порта:

server {
    listen 80 default;
    root /default/site/path;
    ...
    location site_1 {
        ...
    }
    location site_2 {
        ...
    }
}


Если идет проксирование на Apache, то там ничего менять не надо, просто определяем
директории на которые идут запросы с Nginx.

Для чего нужна “@” в location'е (NGINX)?

#nginx #docker #microservices

Объясните пожалуйста, для чего применяется символ @ внутри конфигурационного файла
nginx при указании пути и о чем говорит данный кусок кода:

location @web {
  proxy_pass http://web:3000;
}

    

Ответы

Ответ 1

Префикс “@” задаёт именованный location. Такой location не
  используется при обычной обработке запросов, а предназначен только для
  перенаправления в него запросов. Такие location’ы не могут быть
  вложенными и не могут содержать вложенные location’ы.


Документация

Как проверить, является ли apache бэкэндом для nginx?

#ubuntu #apache #nginx #ssh

Есть сервер на Ubuntu 14.04.3, и к нему есть доступ по SSH.
На сервере установлен nginx/1.4.6 и Apache/2.4.7

Но вот в чем вопрос. Работают ли в паре Nginx+Apache?
То есть, является ли nginx «фронтэндом», а apache «бэкэндом»?

Есть ли какая нибудь ssh-команда, которая бы показала это?
    

Ответы

Ответ 1

можно воспользоваться такой командой:

$ sudo lsof -Pn -iTCP -sTCP:LISTEN -c nginx -c apache -c httpd -a


и проанализировать её вывод. пример (реальный сервер, часть строк опущена для наглядности):

COMMAND   PID                USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
apache2  2206                root    3u  IPv4 58834967      0t0  TCP 127.0.0.1:8080
(LISTEN)
apache2 13377            www-data    3u  IPv4 58834967      0t0  TCP 127.0.0.1:8080
(LISTEN)
nginx   13289                root    6u  IPv4 58829785      0t0  TCP *:80 (LISTEN)
nginx   13289                root    7u  IPv4 58829786      0t0  TCP *:443 (LISTEN)
nginx   13624            www-data    6u  IPv4 58829785      0t0  TCP *:80 (LISTEN)
nginx   13627            www-data    7u  IPv4 58829786      0t0  TCP *:443 (LISTEN)


из него видно, что nginx слушает 80-й и 443-й порты на всех адресах (*:80 и *:443),
а apache — лишь порт 8080 и только на адресе 127.0.0.1 (127.0.0.1:8080).

откуда вытекает вполне логичный вывод: nginx слушает внешние обращения и (возможно)
передаёт (некоторые из них) apache-у.



«расшифровка» использованных опций программы lsof:


-P — отображать номера портов, а не имена, взятые из файла /etc/services
-n — отображать ip-адреса, не пытаясь преобразовать их в доменные имена
-iTCP -sTCP:LISTEN — отобразить процессы, слушающие tcp-порты
-c nginx -c apache -c httpd — отобразить процессы, начинающиеся с этих строк
-a — логическое and для параметров (правда, не для всех: в данном случае применяется
для «связывания» -iTCP и -c имя). если его опустить, то будут выведены ещё и открытые
указанными (с помощью опций -c) процессами файлы (вообще программа lsof в первую очередь
для отображения открытых файлов и писалась).


Ответ 2

Можно посмотреть, кто какие порты слушает:

sudo lsof -i | grep LISTEN


Напр. у меня выводит что-то вроде:

nginx     22633     root   27u  IPv4 82311419      0t0  TCP *:http (LISTEN)
nginx     22633     root   28u  IPv4 82311420      0t0  TCP *:https (LISTEN)
nginx     22635   nobody   27u  IPv4 82311419      0t0  TCP *:http (LISTEN)
nginx     22635   nobody   28u  IPv4 82311420      0t0  TCP *:https (LISTEN)


Тут видно, что по портам 80 (http) и 443 (https) слушает nginx. Т.е. обращения к
вашему серверу по этим портам принимает он.

А Apache, в случае если nginx проксирует соединения к Apache, слушает на порту 8080,
или другом «нестандартном». Посмотрите всю подряд инфу о портах:

sudo lsof -i


или grep'ом выделите оттуда только "apache2" или 'httpd" или как там ещё могут называться
процессы Apache.

А потом можно отправиться смотреть конфиги nignx и Apache подробнее.

Нужен ли nginx для node.js сервера?

#nodejs #nginx

Нужно ли ставить nginx перед нодой?

У нас в компании занимаются поиском Т-функции у новичков, и поэтому на новый проект
я назначен главным backdoor разработчиком.

До этого ребята у нас ставили nginx перед нодой
и имели, с моей точки зрения кучу, проблем и неявных состояний.
Например между nginx и нодой рвется ws соединения, но nginxs об этом никому ничего
не говорит.
А между клиентом и nginx соединение в порядке, но данные почему-то не приходят.
Пришлось городить свой пинг-понг.  

На мой вопрос, а зачем вам вообще nginx, мне ответили что:
1) ничто так быстро не отдает статику как nginx;
2) в конце концов все всегда так делают.  

Ну статику мы отдаем клиенту 1 раз и ее не так уж много.
А вот json'ы потом гоняем туда-сюда сутками, сгусями и с прочими птицами.
А по поводу того, что nginx отдает статику так быстро потому, что он ее никак не
обрабатывает,
а видит из запроса что это "просто" статика и "просто" отдает ее (так мне объяснили) -
разве написав

арр.use(express.static( path.join(__dirname, '/static') ))


я не "просто" отдаю статику, никак ее не обрабатывая?

На своем проекте я пока стучусь непосредственно на ноду.
Прав ли я? Рационально ли это?
Или меня в будущем ждут непредвиденные трудности? На данном уровне моей квалификации
мне кажется, что стучаться сразу на ноду - это само собой напрашивающийся шаг к отказу
от ненужного усложнения системы и от ненужной прослойки. Действительно ли прослойка
в виде nginx - ненужная?

Буду благодарен услышать Ваши комментарии.
    

Ответы

Ответ 1

Да, nginx добавляет сложности, требуя настроить себя, но по-моему это с лихвой компенсируется
получаемыми плюшками.

Масштабируемость

Работать с одной-единственной нодой получится только до тех пор, пока на сервере
находится один-единственный сайт. Однако в моей практике такого не было почти никогда:
я как минимум ставлю ещё Munin для наблюдения за состоянием сервера. Придётся или вешать
сайт на отдельный порт/айпишник (неудобно), или дописывать в ноде код для проксирования
запросов на другой сайт (замусоривание кода всякими сложностями). В то время как в
nginx новый сайт легко подключить парой строчек в конфиге.

Ещё один пример — A/B тестирование: запускаем две разные версии сайта, половину пользователей
направляем на одну версию сайта, половину на другую, сравниваем их поведение и решаем,
какая версия сайта лучше. Если изменения значительные, то скорее всего придётся запустить
две ноды, и опять же нужно каким-то чудом решать, какой пользователь на какую ноду
будет отправлен. Опять же в nginx это делается парой строчек (split_clients).

Когда сайт станет большой и популярный, нода может перестать помещаться в одном процессе
или одном сервере, и придётся запускать несколько экземпляров ноды или даже докупать
новые серверы. nginx позволит равномерно распределить нагрузку между процессами/серверами,
принимая все запросы на себя и пересылая его на один из случайно выбранных процессов/серверов
(или не случайно — смотря как настроить).

Безопасность

Использовать стандартные порты 80/443 может только root. А когда код сайта запускается
от рута, это ОЧЕНЬ плохо: малейшая RCE-уязвимость — и злоумышленник без проблем получает
полный доступ к серверу. Если нода будет работать от рута, то малейшая уязвимость в
коде сайта может позволить с лёгкостью получить контроль над сервером целиком (как
с помощью RCE, так и с помощью чтения какого-нибудь ../../../../../../etc/shadow и
последующего подбора пароля от рута в оффлайне, например).

В идеале код должен быть максимально изолирован от всего (вплоть до помещения в изолированный
Docker-контейнер (ходят слухи, что докер ещё и для разработки и развёртывания очень
удобен, но я не верю)). Если нода будет изолирована от всех, то максимум, что получит
злоумышленник — контроль над нодой. Ну и доступ к базе данных, если она используется.
Это плохо, но не совсем плохо, потому что взломанную ноду можно просто выключить до
исправления уязвимости. А вот выпнуть злоумышленника, получившего root, будет уже гораздо
тяжелее (вплоть до необходимости отключения сервера от интернета и полной переустановки
системы).

Но, допустим, вы перекостыляли с роутингом или форками или пропатчили ядро или ещё
что-то и в итоге каким-то чудом умудрились поднять ноду на порту 80/443 без root. Тогда
пришло время вспомнить про HTTPS и сертификаты для него. Для работы SSL/TLS ноде нужен
будет доступ к приватному ключу, и опять же, если злоумышленник откопает RCE-уязвимость,
то он сможет прочитать приватный ключ и начать организовывать MitM-атаки. Если же HTTPS
будет настроен на nginx и доступ к приватному ключу будет только у nginx, то злоумышленник
обломается. (Хотя, конечно, налажать могут всегда и везде, даже у nginx+openssl однажды
утекали приватные ключи... поэтому переходим на libressl)

Кроме того, есть ряд менее серьёзных атак, которые всё же могут подпортить нервы.
Например, манипуляции с медленными HTTP-запросами. В nodejs была уязвимость CVE-2013-4450,
позволяющая завалить её HTTP pipelining запросами и тем самым скушать ресурсы сервера.
Теоретически подобное, конечно, может найтись и в nginx, но всё же сама его архитектура
неплохо спасает от подобных пакостей. При наличии nginx на ноду уже будут приходить
белые и пушистые HTTP-запросы, доставляющие минимум проблем, в то время как всякий
мусор будет отфильтрован или забуферизован самим nginx'ом. (Хотя от терабитных DDoS-атак
ничего не спасёт, но не будем о грустном)

Прочие плюшки

Обязательно будут моменты, когда нода не будет работать (например, она может быть
просто выключена на техработы). Без nginx пользователи получат просто какую-то невнятную
ошибку браузера, уведомляющую о невозможности подключения. С nginx можно отдать статическую
страницу с более понятным описанием ошибки и предложением сообщить о проблеме администраторам
сайта, или же повесить плашку техработ и предложение подписаться на твиттер.

Про вебсокеты

Непонятно, что у вас за проблемы были — без подрбоностей понять, кто виноват и что
делать, трудно; у меня всё проксируется через nginx вполне стабильно. А пинги должны
быть в любом случае, потому что отвалиться по таймауту может что угодно где угодно
даже не на вашем сервере (например, мобильный оператор Теле2 обрубает TCP-соединения
после пяти минут бездействия). «Городить свой пинг-понг» не нужно, потому что эта фича
встроена в протокол — не знаю, как именно вы реализуете вебсокеты в ноде, но пинги
где-то там наверняка уже должны быть.


Ответ 2

Например между nginx и нодой рвется ws соединения, но nginxs об этом
  никому ничего не говорит. А между клиентом и nginx соединение в
  порядке, но данные почему-то не приходят.


Видимо, криво настроили.


  1) ничто так быстро не отдает статику как nginx;


Правда.


  я не "просто" отдаю статику, никак ее не обрабатывая?


Вы считываете файл средствами node.js и отдаёте в стрим. nginx, который на такие
вещи заточен, явно будет быстрее.


  На своем проекте я пока стучусь непосредственно на ноду. Прав ли я?


Возможно пока правы.


  Рационально ли это?


Если сервис только для себя, то возможно.


  Или меня в будущем ждут непредвиденные трудности?



При росте нагрузок как будете масштабировать? Если бы вы использовали nginx, то могли
бы поднять несколько node.js сервисов на разных портах, а балансили бы их с помощью nginx.
Если ваш сервис упадёт, что будете делать?
Если понадобится SSL соединение, что будете делать?


К тому же, если понадобится для статики в будущем CDN, то они очень хорошо умеют
работать с nginx.

Помогите правильно настроить nginx

#nginx

Пытаюсь поставить медиа сервер на ubuntu, делаю все как здесь.

но в конце, при выполнении команды

sudo /usr/local/nginx/sbin/nginx
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:1935 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:1935 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:1935 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:1935 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:1935 failed (98: Address already in use)
nginx: [emerg] still could not bind()


перерыл кучу форумов и статей в гугле, но ничего не помогает.

как это исправить?
    

Ответы

Ответ 1

перерыл кучу форумов и статей в гугле, но ничего не помогает.


потому что достаточно просто перевести фразу


  bind() to 0.0.0.0:80 failed (98: Address already in use)


(привязка к 0.0.0.0:80 завершилась неудачей: адрес уже используется)

У вас что-то (99% что апач) уже висит на восьмидесятом порту и блокирует подъем еще
одно сервиса там же. Чтобы nginx стартовал, ему надо либо поменять порт, либо прибить
апачелло.


Ответ 2

У Вас nginx стартует на 80 порту,который уже слушает какое то приложение в системе.
Попробуйте прибить процесс:

sudo fuser -k 80/tcp


И перезапустить nginx.


Ответ 3

Попробуй sudo nginx -s stop а затем sudo nginx. Перед этим еще можно sudo srvice
nginx stop и затем sudo service nginx start.

Регулярные выражения в nginx

#регулярные_выражения #nginx

При гуглении регулярных выражений мне попадаются только огромные статьи и толстые
книги. А мне надо только понять как работает это:

 location ~* ^.+\.\w+$ {
     root /home/box/web/public;
 }


Окей. Начал читать книгу, закончил три главы уже, а полного понимая того, что написано
выше все еще нет и, судя по всему, если идти таким путем, то не скоро будет. 

Не могли бы вы просто в двух словах объяснить символику этого примера.
    

Ответы

Ответ 1

^ - означает, что соответствие будет искаться с начала строки, а не с любого символа.
Выражение /box/ будет соответствовать и box-web и home-box-web, а /^box/ только первой
строке.

$ - означает привязку к концу строки /index\.php/ будет соответствовать и site.ru/index.php
и site.ru/index.php?v=3, выражение /index\.php$/ будет соответствовать только первому
варианту.

.+ - любое количество символов. Точка - любой символ, комбинация .+ - один или больше
любых символов.

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

\w - любой символ, который может составить слово \w+ - любое количество таких символов
(один или больше).

Т.е. выражение ^.+\.\w+$ охватывает почти любой URL. Прицел изначально был на выражения
вида hello/index.php.

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

Yii memcache http

#memcached #php #yii #nginx

Итак необходимо реализовать следующее:
Yii пишет в кеш данные, а далее данные должны быть доступны по адресу:
site.ru/_stat/ключ кеша 
В качестве сервера у нас нгинкс, ос: центОс. 
Итак:
if(!Yii::app()->cache->set($GameProposalModel->proposal_id, 'renderTable('.json_encode($toCache).')'))

Я записываю данные в кеш, к примеру ключ будет равен 30 ($GameProposalModel->proposal_id
= 30)
Далее идем на нгинкс:
   location /_stat {
        set            $memcached_key "$uri?$args";
        memcached_pass 127.0.0.1:11211;
        error_page     404 502 504 = @fallback;
        add_header Content-Type "text/html; charset=utf-8"; 
    }

    location @fallback {

        proxy_pass  http://localhost:9000;
    }

Далее я так прикинул, что по ссылку site.ru/_stat/30 я должен получить данные моего
кеша. 
Но я получаю только 502 Bad Gateway
Пример из
http://nginx.org/ru/docs/http/ngx_http_memcached_module.html
Подскажите пожалуйста в чем проблема ?    

Ответы

Ответ 1

Вы делаете запрос к сайту site.ru/_stat/30 .
Запрос обрабатывает ядро YII - отвечает за это UrlManager согласно настройкам. Также
необходимо глянуть что находиться в .htaccess.
После работы UrlManager вызывается контроллер, выбирается его действие - передаются
в действие все параметры - и действие выполняется.

Поэтому вам нада в контроллере делать действие отвечающие за выборку кэша из memcached
и отдачу его клиенту

Как настроить доступ к web-серверу в локальной сети?

#nginx #debian #домен #роутер #adsl

Тема "избитая", но не нашёл решение, прошу помощи у грамотных людей. Что есть:


Домен: mydom.com
Статический IP от провайдера услуги интернет по ADSL: xx.yy.zz.ccc
Роутер D-link DSL-2500u/bru/c под эту услугу
Switch 16port 10/100 
Два компьютера, один под Windows Vista, на втором Debian 8 + nginx.


Оба компьютера и роутер включены в свитч. Интернет работает на обоих.

Что хочу:
Настроить комп. с debian под работу сайта на своем домене mydom.com. Пока только
осваиваю тему, навыков нет.

Что сделал:
Привязал к домену статический IP. Убедился на стороннем ресурсе, что при вводе домена
показывает мой IP (xx.yy.zz.ccc) и другие данные. Далее пишу по компьютеру с Debian.
Есть простой файл index.html, его nginx выводит в браузер, при наборе в строке браузера
: http://localhost

Конфиг:

server {
listen   80;
server_name localhost;
...


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

listen   мой_ip:80;
server_name www.mydom.com mydom.com;


должен получить профит. И набрав в строке браузера mydom.com, получить исходный файл,
причём рассчитывал получать его и на компе с Vista.
Дальше всё грустно.

listen   xx.yy.zz.ccc:80; -- не прошел, nginx не запустился (99: Cannot assign  
   requested address).
listen   ccc.zz.yy.xx:80; -- запустился, но 'ловит' роутер.


Пишет: Сайт DSL Router на mydom.com введите имя и пароль. Ну и входит в его админку.
На обоих компах. Сделал проброс 80-го порта в настройках роутера, перебирал еще варианты,
ничего не получилось. 

Вот такой конфиг:

listen  192.168.1.3:80;
server_name www.mydom.com mydom.com;


Также ловит настройки роутера в браузер, при вводе mydom.com, но, если набрать http://192.168.1.3
то возвращает нужный файл html, причем на обоих компах.



Вопрос:   Как правильно сделать настройки, чтобы получить рабочую систему?



Похожая тема:
Как настроить веб-сервер через ADSL-модем?
    

Ответы

Ответ 1

Это вполне подходящая настройка, в этой строке не требуется изменений:

listen   80;

Да, в директиве server_name надо указать все имена сервера:

server_name www.mydom.com mydom.com;

Если роутер не умеет отдавать в локальную сеть указанные адреса для указанных доменов,
то на всех компьютерах в локальной сети (с которых нужен доступ к сайту) следует добавить
в /etc/hosts (или в его аналоги в других операционных системах) такую строку:

локальный-ip-адрес-сервера www.mydom.com mydom.com


где локальный-ip-адрес-сервера — адрес, по которому сервер доступен в локальной сети
(192.168.1.3 и т.п.)
Если же роутер умеет так делать, то настроить его на такое преобразование:

mydom.com → локальный-ip-адрес-сервера
www.mydom.com → локальный-ip-адрес-сервера

Для того, чтобы сервер всегда был доступен по одному локальному адресу, надо либо
в настройках роутера закрепить связку локальный-ip-адрес-сервера с его (сервера) mac-адресом,
либо в сетевых настройках сервера указать этот адрес как статический.
Для того, чтобы сервер был доступен извне, в роутере надо настроить проброс 80-го
порта из внешнего мира на локальный-ip-адрес-сервера.

Как распределить нагрузку между серверами с nginx-rtmp-module?

#nginx #rtmp

Подскажите как правильно распределять зрителей между серверами с nginx-rtmp-module?
К примеру есть 3 сервера на каждом установлен nginx-rtmp-module, rtmp поток создается
на первом сервере, как отправить зрителей на 2 сервер если их больше чем может держать
первый и так же со второго на третий.
    

Ответы

Ответ 1

RTMP протокол поддерживает редирект. Т.е. при подключении к серверу, если он не сможет
обслужить клиента, он может его перенаправить дальше. Плюс балансировщик на входе.

Схематически это должно выглядеть так:


в настройках application (терминология RTMP) добавляется http-колбек (терминология
nginx-rtmp) on_connect.
в обработчике этих сообщений нужно принять решение о редиректе и ответить согласно
документации:


  If HTTP 2xx code is returned then RTMP session continues. The code of
  3xx makes RTMP redirect to another application whose name is taken
  from Location HTTP response header. Otherwise connection is dropped.



Ещё интересные колбеки:


on_publish - вызывается при начале публикации стрима на сервер
on_play - вызывается при начале проигрывания стрима с сервера. Он позволяет делать
редирект только внутри тещкущего сервера или создавать remove-proxy к другому серверу,
оставаясь сам на обслуживании данного клиента.


Т.е. копать детально нужно в сторону on_connect.

Как реализовать планирование... Тут вопрос сложный. Как минимум планировщик должен
знать о нагрузке всех серверов и динамически принимать решение о перенаправлении. Можно,
к примеру, мониторить нагрузку каждого сервера:


CPU
Память
Число подключений
Утилизация канала


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

Ещё нюансом может стать то, что документация на on_connect не говорит явно, что будет,
если в Location вернуть полный путь с rtmp://.... Нужно изучать исходники или спрашивать
в рассылке или у автора в почте.

Если такой редирект не поддерживается, то можно попытаться решить вопрос при помощи
балансировщиков типа Balance NG или HAProxy. Подобный пример даже рассмотрет в официальном
блоге: http://blog.haproxy.com/2012/09/21/high-available-rtmp-platform-with-haproxy-and-crtmpserver/.
Единственно, нужно как-то привязать ваш супер-визор. Если мне не изменяет память, то
HAProxy можно попросить использовать какой-то скрипт для принятия решения.

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


Ответ 2

Модуль ngx_http_upstream_module позволяет описывать группы серверов, которые могут
использоваться в директивах proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass

Нужно ли настраивать Apache для работы с SSL, если я использую Nginx (proxy) + Apache?

#apache #nginx #ssl

У меня есть сервер с Ubuntu Server 16.04, схема работы веб-сервера стандартная (Apache
+ mod_php + Nginx как прокси)
Настроил Nginx для работы с установленным SSL сертификатом, надо ли тоже самое проделывать
с Apache(имею ввиду настройку Apache для работы с SSL)?
    

Ответы

Ответ 1

Нет не нужно, если запросы идут только на nginx, а так же nginx и apache находятся
на одном сервере.

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

Не удается раздать статику с nginx

#nginx

Сконфигурировал сервер на отдачу статики, получаю "403 Forbidden"

Мой конфиг:


worker_processes  1;
events {
    worker_connections  1024;
}
http{
    server{
        location / {
            root /home/danya/Desktop/data/www;
        }
        location /images/ {
            root /home/danya/Desktop/data;
}   }   }   


Пробовал ходить на http//localhost/index.html , http//localhost/home/danya/Desktop/data/www/index.html ,
http//localhost/home/danya/Desktop/data/images/1.jpg

[danya@stdfx_arch data]$ tree
.
├── images
│   ├── 1.jpg
│   ├── 2.gif
│   └── 3.png
└── www
    └── index.html


/home/danya/Desktop/data

В чем может быть дело?Может я с расположением статики накосячил?
    

Ответы

Ответ 1

пользователь, от имени которого запущен процесс nginx, не имеет доступа к файлам/каталогам,
которые вы указали.

возможные варианты выхода (в порядке убывания степени разумности):


расположить файлы в более подходящем месте (часто — в /var/www/) и сделать их владельцем
пользователя, от имени которого запущен процесс nginx.
запускать процесс nginx от имени того пользователя/группы, который имеет доступ (хотя
бы на чтение) к нужным вам файлам/каталогам.
изменить права доступа к нужным вам файлам/каталогам так, чтобы пользователь, от
имени которого работает nginx, имел к ним доступ хотя бы на чтение.

Неверный редирект через php “header location”

#php #nginx #redirect

Добрый день, коллеги!
Не выходит настроить правильный редирект средствами php.

UPD: 21/10/2016 Вынес поддомен на который должна быть переадресация в отдельный конфиг
nginx и отдельный пул php-fpm. Не помогло.

Конфиг nginx основного домена:
domain.conf:

server {
    server_name  www.domain.ru;
    rewrite ^(.*) http://domain.ru$1 permanent;
}
server {
        listen 80;
        root /var/www/folder/public;

        index index.html index.htm index.php;

        server_name anotherdomain.ru subdomain2.domain.ru domain.ru;


        location ~ \.php$ {
            # root /var/www

                try_files $uri =404;
                fastcgi_keep_conn on;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME $request_filename;
                include /etc/nginx/fastcgi_params;
        }

        location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;
        }

        location ~ /\.ht {
           deny all;
        }
}


Конфиг nginx поддомена:

subdomain.conf:

server {
        listen 80;
        root /var/www/folder/public;

        index index.html index.htm index.php;

        server_name subdomain.domain.ru;
        gzip on;
        gzip_disable "msie6";
        gzip_types text/plain text/css application/json application/x-javascript
text/xml application/xml application/xml+rss text/javascript application/javascript;


        location ~ \.php$ {
            # root /var/www

                try_files $uri =404;
                fastcgi_keep_conn on;
                fastcgi_pass unix:/var/run/php5-fpm-subdomain.sock;
                #fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME $request_filename;
                include /etc/nginx/fastcgi_params;
        }

        location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;
        }

        location ~ /\.ht {
           deny all;
        }
}


При таком коде: 




В ответ получаю:

[root@svm]# curl -I http://domain.ru/indexfile.php
HTTP/1.1 302 Moved Temporarily
Connection: close
Date: Mon, 17 Oct 2016 13:57:59 GMT
Location: http://domain.ru/
Content-Type: text/html; charset=UTF-8
Server: nginx/1.4.6 (Ubuntu)


Но при этом, в консоли отладки firefox вижу такой Url Запроса:
http://domain.ru/subdomain.domain.ru

А при таком коде: 




Прилетает это:

[root@svm]# curl -I http://domain.ru/indexfile2.php
HTTP/1.1 302 Moved Temporarily
Connection: close
Date: Mon, 17 Oct 2016 13:57:59 GMT
Location: http://subdomain2.domain.ru/
Content-Type: text/html; charset=UTF-8
Server: nginx/1.4.6 (Ubuntu)


Для одного конкретного поддомена не присваивается новый заголовок с location.
В чём может быть проблема и как её исправить?

Наблюдение: Если в Location: указывать uri без http (То есть просто //subdomain.domain.ru,
то перенаправление работает. Почему? Как исправить?

Интересный факт - Добавил в файл несколько произвольных заголовков и их вывод: "print_r(headers_list());".
Судя по всему, php правильно выставляет headers, но они либо не применяются, либо их
переписывает nginx:

[root@svm]# curl -v http://domain.ru/indexfile.php
* About to connect() to 4cio.ru port 80 (#0)
*   Trying 11.11.11.11...
* Connected to domain.ru (11.11.11.11) port 80 (#0)
> GET /indexfile.php HTTP/1.1
> User-Agent: curl/7.29.0
> Host: domain.ru
> Accept: /
>
< HTTP/1.1 302 Moved Temporarily
< Connection: Keep-Alive
< Transfer-Encoding: chunked
< Expires: Mon, 26 Jul 2666 05:00:00 GMT
< Date: Tue, 18 Oct 2016 14:46:44 GMT
< Location: **http://domain.ru** - Ну вот откуда он берётся?
< Content-Type: text/html; charset=UTF-8
< Server: nginx/1.4.6 (Ubuntu)
< Cache-Control: no-cache
<
Array
(
    [0] => Expires: Mon, 26 Jul 2666 05:00:00 GMT
    [1] => Cache-Control: no-cache
    [2] => Location: http://subdomain.domain.ru
)


UPD 2: 21.10.2016 Добавил логи nginx в debug-режиме:

Лог очень большой. Сравнил два лога- один для поддомена на который переадресация
выполяется нормально, второй для поддомена на который переадресация не выполняется.
В обоих случаях, nginx получает новый location при первой обработке php-файла. Ниже
предоставлены выдержки с того момента, как они начинают отличаться:

Лог для не работающего поддомена:

http fastcgi sent end request
pipe write downstream: 1
pipe write downstream done
event timer: 61, old: 1477057711592, new: 1477057711593
http upstream exit: 0000000000000000
finalize http upstream request: 0
finalize http fastcgi request
free rr peer 1 0
close http upstream connection: 61
free: 000000000240DFA0, unused: 48
event timer del: 61: 1477057711592
reusable connection: 0
http upstream temp fd: -1
http output filter "/indexfile.php?"
http copy filter: "/indexfile.php?"
image filter
xslt filter body
http postpone filter "/indexfile.php?" 00007FFF3BF1A200
http chunk: 0
write old buf t:1 f:0 000000000249A7E8, pos 000000000249A7E8, size: 274 file: 0, size: 0
write new buf t:0 f:0 0000000000000000, pos 00000000004AA3DA, size: 5 file: 0, size: 0
http write filter: l:1 f:0 s:279
http write filter limit 0
writev: 279
http write filter 0000000000000000
http copy filter: 0 "/indexfile.php?"
http finalize request: 0, "/indexfile.php?" a:1, c:1
set http keepalive handler
http close request
http log handler
free: 000000000249AA20
free: 0000000002487340, unused: 8
free: 0000000002499A10, unused: 8
free: 0000000002409890, unused: 3556
free: 00000000024B1630
hc free: 0000000000000000 0
hc busy: 0000000000000000 0
tcp_nodelay
reusable connection: 1
event timer add: 60: 65000:1477057716593
post event 00000000024E0FA0
delete posted event 00000000024E0FA0
http keepalive handler
malloc: 00000000024B1630:1024
recv: fd:60 -1 of 1024
recv() not ready (11: Resource temporarily unavailable)
free: 00000000024B1630
post event 00000000024E0FA0
post event 00000000024F47B0
delete posted event 00000000024F47B0
http empty handler
delete posted event 00000000024E0FA0
http keepalive handler
malloc: 00000000024B1630:1024
recv: fd:60 329 of 1024
reusable connection: 0
posix_memalign: 0000000002487340:4096 @16
event timer del: 60: 1477057716593
http process request line
http request line: "GET / HTTP/1.1"
http uri: "/"
http args: ""
http exten: ""
posix_memalign: 0000000002499A10:4096 @16
http process request header line
http header: "Reverse-Via: FF-SRV"
http header: "Host: domain.ru"  ------Вот здесь должен быть subdomain.domain.ru
http header: "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101
Firefox/49.0"
http header: "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
http header: "Accept-Language: en-US,ru-RU;q=0.8,ru;q=0.5,en;q=0.3"
http header: "DNT: 1"
http header: "Upgrade-Insecure-Requests: 1"
http header: "Connection: Keep-Alive"
http header done


Лог для работающего поддомена:

http fastcgi sent end request
posix_memalign: 00000000024B2620:4096 @16
pipe write downstream: 1
pipe write downstream done
event timer: 55, old: 1477057946320, new: 1477057946320
http upstream exit: 0000000000000000
finalize http upstream request: 0
finalize http fastcgi request
free rr peer 1 0
close http upstream connection: 55
free: 0000000002413EC0, unused: 48
event timer del: 55: 1477057946320
reusable connection: 0
http upstream temp fd: -1
http output filter "/indexfile.php?"
http copy filter: "/indexfile.php?"
image filter
xslt filter body
http postpone filter "/indexfile.php?" 00007FFF3BF1A200
http chunk: 0
write old buf t:1 f:0 000000000249C4B0, pos 000000000249C4B0, size: 270 file: 0, size: 0
write new buf t:0 f:0 0000000000000000, pos 00000000004AA3DA, size: 5 file: 0, size: 0
http write filter: l:1 f:0 s:275
http write filter limit 0
writev: 275
http write filter 0000000000000000
http copy filter: 0 "/indexfile.php?"
http finalize request: 0, "/indexfile.php?" a:1, c:1
set http keepalive handler
http close request
http log handler
free: 000000000240A000
free: 00000000025096F0, unused: 8
free: 000000000249B6E0, unused: 8
free: 00000000024B2620, unused: 3572
free: 0000000002488790
hc free: 0000000000000000 0
hc busy: 0000000000000000 0
tcp_nodelay
reusable connection: 1
event timer add: 54: 65000:1477057951320
post event 00000000024E0030
delete posted event 00000000024E0030
http keepalive handler
malloc: 0000000002488790:1024
recv: fd:54 -1 of 1024
recv() not ready (11: Resource temporarily unavailable)
free: 0000000002488790
delete posted event 00000000024F3840
http empty handler
accept: 22.22.22.22 fd:55
event timer add: 55: 60000:1477057946388
reusable connection: 1
epoll add event: fd:55 op:1 ev:80000001
post event 00000000024E1BD0
delete posted event 00000000024E1BD0
http wait request handler
posix_memalign: 00000000024888A0:256 @16
malloc: 00000000024889B0:1024
recv: fd:55 336 of 1024
reusable connection: 0
posix_memalign: 00000000025096F0:4096 @16
http process request line
http request line: "GET / HTTP/1.1"
http uri: "/"
http args: ""
http exten: ""
posix_memalign: 000000000249B6E0:4096 @16
http process request header line
http header: "Reverse-Via: FF-SRV"
http header: "Host: subdomain2.domain.ru"
http header: "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101
Firefox/49.0"
http header: "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
http header: "Accept-Language: en-US,ru-RU;q=0.8,ru;q=0.5,en;q=0.3"
http header: "DNT: 1"
http header: "Upgrade-Insecure-Requests: 1"
http header: "Connection: Keep-Alive"
http header done


UPD 3: 24/10/2016 Наблюдение

Ели я размещаю файлик с переадресацией в subdomain2.domain.ru, то перенаправление
на subdomain.domain.ru работает без проблем.
    

Ответы

Ответ 1

Коллеги, проблема решена.

Проблема оказалась вообще не в nginx.

ПЕМКИС, как это часто и бывает. Оказывается, на стороне Заказчика стоит прозрачный
TMG, о чём не сообщили. В этом TMG было включено некорректное правило с изменением
заголовков. Было включено "Подставлять действительный заголовок вместо запрошенного"
для зоны domain.ru

p.s. ПЕМКИС = Проблема Есть Между Клавиатурой И Стулом


Ответ 2

Попробуйте:

rewrite ^(.*) http://domain.ru$request_uri permanent;

Настроить ssl на nginx

#linux #nginx #ssl #dns

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

Есть некий сервер, на котором nginx слушает один адрес (допустим, 1.1.1.1). Адрес
резолвится в большую кучу dns-имён, при чём, самых разных. Допустим, у меня для каждого
имени есть свой SSL-сертификат. Как мне настроить nginx, чтоб они для каждого имени
ассоциировал свой сертификат?
    

Ответы

Ответ 1

Насколько я понимаю, у вас сервер имеет ip 1.1.1.1, на нем nginx и много dns указывают
в A-записи на 1.1.1.1

Тогда так

server {
    listen 80;
    server_name site1.com www.site1.com;
    rewrite ^(.*) https://$host$1 permanent;
}
server {
        listen     443;
        ssl        on;
        ssl_certificate         /etc/nginx/ssl/site1.pem;
        ssl_certificate_key     /etc/nginx/ssl/site1.key;

        server_name site1.com www.site1.com;
        root /var/www/site1;

        ...

}

server {
    listen 80;
    server_name site2.com www.site2.com;
    rewrite ^(.*) https://$host$1 permanent;
}
server {
        listen     443;
        ssl        on;
        ssl_certificate         /etc/nginx/ssl/site2.pem;
        ssl_certificate_key     /etc/nginx/ssl/site2.key;

        server_name site2.com www.site2.com;
        root /var/www/site2;

        ...

}


Для каждого сайта сначала слушаем порт 80, делаем rewrite с http на https, потом
слушаем 443.

Это выдержка из рабочего конфига nginx.


Ответ 2

насколько я помню можно конфиги для разных сайтов вынести из основного.  ссылка