Помилка «Error establishing a database connection» означає, що WordPress не зміг підключитися до бази даних MySQL або MariaDB, тому не може зібрати жодної сторінки: усі тексти, налаштування й облікові записи зберігаються саме там. Найчастіше винні неправильні дані доступу у wp-config.php (після переносу сайту чи зміни пароля), зупинений або перевантажений сервер баз даних і вичерпані ліміти хостингу. Почніть із двох дій: відкрийте /wp-admin/, де WordPress показує детальніше повідомлення, і звірте константи DB_NAME, DB_USER, DB_PASSWORD і DB_HOST з даними бази в панелі хостингу.
Що означає помилка і як WordPress її показує
Під час кожного запиту WordPress спершу з’єднується із сервером баз даних, а потім обирає потрібну базу. Якщо будь-який з цих етапів не вдається, виконання зупиняється: тема, плагіни й кеш навіть не завантажуються. Публічна частина сайту показує лише короткий заголовок, а сервер віддає код 500, щоб пошукові системи не зберегли сторінку з помилкою.
Важливий нюанс: на фронтенді однаковий текст з’являється за різних причин. Детальніші повідомлення WordPress виводить в адмінці, тому відкрийте https://example.com/wp-admin/ і порівняйте текст з таблицею.
| Що бачите | Де | Що це означає | Що робити |
|---|---|---|---|
| Error establishing a database connection | Будь-яка сторінка сайту | Підключення або вибір бази не вдалися, причина не уточнюється | Відкрити /wp-admin/ або тимчасово ввімкнути WP_DEBUG |
| Той самий заголовок і текст «This either means that the username and password information in your wp-config.php file is incorrect…» | /wp-admin/ | Сервер відхилив логін чи пароль або не відповідає за адресою DB_HOST | Перевірити DB_USER, DB_PASSWORD, DB_HOST і роботу MySQL |
| Cannot select database | /wp-admin/ | Логін і пароль правильні, але бази з такою назвою немає або користувач не має до неї прав | Перевірити DB_NAME, префікс назви і права користувача |
| One or more database tables are unavailable. The database may need to be repaired. | /wp-admin/ | З’єднання є, але частини таблиць немає або вони пошкоджені | Відновити таблиці або повернути бекап |
| Could not find site … Searched for table … | Мультисайт | База доступна, але домен не знайдено в таблицях мережі | Перевірити DOMAIN_CURRENT_SITE і таблиці wp_site, wp_blogs |
| Сторінка встановлення WordPress | Будь-яка сторінка | База порожня або $table_prefix не збігається з префіксом таблиць | Виправити $table_prefix, не встановлювати WordPress повторно |
Якщо і в адмінці лише короткий заголовок, тимчасово ввімкніть налагодження у wp-config.php: define( ‘WP_DEBUG’, true ); і define( ‘WP_DEBUG_DISPLAY’, true );. Тоді над повідомленням з’явиться точна відповідь сервера, наприклад Access denied for user ‘user_wp’@’localhost’. Після діагностики поверніть значення false, щоб не показувати технічні подробиці відвідувачам. Якщо ж сайт видає білу сторінку чи іншу помилку з кодом 500, скористайтеся окремим розбором: помилка 500 на хостингу. Якщо ж WordPress показує повідомлення «На сайті сталася критична помилка», скористайтеся інструкцією, як виправити критичну помилку WordPress.
Швидка діагностика: п’ять кроків
Поки сайт недоступний, важить кожна хвилина. Пройдіть кроки по черзі: кожен відсікає одразу кілька причин.
- Прочитайте повідомлення в /wp-admin/. Текст із таблиці вище звужує пошук до однієї-двох причин.
- Перевірте інші сайти й phpMyAdmin на цьому хостингу. Якщо не працює все, проблема на рівні сервера баз даних, а не у вашому wp-config.php.
- Звірте wp-config.php з панеллю. Назва бази, користувач і хост мають збігатися посимвольно, разом із префіксом облікового запису.
- Увійдіть у phpMyAdmin з даними з wp-config.php. Не пускає: неправильний логін або пароль. Пускає, але бази немає в списку: користувач не має на неї прав.
- Перевірте ресурси й логи. Заповнений диск, вичерпані inode, перезапуск MySQL через нестачу пам’яті чи повідомлення Too many connections вказують на ліміти або збій сервера.
7 причин помилки і як виправити кожну
1. Неправильні дані доступу у wp-config.php
Найпоширеніша ситуація: сайт перенесли на інший хостинг, змінили пароль бази в панелі або хтось відредагував wp-config.php. Файл лежить у корені сайту поруч із папками wp-admin і wp-content, потрібні рядки виглядають так:
define( 'DB_NAME', 'user_wp' );
define( 'DB_USER', 'user_wp' );
define( 'DB_PASSWORD', 'your-password' );
define( 'DB_HOST', 'localhost' );
$table_prefix = 'wp_';На що звернути увагу:
- У багатьох панелях хостингу до назви бази й користувача автоматично додається ім’я облікового запису з підкресленням: створивши базу wp, ви отримаєте user_wp. Після переносу з іншої панелі префікс майже завжди інший.
- Зайві пробіли, типографські лапки з текстового редактора, обрізаний під час копіювання пароль.
- Одинарна лапка або зворотна скісна риска в паролі: у PHP-рядку їх треба екранувати (\’ і \\). Простіше задати новий пароль з латинських літер, цифр і дефісів.
Найнадійніше виправлення: задати користувачу бази новий пароль у панелі хостингу і вписати його у wp-config.php. Через SSH це зручно робити за допомогою WP-CLI: команди wp config читають і змінюють файл, не підключаючись до бази.
cd /home/user/web/example.com/public_html
wp config get DB_NAME
wp config get DB_HOST
wp config set DB_PASSWORD 'new-password'Якщо базу переносили разом із сайтом, переконайтеся, що дамп справді імпортовано і він не обірвався на середині. Типові пастки переїзду описані в статті про міграцію бази даних при переїзді хостингу.
2. Неправильний DB_HOST
На більшості віртуальних хостингів база працює на тому самому сервері, тому DB_HOST дорівнює localhost. Деякі провайдери виносять MySQL на окремий сервер і вказують його адресу в панелі, тоді localhost не спрацює. Технічна деталь: для PHP значення localhost означає підключення через Unix-сокет, а 127.0.0.1 через TCP-порт 3306. Якщо PHP шукає сокет не там, де його створює сервер бази, допомагає заміна localhost на 127.0.0.1.
| Значення DB_HOST | Як підключається PHP | Коли використовувати |
|---|---|---|
| localhost | Unix-сокет зі шляхом з налаштувань PHP | Типовий варіант для віртуального хостингу і VPS |
| 127.0.0.1 | TCP, порт 3306 | Сокет недоступний або MySQL приймає лише TCP |
| 127.0.0.1:3307 | TCP, нестандартний порт | На сервері працює другий екземпляр MySQL чи MariaDB |
| localhost:/run/mysqld/mysqld.sock | Явно вказаний сокет | Шлях до сокета відрізняється від типового |
| db.example.net | TCP до окремого сервера | Хостер дав окрему адресу сервера баз даних |
Після заміни localhost на 127.0.0.1 іноді з’являється Access denied: MySQL розрізняє користувачів ‘user’@’localhost’ і ‘user’@’127.0.0.1’, тож другого запису може просто не існувати.
3. Бази немає або користувач не має прав
Повідомлення Cannot select database означає, що логін і пароль прийнято, але база з назвою DB_NAME недоступна. Її не створили чи не імпортували після переносу, у назві помилка, або користувача не прив’язано до бази. У панелі хостингу користувача часто створюють разом із базою, тож перевірте в розділі баз даних, що DB_NAME і DB_USER належать одному запису. На VPS права перевіряє і видає адміністратор:
sudo mysql -e "SHOW DATABASES;"
sudo mysql -e "SHOW GRANTS FOR 'user_wp'@'localhost';"
sudo mysql -e "GRANT ALL PRIVILEGES ON user_wp.* TO 'user_wp'@'localhost';"4. Сервер MySQL або MariaDB зупинився
Якщо не працюють усі сайти облікового запису, а phpMyAdmin теж не відкривається, служба бази даних зупинена. На віртуальному хостингу це питання до підтримки. На VPS перевірте службу і причину зупинки:
sudo systemctl status mariadb # або mysql
sudo journalctl -u mariadb -n 50 --no-pager
sudo dmesg -T | grep -i -E "out of memory|killed process"
df -h # вільне місце на диску
df -i # вільні inode
sudo systemctl restart mariadbТри типові сценарії: ядро Linux зупинило mysqld через нестачу пам’яті, закінчилося місце на диску і база не може записувати журнали та тимчасові файли, або служба не стартує після оновлення через помилку в конфігурації. Перезапуск допомагає лише в першому випадку і тільки до наступного піку навантаження, тому з’ясуйте, що з’їдає пам’ять. Механізм розібрано в статті Swap, OOM Killer і tmpfs, а про вичерпані inode читайте в матеріалі про inode-ліміт на віртуальному хостингу.
5. Вичерпано ліміти хостингу
Помилка, яка з’являється і зникає, найчастіше пов’язана з лімітами. Сервер баз даних обмежує кількість одночасних з’єднань: загальну (max_connections, у MySQL і MariaDB за замовчуванням 151) і для одного користувача (max_user_connections, на віртуальному хостингу її задає провайдер). Коли ліміт вичерпано, нові запити отримують помилку 1040 Too many connections або 1203 User already has more than ‘max_user_connections’ active connections, а відвідувачі бачать Error establishing a database connection.
З’єднання тримають PHP-процеси, тож ліміт вичерпують ті самі чинники, що й процесорний час: наплив ботів на wp-login.php, xmlrpc.php і сторінки пошуку, важкі плагіни, відсутність кешу сторінок, wp-cron із десятками завдань. На VPS ситуацію видно так:
sudo mysql -e "SHOW VARIABLES LIKE 'max%connections';"
sudo mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_connected';"
sudo mysql -e "SHOW GLOBAL STATUS LIKE 'Max_used_connections';"
sudo mysql -e "SHOW FULL PROCESSLIST;"Збільшувати max_connections без аналізу не варто: кожне з’єднання займає пам’ять, і замість відмови в підключенні ви отримаєте зупинку сервера. Спершу ввімкніть кеш сторінок, закрийте xmlrpc.php, якщо він не потрібен, і перенесіть wp-cron у системний планувальник. Хто саме генерує запити, покажуть журнали доступу: як їх читати, пояснює стаття про логи хостингу. Якщо навантаження легітимне і стабільно впирається в ліміти, сайт переріс свій тариф.
6. Пошкоджені таблиці бази даних
Таблиці пошкоджуються після аварійного вимкнення сервера, переповнення диска або перерваного імпорту. Ознаки: повідомлення One or more database tables are unavailable в адмінці або записи на зразок Table ‘wp_options’ is marked as crashed у логах. Перед будь-яким відновленням зробіть копію бази (wp db export або експорт у phpMyAdmin). Далі є три способи:
- Вбудований інструмент WordPress. Додайте у wp-config.php рядок define( ‘WP_ALLOW_REPAIR’, true ); і відкрийте https://example.com/wp-admin/maint/repair.php. Сторінка працює без входу в адмінку, тому одразу після відновлення видаліть цей рядок.
- WP-CLI. Команда wp db check перевіряє таблиці, wp db repair відновлює їх.
- phpMyAdmin. Позначте таблиці бази і виберіть дію «Відновити таблицю» (Repair table).
REPAIR TABLE працює для таблиць MyISAM і Aria, а сучасні бази WordPress переважно використовують InnoDB, який відновлюється автоматично під час запуску сервера. Якщо InnoDB не стартує, на VPS вдаються до параметра innodb_force_recovery, але лише для того, щоб зробити дамп даних: значення 4 і вище можуть остаточно пошкодити файли. Без досвіду надійніше повернути свіжу резервну копію.
7. Drop-in db.php, пошкоджені файли або злам
Якщо дані доступу правильні, phpMyAdmin працює, а WordPress не підключається, загляньте в папку wp-content. Файл db.php у ній: це drop-in, який замінює стандартний клас роботи з базою. Його створюють, зокрема, плагіни кешування запитів і розподілу навантаження між кількома серверами на кшталт HyperDB чи LudicrousDB, які беруть налаштування з власного файлу, а не з wp-config.php. Тимчасово перейменуйте db.php на db.php.off: якщо сайт запрацював, причина в плагіні, що його створив.
Рідше трапляються пошкоджені файли ядра після невдалого оновлення: завантажте свіжі папки wp-admin і wp-includes з wordpress.org, не чіпаючи wp-content і wp-config.php. Якщо ж у wp-config.php з’явилися чужі рядки або змінилися дані бази, яких ви не редагували, розглядайте це як злам: змініть паролі бази, FTP і адміністраторів, перевірте файли і виставте коректні права доступу до файлів. Для wp-config.php зазвичай достатньо 640 або 600, якщо PHP працює від імені власника файлів, як зазвичай на віртуальному хостингу.
Тестовий скрипт: перевірка підключення без WordPress
Скрипт підключається до бази з тими самими даними, що й WordPress, і виводить точний код помилки MySQL. Створіть у корені сайту файл з випадковою назвою, наприклад db-check-7f3a.php, вставте код, підставте дані з wp-config.php і відкрийте файл у браузері.
<?php
mysqli_report(MYSQLI_REPORT_OFF);
$link = @mysqli_connect('localhost', 'user_wp', 'your-password', 'user_wp');
if (!$link) {
exit('ERROR ' . mysqli_connect_errno() . ': ' . mysqli_connect_error());
}
echo 'OK, server: ' . mysqli_get_server_info($link);Рядок mysqli_report потрібен для PHP 8.1 і новіших: без нього невдале підключення викидає виняток замість зрозумілого тексту. Після перевірки обов’язково видаліть файл, бо в ньому записано пароль від бази.
| Код | Текст помилки | Що означає | Що робити |
|---|---|---|---|
| 1045 | Access denied for user ‘user’@’localhost’ (using password: YES) | Неправильний логін чи пароль або немає користувача з таким хостом | Задати новий пароль у панелі й оновити wp-config.php |
| 1044 | Access denied for user … to database … | Користувач існує, але не має прав на базу | Прив’язати користувача до бази, видати права |
| 1049 | Unknown database | Бази з такою назвою немає | Перевірити DB_NAME і префікс, імпортувати дамп |
| 2002 | No such file or directory, Connection refused або getaddrinfo failed | Немає сокета, сервер бази не запущений або хост не знайдено | Перевірити службу MySQL, спробувати 127.0.0.1, звірити DB_HOST |
| 1040 | Too many connections | Вичерпано загальний ліміт з’єднань сервера | Знайти джерело навантаження, звернутися до хостера |
| 1203 | User … already has more than ‘max_user_connections’ active connections | Вичерпано ліміт з’єднань вашого користувача | Кеш сторінок, захист від ботів, перенесення cron, більший тариф |
Віртуальний хостинг чи VPS: що можна зробити самостійно
| Дія | Віртуальний хостинг | VPS |
|---|---|---|
| Змінити пароль бази і wp-config.php | Так, у панелі | Так |
| Відновити таблиці (repair.php, phpMyAdmin, WP-CLI) | Так | Так |
| Перезапустити MySQL чи MariaDB | Ні, через підтримку | Так |
| Змінити max_connections і пам’ять для бази | Ні | Так |
| Переглянути журнал сервера бази даних | Зазвичай ні | Так |
Звертаючись до підтримки, одразу вкажіть адресу сайту, точний час появи помилки, що змінювали перед цим (перенос, оновлення, новий плагін) і результат тестового скрипта з кодом помилки. Такий запит розбирають значно швидше, ніж коротке «сайт не працює».
Як не допустити повторення
- Робіть резервні копії бази окремо від файлів і хоча б раз перевірте, що з них справді можна відновитися.
- Налаштуйте моніторинг доступності: WordPress віддає на цій помилці код 500, тож її помітить будь-яка перевірка статусу сторінки.
- Увімкніть кеш сторінок, обмежте спроби входу на wp-login.php і закрийте xmlrpc.php, якщо він не потрібен.
- Регулярно проводьте оптимізацію бази даних: роздуті таблиці опцій, ревізій і транзієнтів тримають з’єднання довше.
- Стежте за вільним місцем і inode: переповнений диск зупиняє базу даних.
- Не ставте права 777 на wp-config.php і не зберігайте копії файлу з паролем у публічних папках.
Корисно також підготувати власну сторінку на випадок збою. Якщо у wp-content є файл db-error.php, WordPress показує його замість стандартного повідомлення. Код 503 із заголовком Retry-After підказує пошуковим роботам, що збій тимчасовий:
<?php
http_response_code(503);
header('Retry-After: 600');
?>
<!doctype html>
<html lang="uk"><head><meta charset="utf-8"><title>Технічні роботи</title></head>
<body><h1>Сайт тимчасово недоступний</h1><p>Ми вже працюємо над цим. Спробуйте за кілька хвилин.</p></body></html>Часті питання
Чи можна втратити дані через цю помилку?
Сама помилка нічого не видаляє: WordPress просто не може прочитати базу. Ризик з’являється під час відновлення таблиць, експериментів з innodb_force_recovery чи повторного встановлення WordPress, тому спершу зробіть копію бази.
Чому помилка то з’являється, то зникає?
Майже завжди це ліміти: у пікові хвилини вичерпується кількість з’єднань, пам’ять або процеси PHP. Порівняйте час збоїв із журналами доступу і пошукайте ботів, запуски cron і важкі операції в адмінці.
Сайт працює, а адмінка пише, що таблиці недоступні. Що робити?
Частина таблиць пошкоджена або відсутня. Зробіть копію бази, увімкніть WP_ALLOW_REPAIR і запустіть /wp-admin/maint/repair.php, а після відновлення видаліть константу з wp-config.php.
Чи допоможе перевстановлення WordPress?
Зазвичай ні, бо проблема в підключенні до бази, а не у файлах. Замінювати варто лише папки wp-admin і wp-includes, якщо є ознаки пошкодження ядра. Не запускайте встановлення повторно, якщо бачите сторінку інсталяції: спершу перевірте $table_prefix.
Помилка з’явилася після переносу мультисайту на новий домен. Чому?
Мережа WordPress шукає домен у таблицях wp_site і wp_blogs і в константі DOMAIN_CURRENT_SITE. Якщо там лишився старий домен, ви бачите Error establishing a database connection з поясненням Could not find site. Оновіть домен у wp-config.php і в цих таблицях.
Чи впливає помилка на SEO?
Короткий збій на кілька хвилин позиціям не шкодить. Якщо ж сайт віддає помилку годинами чи днями, пошукові системи можуть тимчасово прибрати сторінки з видачі. Швидке виправлення і сторінка db-error.php з кодом 503 зменшують ризик.
Висновок
Error establishing a database connection лише здається страшною: у більшості випадків причину знаходять за кілька хвилин. Прочитайте детальне повідомлення в /wp-admin/, звірте wp-config.php з панеллю, перевірте вхід у phpMyAdmin і запустіть тестовий скрипт, а якщо збій повторюється, шукайте причину в лімітах і навантаженні. Коли сайт стабільно впирається в ресурси, варто перейти на потужніший тариф. На хостингу для WordPress від RichHost сайти працюють на NVMe-дисках, сайтами й базами даних керують через власну панель керування з ШІ-помічником, а тарифи починаються від $8 на місяць за A3 з економією 10% при оплаті за рік.
