Nginx как настроить поддомен

Лисаков и макромир

Краткая инструкция по настройке https с помощью Let’s Encrypt на ОС Ubuntu с вебсервером Nginx. Сначала прочтите всё до конца, а потом выполняйте. Написано по мотивам рекомендаций от hombit. Если что-то не получится, обязательно задавайте вопросы в комментариях. Полная официальная инструкция на английском доступна на readthedocs.org.

После успешного перехода на https внешние ресурсы (например, js, тэги ) надо брать только по https, иначе замо́чек в адресной строке не будет зелёным.

Установка Let’s Encrypt

Устанавливаем их программу. Для определённости будем считать, что мы находимся в /home/user/ .

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

Запускаем их программу в первый раз (с правами root), чтобы она установила все зависимости из репозиториев:

Запускаем программу во второй раз и запрашиваем сертификат (опять с правами root). Замените mydomain.com на своё доменное имя.

Действуем аналогично, если есть поддомен:

Программа попросит электронную почту. Она пригодится для:

  • восстановления сертификатов в случае их утери;
  • напоминания об обновлении сертификата.

После выполнения программа сообщит, что установила сертификаты в /etc/letsencrypt/live/mydomain.com .

Настройка Nginx

Настройка домена в Nginx

Пора настроить Nginx . Замените mydomain.com на своё доменное имя.

Настройка поддомена в Nginx

Если имеется поддомен, например, subdomain.mydomain.com, ему нужно указать такие настройки:

Готово! Снова запускаем Nginx:

Обновление сертификата

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

Проверка статуса сертификата

Чтобы узнать статус и срок действия своего сертификата, можно в браузере зайти на сайт и щёлкнуть на иконку замка́ в адресной строке. В Safari, например, надо будет ещё нажать на «Show Certificate», а в Chrome дату можно увидеть так: щёлкнуть на замо́чек → вкладка Connection → Certificate information → General → Expires on.

Источник

Динамические поддомены с использованием nginx+apache

Этот топик — очередной топик про реализацию динамических поддоменов на сайте, коих много в интернете и даже есть пара топиков на хабре.

Проблема в том, что этот вопрос везде освещается только с точки зрения перенаправления с поддомена в папку и вся динамичность поддомена заключается в том, что ты создал папку — поддомен у тебя заработал.

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

Например, у нас есть готовый сайт, на котором работают профили по такому url: www.example.com/users/username, и есть всякие дополнительные возможности (например www.example.com/users/username/contact и другие страницы, связанные с этим юзером).

И мы теперь хотим вынести все, что связано с юзером, на поддомен, например username.example.com, username.example.com/contact и т.д.)

Решения, которые были найдены в интернете, меня не удовлетворили по 2 причинам:

  • Не нашел решения как заставить ее работать, сохранив работоспособность домена www.example.com
  • Все найденные решения подходят только для перенаправления в папку и не работают если дальше должны работать какие то правила
Читайте также:  Не работает моторчик омывателя лобового стекла ваз 2110 причины

На нашем сайте стоит nginx над апачем (как и на многих других), поэтому пришлось изобретать велосипед самому, используя эту связку (nginx+ apache, благо сейчас почти на всех крупных сайтах стоит проксирующий nginx над апачем)

В общем то решение простое — т.к. на сайте уже налажена через mod_rewrite работоспособность ссылок вида www.example.com/users([a-zA-Z_]+) то было принято решение делать рерайт поддоменов через nginx.

Дополнительное условие — наш сайт работает только как ww.example.com, а example.com редиректит на www.

Соответственно осталось просто написать правило в конфиге nginx для рерайта поддоменов. Правило получилось такое это решение — не верное, использовать его не рекомендуется:

upd После публикации топика BlackWizard подсказал лучшее решение, которое отвечает всем изначальным условиям:

Таким образом, если посетитель зашел на поддомен то nginx это определяет и запрашивает из апача уже адрес вида www.example.com/users/username, а апач уже дальше разбирает все в соотвествии со своими правилами mod_rewrite.

Полученное в итоге решение обладает следующими плюсами:

  • Нет проблемы с www
  • Легко внедряется на любом сайте с уже готовой системой ссылок (не будем рассматривать процесс измененения ссылок на самом сайте)
  • Работает как для папок, так и для url, которые используют mod_rewrite

Минусы:

  • Требуется проксирующий nginx

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

UPDкак сделать чтобы username.example.com работал без указания всех возможных доменов в конфиге веб-сервера
Чтобы сервер корректно обрабатывал динамические поддомены, необходимо добавить одну маленькую запись в настройки DNS. Это можно сделать, используя панель управления сервером.
Просто добавьте следующую запись формата A («A record» в англоязычной версии):
*.example.com

Запись нужно добавлять после всех поддоменов (mail, smtp и т.д.)

Источник

Как создать динамические поддомены?

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

Когда может понадобится создание динамических поддоменов?

Создание динамических поддоменов может понадобится для решения разных задач. Очень часто их используют чтобы сделать открытие аккаунтов пользователей сайта на поддоменах с их именами. Например, при заходе на username.unetway.com открывать содержимое скрипта unetway.com/users.php?login=username .

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

Если доменов несколько, то конечно их лучше создать вручную. А когда их уже больше пяти, то стоит воспользоваться созданием динамических поддоменов.

Создание динамических поддоменов через DNS

Для начала необходимо настроить DNS на вашем веб-сервере:

  • В настройках DNS вашего домена добавьте wildcard запись *.unetway.com , чтобы запросы на любой поддомен, шли на основной домен вашего сайта.
  • В настройках веб-сервера пропишите virtualhost (виртуальный хост) * — звездочку, чтобы все запросы обрабатывались одним доменом.

Таким образом, все запросы на *.unetway.com вы можете обрабатывать своим скриптом.

Создание динамических поддоменов через htaccess

Одним из самых легких способов создания автоматических поддоменов, является использование файла htaccess. Возможность его использовать есть на любом хостинге (кроме каких-то закрытых платформ по созданию сайтов).

Пример кода, для создания динамических поддоменов через htaccess, выглядит следующим образом:

Создание динамических поддоменов через Apache

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

Создание динамических поддоменов через Nginx

Пример кода, для создания динамических поддоменов через Nginx, выглядит следующим образом:

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

Читайте также:  Как настроить сеть чтобы видел телевизор

Автор

Программист с образованием в области IT и опытом разработки на разных языках. Автор статей по программированию. Общий опыт работы в сфере IT и интернета более 5 лет.

Источник

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

Добрый день,
Наконец то я решился перейти со старого и доброго Apache на новый и прогрессивный nginx.
Настроил в связке php-fpm, поставил все нужные модули, и вроди мне даже все показалось прозрачнее и проще чем с Apache, на default конфиге погонял пару скриптов и остался доволен результатом.

И вот наступил черед конфигурации хостов и тут я столкнулся с проблемой:

есть www.site1.com и есть субдомен subdomain.site1.com

В sites-enebled 2 конфига, для www.site1.com:

При такой конфигурации при переходе на site1.com мне выдается содержимое папки subdomain.site1.com

Где я делаю ошибку,

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

  • Вопрос задан более трёх лет назад
  • 5508 просмотров

Оценить 2 комментария

Проверьте кофиг командой `sudo nginx -t`.
Проверьте, что обоих конфигах директива `listen` одинакова.

А так, вообще-то должно работать.

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

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

Может, дело в php-fpm ? Я вижу, что вы отправляете все на один сокет php-fpm. Попробуйте разнести пул домена и поддомена по разным конфигам php-fpm, указав при этом разные сокеты.

@vkrzt К примеру, конфиг php-fpm для поддомена:

/etc/php5/fpm/pool.d/subdomain.site1.ru.conf
[subdomain.site1.ru]
listen = /var/run/php-fpm/subdomain.site1.ru.sock
listen.owner = subdomain.site1.ru
listen.group = subdomain.site1.ru
listen.mode = 0666
user = subdomain.site1.ru
group = subdomain.site1.ru
.
php_admin_flag[display_errors] = off
php_admin_value[error_log] = /var/www/subdomain.site1.ru/log/php/fpm-php.log
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/subdomain.site1.ru/data
php_admin_value[upload_tmp_dir] = /var/www/subdomain.site1.ru/upload

!ВНИМАНИЕ! Пути изменить на нужные, вместо многоточия подставить свои параметра, в данном конфиге выставлены директивы пользователя и группы от которых будет работать дочерний процесс php-fpm, использующий данный конфиг.

Создаете рядом аналогичный файл для домена site1.ru с указанем аналогичных уникальных путей, в т.ч. указываете отличный сокет.

Источник

Настройка виртуальных хостов Nginx

В одной из прошлых статей мы говорили о том, как выполняется установка и первоначальная настройка веб-сервера Nginx в CentOS 7. Этот веб-сервер завоевал огромную популярность благодаря высокой производительности и удачной архитектуре самой программы, из-за которой такая производительность и стала возможной.

Одна из основных возможностей веб-сервера — обслуживание нескольких сайтов на одном IP-адресе и в одной программе. Эта функция реализована с помощью виртуальных хостов. В этой статье мы разберём, как выполняется настройка виртуальных хостов в Nginx. Прежде чем читать статью дальше, я рекомендую просмотреть статью настройка Nginx, чтобы понять общий синтаксис конфигурационного файла.

Настройка виртуального хоста Nginx

Вообще, у Nginx только один конфигурационный файл — это /etc/nginx/nginx.conf. Все остальные файлы из папки /etc/nginx/* подключаются в этот файл с помощью директивы include. Поэтому теоретически все виртуальные хосты или только часть из них могут быть размещены в этом файле. Однако так делать не рекомендуется.

Для этого уже существует папка /etc/nginx/sites-available/ и /etc/nginx/sites-enabled. Первая просто содержит файлы конфигурации, в каждом из которых находится отдельный виртуальный хост. Вторая папка содержит ссылки на файлы из /etc/nginx/sites-available и подключена к основному конфигурационному файлу. Даже если в вашей системе пока такая структура не используется, я рекомендую её создать, чтобы в конфигурации всегда был порядок.

1. Синтаксис виртуального хоста

Каждый виртуальный хост представляет из себя такой блок кода:

server <
listen ip_адрес:порт;
server_name доменные_имена;
root /путь/к/файлам/сайта/;
index index.php index.html;
.
location / <>
.
>

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

  • listen — указывает на IP-адрес и порт, на котором программа будет ожидать соединения от этого сайта. Чтобы выбрать любой IP-адрес, можно указать звёздочку, а порт указывать обязательно. Также в этой строке можно добавить параметр default_server, тогда этот виртуальный хост будет использоваться по умолчанию;
  • server_name — доменные имена, на которые будет отзываться этот хост. При отправке запроса на сервер, браузер указывает, к какому домену он обращается. Nginx анализирует этот параметр и выбирает необходимый виртуальный хост. Чтобы обрабатывать все домены, используйте символ подчеркивания _;
  • root — путь к файлам сайта, которые будут открываться при запросе к этому виртуальному хосту. У Nginx должен быть доступ на чтение ко всем папкам по этому пути;
  • index — файлы, которые будут открываться, если адрес файла не указан в URL;
  • location — это набор правил обработки путей в url. Каждый location может содержит путь URL а внутри него можно настроить открытие другого файла, аутентификацию, запрос к другому серверу и другие подобные вещи. Nginx анализирует все location в конфигурационном файле и выбирает самое подходящее. Из этого правила есть одно исключение. Если несколько location содержат регулярные выражения, то для обработки будет выбран первый подходящий.
Читайте также:  Как настроить имя аккаунта

2. Виртуальный хост по умолчанию

Теперь разберём создание виртуальных хостов nginx на примере. Давайте создадим виртуальный хост, который будет обрабатывать все необработанные запросы:

sudo vi /etc/nginx/sites-available/000-default.conf

server <
listen *:80 default_server;
server_name _;
root /usr/share/nginx/html;
index index.html index.htm;
location / <>

Все директивы, которые используются в блоке server, могут использоваться и в блоках location. Но нам не обязательно указывать root и index в каждом location. Если их опустить, то будут наследоваться те, которые были указаны в родительском блоке. Блоки server ведут себя аналогичным образом, поэтому, если мы не укажем другой путь к access.log, то будет использоваться путь, указанный в /etc/nginx/nginx.conf и так далее.

Теперь нам нужно активировать созданный виртуальный хост nginx. Для этого создайте символическую ссылку:

sudo ln -s /etc/nginx/sites-available/000-default.conf /etc/nginx/sites-enabled/000-default.conf

Затем убедитесь, что файлы из этого каталога подключены в основном конфигурационном файле:

sudo vi /etc/nginx/nginx.conf

Затем выполните эту команду, чтобы убедится, что вы не допустили ошибок:

Далее перечитайте конфигурацию nginx:

Теперь, если вы откроете IP-адрес сервера, то откроется созданный нами виртуальный хост.

2. Виртуальный хост с доменом

Аналогичным образом можно создать виртуальный хост для домена. Например example.ru:

sudo vi /etc/nginx/sites-available/example.conf

server <
listen *:80;
server_name example.ru;
root /usr/share/nginx/html;
index index.html index.htm;
location / <>
>

Если вы работаете на локальной машине и доступа к DNS выбранного домена у вас нет, то надо добавить его IP в файл /etc/hosts:

sudo vi /etc/hosts

Повторите процедуру активации домена, и затем в браузере при запросе к домену example.ru откроется стартовая страница Nginx. Если по каким-либо причинам виртуальный хост Nginx не работает, вы можете посмотреть полный скомпилированный файл nginx.conf:

Также можно проверить, есть ли в нём конфигурация нужного хоста, например, ищем упоминания example.ru:

nginx -T | grep example.ru

3. Отключение виртуального хоста

Благодаря структуре директорий, которую мы использовали, будет довольно просто отключить ненужный хост. Все наши виртуальные хосты Nginx находятся в папке /etc/nginx/sites-available, а в активной папке только ссылки на эти файлы. Поэтому для удаления достаточно удалить на него ссылку из папки /etc/nginx/sites-enabled/:

А затем, при необходимости, мы можем активировать его обратно, просто создав ссылку.

Выводы

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

Источник

Оцените статью