Cómo solucionar MySQL Error 1045: Access Denied for User (guía definitiva 2026)

Son las 2 de la mañana. Tu deploy funcionaba hace cinco minutos. Cambiaste una variable de entorno, reiniciaste el contenedor, y ahora tu aplicación —o tu terminal, o tu script de Python— te devuelve esto:

ERROR 1045 (28000): Access denied for user 'app_user'@'localhost' (using password: YES)

Si llegaste aquí googleando ese mensaje exacto, no estás solo: es uno de los errores más reportados en foros de MySQL, WordPress, Docker y stacks de Python/Flask. La buena noticia es que, aunque el mensaje suena genérico, las causas reales son solo cuatro o cinco, y casi siempre se resuelven en menos de diez minutos si sabes por dónde empezar.

En este artículo vamos a diagnosticar tu caso específico —no solo "probá cambiar la contraseña"— y a resolverlo con los comandos exactos, incluyendo el conflicto de autenticación que MySQL 8 introdujo y que sigue rompiendo proyectos en 2026.

Qué significa realmente el error 1045

Antes de tocar nada, lee el mensaje completo. Trae más información de la que parece:

ERROR 1045 (28000): Access denied for user 'app_user'@'192.168.1.50' (using password: YES)

Tres datos clave:

'app_user'@'192.168.1.50': es la combinación exacta de usuario y host que MySQL intentó autenticar. MySQL no valida solo el nombre de usuario: valida el par usuario + origen de la conexión. Un usuario creado como 'app_user'@'localhost' no puede conectarse desde 127.0.0.1, desde un contenedor Docker, ni desde una IP remota, aunque la contraseña sea correcta.
(using password: YES): te dice si el cliente envió una contraseña. Si ves NO, el problema es que tu aplicación no está enviando ninguna, generalmente por una variable de entorno vacía o mal leída.
(28000): es el SQLSTATE estándar para errores de autorización, común a MySQL, MariaDB y otros motores compatibles.

En resumen: <cite index="2-1">MySQL rechazó la conexión porque la combinación de usuario, host y contraseña no coincidió con ninguna entrada autorizada en la tabla mysql.user</cite>. Dicho de otro modo, el error 1045 siempre se reduce a una de estas cinco causas: <cite index="1-1">una contraseña incorrecta, una cuenta de usuario inexistente, un problema de privilegios, un desajuste de host, o un conflicto del plugin de autenticación en MySQL 8.0</cite>.

Vamos a revisar cada una, en el orden en que conviene descartarlas.

Paso 1: Confirma que el usuario existe (y en qué host)

Conéctate como root o con un usuario administrativo y corre:

SELECT User, Host, plugin FROM mysql.user WHERE User = 'app_user';

<cite index="1-1">Si no se devuelve ninguna fila, el usuario no existe</cite> para ese nombre, sin importar cuántas veces hayas escrito bien la contraseña. Si aparece pero con un Host distinto al que estás usando para conectarte, ahí está tu problema: MySQL trata 'app_user'@'localhost', 'app_user'@'127.0.0.1' y 'app_user'@'%' como cuentas completamente distintas.

Si el usuario no existe, créalo:

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'ContraseñaSegura!';
GRANT ALL PRIVILEGES ON tu_base_de_datos.* TO 'app_user'@'localhost';
FLUSH PRIVILEGES;

Si necesitas acceso desde cualquier host (por ejemplo, porque tu app corre en un contenedor Docker con IP dinámica), usa el comodín %, pero con cuidado en producción:

CREATE USER 'app_user'@'%' IDENTIFIED BY 'ContraseñaSegura!';
GRANT ALL PRIVILEGES ON tu_base_de_datos.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

Truco de diagnóstico rápido: si conectarte con -h 127.0.0.1 funciona pero -h localhost falla (o viceversa), el problema no es la contraseña: es que estás forzando una conexión TCP cuando el usuario solo tiene permiso vía socket Unix, o al revés.

Paso 2: Verifica el conflicto de autenticación de MySQL 8

Esta es, hoy en día, la causa más frecuente en proyectos nuevos —y la que menos gente relaciona con el error 1045 a simple vista. <cite index="1-1">MySQL 8.0 cambió el plugin de autenticación por defecto de mysql_native_password a caching_sha2_password</cite>. El problema: <cite index="3-1">muchos clientes antiguos no soportan el nuevo plugin</cite>, lo que genera un 1045 aunque la contraseña sea correcta, porque el handshake de autenticación falla antes de siquiera comparar credenciales.

Verifica qué plugin usa tu usuario:

SELECT User, Host, plugin FROM mysql.user WHERE User = 'app_user';

Si ves caching_sha2_password y tu cliente es antiguo (PyMySQL desactualizado, un driver PHP viejo, o una librería mysqlclient sin compilar contra OpenSSL reciente), tienes dos rutas:

Opción recomendada: actualiza tu librería cliente. En Python, por ejemplo:

pip install --upgrade pymysql mysqlclient

Opción de compatibilidad temporal: cambia el usuario al plugin legado.

ALTER USER 'app_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'ContraseñaSegura!';
FLUSH PRIVILEGES;

Ojo con este detalle si usas MySQL 8.4 o más reciente: <cite index="4-1">el plugin mysql_native_password está incluido pero deshabilitado por defecto, y ese mismo comando ALTER USER falla con el error 1524 indicando que el plugin no está cargado</cite>. Para habilitarlo hay que reiniciar el servidor con la opción correspondiente activada en el archivo de configuración de mysqld.

Paso 3: Revisa si un usuario anónimo te está robando la conexión

Esta causa es menos conocida pero explica muchos casos de "estoy seguro de que la contraseña es correcta y aun así falla". <cite index="4-1">Cuando dos filas de cuentas podrían coincidir con una conexión, MySQL prioriza primero el valor de Host más específico y luego el de User más específico</cite>. Esto significa que una fila anónima ''@'localhost' puede ganarle a tu cuenta 'app_user'@'%' cuando te conectás desde el host local, porque localhost es más específico que %. MySQL intenta autenticarte contra esa cuenta anónima (normalmente con contraseña vacía), falla, y te devuelve el 1045 sin que tu contraseña real llegue a evaluarse.

Para descartarlo:

SELECT User, Host FROM mysql.user WHERE User = '';

Si aparecen filas, elimínalas (a menos que las uses deliberadamente):

DROP USER ''@'localhost';

Paso 4: Diagnóstico específico para Docker

Si tu error aparece solo al conectar desde un contenedor, el motivo casi siempre es el mismo: <cite index="6-1">si creaste 'myuser'@'localhost' pero te conectas desde un contenedor Docker, en realidad te estás conectando desde la IP del contenedor, no desde localhost</cite>. Docker asigna IPs internas (normalmente en el rango 172.17.0.0/16 por defecto), así que tu usuario necesita permiso para ese host o rango, no para localhost.

Solución rápida en docker-compose.yml + SQL:

CREATE USER 'app_user'@'%' IDENTIFIED BY 'ContraseñaSegura!';
GRANT ALL PRIVILEGES ON tu_base_de_datos.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

Y en tu conexión desde Python (usando el nombre del servicio de MySQL definido en docker-compose.yml, no localhost):

import pymysql
import os

try:
    connection = pymysql.connect(
        host=os.environ.get('DB_HOST', 'mysql'),  # nombre del servicio, no localhost
        port=int(os.environ.get('DB_PORT', 3306)),
        user=os.environ['DB_USER'],
        password=os.environ['DB_PASSWORD'],
        database=os.environ['DB_NAME'],
        connect_timeout=10,
    )
    print("Conexión exitosa")
except pymysql.err.OperationalError as e:
    error_code = e.args[0]
    if error_code == 1045:
        print("Acceso denegado: revisa usuario, contraseña y host")
    elif error_code == 1049:
        print("La base de datos no existe")
    else:
        print(f"Error de conexión: {e}")

Paso 5: Si perdiste el acceso de root

Cuando ni siquiera el usuario root funciona, necesitas el modo de recuperación:

sudo systemctl stop mysql
sudo mysqld_safe --skip-grant-tables &
mysql -u root

Dentro de la sesión:

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'NuevaContraseñaSegura!';
FLUSH PRIVILEGES;

Y para volver a producción:

sudo kill $(sudo cat /var/run/mysqld/mysqld.pid)
sudo systemctl start mysql

Importante: durante el modo --skip-grant-tables, MySQL no valida ninguna contraseña. No dejes el servidor así ni un segundo más de lo necesario, y nunca lo hagas en un servidor expuesto a internet.

El contraargumento: ¿deberías usar `%` como host?

Es tentador resolver todo con 'usuario'@'%' para no volver a pensar en el tema. No lo hagas por defecto. <cite index="1-1">La recomendación de buenas prácticas es usar usuarios de base de datos separados por aplicación, nunca conectar aplicaciones web con la cuenta root, y crear un usuario dedicado con los privilegios mínimos necesarios para cada aplicación</cite>. Además, <cite index="1-1">se recomienda restringir el acceso remoto solo a IPs específicas</cite> cuando sea posible, en vez de abrir la puerta a cualquier host.

El comodín % es razonable en desarrollo local o dentro de una red Docker interna que no está expuesta a internet. En producción, si tu arquitectura lo permite, es mejor listar hosts o rangos específicos.

Resumen práctico según tu perfil

Si sos vibe coder o estás prototipando rápido: lo más probable es que te falte crear el usuario o que estés usando localhost en vez del nombre del servicio Docker. Empieza por el Paso 1 y el Paso 4.
Si mantenés un proyecto en producción con MySQL 8: revisa primero el plugin de autenticación (Paso 2). Es la causa que más sorprende porque "la contraseña es correcta" y aun así falla.
Si administrás infraestructura o Debian/Ubuntu en servidores propios: además de los pasos anteriores, corré siempre FLUSH PRIVILEGES después de editar mysql.user manualmente con UPDATE en vez de ALTER USER o GRANT —de lo contrario MySQL no relee los cambios hasta el próximo reinicio o flush.

El error 1045 parece intimidante por lo genérico del mensaje, pero en la práctica es uno de los errores de MySQL más fáciles de diagnosticar con el método correcto: usuario, host, contraseña, plugin, y privilegios, en ese orden. La próxima vez que te aparezca a las 2am, ya sabés por dónde empezar.

¿Te trabó algo que no está en esta lista? Contame en los comentarios tu mensaje de error exacto y lo agregamos a la guía.

Buscar en este blog

EL JUBILADO INFORMATICO