Ошибка подключения к базе данных в WordPress: как её исправить

Вы открываете сайт, и каждая страница — и публичная часть, и wp-admin — заменена одной серой строкой: Ошибка установки соединения с базой данных. Ничего не отображается, потому что и не может. WordPress не дошёл даже до сборки страницы.

Вот модель, которая делает починку быстрой. WordPress хранит весь ваш контент — записи, страницы, настройки, пользователей — в базе данных MySQL, а не в файлах. На каждый запрос он читает четыре учётных данных из wp-config.php, подключается к этой базе и берёт нужное. Эта ошибка означает, что соединение было предпринято и отклонено. Чтобы исправить, нужно понять, почему его отклонили, а вариантов всего три.

Три причины, в порядке вероятности

1. Неверные учётные данные в wp-config.php — обычный итог переезда на другой хостинг.
2. Сервер базы данных выключен или перегружен — обычный итог того, что с вашей стороны ничего не менялось.
3. База данных повреждена — реже, и проявляет себя иначе.

Разбирайтесь с ними именно в этом порядке.

Шаг 1: проверьте четыре учётных данных

Откройте wp-config.php в корне сайта по SFTP или через файловый менеджер хостинга. Соединение задают четыре строки:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Каждое из этих значений должно в точности совпадать с тем, что выдал хостинг. Откройте раздел баз данных в панели управления хостинга (в cPanel это «MySQL Databases») и сверьте символ за символом:

• DB_NAME — хостинги часто добавляют к имени префикс с вашим аккаунтом, например cpaneluser_wpdb. Префикс — часть имени.
• DB_USER — тот же префикс, и пользователь должен быть назначен на эту базу данных, а не просто существовать.
• DB_PASSWORD — самый частый виновник. Если сомневаетесь, сбросьте его в панели управления и вставьте новое значение. Следите за пробелом в конце и за «умной» кавычкой.
• DB_HOST — не считайте, что это localhost. Многие хостинги используют отдельный сервер базы данных с адресом вроде mysql.yourhost.com, иногда с :port. Правильное значение показано в панели управления.

Поскольку именно в этом файле и хранятся четыре значения, самый надёжный способ заново получить чистый и правильно закавыченный wp-config.php — генератор wp-config.php: заполните четыре поля базы данных и вставьте результат поверх старого блока.

Один этот шаг устраняет ошибку почти после каждого переезда: учётные данные, которые были верны на старом хостинге, на новом уже не годятся.

Шаг 2: убедитесь, что сервер базы данных действительно работает

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

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

Чтобы проверить, действительны ли учётные данные вообще, независимо от WordPress, положите рядом с wp-config.php крошечный скрипт:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Подставьте свои настоящие DB_HOST, DB_USER и DB_PASSWORD. Если выводится Connected, логин работает, и проблема в другом (повреждённая база данных, Шаг 3). Если выводится ошибка соединения, само сообщение подскажет, какая именно: «Access denied» — неверный пользователь или пароль; «Can’t connect to MySQL server» — неверный хост или действительно недоступная служба, и тогда пора писать в хостинг. Удалите скрипт, как только закончите.

Шаг 3: восстановите повреждённую базу данных

Повреждение от проблемы с подключением отличает один признак: публичная часть открывается, а wp-admin показывает ошибку — или наоборот. Если бы соединение действительно отклонялось, не работало бы ни то, ни другое. Такое расхождение указывает на повреждённые таблицы.

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

define( 'WP_ALLOW_REPAIR', true );

Затем откройте этот URL прямо в браузере:

https://yoursite.com/wp-admin/maint/repair.php

Она загружается без входа — в этом весь смысл, ведь доступ у вас может быть закрыт — и предлагает «Восстановить базу данных» и «Восстановить и оптимизировать базу данных». Запустите.

Затем сразу удалите эту строку из wp-config.php. Пока она на месте, любой человек в интернете может открыть этот URL и запустить восстановление вашей базы данных. Это не необязательная уборка, а закрытие дыры, которую вы только что открыли.

Шаг 4: когда восстановление даже не подключается

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

Советы, которые можно спокойно игнорировать

«Просто переустановите WordPress». Эта ошибка про подключение к базе данных, а не про файлы ядра. Переустановка заменяет как раз те файлы, что и так работают, и не трогает ничего сломанного.

«Увеличьте лимит памяти PHP». Исчерпание памяти — это другая ошибка с другим сообщением. Повышение лимита ничего не даёт при отклонённом подключении к базе данных и лишь маскирует то, что вы так и не проверили учётные данные.

«Очистите кэш». Сбой происходит в PHP раньше, чем кэш успеет отдать страницу. Пока соединение отклоняется, очистка кэша ничего не меняет; её стоит делать только после того, как сайт вернётся к жизни.

«Отредактируйте базу данных напрямую». Лезть в phpMyAdmin и править таблицы вручную, не убедившись даже, что соединение работает, — так временный сбой превращается в безвозвратную потерю данных. Сначала убедитесь в соединении; данные трогайте в последнюю очередь и только из резервной копии.

Всё ещё не получается?

Если тестовый скрипт подтверждает учётные данные, сервер работает, восстановление подключается и не находит ошибок, а сайт всё равно показывает сообщение, остаётся один подозреваемый — плагин, который обращается к базе данных по собственному соединению: кэширующий или работающий с базой плагин, сохранивший устаревший хост. Чтобы это исключить, переименуйте wp-content/plugins в plugins-off по SFTP. Если ошибка исчезнет, возвращайте плагины по одному, пока она не появится снова.