Fix: MySQL 'Access denied for user' from an AMXX Plugin

An AMX Mod X plugin that stores data in MySQL — a SQL stats system, a ban manager, a shop — fails to save anything, and the AMXX log shows an access-denied error. This is authentication, not connectivity: the game server reached MySQL fine, but MySQL rejected the username, password, or the host the connection came from. The fix is to line up the credentials the plugin sends with a MySQL account that is actually allowed to log in from the game server.

1. Read the exact error

Find it in addons/amxmodx/logs/. It looks like:

Access denied for user 'csstats'@'gameserver.example.com' (using password: YES)

Every part of that line is a clue. The user is csstats; the host MySQL saw the connection from is gameserver.example.com; and using password: YES means a password was sent (if it says NO, the plugin sent no password at all). MySQL grants are per user and per source host, so a grant for 'csstats'@'localhost' does not authorize 'csstats'@'gameserver.example.com'.

2. Find where the plugin reads its credentials

Most AMXX SQL plugins built on the sqlx module read one shared config:

addons/amxmodx/configs/sql.cfg

It sets the default host, user, password, and database via cvars:

amx_sql_host "127.0.0.1"
amx_sql_user "csstats"
amx_sql_pass "yourpassword"
amx_sql_db "amxx"
amx_sql_type "mysql"

Some plugins override these with their own cvars in their own config — a ban manager often has its own amxbans_sql_* or similar block. Check the plugin's config too, because a plugin-specific value wins over sql.cfg and is easy to overlook. Whatever the plugin actually sends must match a real MySQL account.

3. Fix the credentials or the grant

You have two levers — change what the plugin sends, or change what MySQL allows:

• If the username or password in sql.cfg is simply wrong, correct it. A trailing space or a copied smart-quote breaks the password silently.
• If the credentials are right but the host is wrong in MySQL's eyes, grant access for the host the error names. For a game server connecting to a remote database, MySQL needs a grant for that source host (or a wildcard) — a @'localhost' grant will not cover a remote game server.

The canonical grant, run in the MySQL client on the database host:

GRANT ALL PRIVILEGES ON amxx.* TO 'csstats'@'gameserver.example.com' IDENTIFIED BY 'yourpassword';
FLUSH PRIVILEGES;

Match the user, the source host, and the password to exactly what the plugin sends. If the game server and MySQL are on the same box and the plugin uses 127.0.0.1, grant for 'csstats'@'127.0.0.1' or 'localhost' accordingly — the two are not interchangeable in MySQL.

4. Restart the plugin so it re-reads the config

Changing sql.cfg or the plugin config does not re-authenticate a running plugin. Change the map (or restart the server) so the plugin reconnects with the corrected credentials. Watch the AMXX log on the next connect attempt.

5. Watch the localhost versus 127.0.0.1 trap

MySQL treats localhost and 127.0.0.1 as two different hosts, and this bites people constantly. A connection to localhost on Linux typically uses a Unix socket and matches a grant for 'user'@'localhost'; a connection to 127.0.0.1 uses TCP and matches a grant for 'user'@'127.0.0.1'. If the plugin's amx_sql_host is 127.0.0.1 but you only granted @'localhost', MySQL denies it even though everything is on one box. Either grant for the exact host string the plugin sends, or align amx_sql_host to the host you granted. When in doubt, grant both and let the plugin use whichever it likes. This one detail resolves a large share of same-box access-denied errors that otherwise look inexplicable because "the password is obviously correct."

Troubleshooting

• using password: NO — the plugin sent no password. The amx_sql_pass line is empty, misnamed, or in a config the plugin does not read.
• Works from localhost, fails from the game server — you granted @'localhost' but the connection comes from a different host. Grant for the host in the error.
• Right user, right host, still denied — the password does not match, or you added the grant without FLUSH PRIVILEGES. Reset the password and flush.
• Plugin ignores sql.cfg — it uses its own cvars in its own config file, which override the shared one. Fix those.
• Credentials correct but connection refused (not denied) — that is a different error (errno 111), a networking problem, not authentication. See can't connect to MySQL (111).

Verification

Change the map to force a reconnect and watch addons/amxmodx/logs/ — the access-denied line should be gone. Then exercise the plugin: for a stats plugin, get a kill and check that a row appears in the database; for a ban manager, issue a test ban and confirm the row is written. As an independent check, log in to MySQL from the game server host with the exact same user, host, and password the plugin uses and run a simple query — if that succeeds, the plugin will too, because it authenticates the same way.