MySQL远程连接报错1130：原因排查与授权配置详解

连着好几个晚上在群里帮人看同一个报错，内容几乎一模一样：刚装好的MySQL，或者刚上线的服务器，本机用mysql -uroot -p登录完全正常，换成Navicat、换成另一台机器、换成云服务器上的服务，就甩来一行通红的结果：

text复制ERROR 1130 (HY000): Host '192.168.31.14' is not allowed to connect to this MySQL server

老实说，mysql报错1130是我见过出现频率最高的数据库连接故障之一，它和密码错误、端口不通经常被混为一谈，但本质完全不同。这篇文章就围绕这个报错，把排查路径和解决方案讲透：为什么本机能连、远程连不上，报1130时问题到底出在哪个环节，以及最稳妥的修复方式是什么。内容对刚接触MySQL的新手，和已经维护过一阵子数据库但没仔细抠过授权机制的后端开发，都有参考价值。

1. 先分清1130和2003、1045：这个报错卡在了哪一层

1.1 一句话先理解1130的本质

MySQL的1130报错，核心意思是：MySQL服务器收到了你的TCP连接请求，也完成了MySQL协议层面的握手，但在校验"你从哪台机器来"的时候，发现这个来源主机不在授权范围内，于是直接拒绝。

它不是网络不通，不是MySQL服务没启动，不是用户名密码错，更不需要去检查3306端口是否被占用。它就是一道权限关卡：连接来源的主机，没有被当前账号在mysql.user表里的host字段覆盖到。

很多人在这一步会犯一个方向性错误：以为是防火墙拦截、以为是端口没开、以为是服务配置有问题，于是在安全组、firewalld、my.cnf里来回折腾，最后才发现问题出在授权表上。1130这个报错只要出现，说明从客户端机器到MySQL服务器的网络通道已经建立起来了，真正拦下你的，是MySQL自己。

1.2 和相近报错对照，避免排查方向跑偏

我整理了一张对比表，这几个错误在论坛和群里被问得最多，很多人分不清。

注意看2003和1130的区别：报2003的时候，数据包根本没到MySQL服务手里，多半是端口监听、安全组、防火墙的问题；报1130的时候，TCP三次握手已经完成，MySQL已经开口跟你说话了，只是说了一句"我不认识你"。所以看到1130，第一反应不应该是去开防火墙，而是去查授权。

这个区分非常关键。你在排查的时候如果方向错了，后面所有步骤都会跟着错。

2. 完整排查链路：从网络连通一路看到MySQL授权表

2.1 端口检查：看到1130时其实TCP已经通了

既然1130本身就说明TCP层已经通了，为什么还要强调端口检查？因为排查讲究的是流程感，你不能跳步，而且在你最终确认是1130之前，必须先排除掉"是不是我看到的报错根本就不是1130，而是2003"。生产环境里，客户端显示什么报错，往往受到客户端工具、代理层、中间件的影响，最好从源头确认一次。

从客户端发起telnet测试：

bash复制telnet 192.168.1.10 3306

如果端口通，屏幕上可能出现一串MySQL版本信息（比如5.7.36-log开头的内容），或者直接进入一个黑屏等待状态。如果端口不通，会提示Connection refused或者一直卡在Trying...。这时候你看到的就已经不是1130的语境了，要转去查bind-address、防火墙、云安全组这些网络相关项。

Windows上可以用PowerShell执行：

powershell复制Test-NetConnection 192.168.1.10 -Port 3306

一个比较容易忽略的细节：尽量从真正出问题的客户端机器上测试，而不是登录到MySQL服务器本机测试。本机测本机，走的是回环，即便服务器上的防火墙规则有问题也可能被绕过去，测出来的结果不能代表业务方的真实网络路径。

2.2 进MySQL内部看授权表

端口确认没问题、报错确实是1130之后，接下来做的事非常直接：本机登录MySQL，查看授权表。

bash复制mysql -uroot -p

登录后执行：

sql复制SELECT user, host, plugin, account_locked FROM mysql.user;

正常情况下你会看到类似下面的内容：

text复制+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
| root             | localhost | caching_sha2_password |
| mysql.session    | localhost | caching_sha2_password |
| mysql.sys        | localhost | caching_sha2_password |
+------------------+-----------+-----------------------+

这里的关键信息是：root用户对应的host只有localhost。localhost不是指"你本机"，而是指"通过本地socket方式发起的连接才能匹配到这一条"。

客户端从另外一台机器通过TCP协议访问时，MySQL看到的来源主机是那个客户端的IP（比如192.168.31.14），授权表里没有任何一条host记录等于这个IP，也没有%这样的通配符兜底，于是1130就出现了。

这里补一句授权表的匹配机制：MySQL在判断一个连接能否通过时，会同时看user和host两个字段。host字段支持精确IP（192.168.1.10）、网段通配符（192.168.1.%）、任意主机（%），甚至IP掩码格式。服务器会按照"最具体优先"的方式在内存里匹配，所以如果同一个用户既有localhost又有%两条记录，两条不会冲突，本机连接走localhost那一条，远程连接走%那一条。

2.3 bind-address和skip-networking两个干扰项

有相当一部分情况，报的不是1130而是2003，但很多人贴出来的问题描述写着"远程连接不上"，实际一翻配置才发现是bind-address写死了回环地址。在排查1130之前，最好把这两个变量也看一眼，确认没有藏在暗处的绊脚石。

在MySQL命令行里执行：

sql复制SHOW VARIABLES LIKE 'bind_address';
SHOW VARIABLES LIKE 'skip_networking';
SHOW VARIABLES LIKE 'port';

结果会告诉我们三件事：

• skip_networking如果是ON，MySQL只接受本机socket连接，TCP连接直接不可用，这时候远程访问哪怕端口看着通，实际也会被拒绝。
• bind_address如果显示127.0.0.1，MySQL的3306端口只监听了本机回环，外部机器的请求根本进不来。
• port当然就是确认服务实际监听的端口，有人会在配置文件里改过端口但自己忘了。

如果bind_address确实被设成了127.0.0.1，又确实需要远程访问，需要修改MySQL配置文件。以Linux常见的配置路径为例，可能位于/etc/mysql/mysql.conf.d/mysqld.cnf或/etc/my.cnf，把这一行改成：

ini复制bind-address = 0.0.0.0

然后重启MySQL服务，再执行一次SHOW VARIABLES LIKE 'bind_address'确认生效。很多人在这一步踩坑：改了配置文件不重启，然后反复怀疑自己改错了地方。

但要再次强调，bind-address设成127.0.0.1时会报2003，不是1130。如果已经稳定复现1130，说明bind-address这一关已经过了，MySQL的端口已经能被外部机器访问到，接下来重心还是要回到授权表上。

2.4 别忘了确认客户端来源IP到底是多少

排查授权问题时，有一个信息必须拿到准确值：MySQL服务器视角下，客户端连接到底来自哪个IP。看起来很简单，实际经常出错。

举例：你在办公室用Navicat连接公司内网的MySQL服务器，本机IP看的是192.168.31.14，但办公室出口做了NAT，服务器看到的可能是公司出口公网IP，比如118.31.xx.xx。如果你照着本机IP去授权，授权永远不生效，因为服务器看到的来源IP跟你以为的完全不是一回事。

确认来源IP最靠谱的办法，是让一个已经能连上MySQL的账号先登录进去，然后执行：

sql复制SHOW PROCESSLIST;

结果里每一行的Host列会显示客户端IP:端口，比如192.168.31.14:52341，这个IP就是MySQL服务器视角下正在连接你的客户端的真实来源。

如果当前没有任何能远程登录的账号，也可以临时在服务器本机用TCP方式连一下自己，指定用服务器的内网IP而不是默认的socket连接，然后再去SHOW PROCESSLIST里看来源：

bash复制mysql -h 192.168.1.10 -uroot -p

这样得到的Host列就能反推出，当业务机器通过网络访问这台MySQL时，服务器会把这个连接识别成哪个IP。

3. 解决方案：从临时放行到规范化授权

3.1 救急：给root开放远程连接

网上很多教程到这里就直接给出答案，把root账号的host改成一个%一了百了。这种做法我明确不推荐用于生产，但如果是在本地开发环境、临时测试环境，或者业务本身就在内网隔离网段，救急是够用的。

MySQL 5.7及更早的老版本，可以用一条GRANT语句完成创建并授权：

sql复制GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '你的密码' WITH GRANT OPTION;
FLUSH PRIVILEGES;

这条SQL的含义是：创建一个用户名为root、允许从任意主机登录、密码为你的密码的账号，并授予所有库所有表的全部权限。

需要注意的是，这里IDENTIFIED BY后面的密码，会和MySQL系统里已有的root密码互相独立。如果你本机密码是abc123，这里指定def456，那么远程用def456才能登录，这不是bug，是授权表里出现了两条独立的记录。所以建议直接把密码写成和本机root一致的密码，省得自己绕晕。

MySQL 8.0之后语法有变化，不能用上面的老写法，我在3.4节单独细说。

3.2 推荐：新建专用账号并限定来源

真正长期使用的方式，是放弃"让root远程登录"这种偷懒思路，新建一个只给指定业务或指定网段使用的账号，指定最小权限。这样即使账号密码泄露，损失范围也被限制在单一业务库内，不会一上来就是最高权限裸奔。

给运维同事或自己远程管理用的账号，可以这样创建：

sql复制CREATE USER 'opsadmin'@'192.168.31.%' IDENTIFIED BY 'YourStrongPass!2024';
GRANT ALL PRIVILEGES ON *.* TO 'opsadmin'@'192.168.31.%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

192.168.31.%表示允许整个192.168.31.0/24网段访问。如果你们办公室出口IP固定，建议直接写死成单个IP：

sql复制CREATE USER 'opsadmin'@'118.31.20.33' IDENTIFIED BY 'YourStrongPass!2024';
GRANT ALL PRIVILEGES ON *.* TO 'opsadmin'@'118.31.20.33' WITH GRANT OPTION;
FLUSH PRIVILEGES;

如果是给业务系统连接数据库用的应用账号，连ALL PRIVILEGES都不应该给，按需授最基础的增删改查权限就够了：

sql复制CREATE USER 'app_user'@'192.168.31.%' IDENTIFIED BY 'AppPass!2024';
GRANT SELECT, INSERT, UPDATE, DELETE ON shopdb.* TO 'app_user'@'192.168.31.%';
FLUSH PRIVILEGES;

这样授权还有个好处：当某一天需要隔离问题，你可以直接从mysql.user里看到账号归属和来源范围，而不是面对一堆root@%无从下手。

3.3 特殊场景：直接改mysql.user表

除了GRANT方式，确实还存在一种直接修改系统授权表的做法。它通常出现在特殊场景下，比如root密码忘记后通过--skip-grant-tables模式进入MySQL做修复，或者手里的账号没有GRANT权限但又需要调整授权记录。

操作大概是这样：

sql复制UPDATE mysql.user SET host = '%' WHERE user = 'root' AND host = 'localhost';
FLUSH PRIVILEGES;

这条SQL会把原来仅限localhost的root账号来源改成允许任意主机。执行FLUSH PRIVILEGES是必须的，原因我在3.5节讲清楚。

但说句实话，这种操作在生产环境我不推荐作为首选。把root@localhost直接UPDATE成root@%，等于把你本地最稳的管理入口也一并改掉了，本地socket连接匹配的host记录从localhost变成了%，一些依赖localhost特殊处理的场景可能会受牵连。更稳妥的做法是保持原来的root@localhost不动，另外CREATE一条root@'%'或者新建独立账号。CREATE USER、GRANT能做的事，就不要去手改系统表。

3.4 MySQL 8.0变更点：GRANT写法与认证插件

MySQL 8.0之后，有两个改动让很多旧教程直接失效，如果你照着老文章执行，反而会报别的错。

第一个改动是：不再支持在GRANT语句里用IDENTIFIED BY直接设置密码。8.0里必须先用CREATE USER创建账号，再单独用GRANT授权：

sql复制CREATE USER 'root'@'%' IDENTIFIED BY '你的密码';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

如果你在8.0里执行老式的GRANT ALL ... IDENTIFIED BY...，MySQL会直接语法报错。

第二个改动是默认认证插件变成了caching_sha2_password。新版本的Navicat、mysql客户端一般没有问题，但一些老版本客户端会报类似这样的错误：

text复制Authentication plugin 'caching_sha2_password' cannot be loaded

或者其他版本的报错：

text复制ERROR 1251 (08004): Client does not support authentication protocol requested by server; consider upgrading MySQL client

这个问题容易和1130混在一起排查，因为都发生在远程连接阶段。解决方式是把那个账号的认证插件改成老客户端能识别的mysql_native_password：

sql复制ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '你的密码';
FLUSH PRIVILEGES;

需要说明：mysql_native_password在新版MySQL中已经逐渐走入弃用轨道，更规范的长期做法是升级客户端。但如果业务系统里某个老模块短期没法升级，改认证插件是比较务实、也是最常采用的过渡方案。

3.5 flush privileges什么时候才必须手动执行

FLUSH PRIVILEGES是很多人知其然不知其所以然的一条语句。它做的事情是让MySQL重新读取授权表，把改动加载进内存里的权限缓存。

这里有一个关键规则：

• 通过CREATE USER、GRANT、REVOKE、ALTER USER这些官方账号管理语句修改授权信息时，MySQL会立刻检测到变更并自动重新加载授权表，不需要手动执行FLUSH PRIVILEGES。
• 通过INSERT、UPDATE、DELETE直接修改mysql.user、mysql.db等系统表时，MySQL不会自动感知，必须手动执行FLUSH PRIVILEGES或重启服务，否则改动不会生效。

所以3.3节里直接UPDATE mysql.user表的场景，后续必须带上FLUSH PRIVILEGES。而3.1、3.2里的GRANT方式，即使不手动FLUSH也会生效，手动执行一遍也无害，只是多一层保险。

另外有人习惯改完授权后直接重启MySQL让它生效，这是完全没有必要的操作。重启一次生产数据库的成本和风险，远比执行一条FLUSH PRIVILEGES高。能用语句解决的，别随便重启。

4. Docker与云服务器场景下的特殊处理

4.1 Docker官方镜像初始化时的root账号范围

现在很多人用Docker装MySQL，结果装完在宿主机上用Navicat一连，同样报1130，而且排查思路经常被"容器环境特殊"带偏。其实容器场景下，1130的原因和裸机安装基本一样，仍然是授权表里没有匹配的来源主机。

以Docker官方mysql:8.0镜像为例，容器首次启动时，如果只设置了MYSQL_ROOT_PASSWORD，没有额外设置MYSQL_ROOT_HOST环境变量，官方初始化脚本通常只会创建root@localhost账号，远程连接自然全被挡在外面。

推荐的做法是在docker run时直接加上MYSQL_ROOT_HOST：

bash复制docker run -d --name mysql8 \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD='RootPasswd123!' \
  -e MYSQL_ROOT_HOST='%' \
  -e MYSQL_DATABASE=appdb \
  mysql:8.0

MYSQL_ROOT_HOST='%'的意思是告诉初始化脚本：额外创建一个允许任意主机连接的root账号。如果你只想让某个网段访问，把%替换成具体网段或IP即可。

如果容器已经建好了，不想删掉重来，补救方式就是进入容器内部执行常规SQL：

bash复制docker exec -it mysql8 mysql -uroot -p

进去之后，按第3章里说的思路，要么给root加%，要么创建一个专用账号授权，SQL逻辑完全一样，没有因为容器而产生新机制。

在此基础上观察一下宿主机的端口映射情况也很重要：

bash复制docker port mysql8

4.2 端口映射只绑定了127.0.0.1的坑

Docker容器跑起来了，MySQL容器内部也允许远程了，但外部还是连不上，这时候要怀疑宿主机上的端口映射是不是绑错了地方。很多人执行了类似下面的命令启动容器：

bash复制docker run -d --name mysql8 -p 127.0.0.1:3306:3306 mysql:8.0

127.0.0.1:3306:3306的意思是：把容器的3306端口映射到宿主机的127.0.0.1回环地址上。这种情况下，只有宿主机自己能访问这个3306端口，局域网内其他机器访问宿主机IP的3306端口，连接会被kernel直接拒绝，表现为Connection refused，这在错误分类上属于2003，不是1130。

排查方法很简单，在宿主机上执行：

bash复制ss -lntp | grep 3306

如果看到的是127.0.0.1:3306，说明端口被绑在回环上。想要让外部访问，需要改成0.0.0.0:3306:3306重新运行容器，或者调整端口绑定规则。docker端口映射这一层和MySQL授权是两条独立的链路，先确保宿主机端口能被外部访问到，再去谈MySQL内部的授权问题，顺序不能乱。

4.3 安全组和防火墙为什么不是1130的排查重点

云服务器场景下，很多人一遇到数据库连不上，第一反应就是阿里云/腾讯云安全组没放行，或者Linux里firewalld拦了3306。事实上如果客户端已经报出1130，说明你的请求已经穿过安全组、穿过防火墙、穿过宿主机的端口映射，精确触达了MySQL服务本身。安全组和防火墙在这一步已经放行了，否则你看到的会是连接超时、Connection timed out或者10060，绝不可能是1130。

所以排查1130时，不要把时间浪费在安全组上。真正需要关注的是：

• MySQL服务是否监听了正确的网卡和端口；
• 授权表里有没有覆盖客户端来源的host记录；
• 如果有密码，密码是否正确；
• 如果用的是MySQL 8.0，老客户端是否支持新的认证插件。

这四件事查完，1130基本就水落石出了。反向再提醒一句：如果远程真的连不上，但报的是2003超时，而你的MySQL授权完全没问题，那时候再去检查安全组和防火墙，对症下药。

5. 一次因root放开%引发的生产事故复盘

5.1 事故经过，为什么我坚持不要随便开放root

讲一个真实发生过的事。之前有个朋友公司上线一套内部系统，为了方便远程维护，DBA把root账号开放成了'%'，密码设置得也比较弱，同时安全组把3306端口对公网完全放行。两天后，他们发现数据库里出现了一