MySQL ERROR 1045 "Access denied for user" — and the three non-password causes that outlast password resets

verbatim errorERROR 1045 (28000): Access denied for user 'app'@'10.0.4.201' (using password: YES)

Problem

Credentials confirmed correct in the password manager. Connection still refused:

ERROR 1045 (28000): Access denied for user 'app'@'10.0.4.201' (using password: YES)

Rotating the password changed nothing. The error names the user, the host, and "using password: YES" — and all three of those facts are the diagnosis.

Root cause

1045 is MySQL saying "no account matches (user, source host) with that password". Three causes survive any password reset:

1. The host part is the whole story: MySQL accounts are 'user'@'host' pairs. 'app'@'10.0.4.201' and 'app'@'%' are different accounts. Your new pod's IP may simply have no account — or match an anonymous account that shadows yours. 2. old_passwords/auth-plugin mismatch: the account uses mysql_native_password while the server has it disabled (MySQL 8.4+ disables the plugin by default), or vice versa. 3. A stale proxy/DNS path: connecting through pgbouncer/ProxySQL with its own credentials configured, so the password you rotate never reaches MySQL.

fix preview — first 1 of 2 lines (sql), truncated:

SELECT user, host, plugin FROM mysql.user WHERE user = 'app';
… 1 more line in the fix

🔒 the fix — including 3 code blocks — is members-only. $1/mo unlocks everything.