Сообщение «Ошибка установления соединения с базой данных» означает, что WordPress не смог подключиться к базе. Причиной могут быть неверные параметры, недоступный сервер MySQL или ограничения хостинга. Оно само по себе не означает, что статьи и заказы удалены.
Начни с обстоятельств сбоя: сайт перестал работать после переноса, смены пароля или без видимых изменений? Это поможет выбрать первую проверку и не менять исправные настройки наугад.
Сначала зафиксируй симптомы
- Открой главную, одну внутреннюю страницу и /wp-admin/. Запиши, где появляется ошибка.
- Уточни время начала сбоя и последние изменения: перенос, обновление, новые доступы, нагрузка.
- Проверь сообщения о работах у хостинга и доступность панели управления.
- До редактирования сохрани текущий wp-config.php. Если база доступна через панель, сделай её экспорт.
Если публичная главная открывается, а админка нет, это ещё не доказывает исправность базы: посетителю могла отдаться кешированная страница. И наоборот, ошибка формы или отдельного плагина не всегда связана с общим подключением WordPress.
Проверь параметры подключения
В корне установки найди wp-config.php. Сравни DB_NAME, DB_USER, DB_PASSWORD и DB_HOST с данными выбранной базы в панели хостинга. Проверь полный логин и имя базы: провайдер может добавлять к ним префикс аккаунта. Не публикуй содержимое файла — в нём есть секреты.
DB_HOST — адрес сервера базы, иногда с портом или путём сокета. Не подставляй localhost только потому, что такое значение встречается в инструкции. На хостинге база может жить на отдельном сервере, а в Docker адресом часто служит имя сервиса. Используй значение для своего окружения.
В некоторых установках конфигурация читает переменные окружения. Тогда изменение текстовой строки в другом файле ничего не исправит: важно найти фактический источник параметров. Если такой конфигурацией занимался администратор, передай ему диагностику вместо раскрытия переменных в браузере.
Отдельно проверь, назначен ли пользователь нужной базе и разрешено ли ему подключение с сервера сайта. Вход в phpMyAdmin через панель не всегда проверяет те же учётные данные: панель может авторизовать тебя автоматически.
Выясни, доступен ли сервер базы
При отсутствии изменений в настройках посмотри состояние услуг хостинга, лимиты диска и ресурсов. Переполненный диск или достигнутый лимит подключений требуют другого решения, чем неверный пароль. Не перезапускай сервер многократно: сначала сохрани время ошибки и доступные сведения.
Если есть SSH и WP-CLI, из каталога установки можно выполнить проверку:
wp db checkКоманда использует конфигурацию WordPress и утилиту проверки MySQL. Она может завершиться ошибкой не только из-за сайта, но и из-за отсутствия нужной утилиты или прав. Сохрани точный текст ответа для администратора; это диагностическая проверка, а не команда восстановления.
Как читать сообщение об ошибке
- Access denied. Проверь учётные данные, права и разрешённый источник подключения. Самостоятельная смена пароля без обновления всех потребителей может нарушить другие подключения.
- Unknown database. Проверь имя базы, её существование и завершение импорта.
- Connection refused или timeout. Проверь адрес, порт, доступность службы и сетевые ограничения вместе с хостингом.
- Too many connections. Нужен разбор нагрузки и соединений; простая правка пароля не поможет.
Ошибку ищут в журнале PHP и журнале сервера базы. Обычный debug.log WordPress может не дать нужных сведений при проблеме на раннем этапе запуска. Не включай вывод технических сообщений посетителям. Публичный журнал с путями, запросами и данными формы тоже не должен оставаться доступным.
Если ошибка появилась после переноса
Проверь, что импорт выполнен именно в ту базу, которая указана в конфигурации нового сайта. На старом и новом хостингах одинаковые имена каталогов не означают одинаковое содержимое. Для проверки новой копии убедись, что браузер обращается к новому серверу.
Если WordPress подключается, но предлагает установку, проверь наличие таблиц и $table_prefix. Несовпадение префикса — другой сценарий: исправлять его подбором пароля бессмысленно. Не запускай установку и не очищай таблицы до выяснения причины.
Когда требуется восстановление
Не начинай с восстановления вчерашней копии: в текущей базе могут быть свежие заказы. Если журнал прямо сообщает о повреждении таблиц, сохрани доступную копию и обсуди восстановление с хостингом. Метод зависит от движка таблиц и характера повреждения; универсального безопасного «ремонта одной кнопкой» нет.
Встроенный режим ремонта WordPress не решает неверные доступы и отключённый MySQL. Не включай его профилактически. Если специалист временно использовал WP_ALLOW_REPAIR, эту настройку после работ нужно убрать: доступ к странице ремонта не требует обычной авторизации.
Что написать в поддержку хостинга
Сообщи домен, время начала ошибки и часовой пояс, что менялось перед сбоем, открывается ли панель и точный текст из журнала без паролей. Попроси проверить доступность MySQL, права пользователя, свободное место и лимит соединений. Такое обращение полезнее формулировки «WordPress сломался».
После исправления проверь не только открытие страницы, но и сохранение тестовой правки или работу формы. Удали тестовые данные и убедись, что ошибка не повторяется в журналах. Если вместо проблемы подключения появилась PHP-ошибка, перейди к разбору критической ошибки WordPress.
Если ошибка появилась после переезда, сверь шаги с инструкцией по переносу WordPress. Перед любыми правками базы сохрани копию по инструкцией по резервным копиям WordPress.
Документация
Настройки wp-config.php · Типичные ошибки WordPress · wp db check.