Contact
← Terug naar kennisbank WORDPRESS

Error establishing a database connection — uitgelegd en opgelost

Dé meest gevreesde WordPress-fout: een blanco pagina met één regel: "Error establishing a database connection". WordPress kan geen verbinding maken met MySQL en weigert iets anders te doen. In 70% van mijn tickets ligt het aan een van vier oorzaken — en met de juiste diagnose vind je in 10 minuten welke. Geen restore nodig, geen plugins uitschakelen, niet eindeloos zoeken op fora. Deze gids legt uit hoe je systematisch te werk gaat.

11 min lezen · Laatst gecheckt:

Wat de bezoeker ziet:

Error establishing a database connection

Meer niet. Geen stack trace, geen aanwijzing wat er fout is. Dat is met opzet zo: WordPress wil geen gevoelige info lekken (zoals MySQL-username of error-detail) richting publiek. De echte details staan in error_log — daar moet je heen. Maar vóórdat we naar logs gaan: dit zijn de vier meest voorkomende oorzaken in volgorde van frequentie.

De vier hoofdoorzaken

1. Verkeerde credentials in wp-config.php (50% van de gevallen)

De klassieker. Vooral na een migratie, hoster-overstap of een handmatige aanpassing van wp-config.php. WordPress probeert verbinding te maken met de credentials in dat bestand:

// In wp-config.php
define( 'DB_NAME',     'database_naam' );
define( 'DB_USER',     'database_user' );
define( 'DB_PASSWORD', 'database_pass' );
define( 'DB_HOST',     'localhost' );
define( 'DB_CHARSET',  'utf8mb4' );
define( 'DB_COLLATE',  '' );

Klopt één van DB_NAME, DB_USER, DB_PASSWORD of DB_HOST niet, dan deze fout. Veelvoorkomende oorzaken:

  • Migratie: nieuwe hoster heeft andere DB-credentials, oude wp-config.php is niet bijgewerkt
  • Wachtwoord-reset: iemand heeft het MySQL-wachtwoord gewijzigd in cPanel maar wp-config niet aangepast
  • Database hernoemd: in het hosting-panel hernoemd, maar wp-config heeft nog de oude naam
  • Tikfout: copy-paste van credentials met onzichtbare karakters of trailing-spatie

2. MySQL-server draait niet (20%)

De server staat uit, herstart, of zit in onderhoud. Op shared hosting zelden door jou veroorzaakt — vaker:

  • Hoster doet onderhoud (typisch 's nachts of in het weekend)
  • MySQL is gecrasht door te weinig geheugen op de server
  • De disk is vol, MySQL kan geen writes meer doen en verbreekt zichzelf
  • Een hardware-issue in het datacenter

3. max_connections bereikt (15%)

MySQL heeft een limiet op gelijktijdige verbindingen (typisch 100–500). Als deze wordt bereikt — bijvoorbeeld door een DDoS-poging, een plugin met memory leaks, of cron-jobs die zich opstapelen — weigert MySQL nieuwe verbindingen.

4. Corrupte database of tabellen (10%)

Tabellen kunnen corrupt raken na een server-crash, bij volle disk, of na een onverwacht reboot tijdens een schrijf-actie. WordPress merkt dit soms tijdens het connect-attempt.

5. Andere — restant 5%

Firewall die poort 3306 blokt, MySQL bind-address verkeerd ingesteld, hoster die het account heeft opgeschort wegens betalingsachterstand, etc.

Diagnose in 5 minuten

Voor je iets aanpast, weet je welk scenario je hebt. Volg deze stappen in volgorde:

Stap 1: Werkt /wp-admin/ ook niet?

Probeer https://voorbeeld.nl/wp-admin/. Twee uitkomsten:

  • Zelfde fout: WordPress kan helemaal niet verbinden → oorzaak 1, 2 of 3 (credentials/server/connections)
  • Andere melding: "One or more database tables are unavailable. The database may need to be repaired." → oorzaak 4 (corrupte tabellen). Spring naar de repair-stap onder.

Stap 2: Check error_log

De echte foutmelding zit in het PHP error log. Locatie hangt af van hoster:

# cPanel: ~/error_log of in publiek-html-root
# DirectAdmin: ~/.../public_html/php-error.log of via control panel
# Plesk: /var/log/plesk/...
# Eigen VPS: /var/log/apache2/error.log of /var/log/nginx/error.log

Wat je zoekt:

# Verkeerde credentials (oorzaak 1):
mysqli_real_connect(): (HY000/1045): Access denied for user 'gebruiker'@'localhost'

# MySQL-server down (oorzaak 2):
mysqli_real_connect(): (HY000/2002): Can't connect to local MySQL server through socket
mysqli_real_connect(): (HY000/2003): Can't connect to MySQL server on '127.0.0.1'

# max_connections bereikt (oorzaak 3):
mysqli_real_connect(): (HY000/1040): Too many connections

# Database bestaat niet (oorzaak 1, variant):
mysqli_real_connect(): (HY000/1049): Unknown database 'verkeerde_naam'

De error-code (1045, 2002, 1040, 1049) vertelt je exact welk scenario je hebt.

Stap 3: Test de credentials los van WordPress

Maak test-db.php in je wp-root:

<?php
$link = mysqli_connect(
    'localhost',         // DB_HOST
    'database_user',     // DB_USER
    'database_pass',     // DB_PASSWORD
    'database_naam'      // DB_NAME
);
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Verbinding werkt! MySQL versie: ' . mysqli_get_server_info($link);
mysqli_close($link);
?>

Open https://voorbeeld.nl/test-db.php. Krijg je dezelfde access-denied? Dan is je wp-config.php fóut. Werkt het? Dan ligt 't aan iets WordPress-specifieks (corrupte options-tabel, plugin die DB-init kapotmaakt). Verwijder dit testbestand direct na gebruik — het bevat je credentials in plain-text.

Fix per scenario

Fix scenario 1: Credentials kloppen niet

Pak de juiste credentials uit je hosting-panel:

  • cPanel: MySQL Databases → daar staan database-namen en users
  • DirectAdmin: MySQL Management → hetzelfde
  • Plesk: Databases → klik door op je database

Reset het wachtwoord als je het kwijt bent:

  • cPanel: MySQL Databases → bij user klikken → Change Password
  • DirectAdmin: MySQL Management → user-edit → password
  • Plesk: Database-user-detail → Change Password

Update wp-config.php met de juiste waarden. Tip: niet retypen maar kopiëren-en-plakken om typos te voorkomen, en check daarna of er geen onzichtbare spaties of newlines in zitten.

Fix scenario 2: MySQL-server is down

Op shared hosting kun je de server niet zelf herstarten. Drie acties:

  1. Check status-pagina van je hoster: status.hoster.nl of hun Twitter / X. Onderhouds-meldingen staan daar vaak.
  2. Mail / bel support: meld de fout, vraag of MySQL down is. Goede hosters reageren binnen het uur.
  3. Wachten: als 't onderhoud is, komt 't binnen een uur of twee terug. Plak intussen een onderhouds-pagina ervoor (zie WordPress maintenance mode zonder plugin).

Eigen VPS: log in via SSH en check:

sudo systemctl status mysql
sudo systemctl restart mysql
df -h    # check of disk niet vol is
free -m  # check geheugen
sudo tail -100 /var/log/mysql/error.log

Fix scenario 3: Te veel connecties

Tijdelijke piek of structureel probleem? Check:

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';
SHOW PROCESSLIST;

Threads_connected dicht bij max_connections = je zit aan de limiet. Mogelijke oplossingen:

  • Tijdelijk: MySQL herstarten (dropt alle bestaande connecties)
  • Verhoog max_connections in my.cnf — alleen op eigen VPS, niet op shared
  • Verlaag wait_timeout zodat idle-connecties sneller vrijkomen
  • Vind de boosdoener: PROCESSLIST toont welke queries lang draaien. Als je één IP veel connecties ziet maken, mogelijk een DDoS-poging — blokkeer in firewall of via Cloudflare

Fix scenario 4: Corrupte tabellen

Activeer WordPress' ingebouwde repair-tool. Voeg toe aan wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

Ga naar https://voorbeeld.nl/wp-admin/maint/repair.php — geen login vereist. Kies "Repair Database" (of "Repair and Optimize" bij twijfel). Wacht tot het klaar is.

Belangrijk: zet de regel direct daarna terug uit, of verwijder 'm. De repair-URL is publiek toegankelijk en je wilt niet dat een aanvaller de tool kan misbruiken.

Werkt de WordPress-repair niet? Dan via SSH:

# Check welke tabel kapot is
mysqlcheck -u user -p database_naam

# Repair (innodb-tabellen kunnen niet via REPAIR TABLE; gebruik mysqlcheck --auto-repair)
mysqlcheck --auto-repair --optimize -u user -p database_naam

Specifieke gevallen die ik vaak zie

Recent gemigreerd, oude wp-config achtergebleven

Klant had via FTP de hele site gekopieerd inclusief wp-config.php. Die wees nog naar de oude database. Fix: nieuwe credentials van de nieuwe hoster ingevuld, klaar. Lees: Website migreren zonder downtime.

DB_HOST is niet 'localhost' bij sommige hosters

Antagonist gebruikt soms localhost, soms een andere hostname. TransIP gebruikt vaak mysql.transip.nl. Bij DigitalOcean Managed Databases is het db-mysql-fra1-XXXX.b.db.ondigitalocean.com. Bij twijfel: hoster-documentatie of mail support.

Site werkte gisteren, ineens niet meer

9 van de 10 keer hosting-onderhoud of MySQL-crash. Wacht 30 minuten, refresh. Niet weg? Mail support. Het is zélden je eigen schuld als alles ineens stopt zonder dat je iets hebt aangepast.

Alleen wp-admin geeft de fout, frontend werkt?

Atypisch maar gebeurt. Vaak een corrupt wp_options-tabel waardoor admin-login faalt maar gecachte frontend-pagina's nog draaien. WP_ALLOW_REPAIR aanzetten en repareren.

Veelgestelde vragen

Mijn site werkt nu weer, hoe voorkom ik dat 't terugkomt?

Drie maatregelen: (1) zorg voor monitoring (UptimeRobot of Better Stack stuurt je een mail bij downtime), (2) hosting met MySQL-failover (managed hosting in plaats van zuinige shared), (3) backup-discipline — dagelijkse off-site backup zodat een crashed-DB niet je hele site kost.

Welke hostings hebben de minste 'database connection'-issues?

In mijn ervaring: managed WordPress-hosting (Kinsta, WP Engine, premium-tier bij Hostnet/TransIP) heeft het minst. Zuinige shared hosting (onder €5/maand) heeft het meest, vooral bij hosts die honderden klanten op één MySQL-instance plakken. Voor €7–10/maand zit je bij betere hosting.

Maakt WordPress vanzelf reconnect na MySQL-restart?

Ja. WordPress probeert per request opnieuw te verbinden. Zodra MySQL weer draait, werkt je site automatisch weer — geen actie nodig.

Kan ik de fout zelf customizen?

Ja. Maak een bestand wp-content/db-error.php met je eigen HTML. WordPress laadt die in plaats van de standaard "Error establishing a database connection". Goed voor een nettere onderhoudspagina met logo en contact-info.

Betekent deze fout dat mijn database is gehackt?

Niet automatisch. De meeste van deze fouten zijn infrastructureel (credentials, MySQL-state), niet kwaadaardig. Krijg je 'm vlak na een verdacht inlog of na het klikken op een link, controleer dan wel de DB-credentials in wp-config (zijn ze veranderd?). Bij twijfel: hack-recovery.