WordPress no conecta a la base: diagnóstico por capas
- Comprueba si el problema afecta otros servicios
- Revisa wp-config.php de forma privada
- Prueba con una herramienta apropiada
- Permisos y límites de recursos
- Reparación de tablas solo si corresponde
- Si ocurrió tras una migración
- Después de resolver
- Preguntas frecuentes
- En pocas palabras
- Conclusión
- Fuentes y documentación
Cuando WordPress no puede conectarse a su base de datos, revisa disponibilidad del servidor, dirección, credenciales y permisos. Cambiar todo a la vez o reinstalar WordPress puede complicar un problema que tiene una causa concreta.
Anota cuándo comenzó y si hubo una migración, cambio de contraseña, actualización o agotamiento de recursos.
Comprueba si el problema afecta otros servicios
En un hosting compartido, revisa el estado del proveedor y consulta soporte si corresponde. En un servidor propio, verifica que la base esté activa y tenga espacio.
sudo systemctl status mysql --no-pager
df -hEl nombre del servicio puede ser otro, como mariadb. Si la base está en un contenedor o equipo remoto, estos comandos deben adaptarse al entorno correcto.
Revisa wp-config.php de forma privada
Comprueba DB_NAME, DB_USER, DB_PASSWORD y DB_HOST. No copies el archivo completo a un foro ni crees una versión descargable para pedir ayuda.
El host no es siempre localhost. En Docker puede ser el nombre del servicio; en un proveedor, una dirección específica. Además, localhost y 127.0.0.1 pueden utilizar mecanismos de conexión distintos según cliente y configuración.
Prueba con una herramienta apropiada
Si tienes un cliente autorizado en el mismo entorno de la aplicación:
mysql -h HOST_DE_LA_BASE -u USUARIO_DE_LA_APP -p NOMBRE_DE_LA_BASEReemplaza los marcadores y escribe la contraseña en el prompt. La prueba debe recorrer una ruta comparable a la de WordPress; conectarte como administrador local no demuestra que la cuenta de la aplicación funcione.
Si recibe “acceso denegado”, revisa autenticación y permisos. Si no llega al servicio, investiga nombre, puerto, red y disponibilidad.
Permisos y límites de recursos
La cuenta necesita las operaciones apropiadas para su base, no control global de todas las bases. Si el proveedor cambió límites o credenciales, verifica sus datos actuales.
El servicio puede rechazar conexiones por saturación, disco lleno u otra condición. Reiniciarlo sin revisar registros puede ocultar la evidencia y no resolver el origen.
Reparación de tablas solo si corresponde
No todos los errores de conexión significan corrupción. Primero comprueba que puedes autenticar y acceder al servidor. Si hay evidencia de tablas dañadas, utiliza un procedimiento compatible con su motor y conserva respaldo.
WP_ALLOW_REPAIR habilita una función temporal de reparación en WordPress. Si la utilizas, conoce su alcance y retira la definición al terminar. No dejes herramientas de mantenimiento abiertas indefinidamente.
Si ocurrió tras una migración
Comprueba que la importación haya terminado, que el prefijo de tablas sea el correcto y que el destino utilice la base esperada. Un archivo wp-config.php de otro entorno puede apuntar a recursos distintos.
No borres tablas “duplicadas” antes de identificar qué instalación las utiliza. Conserva las copias hasta verificar el sitio y su recuperación.
Después de resolver
Prueba páginas, administración y una operación de escritura controlada. Revisa logs y confirma que no quedó una contraseña de demostración o un archivo de prueba.
Si hubo exposición de credenciales, rotarlas es un trabajo adicional al arreglo de la conexión.
Preguntas frecuentes
¿Debo cambiar siempre DB_HOST a localhost?
No. Usa la dirección que corresponda a tu arquitectura o proveedor. El valor correcto depende del entorno.
¿Conectarme como root demuestra que WordPress puede entrar?
No. Debes comprobar la cuenta y la ruta de conexión de la aplicación.
¿Una reparación de tablas arregla cualquier error de conexión?
No. Disponibilidad, red y autenticación deben investigarse antes de suponer corrupción.
En pocas palabras
El error de conexión puede deberse a disponibilidad, dirección o autenticación, no solo a una contraseña. Una comprobación por capas evita cambios innecesarios y exposición de configuración.
Conclusión
Repite la consulta y el acceso web después de corregir la causa. Retira diagnósticos temporales y conserva un registro privado del cambio sin contraseñas ni archivos de configuración completos.
Para continuar, revisa Cómo instalar WordPress paso a paso: guía rápida y WordPress en Docker (ARM y x86): guía completa con docker-compose, Dockerfile y PHP.ini.