Fehler beim Aufbau einer Datenbankverbindung beheben

„Fehler beim Aufbau einer Datenbankverbindung“ heißt: PHP läuft, WordPress hat die wp-config.php gelesen und wollte den MySQL- oder MariaDB-Server erreichen, und genau das ist gescheitert. Alles, was danach käme, Plugins, Theme, Inhalte, wird gar nicht erst geladen. Deshalb sieht die Seite für alle gleich aus: Startseite, Beiträge und /wp-admin/ zeigen dieselbe Meldung. Die Ursache liegt in einer von drei Ecken: in den vier Datenbank-Zeilen der wp-config.php, beim Datenbankserver des Hosters oder in einer Datenbank, die es so nicht mehr gibt.

Die Meldung verrät die Ursache nicht. In db_connect() in wp-includes/class-wpdb.php unterdrückt WordPress die Fehlermeldung der Verbindungsfunktion, solange WP_DEBUG aus ist. Der Hilfetext darunter („Sind Benutzername und Passwort wirklich korrekt?“, „Hast du den Hostnamen wirklich korrekt eingegeben?“, „Ist sichergestellt, dass der Datenbank-Server läuft?“) ist für alle Fälle derselbe. Mit WP_DEBUG steht die echte Meldung von MySQL über der Überschrift, und die sagt, was los ist.

Welche Meldung es ist, und welche nicht#

Drei Meldungen werden gern verwechselt:

• „Fehler beim Aufbau einer Datenbankverbindung“ (Error establishing a database connection): Der Datenbankserver wurde nicht erreicht oder hat die Anmeldung abgelehnt. Darum geht es hier.
• „Die Datenbank konnte nicht ausgewählt werden“ (Cannot select database): Die Anmeldung hat geklappt, aber die Datenbank mit dem Namen aus DB_NAME gibt es nicht, oder der Benutzer darf sie nicht benutzen. WordPress schreibt in diese Meldung sogar hinein, dass Benutzername und Passwort in Ordnung sind, und fragt nach dem Namen: Manche Hoster stellen den Benutzernamen voran, dann heißt die Datenbank benutzername_wordpress und nicht wordpress.
• „Es gab einen kritischen Fehler auf deiner Website“: Das ist ein PHP-Fehler in Plugin oder Theme, abgefangen vom Fehlerschutz, den WordPress seit 5.2 hat, meist mit Wiederherstellungs-Mail. Dazu gibt es den eigenen Beitrag Kritischer Fehler in WordPress beheben. Bei der Datenbankmeldung kommt keine Mail, weil WordPress noch gar nicht so weit geladen ist, dass es eine schicken könnte.

Die Seite antwortet dabei mit dem HTTP-Status 500. Für Google ist das ein Serverfehler: Der Crawler kommt seltener, und wer dauerhaft 500 liefert, fliegt aus dem Index. Ein paar Stunden sind kein Problem, Wochen schon.

Schritt 1: die echte Fehlermeldung sichtbar machen#

In der wp-config.php oberhalb der Zeile /* That's all, stop editing! Happy publishing. */:

define( 'WP_DEBUG', true );

Seite neu laden. Über der Überschrift steht jetzt eine Zeile wie Access denied for user 'wp_shop'@'10.0.5.12' (using password: YES). Das ist die Antwort des Datenbankservers, und bail() in der Datenbankklasse stellt sie der Meldung voran, sobald WP_DEBUG gesetzt ist. Wer die Meldung lieber nicht auf der Website sehen will (sie nennt Benutzername und Server), schreibt sie ins Protokoll:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Dann steht in wp-content/debug.log eine Zeile wie PHP Warning: mysqli_real_connect(): (HY000/1045): Access denied for user …. Die Zahl hinter dem Schrägstrich ist die Fehlernummer von MySQL. Danach WP_DEBUG wieder auf false, die Dokumentation von WordPress sagt ausdrücklich, dass der Debug-Modus nichts für Live-Seiten ist.

Die Nummern, die bei dieser Meldung vorkommen, nach der MySQL-Referenz:

1045 ist dein Fall, 2003 und 1040 sind meist der Fall des Hosters, 2005 kann beides sein.

Schritt 2: wp-config.php mit den Daten des Hosters abgleichen#

Die vier Zeilen, um die es geht:

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

Die richtigen Werte stehen im Kundenmenü des Hosters, nicht in WordPress. Bei STRATO unter Paket → Datenbanken und Webspace → Datenbankverwaltung, und als Server gehört dort rdbms.strato.de statt localhost hinein, so steht es in der Anleitung von STRATO. World4You beschreibt in seiner FAQ, wo die MySQL-Zugangsdaten stehen und wie man sie neu setzt. Bei vielen anderen Hostern ist localhost richtig. Braucht der Server einen Port oder eine Socket-Datei, nimmt WordPress beides im selben Feld: 'DB_HOST', 'db.example.at:3307' oder 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock'.

Was beim Abgleich auffällt:

• Ein Leerzeichen am Ende des Passworts, beim Kopieren mitgenommen. Oder 0 und O, l und 1.
• Das Passwort wurde neu gesetzt, im Kundenmenü, „zur Sicherheit“, von dir, vom Webdesigner oder bei einem Umzug, und niemand hat die wp-config.php nachgezogen.
• Der Hoster hat den Datenbankserver umgestellt, zum Beispiel auf eine neuere MySQL-Version, und der Hostname ist ein anderer. Dann steht es in einer Mail des Hosters, und die Fehlernummer ist 2005 oder 2003.
• Die Datenbank gibt es nicht mehr: Zusatzpaket gekündigt, Vertrag gewechselt, Datenbank im Kundenmenü gelöscht. Die WordPress-Dokumentation nennt auch ein überschrittenes Kontingent als Ursache.

Ob die Daten stimmen, prüfst du außerhalb von WordPress. Am einfachsten im phpMyAdmin des Hosters mit genau diesem Benutzer und Passwort. Mit SSH tut es wp db check, das mysqlcheck mit den vier Werten aus der wp-config.php aufruft; scheitert das mit derselben Meldung, liegt es nicht an WordPress. Ohne beides reicht eine Datei test-db.php im Hauptverzeichnis:

<?php
$db = @new mysqli( 'HOST', 'BENUTZER', 'PASSWORT', 'DATENBANKNAME' );
echo $db->connect_errno ? $db->connect_errno . ': ' . $db->connect_error : 'Verbindung in Ordnung';

Aufrufen, lesen, danach sofort löschen, denn in der Datei steht das Passwort.

Schritt 3: wenn es beim Hoster liegt#

Bei 2002, 2003 und 1040 hilft keine Änderung an der wp-config.php. Der Datenbankserver läuft nicht, ist nicht erreichbar oder hat keine freie Verbindung mehr. Dann: Statusseite des Hosters ansehen, zehn Minuten warten, noch einmal laden. Bleibt es, ein Ticket mit Fehlernummer, Uhrzeit und Domain. Das spart dem Support die erste Rückfrage.

Kommt die Meldung nur manchmal, mitten am Tag, und verschwindet beim Neuladen, ist der Server überlastet, oder deine eigene Seite erzeugt die Last: ein Plugin mit vielen Abfragen, ein Bot, der jede Seite zehnmal zieht. WordPress versucht in so einem Fall fünfmal im Abstand von einer Sekunde, die Verbindung neu aufzubauen, bevor es aufgibt (check_connection()). Wer das öfter sieht, schaut ins Zugriffsprotokoll des Webservers, bevor er den Hoster beschuldigt.

Schritt 4: kaputte Tabellen reparieren#

Manchmal ist die Verbindung in Ordnung, aber einzelne Tabellen sind beschädigt, etwa nach einem abgebrochenen Schreibvorgang oder vollem Speicher. Dann lädt die Seite teilweise, oder im Protokoll stehen Meldungen wie Table 'wp_options' is marked as crashed and should be repaired (1194) oder Incorrect key file for table (1034). Dafür hat WordPress eine Reparaturseite, die ohne Anmeldung funktioniert und deshalb ausdrücklich freigeschaltet werden muss:

define( 'WP_ALLOW_REPAIR', true );

Danach https://deine-domain.at/wp-admin/maint/repair.php aufrufen. Die Seite bietet zwei Knöpfe: nur reparieren, oder reparieren und optimieren. Sie läuft über alle WordPress-Tabellen mit CHECK TABLE, repariert mit REPAIR TABLE, was nicht in Ordnung ist, und zeigt je Tabelle das Ergebnis. Am Ende steht die Aufforderung, die Zeile wieder aus der wp-config.php zu entfernen, weil die Seite sonst jedem offensteht. Dasselbe tut wp db repair auf der Kommandozeile.

Eine Grenze: REPAIR TABLE repariert laut MySQL-Dokumentation MyISAM-, ARCHIVE- und CSV-Tabellen. Neue WordPress-Installationen legen ihre Tabellen seit Jahren als InnoDB an, und eine beschädigte InnoDB-Tabelle repariert man nicht, man spielt sie aus dem Backup zurück. Wie das Backup aussehen sollte, das dafür taugt, steht in WordPress-Backup.

Schritt 5: wenn nichts davon greift#

Eine Datei wp-content/db.php. Liegt sie dort, lädt WordPress sie statt der eigenen Datenbankklasse (require_wp_db() in wp-includes/load.php). Manche Plugins legen so eine Datei an, für Caching oder Analyse, und lassen sie beim Deinstallieren liegen. Umbenennen, neu laden.

Die Website wurde übernommen. Die WordPress-Dokumentation nennt eine kompromittierte Installation ausdrücklich als mögliche Ursache. Wenn die wp-config.php ein anderes Änderungsdatum hat als erwartet, oder Zeilen enthält, die du nicht kennst, geh die Liste in WordPress gehackt durch, bevor du nur das Passwort einträgst.

Backup zurückspielen. Erst die Datenbank, dann prüfen, ob die Meldung weg ist. Bei vielen Hostern gibt es dafür einen Knopf im Kundenmenü, STRATO nennt seinen BackupControl.

Eine eigene Fehlerseite statt der Standardmeldung#

WordPress lädt eine Datei wp-content/db-error.php, wenn es sie gibt, und zeigt sie statt der eingebauten Meldung. Seit WordPress 7.2 setzt WordPress vorher selbst den Status 500 und die Kopfzeilen, die ein Zwischenspeichern verhindern; bei älteren Versionen gehört http_response_code( 500 ); an den Anfang der Datei. In der Datei dürfen keine WordPress-Funktionen stehen, denn WordPress ist an dieser Stelle noch nicht geladen:

<?php
// wp-content/db-error.php: wird ohne WordPress-Funktionen geladen
header( 'Retry-After: 600' );
?>
<!DOCTYPE html>
<html lang="de">
<head><meta charset="utf-8"><title>Kurz nicht erreichbar</title></head>
<body>
<p>Die Website ist gerade nicht erreichbar. Wir arbeiten daran, bitte versuch es in ein paar Minuten noch einmal.</p>
</body>
</html>

Der Status 500 ist dabei richtig und wichtig. Wer die Fehlerseite mit Status 200 ausliefert, zeigt Google eine leere Seite mit Fehlertext, und das wertet Google als „Soft 404“, als Seite, die es nicht mehr gibt.

Was nicht hilft#

Plugins löschen oder das Theme wechseln. Beides wird erst nach der Datenbankverbindung geladen. Einzige Ausnahme ist die db.php von oben.

WordPress-Dateien neu hochladen. Die Datenbankklasse ist nicht kaputt, sie meldet nur ehrlich, was der Server antwortet. Eine beschädigte wp-config.php erzeugt eine andere Meldung, meist einen PHP-Fehler oder eine weiße Seite.

Das Datenbank-Passwort im Kundenmenü neu setzen, „um sicherzugehen“. Das erzeugt den Fehler, statt ihn zu beheben, solange die wp-config.php den alten Wert hat.

Browser-Cache leeren. Die Meldung kommt frisch vom Server, bei jedem Aufruf.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. „Anmeldung oder Datenbank geht nicht“ ist einer der Fälle, für die es die WordPress-Soforthilfe gibt, Fehlerdiagnose und Reparatur zum Festpreis von 149 €. Danach sorgt die WordPress-Wartung für 49 € im Monat dafür, dass ein Backup da ist, bevor man es braucht, und dass ein Ausfall auffällt, bevor ein Kunde ihn meldet.

Häufige Fragen#

Stand 13.10.2026. WordPress-Quelltext (class-wpdb.php, repair.php, load.php), WordPress-Dokumentation, MySQL-Fehlerreferenz, deutsche WordPress-Übersetzung und die Hilfeseiten von STRATO und World4You an diesem Tag gelesen.