Если вместо сайта WordPress показывает сообщение «Ошибка установки соединения с базой данных» (Error establishing a database connection), это ещё не означает, что сломалась база. WordPress мог получить неверные параметры подключения, сервер MySQL или MariaDB может быть недоступен, а у пользователя базы — не хватать прав. Проверяйте эти причины по порядку: так проще найти сбой и не менять настройки вслепую.
Сначала выясните, когда и у кого появилась ошибка
Откройте главную страницу и /wp-admin/. Если сообщение одинаковое, проблема, скорее всего, затрагивает подключение WordPress к базе. Запишите время появления ошибки и вспомните, что менялось незадолго до неё: перенос сайта, смена пароля пользователя базы, восстановление резервной копии, изменение wp-config.php или работ на хостинге.
Если сайт перестал открываться у всех, а ошибка возникла без изменений в WordPress, сначала проверьте панель хостинга: статус сервера баз данных, уведомления о технических работах, ограничения аккаунта и свободное место. При сбое сервера базы правка конфигурации сайта не поможет. Если ошибка появляется время от времени, сообщите хостингу время и частоту сбоев: причиной могут быть перезапуски сервиса или ограничение числа подключений.
Проверьте подключение и состояние базы на хостинге
В панели хостинга найдите раздел баз данных. Убедитесь, что нужная база существует, а назначенный для неё пользователь не удалён и не заблокирован. Если панель позволяет открыть базу через phpMyAdmin, проверьте, что она доступна. Но вход в phpMyAdmin сам по себе не доказывает, что WordPress использует правильные имя пользователя и пароль: панель может подключаться под другой учётной записью.
Если в панели есть журнал ошибок базы данных или состояние служб, проверьте их. При наличии доступа по SSH можно проверить соединение средствами WP-CLI. Выполните команду из каталога WordPress, где находится wp-config.php:
wp db checkWP-CLI использует параметры сайта. Если команда не может подключиться, сообщение поможет отделить проблему соединения от проверки таблиц. Команда доступна только если на хостинге установлен WP-CLI; отсутствие команды не означает, что база неисправна. Не публикуйте вывод, если в нём оказались внутренние адреса или другие данные сайта.
Сверьте параметры в wp-config.php
В корневом каталоге WordPress найдите wp-config.php. Перед изменением сохраните его резервную копию в безопасном месте: в этом файле находятся секретные данные. Откройте его через файловый менеджер хостинга или SFTP и найдите существующие определения:
define( 'DB_NAME', 'имя_базы' );
define( 'DB_USER', 'пользователь_базы' );
define( 'DB_PASSWORD', 'пароль_пользователя' );
define( 'DB_HOST', 'адрес_сервера_базы' );Сравните значения с данными именно этой базы в панели хостинга. Регистр символов и префиксы важны: на некоторых хостингах к имени базы и пользователя автоматически добавляется префикс аккаунта. Если недавно меняли пароль пользователя базы, новый пароль нужно указать и в панели, и в wp-config.php. Изменение только в одном месте нарушит подключение.
Не заменяйте DB_HOST на localhost наугад. На одном хостинге это правильный адрес, на другом нужен отдельный hostname, порт или другой вариант, указанный провайдером. При переезде сайта проверьте адрес базы в настройках нового хостинга: прежний адрес может быть недоступен с нового сервера.
Меняйте только неверные значения, не добавляйте второй набор тех же констант ниже по файлу. Пароль может содержать символы, которые нужно корректно экранировать в PHP-строке; не вставляйте в неё кавычку или обратную косую черту без учёта синтаксиса. Если не уверены, скопируйте значение из панели и попросите поддержку хостинга помочь обновить его. Не отправляйте пароль в открытом виде на форумах и в обращениях без защищённого канала.
DB_CHARSET и DB_COLLATE обычно не являются причиной сообщения об ошибке подключения. Не меняйте кодировку базы в попытке исправить доступ: это не исправит неверный пароль или недоступный сервер и может привести к проблемам с данными.
Убедитесь, что пользователь имеет права на базу
Даже при правильных имени базы и пароле подключение не заработает, если пользователь не назначен этой базе или ему не выданы необходимые привилегии. В панели хостинга проверьте связь пользователя с базой и предоставленные ему права. Для обычной работы WordPress пользователю нужны права на операции с таблицами; конкретный способ назначения прав зависит от панели и конфигурации хостинга.
Если вы сбрасываете пароль, не создавайте нового пользователя и не удаляйте старого, пока не выясните, какой аккаунт использует сайт. Безопаснее обновить пароль существующего пользователя, затем указать его в wp-config.php и проверить сайт. Если база или пользователь не отображаются в панели либо права назначить нельзя, обратитесь в поддержку хостинга, указав имя базы и пользователя, но не пароль.
Если параметры верны, ищите сбой сервера или ограничения
При корректных настройках проверьте, что сервер MySQL или MariaDB запущен и принимает соединения с веб-сервера. Это особенно важно на VPS и выделенном сервере: сервис мог остановиться, сменился адрес или порт, закончились доступные ресурсы. На обычном виртуальном хостинге состояние службы и её журналы обычно проверяет провайдер.
Проверьте также свободное место и сообщения о превышении лимитов аккаунта. При заполненном диске база может перестать нормально работать. Если ошибка появляется только при высокой нагрузке, возможны временная недоступность базы или достижение лимита соединений. Не увеличивайте лимиты и не перезапускайте службы без понимания настроек сервера: на управляемом хостинге эти действия должен выполнять провайдер.
Если проблема началась после переноса, проверьте не только четыре значения в конфигурации, но и то, импортирована ли база на новый сервер. Если после смены адреса сайта WordPress продолжает ссылаться на старый сервер базы, запросите у хостинга актуальные параметры подключения. Настройки базы сайта и адрес сайта в WordPress — разные вещи: изменение адреса сайта не исправляет доступ к MySQL.
Как убедиться, что ошибка устранена
После сохранения конфигурации обновите главную страницу и войдите в /wp-admin/. Проверьте несколько страниц и действие, которое обращается к базе, например открытие записи. Если сайт заработал, убедитесь, что в журнале ошибок не появляются новые сообщения о сбоях подключения. Не включайте вывод ошибок посетителям ради проверки: диагностические сообщения могут раскрыть пути и внутренние данные. Если нужно посмотреть журналы, используйте средства хостинга или настройку логирования, не показывающую ошибки публично.
Если ошибка осталась, не меняйте параметры методом перебора. Передайте поддержке хостинга время сбоя, название базы, hostname из DB_HOST и результат проверки WP-CLI, если она доступна. Не передавайте пароль. Провайдер сможет проверить журналы и подтвердить, принимает ли сервер подключение от вашего сайта.
Когда проблема не в подключении
Сообщение WordPress о подключении — общий признак, но не всякая неисправность сайта связана с паролем или wp-config.php. Если база доступна и WP-CLI подключается, но сайт выдаёт другую ошибку, проверьте журналы PHP и сервера, а также недавние изменения плагинов или темы. Ошибка PHP может возникнуть раньше, чем WordPress вообще попытается подключиться к базе.
Если соединение устанавливается, но появляются сообщения о повреждённых таблицах или сбой возникает при чтении конкретных данных, это отдельная проблема. Перед восстановлением или ремонтом таблиц сделайте резервную копию базы. Не запускайте ремонтные операции на рабочем сайте без копии и не включайте режим восстановления WordPress без необходимости: такая диагностика не исправляет неверные реквизиты и недоступность сервера.
При исправлении ошибки подключения обычно достаточно восстановить правильные параметры, права пользователя или доступность сервера. Если после проверки этих пунктов причина неясна, дальнейшие изменения в конфигурации лучше остановить и запросить у хостинга журналы и подтверждение состояния MySQL или MariaDB.