Переезд Nginx-конфигурации на новый VPS: сайты, reverse proxy и проверка

Снимите карту сайтов и зависимостей

Соберите имена server_name, корневые каталоги, правила rewrite, locations, upstream, проксирование WebSocket, максимальный размер запроса и особенности кеширования. Отметьте, где обрабатывается PHP: через сокет или TCP, какой путь у сокета и какой пользователь может читать файлы. Проверьте все include, в том числе те, которые добавляет панель управления. Внешне простой файл сайта может зависеть от глобальных snippets и настроек TLS.

Сверьте фактические DNS-записи, дополнительные домены и поддомены, A и AAAA. Для reverse proxy запишите сервисы за upstream, health paths, таймауты и заголовки Host/X-Forwarded-For. Перенесите только нужные server blocks, а не все конфиги из /etc/nginx без ревизии: на целевой версии Nginx могут отсутствовать модули или отличаться синтаксис.

• Составьте перечень доменов, портов и корневых каталогов.
• Найдите все include и связанные с панелью файлы.
• Зафиксируйте upstream, WebSocket и таймауты.
• Отдельно отметьте правила IPv4 и IPv6.

Подготовьте новую среду и пути

Установите совместимый пакет Nginx и проверьте его версию, модули, пути конфигурации и права. Подготовьте каталоги сайта и журналов. Если новый VPS использует панель управления, придерживайтесь её механизма создания сайта: ручные файлы могут быть перезаписаны при следующей генерации конфигурации. Сверьте владельца файлов, доступ PHP-FPM и каталог для ACME challenge.

Подготовьте TLS отдельно. Не копируйте приватный ключ в открытую папку для удобства. Если автоматическая выдача сертификата доступна, проще запланировать выпуск на целевой машине после проверки маршрута и challenge. Для нескольких Nginx-инстансов важно, чтобы challenge был доступен на каждом из них или через согласованную DNS-проверку. Сначала убедитесь, что новый конфиг способен отдать нужный файл или proxy health endpoint под тестовым именем.

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

Перенесите virtual hosts и upstream последовательно

Переносите один сайт за раз и держите рядом сопоставление старого и нового файла. Проверьте каждый путь root, alias, try_files и location для загрузок. Часто ошибка возникает из-за лишнего слеша или пути, который существовал на прежнем сервере. Для upstream проверьте адрес и порт приложения, локальный firewall, сетевой интерфейс и формат health endpoint. Не переводите backend в публичный доступ, если он должен быть доступен только через proxy.

Перенесите необходимые rate limits и security headers, но не включайте новый набор ограничений одновременно с миграцией, если нельзя быстро понять источник проблемы. Переменные окружения для Nginx и PHP могут отличаться. Сравните конфигурацию по директивам, а не только текстово: некоторые значения следует адаптировать к новому окружению, а не копировать дословно.

• Проверьте root, alias, try_files и location.
• Проверьте upstream-порт и сетевой маршрут.
• Сохраните нужные заголовки и лимиты запросов.
• Не публикуйте backend-порт без необходимости.

Тестируйте конфигурацию до reload

Официальное руководство Nginx описывает reload как перечитывание и проверку конфигурации с запуском новых worker процессов, если проверка успешна; при неуспехе старые процессы продолжают обслуживать запросы. На целевом VPS выполните штатный тест конфигурации, затем проверьте отдельный сайт по hosts или временному домену с правильным Host-заголовком и TLS SNI. Reload относится к целевому узлу, а не к старому серверу.

Проверьте также размеры запроса, долгие API-ответы, редиректы, cookies, заголовки, веб-сокеты и доступ к статическим файлам. Убедитесь, что журнал не показывает отказов в подключении к upstream или ошибок доступа. Если Nginx обслуживает несколько проектов, тестируйте каждый домен до общего cutover: корректная главная одного сайта ничего не говорит о соседнем server block.

• Проверьте синтаксис штатной командой Nginx.
• Откройте тестовый сайт с корректным именем хоста.
• Проверьте HTTPS, redirect, upload и API.
• Посмотрите журналы Nginx и приложения вместе.

Переключите DNS и проследите за запросами

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

Смотрите на статус и время ответа отдельных доменов, а также на ошибки upstream, 404, 413 и 502. Проверьте, не остался ли в приложении абсолютный URL старого server, и обновите доступы внешних сервисов при смене IP. Сохраняйте старый Nginx-конфиг отдельно до окончания наблюдения. При необходимости отката восстановите последнюю известную конфигурацию и пересмотрите путь возврата данных.

• После cutover проверяйте все домены, а не только основной.
• Сверяйте A/AAAA и ответ каждого upstream.
• Отслеживайте новые 4xx/5xx по журналам.
• Сохраните старые конфиги и DNS-значения до завершения перехода.

Выберите VPS по схеме приложений и объёму трафика

Если Nginx — только входная точка, ресурсов может требоваться меньше, чем серверу с базой и обработчиками файлов. Но окончательный план зависит от TLS, gzip/brotli, кеширования, количества соединений и характера API. Измерьте нагрузку действующей машины и учтите пики. Проверьте сетевые лимиты, наличие IPv4/IPv6 и возможность быстро подключить ресурсы, когда нужно.

В рейтинге приведён тот же список и порядок VPS/VDS, что в <a href="https://impossible-studio.com/vps-vds/vps-vds-dlya-proekta-s-vebhukami-kak-ne-teryat-vhodyashhie-sobytiya-i-obrabatyvat-ih-bez-zaderzhek/">материале о VPS для проекта с вебхуками</a>. Сравните конкретные условия: доступ к конфигурации, консоли, резервам, поддержке и внешним IP. Перед заказом проверьте, подходит ли выбранный тариф для ваших upstream и пиковых соединений, а не ориентируйтесь на название провайдера.

• Определите, какие сервисы находятся за Nginx.
• Учтите пиковые соединения и TLS-обработку.
• Уточните IPv4/IPv6 и сетевые ограничения.
• Сверьте доступность консоли и процедуры восстановления.

Проверка маршрутов до и после переключения Nginx

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

Если новый сервер отвечает локально, но публично запрос не проходит, проверьте последовательно DNS, внешний firewall, локальные правила, слушающий порт, reverse proxy и upstream приложения. Не открывайте все порты для диагностики. Сверьте access и error logs в пределах согласованного интервала, удалив из передаваемых фрагментов токены и пользовательские параметры. После cutover протестируйте редиректы и canonical: цепочки из нескольких переходов могут ухудшить скорость и ломать внешние callback.

• Проверьте каждое имя домена и путь.
• Тестируйте Host/SNI и HTTPS.
• Разбирайте сетевой маршрут по слоям.
• Не расширяйте firewall без нужды.

Частые вопросы

Можно ли просто скопировать /etc/nginx?

Лучше сначала проверить include, версии, модули, пути и то, управляет ли файлами панель. Скопированный конфиг может ссылаться на несуществующий сокет или сертификат.

Нужно ли перезапускать Nginx при переносе?

На новом сервере применяйте изменения после теста конфигурации штатным способом. Старый VPS не меняйте без необходимости, пока идёт переход.

Как проверить сайт до смены DNS?

Используйте временный домен или локальное сопоставление имени с IP нового VPS, сохраняя нужный Host и TLS SNI.

Документация и полезные источники

• Nginx: Beginner’s Guide, reload configuration
• Let’s Encrypt: типы challenge

Материал проверен 12 ноября 2026 года. Условия провайдеров, версии программ и DNS-настройки могут меняться — сверяйте актуальные данные перед выполнением переноса.