Утром вместо главной — серая страница «Error establishing a database connection» или «Ошибка установки соединения с базой данных». Админка та же, заявки не приходят. Общий порядок при «сайт не работает» — в hub-статье по симптомам. В сопровождении WordPress это одна из самых частых «внезапных смертей» сайта — и почти всегда решается за 20–60 минут, если идти по чек-листу, а не переустанавливать CMS с нуля.
Что означает ошибка подключения к базе
WordPress на каждом запросе открывает соединение с MySQL или MariaDB через параметры из wp-config.php: имя базы, пользователь, пароль, хост. Если драйвер не подключился — ядро не загружается и показывает одну из двух фраз:
- Error establishing a database connection (английская локаль);
- Ошибка установки соединения с базой данных (русская).
Это не «сломался WordPress» и не вирус. Это разрыв между PHP и базой: неверные реквизиты, остановленный MySQL, переполненный диск или битые таблицы после сбоя сервера. Картина похожа на белый экран и ошибку 500, но текст ошибки однозначный — начинайте с базы, а не с плагинов.
Шаг 1. Проверьте: падает весь сайт или одна страница
Откройте главную и любую запись. Если везде одно и то же сообщение про базу — проблема глобальная (конфиг, MySQL, лимиты хостинга). Если только отдельные URL — реже, но бывает повреждение одной таблицы или плагин кэша отдаёт старую заглушку; всё равно первым делом смотрите wp-config.php и статус MySQL.
Шаг 2. Сверьте wp-config.php с панелью хостинга
По FTP или файловому менеджеру откройте wp-config.php в корне сайта. Нужны четыре строки:
define('DB_NAME', 'имя_базы');
define('DB_USER', 'пользователь');
define('DB_PASSWORD', 'пароль');
define('DB_HOST', 'localhost');На Beget, Timeweb, Reg.ru, SpaceWeb актуальные значения — в разделе «Базы данных MySQL» личного кабинета. Типовые промахи:
- после переноса на другой хостинг забыли обновить пароль или имя базы (часто с префиксом
u123456_); - скопировали
wp-config.phpсо staging, а база на проде другая; - лишний пробел в пароле при правке в блокноте;
- вместо
DB_HOSTуказали URL сайта, а не хост MySQL.
DB_HOST: на shared чаще всего localhost. На части хостингов — localhost:/tmp/mysql.sock или отдельный хост вида mysql123.hosting.ru — смотрите подсказку в панели, не угадывайте.
Шаг 3. Жив ли MySQL на хостинге
Зайдите в панель хостинга → MySQL / MariaDB. Признаки проблемы на стороне сервера:
- база «остановлена» или «приостановлена»;
- закончилась квота диска — MySQL не стартует;
- техработы — статус в новостях хостера;
- на тарифе исчерпан лимит одновременных подключений (тяжёлый импорт, зависший cron).
Если phpMyAdmin из панели тоже не подключается с теми же логином и паролем — править нужно не WordPress, а хостинг (оплата, лимиты, тикет в поддержку).
Шаг 4. Проверка через phpMyAdmin
Откройте phpMyAdmin из панели хостинга, войдите тем же пользователем, что в wp-config.php.
- Вход успешен — MySQL жив, логин/пароль верны. Значит, WordPress смотрит не туда: другой
DB_NAME, опечатка вDB_HOST, или на сервере два окружения (staging/prod перепутали). - Access denied — неверный пароль или пользователь не привязан к базе. Сбросьте пароль пользователя MySQL в панели и обновите
DB_PASSWORD. - База пустая — после миграции залили файлы, но не импортировали SQL. Нужен дамп из бэкапа.
Шаг 5. Починка таблиц (Repair)
Если реквизиты верны, MySQL работает, но сайт всё равно показывает ошибку — таблицы могли повредиться при резком выключении VPS или переполнении диска. В phpMyAdmin выберите базу → отметьте все таблицы с префиксом wp_ (или ваш кастомный) → «Восстановить» / Repair.
Альтернатива — временно в wp-config.php:
define('WP_ALLOW_REPAIR', true);Откройте https://ваш-сайт.ru/wp-admin/maint/repair.php, запустите repair. Сразу после удалите константу — иначе страницу восстановления увидят все.
Шаг 6. После смены пароля, домена или переноса
Типовой сценарий: перенесли файлы по FTP, домен уже смотрит на новый хостинг, а:
- дамп базы не импортировали;
- создали новую пустую базу с другим именем;
- на старом хосте MySQL ещё «живой», а DNS уже на новом — кажется, что «всё сломалось за ночь».
Порядок при переезде: бэкап → импорт SQL на новом хосте → правка wp-config.php → проверка siteurl и home в таблице wp_options (или через WP-CLI / одноразовый скрипт). Подробнее про выбор хостинга и лимиты — в статье про хостинг для WordPress.
Что не делать
- Не переустанавливать WordPress поверх живой базы «на авось» — риск потерять контент и получить дубли таблиц.
- Не публиковать wp-config.php в чатах и тикетах — там пароль базы. Достаточно скриншота панели с замазанным паролем.
- Не править таблицы вручную, если не уверены в SQL — одна ошибка в
wp_optionsломает URL сайта. - Не путать с critical error — там другое сообщение и решается отключением плагина; см. критическая ошибка WordPress.
Когда звать специалиста
Если за 30–40 минут не помогли проверка wp-config.php, phpMyAdmin и repair — нужны логи MySQL и доступ SSH, которых на shared может не быть. Пишите на срочную починку: опишем, что проверили, восстановим из бэкапа или поднимем базу на Timeweb/Beget. Оценка задачи бесплатно, оплата по факту.
