★ FEATURED ARTICLE 简介一份解决Linux云服务器上MySQL无法通过Navicat远程连接的排错资料针对连接初始化阶段报错“2013-Lost connection to MYSQL server”的问题适合后端开发、运维人员或刚接触服务器配置的学习者。文档按完整流程展开先检查数据库安装状态再定位并修改MySQL配置文件随后进入服务环境执行授权命令最后使用Navicat完成远程连接验证其中重点解释了bind-address注释、skip-name-resolve配置、以及SSH与常规连接配合使用时的注意事项帮助读者理解报错产生的常见原因。内容还覆盖权限、端口、连接方式等排查细节并补充了修改配置后的保存退出、刷新权限等易忽略操作按文档顺序操作即可避开常见坑点。资源包共1个文件为PDF文档大小843KB体量轻便、包含逐步操作截图与命令说明可当作远程连接故障排查的速查手册。已有20939人浏览学习说明该问题在实战中较为常见下载后对照操作即可处理同类环境问题。1. 这个 2013 报错不是一个密码问题用 Navicat 连远程 MySQL 时点了“测试连接”转圈十几秒后弹出2013 - Lost connection to MYSQL server at waiting for initial communication packet这是比 1045 Access denied 更磨人的报错。它说明 TCP 端口大概率是通的但 MySQL 服务器一直没把第一个握手包顺利交到客户端手里连接在认证开始之前就被掐断。常见诱因有 bind-address 只监听本机、DNS 反向解析超时、云安全组半开状态、以及 Navicat 与 MySQL 8 认证插件不兼容。这篇文章按服务器端和客户端两条线给做法配抓包和参数修改适合自己管理 MySQL 的开发者、运维和刚上云的新手。2. 连接还没开始就断了initial communication packet 是在哪个环节丢的先把错误文案读完整Lost connection to MYSQL server at waiting for initial communication packet。注意官方拼写是 waiting少一个 i 的 waitting 是搜索引擎里常见的变体你在排查时两边都要搜。MySQL 的握手是单向先行的客户端 TCP 连上后服务器先发一个 HandshakeV10 数据包里面带着协议版本、salt、认证插件名。如果客户端在读到这个包之前连接就关闭就会把失败的阶段记成 waiting for initial communication packet如果读到了一半被截断则是 reading。绝大多数 2013 都发生在这个阶段。别急着改密码先看链路。2.1 一次 MySQL 远程连接的完整握手时序常见做法是把故障拆到四个瞬间域名解析 → TCP 三次握手 → 服务器发送握手包 → 客户端回认证包。Navicat 报 2013 时第一瞬间和第二瞬间往往没问题因为域名解析失败会报 2005端口不通会报 2003。真正断在第三或第四瞬间。第三瞬间断常见的是服务器端 DNS 反查卡住 accept、TCP 层有中间设备静默丢包、服务器 accept 后因 hosts.deny 或 fail2ban 直接断开。其中 DNS 反查这一条很阴险服务器在做反向解析时若上游 DNS 慢TCP 连接已经建立却迟迟不进入发握手包的流程客户端就只能干等。第四瞬间断常见的是认证插件不兼容MySQL 8 的 caching_sha2_password 需要额外交互旧驱动在等待服务器返回公钥时超时也会被客户端判定为连接丢失。这一阶段还有一个不常被注意的参数服务器端的 connect_timeout默认 10 秒。它控制的是服务器等待客户端回认证包的时间。如果客户端已经收到握手包但认证交互卡住超过 10 秒服务器会主动断开客户端最终也落在 2013 上。所以排查方向不要只盯着客户端。2.2 用 mysql 命令行复现并缩小故障范围复现是最快的分类方式。在能访问服务器的机器上用官方 mysql 客户端试一次同样的连接# --connect-timeout 设为 15避免客户端过早放弃 mysql -h 11.22.33.44 -P 3306 -u myuser -p --connect-timeout15这里 -h 必须填 IP别填域名我们要排除 DNS 解析这一层。如果命令行秒连成功说明服务器链路和认证都没有问题故障收敛到 Navicat 自己的驱动配置上后面第 4 章的 SSL 和认证插件部分重点看。如果命令行也报 2013那就按第 3 章去服务器端排查监听和防火墙如果是等了很久才报优先怀疑 DNS 反查。再补一条判断报 2003 是 TCP 层根本没连上报 2013 是 TCP 连上了但 MySQL 协议层的第一个包没走完。这两者的处理方向完全不一样2003 去查端口和安全组2013 去查 MySQL 配置与中间设备。很多人把 2013 当成网络不通反复重启防火墙白折腾。2.3 tcpdump 抓包看握手包到底有没有出现到了这一步如果还定位不了就直接抓包。在 MySQL 服务器上执行# 抓 eth0 网卡的 3306 端口流量网卡名换成机器上实际名称 sudo tcpdump -i eth0 -nn -s 0 port 3306 -w mysql-handshake.pcap抓包的同时让客户端再连一次然后按三次握手和握手包的出现位置分类。只看到 SYN 和 SYN-ACK没有后续数据包是中间链路把后续包丢了常见于安全组规则只放行了一半或是负载均衡后端配置错误。看到服务器发出协议版本串后紧跟 RST是服务器端主动拒绝查 hosts.deny、fail2ban 和 max_connect_errors。看到完整包交互但 Navicat 仍报 2013问题就在客户端驱动对数据包内容的解析上。实际操作不需要逐字节分析 HandshakeV10 内容只需要数包。我用 Wireshark 打开抓包文件过滤 mysql 协议看有没有 Server Greeting 这一行。抓不到就回头看网络和 bind-address抓到了就看时间戳如果服务器发出 greeting 和客户端回包之间隔了好几秒中间多半卡在认证插件或 SSL 协商这一步能救命。3. 服务器端三查bind-address、DNS 反查与防火墙3.1 第一查bind-address 是否把远程连接挡在了 TCP 层严格说bind-address 配错时最典型的报错是 2003Cant connect而不是 2013因为连接根本建立不起来。但我在处理 2013 时从来不会跳过这一步你要先证明服务器在监听并接受连接后面的握手包分析才有意义。打开 my.cnf / my.ini 的 [mysqld] 段看 bind-address。写 127.0.0.1 就是只对本机开放改成 0.0.0.0 或内网 IP 后重启 mysqld[mysqld] bind-address 0.0.0.0改成 0.0.0.0 表示监听所有网卡。如果服务器有多块网卡只想对内网开放就写内网 IP不要偷懒写 0.0.0.0少一个暴露面是一层安全。改完确认监听情况sudo ss -lnpt | grep 3306输出里监听地址从 127.0.0.1:3306 变成 *:3306说明已经对外监听了。Windows 服务器要改 my.ini改完在服务里重启 MySQL 服务。很多在 Windows 10 上装完 MySQL 后一远程就连不上原因就是安装器默认把 bind-address 写成了 127.0.0.1这一条在排查顺序里永远排第一。3.2 第二查DNS 反查是隐藏的 20 秒黑洞这种案例的特征非常统一Navicat 转圈明显超过十秒然后才报 2013同一台服务器上从局域网连很快从办公网或公网连就卡。很多人的第一反应是“网络慢”其实是被 MySQL 的 DNS 反向解析卡住了。MySQL 在 accept 一个客户端 TCP 连接后默认会对来源 IP 做反向 DNS 解析。如果这台服务器的 DNS 配置指向了一个不可达的 DNS 服务器或者上游解析很慢握手包就会迟迟发不出来客户端只能等到超时。解决方法是关掉反查[mysqld] skip-name-resolve重启 mysqld 后反查不再发生之前要等二三十秒的场景通常会立即恢复。注意授权表在这之后行为会变化grant 语句里不能再写主机名必须写 IP 或 ‘%’。如果之前建的账号是 ‘myuser’‘web-server-1’关掉反查后会直接匹配不到我一般会顺手把授权主机改成具体 IP省得后面排查别的连接问题时绕回来。3.3 第三查防火墙和安全组两层都要过端口不通的常规排查大家都知道但这里有个特别容易翻车的点云服务器有两层过滤一层是云厂商的安全组一层是系统内的 firewalld 或 iptables。只放行安全组、忘了开系统防火墙或反过来都会让握手包出不来。我习惯先看系统内# 查看 firewalld 放行情况没有放行则永久放行 3306 sudo firewall-cmd --list-all sudo firewall-cmd --permanent --add-port3306/tcp sudo firewall-cmd --reload再回到云控制台确认入站规则里有 3306/TCP并且来源不是“仅本机”。安全组规则是立即生效的不用重启实例。如果你用 Docker 跑 MySQL需要先确认 docker run -p 3306:3306 做了端口映射同时容器内 mysqld 的 bind-address 不能是 127.0.0.1因为 Docker 的 NAT 会让外部的连接从 docker0 网卡进来只监听回环的容器自然拒收。防火墙都检查完用 telnet 验证端口telnet 11.22.33.44 3306能连通时会看到一段乱码字符那实际上是 MySQL 发来的握手包字节看到乱码反而说明链路是通的问题不在网络层而在应用层。如果 telnet 直接超时或拒绝再回头查安全组和系统防火墙。这一步能把 2013 里相当一部分“伪网络故障”打掉。4. 客户端参数重调Navicat 里值得动的超时、SSL 与驱动选择4.1 Navicat 高级参数连接超时与心跳最该改当命令行秒连、Navicat 却报 2013先别怀疑服务器去编辑连接在高级页找连接超时和保持连接间隔单位是秒界面文字在不同版本里略有差异但位置固定。Navicat 的连接超时如果设置得太短例如 5 秒公网跨地域的 RTT 稍高TCP 三次握手后还没等到握手包就自行断开界面显示的正是 2013。我的习惯是公网连接设 30 秒起步境外到境内部署场景直接 60 秒。保持连接间隔是给 Navicat 定期发送心跳查询用的。如果 MySQL 的 wait_timeout 比较小空闲连接被服务器回收后Navicat 下一次执行查询可能收到的不是结果而是连接丢失也就是在工作时段随机出现 2013。把心跳间隔设成小于 wait_timeout 的数值比如 30 秒能让长连接一直活着。压缩协议那个选项慢网络下能省带宽但会额外消耗两端 CPU内网不建议开。4.2 SSL 模式与认证插件MySQL 8 的 2013 重灾区MySQL 8 默认用 caching_sha2_password 认证插件。这个插件在非 SSL 连接下需要额外做 RSA 公钥交换如果 Navicat 版本较旧JDBC 驱动实现不完整认证阶段会卡住客户端看到的错误就是 Lost connection 2013还有一部分场景直接显示 mysql ssl 连接错误。处理顺序是先在 Navicat 的 SSL 标签页把 SSL 模式改为“禁用”再试一次这样可以排除 TLS 协商环节的问题。禁用后能连通说明之前的握手卡在 SSL 证书链或 TLS 版本不匹配上。如果禁用后依然 2013再去 MySQL 里查当前账号用的哪个插件SELECT user, host, plugin FROM mysql.user WHERE user myuser;查询结果显示 caching_sha2_password 时你可以决定是升级 Navicat 还是把账号改回旧插件。MySQL 8.0 里临时改账号可以用ALTER USER myuser% IDENTIFIED WITH mysql_native_password BY 你自己的密码;注意这个改法在 MySQL 8.4 之后不再默认支持官方已经把 mysql_native_password 移出默认启用列表。所以这只是过渡手法长远方案是升级 Navicat 以支持 caching_sha2_password。改完账号不需要 FLUSH PRIVILEGES重新连接即可。改完仍然 2013就回来检查服务器端 connect_timeout见 4.3。4.3 服务器 connect_timeout 兜底给握手留出余地如果抓包显示服务器已经发出了 greeting客户端也回了包但总在十几秒后被断看看服务器端 connect_timeout 是不是默认 10 秒。这个参数决定服务器在等待客户端认证数据包时能等多久网络跨地域大、丢包率高时认证交互可能在 10 秒内完不成服务器主动断开客户端就报 2013。把它调大[mysqld] connect_timeout 30改完重启 mysqld或者用 SET PERSIST 动态改不用动 Navicat。我一般只在抓包确认“双方都在收包但耗时很稳地超过 10 秒”时才动它否则开着 30 秒反而会让服务端挂着大量半连接给后面 max_connect_errors 添乱。另外还有个字段是 net_read_timeout 和 net_write_timeout那是查询阶段用的解决的不是握手期 2013别一上来就乱调。5. 高频现场排查5 个把 2013 修成功的真实方向很多 2013 修起来像玄学其实每条都有迹可循。下面 5 个现场是我实际处理时收敛出来的按频率排序。遇到问题先对照现象再动手不要一次性把服务器配置全改掉。5.1 现象一Navicat 必挂mysql 命令行秒连现象同一台服务器、同一个账号命令行连得飞快Navicat 的测试连接却稳定报 2013。原因基本在 Navicat 驱动与 MySQL 8 认证插件的兼容性尤其是旧版本 Navicat 对 caching_sha2_password 的 RSA 公钥交互支持不全或默认 SSL 协商失败。解决进编辑连接的 SSL 标签页把 SSL 模式改为禁用如果仍不行再按第 4 章的 ALTER USER 过渡方案把账号换回 mysql_native_password。这里要先确认版本别一上来就改账号毕竟改服务器侧的认证方式影响面比客户端大。5.2 现象二本机正常远程一律失败现象在服务器上连 127.0.0.1 秒进从任何外部机器连都报错错误码可能是 2003 超时也可能是 2013。原因bind-address 只写了 127.0.0.1或云安全组入站规则漏了 3306或系统防火墙没放行。解决先执行 ss -lnpt 看监听地址再核对安全组两个地方都改好。如果监听地址已经是 *:3306问题九成在安全组如果监听是 127.0.0.1先改 bind-address。这条是最常见的初学者踩坑点也是我在工单里回复最多的一种。5.3 现象三时好时坏报错在 2003 和 2013 之间切换现象白天正常某个时间点开始连不上报 2003 或 2013过一会儿自己恢复。原因max_connect_errors 累积到阈值服务器把来源 IP 标记为 blocked或者 fail2ban 因为 MySQL 认证失败次数过多把 IP 拉黑了。解决在 MySQL 里查失败连接数然后清空主机缓存SHOW GLOBAL STATUS LIKE Aborted_connects; FLUSH HOSTS;FLUSH HOSTS 会清掉所有被 max_connect_errors 标记的主机缓存立竿见影。同时查服务器的 fail2ban 状态把对应 IP 从 jail 里移除。根治办法是调大阈值并保证客户端不用错密码[mysqld] max_connect_errors 1000max_connect_errors 是累积的瞬间的 TCP 半连接、认证失败都会加计数超过阈值后同一 IP 的新连接在握手阶段就被拒。5.4 现象四要等 2030 秒才报错像网络丢包现象连接总要转很多圈最后才 2013局域网内没事跨网段就卡。原因MySQL 开启 DNS 反查而异网段的反向解析恰好慢或不可达。解决按第 3 章加 skip-name-resolve 并重启 mysqld。重启后注意授权表里不能有主机名账号建议把授权主机统一改成 IP。这条现象与 5.2 的最大区别是“能连但慢”处理方向完全相反一个是查监听一个是关反查。5.5 现象五公网 VPS 端口通、握手包就是等不来现象telnet 到 3306 能看到乱码握手字节但 Navicat 连上去一直 waiting最终 2013。原因某些云厂商或运营商对公网入站的 3306 端口做了特殊管控TCP 能连后续包却可能在链路中被丢弃也有小概率是 MTU 分片问题握手包被中间链路丢弃。解决先把 MySQL 端口改到非默认端口例如 13306在 my.cnf 里加 port 13306同步改安全组和防火墙。如果还是不行可以把 MySQL 只留在内网用 SSH 远程端口转发把服务器 127.0.0.1:3306 映射到本地再让 Navicat 连接ssh -L 13306:127.0.0.1:3306 userserver_ip然后 Navicat 连 127.0.0.1:13306。这个方案顺带把连接保护住了适合必须直连的场景。6. 收尾的硬核验证法让握手过程看得见的三个动作第一个动作是打开 general log把 MySQL 实际收到的连接过程录下来SET GLOBAL general_log ON; SET GLOBAL general_log_file /tmp/mysql-debug.log;这是临时的排查完记得 SET GLOBAL general_log OFF;。里面会记录每一个连接的来源 IP、连接时间、断开原因能帮你判断是客户端没发认证包还是服务器主动断开。一般 2013 会对应一行 Connect 记录后马上跟着 Quit能看出断点时序。第二个动作是 mysqladmin 检查所有相关参数一次性确认配置生效mysqladmin -u root -p variables | grep -E connect_timeout|skip.name.resolve|bind.address|max_connect_errors这条命令的好处是看到的是运行时的真实值而不是配置文件里可能被覆盖后的假象。改完 my.cnf 后很多人忘了重启或者同一参数在 [mysqld] 之外多写了一份运行时变量一眼就能看出来。第三个动作是清理现场把第 2 章的 tcpdump 抓包文件和 general log 关掉、删除恢复生产环境的日志配置。我自己的教训是曾把 general log 开了一整天才想起来关磁盘被写满业务直接停摆。从那以后所有临时诊断都会先设一个闹钟并且用脚本在结束时自动恢复配置。这系列动作做完2013 再出现时你能明确说出是第几层的问题修复就是顺水推舟的事。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
