Download

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

The server has no account at all whose host part matches the address you’re connecting from, so it refuses you before checking any password. Create an account for that address (or a range of them) and grant it what it needs.

MySQL error 1130· Tested on MySQL 8.4.11 and MariaDB 11.4.13· Updated 11 October 2026

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

What it means

A MySQL or MariaDB account is a user name and a host: 'app'@'localhost', 'app'@'10.0.0.%', 'app'@'%'. When a client connects, the server first looks for any account whose host part matches the client’s address. Error 1130 means there isn’t one, for any user name, so it closes the connection straight away. Your user name and password haven’t been looked at yet.

The address in the message is the one the server saw. With skip_name_resolve on (the official Docker images turn it on) it’s an IP address; otherwise it can be a host name. From your Mac to a server in Docker, it’s the Docker network’s gateway (192.168.215.1 here), not 127.0.0.1.

As soon as some account matches your address, a wrong user or password gets error 1045, access denied instead.

Common causes

  1. A fresh install where only local accounts exist. Package installs on Linux and macOS create root@localhost; connecting from another machine, or from your Mac to a VM, has no account to match.
  2. A Docker container started with MYSQL_ROOT_HOST=localhost (or MARIADB_ROOT_HOST), or a compose file that sets it, so root can only sign in from inside the container.
  3. The application’s account is for a different address: created for localhost or one IP, and the application now runs on another host, container or network.
  4. The client’s address changed: a new office IP, a VPN, a cloud NAT, or Docker giving containers new addresses.

How to fix it

See which hosts the server has accounts for

Connect locally on the server (through the socket, or docker exec into the container):

SELECT user, host, plugin FROM mysql.user ORDER BY user, host;
user	host	plugin
mysql.infoschema	localhost	caching_sha2_password
mysql.session	localhost	caching_sha2_password
mysql.sys	localhost	caching_sha2_password
root	localhost	caching_sha2_password

Here every account is localhost, so any TCP connection from elsewhere gets 1130.

Create an account for the client’s address

Use a dedicated account with only the privileges the application needs, and the narrowest host pattern that works:

CREATE USER 'app'@'192.168.215.%' IDENTIFIED BY '<password>';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'app'@'192.168.215.%';

% matches any address, and 192.168.215.% any address starting with those numbers. Opening root to '%' works too, but it exposes the account with every privilege to the whole network.

Docker

The official images create root@'%' unless MYSQL_ROOT_HOST (or MARIADB_ROOT_HOST) says otherwise, and create MYSQL_USER for '%'. Those variables are read only when the data volume is empty, so on an existing volume, create the account with SQL as above:

docker exec -it <container> mysql -uroot -p

Then check the network side

An account is only half of it. If you then get “Can’t connect to MySQL server”, the server listens only on 127.0.0.1 (bind_address) or a firewall is in the way.

Reproduce it

In a temporary MySQL 8.4.11 container started with MYSQL_ROOT_HOST=localhost, so root@localhost was the only account, connecting from another container through the published port:

mysql -h host.docker.internal -P33991 -uroot -p -e 'select 1'
ERROR 1130 (HY000): Host '192.168.215.1' is not allowed to connect to this MySQL server

Any user name gave the same error. Connecting over TCP from inside the container itself gave Host '127.0.0.1' is not allowed, because with skip_name_resolve on, localhost matches only the Unix socket. After CREATE USER 'seo_app'@'192.168.215.%', that account signed in (current_user() was seo_app@192.168.215.%), and root from the same address now got 1045:

ERROR 1045 (28000): Access denied for user 'root'@'192.168.215.1' (using password: YES)

A temporary MariaDB 11.4.13 container with MARIADB_ROOT_HOST=localhost gave the same error, naming MariaDB:

ERROR 1130 (HY000): Host '192.168.215.1' is not allowed to connect to this MariaDB server

The MariaDB 11.4 client, which tries TLS by default, wrapped it in another error, since the server refused before TLS was set up:

ERROR 2002 (HY000): Received error packet before completion of TLS handshake. The authenticity of the following error cannot be verified: 1130 - Host '192.168.215.1' is not allowed to connect to this MariaDB server

From MariaDB’s own container, a TCP connection to 127.0.0.1 got 1045 instead, because the image creates healthcheck@127.0.0.1. Both containers were removed afterwards.

In Inlet

When the server refuses the connection, Inlet’s connection window shows its message and links to this page. If the database only has accounts for local connections and you can reach its host over SSH, connect through an SSH tunnel (Pro): the server then sees the connection coming from the SSH server, so an account for that machine (often 127.0.0.1 when the database runs there) is enough. Inlet runs the system ssh, so your ~/.ssh/config and SSH agent work.

Inlet: a database client for the Mac

One native app for PostgreSQL, MySQL, SQL Server, SQLite, MongoDB and Redis. It explains errors where they happen, holds your edits until you save them, and keeps production read-only until you say so.

Version 0.1.0 · macOS 26 Tahoe or later · Apple silicon and Intel