宝塔面板如何开启MySQL远程访问权限_修改访问权限为所有人并放行3306端口
MySQL远程连接需四步:改用户权限为%、放行宝塔防火墙3306端口、云服务器安全组同步放行、修改my.cnf中bind-address为0.0.0.0并重启服务;若仍失败,检查认证插件兼容性。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新! 👉 点此立即查看 👈
MySQL 用户权限没开远程,连都连不上
很多朋友第一次配置远程连接时,都会卡在第一步。默认安装的 MySQL,无论是独立安装还是通过宝塔面板一键部署,其用户权限通常只允许 localhost 或 127.0.0.1 进行本地连接。这时候,外部 IP 尝试连接会直接收到一个明确的拒绝信息:Host 'xxx.xxx.xxx.xxx' is not allowed to connect to this MySQL server。需要明确的是,这并非防火墙在作祟,而是 MySQL 自身的权限机制在发挥作用。
所以,操作顺序至关重要:必须先调整用户权限,再去处理端口放行。顺序一旦颠倒,就是白费功夫。
- 最直观的方法是使用宝塔面板:进入「数据库」模块,找到目标数据库,点击对应的「root」或目标用户名,选择「修改权限」。关键一步是将「访问权限」从默认的
localhost修改为%(这个符号代表允许来自任意主机的连接)。 - 如果在宝塔界面找不到这个选项,那很可能该用户是通过命令行创建的。这时就需要手动执行 SQL 命令来授权:
GRANT ALL PRIVILEGES ON *.* TO 'your_user'@'%' IDENTIFIED BY 'your_password' WITH GRANT OPTION;
FLUSH PRIVILEGES;
- 完成修改后,别忘了重启 MySQL 服务(在宝塔界面点击「重启」按钮),否则新的权限设置不会生效。
宝塔自带防火墙默认拦 3306,得手动放行
解决了权限问题,只是闯过了第一关。宝塔面板自带的防火墙,在「安全」→ 「防火墙」设置中,默认策略是封禁所有非白名单端口,而 MySQL 的标准端口 3306 恰恰就在这个黑名单里。如果不放行,外部的 TCP 连接请求在系统层面就会被拦截,根本传递不到 MySQL 服务进程。
操作路径其实很清晰:
- 在宝塔左侧菜单栏点击「安全」,进入「防火墙」页面,找到「放行端口」选项。
- 输入端口号
3306,协议选择TCP,然后点击「放行」。 - 确认状态栏显示为「已放行」,同时检查一下避免重复添加(重复操作虽不会报错,但确实没有必要)。
- 这里有个常见的“坑”:如果您的服务器部署在阿里云、腾讯云等云平台上,除了宝塔的系统层防火墙,还必须同步在云服务商的安全组规则中放行
3306端口。云平台的安全组是网络层的防护,两者缺一不可。
MySQL 配置文件绑定了 127.0.0.1,远程连不上
到了这一步,权限和端口都畅通了,但连接依然失败?问题可能藏在更深层的配置里。尤其是宝塔 8.x 版本之后集成的 MySQL 8.0+,其配置文件 /www/server/mysql/etc/my.cnf 中,默认可能包含了 bind-address = 127.0.0.1 这一行。这个配置会让 MySQL 服务只监听本地的回环地址,外部网络请求自然也就石沉大海了。
解决方法依然是修改配置并重启服务:
- 使用宝塔的文件管理器,打开上述路径的
my.cnf文件。 - 搜索
bind-address这一项,将其修改为bind-address = 0.0.0.0(或者直接删除这一行,MySQL 默认会监听所有网络接口)。 - 保存文件后,回到宝塔的「软件商店」,找到 MySQL 服务,点击「重启」。
- 如何验证是否生效?可以通过 SSH 连接到服务器,执行命令
netstat -tlnp | grep :3306。如果看到监听地址显示为0.0.0.0:3306或*:3306,才算是大功告成。
连上了但被拒绝,检查是不是密码认证插件不兼容
有时候,连接能建立,但最终登录却被拒绝,并伴随报错:Client does not support authentication protocol requested by server。这通常是 MySQL 8.0 版本引入的新默认认证插件 caching_sha2_password 惹的祸。许多旧的客户端(例如某些老版本的 PHP 扩展或 Na vicat)尚未支持该协议,它们只认传统的 mysql_native_password。
针对此问题,有一个临时的解决方案(但请注意,长期对 root 用户使用此方法不推荐):
- 首先登录到 MySQL 命令行:
mysql -u root -p。 - 执行以下命令修改用户的认证方式:
ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
- 之后别忘了执行
FLUSH PRIVILEGES;刷新权限。 - 需要特别强调的是,如果是为了远程管理,更安全的做法不是直接修改 root 用户的认证方式,而是创建一个新的专用用户并赋予相应权限,这样可以有效降低安全风险。
最后必须提醒的是,打通远程连接固然重要,但安全边界绝不能松懈。将用户权限设为 % 和直接对外暴露 3306 端口,本身就会引入风险。在生产环境中,至少应该将 % 替换为具体的、可信的 IP 地址段。更进一步,考虑通过 SSH 隧道、跳板机或数据库中间件来进行访问隔离,这才是兼顾便捷与安全的实践之道。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
怎么利用 System.err 输出错误流并在控制台中以醒目的颜色标记(取决于终端)
怎么利用 System err 输出错误流并在控制台中以醒目的颜色标记(取决于终端) System err 默认行为不带颜色,终端是否显示颜色取决于自身支持 首先得明确一点:System err 本质上只是 Ja va 标准库里的一个 PrintStream 对象。它本身并不负责“颜色”这种花哨的玩
如何在 Java 中使用 ThreadLocal.remove() 确保在线程池复用场景下不会发生数据污染
如何在 Ja va 中使用 ThreadLocal remove() 确保在线程池复用场景下不会发生数据污染 说到线程池和 ThreadLocal 的搭配使用,一个看似不起眼、实则极易“踩坑”的细节就是数据清理。想象一下,你精心设计的线程池正在高效运转,却因为某个任务留下的“数据尾巴”,导致后续任务
怎么利用 Arrays.asList() 转换出的“受限列表”理解其对 add() 等修改操作的限制
Arrays asList():一个“受限”但实用的列表视图 在Ja va开发中,Arrays asList()是一个高频使用的方法,但你是否真正了解它返回的是什么?一个常见的误解是,它直接生成了一个标准的ArrayList。事实并非如此。 简单来说,Arrays asList()返回的并非我们熟悉
如何在 Java 中利用 try-catch 实现对“软错误”的平滑感知与非侵入式监控日志记录
如何在 Ja va 中利用 try-catch 实现对“软错误”的平滑感知与非侵入式监控日志记录 在 Ja va 开发中,我们常常会遇到一些“软错误”——它们不会让程序直接崩溃,却可能悄悄影响业务的正确性或用户体验。比如,调用第三方 API 时返回了空响应、缓存查询未命中、配置文件里某个非关键项缺失
Django怎么防止Celery任务重复执行_Python结合Redis实现分布式锁
Django怎么防止Celery任务重复执行:Python结合Redis实现分布式锁 你遇到过吗?明明只发了一次任务,后台却执行了两次。这不是代码写错了,而是分布式环境下一个经典的老朋友:多个worker同时抢到了同一个活儿。 为什么Celery任务会重复执行 问题的根源在于竞争。想象一下,多个Ce
- 日榜
- 周榜
- 月榜
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
相关攻略
2015-03-10 11:25
2015-03-10 11:05
2021-08-04 13:30
2015-03-10 11:22
2015-03-10 12:39
2022-05-16 18:57
2025-05-23 13:43
2025-05-23 14:01
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程
热门话题

