【MySQL 错误 1130】Host ‘xxx‘ is not allowed to connect to this MySQL server —— 原因分析与完整解决方案

问题描述

在本地 Windows 开发机(主机名为 WIN-OGL3PGSJRF9)上通过 Java 应用连接远程 MySQL 服务器时,报错如下:

1130 - Host 'WIN-OGL3PGSJRF9' is not allowed to connect to this MySQL server

该错误导致应用无法连接数据库,开发调试中断。

错误原因

MySQL 的用户权限系统由 用户名(user) + 允许连接的主机(host) 共同组成。例如:

  • 'root'@'localhost':仅允许本机连接
  • 'app'@'192.168.1.%':允许某网段连接
  • 'user'@'%':允许任意主机连接

而当前 MySQL 服务器中 没有为你的客户端主机(WIN-OGL3PGSJRF9 或其 IP)创建对应的访问权限,因此拒绝连接。

⚠️ 注意:即使你使用的是正确的用户名和密码,只要 host 不匹配,MySQL 也会直接拒绝连接,并抛出 Error 1130

解决方案(四步走)

第一步:登录 MySQL 服务器(需 root 权限)

在 MySQL 所在服务器上执行:

mysql -u root -p

第二步:查看现有用户权限

SELECT host, user FROM mysql.user;

典型输出

+-----------+-------+

| host | user |

+-----------+-------+

| localhost | root |

| 127.0.0.1 | root |

+-----------+-------+

你会发现:没有 % 或你的客户端 IP,所以外部连接被拒。

第三步:创建允许远程连接的用户(推荐方式)

 切勿直接开放 root@%(生产环境高危!)
方式 A:创建专用用户(安全推荐)
-- 创建用户:允许从任意 IP 连接 CREATE USER 'myapp'@'%' IDENTIFIED BY 'StrongPass123!'; -- 授权指定数据库(按需调整) GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'myapp'@'%'; -- 刷新权限 FLUSH PRIVILEGES;
方式 B:仅允许特定 IP(更安全)
-- 假设你的 Windows 客户端 IP 是 172.20.10.95 CREATE USER 'myapp'@'172.20.10.95' IDENTIFIED BY 'StrongPass123!'; GRANT ALL PRIVILEGES ON mydb.* TO 'myapp'@'172.20.10.95'; FLUSH PRIVILEGES;
小技巧:可用 '172.20.10.%' 匹配整个子网。

第四步:检查 MySQL 绑定地址(bind-address)

默认情况下,MySQL 可能只监听 127.0.0.1,导致外部无法访问。

  1. 编辑配置文件:
    • Linux: /etc/mysql/mysql.conf.d/mysqld.cnf
    • Windows: my.ini(MySQL 安装目录下)
  2. 找到并修改:
# 注释掉或改为 0.0.0.0 bind-address = 0.0.0.0

重启 MySQL 服务:

# Linux sudo systemctl restart mysql # Windows net stop mysql && net start mysql

验证连接是否成功

在你的 Windows 开发机上测试:

# 测试端口连通性 telnet 172.20.10.95 3306 # 测试 MySQL 登录(替换为你的用户和 IP) mysql -h 172.20.10.95 -u myapp -p

如果能成功登录,说明问题已解决!

安全最佳实践

  1. 不要开放 root@%,尤其在公网环境;
  2. 为每个应用创建独立数据库用户;
  3. 限制访问 IP 范围(如 172.20.10.%);
  4. 配合防火墙,仅开放必要 IP 访问 3306 端口;
  5. 使用强密码,并定期轮换。

总结

步骤操作
1️⃣登录 MySQL 服务器
2️⃣检查 mysql.user 表权限
3️⃣创建 'user'@'%' 或 'user'@'IP' 用户
4️⃣修改 bind-address = 0.0.0.0 并重启服务
5️⃣应用中使用 IP 连接数据库

如果你也遇到过类似问题,欢迎在评论区留言交流!
觉得本文有帮助?别忘了 点赞 + 收藏 + 关注,持续分享更多实战开发经验!

Read more

云原生混合架构 K8s 自动化部署平台

云原生混合架构 K8s 自动化部署平台

本项目构建了一套 “本地虚拟化 + 阿里云公有云” 的混合云原生 K8s 自动化部署平台,核心目标是落地安全隔离、自动化交付、弹性稳定且可监控的运维体系,完整覆盖从基础环境搭建到云原生集群部署、服务交付、混合云网络打通的全流程。 1 环境搭建 本阶段核心目标是通过虚拟化技术创建3个节点的本地集群(1个master节点+3个node节点),为后续云原生环境测试、CI/CD组件部署提供基础环境。 1.1 环境规划 节点角色CPU内存磁盘IP规划(桥接模式)master节点(master)2核8G50G192.168.0.200node1节点(node1)2核8G50G192.168.0.201node2节点(node2)2核8G50G192.168.0.202node3节点(node3)2核8G50G192.168.0.203阿里云ECS(Jenkins)2核4G40G弹性公网IP阿里云ECS(Gitlab)2核8G40G弹性公网IP阿里云ACR容器镜像服务----阿里云SLS日志服务----

By Ne0inhk

OpenClaw gateway start 报 401 Invalid API key?一个环境变量的坑

今天折腾了半小时,终于搞明白为什么 openclaw gateway start 一直报 HTTP 401: Invalid API key,而 openclaw gateway run 却能正常工作。 记录一下,免得以后又踩。 问题现象 用 openclaw gateway run 前台运行,一切正常,能正常对话。 但换成 openclaw gateway start(systemd 后台服务),就报错: HTTP 401: Invalid API key 明明配置文件里 API key 写得好好的,为什么会这样? 原因分析 run 和 start 的区别: * run — 前台运行,

By Ne0inhk
如何在分布式环境中实现高可靠性分布式锁

如何在分布式环境中实现高可靠性分布式锁

目录 一、简单了解分布式锁 (一)分布式锁:应对分布式环境的同步挑战 (二)分布式锁的实现方式 (三)分布式锁的使用场景 (四)分布式锁需满足的特点 二、Redis 实现分布式锁的基本思路(粗糙实现版本) (一)实现步骤 (二)基本代码展示 (三)上述实现的缺陷 三、健壮分布式锁聚焦 (一)误删问题的分析 问题说明 解决方案 具体实现步骤 具体代码实现 (二)原子性保证 问题场景 解决方案:使用 Lua 脚本 设置锁并设置过期时间(原子操作) 释放锁(原子操作) Java 调用 Lua 脚本 (三)超时自动解锁 问题描述 传统解决方案 改进方案:

By Ne0inhk