SvelteKit на VPS: формы, загрузка файлов и постоянный запуск
У формы есть хороший способ проверить качество развёртывания: выглядеть безупречно и отказываться отправляться только на рабочем домене. В разработке всё прошло, сборка завершилась, главная страница открылась. Но сервер за обратным прокси иначе видит адрес запроса, и действие блокируется. Такая ошибка неприятна именно тем, что почти весь сайт при этом кажется исправным.
Развёртывание SvelteKit лучше проверять через действия пользователя. Нам нужны работающие формы, правильное определение публичного адреса, постоянное хранение файлов и запуск после перезагрузки. Рассмотрим существующее приложение с серверной логикой и адаптером для Node.js, а статический вариант отделим сразу.
Содержание
VPS для SvelteKit с серверной логикой
Подберите VPS MAATRIX для форм, базы и файлов вашего приложения. Проверьте память при сборке и загрузках, а объём диска рассчитайте по пользовательским данным.
ВЫБРАТЬ VPSСначала выберите подходящий адаптер
Если все страницы можно подготовить заранее, а серверных действий нет, изучите adapter-static. Для приложения, которое обрабатывает формы на сервере, обращается к базе и проверяет сессии, нужен соответствующий серверный вариант.
На VPS распространён adapter-node. Его настройка зависит от версии SvelteKit, поэтому сохраняйте существующую конфигурацию проекта и сверяйте место подключения с актуальной документацией. Не заменяйте целый конфигурационный файл коротким примером из другой версии: вместе с ним легко потерять алиасы, предварительную обработку и собственные параметры.
Зафиксируйте версию Node.js, lock-файл и рабочий коммит. Соберите проект в чистой среде. Если сборка читает внешние данные, убедитесь, что у неё есть нужные тестовые подключения и что она не изменяет рабочую базу.
Для обычного результата adapter-node используется каталог build; кроме него могут требоваться производственные зависимости проекта. Подробности приведены в руководстве Node servers. Проверяйте запуск готового результата, а не сервера разработки.
Минимальная проверка готовой сборки
При стандартном выходном каталоге запуск выглядит так:
HOST=127.0.0.1 PORT=3000 node build
Команда предполагает установленную совместимую версию Node.js, подготовленную сборку и необходимые зависимости. Адрес ограничивает процесс локальным интерфейсом. Публичные запросы позже примет обратный прокси.
Откройте приложение через тестовую схему доступа и проверьте вложенный маршрут напрямую. Затем отправьте форму и убедитесь, что действие действительно изменило тестовую базу. Успешная загрузка HTML проверяет лишь часть приложения.
Передайте обязательные переменные окружения явно. В production обычный запуск не обязан автоматически читать тот .env, который работал в разработке. Можно использовать поддерживаемый Node.js способ загрузки файла или окружение менеджера службы. Выберите один вариант и запишите его, чтобы настройки не зависели от того, из какой папки администратор открыл терминал.
Форма должна пережить и ошибку, и повтор
Серверные действия SvelteKit позволяют обрабатывать формы в приложении; принципы описаны в руководстве form actions. Но проверка прав, данных и последствий остаётся задачей вашего кода.
Возьмём учебную форму заявки. Поля: имя, адрес почты, описание проблемы и вложение. На сервере задайте допустимую длину текста, обязательность полей и правила обработки файла. Возвращайте понятную ошибку без потери уже введённого безопасного содержимого. Не показывайте пользователю внутреннюю строку подключения или полный стек исключения.
Проверяйте права внутри действия, даже если кнопка видна только вошедшему пользователю. Прямой запрос можно отправить без посещения страницы. Для изменения существующей заявки проверяйте принадлежность записи, а не только наличие действующей сессии.
Повторная отправка должна иметь определённое поведение. Для создания заявки можно использовать устойчивый идентификатор попытки. Для оплаты или внешней операции требуется согласованная защита от дублей. Отключённая после нажатия кнопка полезна для интерфейса, но не решает повтор запроса из-за разрыва связи.
Почему за HTTPS внезапно запрещён POST
Когда TLS завершается на обратном прокси, внутреннее соединение до Node.js может идти по HTTP. Приложению нужно корректно определить исходный протокол и публичный домен. Если оно видит другой адрес, проверка происхождения формы может отклонить отправку.
Настройте передачу нужных заголовков от доверенного прокси и соответствующие параметры адаптера. В актуальных версиях также учитывается конфигурация публичного origin; её расположение сверяйте с версией SvelteKit. Не лечите ошибку отключением защиты для всех источников.
Доверять заголовкам следует только в реальной защищённой цепочке. Если внутренний порт открыт напрямую всему интернету, клиент может попытаться подставить значения сам. Ограничьте доступ к Node.js и задайте понятное число доверенных посредников, когда используете адрес клиента для журналов и ограничений.
Проверьте форму именно через основной HTTPS-домен. Проверка локального порта не воспроизводит поведение прокси. Затем проверьте альтернативное имя домена: оно должно либо корректно перенаправлять на основной адрес, либо быть явно предусмотрено конфигурацией.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
АРЕНДОВАТЬ СЕРВЕРФайлы: три ограничения и одно постоянное место
Размер загрузки ограничивается несколькими уровнями: обратным прокси, адаптером и самим приложением. Если один уровень разрешает файл, а другой отклоняет, пользователь получает неожиданную ошибку. Согласуйте пределы и выводите понятное сообщение до повторной попытки.
У adapter-node предусмотрен параметр BODY_SIZE_LIMIT. Выбирайте конечное значение под задачу вместо безусловного снятия ограничения. Для крупных файлов продумайте потоковую обработку или отдельное хранилище, чтобы несколько одновременных загрузок не заняли всю память сервера.
Проверяйте допустимый тип и содержимое файла в пределах требований приложения. Имя, присланное браузером, нельзя использовать как готовый безопасный путь. Назначайте внутренний идентификатор, сохраняйте исходное имя отдельно и исключайте выход за разрешённый каталог.
Пользовательские файлы храните вне build. Для закрытых документов организуйте выдачу после проверки доступа. Прямое размещение всего каталога загрузок под публичным адресом способно обойти аккуратную авторизацию формы.
Проверьте удаление и замену файла. Старая версия не должна бесконечно оставаться на диске без понятной политики. При сбое между записью файла и созданием записи в базе нужен способ найти и очистить незавершённые объекты.
Запуск после перезагрузки
Оформите приложение как службу systemd, контейнер или управляемый процесс панели развёртывания. Запускайте его от отдельного пользователя с доступом только к нужным каталогам. Настройте рабочую директорию, окружение, перезапуск и сохранение журналов.
Обратный прокси принимает публичные подключения и обслуживает сертификат. База остаётся во внутренней сети или на локальном интерфейсе. Публично открывайте только действительно необходимые порты, а административный доступ защищайте отдельным способом.
Перезагрузите VPS в тестовом окружении. Проверьте, что приложение стартовало, подключилось к базе, принимает форму и читает ранее загруженный файл. Затем остановите процесс штатно и убедитесь, что менеджер службы ведёт себя согласно настройке. Эти проверки просты, но именно они отличают развёртывание от удачного ручного запуска.
Журналы ограничивайте по размеру и сроку хранения. Для ошибки сохраняйте время, маршрут и идентификатор запроса. Содержимое документов, пароли и cookies в обычном журнале не нужны. Диагностика должна помогать расследованию, а не создавать новый архив секретов.
Проверка выпуска на двух аккаунтах
Создайте два тестовых пользователя. Первый отправляет заявку и прикрепляет файл, второй пытается открыть известный адрес этой заявки. Затем первый выходит, а второй входит в том же браузере. Проверьте, что личные данные не сохранились в общем кеше или состоянии интерфейса.
Измените заявку и обновите страницу напрямую. Если новая версия видна только после перехода через меню, исследуйте кеширование и загрузку данных. Проверьте отсутствующий объект: страница должна отдавать соответствующий код ответа и понятное сообщение.
Сохраните предыдущую сборку. Обновление приложения и миграция базы требуют общего плана: прежний код может быть несовместим с новой структурой. Для небольшого проекта лучше один проверенный выпуск с ясным откатом, чем сложная автоматизация, которую никто не умеет остановить.
Конфигурация VPS под приложение
Для пилота SvelteKit с небольшой базой и обычными формами можно рассматривать MAATRIX Uab Start: 2 vCPU и 4 ГБ памяти. Если на сервере идут сборки, обработка файлов и фоновые задачи, начните оценку с Heka Standard с 4 vCPU и 8 ГБ.
Выберите совместимую Ubuntu или Debian. Диск рассчитывайте по базе, вложениям, журналам и запасу для обновления; резервные копии храните отдельно. Рост памяти при параллельной загрузке файлов проверяйте экспериментом на тестовых данных, а не по размеру одной страницы.
VPS MAATRIX позволяет разместить приложение с собственной серверной логикой. Хорошая приёмка занимает несколько понятных действий: войти, отправить форму, скачать свой файл, отказать чужому аккаунту и повторить всё после перезагрузки. Если эти действия проходят, у проекта появилась рабочая площадка, а не просто доступная главная страница.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
АРЕНДОВАТЬ СЕРВЕРОбсудить статью, задать вопрос или начать новую тему
Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.
Перейти в сообщество →