佚格麻瓜连着好几个晚上在群里帮人看同一个报错，内容几乎一模一样：刚装好的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 和相近报错对照，避免排查方向跑偏
我整理了一张对比表，这几个错误在论坛和群里被问得最多，很多人分不清。
| 错误号 | 典型报错内容 | 卡在哪一层 | 一句话原因 |
|---|---|---|---|
| 2002 | Can't connect to local MySQL server through socket '/tmp/mysql.sock' | 本地socket层 | 客户端找不到MySQL的socket文件，常见于服务没起来或socket路径不对 |
| 2003 | Can't connect to MySQL server on 'x.x.x.x' | TCP连接层 | 网络不通、端口没监听、防火墙或安全组拦截 |
| 1045 | Access denied for user 'root'@'x.x.x.x' | 账号密码认证层 | 用户或密码错误 |
| 1130 | Host 'x.x.x.x' is not allowed to connect to this MySQL server | 来源主机授权层 | 客户端来源IP不在该账号的host授权范围内 |
注意看2003和1130的区别：报2003的时候，数据包根本没到MySQL服务手里，多半是端口监听、安全组、防火墙的问题；报1130的时候，TCP三次握手已经完成，MySQL已经开口跟你说话了，只是说了一句"我不认识你"。所以看到1130，第一反应不应该是去开防火墙，而是去查授权。
这个区分非常关键。你在排查的时候如果方向错了，后面所有步骤都会跟着错。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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
``