Ошибка соединения с базой данных WordPress: как починить

«Error establishing a database connection» — «Ошибка установки соединения с базой данных». WordPress хранит весь контент в MySQL или MariaDB, и если движок не смог подключиться к базе, показывать ему нечего: вместо сайта — эта заглушка на белом фоне.

Хорошая новость: данные почти наверняка целы. Ошибка означает «не могу достучаться до базы», а не «база пропала». Причин всего четыре: неверные реквизиты подключения в wp-config.php, упавший сервер MySQL, повреждённые таблицы или проблемы на стороне хостинга. Разберём диагностику по шагам — от самой частой причины к самой редкой.

Если вместо этой заглушки сервер отдаёт «500 Internal Server Error» — это другая история, читайте разбор ошибки 500.

Быстрая диагностика: симптом → причина → что делать

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

Симптом	Вероятная причина	Что делать
Ошибка появилась после переноса сайта, смены пароля БД или правки конфига	Неверные реквизиты в wp-config.php	Сверить DB_NAME, DB_USER, DB_PASSWORD, DB_HOST с панелью хостинга (шаг 1)
Сайт лежит, а на /wp-admin — сообщение «One or more database tables are unavailable»	Повреждённые таблицы	Ремонт через WP_ALLOW_REPAIR или wp db repair (шаг 3)
VPS: ошибка после перезагрузки сервера или скачка нагрузки	MySQL не запустился или был убит из-за нехватки памяти	Проверить статус службы и перезапустить (шаг 2)
Ошибка появляется периодически под нагрузкой и сама пропадает	Исчерпан лимит подключений, серверу БД не хватает ресурсов	Кэширование, тикет хостеру или тюнинг MySQL (шаг 4)
Ничего не меняли, шаред-хостинг, лежит весь сайт	Авария или перегрузка на стороне хостера	Проверить статус хостинга, написать в поддержку (шаг 4)
Ошибка после установки плагина «оптимизации БД» или чистки таблиц	Повреждённые или удалённые таблицы	Ремонт таблиц, при неудаче — восстановление из бэкапа

Теперь — каждый шаг подробно.

Шаг 1. Сверьте реквизиты в wp-config.php

Самая частая причина, особенно после переноса сайта или смены пароля в панели хостинга. Подключитесь по FTP/SFTP или откройте файловый менеджер хостинга и найдите в корне сайта файл wp-config.php. Реквизиты подключения — четыре константы:

define( 'DB_NAME', 'имя_базы' );
define( 'DB_USER', 'пользователь_базы' );
define( 'DB_PASSWORD', 'пароль' );
define( 'DB_HOST', 'localhost' );

Сверьте каждую с данными из панели хостинга (раздел «Базы данных» или «MySQL»). Проверяйте посимвольно: лишний пробел, старый пароль или префикс аккаунта в имени базы (user_wp вместо wp) — и соединения не будет.

Отдельное внимание — DB_HOST. На большинстве хостингов это localhost, но не везде: встречаются отдельные серверы вида mysql.hosting.ru, адреса с портом (127.0.0.1:3307) или путь к сокету. Правильное значение указано в панели хостинга или в письме с реквизитами.

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

mysql -u пользователь_базы -p -h localhost имя_базы

Команда спросит пароль. Пустили внутрь — реквизиты верны, причина в другом. Access denied — ошибка именно в логине, пароле или правах пользователя: создайте нового пользователя БД в панели хостинга и пропишите его в wp-config.php.

Без SSH то же самое делает тестовый PHP-файл. Создайте в корне сайта db-test.php:

<?php
$link = mysqli_connect( 'localhost', 'пользователь', 'пароль', 'имя_базы' );
if ( ! $link ) {
    die( 'Ошибка: ' . mysqli_connect_error() );
}
echo 'Соединение работает';

Откройте https://ваш-сайт.ru/db-test.php — текст ошибки подскажет причину: Access denied — неверные логин/пароль, Unknown database — опечатка в имени базы, Connection refused или таймаут — сервер MySQL недоступен. После проверки файл обязательно удалите: он содержит пароль от базы.

Шаг 2. Проверьте, жив ли сервер MySQL

Актуально, если у вас VPS или выделенный сервер. Реквизиты верны, но подключаться не к чему: служба MySQL/MariaDB упала. Типовые сценарии — сервер перезагрузился, а автозапуск службы не настроен, или на машине кончилась память и система принудительно завершила самый «тяжёлый» процесс, которым обычно оказывается mysqld.

Проверка и перезапуск по SSH:

systemctl status mysql      # или mariadb — смотря что установлено
sudo systemctl restart mysql
sudo systemctl enable mysql # автозапуск после перезагрузки

Если служба не стартует, смотрите её лог (journalctl -u mysql -n 50) и проверьте свободное место на диске (df -h): переполненный диск — банальная и частая причина, MySQL не может писать и отказывается запускаться.

Если WP-CLI установлен, состояние базы удобно проверять одной командой:

wp db check

Она подключается с реквизитами из wp-config.php и прогоняет проверку всех таблиц — сразу видно и доступность сервера, и целостность данных.

На шаред-хостинге этого шага у вас нет: сервером БД управляет хостер. Если реквизиты верны, а базы нет — переходите к шагу 4.

Шаг 3. Почините повреждённые таблицы

Таблицы MySQL могут «биться» — после аварийной перезагрузки сервера, переполнения диска или сбоя во время записи. Характерный признак: сайт лежит с ошибкой соединения, а по адресу /wp-admin WordPress пишет что-то вроде «One or more database tables are unavailable» и сам предлагает ремонт.

У WordPress для этого есть встроенный инструмент. Добавьте в wp-config.php строку — выше комментария «Это всё, дальше не редактируем»:

define( 'WP_ALLOW_REPAIR', true );

Затем откройте в браузере:

https://ваш-сайт.ru/wp-admin/maint/repair.php

Страница предложит два варианта: «Repair Database» (только ремонт) и «Repair and Optimize Database» (ремонт с оптимизацией — дольше). Для починки достаточно первого. Инструмент пройдётся по стандартным таблицам WordPress и покажет отчёт по каждой.

Важно: страница ремонта доступна любому, без входа в админку. Как только таблицы починены — удалите строку WP_ALLOW_REPAIR из wp-config.php, не откладывая.

С WP-CLI то же самое без правки конфига:

wp db repair

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

Шаг 4. Когда виноват хостер, а когда вы

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

Похоже на хостера, если:

• вы ничего не меняли — ни файлов, ни плагинов, ни паролей, — и сайт внезапно лёг;
• ошибка появляется волнами: несколько минут лежит, потом работает;
• лежат и другие сайты на том же аккаунте;
• страница статуса хостинга сообщает о работах или аварии.

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

Похоже на вас, если:

• ошибка появилась сразу после переноса, правки wp-config.php или смены пароля БД — шаг 1;
• у вас VPS и ошибка возникла после перезагрузки или роста трафика — шаг 2, а дальше стоит добавить памяти или настроить кэширование;
• перед поломкой вы «оптимизировали» базу плагином или руками удаляли таблицы — шаг 3 и бэкап;
• сайт под атакой или на него пришёл всплеск ботов — каждое обращение к странице без кэша порождает запросы к БД, и база захлёбывается. Кэширующий плагин снимает бо́льшую часть таких запросов.

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

Что сделать после починки

Ошибку убрали — теперь три коротких дела, чтобы не проходить этот квест снова:

1. Удалите временные правки. Строку WP_ALLOW_REPAIR из wp-config.php, тестовый db-test.php из корня — всё это дыры в безопасности, если оставить.
2. Настройте бэкапы базы. Автоматический дамп хотя бы раз в сутки — панелью хостинга или плагином. При битых таблицах свежий дамп превращает аварию из катастрофы в пятиминутный откат.
3. Поставьте кэширование. Кэш страниц радикально снижает число запросов к базе — сайт переживёт и всплеск трафика, и «тесный» тариф. С чего начать — в статье как ускорить WordPress.

Сама по себе ошибка соединения с базой — не приговор и не потеря данных. Это разрыв между WordPress и MySQL, который в большинстве случаев закрывается за 10–15 минут: сверить реквизиты, перезапустить сервер или прогнать ремонт таблиц. Главное — идти по шагам и не править всё подряд наугад.