WordPress: ошибка Error establishing database connection — причины и решение

MAATRIX

Вместо сайта — короткая строка: WordPress ошибка Error establishing database connection. Это значит, что WordPress не смог подключиться к базе данных, и весь сайт лёг, потому что без базы он не работает. Причина всегда в одном из четырёх: неверные данные в конфиге, база не запущена, у пользователя нет доступа или база повреждена. Разберём по порядку, как быстро найти виновника и поднять сайт.

Первое действие: проверьте, жива ли база

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

systemctl status mysql
mysqladmin ping

Если сервис не запущен или mysqladmin ping не отвечает — проблема в самой базе, а не в WordPress. Запустите MySQL и, если он не стартует, разбирайтесь уже с базой (частые причины — переполненный диск, повреждение, нехватка памяти). Если же база жива и отвечает — значит, дело в настройках подключения или правах, и переходим к конфигу. Это разделение важно: половина случаев «database connection error» — это просто упавший или не запустившийся MySQL, и лечится он на стороне базы, а не WordPress. Определив, жива база или нет, вы сразу знаете, куда смотреть дальше.

Причина 1: неверные данные в wp-config.php

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

define('DB_NAME', 'mydb');
define('DB_USER', 'myuser');
define('DB_PASSWORD', 'пароль');
define('DB_HOST', 'localhost');

Теперь проверьте, что этими же данными реально можно зайти в базу — подключитесь вручную ровно с теми же логином, паролем и именем базы:

mysql -u myuser -p mydb

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

Причина 2: неверный DB_HOST

Отдельно стоит разобрать DB_HOST, потому что это частый камень преткновения при переносах и на разных конфигурациях. Обычно это localhost, но бывают варианты: если MySQL слушает по сети, нужен IP или имя хоста; если база в отдельном контейнере — имя сервиса; на некоторых системах вместо localhost нужен 127.0.0.1 (разница в том, что localhost идёт через сокет, а 127.0.0.1 — через TCP). Проверьте, на чём слушает база:

ss -tlnp | grep 3306

Если база слушает только сокет, а вы указали 127.0.0.1, или наоборот — подключение не пройдёт. При переносе с хостинга на VPS часто остаётся старый DB_HOST от прежнего провайдера, который на новом сервере не работает. Приведите DB_HOST в соответствие с реальным расположением и способом подключения к базе. Если WordPress и MySQL на одном сервере — почти всегда подходит localhost или 127.0.0.1. Правильный DB_HOST — обязательное условие, и его легко упустить именно при миграциях.

Причина 3: у пользователя нет прав на базу

Иногда данные верны и хост правильный, но пользователь базы не имеет прав на нужную базу — например, после восстановления из дампа пользователя создали, а права выдать забыли, или база перенесена, а грант потерян. Проверьте права пользователя:

SHOW GRANTS FOR 'myuser'@'localhost';

Если среди грантов нет доступа к вашей базе, выдайте права и примените их:

GRANT ALL PRIVILEGES ON mydb.* TO 'myuser'@'localhost';
FLUSH PRIVILEGES;

Обратите внимание на часть @'localhost': права в MySQL привязаны к паре «пользователь плюс хост, откуда он подключается». Если WordPress ходит с 127.0.0.1, а грант выдан на localhost (или наоборот), доступа не будет — это частая тонкость. Убедитесь, что пользователь, хост подключения и права согласованы. Выдача корректных прав завершает настройку доступа: пользователь не только существует и знает пароль, но и реально может работать с базой сайта. После этого WordPress подключится.

Причина 4: повреждённая база данных

Если подключение проходит, но WordPress всё равно жалуется, или сайт частично работает со сбоями — возможно, повреждены таблицы базы, часто после сбоя питания или переполнения диска. WordPress даже может подсказывать про «one or more database tables are unavailable». Проверьте и, при необходимости, почините таблицы:

mysqlcheck --auto-repair --databases mydb

Команда проверит и попытается автоматически восстановить повреждённые таблицы. У WordPress есть и встроенный инструмент восстановления базы — его включают строкой define('WP_ALLOW_REPAIR', true); в wp-config.php, после чего доступна страница /wp-admin/maint/repair.php (после починки эту строку обязательно убирают). Повреждение базы — менее частая, но возможная причина, особенно если проблеме предшествовал жёсткий сбой сервера или переполнение диска. Починка таблиц или восстановление из бэкапа возвращают базу в рабочее состояние. Если повреждение серьёзное — восстановление из свежего дампа надёжнее ремонта.

Как проверить, что сайт снова работает

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

mysql -u myuser -p'пароль' -e "USE mydb; SELECT COUNT(*) FROM wp_options;"
curl -I https://site.ru

Успешный запрос к таблице wp_options подтверждает, что учётные данные, хост, права и целостность базы в порядке, а curl покажет, что сайт отвечает нормально, а не ошибкой базы. Если запрос к базе проходит, а WordPress всё ещё ругается — перепроверьте, что правите тот самый wp-config.php, который использует сайт (на сервере бывает несколько копий или сайтов). Проверка именно теми параметрами, что в конфиге, снимает неопределённость и подтверждает, что проблема устранена по сути.

Профилактика: чтобы база всегда была на связи

Чтобы ошибка подключения к базе не заставала врасплох, соблюдайте несколько правил. При переносе сайта первым делом сверяйте DB_NAME, DB_USER, DB_PASSWORD и DB_HOST с реальными параметрами нового сервера — большинство ошибок подключения возникает именно при миграциях. Держите скрипт создания пользователя базы и выдачи прав вместе с проектом, чтобы развернуть базу с нуля без забытых грантов. Следите за свободным местом на диске: переполнение и роняет базу, и повреждает таблицы.

Настройте мониторинг доступности MySQL и автоматические бэкапы базы, лежащие отдельно от сервера, — тогда и упавшую базу вы заметите сразу, и при повреждении восстановитесь из дампа за минуты. Свой VPS с полным доступом позволяет и перезапустить базу, и починить таблицы, и поправить конфиг напрямую по SSH — то есть решить проблему по-настоящему, а не ждать поддержку хостинга. Аккуратная работа с параметрами подключения, права в порядке и регулярные бэкапы вместе делают ошибку установления соединения с базой редким и быстро устранимым эпизодом.

Частые вопросы