🚨 MySQL Error: 'ERROR 1130 (HY000): Host is not allowed to connect to this MySQL server' — Cause, Fix, and Troubleshooting Guide

Overview

ERROR 1130 (HY000) is returned during the handshake when no account in mysql.user matches the client’s host, so the server rejects the connection before authentication:

ERROR 1130 (HY000): Host '10.0.5.23' is not allowed to connect to this MySQL server

Unlike ERROR 1045 (wrong password), 1130 means the server found no user@host grant for where you are connecting from. It is an authorization-by-origin failure, common right after moving an app to a new subnet, pod network, or NAT gateway.

Symptoms

• A client on a new host/IP is refused while existing hosts still connect.
• root@localhost works on the box but remote clients get 1130.
• The connecting IP in the message is a gateway/NAT address, not the pod’s own IP.
• Reverse-DNS names appear where you expected raw IPs (or vice-versa).

Common Root Causes

1. No account for that host pattern

The user exists as 'app'@'localhost' but not for the remote network:

SELECT user, host FROM mysql.user WHERE user='app';

+------+-----------+
| user | host      |
+------+-----------+
| app  | localhost |
+------+-----------+

A connection from 10.0.5.23 matches nothing here.

2. Server bound to localhost only

bind-address = 127.0.0.1 accepts only loopback; remote clients never even reach an auth check for their host and are refused.

3. skip_name_resolve mismatch

With skip_name_resolve=ON, grants must use IPs/CIDR, not hostnames. A grant to 'app'@'appserver.local' is dead if name resolution is off.

4. NAT / proxy rewriting the source IP

The server sees the gateway IP, not the client’s, so a per-pod-IP grant never matches.

How to diagnose

List which hosts are actually permitted for the user:

SELECT user, host FROM mysql.user ORDER BY user, host;

Check the bind address and name-resolution setting:

SHOW VARIABLES LIKE 'bind_address';
SHOW VARIABLES LIKE 'skip_name_resolve';

Confirm the IP the server sees (run from the client, then check the message): the address quoted in the 1130 error is authoritative — grant to exactly that.

Fixes

Create/grant the account for the correct host or CIDR pattern:

CREATE USER 'app'@'10.0.%' IDENTIFIED BY 'strong-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app'@'10.0.%';
FLUSH PRIVILEGES;

Allow the server to accept remote connections (bind to all or a specific interface):

[mysqld]
bind-address = 0.0.0.0
skip_name_resolve = ON

Restart MySQL for bind-address/skip_name_resolve changes to take effect. When skip_name_resolve=ON, always grant to IPs/CIDR:

RENAME USER 'app'@'appserver.local' TO 'app'@'10.0.5.23';

What to watch out for

• Grant to the IP shown in the 1130 message, not the pod’s advertised IP — behind NAT they differ.
• bind-address = 0.0.0.0 exposes MySQL to the network; pair it with a firewall/security group, never a public % grant with a weak password.
• Avoid 'app'@'%' as a lazy fix; scope to the smallest CIDR that covers your app tier.
• Enable skip_name_resolve for predictable, fast auth, but then purge all hostname-based grants or they stop matching.

Related

• ERROR 1045: Access denied for user — the password-failure error you hit once the host is allowed.
• ERROR 1129: Host is blocked (max_connect_errors) — a host that was allowed but got blocked after failed handshakes.
• ERROR 2003: Can’t connect to MySQL server (TCP) — network-layer failures to rule out first.