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

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

Ниже — порядок диагностики, который отсеивает варианты по одному и почти всегда даёт ответ за четверть часа. Отдельно покажу, как за минуту понять, ваш это сайт сломался или лежит сервер хостинга, — от этого зависит, чинить самому или писать в поддержку. В SEO с 2005 года, и такие аварии на клиентских проектах приходится разбирать регулярно.

Что означает сообщение и когда оно врёт

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

Сообщение появляется, когда PHP не смог выполнить подключение к серверу базы данных или не смог выбрать саму базу. Это два разных сбоя, и WordPress их не различает в тексте, хотя причины у них разные. Первый случай — сервер не ответил, отказал в доступе или отверг логин. Второй — сервер ответил, но базы с указанным именем на нём нет либо у пользователя нет к ней прав.

Отдельно стоит вариант, когда вместо белой страницы вы видите ту же ошибку, но с приставкой о том, что база повреждена и WordPress предлагает её починить. Это уже третий сценарий: соединение установлено, но одна или несколько таблиц не читаются.

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

Проверяем доступы в wp-config.php

Первый и самый частый источник проблемы — четыре константы в файле wp-config.php. Файл лежит в корне сайта, открывается любым текстовым редактором через FTP или файловый менеджер панели.

define( 'DB_NAME', 'имя_базы' );
define( 'DB_USER', 'пользователь' );
define( 'DB_PASSWORD', 'пароль' );
define( 'DB_HOST', 'localhost' );

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

Отдельного внимания заслуживает DB_HOST. На большинстве обычных хостингов там действительно localhost, но далеко не всегда. Часть панелей выносит базы на отдельный сервер, и тогда в поле должен стоять его адрес или имя вида mysql.имя-аккаунта. Ещё вариант — нестандартный порт, который указывается через двоеточие. Правильное значение всегда написано в панели, в разделе баз данных.

Проверить связку логин-пароль-база быстрее всего через phpMyAdmin: если вы входите туда теми же учётными данными и видите нужную базу с таблицами, доступы верны и причина в другом. Если phpMyAdmin отказывает во входе — вы нашли проблему за две минуты.

Второй нюанс — сам файл. Пароли часто содержат кавычки, обратные слеши, знаки доллара. Если пароль вставили в одинарные кавычки без экранирования, PHP прочитает его неправильно. Признак: доступы вроде верные, а соединения нет. Решение простое — смените пароль пользователя базы на строку из букв и цифр без спецсимволов и пропишите новый в конфиг.

Сервер базы данных упал или перегружен

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

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

Отдельная и очень распространённая история — не падение, а перегрузка. На виртуальном хостинге ресурсы делятся между сотнями аккаунтов, и служба базы данных может отвечать с задержкой в несколько секунд или отклонять новые подключения. Тогда ошибка появляется не постоянно, а вспышками: сайт то работает, то нет, и обновление страницы иногда помогает. Это самый неприятный вариант, потому что в момент вашей проверки всё обычно уже работает.

Косвенный признак перегрузки — медленный ответ сервера в обычное время. Если время до первого байта скачет от 200 миллисекунд до трёх секунд, база почти наверняка задыхается. Про эту диагностику подробно писал в материале «Хостинг быстрый, а сайт тормозит: куда исчезает секунда до первого байта».

Лимит подключений и его последствия

У каждого сервера базы данных есть предельное число одновременных подключений. На виртуальном хостинге лимит бывает жёстким и низким — например, 30 на аккаунт. Каждый посетитель, каждый запрос робота, каждая фоновая задача занимают подключение на время выполнения запроса.

Пока запросы быстрые, лимит не выбирается никогда: подключение живёт миллисекунды. Как только появляется медленный запрос — тяжёлый фильтр каталога, поиск по всему содержимому, неоптимизированная выборка в плагине — подключения начинают накапливаться. Тридцать одновременных посетителей на медленном запросе выбирают лимит, и тридцать первый получает ошибку соединения.

Симптом	Вероятная причина	Проверка	Что делать
Ошибка постоянная, не проходит сама	Неверные доступы, отсутствующая база, упавшая служба	Вход в phpMyAdmin теми же данными	Сверить константы в wp-config.php или обратиться в поддержку
Ошибка появляется вспышками, обновление помогает	Исчерпание лимита подключений или перегрузка сервера	Совпадение с пиками посещаемости в статистике	Найти медленные запросы, включить кэш, поднять тариф
Ошибка только в админке, фронт работает	Страницы отдаются из кэша, база уже недоступна	Открыть сайт в режиме инкогнито с параметром в адресе	Диагностировать как постоянную ошибку
Ошибка с предложением починить базу	Повреждены таблицы	Проверка таблиц в phpMyAdmin	Запустить встроенную починку или восстановить из копии
Ошибка появилась после роста сайта или наплыва трафика	Упёрлись в лимиты тарифа	Графики нагрузки в панели хостинга	Оптимизировать запросы, затем менять тариф
Ошибка совпала с обновлением плагина	Плагин создаёт таблицы или шлёт тяжёлые запросы	Откат плагина на предыдущую версию	Отключить, найти замену, написать разработчику

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

Практические шаги по снижению нагрузки на базу выглядят так. Включить кэширование страниц — тогда большинство посетителей вообще не дойдёт до базы. Отключить или заменить плагины, которые пишут в базу на каждом просмотре: счётчики просмотров, сборщики статистики, журналы посещений. Почистить служебные таблицы: ревизии записей, устаревшие временные значения, логи ошибок плагинов. И ограничить частоту фоновых задач: планировщик WordPress запускается при обращении к сайту, и на посещаемом ресурсе он способен сам себя загрузить. Как хостинг вообще влияет на видимость сайта, разбирал в статье «Влияет ли хостинг на продвижение сайта».

Повреждённые таблицы и встроенная починка

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

В WordPress встроен режим починки. Включается он константой, которую надо добавить в wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

После этого откройте адрес /wp-admin/maint/repair.php. Страница доступна без авторизации — именно поэтому константу обязательно нужно убрать сразу после ремонта. На странице две кнопки: проверка и починка таблиц, а также вариант с оптимизацией. Начинайте с первой: она безопаснее и в большинстве случаев достаточна.

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

Когда таблица не восстанавливается, остаётся резервная копия. И здесь выясняется главное: копия либо есть, либо нет. Хостинги часто хранят автоматические копии за последние несколько дней, но полагаться только на них рискованно — глубина хранения бывает суточной, а восстановление недоступно на дешёвых тарифах. Своя копия базы, которая делается расписанием и складывается за пределы сервера, стоит копейки и решает эту категорию проблем целиком. Про то, как устроены индексы и почему таблицы вообще важны для скорости выборки, писал в заметке «Индексация базы данных».

Кончившееся место на диске

Забитый диск — причина, которую почти никто не проверяет первой, а она даёт ровно ту же ошибку. Механизм такой: службе базы данных нужно место для временных файлов и журналов. Когда свободного места нет, она не может выполнить даже простой запрос и отклоняет подключения.

Проверяется мгновенно: в панели хостинга есть индикатор занятого места. Если он показывает сто процентов — причина найдена.

Дальше вопрос, что именно заняло диск. Типовые пожиратели в порядке частоты: журнал отладки debug.log, который забыли выключить и который растёт до гигабайтов; резервные копии, которые плагин складывает в папку загрузок на том же сервере; кэш плагина кэширования, разросшийся из-за адресов с параметрами; изображения, загруженные в оригинальном размере вместе с десятком копий каждой; журналы почтового сервера и старые логи веб-сервера.

Чистить надо аккуратно: удаление файла из папки загрузок ломает ссылку в записи, а удаление кэша безопасно всегда. Сначала уберите заведомо мусорное — логи и старые бэкапы, — потом разбирайтесь с медиафайлами. Хорошая привычка — следить за местом заранее, а не в момент аварии; общие принципы такого контроля собраны в материале «Контроль работы хостинга».

Как отличить проблему сайта от проблемы сервера

Это ключевая развилка. Если проблема на стороне сервера, вы потратите час впустую, копаясь в конфиге. Если проблема на стороне сайта, поддержка ответит «у нас всё работает» и будет права.

Проверка	Результат «проблема на сервере»	Результат «проблема на сайте»
Вход в phpMyAdmin из панели хостинга	Не подключается, ошибка соединения	Входит, база и таблицы на месте
Другой сайт на том же аккаунте	Тоже отдаёт ошибку базы	Работает нормально
Статический файл: robots.txt или картинка из загрузок	Не открывается или отдаёт ошибку сервера	Открывается мгновенно
Индикатор свободного места в панели	Ноль свободного места	Место есть
Время появления ошибки	Ночью, без ваших действий, у нескольких сайтов сразу	Сразу после обновления, переноса или правки файлов
Простой тестовый скрипт подключения к базе	Отказ на этапе соединения с сервером	Соединение есть, отказ на выборе базы

Тестовый скрипт из последней строки — самый честный способ. Создайте в корне файл с любым именем и одной проверкой подключения средствами PHP, подставив данные из конфига. Скрипт отделит проблему доступа от проблемы самого сервера и покажет текст ошибки, который WordPress прячет. После проверки файл обязательно удалите: он содержит пароль от базы открытым текстом.

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

Что спрашивать у хостинга

Обращение в поддержку в формате «у меня не работает сайт» гарантирует ответ через несколько часов и просьбу уточнить. Формулировка, которая ускоряет разбор, содержит четыре вещи: адрес сайта, точный текст ошибки, время её появления и перечень уже сделанных проверок.

Конкретные вопросы, которые имеет смысл задать: работает ли служба базы данных на сервере в данный момент; не превышен ли лимит одновременных подключений и какое у него значение на моём тарифе; есть ли свободное место на диске и в квоте базы; не было ли на сервере аварий или плановых работ в указанное время; не блокировала ли система защиты мои запросы к базе.

Отдельно попросите текст ошибки из журнала сервера. Поддержка видит его в своих логах, и там обычно стоит точный код — отказ доступа, превышение подключений, неизвестная база. Это на порядок информативнее того, что показывает WordPress.

Если хостинг регулярно отвечает «всё в порядке», а сайт продолжает падать вспышками, это уже вопрос выбора площадки. Простой сайта прямо влияет на позиции: робот получает код 500, снижает скорость обхода, часть страниц выпадает из индекса. Что происходит, когда сервер перестаёт отвечать надолго, показывал на примере в заметке «Заказчик просрочил оплату хостинга и позиции сайта рухнули». Если после восстановления база работает, но сайт остался медленным и с ошибками в вёрстке, это уже отдельная задача на доработку сайта.

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

Можно ли потерять данные при встроенной починке? Риск есть, хотя и небольшой: восстановление таблицы иногда отбрасывает повреждённые строки. Перед запуском сделайте копию базы через экспорт в phpMyAdmin — это займёт минуту.

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

Помогает ли смена префикса таблиц? К этой ошибке отношения не имеет. Префикс задаётся переменной в конфиге и должен совпадать с тем, что в базе; если он не совпадает, WordPress предложит установку заново, а не ошибку соединения.

Что делать, если ошибка появилась сразу после переноса сайта? Проверять доступы и хост. При переносе меняются имя базы, пользователь и пароль, а иногда и адрес сервера базы. Это причина номер один после переезда.

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

Спасает ли кэширование от этой ошибки? Частично. Полностраничный кэш отдаёт посетителям сохранённые копии и снимает нагрузку с базы, но админка, корзина и формы всё равно ходят в базу напрямую. Кэш уменьшает вероятность аварии, а не устраняет её.

Коротко

• Ошибка соединения с базой имеет пять типовых причин: неверные доступы, упавшая служба, лимит подключений, повреждённые таблицы, кончившееся место на диске.
• Первым делом сверьте четыре константы в wp-config.php с реальными данными в панели хостинга, особое внимание — значению DB_HOST.
• Вход в phpMyAdmin теми же учётными данными за две минуты отделяет проблему сайта от проблемы сервера.
• Ошибка вспышками, которая проходит сама, — это почти всегда лимит подключений; лечится оптимизацией запросов и кэшем, а не повышением лимита.
• Повреждённые таблицы чинятся константой WP_ALLOW_REPAIR, но её обязательно убирают сразу после ремонта — страница доступна без авторизации.
• Долгий простой означает для робота серию ответов 500: падает скорость обхода и часть страниц выпадает из индекса, поэтому мониторинг доступности нужен даже маленькому сайту.

Если база восстановлена, но после простоя просели позиции и непонятно, что делать дальше, — приходите на SEO-консультацию по проекту, посмотрим статистику обхода и составим план возврата.