Error establishing a database connection: co oznacza błąd połączenia z bazą danych w WordPressie i jak go naprawić

Komunikat „Error establishing a database connection” (w polskiej wersji: „Błąd łączenia się z bazą danych”) zastępuje całą stronę. Wygląda groźnie, ale w większości przypadków dane są całe. WordPress po prostu nie może się do nich dostać. Poniżej opisujemy, jak w kilku krokach ustalić, czy problem leży po Twojej stronie (ustawienia), czy po stronie hostingu (serwer), i co zrobić w każdym z tych przypadków.

Jak WordPress korzysta z bazy danych

Strona na WordPressie składa się z dwóch części. Pierwsza to pliki: sam WordPress, motyw, wtyczki i zdjęcia. Druga to baza danych MySQL lub MariaDB, w której są treści wpisów i stron, użytkownicy, komentarze, ustawienia i konfiguracja wtyczek. Przy każdym otwarciu strony WordPress łączy się z bazą, pobiera treść i składa z niej stronę.

Do połączenia potrzebne są cztery dane zapisane w pliku wp-config.php:

define( 'DB_NAME', 'nazwa_bazy' );     // nazwa bazy danych
define( 'DB_USER', 'uzytkownik_bazy' ); // użytkownik bazy (nie login do WordPressa)
define( 'DB_PASSWORD', 'haslo' );       // hasło użytkownika bazy
define( 'DB_HOST', 'localhost' );       // adres serwera bazy, najczęściej localhost

Jeśli którakolwiek z nich jest błędna albo serwer bazy nie odpowiada, WordPress nie ma skąd wziąć treści i pokazuje komunikat o błędzie połączenia.

Najczęstsze przyczyny błędu error establishing a database connection

1. Błędne dane w wp-config.php. Najczęściej po przeprowadzce strony na inny hosting, po zmianie hasła do bazy w panelu albo po przywróceniu starej kopii plików. Typowy objaw: błąd pojawił się dokładnie po jednej z tych czynności i nie znika.
2. Serwer bazy nie działa lub jest przeciążony. Awaria albo prace u hostingu, zbyt wiele jednoczesnych połączeń (np. przy nagłym ruchu albo ataku botów). Typowy objaw: błąd pojawia się i znika, albo dotyczy wielu stron na tym samym hostingu.
3. Brak miejsca na koncie. Gdy konto hostingowe jest pełne, serwer bazy nie może zapisywać danych. Typowy objaw: wcześniej przychodziły e-maile o zbliżającym się limicie, a w panelu pasek miejsca jest na 100%.
4. Uszkodzone tabele. Po awarii serwera lub przerwanej aktualizacji część tabel może wymagać naprawy. Typowy objaw: w /wp-admin pojawia się inny komunikat, o niedostępnych tabelach.
5. Baza została usunięta lub zawieszona. Zdarza się po nieopłaconym hostingu, pomyłce przy porządkach w panelu albo po włamaniu.

Zanim zaczniesz

• Zrób kopię plików i bazy w panelu hostingu, jeśli panel na to pozwala. Jeśli baza nie działa, zrób przynajmniej kopię plików, w tym wp-config.php.
• Sprawdź, czy to nie jest problem tylko u Ciebie. Otwórz stronę w trybie prywatnym przeglądarki i na telefonie przez sieć komórkową. Jeśli działa, problem leży w pamięci podręcznej (np. Cloudflare lub wtyczki cache), a nie w bazie.
• Zanotuj, co się działo przed awarią: przeprowadzka, zmiana hasła, aktualizacja, wiadomość od hostingu. To zwykle wskazuje przyczynę szybciej niż jakakolwiek diagnoza.

Krok 1. Sprawdź stronę statusu hostingu

Zanim zaczniesz zmieniać ustawienia, sprawdź, czy hosting nie ma awarii. Większość firm hostingowych prowadzi stronę statusu albo informuje o pracach na swoich profilach w mediach społecznościowych. Pomocny jest też panel klienta: komunikaty o awariach, o przekroczonych limitach czy o zawieszeniu konta są tam zwykle na pierwszym ekranie.

Jeśli hosting zgłasza awarię, nie zmieniaj niczego na stronie. Poczekaj na zakończenie prac i sprawdź stronę ponownie. Zmiany w trakcie awarii utrudniają potem ustalenie, co naprawdę się zepsuło.

Krok 2. Zobacz, co pokazuje /wp-admin

Wpisz w przeglądarce adres swojej strony z dopiskiem /wp-admin. Możliwe są dwa wyniki:

• Ten sam komunikat o błędzie połączenia. WordPress w ogóle nie łączy się z bazą. Przejdź do kroku 3.
• Komunikat, że jedna lub więcej tabel bazy jest niedostępnych i baza może wymagać naprawy. Połączenie działa, ale część tabel jest uszkodzona. Przejdź do kroku 5.

Krok 3. Sprawdź dane logowania do bazy w phpMyAdmin

To najważniejszy test, bo w kilka minut rozstrzyga, czy problem leży w danych logowania. Nie wymaga znajomości kodu.

1. W menedżerze plików hostingu otwórz plik wp-config.php (w głównym folderze strony) w trybie podglądu. Przepisz wartości DB_NAME, DB_USER, DB_PASSWORD i DB_HOST.
2. W panelu hostingu znajdź phpMyAdmin (zwykle w sekcji „Bazy danych MySQL” lub „Zarządzanie MySQL”).
3. Jeśli phpMyAdmin pyta o login, wpisz dokładnie użytkownika i hasło z wp-config.php. Jeśli loguje automatycznie, przejdź do punktu 5.
4. Jeśli logowanie się udało, sprawdź, czy na liście po lewej jest baza o nazwie z DB_NAME i czy ma tabele z przedrostkiem z pliku wp-config.php (zmienna $table_prefix, domyślnie wp_).
5. W sekcji baz danych w panelu sprawdź też, czy baza i użytkownik o tych nazwach istnieją i czy użytkownik ma przypisane uprawnienia do bazy.

Uwaga na DB_HOST. Na większości polskich hostingów współdzielonych wartość to localhost. Niektóre firmy używają osobnego adresu serwera bazy. Jeśli przenosiłeś stronę, sprawdź w panelu lub dokumentacji nowego hostingu, jaki adres podać. Stary adres z poprzedniego hostingu to częsta przyczyna błędu po przeprowadzce.

Krok 4. Popraw dane logowania

Jeśli test wykazał błędne dane, masz dwie drogi:

• Znasz poprawne hasło (np. z wiadomości od hostingu przy zakładaniu bazy): popraw wartość w wp-config.php.
• Nie znasz hasła: w panelu hostingu, w sekcji baz danych, ustaw nowe hasło dla użytkownika bazy. Następnie wpisz to samo hasło w wp-config.php w linii DB_PASSWORD.

Przy edycji wp-config.php zwróć uwagę na apostrofy. Wartość musi być w pojedynczych prostych apostrofach, a hasło nie może zawierać znaku apostrofu, chyba że zostanie poprzedzony ukośnikiem. Najprościej ustawić w panelu hasło bez apostrofów i cudzysłowów. Zapisz plik i odśwież stronę.

Ważne: zmiana hasła użytkownika bazy w panelu bez zmiany wp-config.php wyłączy stronę. Jeśli z tego samego użytkownika korzysta więcej stron, zaktualizuj plik w każdej z nich.

Krok 5. Napraw uszkodzone tabele

Jeśli /wp-admin pokazuje komunikat o niedostępnych tabelach, WordPress ma wbudowane narzędzie naprawy.

1. W pliku wp-config.php, nad linią kończącą edycję (w polskiej wersji zaczyna się od „To wszystko”), dodaj linię:

   define( 'WP_ALLOW_REPAIR', true );

2. Otwórz adres twojadomena.pl/wp-admin/maint/repair.php.
3. Wybierz Napraw bazę danych. Opcja z optymalizacją trwa dłużej i na dużej bazie może obciążyć serwer.
4. Po zakończeniu usuń tę linię z wp-config.php. Strona naprawy działa bez logowania, więc pozostawiona włączona jest dostępna dla każdego.

Naprawę można też uruchomić w phpMyAdmin: zaznacz tabele, a z listy na dole wybierz „Napraw tabelę”. Efekt jest podobny.

Krok 6. Gdy problem jest po stronie serwera

Brak miejsca. Sprawdź w panelu hostingu zużycie miejsca. Najczęściej zapychają je stare kopie zapasowe trzymane na tym samym koncie, logi i nieużywane instalacje. Usuń zbędne pliki albo zwiększ pakiet. Nie usuwaj niczego z folderu bazy danych ani z wp-content/uploads, jeśli nie wiesz, co to jest.

Zbyt wiele połączeń. Serwer bazy ma limit jednoczesnych połączeń. Gdy go przekroczy, odrzuca kolejne. Na hostingu współdzielonym limit dotyczy zwykle jednego konta. Przyczyną bywa nagły ruch, agresywne boty albo wtyczka, która wykonuje bardzo dużo zapytań. Hosting może sprawdzić w logach, co obciąża bazę. Po Twojej stronie pomaga wtyczka cache lub cache na poziomie serwera, ograniczenie ruchu botów (np. w Cloudflare) i usunięcie wtyczek, które tego wymagają.

Baza usunięta lub pusta. Nie twórz nowej, pustej bazy pod tą samą nazwą, bo WordPress zaproponuje wtedy nową instalację, a pomyłka przy niej może nadpisać dane. Sprawdź kopie zapasowe hostingu i przywróć bazę z ostatniej dobrej kopii. Więcej o tym, jak powinny wyglądać kopie, piszemy w artykule o kopiach zapasowych według zasady 3-2-1.

W każdym innym przypadku napisz do obsługi hostingu. Podaj adres strony, dokładną godzinę wystąpienia błędu, wynik testu z kroku 3 i informację, czy błąd jest stały, czy pojawia się i znika. Takie zgłoszenie zwykle dostaje konkretną odpowiedź zamiast prośby o więcej danych.

Kiedy przestać i poprosić o pomoc

• Na liście baz w phpMyAdmin widzisz tabele lub użytkowników, których nie tworzyłeś, albo w tabeli użytkowników są nieznane konta administratorów. To może być ślad włamania. Zobacz nasz poradnik WordPress po włamaniu: pierwsze 24 godziny.
• Naprawa tabel zgłasza błędy, których nie da się naprawić.
• Jedyna kopia bazy jest starsza niż kilka tygodni, a strona to sklep z zamówieniami.
• Strona była niedawno przenoszona, a w bazie zostały stare adresy (strona działa, ale przekierowuje na stary hosting lub starą domenę).

Jak zapobiegać

• Kopia bazy codziennie, poza serwerem. Kopia na tym samym koncie nie pomoże, gdy konto zostanie zawieszone lub zapełnione.
• Zapisuj dane do bazy w menedżerze haseł, razem z adresem phpMyAdmin i nazwą hostingu.
• Przeprowadzki z listą kontrolną. Przy przenoszeniu strony dane bazy w wp-config.php zawsze trzeba zmienić. Opisujemy to w artykule Przeniesienie strony na inny hosting bez przerwy w działaniu.
• Kontrola miejsca na koncie raz w miesiącu, a przynajmniej reakcja na e-maile od hostingu o limitach.
• Monitoring dostępności. Prosty, bezpłatny monitoring (sprawdzanie strony co kilka minut) powie Ci o awarii, zanim zgłosi ją klient.

Podobny w objawach, ale inny w przyczynach jest błąd krytyczny na stronie WordPress. Jeśli strona działa, ale nie możesz wejść do panelu, zobacz poradnik Nie mogę zalogować się do WordPressa.

Źródła

• WordPress Developer Resources: Editing wp-config.php (ustawienia bazy, WP_ALLOW_REPAIR) (dostęp: 9.11.2026)
• WordPress.org Documentation: Common WordPress Errors (dostęp: 9.11.2026)
• MySQL Reference Manual: Too many connections (dostęp: 9.11.2026)
• MariaDB Documentation: REPAIR TABLE (dostęp: 9.11.2026)
• phpMyAdmin: Dokumentacja (dostęp: 9.11.2026)