Ошибка установления соединения с базой данных в WordPress: Полное руководство

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

Хорошая новость: в 95% случаев эта ошибка не означает потерю данных. Это просто разрыв связи между движком сайта и базой. В этом руководстве мы системно разберем все причины и способы их устранения — от проверки паролей до диагностики сервера.

Почему возникает эта ошибка?

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

  • Неправильные учетные данные в wp-config.php (после миграции или смены хостинга)
  • Служба MySQL/MariaDB упала или не запускается
  • База данных повреждена и требует восстановления
  • Превышены лимиты подключений к базе данных
  • Сервер перегружен (закончилась оперативная память, и MySQL был «убит» системой)

Шаг 1: Проверка учетных данных в wp-config.php

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

Найдите следующие строки и внимательно проверьте их:

// ** Параметры MySQL ** //
/** Имя базы данных для WordPress */
define( 'DB_NAME', 'custom_code_db' );

/** Имя пользователя MySQL */
define( 'DB_USER', 'custom_code_user' );

/** Пароль к базе данных MySQL */
define( 'DB_PASSWORD', 'your_strong_password' );

/** Имя сервера MySQL */
define( 'DB_HOST', 'localhost' );

Что проверить:

  • Нет ли опечаток в имени пользователя или пароле (часто пароль случайно меняется при копировании)
  • Существует ли сама база данных с именем DB_NAME в панели управления хостинга (phpMyAdmin)
  • Действителен ли пользователь DB_USER и есть ли у него права доступа к этой базе

Шаг 2: Проверка работы службы MySQL/MariaDB

Если вы управляете сервером самостоятельно (VPS/VDS), возможно, служба баз данных просто остановилась. Подключитесь по SSH и проверьте статус:

# Для Ubuntu/Debian
sudo systemctl status mysql
# или
sudo systemctl status mariadb

Если статус inactive (dead) или failed, попробуйте перезапустить службу:

sudo systemctl restart mysql

Если служба не запускается, смотрите логи, чтобы понять причину сбоя:

sudo tail -n 50 /var/log/mysql/error.log
# или
sudo journalctl -u mysql.service -n 50 --no-pager

Шаг 3: Восстановление поврежденной базы данных

Иногда база данных повреждается из-за некорректного завершения работы сервера или сбоя плагина. WordPress имеет встроенный инструмент для ее восстановления.

Откройте wp-config.php и добавьте в конец файла (перед строкой «That’s all, stop editing!»):

// Включаем режим восстановления БД
define( 'WP_ALLOW_REPAIR', true );

Сохраните файл и перейдите в браузере по адресу:

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

Вы увидите экран с двумя кнопками. Нажмите «Исправить базу данных». WordPress проверит таблицы и попытается восстановить поврежденные.

Важно: после завершения восстановления обязательно удалите строку define( 'WP_ALLOW_REPAIR', true ); из файла конфигурации, иначе любой посетитель сможет запускать восстановление!

Шаг 4: Проверка прав доступа пользователя к базе

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

mysql -u root -p

Выполните SQL-запросы для проверки и выдачи прав:

-- Проверяем, существует ли пользователь
SELECT user, host FROM mysql.user WHERE user = 'custom_code_user';

-- Выдаем все права пользователю на базу
GRANT ALL PRIVILEGES ON custom_code_db.* TO 'custom_code_user'@'localhost';

-- Применяем изменения
FLUSH PRIVILEGES;
EXIT;

Обновите сайт в браузере. Если ошибка исчезла — проблема была в правах.

Шаг 5: Смена localhost на 127.0.0.1

На некоторых хостингах и конфигурациях серверов использование слова localhost заставляет PHP пытаться подключиться к MySQL через Unix-сокет, что может не работать. Замена на IP-адрес принудительно использует TCP-соединение.

// В wp-config.php измените:
define( 'DB_HOST', '127.0.0.1' );

Это простое изменение часто решает проблему на специфичных конфигурациях Nginx и LiteSpeed.

Шаг 6: Проверка ресурсов сервера (OOM Killer)

Если ошибка появляется периодически (особенно ночью или при высокой нагрузке), скорее всего, на сервере заканчивается оперативная память, и Linux принудительно останавливает процесс MySQL, чтобы спасти систему.

Проверьте системные логи на наличие убийств процессов:

dmesg | grep -i "killed process"
# или
grep -i "out of memory" /var/log/syslog

Если вы видите, что MySQL был убит из-за нехватки памяти, вам нужно либо увеличить RAM на сервере, либо оптимизировать потребление памяти. Подробно эта проблема разбирается в нашем руководстве по устранению ошибки Docker Code 137 (принцип OOM Killer одинаков для хоста и контейнеров) и в статье про увеличение memory_limit в PHP.

Что делать, если проблема не решается?

Ошибка появляется только при высокой нагрузке

Если сайт падает в моменты пикового трафика, база данных не справляется с количеством одновременных подключений. Настройте кэширование, чтобы снизить нагрузку. Мы подробно описывали ускорение сайта с помощью Redis Object Cache и кэширования Nginx в соответствующих статьях. Это снизит количество прямых запросов к MySQL в десятки раз.

Сайт работает, но в админке ошибка

Если фронтенд открывается, а /wp-admin/ выдает ошибку подключения, проблема может быть в плагине безопасности, который блокирует доступ к БД для определенных IP, или в конфликте плагинов кэширования. Попробуйте временно отключить все плагины через FTP (переименовав папку plugins), как описано в руководстве по белому экрану смерти.

Хостинг ограничивает количество подключений

На дешевых Shared-хостингах часто стоит лимит на количество одновременных подключений к БД (например, 25-30). Если ваш сайт использует тяжелый конструктор (Elementor) или много плагинов, этот лимит быстро исчерпывается. В этом случае помогает либо переход на VPS, либо оптимизация стека сайта.

Краткий чек-лист диагностики

  • Проверить логи MySQL/MariaDB на предмет причин падения
  • Убедиться, что служба БД запущена (systemctl status mysql)
  • Перепроверить логин, пароль и имя БД в wp-config.php
  • Попробовать сменить localhost на 127.0.0.1
  • Запустить встроенное восстановление БД (WP_ALLOW_REPAIR)
  • Проверить системные логи на утечки памяти и OOM Killer