Nuxt на VPS: когда достаточно статики, а когда нужен SSR

MAATRIX · 17 октября 2026 · 8 мин чтения

Два сайта на Nuxt могут требовать совершенно разного размещения. Первый — небольшой справочник, который меняется раз в неделю. Второй — каталог с персональными ценами, поиском и кабинетом клиента. У обоих похожие компоненты и знакомые команды разработки, но одинаковая схема публикации будет либо избыточной для первого, либо недостаточной для второго.

Выбор между статикой и серверным рендерингом стоит делать по поведению страниц. Сколько раз меняются данные? Зависят ли они от пользователя? Должна ли страница существовать до очередной сборки? Ответы помогают выбрать режим, а затем — VPS и способ сопровождения.

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

Главная страница компании содержит описание услуг и контакты. Её можно подготовить заранее. Статья блога также хорошо подходит для предварительной генерации. Каталог с часто меняющимися остатками требует аккуратного обновления данных. Личный кабинет зависит от сессии конкретного человека и не должен попадать в общий публичный кеш.

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

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

Когда предварительная генерация действительно удобна

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

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

Определите процесс обновления. Редактор изменил текст — кто запускает сборку, как проверяется успех и когда новый выпуск появляется на сайте? Если ответа нет, статическая схема скоро превратится в коллекцию устаревших сведений. Для небольшого проекта достаточно понятного ручного выпуска, для активного — автоматического запуска с журналом результата.

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

Когда нужен постоянно работающий сервер

Серверная схема полезна, если HTML зависит от запроса, данные быстро меняются или приложение выполняет серверные обработчики. Для Node.js используется серверный результат Nitro. В руководстве Nitro описаны выходной каталог, переменные адреса и порта, а также работа за обратным прокси.

Для проекта с настроенной стандартной сборкой Nuxt серверный выпуск обычно запускается из подготовленного каталога:

node .output/server/index.mjs

Эта команда предполагает, что сборка уже выполнена для Node.js и совместимая версия Node.js установлена. Она не заменяет настройку окружения, базы, HTTPS и управления процессом. Перед публикацией сверяйте результат с конфигурацией конкретной версии проекта.

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

Где искать ошибки между сервером и браузером

Код при универсальном рендеринге может исполняться в разных окружениях. Обращение к браузерному объекту во время серверной обработки приводит к ошибке. И наоборот, секрет, предназначенный серверу, нельзя передавать клиенту ради удобства доступа.

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

Отдельно разберите ошибки гидратации. Они появляются, когда исходный HTML и первое представление браузера расходятся. Причиной могут быть случайные значения, локальное время, разные данные или условие, зависящее от окружения. Сравните содержимое до запуска JavaScript и после него; предупреждение в консоли обычно указывает место расследования, а не просит его игнорировать.

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

Кеш: разделите публичное и личное

Начните с простого правила: персональный ответ не должен повторно использоваться для другого пользователя. Создайте два аккаунта, откройте один и тот же маршрут и сравните HTML, данные и заголовки. Повторите проверку после выхода и входа другим аккаунтом в том же браузере.

Для публичного каталога определите допустимую задержку обновления. Цена, остаток и описание могут иметь разные требования. После изменения товара проверьте, когда новое значение появится у посетителя. Учитывайте кеш приложения, прокси и браузера: очистка одного уровня не очищает остальные.

Не настраивайте длительное кеширование всех ответов по одному правилу. Ошибка авторизации, страница корзины и неизменяемый файл со сборочным хешем требуют разного поведения. Для статических ресурсов удобно использовать версионированные имена; для изменяемых страниц нужна осмысленная политика свежести.

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

Сборка и данные должны жить отдельно

Сохраняйте lock-файл и фиксируйте рабочий коммит. Сборку выполняйте в воспроизводимой среде. Если сервер небольшой, можно собирать приложение отдельно и доставлять готовый совместимый результат: это уменьшит конкуренцию за память с действующим сайтом.

Пользовательские загрузки храните вне заменяемого каталога выпуска. Для базы используйте постоянное хранилище и отдельное резервное копирование. Обновление кода не должно удалять вложения или неожиданно создавать пустую базу из-за изменившегося пути.

Секреты передавайте через окружение, публичные настройки отделяйте. После сборки проверьте реальные запросы браузера: они должны идти на правильный домен и API. Для переменных времени выполнения учитывайте принятый в проекте механизм конфигурации, а не рассчитывайте, что любой произвольный .env будет автоматически прочитан готовым сервером.

Проверка перед первым посетителем

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

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

Для поисковой видимости посмотрите уникальные title и description, канонические адреса и карту сайта. Удалите случайный запрет индексирования с рабочего окружения, сохранив ограничение доступа к тестовому. Карта сайта должна содержать действующие публичные страницы, а не все технически возможные маршруты.

Перезапустите процесс и VPS, затем повторите короткую проверку. Сохраните предыдущий выпуск и опишите возврат. Если обновление меняет базу, откат кода нужно согласовать с совместимостью схемы.

Какая конфигурация VPS нужна Nuxt

Для статического сайта без тяжёлого обработчика можно начать пилот на MAATRIX Ba Lite с 1 vCPU и 2 ГБ памяти. Серверному приложению с небольшой базой разумнее рассматривать Uab Start: 2 vCPU и 4 ГБ. Если сборка, база и фоновые задачи работают вместе, оцените Heka Standard с 4 vCPU и 8 ГБ.

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

Для размещения подойдут совместимые с проектом Ubuntu или Debian. VPS MAATRIX позволяет выбрать ресурсы под конкретный режим Nuxt. Удобная схема — та, где редактор понимает момент публикации, посетитель получает свежие данные, а администратор может повторить выпуск без магии и счастливого совпадения переменных.