Error establishing a database connection: cómo solucionarlo

Pocas cosas ponen los pulso a cien como ese Error establishing a database connection en pantalla. Significa, ni más ni menos, que WordPress no consigue hablar con la base de datos MySQL o MariaDB, y sin esa conversación el sitio entero se queda mudo. La web cae. Entera. Ahora bien, tranquilidad: en la mayoría de los casos se arregla en pocos minutos. Vamos a ver qué es exactamente este error, por qué suele aparecer y cómo se resuelve paso a paso, empezando por el archivo más delicado de toda tu instalación.

¿Qué significa el error «Error establishing a database connection»?

Casi todo lo que muestr tu WordPress vive en una base de datos. Entradas, páginas, comentarios, ajustes de plugins, usuarios… todo ahí. Los archivos PHP del núcleo, los temas y los plugins están en el servidor, sí, pero sin la base de datos el CMS se queda sin nada que mostrar. Así que cuando lees ese mensaje en el navegador, la traducción es simple: WordPress intentó conectarse y la conexión fracasó. Algún motivo hubo.

Ojo, porque conviene distinguirlo de otros fallos que se le parecen. Si solo una parte del sitio falla (wp-admin carga pero el frontend no, por ejemplo), la causa probablemente no es la misma que cuando la web completa está caída. Y hay otro detalle útil: comprueba si el error afecta también a otros sitios en el mismo servidor. Si varios caen a la vez, el problema casi seguro no está en tu instalación, sino en el servidor de bases de datos.

Causas más comunes del error de conexión a la base de datos

Llevamos años diagnosticando esto en RedServicio y, la verdad, las causas acaban repitiéndose. Casi siempre es uno de estos puntos:

• Credenciales incorrectas en wp-config.php: el nombre de la base de datos, el usuario, la contraseña o el host no coinciden con los reales. Pasa muchísimo tras una migración o al cambiar de proveedor de hosting.
• Servidor de base de datos caído: el servicio MySQL o MariaDB se ha detenido, o está sobrecargado por un pico de tráfico (o un ataque).
• Base de datos corrupta: una actualización que se quedó a medias o un fallo de disco pueden dañar tablas críticas.
• Límite de conexiones superado: en hostings compartidos, el proveedor limita las conexiones simultáneas por usuario. Y si te pasas, error.
• Usuario sin permisos suficientes: el usuario existe, pero no tiene privilegios sobre la base de datos que le toca.
• Host incorrecto: usar «localhost» cuando la base de datos está en un servidor remoto, o al revés.

El primer paso es averiguar cuál de estas te toca. El siguiente apartado te ayuda a descartar la más frecuente de todas.

Verificar las credenciales en wp-config.php

Abramos el archivo. wp-config.php está en la raíz de tu instalación de WordPress y guarda los cuatro valores que el CMS usa para conectarse. Entra por FTP o desde el gestor de archivos de tu panel de hosting, localízalo y busca este bloque:

Ahora compara cada valor con los datos reales de tu base de datos. Los tienes en cPanel (sección «Bases de datos MySQL»), en Plesk o en el panel de tu proveedor. Hay tres detalles que traen de cabeza a más de uno:

1. Espacios y comillas: revisa que no se haya colado ningún espacio dentro de las comillas, y que sean comillas simples rectas, no tipográficas. Sí, ese detalle tonto rompe la conexión.
2. Prefijos del hosting: muchos proveedores añaden un prefijo al usuario y al nombre (algo como «cpaneluser_wp001»). Deben coincidir exactamente, letra por letra.
3. DB_HOST: en la mayoría de hostings compartidos es «localhost», pero hay proveedores que usan una IP o un dominio interno tipo «mysql.tudominio.com». Si tienes dudas, la documentación de tu proveedor lo dirá.

¿Y si la contraseña está mal pero no puedes recuperarla? Lo más práctico, en mi experiencia, es no pelearse con la vieja: crea un usuario nuevo de base de datos desde el panel de hosting, dale todos los privilegios sobre la base de datos y actualiza DB_USER y DB_PASSWORD en wp-config.php con esos valores nuevos. Guarda, recarga la web. Si el error desaparece, ya sabías dónde estaba el problema. Eran las credenciales.

Cómo reparar una base de datos corrupta en WordPress

A veces las credenciales están bien. Las revisas dos veces, las pegas de nuevo, y el error sigue ahí. En ese caso la causa más habitual suele ser una base de datos dañada, y para eso WordPress trae una herramienta propia. Hay que activarla a mano: añade esta línea al final de wp-config.php, justo antes del comentario que avisa de dejar de editar.

define(‘WP_ALLOW_REPAIR’, true);

Guardas el archivo y entras en https://tudominio.com/wp-admin/maint/repair.php. Ahí verás dos opciones: «Reparar base de datos» y «Reparar y optimizar base de datos». Yo cogería la segunda, ya que de paso mejoras el rendimiento. Ojo con el tiempo: en bases de datos grandes puede tardar varios minutos, así que no cierres la pestaña a medias. Espera al mensaje de finalización.

Importante: cuando acabe, borra la línea WP_ALLOW_REPAIR del wp-config.php. No es opcional. Esa página se abre sin autenticación, así que dejarla activa es dejar la puerta abierta.

¿Y si la herramienta nativa no arregla nada? Pues toca ir a phpMyAdmin: seleccionas la base de datos, marcas todas las tablas y eliges «Reparar tabla» en el menú desplegable de abajo. Si tienes acceso SSH al servidor, mejor aún. Ejecuta directamente mysqlcheck -u usuario -p –repair nombre_base_datos; en corrupciones severas suele funcionar donde lo anterior falló. Y si nada de esto da resultado, no te compliques: restaura el último backup limpio. Es exactamente por esto que siempre insistimos en tener copias automáticas diarias.

Soluciones a nivel de servidor: MySQL, host y recursos agotados

Habrá veces en que el error no aparezca siempre, sino a ratos, sobre todo tras un pico de tráfico. Cuando eso pasa, el problema casi nunca está en WordPress. Está en el servidor. Estas son las comprobaciones que más resultados dan:

• Verifica que MySQL está en ejecución. En un VPS o servidor dedicado, conecta por SSH y ejecuta systemctl status mysql (o mysqld, según la distribución). Si está caído, reinícialo con systemctl restart mysql y mira los logs en /var/log/mysql/error.log para saber por qué se cayó.
• Revisa los límites de recursos. Un plan de hosting compartido saturado puede tumbar MySQL sin avisar. Consulta el uso de CPU y RAM en cPanel o en tu panel de nube; si superas el 80% de forma recurrente, toca plantearse subir de plan.
• Ajusta max_connections. ¿Los logs muestran «Too many connections»? Aumenta el valor en my.cnf (de 100 a 300, por ejemplo) y reinicia MySQL.
• Comprueba el host de la base de datos. En la mayoría de hostings funciona localhost, pero algunos proveedores usan una URL interna del tipo mysql.servidor.com. Un valor equivocado en db_host produce justo este error, ni más ni menos.
• Contacta al soporte del hosting. Si MySQL se cae una y otra vez sin causa aparente en un plan compartido, puede que el culpable sea otro sitio del mismo servidor. Eso ya le toca resolverlo al proveedor, no a ti.

Eso sí, si el servidor se queda corto una y otra vez, los parches no bastan. La solución definitiva pasa por migrar a un VPS o a un hosting gestionado con recursos garantizados.

Conclusión: cómo evitar el error de conexión a la base de datos en el futuro

El error Error establishing a database connection asusta, pero casi siempre se resuelve con un diagnóstico ordenado: credenciales en wp-config.php, reparar las tablas dañadas y mirar cómo está el servidor MySQL. Una vez recuperada la web, toca prevenir. Backups automáticos diarios de archivos y base de datos, un plugin de caché para aligerar la carga sobre MySQL, WordPress y plugins al día, y vigilar los recursos del plan antes de que se agoten. Nada espectacular. Pero con esa rutina, este error deja de ser una emergencia a las tres de la mañana y se convierte en una anécdota que resuelves en minutos. Y si en algún momento el problema rebasa lo que puedes hacer tú solo, en RedServicio (redservicio.net) encontrarás ayuda profesional para recuperar tu web y dejarla blindada frente a futuras caídas.