Сайт не подключается к MySQL после переноса: как исправить Access denied и ошибку соединения

Коротко: что сделать сразу

• Сделайте копию config.php/.env/wp-config.php и экспорт базы перед правками.
• В панели хостинга откройте раздел MySQL/Базы данных и выпишите точные имя базы, пользователя и хост.
• Не путайте пароль от панели хостинга, FTP и MySQL — это разные учётные данные.
• Проверьте, что пользователь добавлен к нужной базе и ему выданы необходимые права.
• Меняйте по одному параметру в конфиге и после каждого шага проверяйте сайт.

По тексту ошибки можно сразу сузить поиск

Access denied for user обычно означает: сервер MySQL найден, но не принял пользователя/пароль или пользователь не имеет доступа к этой базе.

Unknown database — указанного имени базы на сервере нет. Часто после переноса хостер добавляет к имени префикс аккаунта.

Connection refused или тайм-аут — неверный DB_HOST, MySQL не слушает этот адрес или хостинг запрещает удалённое подключение. Для сайта на том же shared-хостинге обычно нужен внутренний адрес, который показывает панель.

Table does not exist — подключение уже работает, но импортирована не та база, не все таблицы или приложение использует другой префикс таблиц.

Где найти правильные параметры в панели хостинга

В cPanel ищите MySQL Databases, в ISPmanager — «Базы данных», у других хостеров — «MySQL», «БД» или «Управление базами». Названия отличаются, но вам нужны четыре вещи: имя базы, имя пользователя, сервер/хост и назначенные права.

Обратите внимание на префиксы. Вы могли создать базу site, а фактическое имя будет account_site. То же касается пользователя. В конфигурации сайта нужно фактическое имя, а не короткая подпись из старого хостинга.

Проверьте связь «пользователь → база → права»

Создать пользователя недостаточно. Во многих панелях его нужно отдельно добавить к базе и назначить привилегии. Если этого не сделать, логин существует, пароль правильный, но MySQL всё равно отвечает Access denied.

Для обычной CMS обычно нужны права чтения и изменения таблиц; при установке и обновлении — ещё создание/изменение структуры. Не выдавайте глобальные права на все базы аккаунта, если достаточно доступа к одной конкретной базе.

Как безопасно править config.php, .env или wp-config.php

Перед изменением скачайте текущий конфиг. В WordPress параметры находятся в wp-config.php, в Laravel и многих современных приложениях — в .env, в самописных сайтах — в config.php или похожем файле.

Меняйте только DB_NAME, DB_USER, DB_PASSWORD и DB_HOST, если именно они отличаются. Не публикуйте эти значения в тикете, чате или скриншоте без необходимости. Пароль к базе хранится в конфиге потому, что приложению он нужен, но сам конфиг не должен отдаваться браузером как текст.

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

Убедитесь, что база действительно импортирована

Откройте phpMyAdmin из панели и выберите нужную базу. Вы должны видеть таблицы сайта. Если база пустая, импортируйте SQL-дамп через штатный раздел «Импорт». Перед повторным импортом не удаляйте рабочие таблицы наугад: сначала сделайте экспорт текущего состояния.

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

DB_HOST: localhost подходит не всегда

На одном хостинге MySQL доступен как localhost, на другом — отдельным именем сервера. После переезда старое значение может стать неправильным. Точное значение смотрите в панели или в инструкции именно вашего хостера.

Не открывайте удалённый доступ к MySQL «для всех IP», если сайт и база находятся на одном сервере. Это лишний риск. Если удалённое подключение действительно нужно, ограничивайте доступ конкретным IP и используйте защищённый канал согласно правилам хостинга.

DNS после переноса: почему сайт может вести себя по-разному

Если домен только что переключили на новый хостинг, часть посетителей может ещё попадать на старый сервер, а вы — уже на новый. Перед изменением DNS всегда сохраняйте текущие записи, особенно почтовые MX/SPF/DKIM/DMARC.

Распространение DNS может занимать до 24–48 часов из-за TTL и кэша у провайдеров. Поэтому в переходный период один пользователь может видеть исправленный сайт, а другой — старую ошибку подключения к базе.

Как понять, что проблема решена

Сайт открывает главную и несколько внутренних страниц, вход в административную часть проходит, операции чтения и записи работают: например, сохраняется тестовая настройка или черновик. В журнале PHP/MySQL больше нет Access denied, Unknown database или ошибок соединения.

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

Когда лучше остановиться и не экспериментировать

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

Перед правкой config.php, .env, базы и DNS обязательно делайте копию. Не отключайте SSL-проверки, не ставьте 777 и не храните пароли в открытых txt-файлах. Если неясно, какая база актуальная, остановитесь до выяснения.

Вывод

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