Сайт с Netlify на VPS: перенос форм, функций и перенаправлений

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

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

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

Найдите работу, которую выполняла платформа

Откройте репозиторий, настройки проекта и список подключённых сервисов. Проверьте netlify.toml, файл _redirects, каталог функций и атрибуты форм. Отдельно посмотрите переменные окружения, плагины сборки, расписания и обработчики событий.

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

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

Формы: атрибут в HTML не является сервером

Netlify умеет обнаруживать формы и обрабатывать отправку на своей стороне. На обычном VPS атрибуты формы не создадут обработчик автоматически. Руководство Netlify Forms описывает именно платформенный механизм, который после переезда нужно заменить собственным endpoint или внешним сервисом.

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

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

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

История заявок тоже должна переехать

В интерфейсе Netlify можно выгрузить проверенные отправки в CSV; порядок описан в разделе Form submissions. Сохраните экспорт до закрытия проекта. Проверьте, какие поля в него вошли, как представлены даты и что произошло с вложениями.

Ссылка на прикреплённый файл не заменяет сам файл. Скачайте необходимые объекты отдельно, свяжите их с идентификатором обращения и проверьте доступность. Для архива сохраните исходный CSV без изменений, а преобразование выполняйте на копии. Это позволит разобраться с ошибкой импорта, не повторяя экспорт из уже закрытого сервиса.

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

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

Функции: переносим логику, меняем окружение

Разберите каждую функцию по входным данным и результату. HTTP-обработчик можно перенести в серверное приложение, но платформенный контекст и события потребуют отдельной реализации. Документация Netlify Functions показывает, что функции могут реагировать не только на запросы, но и на события платформы.

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

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

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

Перенаправления: маленькие строки с большой историей

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

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

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

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

Испытание формы до переключения домена

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

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

Для формы с вложениями проверьте ограничение размера, разрешённые типы и способ выдачи файлов. Пользовательский файл не должен исполняться веб-сервером. Закрытое вложение выдавайте через проверку прав, а не через общедоступный каталог с легко угадываемым именем.

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

Контрольный набор старых адресов

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

Публикация на VPS и дальнейшее обслуживание

Раздавайте статику через веб-сервер, а запросы формы и API направляйте в отдельный серверный процесс. Настройте автоматический запуск, HTTPS, ограничение журналов и резервное копирование записей. Базу и административные интерфейсы не открывайте всему интернету без необходимости.

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

Подойдут поддерживаемые приложением Ubuntu или Debian. Если сайт собирается на том же VPS, предусмотрите память и место для сборки; доставка уже подготовленной статики часто экономнее. Выбор VPS MAATRIX стоит привязать к реальной схеме, а не к числу страниц.

Перед сменой DNS сохраните старые заявки и остановите независимый приём на прежнем обработчике. После перехода проверьте основной домен, формы, письма и старые ссылки. Хороший финальный тест здесь очень человеческий: заполнить форму так, как это сделал бы новый клиент, и убедиться, что менеджер действительно получил обращение.