Мультиарендность: один рендерер, много сайтов
Хост запроса выбирает сайт. Рендерер не знает «главный домен проекта» — он знает таблицу узлов.
4 мин чтения · 19 августа 2026 г.
Мультиарендность здесь означает: один процесс отдаёт страницы многим доменам. Входящий Host определяет сайт, затем загружаются его разделы, материалы и настройки. Это дешевле, чем поднимать отдельное приложение на каждый узел, и строже, чем подставлять тексты в один общий HTML.
Как выбирается сайт
Прокси принимает запрос, рендерер читает заголовок, нормализует домен и ищет активный узел. Если узла нет — это не «покажем чужой контент», это 404. Смешение витрин из-за дефолтного сайта хуже простоя: читатель получает чужой смысл под своим именем.
| Слой | Ответственность | Типичная ошибка |
|---|---|---|
| Прокси | TLS, Host, маршрут на рендерер | Один default_server на все домены без карты |
| Рендерер | Загрузка сайта по домену | Фолбэк на первый сайт в базе |
| База | Данные только этого siteId | Запрос без фильтра по сайту |
Границы арендатора
Страницы, посты, категории, FAQ и SEO-поля принадлежат узлу. Общими остаются код шаблона и инфраструктурные секреты контура. Админка может видеть список сайтов, публичный рендерер — только текущий Host.
Любой запрос к контенту без siteId считается ошибкой проектирования, даже если «пока сайтов мало».
Где кончается выгода
Один рендерер хорошо живёт, пока узлы похожи. Когда появляются совершенно другие типы страниц, тяжёлая персонализация или отдельный стек, выгоднее вынести семейство в другой шаблон, а не усложнять ветвлениями. Мультиарендность — про одинаковый механизм, не про бесконечную универсальность.
Нужен ли отдельный сервер на каждый домен?
Нет, пока нагрузка и риски это позволяют. Отдельный сервер — мера изоляции сбоев ОС и лимитов, не обязательное условие «настоящей» сети.