局域网MySQL连接失败，绝大多数情况下是bind-address监听地址、用户授权host、防火墙规则、3306端口连通性这四个环节中的一个或多个配置不当，按网络层→配置层→权限层→防火墙层的顺序排查，多数问题能在十分钟内定位。
局域网mysql连接不上怎么办，先从网络层动手
很多人一上来就改MySQL配置文件，改完重启发现还是连不上，白忙一场，连接数据库服务器失败，第一步永远是确认两台机器之间能不能“说上话”。
用ping测试基本连通性
在客户端机器上打开命令行工具,输入：
ping 192.168.1.100把IP换成你数据库服务器的实际内网地址，如果ping不通，说明两台机器根本不在同一网络，或者服务器IP地址有误，检查一下服务器IP是否变了、网线是否松动、Wi-Fi是否连到了访客网络。
用telnet测试3306端口
ping通了不代表MySQL能连，端口才是关键,继续在客户端执行：
telnet 192.168.1.100 3306如果光标停在左上角闪烁，或者出现一堆乱码字符，说明端口是通的，问题出在MySQL自身配置，如果提示“无法打开到主机的连接”或“Connection refused”，说明端口不通，要么MySQL没在监听,要么被防火墙拦了。
局域网内mysql连接超时，多半是网络层卡住了
超时和拒绝是两种完全不同的症状，超时意味着数据包发出去没回应，像是敲门没人应；拒绝则是有人开门但把你关在门外，局域网内mysql连接超时，常见原因是服务器防火墙丢弃了请求包，而不是MySQL本身有问题，这时候直接跳到防火墙排查环节,别在MySQL配置上浪费时间。
mysql数据库连接失败怎么解决，关键在于监听和授权
网络层通了，接下来看MySQL自己愿不愿意“开门迎客”，MySQL默认只监听127.0.0.1，也就是只允许本机访问，这个设计在安全上没问题,但局域网连接失败往往就栽在这里。
bind-address设为127.0.0.1，等于只接待本地访客
找到MySQL配置文件，Linux一般在/etc/mysql/mysql.conf.d/mysqld.cnf或/etc/my.cnf，Windows一般在安装目录下的my.ini，打开后搜索bind-address：
bind-address = 127.0.0.1只要看到这一行，无论IP是什么,都改成：
bind-address = 0.0.0.00.0.0表示监听所有网卡接口,改完重启MySQL服务：
systemctl restart mysql或者：
service mysql restartskip-networking：大门直接锁死
有些配置文件里会出现skip-networking这个参数，它意味着MySQL完全关闭TCP/IP网络通信，只允许本地通过socket连接，局域网想连上，必须把这一行注释掉,在行首加个即可：
# skip-networking用户授权表里的host字段，决定谁能进门
配置改好了，端口也监听了，但客户端连接时提示Access denied for user，问题就出在授权，MySQL的用户由user和host两个字段共同决定身份，root@localhost只在本地有效。
登录服务器MySQL：
mysql -u root -p然后执行：
SELECT user, host FROM mysql.user;如果看到root对应的host只有localhost，那远程肯定连不上,需要创建一个允许局域网访问的用户：
CREATE USER 'appuser'@'192.168.1.%' IDENTIFIED BY '你的密码';
GRANT ALL PRIVILEGES ON . TO 'appuser'@'192.168.1.%';
FLUSH PRIVILEGES;168.1.%表示允许192.168.1网段的所有机器连接，也可以写成具体IP，比如'appuser'@'192.168.1.50'，更安全，如果只想让某个IP连,就别用通配符。
防火墙和杀毒软件，最容易踩的坑
配置和授权都对了，还是连不上，十有八九是防火墙在从中作梗，行业共识认为，局域网MySQL连接问题中，防火墙导致的占比相当高，而且症状极其迷惑有时候本地一切正常,换台机器就超时。
Linux服务器：检查iptables与firewalld
CentOS/RHEL系列用firewalld的话,执行：
firewall-cmd --permanent --add-port=3306/tcp
firewall-cmd --reloadUbuntu/Debian系列用UFW的话,执行：
sudo ufw allow 3306/tcp如果服务器装了宝塔面板或类似管理工具，还要检查面板自带的防火墙和安全组,这里经常有第二层拦截。
Windows服务器：检查入站规则
Windows服务器自带防火墙默认拦截入站连接，打开“控制面板 → Windows Defender防火墙 → 高级设置 → 入站规则”，找到“新建规则 → 端口 → TCP → 特定本地端口”，填入3306，选择“允许连接”，保存即可，如果服务器有多个网卡，记得在“作用域”里限定允许的远程IP,避免暴露到公网。
内网其他机器装了安全软件也要排查
客户端机器上的杀毒软件偶尔也会拦截MySQL连接，尤其是某些国产安全软件默认开启“网络防护”功能，如果服务器端怎么调都不行，试着在客户端暂时关闭安全软件，或者把MySQL的IP加入白名单,再试一次连接。
常见错误码对照表，一眼定位问题
在Navicat、DBeaver、命令行等客户端工具中，错误码能直接告诉你问题方向,下面是局域网场景下最常见的四个错误码：
| 错误码 | 含义 | 常见原因 | 解决方向 |
|---|---|---|---|
| 2003 | 无法连接到MySQL服务器 | 端口不通、防火墙拦截、MySQL未启动 | 检查端口和防火墙 |
| 1045 | 访问被拒绝 | 用户名密码错误、host授权不对 | 检查授权表和密码 |
| 1130 | 主机不允许连接 | 用户host字段限制 | 修改host授权 |
| 10061 | 目标机器主动拒绝 | MySQL未监听、bind-address不对 | 修改监听配置 |
10061在Windows上很常见，提示“由于目标计算机积极拒绝，无法连接”，意思就是MySQL服务可能根本没启动，去服务管理器看看MySQL服务的状态，右键“启动”再说。
mysql连接navicat失败10061，一个真实场景
前阵子帮一个朋友的实验室调试，他们用Navicat连局域网里的MySQL，报错就是mysql连接navicat失败10061，服务器是Windows 10，MySQL 8.0,客户端是同一层的另外一台电脑。
排查过程是这样的：
- 先ping通了,没问题。
- telnet 3306,提示拒绝。
- 检查MySQL服务，发现服务没有启动,启动后发现3306还是不通。
- 检查配置文件，发现
bind-address被设置成了0.0.1，改成0.0.0后重启服务。 - 再telnet,通了。
- 用Navicat连接，又报1045，检查发现用户授权只有localhost，创建新用户并授权后,顺利连上。
整个过程花了二十分钟，问题一环套一环，典型的连环坑，局域网mysql连接不上，往往不是单一原因,而是多个配置叠加导致的结果。
局域网自建MySQL和云数据库怎么选，这些问题值得提前想
如果局域网内经常遇到连接问题，并且团队规模不大，不少人会纠结要不要把数据库迁到云上，局域网自建MySQL和云数据库怎么选，关键看你的场景：如果数据敏感度极高、要求完全内网隔离，自建仍是首选；如果希望省去运维精力，云数据库的VPC内网连接更省心，但云数据库同样有白名单和账号权限配置，逻辑和自建大同小异,只是把防火墙换成了安全组。
Q&A：局域网mysql连接不上怎么办
问：局域网mysql连接不上怎么办，改了bind-address还是不行？
改完bind-address后必须重启MySQL服务，否则配置不生效，另外确认配置文件改的是正确的文件，MySQL 8.0在Ubuntu上通常有两个配置文件，一个在/etc/mysql/目录下，一个在/etc/mysql/mysql.conf.d/目录下，后者的优先级更高，修改后执行SHOW VARIABLES LIKE 'bind_address';确认当前值，如果显示0.0.0说明配置已生效，若仍然连不上，检查防火墙是否放行3306端口,以及客户端telnet是否能通。
问：为什么局域网内mysql连接超时但ping能通？
ping走的是ICMP协议，MySQL走的是TCP协议，两个完全不同的通道，ping通只说明网络层通，TCP层可能被防火墙丢弃或拦截，这种情况多数是服务器防火墙的INPUT链默认策略为DROP，规则中又没有放行3306端口导致的，检查iptables -L -n输出，看是否有针对3306端口的ACCEPT规则,没有就加上。
问：root用户能远程登录MySQL吗？
能，但不建议，root在MySQL中拥有最高权限，一旦客户端机器被攻破，攻击者可以直连数据库删库跑路，更稳妥的做法是创建专用账号，只授权业务需要的数据库和操作权限，host字段限定到具体IP或网段，如果确实需要root远程登录，可以用GRANT ALL PRIVILEGES ON . TO 'root'@'192.168.1.%' IDENTIFIED BY '密码' WITH GRANT OPTION;,但事后建议立即修改root密码并收窄host范围。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/566273.html
