Navicat 报错 2013 握手失败？MySQL 远程连接排查全指南

1. 问题现象与背景拆解1.1 这个报错到底在说什么用过 Navicat 连数据库的人大概率都撞见过这个让人头大的提示2013 - Lost connection to server at handshake: reading initial communication packet。它不像密码错误那样直白也不像端口不通那样干脆而是卡在“握手”这个环节——客户端和服务器刚准备打招呼话还没说完连接就断了。先把这句话拆开看。2013是 MySQL 客户端错误码代表“连接在握手阶段丢失”。handshake指的是 MySQL 的连接握手协议客户端连上服务器后服务器会先发一个初始握手包Initial Handshake Packet里面包含协议版本、服务器版本、线程 ID、认证插件、盐值等信息。客户端收到后再回一个认证包。而reading initial communication packet说明问题出在客户端等待读取服务器发来的第一个握手包时连接就没了。换句话说TCP 三次握手可能已经完成但 MySQL 协议层的握手没走完。这就像你拨通了电话对方也接了但还没开口说话线路就断了。问题可能出在网络链路上也可能出在服务器配置上还可能是客户端本身的环境问题。1.2 为什么远程连接特别容易触发本地连localhost或127.0.0.1时数据包走的是回环接口不经过物理网卡也不经过防火墙的 FORWARD 链握手几乎不会出问题。但一旦变成远程连接情况就复杂了数据包要经过客户端防火墙、路由器、运营商网络、服务器防火墙、服务器安全组等多道关卡中间任何一跳出现 MTU 不匹配、丢包、连接跟踪表满、反向路径过滤等情况都可能导致握手包被丢弃服务器端的bind-address、skip-name-resolve、max_connections、connect_timeout等参数配置不当也会让握手阶段直接失败。所以这个报错不是单一原因造成的而是一类“握手阶段连接中断”问题的统称。排查时必须按链路逐段排除不能一上来就改配置。1.3 适合谁来参考这篇内容这篇内容适合三类人一是刚接触 Navicat 和 MySQL 远程连接的新手遇到报错不知道从哪下手二是运维或后端开发需要快速定位是网络问题还是数据库配置问题三是经常在云服务器上部署 MySQL 的从业者想系统梳理一遍远程连接排查思路。下面我会按“先网络、后服务、再客户端”的顺序把每个环节的排查方法和实操命令都写清楚。2. 核心排查思路与方案选型2.1 为什么不能直接改 MySQL 配置很多人一看到这个报错第一反应是去改my.cnf加skip-name-resolve或者调大connect_timeout。这个思路不能说错但顺序不对。因为如果问题出在网络层比如安全组没放行 3306 端口或者服务器防火墙拦截了外部连接那你改再多数据库参数也没用。我习惯的排查顺序是先确认端口通不通再确认握手包能不能到达最后才看 MySQL 自身配置。这个顺序的好处是每一步都能排除一大类原因避免在错误的方向上浪费时间。2.2 三层排查模型我把整个排查过程分成三层层级排查目标常用工具典型问题网络层端口是否可达telnet、nc、Test-NetConnection安全组未放行、防火墙拦截传输层握手包是否完整tcpdump、WiresharkMTU 不匹配、丢包、RST 中断应用层MySQL 是否接受连接mysql 命令行、错误日志bind-address、max_connections、认证插件这个模型的核心逻辑是从外到内逐层缩小范围。网络层不通后面都不用看网络层通了但握手失败就要抓包看是谁先发的 RST如果抓包显示握手包正常到达但 MySQL 没响应那才是数据库配置的问题。2.3 工具选型与替代方案Navicat 本身只是一个图形化客户端它底层调用的还是 MySQL 的 C 客户端库。所以排查时我建议先用命令行工具验证排除 Navicat 自身的问题。Windows 端用Test-NetConnection或telnet测端口用mysql命令行客户端测连接Linux 端用nc -zv测端口用mysql -h测连接用tcpdump抓包macOS 端用nc和mysql命令行抓包用tcpdump。如果命令行能连上只有 Navicat 连不上那问题就在 Navicat 的配置或版本上。如果命令行也连不上那就跟 Navicat 无关专心排查网络和 MySQL。提示Navicat 不同版本对 MySQL 8.0 的认证插件支持不一样。如果你服务器是 MySQL 8.0 且用了caching_sha2_password老版本 Navicat 可能握手失败。这种情况报错可能不是 2013而是 2059但也不排除某些版本会报 2013。3. 网络层排查实操3.1 确认服务器监听地址第一步登录服务器确认 MySQL 到底监听在哪个地址上。执行ss -tlnp | grep 3306或者netstat -tlnp | grep 3306你会看到类似这样的输出LISTEN 0 151 127.0.0.1:3306 0.0.0.0:* users:((mysqld,pid1234,fd22))如果显示的是127.0.0.1:3306说明 MySQL 只监听本地回环地址外部根本连不进来。这时候你需要修改 MySQL 配置文件把bind-address改成0.0.0.0或者注释掉这一行。配置文件通常在/etc/mysql/mysql.conf.d/mysqld.cnf或/etc/my.cnf具体位置可以用mysql --help | grep my.cnf查看。修改后重启 MySQLsystemctl restart mysql再确认监听地址变成0.0.0.0:3306或*:3306。3.2 检查防火墙与安全组确认监听地址没问题后下一步是检查防火墙。Linux 上常见的有iptables、firewalld、ufw三种。用iptables的话执行iptables -L -n | grep 3306如果没有放行规则添加一条iptables -I INPUT -p tcp --dport 3306 -j ACCEPT用firewalld的话firewall-cmd --list-ports firewall-cmd --add-port3306/tcp --permanent firewall-cmd --reload用ufw的话ufw status ufw allow 3306/tcp如果是云服务器还要检查云平台的安全组规则。安全组是独立于服务器防火墙的一层虚拟防火墙很多人只改了服务器防火墙忘了安全组结果还是连不上。安全组里要确保入方向规则允许你的客户端 IP 访问 3306 端口。3.3 从客户端测端口连通性在客户端机器上用以下命令测试端口Windows PowerShellTest-NetConnection -ComputerName 服务器IP -Port 3306如果返回TcpTestSucceeded : True说明端口通。如果返回False说明网络层就不通继续查安全组和防火墙。Linux 或 macOSnc -zv 服务器IP 3306成功会显示succeeded或open。失败会显示Connection refused或超时。注意有些云服务器默认禁 ping所以ping通不代表端口通ping不通也不代表端口不通。测端口一定要用telnet、nc或Test-NetConnection不要用ping下结论。4. 传输层抓包与握手分析4.1 什么时候需要抓包如果端口测试显示通但 Navicat 还是报 2013那就说明 TCP 连接建立了但 MySQL 握手包出了问题。这时候光看应用层日志不够需要在服务器端抓包看握手包到底有没有到达以及是谁先断开的连接。抓包命令tcpdump -i any -nn port 3306 -w mysql_handshake.pcap然后在客户端发起一次 Navicat 连接抓完后用 Wireshark 打开mysql_handshake.pcap分析。4.2 握手包分析要点在 Wireshark 里过滤mysql协议你会看到握手过程。正常流程是客户端发 SYN服务器回 SYN-ACK客户端回 ACK服务器发 MySQL Initial Handshake Packet客户端发 Handshake Response服务器回 OK 或 Error。如果第 4 步的包没出现或者出现后紧接着一个 RST说明服务器端主动断开了连接。常见原因有MySQL 的max_connections满了服务器直接拒绝新连接host_cache表满了DNS 反解失败导致连接被拒服务器负载过高connect_timeout超时中间网络设备如负载均衡、WAF主动拦截。如果第 4 步的包出现了但客户端没收到那可能是 MTU 问题。MySQL 初始握手包通常不大但如果服务器版本信息很长加上 TCP 选项可能超过路径 MTU导致分片丢失。4.3 MTU 问题与 MSS 调整MTU 问题在跨运营商、跨地域的远程连接中很常见。表现是小包能通大包丢失握手阶段刚好卡在服务器发握手包的时候。排查方法在客户端用ping发大包测试ping -M do -s 1472 服务器IP-M do表示禁止分片-s 1472是数据部分大小加上 28 字节的 IP 和 ICMP 头总共 1500 字节。如果提示Frag needed或超时说明路径 MTU 小于 1500。解决办法有两种一是调整客户端或服务器网卡的 MTU二是调整 MSS。Linux 上可以用iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu或者在 MySQL 服务器上把网卡 MTU 调小ip link set dev eth0 mtu 1400提示MTU 问题不一定每次都触发它跟网络路径有关。有时候换个网络环境就好了这种“时好时坏”的现象往往就是 MTU 或丢包导致的。5. MySQL 服务端配置排查5.1 bind-address 与 skip-name-resolve前面提到bind-address要改成0.0.0.0但还有一个参数容易忽略skip-name-resolve。MySQL 在收到连接时默认会尝试把客户端 IP 反解成主机名用于匹配user表里的Host字段。如果 DNS 反解很慢或失败握手阶段就会超时。在my.cnf的[mysqld]段加上skip-name-resolve这样 MySQL 就不会做 DNS 反解直接用 IP 匹配。代价是user表里的Host字段不能用主机名只能用 IP 或%。改完后重启 MySQL再试连接。5.2 max_connections 与连接数检查如果服务器连接数满了新连接会在握手阶段被拒绝。查看当前连接数SHOW STATUS LIKE Threads_connected; SHOW VARIABLES LIKE max_connections;如果Threads_connected接近max_connections就需要调大上限或者排查是谁占用了大量连接。临时调大SET GLOBAL max_connections 500;永久生效要改配置文件[mysqld] max_connections 500同时检查wait_timeout和interactive_timeout如果设置过大空闲连接会一直占着名额。一般建议wait_timeout设为 600 秒左右。5.3 用户权限与 Host 匹配MySQL 的用户权限是userhost的形式。如果你创建的用户是testlocalhost那从远程连就会失败。需要创建或修改为test%或test客户端IP。查看当前用户SELECT user, host FROM mysql.user;授权远程访问CREATE USER test% IDENTIFIED BY 密码; GRANT ALL PRIVILEGES ON *.* TO test%; FLUSH PRIVILEGES;如果是 MySQL 8.0还要注意认证插件。默认是caching_sha2_password老版本 Navicat 可能不支持。可以改成mysql_native_passwordALTER USER test% IDENTIFIED WITH mysql_native_password BY 密码; FLUSH PRIVILEGES;5.4 错误日志与 host_cache 排查MySQL 错误日志里通常会有握手失败的记录。日志位置可以用SHOW VARIABLES LIKE log_error;查看日志tail -f /var/log/mysql/error.log如果看到Host xxx is blocked because of many connection errors说明该 IP 被host_cache拉黑了。原因是之前有太多连接错误MySQL 会暂时拒绝该 IP 的连接。解决办法FLUSH HOSTS;然后检查为什么会有大量连接错误可能是密码错误、认证插件不匹配或者客户端反复重试。6. 客户端与 Navicat 侧排查6.1 Navicat 连接配置检查Navicat 连接配置里有几个地方容易填错主机名/IP确认填的是服务器公网 IP不是内网 IP端口默认 3306如果服务器改了端口要对应修改用户名/密码注意大小写和特殊字符SSH 隧道如果勾了 SSH 隧道但 SSH 配置不对也会报握手失败。如果用了 SSH 隧道Navicat 会先建 SSH 连接再通过隧道连 MySQL。这时候报错可能来自 SSH 层而不是 MySQL 层。可以先用命令行 SSH 登录服务器再在服务器上mysql -h 127.0.0.1 -u test -p测试确认 MySQL 本身没问题。6.2 Navicat 版本与 MySQL 8.0 兼容性Navicat 老版本如 Navicat for MySQL 10、11对 MySQL 8.0 的caching_sha2_password支持不好握手阶段可能直接失败。解决办法有两个一是升级 Navicat 到 15 以上版本二是把 MySQL 用户认证插件改成mysql_native_password。如果你用的是 Navicat Premium 17基本不存在这个问题它已经支持 MySQL 8.0 的所有认证方式。但要注意Navicat 17 需要对应的许可证免费版功能有限制。6.3 客户端网络环境与代理设置有些公司网络会强制走代理或者有 SSL 拦截。Navicat 默认不走系统代理但如果系统装了某些网络加速工具可能会影响连接。可以尝试关闭系统代理直接连换一个网络环境如手机热点测试检查 hosts 文件是否有错误映射。另外Windows 上的vc 2013运行库缺失也可能导致 Navicat 无法正常调用底层库。虽然这个报错不直接指向运行库但如果 Navicat 启动就报错或者连接时崩溃可以检查一下Microsoft Visual C 2013 Redistributable是否安装。7. 常见问题速查表与避坑经验7.1 问题速查表现象可能原因排查命令解决办法端口不通安全组/防火墙拦截nc -zv IP 3306放行 3306 端口端口通但报 2013bind-address 限制ss -tlnp | grep 3306改 bind-address 为 0.0.0.0时好时坏MTU 不匹配ping -M do -s 1472 IP调小 MTU 或 clamp MSS连接数满max_connections 太小SHOW STATUS LIKE Threads_connected调大 max_connections认证失败认证插件不匹配SELECT user,host,plugin FROM mysql.user改 mysql_native_passwordIP 被拉黑host_cache 满FLUSH HOSTS清理并排查错误原因DNS 反解慢未开 skip-name-resolve查看错误日志加 skip-name-resolve7.2 避坑经验经验一先命令行后 Navicat。很多人一上来就折腾 Navicat改连接配置、重装软件结果问题根本不在 Navicat。先用mysql命令行客户端测能连上说明 Navicat 配置有问题连不上说明网络或 MySQL 有问题。这一步能省掉大量无效操作。经验二云服务器安全组和服务器防火墙是两回事。我见过太多人只改了iptables忘了云平台安全组或者只改了安全组忘了服务器防火墙。两个都要检查缺一不可。经验三MySQL 8.0 的认证插件是重灾区。如果你从 MySQL 5.7 升级到 8.0或者新装了 8.0老客户端连不上很正常。要么升级客户端要么改认证插件没有第三条路。经验四抓包是终极手段。当所有配置都检查过还是不行抓包能告诉你真相。是服务器没发握手包还是发了但客户端没收到还是中间有 RST一看便知。不要靠猜要靠数据。经验五MTU 问题容易被忽略。尤其是跨地域、跨运营商的连接MTU 不匹配会导致握手包丢失。表现是“有时候能连有时候不能”或者“小数据量能连大数据量断”。遇到这种玄学问题先测 MTU。7.3 一个真实排查案例之前帮朋友排查过一个类似问题他在云服务器上装了 MySQL本地 Navicat 连的时候报 2013。我让他先telnet端口通的再mysql命令行连也通的但 Navicat 就是不行。后来发现他 Navicat 里填的主机名是服务器的内网主机名而他的 Navicat 版本会先做 DNS 解析解析失败后握手超时。改成公网 IP 后问题解决。这个案例说明有时候问题不在服务器而在客户端的一个小配置。排查时要有耐心逐项确认不要放过任何细节。8. 远程连接稳定性优化建议8.1 服务端参数调优如果远程连接经常不稳定可以在my.cnf里加几个参数[mysqld] bind-address 0.0.0.0 skip-name-resolve max_connections 500 connect_timeout 30 wait_timeout 600 interactive_timeout 600connect_timeout是握手超时时间默认 10 秒网络差可以调到 30 秒。wait_timeout和interactive_timeout控制空闲连接回收避免连接数堆积。8.2 使用 SSH 隧道替代直连如果公网直连 3306 不安全或者不稳定可以用 SSH 隧道。Navicat 自带 SSH 隧道功能配置好 SSH 主机、端口、用户名、密码或密钥后Navicat 会通过 SSH 连到服务器再在服务器内部连 MySQL。这样 3306 端口不需要对公网开放安全性更高也能绕过一些网络限制。SSH 隧道配置要点SSH 主机填服务器公网 IPSSH 端口默认 22如果改了要对应MySQL 主机填127.0.0.1因为隧道是在服务器内部转发MySQL 端口填 3306。8.3 定期检查与监控远程连接问题往往不是一次性的而是会反复出现。建议定期检查MySQL 错误日志有没有异常Threads_connected是否接近上限host_cache有没有被拉黑的 IP服务器网络有没有丢包。可以用简单的脚本定时检查或者用监控工具。关键是早发现早处理不要等业务断了才去查。9. 个人实操体会这个报错我前后遇到过不下十次每次原因都不一样。有一次是安全组没放行有一次是bind-address没改有一次是 MySQL 8.0 认证插件问题还有一次是 MTU 不匹配。最坑的一次是服务器host_cache满了把客户端 IP 拉黑了但错误日志里没明显提示最后靠FLUSH HOSTS才解决。我的体会是不要迷信单一解决方案要建立排查框架。网络层、传输层、应用层一层一层过每层都有对应的工具和命令。只要框架清晰再复杂的问题也能定位。另外Navicat 本身的问题也不少。不同版本对 MySQL 8.0 的支持差异很大如果条件允许尽量用较新版本。如果只能用老版本那就把服务器认证插件改成mysql_native_password兼容性最好。最后分享一个小技巧如果你不确定问题出在哪先在服务器上tcpdump抓包同时在客户端发起连接。抓包文件用 Wireshark 打开看握手包走到哪一步断了。这个方法虽然有点“重”但最直接能省掉大量猜测时间。