„Error establishing a database connection" in WordPress beheben

Statt deiner Seite erscheint nur ein nüchterner Satz: „Error establishing a database connection”. Bei deutscher Spracheinstellung lautet die Meldung laut WordPress-Übersetzung „Fehler beim Aufbau einer Datenbankverbindung”. Gemeint ist dasselbe: WordPress erreicht seine Datenbank nicht, und ohne Datenbank kann es nichts anzeigen.

Der Text selbst nennt schon die Richtung. In wp-includes/class-wpdb.php steht, dass entweder die Zugangsdaten in der wp-config.php falsch sind oder dass der Datenbankserver unter dem angegebenen Host nicht erreicht wurde, vielleicht weil er ausgefallen ist. Mehr weiß WordPress an dieser Stelle auch nicht. Deine Aufgabe ist, das herauszufinden, was die Meldung offenlässt.

Erst einordnen: Welcher Fehler ist es genau?

Drei Bilder sehen ähnlich aus und haben verschiedene Ursachen:

• Frontend und Backend zeigen „Error establishing a database connection”. Die Verbindung kommt nicht zustande. Das ist der Hauptfall dieses Artikels.
• Das Frontend zeigt den Fehler, im Backend steht „One or more database tables are unavailable. The database may need to be repaired”. Die Verbindung steht, aber Tabellen sind beschädigt oder fehlen. Dann springst du zu Abschnitt 6. Dieser Hinweis wird in is_blog_installed() (wp-includes/functions.php) gesetzt und verlinkt auf maint/repair.php.
• „Cannot select database”. Der Server hat Benutzer und Passwort akzeptiert, aber die Datenbank unter DB_NAME ließ sich nicht auswählen. Das ist eine eigene Meldung in class-wpdb.php. Passwort und Host stimmen dann, falsch ist meist der Datenbankname. Bei manchen Systemen steht vor dem Namen ein Präfix, oft der Kontoname; die Meldung weist selbst darauf hin.

Ein komplett weißer Bildschirm ohne Text ist wieder etwas anderes. Dafür gibt es den Überblick zu WordPress-Fehlern.

1. Stimmen die Zugangsdaten in der wp-config.php?

Der häufigste Auslöser, besonders nach einem Server- oder Hosting-Umzug. Öffne die wp-config.php im Hauptverzeichnis und prüfe diese vier Werte:

define( 'DB_NAME', 'datenbankname' );
define( 'DB_USER', 'benutzer' );
define( 'DB_PASSWORD', 'passwort' );
define( 'DB_HOST', 'localhost' );

Typische Fehler: ein Tippfehler im Namen, ein Passwort, das beim Kopieren ein Leerzeichen oder ein verändertes Sonderzeichen mitgenommen hat, oder Zugangsdaten des alten Servers, die nach dem Umzug nicht angepasst wurden. Vergleiche die Werte nicht aus dem Gedächtnis, sondern mit dem, was das Hosting-Panel in der Datenbankverwaltung anzeigt.

DB_HOST: Port, Socket, localhost und 127.0.0.1

DB_HOST ist oft localhost, bei manchen Hostern aber ein eigener Servername. WordPress akzeptiert in diesem Feld mehr als einen Namen: Die Methode parse_db_host() in class-wpdb.php trennt einen Port (db.example.com:3306) und einen Socket-Pfad (alles ab :/) ab und reicht beides an mysqli weiter. Auch IPv6-Adressen werden erkannt.

Relevant ist der Unterschied zwischen localhost und 127.0.0.1. Laut MySQL-Dokumentation verbinden sich Clients unter Unix bei localhost über eine Socket-Datei statt über TCP/IP, und eine Portangabe wird dann ignoriert. Die PHP-Dokumentation zu mysqli sagt dasselbe: Bei localhost wird der Port übergangen, wer einen anderen Port braucht, nimmt 127.0.0.1. Wenn dein Hoster einen Port nennt und localhost:3307 nicht funktioniert, ist das also kein Zufall. Probiere den Wechsel nur, wenn der Hoster keine andere Angabe macht.

2. Verbindung unabhängig von WordPress testen

Ob die Zugangsdaten stimmen, sagt dir ein temporäres Testskript in einer Minute, inklusive Klartext-Erklärung des MySQL-Fehlers:

Auch als eigenständige Seite mit allen Anleitungen: Verbindungstest.

Wer es selbst bauen will, legt eine Datei dbtest.php ins Hauptverzeichnis, trägt die Werte aus der wp-config.php ein und ruft sie im Browser auf:

<?php
mysqli_report( MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT );

try {
    $db = new mysqli( 'localhost', 'benutzer', 'passwort', 'datenbankname' );
    echo 'Verbindung steht. Serverversion: ' . $db->server_info;
} catch ( mysqli_sql_exception $e ) {
    echo 'Fehler ' . $e->getCode() . ': ' . $e->getMessage();
}

Lösche die Datei sofort nach dem Test. Sie enthält dein Datenbankpasswort im Klartext.

Mit SSH-Zugang geht es auch auf der Kommandozeile mit dem MySQL-Client:

mysql -h localhost -u benutzer -p datenbankname

Gelingt der Login, stimmen Daten und Server, und das Problem liegt bei dem, was WordPress daraus macht, zum Beispiel weil du eine andere wp-config.php prüfst als die, die tatsächlich geladen wird. Scheitert er, steht im Fehler meist die Richtung: „Access denied” heißt, Benutzer oder Passwort passen nicht. Ein Verbindungsfehler zum Host heißt, dass der Server nicht erreicht wird.

3. Läuft der Datenbankserver überhaupt?

Prüfe, ob andere Seiten auf demselben Hosting betroffen sind. Sind sie es, ist der Datenbankserver das Problem, und du kannst nur beim Hoster nachfragen. Ein Blick ins Hosting-Panel oder auf die Statusseite des Hosters spart oft Zeit.

Bei ausgelasteten Seiten kommt die Meldung „Too many connections” vor. Die MySQL-Dokumentation erklärt sie so: Alle erlaubten Verbindungen sind von anderen Clients belegt. Die Obergrenze steuert die Variable max_connections. Der Server erlaubt außerdem eine zusätzliche Verbindung für Konten mit dem Recht CONNECTION_ADMIN (früher SUPER), damit Administratoren die Lage untersuchen können. Im Shared Hosting kannst du max_connections nicht ändern. Du kannst nur herausfinden, was die Verbindungen belegt, etwa ein Bot-Ansturm oder ein Plugin mit langsamen Abfragen. Auf einem eigenen Server erhöhst du den Wert in der MySQL-Konfiguration, solltest aber zuerst fragen, warum so viele Verbindungen offen sind.

Auch ein erreichtes Kontingent beim Hoster kommt vor. Die WordPress-Dokumentation zu häufigen Fehlern nennt als Ursache ausdrücklich, dass die Datenbank ihr Kontingent erreicht hat und abgeschaltet wurde. Im Panel siehst du unter Speicherplatz und Datenbankgröße, ob das bei dir zutrifft. Ist dort ein Limit voll, schaffst du Platz (alte Backups, Logfiles, Revisionen) und bittest den Hoster, den Datenbankdienst zu prüfen.

4. Zugangsdaten beim Hoster neu setzen

Hat sich das Datenbank-Passwort geändert oder ist der Benutzer gesperrt, setzt du beides im Hosting-Panel neu und trägst es in die wp-config.php ein. Prüfe dabei auch, ob der Benutzer der Datenbank zugeordnet ist und Rechte darauf hat. Genau das fragt auch WordPress selbst in der Meldung „Cannot select database”. Wenn du dabei ohnehin in der Datenbank bist und noch Login-Probleme hast, hilft dir der Beitrag Ausgesperrt aus dem WP-Admin weiter.

5. Fehler nach einem Umzug oder Hosterwechsel

Taucht der Fehler direkt nach einem Umzug auf, gehst du in dieser Reihenfolge vor:

1. Wurde die Datenbank importiert, und ist sie vollständig? In phpMyAdmin siehst du die Tabellen mit dem Präfix aus $table_prefix in der wp-config.php.
2. Passen DB_NAME, DB_USER und DB_PASSWORD zum neuen Server? Beim Hosterwechsel ändern sich diese Werte fast immer.
3. Stimmt DB_HOST? Der neue Hoster nutzt vielleicht keinen localhost-Eintrag.

Nicht die Ursache sind siteurl und home. Diese beiden Werte stehen als Optionen selbst in der Datenbank, WordPress kann sie erst lesen, wenn die Verbindung steht. Eine falsche Domain nach dem Umzug führt zu Weiterleitungen oder kaputten Styles, nicht zu dieser Meldung. Hast du Domain und Datenbank gleichzeitig geändert, behebe zuerst die Verbindung, dann die URLs.

6. Ist die Datenbank beschädigt?

Lädt das Frontend nicht, das Backend aber mit dem Hinweis „One or more database tables are unavailable. The database may need to be repaired”, hilft oft die eingebaute Reparatur. Die Seite wp-admin/maint/repair.php führt laut Quellcode REPAIR TABLE für die Tabellen aus und kann auf Wunsch anschließend OPTIMIZE TABLE anstoßen. Dafür ergänzt du in der wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

Rufe anschließend https://www.domain.tld/wp-admin/maint/repair.php auf (mit deiner Domain), starte die Reparatur und entferne die Zeile danach wieder. Die Seite ist solange ohne Login erreichbar, und WordPress selbst weist am Ende darauf hin, die Zeile zu entfernen.

Mit SSH-Zugang und WP-CLI geht es auch ohne Browser. wp db check prüft die Tabellen, wp db repair repariert sie. Beide Befehle rufen laut WP-CLI-Dokumentation das Werkzeug mysqlcheck mit den Zugangsdaten aus der wp-config.php auf:

wp db check
wp db repair

Eine Reparatur ersetzt kein Backup. Sichere vorher, was sich noch exportieren lässt.

7. Wurde die wp-config.php verändert?

Sind Konfiguration und Hosting unauffällig, nennt die WordPress-Dokumentation als dritte mögliche Ursache eine kompromittierte Seite. Warnzeichen sind ein Änderungsdatum der wp-config.php, das du nicht erklären kannst, unbekannte Benutzer in der Datenbank oder fremder Code in der Datei. Dann reicht es nicht, die Verbindung wiederherzustellen, die Ursache muss mit raus. Wie du die Konfiguration künftig absicherst, steht in wp-config.php härten.

Wann es am Hoster liegt und was du dem Support schickst

Der Fehler liegt nicht bei dir, wenn der Test aus Abschnitt 2 mit den Werten aus dem Panel scheitert, wenn mehrere Seiten auf dem Hosting betroffen sind oder wenn der Fehler ohne jede Änderung von deiner Seite aufgetreten ist. Schick dem Support:

• die genaue Fehlermeldung aus dem Testskript, nicht nur „WordPress geht nicht”
• den Zeitpunkt des ersten Auftretens und was davor geändert wurde
• den Wert von DB_HOST und den Datenbanknamen, ohne Passwort
• ob andere Seiten auf demselben Paket betroffen sind

Mit diesen Angaben spart der Support Rückfragen.

Vorbeugen

Ein aktuelles, getestetes Backup macht aus diesem Fehler eine Unannehmlichkeit statt einer Katastrophe. Wie du das sinnvoll aufsetzt, beschreibt WordPress-Backups richtig machen. Dazu passt ein Monitoring, das die Seite von außen prüft und dich informiert, bevor Besucher die Meldung sehen.

Kurz-Checkliste

1. Fehlerbild einordnen: Verbindung (Frontend und Backend) oder nur Tabellenhinweis im Backend.
2. Zugangsdaten und DB_HOST in der wp-config.php mit dem Hosting-Panel vergleichen.
3. Verbindung unabhängig testen (mysqli-Skript oder mysql-Client), Skript danach löschen.
4. Andere Seiten, Limits und „Too many connections” prüfen, dann den Hoster kontaktieren.
5. Bei Tabellenhinweis: WP_ALLOW_REPAIR oder wp db repair, Zeile danach entfernen.
6. Nach Umzug: Import, Benutzerzuordnung, Host.

Eine Einordnung anderer Fehlerbilder findest du im Überblick zu WordPress-Fehlern.

Bleibt die Verbindung weg oder willst du nicht selbst an Zugangsdaten und Datenbank: Schreib uns kurz – wir stellen die Verbindung wieder her. Mit einem laufenden Wartungspaket fällt so ein Ausfall übrigens durchs Monitoring auf, bevor ihn deine Besucher bemerken.