Что делать, если сайт не открывается после переноса на VPS: DNS, SSL, firewall, Nginx и база данных

Если сайт не открывается после переноса на VPS, проблему нужно искать по уровням. Не стоит сразу менять все настройки подряд: сначала проверяют DNS, затем доступность портов, веб-сервер, SSL, PHP, базу данных, права на файлы и настройки CMS.

Базовый чек-лист после миграции выглядит так:

Симптомы помогают сузить поиск. Белый экран чаще связан с PHP-ошибками, 403 — с правами или запретом доступа, 404 — с virtual host, rewrite-правилами или неправильной директорией, 500 — с ошибкой приложения, .htaccess, PHP или конфигов. Ошибка подключения к базе указывает на wp-config.php, .env, пользователя базы, пароль, host или права доступа к базе.

Если часть пользователей видит старый сайт, а часть новый, это не всегда ошибка сервера. Часто причина в DNS propagation, TTL, локальном кеше DNS, разных резолверах или старых nameservers. Поэтому после миграции важно проверять домен через dig, nslookup, публичные DNS и локальную машину.

Перед переключением DNS полезно проверить сайт через файл hosts. Так можно открыть новый VPS по домену ещё до того, как весь трафик уйдёт на новый IP. Это помогает заранее увидеть ошибки SSL, virtual host, PHP, базы, путей, uploads и CMS.

Типовые ошибки при переносе: менять nameservers без понимания TTL, забывать обновить .env или wp-config.php, не переносить hidden files вроде .htaccess, не проверять сайт через hosts до переключения DNS и чинить всё сразу без фиксации причины.

Правильная логика такая: сначала убедиться, что домен ведёт на новый IP, потом проверить 80/443 и веб-сервер, затем virtual host и SSL, после этого PHP, базу, права, hidden files и настройки CMS. Так миграция превращается не в хаотичный поиск, а в понятный checklist.

Чек-лист после миграции

После переноса сайта на VPS диагностику лучше вести сверху вниз: сначала проверить, нет ли проблем на клиенте, после этого  куда ведёт домен, затем открыт ли сервер снаружи, потом веб-сервер, SSL, приложение, базу данных и настройки CMS.

Такой порядок помогает не чинить всё сразу. Например, нет смысла разбирать wp-config.php, если домен всё ещё указывает на старый IP. И наоборот: если DNS уже правильный, но сайт отдаёт 500, проблема, скорее всего, находится на уровне приложения, PHP, базы или прав доступа.

Проверка клиента

Первое что нужно проверить - нет ли проблем на клиентской стороне. Это может быть сбой компьютера, браузерный кэш, неполадки у провайдера, записи в файле hosts и прочие антивирусы.

Наиболее простой способ проверки - взять другое устройство, желательно с другим провайдером - например если вы проверяете с компьютера на Wi-Fi, можно проверить и с мобильного телефона на сотовом операторе.

И только когда есть уверенность, что проблема не локальная, а массовая, приступаем к диагностике серверной части.

DNS и новый IP

Первое, что нужно проверить по серверной части после переноса, — указывает ли домен на новый IP-адрес VPS. Если A-запись осталась старой, часть пользователей будет попадать на прежний сервер, даже если новый VPS уже полностью настроен.

Проверить A-запись можно так: dig A example.com +short

Или через nslookup: nslookup example.com

Если домен должен открываться и с www, и без www, нужно проверить обе версии:

dig A example.com +short

dig A www.example.com +short

Важно учитывать TTL. После изменения DNS-записей обновление может занять время: у разных провайдеров, резолверов и пользователей старый IP может сохраняться в кеше. Поэтому ситуация, когда один пользователь уже видит новый сайт, а другой ещё старый, не всегда означает ошибку на VPS.

Когда DNS указывает на новый IP, следующий вопрос — доступен ли сам сервер по HTTP и HTTPS.

80/443 и firewall

Даже если домен указывает на правильный IP, сайт не откроется, если на VPS закрыты порты 80 и 443. Порт 80 нужен для HTTP и выпуска Let’s Encrypt-сертификата через HTTP challenge, порт 443 — для HTTPS.

На сервере можно проверить firewall. Если используется UFW: sudo ufw status

Обычно для сайта нужны правила:

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

Также стоит проверить, слушает ли сервер эти порты: sudo ss -tulpn | grep -E ':80|:443'

Если 80/443 закрыты на уровне панели провайдера, security group или внешнего firewall, настройки внутри Linux могут быть правильными, но сайт всё равно будет недоступен снаружи.

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

Nginx/Apache и virtual host

На VPS сайт обычно обслуживает Nginx или Apache. Если веб-сервер не запущен, домен может вести на правильный IP, но браузер получит ошибку подключения или пустой ответ.

Проверка Nginx: systemctl status nginx

Проверка Apache: systemctl status apache2

Если сервис запущен, нужно проверить конфигурацию. Для Nginx: sudo nginx -t

Для Apache: sudo apachectl configtest

Virtual host должен быть привязан к нужному домену и директории сайта. Например, в Nginx важно проверить server_name и root:

server_name example.com www.example.com;

root /var/www/example.com/public;

Если root указывает не туда, сайт может отдавать 404, default page или пустую директорию. Если server_name не совпадает с доменом, запрос может попасть в другой virtual host.

Когда веб-сервер принимает запрос и направляет его в правильную директорию, нужно проверить HTTPS. После миграции именно SSL и редиректы часто создают ощущение, что сайт “не открывается”.

SSL и HTTPS-редиректы

После переноса на VPS SSL-сертификат нужно выпустить или перенастроить для нового сервера. Старый сертификат мог остаться на прежнем хостинге, а новый VPS ещё не готов принимать HTTPS-запросы.

Если используется Let’s Encrypt, часто применяют Certbot: sudo certbot --nginx -d example.com -d www.example.com

Для Apache команда может отличаться: sudo certbot --apache -d example.com -d www.example.com

Перед выпуском сертификата домен уже должен указывать на новый IP, а порт 80 должен быть доступен снаружи. Иначе HTTP challenge может не пройти.

После выпуска SSL нужно проверить редиректы. Частая проблема после миграции — сайт уходит в redirect loop: Nginx редиректит на HTTPS, CMS тоже редиректит, CDN добавляет свой SSL-режим, а в итоге браузер видит бесконечные перенаправления.

Проверить цепочку редиректов можно так:

curl -I http://example.com

curl -I https://example.com

Если SSL работает, но сайт всё равно не загружается, следующий слой — PHP и база данных.

PHP и база данных

Для WordPress, Laravel, OpenCart и других динамических сайтов недостаточно перенести файлы. Нужно, чтобы PHP работал, база данных была импортирована, а приложение подключалось к ней с правильными доступами.

Если используется PHP-FPM, проверьте сервис: systemctl status php8.2-fpm

Версия может отличаться: php8.1-fpm, php8.3-fpm или другая.

Также нужно убедиться, что Nginx смотрит на актуальный PHP-FPM socket или port: fastcgi_pass unix:/run/php/php8.2-fpm.sock;

Для базы данных проверьте, что MySQL или MariaDB запущены: systemctl status mysql

И что база доступна под теми данными, которые указаны в CMS: mysql -u db_user -p database_name

Для WordPress доступы находятся в wp-config.php, для Laravel и многих других приложений — в .env.

Если сайт показывает Error establishing a database connection, причина часто в имени базы, пользователе, пароле, host, правах пользователя или в том, что dump базы не был корректно импортирован на новый сервер.

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

Пути, права и hidden files

При переносе сайта важно сохранить не только видимые файлы, но и hidden files: .htaccess, .env, .user.ini, конфиги фреймворка и другие файлы, которые начинаются с точки.

Если hidden files не перенесли, сайт может вести себя странно: пропадут rewrite-правила, не подхватятся переменные окружения, сломаются маршруты, появятся ошибки 403, 404 или 500.

Проверить наличие скрытых файлов можно так: ls -la /var/www/example.com

Права доступа тоже важны. Если файлы принадлежат не тому пользователю, веб-сервер может не читать файлы сайта или не писать в uploads, cache и storage.

Пример проверки владельца: ls -la /var/www/example.com

Для типичной связки с www-data права можно поправить так: sudo chown -R www-data:www-data /var/www/example.com

Но это не универсальное правило для всех проектов. Некоторые панели управления, Docker-сборки и деплой-схемы используют отдельного пользователя сайта. Важно не просто выдать права “на всё”, а понять, от какого пользователя работает веб-сервер или PHP-FPM.

Для WordPress отдельно проверьте wp-content/uploads. Для Laravel — storage и bootstrap/cache. Для других CMS — каталоги cache, logs, uploads и временные директории.

Когда файлы, права и hidden files на месте, последний слой проверки — настройки домена внутри самой CMS.

Домен в настройках CMS

После переноса сайт может технически работать, но CMS продолжит считать основным старый домен, старый URL или старый путь. Это приводит к редиректам, сломанным ссылкам, mixed content, redirect loop или переходам на прежний сайт.

В WordPress нужно проверить siteurl и home. Это можно сделать через базу:

SELECT option_name, option_value

FROM wp_options

WHERE option_name IN ('siteurl', 'home');

Если домен изменился, значения нужно обновить аккуратно. Для WordPress также можно временно задать URL в wp-config.php:

define('WP_HOME', 'https://example.com');

define('WP_SITEURL', 'https://example.com');

Для Laravel и других приложений проверьте .env: APP_URL=https://example.com

Для интернет-магазинов и CMS также важно проверить base URL, canonical URL, настройки cookie domain, пути к uploads, настройки HTTPS и редиректы.

Если CMS всё ещё видит старый домен, сайт может открываться на новом VPS, но отдельные страницы, админка, стили, изображения или формы будут вести на прежний адрес.

В итоге чек-лист после миграции должен закрывать всю цепочку: домен указывает на новый IP, порты 80/443 доступны, веб-сервер запущен, virtual host ведёт в правильную директорию, SSL работает, PHP подключается к базе, файлы перенесены вместе с hidden files, права корректны, а CMS знает актуальный домен.

Диагностика по симптомам

После миграции сайт может “не открываться” по-разному. Иногда браузер показывает конкретный код ошибки, иногда открывается пустой белый экран, иногда часть пользователей видит старую версию сайта, а часть — новую.

Поэтому полезно начинать не с догадок, а с симптома. Он помогает быстрее понять, где искать причину: в DNS, firewall, Nginx/Apache, SSL, PHP, базе данных, правах доступа или настройках CMS.

Белый экран

Белый экран после переноса чаще всего связан с ошибкой приложения, PHP или CMS. Сервер может принимать запрос, домен может указывать на правильный IP, но приложение не выводит нормальную страницу.

Для WordPress это часто называют “white screen of death”. Причины могут быть разными:

• PHP-ошибка после переноса;
• Несовместимая версия PHP;
• Не перенесён плагин или тема;
• Сломанный wp-config.php;
• Неверные пути к файлам;
• Недостаточно памяти для PHP;
• Ошибка в .htaccess или rewrite-правилах;
• Права доступа мешают читать файлы.

Начать стоит с логов веб-сервера и PHP. Для Nginx: sudo tail -n 100 /var/log/nginx/error.log

Для Apache: sudo tail -n 100 /var/log/apache2/error.log

Если используется PHP-FPM, проверьте его статус и логи:

systemctl status php8.2-fpm

journalctl -u php8.2-fpm -n 100 --no-pager

Версия PHP может отличаться. На сервере это может быть php8.1-fpm, php8.3-fpm или другая.

Для WordPress можно временно включить debug-режим в wp-config.php, но делать это нужно аккуратно: ошибки не должны выводиться публично на боевом сайте.

define('WP_DEBUG', true);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);

После этого ошибки будут записываться в лог, а не показываться посетителям.

Если вместо белого экрана браузер показывает код 403, 404 или 500, диагностика смещается к правам, virtual host, маршрутам и внутренним ошибкам сервера.

403, 404 или 500

Ошибки 403, 404 и 500 после переноса указывают на разные уровни проблемы.

403 Forbidden обычно означает, что сервер понял запрос, но не даёт доступ. После миграции это часто связано с правами на файлы, владельцем директорий, отсутствием index-файла или запретом в конфиге Nginx/Apache.

Проверить права и владельца можно так: ls -la /var/www/example.com

Также стоит убедиться, что в директории есть стартовый файл:

index.php

index.html

404 Not Found может означать, что домен попал не в тот virtual host, root указывает на неправильную директорию, не перенесены rewrite-правила или CMS не может обработать красивые URL.

Для Nginx проверьте server_name и root:

server_name example.com www.example.com;

root /var/www/example.com/public;

Для Apache и WordPress отдельно важен .htaccess. Если hidden files не перенесли, постоянные ссылки могут сломаться, а внутренние страницы начнут отдавать 404.

500 Internal Server Error чаще связан с ошибкой приложения, PHP, .htaccess, правами, несовместимыми настройками или отсутствующими зависимостями.

При 500 первым делом нужно смотреть логи:

sudo tail -n 100 /var/log/nginx/error.log

sudo tail -n 100 /var/log/apache2/error.log

Если сайт на PHP, дополнительно проверьте PHP-FPM и логи приложения.

Эти ошибки помогают понять, что запрос уже дошёл до VPS. Если же сайт показывает ошибку подключения к базе, проблема обычно находится глубже — в настройках CMS и MySQL/MariaDB.

Database connection error

Ошибка подключения к базе данных после переноса означает, что CMS или приложение не может подключиться к MySQL/MariaDB. Сам веб-сервер при этом может работать нормально.

Для WordPress типичная ошибка выглядит как Error establishing a database connection. Чаще всего причина находится в wp-config.php:

define( 'DB_NAME', 'database_name' );

define( 'DB_USER', 'database_user' );

define( 'DB_PASSWORD', 'database_password' );

define( 'DB_HOST', 'localhost' );

Для Laravel, Symfony и многих других приложений аналогичные настройки находятся в .env:

DB_DATABASE=database_name

DB_USERNAME=database_user

DB_PASSWORD=database_password

DB_HOST=127.0.0.1

После переноса нужно проверить:

• Импортирована ли база на новый VPS;
• Правильно ли указано имя базы;
• Существует ли пользователь базы;
• Верный ли пароль;
• Есть ли у пользователя права на эту базу;
• Правильно ли указан host: localhost, 127.0.0.1 или внешний адрес;
• Запущен ли MySQL/MariaDB.

Проверить статус MySQL: systemctl status mysql

Проверить подключение вручную: mysql -u database_user -p database_name

Если подключение вручную не проходит, проблема не в CMS, а в базе, пользователе, пароле, правах или был запущен движок MySQL/MariaDB или нет.

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

Redirect loop

Redirect loop возникает, когда сайт бесконечно перенаправляет пользователя между адресами. Например, с HTTP на HTTPS, с HTTPS на HTTP, с www на без www, обратно на www или на старый домен.

После переноса это часто связано с тем, что редиректы настроены сразу в нескольких местах:

• в Nginx или Apache;
• в .htaccess;
• в CMS;
• в плагине редиректов;
• в CDN;
• в конфиге приложения.

Проверить цепочку редиректов можно так:

curl -I http://example.com

curl -I https://example.com

Если нужно увидеть несколько переходов подряд: curl -IL http://example.com

Для WordPress нужно проверить siteurl и home:

SELECT option_name, option_value

FROM wp_options

WHERE option_name IN ('siteurl', 'home');

Если сайт должен работать на https://example.com, а в базе остался http://example.com или старый домен, возможны неправильные редиректы, mixed content и проблемы с авторизацией.

Если используется CDN, важно проверить SSL-режим. Например, когда CDN подключается к origin по HTTP, а сайт на VPS принудительно редиректит на HTTPS, может появиться бесконечная петля.

Redirect loop обычно означает, что сервер и CMS спорят о правильном адресе сайта. Нужно выбрать одну каноническую версию: HTTPS, с www или без www, и привести к ней Nginx/Apache, CMS и CDN.

Другой симптом после миграции выглядит менее драматично: сайт открывается, но у части пользователей всё ещё видна старая версия.

Старый сайт у части пользователей

Если после переноса часть пользователей видит новый сайт, а часть — старый, причина чаще всего в DNS. Это нормально в первые часы после изменения записей, особенно если до миграции был большой TTL.

DNS-ответы могут кэшироваться:

• У интернет-провайдера;
• В публичных DNS-резолверах;
• В операционной системе пользователя;
• В браузере;
• В корпоративной сети;
• На стороне CDN.

Проверить, куда резолвится домен с текущей машины, можно так: dig A example.com +short

Проверить через конкретный DNS-сервер:

dig @8.8.8.8 A example.com +short

dig @1.1.1.1 A example.com +short

Если разные резолверы возвращают разные IP, DNS ещё не обновился везде или nameservers настроены неодинаково.

Также нужно проверить www и корневой домен отдельно:

dig A example.com +short

dig A www.example.com +short

Иногда переносят только example.com, но забывают www.example.com, и часть пользователей попадает на другой сервер.

Если используются новые nameservers, важно убедиться, что DNS-зона на них полностью перенесена: A-записи, CNAME, MX, TXT, SPF, DKIM, DMARC и другие важные записи.

Также это может быть ситуация, когда у одних клиентов используется ipv6, а у других ipv4 - и надо не забыть проверить как А-записи, так и АААА.

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

В итоге диагностика по симптомам помогает быстрее сузить поиск: белый экран — PHP и приложение, 403/404/500 — веб-сервер, права и конфиги, database error — база данных, redirect loop — SSL и домен, старый сайт у части пользователей — DNS, TTL и кеши.

Что проверить на VPS

Если DNS уже указывает на новый IP, порты открыты, а сайт всё равно не работает, нужно переходить к проверкам внутри VPS. На этом уровне важно понять, принимает ли сервер запросы, правильно ли настроен virtual host, видит ли приложение базу и хватает ли прав на файлы.

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

Статус сервисов

После переноса сайт зависит от нескольких сервисов. Обычно это Nginx или Apache, PHP-FPM, MySQL/MariaDB, иногда Redis, Node.js, supervisor, Docker или очередь задач.

Начать можно с веб-сервера. Для Nginx: systemctl status nginx

Для Apache: systemctl status apache2

Если сайт работает на PHP-FPM, проверьте PHP: systemctl status php8.2-fpm

Версия может отличаться: php8.1-fpm, php8.3-fpm или другая.

Для базы данных: systemctl status mysql

Или, если используется MariaDB: systemctl status mariadb

Важно смотреть не только на слово active, но и на последние ошибки в выводе systemctl. Сервис может быть запущен, но постоянно перезапускаться, падать после запросов или работать с неправильной конфигурацией.

Если сервисы активны, следующий шаг — проверить, правильно ли сайт описан в конфигурации веб-сервера.

Конфиги сайта

Конфиг сайта определяет, какой домен принимает веб-сервер, в какую директорию он смотрит и как передаёт запросы в PHP или приложение.

Для Nginx сначала проверьте синтаксис: sudo nginx -t

Затем откройте конфиг нужного сайта. Обычно он находится в одном из каталогов:

/etc/nginx/sites-available/

/etc/nginx/conf.d/

В Nginx особенно важны server_name, root и обработка PHP:

server_name example.com www.example.com;

root /var/www/example.com/public;

location ~ \.php$ {

    fastcgi_pass unix:/run/php/php8.2-fpm.sock;

}

Если server_name не совпадает с доменом, запрос может попасть в другой virtual host. Если root указывает не туда, сайт отдаст 404, default page или пустую директорию. Если fastcgi_pass смотрит на старый PHP-FPM socket, PHP-страницы могут не открываться.

Для Apache проверьте конфиги virtual host: /etc/apache2/sites-available/

И синтаксис: sudo apachectl configtest

После изменения конфигов не забудьте reload: sudo systemctl reload nginx

Или для Apache: sudo systemctl reload apache2

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

Логи Nginx/Apache и PHP

Логи помогают понять, что именно происходит при запросе. Без них легко спутать 403 с правами, 404 с неверным root, 500 с ошибкой PHP, а 502 с проблемой PHP-FPM.

Для Nginx проверьте error log: sudo tail -n 100 /var/log/nginx/error.log

Если для сайта настроен отдельный лог, смотрите его: sudo tail -n 100 /var/log/nginx/example.com.error.log

Для Apache: sudo tail -n 100 /var/log/apache2/error.log

Для PHP-FPM: journalctl -u php8.2-fpm -n 100 --no-pager

Также ошибки PHP могут писаться в отдельный файл, если это настроено в php.ini, pool-конфиге или самой CMS.

В логах стоит искать фразы вроде:

permission denied

file not found

primary script unknown

connect() failed

upstream timed out

PHP Fatal error

Access denied

Permission denied часто указывает на права. File not found и Primary script unknown — на неправильный root, fastcgi_param или структуру проекта. PHP Fatal error — на ошибку приложения, несовместимую версию PHP, отсутствующий модуль или проблему с кодом.

Если в логах видно, что приложение не может подключиться к базе, нужно переходить к проверке MySQL/MariaDB и настроек CMS.

Подключение к базе

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

Сначала проверьте, запущена ли база: systemctl status mysql

Затем попробуйте подключиться вручную под теми же данными, которые указаны в CMS: mysql -u db_user -p database_name

Если подключение не проходит, нужно проверить пользователя и права: SHOW GRANTS FOR 'db_user'@'localhost';

Для WordPress настройки находятся в wp-config.php:

define( 'DB_NAME', 'database_name' );

define( 'DB_USER', 'db_user' );

define( 'DB_PASSWORD', 'db_password' );

define( 'DB_HOST', 'localhost' );

Для Laravel и многих других приложений — в .env:

DB_DATABASE=database_name

DB_USERNAME=db_user

DB_PASSWORD=db_password

DB_HOST=127.0.0.1

Отдельно обратите внимание на localhost и 127.0.0.1. В некоторых конфигурациях это может иметь значение: подключение через socket и TCP-подключение обрабатываются по-разному.

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

Когда база доступна, но сайт всё равно отдаёт 403, 500 или не показывает изображения, нужно проверить права на файлы и uploads.

Права на файлы и uploads

После переноса файлы могут принадлежать не тому пользователю. Например, архив распаковали от root, а веб-сервер или PHP-FPM работает от www-data. В результате сайт может открываться частично, но не записывать cache, logs, sessions или uploads.

Проверить владельца и права можно так: ls -la /var/www/example.com

Для WordPress отдельно проверьте:

ls -la /var/www/example.com/wp-content

ls -la /var/www/example.com/wp-content/uploads

Для Laravel:

ls -la /var/www/example.com/storage

ls -la /var/www/example.com/bootstrap/cache

Если используется стандартный пользователь веб-сервера, часто владельца приводят к www-data: sudo chown -R www-data:www-data /var/www/example.com

Базовые права для многих PHP-проектов обычно выглядят так:

find /var/www/example.com -type d -exec chmod 755 {} \;

find /var/www/example.com -type f -exec chmod 644 {} \;

Но это не универсальное правило. Некоторые проекты требуют отдельные права на storage, cache, uploads, logs или временные каталоги. А если сайт работает через панель управления, Docker или отдельного пользователя, нужно ориентироваться на их схему.

Также важно не забыть hidden files. Если при переносе не попали .htaccess, .env, .user.ini или другие скрытые файлы, сайт может открываться не так, как на старом сервере.

Проверить их наличие можно так: ls -la /var/www/example.com

В итоге VPS-проверка должна подтвердить несколько вещей: сервисы запущены, virtual host ведёт в правильную директорию, логи не показывают критических ошибок, база доступна, а файлы, uploads и hidden files находятся на месте с корректными правами.

Типовые ошибки после переноса 

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

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

Nameservers и TTL без плана

Одна из частых ошибок — менять nameservers или DNS-записи без понимания TTL. В результате часть пользователей уже попадает на новый VPS, а часть продолжает видеть старый сайт.

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

Перед миграцией лучше заранее снизить TTL для ключевых записей:

example.com.      A      203.0.113.10

www.example.com.  A      203.0.113.10

После переключения нужно проверять не только свой браузер, а разные резолверы:

dig A example.com +short

dig @8.8.8.8 A example.com +short

dig @1.1.1.1 A example.com +short

Если меняются nameservers, важно перенести всю DNS-зону, а не только A-запись сайта. Иначе можно случайно сломать почту, SPF, DKIM, DMARC, поддомены, верификационные TXT-записи и другие сервисы.

Даже когда DNS уже указывает на новый IP, сайт может не заработать из-за конфигов приложения. Самые критичные из них часто лежат в .env или wp-config.php.

Забытый .env или wp-config.php

После переноса файлов легко забыть конфигурационный файл приложения. Для WordPress это wp-config.php, для Laravel, Symfony, Node.js-приложений и многих других проектов — .env.

В этих файлах могут храниться:

• Имя базы данных;
• Пользователь базы;
• Пароль;
• host базы;
• URL сайта;
• Ключи приложения;
• SMTP-настройки;
• Параметры cache;
• Режим окружения;
• Доступы к внешним API.

Если wp-config.php или .env не перенесены, сайт может показать database connection error, 500, белый экран или начать работать с неправильными настройками.

Для WordPress стоит проверить:

define( 'DB_NAME', 'database_name' );

define( 'DB_USER', 'database_user' );

define( 'DB_PASSWORD', 'database_password' );

define( 'DB_HOST', 'localhost' );

Для приложений с .env:

APP_URL=https://example.com

DB_HOST=127.0.0.1

DB_DATABASE=database_name

DB_USERNAME=database_user

DB_PASSWORD=database_password

Также нужно помнить, что .env — скрытый файл. Если копировали сайт командой, которая не захватывает hidden files, он мог просто не попасть на новый сервер.

Эта же проблема касается не только .env. При миграции часто теряются и другие hidden files.

Неперенесённые hidden files

Hidden files — это файлы и каталоги, которые начинаются с точки. Они могут быть не видны в обычном списке файлов, но для сайта часто критичны.

К ним относятся:

• .htaccess;
• .env;
• .user.ini;
• .well-known;
• .gitignore;
• конфиги фреймворка;
• файлы верификации;
• служебные настройки CMS или деплоя.

Для WordPress на Apache особенно важен .htaccess. В нём могут быть rewrite-правила для постоянных ссылок. Если файл не перенесли, главная страница может открываться, а внутренние страницы будут отдавать 404.

Проверить скрытые файлы можно так: ls -la /var/www/example.com

При копировании через scp, rsync, архивы или файловый менеджер нужно убедиться, что hidden files входят в перенос. Лучше не полагаться только на визуальный список в панели, а проверить директорию через SSH.

Если hidden files потерялись, сайт может выглядеть частично рабочим. Поэтому проблему иногда замечают не сразу: главная открылась, а маршруты, переменные окружения, SSL challenge, cron, cache или API начинают ломаться позже.

Чтобы не переносить ошибки сразу на пользователей, новый VPS лучше проверять заранее через hosts.

Нет проверки через hosts

Проверка через hosts позволяет открыть сайт на новом VPS до переключения DNS для всех пользователей. Это один из самых полезных шагов при миграции.

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

Пример строки для файла hosts: 203.0.113.10 example.com www.example.com

На Windows файл обычно находится здесь: C:\Windows\System32\drivers\etc\hosts

На Linux и macOS: /etc/hosts

Так можно заранее проверить:

• virtual host;
• SSL;
• Редиректы;
• PHP;
• Подключение к базе;
• Авторизацию;
• Админку;
• uploads;
• Формы;
• Корзину;
• Личный кабинет;
• Внутренние страницы;
• Работу CMS с новым доменом.

Если не проверить сайт через hosts, ошибки обнаружатся уже после переключения DNS, когда реальные пользователи начнут попадать на новый VPS.

Но даже проверка через hosts не отменяет финальный тест после переключения DNS. Когда домен реально начал вести на новый сервер, нужно пройти сайт ещё раз.

Нет финального теста после переключения DNS

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

После переключения DNS нужно проверить реальные сценарии:

• Открывается ли главная;
• Работают ли внутренние страницы;
• Открывается ли админка;
• Корректно ли работает HTTPS;
• Нет ли redirect loop;
• Видны ли изображения и uploads;
• Работают ли формы;
• Отправляются ли письма;
• Подключается ли база;
• Работает ли корзина и оформление заказа;
• Не ведут ли ссылки на старый домен;
• Нет ли ошибок в логах.

Для WordPress стоит проверить постоянные ссылки, медиафайлы, плагины, тему, siteurl и home. Для интернет-магазина — каталог, карточку товара, корзину, оформление заказа, оплату, письма клиенту и уведомления администратору.

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

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

Так перенос сайта становится управляемым процессом, а не резким переключением “на удачу”.

Заключение

Если сайт не открывается после переноса на VPS, не стоит сразу менять все настройки подряд. Миграция затрагивает сразу несколько уровней: DNS, firewall, веб-сервер, SSL, PHP, базу данных, файлы, права доступа и настройки CMS.

Правильная диагностика начинается с простого вопроса: домен уже ведёт на новый IP или пользователь всё ещё попадает на старый сервер. После этого нужно проверить порты 80/443, статус Nginx или Apache, virtual host, SSL-сертификат, PHP-FPM, подключение к базе, hidden files, uploads и домен внутри CMS.

Симптомы помогают быстрее сузить поиск. Белый экран чаще связан с PHP или приложением. 403 указывает на права или запрет доступа. 404 — на неправильный root, virtual host или rewrite-правила. 500 — на ошибку приложения, .htaccess, PHP или конфигурации. Database connection error почти всегда ведёт к wp-config.php, .env, пользователю базы, паролю, host или правам доступа к базе.

Отдельно нужно учитывать DNS propagation и TTL. Если часть пользователей видит старый сайт, это не всегда означает, что новый VPS настроен неправильно. Старый IP может сохраняться в кеше у провайдера, резолвера, операционной системы или браузера.

Лучший способ снизить риск — проверять сайт через hosts ещё до переключения DNS. Так можно заранее увидеть проблемы с SSL, virtual host, PHP, базой, путями, правами, uploads и настройками CMS.

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

FAQ

Почему сайт не открывается после переноса на VPS?

Причина может быть на любом уровне: домен всё ещё указывает на старый IP, закрыты порты 80/443, Nginx или Apache не запущен, virtual host настроен неправильно, SSL не выпущен, PHP-FPM не работает, база не подключается или CMS всё ещё использует старый домен.

Начинать диагностику лучше с DNS и доступности сервера, а потом переходить к веб-серверу, SSL, PHP, базе, файлам и настройкам CMS.

Почему часть пользователей видит старый сайт?

Обычно это связано с DNS-кешем и TTL. После изменения A-записи или nameservers разные резолверы обновляют данные не одновременно. Один пользователь уже может попадать на новый VPS, а другой — всё ещё на старый сервер.

Проверить текущий IP можно так:

dig A example.com +short

dig @8.8.8.8 A example.com +short

dig @1.1.1.1 A example.com +short

Старый хостинг лучше оставить активным ещё на несколько дней, чтобы пользователи с устаревшим DNS-кешем не видели ошибку.

Что делать, если после переноса появилась ошибка базы данных?

Нужно проверить настройки подключения к базе. Для WordPress это wp-config.php, для Laravel и многих других приложений — .env.

Проверьте имя базы, пользователя, пароль, host и права пользователя. Также убедитесь, что dump базы действительно импортирован на новый VPS, а MySQL или MariaDB запущены.

systemctl status mysql

mysql -u db_user -p database_name

Если вручную подключиться не получается, проблема не в CMS, а в базе, пользователе, пароле, host или правах.

Почему после переноса появился redirect loop?

Redirect loop возникает, когда сайт бесконечно перенаправляет пользователя между версиями URL. Например, HTTP → HTTPS → HTTP, www → без www → обратно на www или новый домен → старый домен.

Причину нужно искать в Nginx/Apache, .htaccess, CMS, плагинах редиректа, CDN и SSL-настройках.

Проверить цепочку редиректов можно так:

curl -IL http://example.com

curl -IL https://example.com

Для WordPress также проверьте siteurl и home в таблице wp_options.

Зачем проверять сайт через hosts перед переключением DNS?

Файл hosts позволяет открыть новый VPS по домену до того, как DNS начнёт вести всех пользователей на новый IP. Это безопасный способ заранее проверить сайт в условиях, близких к реальным.

Пример строки: 203.0.113.10 example.com www.example.com

Так можно проверить virtual host, SSL, PHP, базу, админку, формы, uploads, редиректы, корзину и настройки CMS до публичного переключения.

Какие hidden files чаще всего забывают перенести?

Чаще всего забывают .env, .htaccess, .user.ini, .well-known, файлы верификации и служебные конфиги фреймворка или CMS.

Проверить скрытые файлы можно так: ls -la /var/www/example.com

Для WordPress на Apache особенно важен .htaccess, потому что без него могут сломаться постоянные ссылки. Для Laravel и многих приложений критичен .env, где хранятся настройки окружения и подключения к базе.

Когда можно отключать старый хостинг после переноса?

Старый хостинг лучше не отключать сразу после смены DNS. Часть пользователей ещё может попадать на старый IP из-за TTL и DNS-кеша.

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

Список источников

1. Nginx Documentation — Beginner’s Guide

2. Apache HTTP Server Documentation — VirtualHost Examples

3. Certbot Documentation — User Guide

4. WordPress Developer Resources — Editing wp-config.php