Error establishing a database connection в WordPress: причины и пошаговое исправление

Сообщение Error establishing a database connection означает, что WordPress не смог установить или сохранить необходимое соединение с MySQL либо MariaDB. Браузер не показывает точную причину: одинаковый экран появляется из-за неверного пароля, недоступного сервера, ошибочного DB_HOST, отсутствующих прав, исчерпанных лимитов или поврежденных таблиц.

Главный риск — действовать наугад. Замена файлов WordPress, переустановка плагинов или импорт старой базы редко являются правильным первым шагом. На сайте с формами или WooCommerce неконтролируемое восстановление способно удалить заявки и заказы, созданные после резервной копии.

Если сайт приносит продажи, а надежной копии и доступа к журналам нет, используйте техническую поддержку сайта. Для самостоятельной диагностики следуйте последовательности ниже и записывайте каждое изменение.

Как WordPress подключается к базе

Контент WordPress хранится не только в файлах. Страницы, записи, пользователи, настройки, товары, заказы и данные плагинов находятся в базе. WordPress читает четыре основных параметра из wp-config.php:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );

Затем PHP обращается к указанному серверу. MySQL проверяет пользователя, пароль, разрешенный источник и права, после чего принимает запросы к таблицам. Сбой на любом этапе может вызвать одно общее сообщение.

Не вставляйте реальные пароли в скриншоты, чаты или заявки. Если секрет уже опубликован, смените его и сразу обновите конфигурацию.

Диагностическая карта

HTTP-ответ проблемного URL можно проверить через инструменты BB STUDIO. Это помогает отличить сбой приложения от закешированной страницы, редиректа или ответа прокси.

Первые 15 минут

1. Откройте сайт в приватном окне и из другой сети.
2. Запишите точное время, URL и последнее известное изменение.
3. Проверьте главную, внутреннюю страницу, /wp-admin/ и статус хостинга.
4. Не очищайте все кеши и не импортируйте копию до сохранения текущего состояния.
5. Скачайте wp-config.php и экспорт базы, если панель доступна.
6. Проверьте другие сайты на том же сервере базы.
7. Откройте журналы MySQL/MariaDB, PHP и системы за нужное время.
8. Проверяйте одну гипотезу за раз.

Не путайте этот экран с общей ошибкой 500 в WordPress. Код 500 часто связан с PHP, плагином, темой или настройкой веб-сервера, а database connection error точнее указывает на этап доступа к данным.

Шаг 1. Определите масштаб

Не работает один сайт

Начните с его конфигурации, базы, пользователя и прав. Если другие проекты на том же хостинге работают, полное падение сервера менее вероятно.

Не работают все сайты

Если независимые установки одновременно потеряли базы, проверяйте службу MySQL/MariaDB, нагрузку, хранилище, сеть между веб-сервером и базой, а также работы провайдера.

Ошибка периодическая

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

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

Сопоставьте время с рекламными кампаниями, импортом товаров, резервным копированием, cron, рассылкой и бот-трафиком. Качественный хостинг для сайта должен давать не только ресурсы, но и метрики, логи и возможность восстановления.

Шаг 2. Проверьте wp-config.php

Сравнивайте файл с актуальными данными панели, а не со старым письмом или локальной копией.

DB_NAME

Название должно совпадать полностью. Shared hosting часто добавляет префикс аккаунта. После переноса новая база может получить другое имя при неизменном домене.

DB_USER

Пользователь базы не обязан совпадать с логином WordPress, FTP или панели. Убедитесь, что аккаунт существует и прикреплен к нужной базе.

DB_PASSWORD

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

DB_HOST

localhost подходит не всегда. Провайдер может требовать отдельный hostname, IP, порт или socket. Значение может выглядеть как db.example.host:3306. После миграции не копируйте старый host без проверки.

Синтаксис

Проверьте прямые кавычки, точки с запятой и случайные переносы. Используйте простой текстовый редактор. Перед изменением сохраните копию файла вне публичной директории.

Шаг 3. Проверьте реквизиты отдельно

При наличии SSH используйте стандартный клиент MySQL с теми же host, user и database. Не помещайте пароль прямо в команду, если он сохранится в истории shell. На управляемом хостинге применяйте штатный инструмент или попросите провайдера проверить соединение с веб-узла.

Ответ сокращает область поиска:

• Access denied for user — неверный пароль, аккаунт, разрешенный host или права;
• Unknown database — ошибочное имя или удаленная база;
• Can't connect to MySQL server — неверный host/port, остановленная служба или сетевой блок;
• Connection refused — на endpoint нет принимающей службы;
• timeout — сеть, firewall, перегрузка или зависший сервер.

Если отдельное соединение работает, а WordPress — нет, сравните среду PHP, фактически загружаемый конфигурационный файл, db.php drop-in и переменные окружения.

Шаг 4. Проверьте пользователя и права

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

На shared hosting:

1. проверьте связь «пользователь → база» в панели;
2. повторно назначьте необходимые права штатным интерфейсом;
3. избегайте глобального доступа ко всем базам;
4. проверьте чтение и запись через WordPress;
5. запишите точное изменение.

Не вставляйте случайные команды GRANT ALL на production. Избыточные права увеличивают последствия компрометации, а неверное совпадение host все равно заблокирует подключение.

Шаг 5. Проверьте MySQL/MariaDB и ресурсы

Если конфигурация верна, изучите инфраструктуру:

• запущена ли служба;
• слушает ли нужный порт или socket;
• есть ли свободное место и inodes;
• не исчерпан ли лимит одновременных соединений;
• достаточно ли памяти;
• не перезапускается ли служба циклически;
• доступен ли endpoint с веб-сервера;
• разрешает ли firewall маршрут;
• не превышена ли квота аккаунта.

Для периодического сбоя сопоставьте CPU, RAM, disk I/O и connections с точным временем. Средние показатели за сутки могут скрыть короткий пик, который ломает checkout.

Шаг 6. Проверьте таблицы и обновление базы

Если WordPress соединяется с сервером, но сообщает о недоступных или поврежденных таблицах, не запускайте repair сразу для всего. Сначала создайте текущий dump и изучите журналы.

WordPress поддерживает режим ремонта:

define( 'WP_ALLOW_REPAIR', true );

Он открывает /wp-admin/maint/repair.php. Страница может работать без авторизации, поэтому удалите константу сразу после завершения. Repair не возвращает удаленные записи, не заменяет резервную копию и не исправляет аппаратный сбой.

До операции определите:

• какие таблицы затронуты;
• какой engine используется;
• есть ли свежая рабочая копия;
• достаточно ли свободного места;
• продолжается ли запись заказов;
• действуют ли ограничения провайдера или репликация.

Для сложной базы проверяйте восстановление на копии или staging. Неудачная операция на единственной production-базе может осложнить дальнейшее восстановление.

Шаг 7. Проверьте миграцию и переменные окружения

После переноса ошибка часто возникает из-за неполной карты зависимостей. Убедитесь, что:

• база импортирована на нужный сервер;
• пользователь создан и получил права;
• DB_HOST или порт не изменились;
• секреты в .env или панели актуальны;
• загружается ожидаемый wp-config.php;
• не перенесен старый хостинг-специфичный wp-content/db.php;
• object cache не ссылается на отключенный сервис;
• новый веб-узел видит приватный endpoint базы.

Профессиональная разработка сайта должна включать документацию среды, контролируемую миграцию и проверенный rollback, а не только копирование файлов.

Особый сценарий WooCommerce

База магазина меняется постоянно. Заказы, оплаты, остатки, корзины, сессии и webhooks записываются каждую минуту. Откат всей базы ко вчерашней копии может вернуть витрину, но удалить новые продажи.

Перед восстановлением:

1. включите контролируемое обслуживание, если возможно;
2. сохраните текущую базу, даже если она частично повреждена;
3. изучите журнал платежного шлюза и эквайринг;
4. выпишите транзакции после выбранной копии;
5. решите, безопаснее ли точечное восстановление таблиц;
6. после запуска сверьте оплаты, заказы, остатки и письма.

Не просите клиента платить повторно до проверки транзакции. Отсутствующий order в WordPress не доказывает, что списания не было.

Когда возможен инцидент безопасности

Необъяснимая смена пароля, неизвестный пользователь базы, модифицированный wp-config.php, посторонний db.php, новые cron-задачи или резкий рост запросов могут указывать на компрометацию.

В этом случае:

• сохраните логи и текущую копию;
• смените доступы к хостингу, SSH/SFTP, базе и WordPress;
• проверьте администраторов и ключи;
• просканируйте файлы и сравните ядро;
• изучите plugins, mu-plugins, cron и drop-ins;
• обновите salts;
• найдите и закройте первоначальный вектор атаки.

Возврат старого пароля не удаляет причину и механизм повторного доступа.

Влияние на SEO и рекламу

Короткий единичный сбой обычно не разрушает позиции, но длительная или регулярная недоступность мешает сканированию, блокирует покупки и тратит рекламный бюджет. Не отдавайте database error со статусом 200 OK. Для временной недоступности уместнее контролируемый 503 Service Unavailable, хотя реализация зависит от инфраструктуры.

После восстановления проверьте важные URL, sitemap, robots, canonical, формы и checkout. При длительном инциденте изучите Search Console и логи. Системное SEO-продвижение включает техническую доступность, а не только ключевые слова.

Как подтвердить полное восстановление

Не останавливайтесь после открытия главной. Проверьте:

• вход и сохранение в админке;
• создание и редактирование записи;
• отправку формы и доставку сообщения;
• поиск, фильтры и кабинет;
• корзину, checkout и тестовую оплату;
• cron и webhooks;
• новые записи MySQL/PHP logs;
• нагрузку и активные соединения;
• свежую копию после восстановления.

Запишите первопричину точно: «пароль изменили без обновления конфигурации», «connections исчерпаны при импорте», «после миграции остался старый host». «Перезапустили сервер» описывает действие, а не причину.

Профилактика

1. Управляйте конфигурацией и секретами контролируемо.
2. Автоматически копируйте файлы и базу в отдельное хранилище.
3. Тестируйте восстановление, а не только наличие архивов.
4. Мониторьте HTTP-статус, MySQL connections, диск, CPU и RAM.
5. Настройте оповещения о нехватке места и недоступности базы.
6. Используйте staging и план rollback для обновлений и миграций.
7. Документируйте DB host, порт, ответственного и контакт провайдера.
8. Ограничивайте пользователя необходимой базой.
9. Не храните production-пароли в публичных репозиториях.
10. После инцидента устраняйте причину, а не только симптом.

Стоимость плановых и срочных работ указана на странице цен BB STUDIO, а примеры проектов — в портфолио.

Итоговый чек-лист

• записаны время, URL и последнее изменение;
• определено, постоянный сбой или периодический;
• сохранены текущие файлы и база;
• проверены DB_NAME, DB_USER, DB_PASSWORD, DB_HOST;
• реквизиты протестированы отдельно;
• пользователь привязан к правильной базе;
• проверены MySQL, порт, socket, диск и connections;
• repair запускается только после копии;
• WP_ALLOW_REPAIR удален после использования;
• для WooCommerce сверены платежи и новые заказы;
• протестированы запись, формы, cron и checkout;
• создана новая контрольная копия;
• первопричина задокументирована.

Если ошибка возвращается или безопасной копии нет, свяжитесь с BB STUDIO для контролируемой диагностики и восстановления.

Вывод

Error establishing a database connection — не полный диагноз, а признак разрыва в цепочке «WordPress → сеть → MySQL → база». Кратчайший путь к причине: определить масштаб, сохранить текущее состояние, проверить четыре параметра wp-config.php, отдельно протестировать реквизиты, изучить права и состояние службы, а затем ремонтировать таблицы или восстанавливать данные.

Последовательность важнее количества попыток. Одно подтвержденное изменение с точкой отката безопаснее десяти догадок на production.

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

Что означает Error establishing a database connection?

WordPress не смог подключиться к MySQL/MariaDB или потерял соединение. Причиной могут быть неверные реквизиты, недоступный сервер, права, лимиты или поврежденные таблицы.

Можно ли исправить ошибку без доступа к админке?

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

Поможет ли восстановление резервной копии?

Только если причина связана с данными или таблицами. Неверный пароль, DB_HOST или недоступный MySQL импорт не исправит. Полный откат магазина также способен удалить новые заказы.

Безопасно ли использовать WP_ALLOW_REPAIR?

Используйте режим после резервной копии и при подозрении на повреждение таблиц. Страница может быть доступна без входа, поэтому сразу удалите константу после завершения.

Почему ошибка возникает только иногда?

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