Виртуальный хостинг: как настроить домены, папки и редиректы

Настройка виртуального хостинга нужна, когда на одном сервере размещают несколько сайтов и хотят, чтобы каждый домен открывал свой контент, а URL вели себя предсказуемо. На практике это набор связок: DNS направляет домен на сервер, веб-сервер сопоставляет домен с нужной конфигурацией, а в пределах этой конфигурации вы задаёте папки (document root), правила доступа и редиректы. Хорошая настройка снижает количество ошибок вроде “открывается не тот сайт” и “редирект крутится по кругу”.

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

Что такое виртуальный хостинг и какие компоненты участвуют

Виртуальный хостинг — это возможность обслуживать несколько сайтов на одном IP/сервере, различая их по имени домена (и иногда по порту). Главные элементы процесса такие:

DNS-запись домена указывает на IP сервера (A/AAAA) или на имя (CNAME).
В веб-сервере конфигурация виртуального хоста сопоставляет входящий запрос с нужным блоком по имени хоста.
Внутри виртуального хоста задаются корневые папки сайта, индексные файлы и правила обработки URL.
Редиректы приводят запросы к канонической форме URL (например, HTTP на HTTPS, www на non-www, старые пути на новые).

Интуитивно это похоже на “маршрутизацию”: сначала выбираем, какой сайт обслуживать, затем решаем, куда направить URL внутри выбранного сайта.

Подготовка доменов и DNS перед настройкой виртуального хостинга

Прежде чем править конфиги Nginx или Apache, проверьте базу: домен должен корректно указывать на сервер. Даже идеально написанный virtual host не поможет, если DNS ведёт не туда.

A/AAAA/CNAME и распространенные ошибки

Обычно используют такие записи:

A: домен → IPv4 адрес сервера.
AAAA: домен → IPv6 адрес сервера (если вы используете IPv6).
CNAME: поддомен → другое имя (часто для переноса управления), но не для корневого домена без специальных оговорок у провайдера.

Типичные ошибки при запуске виртуального хостинга:

В одном месте указали A-запись, а в другом сервер слушает только IPv6 (или наоборот).
Для домена настроили записи, но серверной стороны нет: нужные виртуальные хосты не определены, или слушаются не те порты.
TTL стоит слишком высоким, и вы долго ждёте изменения. Снижать TTL заранее имеет смысл только если вы планируете миграцию.
Поддомен настроили как CNAME, а ожидали, что будет A-запись, и забыли про то, что итоговый ответ зависит от цепочки DNS.

Проверить, что домен реально резолвится в нужный IP, можно с рабочего места или в инфраструктуре:

dig или nslookup для проверки резолва,
curl с указанием Host-заголовка, если нужно проверить веб-сервер до полного DNS-пропагации.

Планирование www и HTTPS: что считать каноническим URL

На этапе подготовки договоритесь о канонической форме URL. Выберите один вариант, который будет “правильным”:

HTTP или HTTPS (обычно только HTTPS),
www или без www.

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

Ещё один момент: если у вас несколько доменов, которые должны открывать один сайт (например, example.com и www.example.com), виртуальный хостинг должен быть согласован по server_name (Nginx) или ServerName/ServerAlias (Apache). В противном случае “часть” доменов может попасть в дефолтный хост, где документрута нет или там другое содержимое.

Структура файлов на сервере: папки для сайтов и шаблоны

Чтобы настройка виртуального хостинга не превращалась в хаос, заранее определите структуру директорий. Главное правило: у каждого сайта должна быть предсказуемая корневая папка, а вспомогательные директории не должны пересекаться между сайтами.

document root и вложенные директории

Типовая структура для нескольких сайтов:

/var/www/
site1/
public/ (или просто root с index.html)
logs/ (иногда делают отдельные лог-папки, но чаще логи идут в системные)
shared/ (опционально)
site2/
public/
/etc/nginx/sites-available/ и /etc/nginx/sites-enabled/ (если используете схему с папками)
/etc/apache2/sites-available/ и /etc/apache2/sites-enabled/ (для Apache в стиле Debian-подобных систем)

Если вы используете фреймворк или SPA, документрута часто две:

папка, из которой отдаются статические файлы,
правила rewrites/try_files, чтобы приложение обрабатывало маршрутизацию.

Пример для Nginx, когда приложение — это публичная папка и все “не файлы” уходят на index.php: «`nginx server { server_name example.com www.example.com; root /var/www/site1/public; index index.php index.html;

location / { tryfiles $uri $uri/ /index.php?$querystring; } } «`

Для простых статических сайтов document root может быть “один-в-один”:

root указывает на папку с index.html,
index задаёт файл по умолчанию.

Права, владельцы и безопасная настройка папок

Обычно проблема не в конфиге, а в правах на файловой системе: Nginx/Apache не могут читать файлы или — хуже — доступны лишние директории.

Практика, которая помогает:

Владелец файлов сайта — пользователь, под которым вы деплоите (например, deploy), а чтение для веб-сервера должно быть доступно через группы.
Папки для записи (cache, storage, uploads) должны иметь отдельные права, но не “на всё сразу”.
Логи и временные файлы лучше хранить в местах, где права настроены осознанно.

Типичные ошибки:

Дали права 777 на все папки ради скорости и забыли.
Публичная папка не отделена от приватной (например, vendor/ или конфиги доступны из web).
Не настроены права на папку uploads, из-за чего редактирование контента начинает падать после деплоя.

Рекомендация по проверке перед запуском: после правок убедитесь, что процесс веб-сервера реально может читать нужные файлы. Если вы не знаете, под каким пользователем работает Nginx/Apache, посмотрите конфиги или системные службы.

Nginx: настройка виртуальных хостов по доменам

Nginx “разделяет” сайты через server block. Каждый такой блок описывает, какие домены он обслуживает, на каких портах и какие правила применяются.

server blocks и директива server_name

Минимальный каркас для виртуального хоста:

«`nginx server { listen 80; server_name example.com www.example.com;

root /var/www/site1/public; index index.html;

location / { try_files $uri $uri/ =404; } } «`

Что важно:

listen 80 и listen 443 должны соответствовать вашим реальным сценариям (HTTP и HTTPS).
server_name перечисляет домены, которые должны матчиться.
root и index задают, откуда отдавать файлы и какой файл использовать, если URL без имени ресурса.

Если домен не матчит ни под один server block, запрос уйдёт в “дефолтный” хост. Поэтому, когда вы добавляете новый виртуальный хост, убедитесь, что дефолтный блок не раскрывает чужой сайт.

root, index, try_files и поведение при запросах

Редиректы и маршрутизация часто упираются в то, как Nginx обрабатывает запросы “не как файл”. Два типичных сценария:

Статика:
try_files проверяет наличие файла/директории и возвращает 404, если ничего нет.

Приложение (PHP/фреймворк):
try_files отправляет на index.php (или другой front-контроллер), если запрошенного файла нет.

Пример с PHP обработчиком (упрощённо, без полной конфигурации fastcgi): «`nginx location / { tryfiles $uri $uri/ /index.php?$querystring; } location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php-fpm.sock; fastcgiparam SCRIPTFILENAME $documentroot$fastcgiscript_name; } «`

Для SEO и каноничности важно, чтобы приложение отдавал корректные редиректы для URL с/без слэша, с нужными расширениями и т.п. Но базовая часть — чтобы Nginx не отдавал “не тот файл” и не создавал неожиданные 404.

Редирект внутри server block: быстрые сценарии

Редиректы на уровне Nginx обычно делаются директивами return или rewrite. Для простого HTTP→HTTPS часто используют отдельный server на 80 порту:

«`nginx server { listen 80; server_name example.com www.example.com;

return 301 https://$host$request_uri; } «`

Обратите внимание на $host: он сохраняет домен, с которым пришли запросы. Если вы хотите всегда приводить к non-www или наоборот, лучше использовать фиксированное имя.

Пример принудительного перехода на www: «`nginx server { listen 80; server_name example.com;

return 301 https://www.example.com$request_uri; } «`

И дальше отдельный server block на www обрабатывает HTTPS. Это снижает риск циклов редиректа и “перепутанных” схем.

Apache: настройка виртуального хостинга по доменам

В Apache виртуальные хосты задаются директивами VirtualHost. По сути, это аналог server block, но синтаксис и логика немного другие.

VirtualHost, DocumentRoot и ServerName/ServerAlias

Базовая заготовка для VirtualHost:

«`apache <VirtualHost *:80> ServerName example.com ServerAlias www.example.com

DocumentRoot /var/www/site1/public Directory /var/www/site1/public Require all granted </Directory>

DirectoryIndex index.html </VirtualHost> «`

Для HTTPS вы добавляете отдельный VirtualHost на 443 с сертификатами. Виртуальный хост может обслуживать несколько доменов через ServerAlias.

Важно предусмотреть два момента:

Если у вас несколько сайтов, дефолтный VirtualHost должен быть “пустым” или содержать безопасную заглушку, чтобы запросы на неизвестные домены не открывали лишнее.
Правила доступа для папок (Directory) должны соответствовать тому, что реально находится в DocumentRoot. Если папка недоступна, вы получите 403 даже при правильном DocumentRoot.

.htaccess vs конфиг: где удобнее управлять редиректами

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

Если всё же используете .htaccess, типичная структура включает:

включение mod_rewrite,
настройку RewriteEngine,
правила RewriteRule.

Но при большом количестве сайтов нагрузка от проверки .htaccess может стать заметной. В задачах “настройка редиректа для конкретного домена/папки” удобнее держать правило в VirtualHost или отдельном конфиг-файле, чем раскладывать по корням.

Редиректы в виртуальном хостинге: как делать правильно

Редиректы — самая “хрупкая” часть в теме доменов и папок. Ошибка в коде ответа или в условии может приводить к редирект-циклам или потере части URL при переходе.

HTTP→HTTPS и принудительное www/non-www

Начните с канонического URL. Обычно схема выглядит так:

На порту 80 вы принимаете все запросы и делаете редирект на HTTPS.
На HTTPS вы делаете приведение к нужному виду домена (www или без).

Для Nginx это обычно два server блока: один на 80, второй на 443 с действительным корнем сайта. Пример, когда канонический домен — www: «`nginx server { listen 80; server_name example.com www.example.com; return 301 https://www.example.com$request_uri; } «`

В HTTPS-блоке вы можете обслуживать только www или сразу оба, но редирект лучше делать на раннем этапе, чтобы исключить дубль логики.

Для Apache логика похожая: делаете 301 редирект в VirtualHost на 80. Если используете modrewrite, обычно перевод делается с корректным сохранением URI, например через переменную REQUESTURI.

Важно: код 301 закрепляет редирект “навсегда”, его кешируют клиенты и поисковые системы. Если вы ещё не уверены в каноническом домене, иногда выбирают 302/307 на период теста, но в долгую всё равно придётся зафиксировать окончательный вариант.

Редиректы по папкам и канонические URL

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

Пример: старый раздел /old/ нужно перенаправить на /new/ с сохранением хвоста. Для Nginx: «`nginx location /old/ { return 301 /new/$request_uri; } «`

Но тут легко ошибиться с дублированием слэшей и с тем, что именно попадает в $request_uri (включая полный путь с /old/). Более безопасный вариант — использовать захват в rewrite, если вы точно понимаете, какую часть нужно сохранить.

Пример с rewrite в Nginx (концептуально): «`nginx location ^~ /old/ { rewrite ^/old/(.*)$ /new/$1 permanent; } «`

В Apache аналогично делается через RewriteRule:

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

Типичные ошибки редиректов по папкам:

Потеря query string. Пользователь теряет фильтры и параметры.
Некорректное формирование нового пути из-за неверного захвата группы.
Цикл: /old/ редиректит на /new/, а где-то ещё /new/ редиректит обратно на /old/.

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

Учет методов и кодов 301/302/307/308

Код ответа влияет не только на SEO, но и на поведение клиентов.

301: постоянный редирект. Обычно используется для канонизации URL (HTTP→HTTPS, www/non-www, переезд разделов).
302: временный редирект. Иногда применяют для теста или временных изменений.
307/308: временный/постоянный редирект, при котором метод обычно сохраняется. Это важно для API или для случаев, где запрос не только GET.

Для сайтов “обычного” типа в большинстве кейсов подходит 301. Но если у вас есть формы, POST-эндпоинты или API, не забывайте про метод: неверный редирект может превратить POST в GET на стороне клиента.

Практический подход:

Если вы редиректите страницу (GET), можно использовать 301.
Если редиректите endpoint, где возможны другие методы, уточните правила и код ответа, чтобы не сломать поведение.

Пересечения доменов и папок: wildcard, subdomains, алиасы

Когда сайтов больше одного, рано или поздно появляются задачи вида:

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

Wildcard-серверы и исключения

Nginx поддерживает wildcard в server_name, например:

*.example.com для поддоменов,
но важно понимать приоритеты и матчи: конкретные имена обычно имеют приоритет над wildcard.

Пример: «`nginx server { listen 443 ssl; server_name *.example.com;

root /var/www/subdomains_site/public; index index.html; } «`

Если вы добавили wildcard, убедитесь, что у конкретных доменов есть свои более приоритетные server blocks. Иначе, например, app.example.com может попасть в “общий” блок, даже если вы ожидали отдельную конфигурацию.

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

Alias/Redirect и работа с несколькими корнями

Иногда внутри одного домена часть URL должна отдавать файлы из другой папки. В Nginx для этого есть alias и location-структура.

Пример: /downloads/ отдаёт файлы из отдельного каталога: «`nginx location /downloads/ { alias /data/downloads/; autoindex off; } «`

Если вы используете alias, учитывайте ключевой момент: alias заменяет именно префикс location, а root влияет иначе. Это частая причина “вылезло не то содержимое”.

Для редиректов внешних URL используйте return: «`nginx location /partners/ { return 302 https://external.example.com/; } «`

В Apache аналогичные сценарии решаются через Redirect или Alias (в зависимости от того, отдаёте файлы или делаете перенаправление). Главное — отделяйте физическую отдачу файлов от перенаправлений, чтобы не смешивать логику и не создавать неожиданные статусы.

Проверка, отладка и типичные проблемы

После того как вы собрали домены, папки и редиректы, начинаются проверки. Они должны быть системными: иначе вы ловите ошибки “вручную”, а это долго и ненадёжно.

тест конфигурации, журналы и curl

Для Nginx:

используйте команду проверки конфигурации (например, nginx -t),
затем перезапускайте или перезагружайте.

Для Apache:

проверяйте синтаксис конфигов (апач умеет проверку командой),
после чего делайте reload, чтобы не терять активные соединения.

Дальше проверка запросами:

curl -I для заголовков и кода редиректа,
curl -L, чтобы увидеть финальный URL,
тест с Host-заголовком, если DNS ещё не полностью обновился.

Пример проверки редиректа HTTP→HTTPS:

делаете запрос на http://example.com/some-path
смотрите, что приходит 301/302 и правильный Location
затем повторяете на https://…

Если вы видите 404 или отдачу “не того сайта”, почти всегда причина одна из трёх:

неправильный server_name (или ServerName/ServerAlias),
неверный root/DocumentRoot или document root не существует,
запрос попал в дефолтный хост из-за отсутствия матча.

типичные ошибки: неправильный порядок location и редирект-циклы

Редирект-циклы — главный страх. Они проявляются так:

браузер долго крутит “перенаправление на страницу”
curl показывает повторяющиеся Location с тем же набором URL

Чтобы найти причину:

проверьте правила на 301 для домена,
затем правила на www/non-www,
затем редиректы по папкам,
и только после этого — редиректы внутри приложения (если оно тоже редиректит).

Ещё несколько частых проблем:

Дублирование “перенаправляющих” правил: например, HTTP→HTTPS делается и на 80, и на 443 где-то в другом месте.
Неправильная обработка слэша: /path/ и /path отличаются, а редирект приводит к циклу при попытке “добавить слэш” и тут же “убрать слэш”.
Ошибка в location-порядке в Nginx: некоторые location с регулярными выражениями могут перехватывать запросы раньше, чем вы ожидаете. Поэтому старайтесь держать правила понятными: конкретные префиксы выше, сложные regex — осознанно.

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

Чек-лист перед запуском виртуального хостинга

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

Проверка доменов и совпадений:
домены, которые должны открывать сайт, перечислены в server_name (Nginx) или ServerName/ServerAlias (Apache);
дефолтный хост не обслуживает чужой контент по ошибке.
Проверка папок:
root/DocumentRoot указывает на существующую папку;
права на чтение есть у пользователя веб-сервера;
index-страница настроена, и запрос без файла действительно отдаёт ожидаемый контент.
Проверка редиректов:
HTTP→HTTPS возвращает 301 и Location содержит верную схему и домен;
www/non-www приводится к выбранному каноническому варианту;
редиректы по папкам сохраняют query string при необходимости;
нет редирект-циклов: проверка curl -I и curl -L для нескольких типовых URL.
Проверка логики приложения (если есть):
правила try_files/rewrite не ломают маршрутизацию;
статические файлы отдаются напрямую, а не “через приложение”, если это критично для производительности.
Проверка поведения для поддоменов и wildcard:
wildcard не перехватывает исключения, где должны быть отдельные конфигурации;
алиасы не указывают на неверные директории из-за путаницы root/alias.
Финальная валидация:
команда проверки конфигурации для Nginx/Apache проходит без ошибок;
после reload/restart сайт открывается по каноническому URL и отдаёт корректные коды статусов.

Итог: как собрать надёжную настройку доменов, папок и редиректов

Надёжная настройка виртуального хостинга держится на трёх принципах. Первый: домен должен однозначно матчиться с нужным виртуальным хостом. Второй: документрута и папки сайта должны быть структурированы и доступны веб-серверу. Третий: редиректы делайте канонизирующими и проверяйте на отсутствие циклов, особенно когда участвуют www/non-www, HTTPS и переезд путей.

Если вам нужно сделать несколько сайтов на одном сервере, начните с простого: один домен, один root, один редирект с HTTP на HTTPS. Затем добавляйте второй домен, потом редиректы по папкам и только после этого — поддомены и wildcard. Такой порядок помогает быстро локализовать ошибку и сохранить контроль над тем, какие URL куда ведут.