Как исправить ошибку установления соединения с базой данных
Если вместо сайта вы видите сообщение об ошибке установления соединения с базой данных, WordPress не может получить доступ к MySQL/MariaDB. Это не проблема темы или контента: сайт не может прочитать записи из базы, поэтому не загружается вообще. В большинстве случаев причина сводится к одному из четырёх сценариев: неверные данные подключения, недоступная база, сбой на хостинге или повреждение таблиц.
Хорошая новость в том, что эту ошибку обычно можно локализовать за несколько минут, если проверять причины по порядку, а не менять всё подряд.
С чего начать проверку
Сначала не трогайте плагины, тему и файлы ядра. Для этой ошибки важнее понять, что именно сломалось: сам сервер базы данных, доступ к ней или конфигурация WordPress.
Проверьте три вещи:
- открывается ли панель хостинга и работает ли сайт в других разделах;
- доступна ли база данных в панели управления хостингом;
- не было ли недавно переноса сайта, смены пароля, обновления хостинга или восстановления из бэкапа.
Если ошибка появилась сразу после переноса или смены хостинга, почти всегда проблема в параметрах подключения. Если сайт работал нормально, а потом внезапно упал без ваших действий, чаще всего дело в базе, ресурсах сервера или временном сбое у хостера.
Проверьте данные подключения в wp-config.php
Самая частая причина — неверные параметры в файле wp-config.php. WordPress берёт из него имя базы, пользователя, пароль и адрес сервера базы данных. Если хотя бы один параметр не совпадает с реальными данными, соединение не установится.
Откройте wp-config.php в корне сайта и проверьте строки вида:
define( 'DB_NAME', 'имя_базы' );
define( 'DB_USER', 'пользователь_базы' );
define( 'DB_PASSWORD', 'пароль' );
define( 'DB_HOST', 'localhost' );Что важно проверить на практике:
DB_NAME— точное имя базы данных, как в панели хостинга;DB_USER— именно пользователь базы, а не логин от панели;DB_PASSWORD— актуальный пароль, особенно если его меняли вручную;DB_HOST— не всегдаlocalhost; у некоторых хостингов это отдельный адрес или IP.
Если сайт переносили, не полагайтесь на старый файл конфигурации. После миграции часто меняются и имя базы, и пользователь, и хост подключения. На некоторых хостингах база может быть доступна только по внутреннему адресу, который указан в панели управления.
Проверьте, жива ли сама база данных
Иногда WordPress настроен правильно, но база данных недоступна: сервер MySQL/MariaDB остановлен, перегружен или временно не отвечает. В этом случае ошибка будет одинаковой, даже если файл wp-config.php безупречен.
Если у вас есть доступ к панели хостинга, откройте раздел баз данных и посмотрите, не отмечена ли база как недоступная. На виртуальном хостинге это обычно видно через phpMyAdmin или внутреннюю панель. Если есть только доступ к сайту, а панели нет, остаётся написать в поддержку хостинга и попросить проверить состояние сервиса MySQL/MariaDB именно для вашего аккаунта.
Полезный признак: если в панели хостинга phpMyAdmin тоже не открывается или выдаёт ошибку подключения, проблема почти наверняка на стороне базы или сервера, а не WordPress.
Если пароль или пользователь базы были изменены
После смены пароля в панели хостинга WordPress сам его не узнает. Нужно вручную обновить wp-config.php. Это частая ситуация после восстановления доступа к панели, смены тарифа или переноса сайта другим специалистом.
Если вы не уверены, какой пароль сейчас актуален, проще всего создать нового пользователя базы с нужными правами и прописать его в wp-config.php. Это безопаснее, чем пытаться угадать старый пароль. После этого проверьте, что у пользователя есть права на чтение и запись в нужной базе.
Если у вас несколько сайтов на одном хостинге, не перепутайте базы. Ошибка часто возникает именно из-за того, что в конфиге указан пользователь от другого проекта, у которого есть доступ к другой базе.
Когда помогает восстановление таблиц
Если данные подключения верны, а база доступна, но ошибка остаётся, возможна проблема с таблицами. Это бывает после некорректного завершения работы сервера, сбоя диска, неудачного обновления или повреждения отдельных таблиц.
WordPress умеет запускать режим восстановления базы. Для этого в wp-config.php временно добавляют строку:
define( 'WP_ALLOW_REPAIR', true );После этого откройте адрес:
https://ваш-домен/wp-admin/maint/repair.phpНа странице будет два варианта: восстановление и восстановление с оптимизацией. Для аварийной ситуации обычно достаточно восстановления. Оптимизацию лучше запускать только если вы понимаете, зачем она нужна, и у вас есть свежая резервная копия, потому что операция дольше и сильнее нагружает базу.
После завершения обязательно удалите строку WP_ALLOW_REPAIR из wp-config.php. Оставлять её включённой не нужно.
Если сайт упал после обновления или переноса
После обновления ядра, плагинов или темы ошибка соединения с базой данных обычно не связана напрямую с самим обновлением. Чаще совпадают два события: обновление и уже существующая проблема с сервером или базой. Но после переноса сайта причина действительно может быть в неверном DB_HOST, в старых данных доступа или в том, что база была импортирована не полностью.
При переносе проверьте:
- совпадает ли имя базы с тем, что создано на новом хостинге;
- создан ли пользователь базы и выданы ли ему права;
- корректно ли импортирован дамп базы без ошибок;
- не остался ли в
wp-config.phpстарый адрес сервера базы.
Если перенос делался вручную, полезно ещё раз открыть логи импорта в phpMyAdmin или в панели хостинга. Иногда база импортируется не до конца, и WordPress не может прочитать нужные таблицы.
Как отличить проблему WordPress от проблемы хостинга
Это важный момент, потому что от него зависит, что делать дальше. WordPress можно исправить самостоятельно, если проблема в конфиге или таблицах. Если же не отвечает сам сервер базы, вы не решите это только правкой файлов сайта.
| Симптом | Что вероятнее всего сломалось | Что делать |
|---|---|---|
| Неверный логин или пароль в конфиге | Параметры подключения | Проверить wp-config.php и данные в панели хостинга |
| phpMyAdmin тоже не открывается | Проблема на стороне MySQL/MariaDB или хостинга | Обратиться в поддержку хостинга |
| Сайт не открывается после переноса | Неверный DB_HOST или данные базы | Сверить конфиг с новой панелью |
| Ошибка появилась после сбоя сервера | Повреждение таблиц или временная недоступность базы | Запустить восстановление или дождаться стабилизации сервиса |
Что делать, если нужен быстрый возврат сайта в работу
Если задача срочная, действуйте в таком порядке:
- Проверьте
wp-config.phpи сравните данные с панелью хостинга. - Убедитесь, что база данных существует и пользователь имеет к ней доступ.
- Проверьте, открывается ли phpMyAdmin или другой инструмент управления базой.
- Если база доступна, но сайт всё равно падает, запустите штатное восстановление таблиц WordPress.
- Если база не отвечает вообще, пишите в поддержку хостинга и просите проверить MySQL/MariaDB по вашему аккаунту.
На этом этапе не стоит массово отключать плагины, менять тему или переустанавливать WordPress. Эти действия не решают ошибку соединения с базой данных, если проблема находится ниже уровня CMS.
Когда имеет смысл подключать дополнительные инструменты
Для самой ошибки никакой отдельный плагин обычно не нужен. WordPress и панель хостинга дают всё необходимое для диагностики. Дополнительные инструменты полезны уже после восстановления сайта: для бэкапов, контроля изменений и более удобного обслуживания.
Если вы регулярно ведёте несколько сайтов и хотите упростить обслуживание, можно посмотреть каталог полезных инструментов WPShop: https://wpshop.ru/plugins. Но для устранения именно этой ошибки сначала важнее проверить конфигурацию, доступ к базе и состояние сервера, а не ставить новый плагин.
Если после всех проверок сайт всё ещё не открывается, а данные подключения верны, проблема почти наверняка на стороне хостинга или самой базы. В таком случае лучший следующий шаг — запрос в поддержку с конкретикой: имя базы, время появления ошибки, факт проверки wp-config.php и результат входа в phpMyAdmin. Так вы быстрее получите не общий ответ, а проверку именно того узла, который сломался.