Настройка нескольких сайтов на одном VPS

MAATRIX

Держать по серверу под каждый сайт — дорого и неудобно, а один VPS способен обслуживать десяток проектов сразу. Настройка нескольких сайтов на одном VPS сводится к виртуальным хостам веб-сервера, отдельным доменам и правильной изоляции. Ниже разберём по шагам, как разместить несколько сайтов на одной машине, выдать каждому свой домен и HTTPS и не дать проектам мешать друг другу — с готовыми конфигами и практикой эксплуатации сервера.

Как один сервер обслуживает много сайтов

Механизм, который делает это возможным, называется виртуальными хостами (в nginx — server blocks). Суть проста: веб-сервер слушает один и тот же IP и порт, но смотрит на доменное имя из заголовка запроса и по нему решает, какой сайт отдать. Пользователь заходит на site-a.ru — сервер отдаёт один каталог, заходит на site-b.ru — другой. Для посетителя это выглядит как совершенно разные сайты, хотя физически они живут на одной машине.

Чтобы это заработало, нужны две вещи. Первое — все домены должны указывать на IP вашего сервера через DNS (A-запись). Второе — для каждого домена на сервере создаётся свой конфиг виртуального хоста, где прописан корневой каталог сайта и правила его обработки. Дальше сервер сам разруливает, кому что отдавать, по имени домена.

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

Готовим структуру каталогов

Прежде чем настраивать конфиги, наведите порядок в файлах. Держите каждый сайт в отдельной директории — так проще управлять, делать бэкапы и не путаться. Разумная структура выглядит так:

mkdir -p /var/www/site-a/public
mkdir -p /var/www/site-b/public
chown -R www-data:www-data /var/www

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

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

Для каждого сайта создайте отдельный конфиг в каталоге /etc/nginx/sites-available/, например /etc/nginx/sites-available/site-a:

server {
    listen 80;
    server_name site-a.ru www.site-a.ru;
    root /var/www/site-a/public;
    index index.html index.php;

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

Ключевое здесь — директива server_name с доменом сайта и root с путём к его файлам. Именно по server_name сервер понимает, какой конфиг применить к запросу. Создайте по такому файлу на каждый сайт, поменяв домен и путь, затем включите их символической ссылкой и перезагрузите сервер:

ln -s /etc/nginx/sites-available/site-a /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Команда nginx -t проверяет конфиг на ошибки до применения — привыкайте запускать её всегда перед перезагрузкой, чтобы одна опечатка не уронила разом все сайты на сервере. Только после успешной проверки делайте reload.

HTTPS для каждого домена

Каждому сайту нужен свой сертификат. Проще всего получить бесплатные сертификаты Let's Encrypt через certbot, который умеет обслуживать сразу несколько доменов на одном сервере и сам продлевает их. После установки certbot выпускает и подключает сертификаты автоматически:

certbot --nginx -d site-a.ru -d www.site-a.ru

Повторите для каждого домена, и certbot добавит в конфиги перенаправление на HTTPS и настроит автопродление. Одна из типовых граблей — забыть открыть в фаерволе порт 443 или не продлить сертификат, из-за чего у посетителей внезапно появляется предупреждение о небезопасном соединении. Автопродление certbot снимает эту проблему, но проверить, что таймер продления работает, всё же стоит.

Изоляция и распределение ресурсов

Главный риск нескольких сайтов на одном сервере — они делят ресурсы и могут мешать друг другу. Наплыв трафика на один проект или его утечка памяти способны замедлить все остальные. Поэтому важно не только разложить сайты по папкам, но и подумать об изоляции. Для PHP-проектов заведите отдельный пул PHP-FPM на каждый сайт под своим пользователем — тогда сбой или взлом одного не заденет соседей и не даст читать чужие файлы. Для более строгой изоляции проекты выносят в отдельные контейнеры Docker, где у каждого своё окружение и лимиты.

Следите за суммарным потреблением. Десять маленьких сайтов на минимальном тарифе живут прекрасно, но если один из них вырастает в нагруженный проект, он начинает тянуть одеяло на себя. Разумная практика эксплуатации сервера — держать мониторинг и понимать, сколько ресурсов ест каждый сайт, чтобы вовремя либо оптимизировать прожорливый проект, либо вынести его на отдельный сервер, либо поднять тариф. Масштабировать VPS у MAATRIX можно без переезда, добавив память и ядра, с оплатой из России картой или криптой.

Когда нескольких сайтов на одном сервере уже мало

Совмещать проекты выгодно, пока они скромные. Но есть моменты, когда сайт лучше отселить. Если проект стал коммерчески важным и его простой недопустим, соседство с чужими сайтами — лишний риск: чужая ошибка не должна ронять ваш основной бизнес. Если один сайт стабильно съедает большую часть ресурсов, остальным не хватает, и честнее дать ему свой сервер. Наконец, если у сайтов разные требования к локации или закону — например, один обслуживает российскую аудиторию и должен хранить данные в РФ, а другой работает на зарубежный рынок, — их логично разнести по разным нодам. Понимание этих границ и есть зрелая эксплуатация сервера: совмещать там, где выгодно, и разделять там, где это оправдано.

Частые вопросы