Несколько сайтов с блоками сервера Nginx

Nginx server blocks — это механизм виртуальных хостов, который позволяет размещать на одном сервере несколько доменов или веб-сайтов с разными настройками. Например, на одном VPS можно настроить сайты example.com, blog.example.com и vtoroj-sajt.com с разными корневыми папками, логами, SSL-сертификатами и параметрами PHP. Вкратце, процесс сводится к созданию отдельной директории для каждого сайта, настройке DNS, написанию конфигурационного файла в /etc/nginx/sites-available, созданию символической ссылки в sites-enabled, проверке конфигурации и перезагрузке Nginx.

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

Что такое server blocks в Nginx?

Nginx server blocks — это части конфигурации, определяющие, какой именно сайт отдавать при запросах по определённому домену или поддомену. Аналог понятия VirtualHost в Apache. Когда пользователь вводит доменное имя в браузере, DNS переводит его в IP-адрес сервера. Затем Nginx смотрит в заголовок Host запроса и выбирает соответствующий server block с совпадающим server_name.

Таким образом, на одном IP и на одном физическом или виртуальном сервере можно разместить десятки сайтов. Для каждого сайта задаются свои корневые папки, логи доступа и ошибок, правила переадресации, SSL-сертификаты, политика кэширования и меры безопасности. Например, корпоративный сайт может храниться в /var/www/corporate/public, блог — в /var/www/blog/public, а тестовая среда — в /var/www/staging/public.

Архитектура Nginx основана на событийной модели, что позволяет эффективно обрабатывать большое количество одновременных соединений при минимальном расходе ресурсов. Поэтому Nginx часто выбирают для shared-хостинга, VPS, облачных серверов и проектов с высокой нагрузкой. Чтобы такой мультисайтинг работал стабильно, важно правильно настроить права доступа, DNS, SSL и логи.

Когда использовать server blocks в Nginx?

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

Если хотите разместить несколько доменов на одном VPS.
Если нужно перенаправлять www и без www на один канонический адрес.
Если поддомены должны указывать на разные папки или приложения.
Если для каждого сайта нужен отдельный SSL-сертификат и политика безопасности.
Если хотите вести отдельные логи для каждого проекта.
Если планируете запускать разные приложения (Laravel, WordPress, статический HTML, Node.js) на одном сервере.

Например, агентство может на одном VPS с 4 ГБ ОЗУ разместить 8 сайтов с небольшой посещаемостью. Но для каждого проекта нужно оценить трафик, использование диска, количество PHP-процессов и нагрузку на базу данных, а также частоту резервного копирования. При высоких нагрузках или необходимости изоляции ресурсов лучше выбрать более мощный VPS, облачный сервер или управляемый хостинг. В этом случае полезно сравнить варианты в Веб-хостинг и Корпоративный Хостинг.

Требования перед началом

В этом руководстве будем использовать Ubuntu или Debian-подобный Linux. Команды могут немного отличаться в зависимости от дистрибутива, но общий принцип одинаков. Обязательно делайте резервные копии перед изменениями — неправильная конфигурация Nginx может привести к временному недоступности всех сайтов.

Необходимая подготовка

Пользователь с root или sudo-привилегиями.
Установленный и запущенный Nginx.
Как минимум один домен, направленный на IP вашего сервера.
Открытые в фаерволе порты 80 и 443.
Правильно организованная структура каталогов для файлов сайтов.
Действующий SSL-сертификат или возможность использовать бесплатный Let’s Encrypt.
PHP-FPM, если планируете запускать PHP-приложения.

В DNS записи A указывает IPv4 адрес, AAAA — IPv6. Для поддоменов типа www используют CNAME или A-записи. DNS-обновления занимают от нескольких минут до суток. Рекомендуется сначала подготовить DNS, а затем настраивать Nginx, чтобы ускорить процесс.

Пошаговое создание server block

Пример ниже на базе домена site1.com. Аналогично повторяйте для других сайтов, меняя server_name, root и пути для логов.

1. Создайте папку сайта

Например, команда: sudo mkdir -p /var/www/site1.com/public. Затем создайте тестовый файл /var/www/site1.com/public/index.html с текстом «Это тестовая страница site1.com».

Чтобы выставить правильные права, выполните sudo chown -R www-data:www-data /var/www/site1.com. Если деплой делаете другим пользователем, настройте права доступа соответствующим образом. Избегайте прав 777, это опасно с точки зрения безопасности.

2. Создайте конфигурационный файл

Обычно конфиги лежат в /etc/nginx/sites-available, а активируются символическими ссылками в sites-enabled. Файл для site1.com — /etc/nginx/sites-available/site1.com.

Пример простого server block для HTTP:

server {
    listen 80;
    server_name site1.com www.site1.com;
    root /var/www/site1.com/public;
    index index.html index.htm;
    access_log /var/log/nginx/site1.com.access.log;
    error_log /var/log/nginx/site1.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

Здесь listen 80 — слушать порт 80, server_name — домены, root — корневая папка сайта, index — файл по умолчанию, try_files возвращает 404 при отсутствии файла.

3. Активируйте сайт

Создайте символическую ссылку: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Такой подход удобнее, чем копирование, так как изменения сразу применяются.

Если стандартная страница Nginx мешает, отключите её: удалите ссылку /etc/nginx/sites-enabled/default. Но сначала убедитесь, что ваш server block работает корректно.

4. Проверьте конфигурацию и перезагрузите Nginx

После каждого изменения запускайте sudo nginx -t для проверки синтаксиса. Если ошибок нет, примените изменения командой sudo systemctl reload nginx. Команда reload перезапускает сервис без разрыва соединений.

Если тест выдаёт ошибки, они обычно указывают на строку и файл — проверьте точки с запятой, фигурные скобки, пути и совпадения server_name. Не перезагружайте Nginx пока не исправите ошибки.

Добавление второго и третьего сайта

Преимущество server blocks — их можно повторять как шаблон. Для site2.com создайте папку /var/www/site2.com/public, напишите конфиг в sites-available/site2.com с уникальными root и логами, создайте символическую ссылку и проверьте Nginx.

Пример конфига для второго сайта:

server {
    listen 80;
    server_name site2.com www.site2.com;
    root /var/www/site2.com/public;
    index index.html;
    access_log /var/log/nginx/site2.com.access.log;
    error_log /var/log/nginx/site2.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

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

Настройка SSL и HTTPS

С 2026 года HTTPS — не только безопасность, но и фактор SEO и доверия пользователей. Браузеры помечают сайты без SSL как небезопасные; для проектов с оплатой, регистрацией или админкой SSL обязателен. Для каждого домена нужен правильный сертификат. Подробнее о сертификатах смотрите на SSL сертификаты.

С Let’s Encrypt сертификаты можно получить бесплатно с помощью Certbot. Например, команда certbot --nginx -d site1.com -d www.site1.com автоматически настроит HTTPS-блоки в конфиге. После автоматической правки рекомендуем проверить конфигурацию — иногда возникают дублирующиеся server blocks или ошибки редиректов.

Обычно HTTP-трафик (порт 80) перенаправляют на HTTPS (порт 443) с кодом 301 — это говорит поисковикам о постоянном редиректе. Выберите, использовать ли www или нет, и направьте все варианты на один канонический адрес, например https://site1.com. Это снижает риск дублирования контента.

Server blocks для PHP и WordPress

Для статических сайтов настройка простая, а для WordPress, Laravel и других PHP-приложений нужна интеграция с PHP-FPM. В конфиге указывается index.php, а PHP-запросы проксируются на сокет PHP-FPM. Путь к сокету зависит от версии PHP и дистрибутива, например /run/php/php8.3-fpm.sock.

Пример конфигурации для WordPress:

server {
    listen 80;
    server_name wordpress-site.com www.wordpress-site.com;
    root /var/www/wordpress-site.com/public;
    index index.php index.html;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Важно, чтобы постоянные ссылки работали корректно — для этого try_files с fallback на index.php обязательны. Также стоит ограничить доступ к xmlrpc.php, wp-login.php, запретить выполнение PHP в папке uploads и применить другие меры безопасности. При размещении множества WordPress-сайтов на одном сервере рекомендуются отдельные базы данных и пользователи, а также регулярные обновления. Для более простого управления можно рассмотреть Хостинг WordPress.

Сравнение Nginx server blocks и Apache VirtualHost

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

Сравнение Nginx server blocks и Apache VirtualHost
Критерий	Nginx server blocks	Apache VirtualHost
Производительность	Отлично справляется с большим количеством одновременных соединений при низком потреблении ресурсов.	Может использовать больше ресурсов из-за модели работы модулей и процессов.
Конфигурация	Централизованная и понятная структура.	Гибкость благодаря .htaccess на уровне директорий.
Отдача статических файлов	Очень быстрая и эффективная.	Тоже хорошая, но Nginx обычно легче.
Обработка PHP	Работает через PHP-FPM.	Поддерживает mod_php и PHP-FPM.
Сценарии использования	Идеален для обратного прокси, статических сайтов, высоконагруженных и современных приложений.	Подходит для старых приложений, сильно завязанных на .htaccess, и shared-хостинга.

Если ваш проект использует сложные правила в .htaccess, Apache может быть проще. Но для высоких нагрузок, кэширования и современных микро-сервисов Nginx чаще выигрывает. Иногда их комбинируют: Nginx — как обратный прокси, Apache — для обработки запросов.

Оптимизация производительности и SEO

Nginx server blocks влияют не только на работу сайтов, но и на их скорость и SEO. Неправильные редиректы, отсутствующие канонические ссылки, не настроенное сжатие gzip или brotli, большие логи и слабый кэш замедляют загрузку. Google оценивает сайты по пользовательскому опыту — скорость, безопасность и стабильность важны.

Для каждого домена выберите единственный канонический адрес. Сделайте редирект с HTTP на HTTPS и с www на без www (или наоборот) за один шаг с кодом 301. Избегайте цепочек редиректов, например: http://site.com → http://www.site.com → https://www.site.com → https://site.com. Лучше сразу направлять на конечный адрес.

Используйте заголовки cache-control для статики — картинки, CSS, JS можно кэшировать в браузере. Для часто меняющихся файлов применяйте версионирование. Сжатие gzip снижает трафик для текстовых файлов. Для сайтов с большим трафиком стоит рассмотреть Nginx microcache, FastCGI cache или CDN. Для глобального доступа полезна информация по Что такое CDN.

Управление логами и мониторинг

Отдельные логи для каждого сайта — ключ к быстрому решению проблем. access_log фиксирует запросы пользователей, error_log — ошибки конфигурации, доступа, отсутствующие файлы и проблемы с backend. Ошибка 502 Bad Gateway чаще всего связана с PHP-FPM или другими backend-сервисами. 403 Forbidden — проблемы с правами или отсутствием index-файла. 404 Not Found указывает на неправильный root, ошибки в правилах rewrite или DNS.

Чтобы логи не занимали всё место, настройте logrotate. Для небольших проектов достаточно ежедневного или еженедельного ротации. Для крупных — централизованный сбор логов, мониторинг и оповещения. Переполнение диска может привести к отказу записи логов, остановке БД и недоступности сайтов, поэтому мониторьте использование дискового пространства.

Типичные ошибки и их исправление

При работе с Nginx server blocks часто встречаются следующие проблемы. Знание их поможет быстрее запускать проекты.

Открывается не тот сайт: проверьте пересечения server_name и default server block.
Ошибка 403 Forbidden: проверьте права на папку root и наличие index-файла.
Ошибка 404 Not Found: проверьте путь root и директиву try_files.
Ошибка 502 Bad Gateway: удостоверьтесь, что PHP-FPM запущен и сокет указан правильно.
SSL сертификат не соответствует сайту: проверьте server_name и пути сертификатов в порт 443.
Цикл редиректов: упростите правила перенаправления HTTP/HTTPS и www.
Nginx не перезагружается: исправьте синтаксические ошибки по выводу sudo nginx -t.

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

Практический чек-лист перед запуском

Перед публикацией сайта пройдитесь по списку ниже. Особенно важно при передаче проектов клиентам — это демонстрирует профессионализм.

DNS A и AAAA записи указывают на правильный IP.
Выбран канонический вариант с www или без.
HTTP редиректит на HTTPS с кодом 301.
SSL-сертификаты действительны, автоматическое обновление настроено.
Для каждого сайта прописаны уникальные root и логи.
Конфигурация прошла проверку sudo nginx -t.
Определён план резервного копирования и проведено тестовое восстановление.
Права доступа установлены по принципу минимальных привилегий.
В файерволе открыты только необходимые порты.
Логи ошибок мониторились минимум 15 минут после запуска.

Хотя список кажется простым, он существенно снижает риск сбоев и проблем в реальных условиях. Особенно контроль SSL, DNS и логов помогает выявлять скрытые ошибки.

Итоги

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

Если планируете запуск нового проекта, сначала определитесь с доменом, серверными ресурсами и SSL, затем настройте Nginx согласно чек-листу. Для более простого старта и управления смотрите решения Hostragons: Пакеты хостинга, VPS сервер и SSL сертификаты.

Часто задаваемые вопросы

Сколько сайтов можно разместить на одном Nginx сервере?

Технически — сколько угодно, ограничением служат ресурсы сервера: CPU, ОЗУ, диск, трафик, нагрузка на базу данных и PHP-FPM. Для небольших статических сайтов — десятки, для тяжелых WordPress или интернет-магазинов — меньше.

Нужен ли отдельный SSL-сертификат для каждого сайта?

Да, каждый домен и поддомен, работающий по HTTPS, должен иметь сертификат. Можно использовать отдельные сертификаты, либо SAN и wildcard-сертификаты. Главное — правильно связать сертификат с server_name в конфигурации порта 443.

Можно ли с помощью server blocks публиковать поддомены?

Да, для поддоменов (например, blog.site.com или admin.site.com) создают отдельные server_name и указывают разные корневые директории или backend-приложения. Не забудьте настроить соответствующие DNS-записи A или CNAME.

В чём разница между sites-available и sites-enabled?

sites-available — папка для хранения всех конфигураций, в том числе неактивных. sites-enabled содержит символические ссылки на активные конфиги из sites-available. Такой подход позволяет удобно включать и выключать сайты.

Почему открывается не тот сайт?

Чаще всего из-за DNS, указывающего на неправильный IP, или неверного server_name, либо если срабатывает default server block. Проверьте DNS-записи, результат команды nginx -t, ссылки в sites-enabled и логи доступа.

Nginx Server Blocks (Виртуальные хосты) для размещения нескольких сайтов на одном сервере