企业官网建设流程全解析

简介：这份PDF文档面向使用Navicat远程连接MySQL数据库的开发者与运维人员，针对连接初始化阶段报出的2013-Lost connection to MYSQL server错误，给出从环境检查到配置修改、授权设置再到远程连接的完整排错思路。内容围绕MySQL安装验证、my.cnf配置文件调整、skip-name-resolve参数设置、mysql环境下的授权命令以及Navicat常规与SSH配合连接等环节展开，帮助读者定位连接初始化阶段丢失连接的原因并完成远程访问配置。资源包共1个PDF文件，大小约843KB，内容以图文步骤形式呈现，便于对照操作。目前已有20938人学习下载，适合需要快速排查Navicat远程连接MySQL失败问题、希望获得可复现配置流程的读者参考。

1. 远程连 MySQL 报 2013：先别急着重装 Navicat

Navicat 连远程服务器时弹出2013 - Lost connection to MySQL server at 'waiting for initial communication packet', system error: 0，这个报错和「密码错」「权限不够」完全不是一回事。它发生在 TCP 三次握手已经完成、MySQL 还没开始跟你聊认证协议的那个瞬间——连接在「等待初始通信包」阶段被掐断了。换句话说，网络是通的，端口也连上了，但服务端在吐出第一个握手包之前就把你踢了。这个阶段能插手的东西不多：服务端的bind-address、skip-name-resolve、max_allowed_packet初值、防火墙的深度包检测、以及中间链路对长连接的静默丢弃。搞清这一点，排查方向就不会跑偏到改密码、重装 Navicat 上去。这篇笔记面向的是手上有远程 MySQL、用 Navicat 或命令行都连不上、又不想盲目重启服务的后端和运维同学，从原理到命令一步步把 2013 拆开。

2. 2013 到底卡在哪一步：握手时序与三个可疑层

2.1 从 TCP 到 MySQL 握手包之间发生了什么

要理解 2013，得先把一次 MySQL 连接拆成两段。第一段是 TCP 层：客户端向 3306 发起 SYN，服务端回 SYN-ACK，客户端再回 ACK，三次握手完成，socket 建立。第二段才是 MySQL 协议层：服务端主动发送一个 Initial Handshake Packet，里面带着协议版本、服务端版本、线程 id、 scramble 盐值、能力标志位；客户端收到后回一个 Handshake Response，带上用户名、加密后的密码、字符集等。waiting for initial communication packet这个措辞，指的就是客户端在第二段里等第一个包——服务端那个 Initial Handshake Packet 迟迟没来，或者来了但被中途丢掉，超时后客户端报 2013。

所以这个错的核心矛盾是：TCP 通了，MySQL 协议层的第一个包没通。能造成这个现象的原因被压缩到很窄的范围里。常见的有四类：服务端bind-address只监听 127.0.0.1，外部 TCP 根本到不了 MySQL 进程；skip-name-resolve没开，服务端在收到连接后要反向解析客户端 IP，DNS 卡住导致握手包发不出来；中间防火墙或云安全组做了应用层检测，把 MySQL 握手包当异常流量丢了；以及max_allowed_packet或thread_stack配置异常导致服务端在准备握手包时就出错。

2.2 用三条命令把故障层定位出来

不要一上来就翻 Navicat 设置。先在能访问服务器的机器上，用命令行把三层依次验证。第一层验证 TCP 可达性，第二层验证 MySQL 协议握手，第三层验证认证。

# 第一层：TCP 端口是否真的能连上，-v 看详细过程，-w 3 设 3 秒超时 nc -vz -w 3 10.0.0.20 3306 # 第二层：用 mysql 客户端带协议调试，看是否卡在握手包 mysql -h 10.0.0.20 -P 3306 -u appuser -p --connect-timeout=5 -e "SELECT 1;" # 第三层：在服务器本机用 socket 连，绕开网络，确认服务本身正常 mysql -u appuser -p -S /var/run/mysqld/mysqld.sock -e "SELECT 1;"

nc返回succeeded说明 TCP 层没问题，问题在 MySQL 协议层或中间设备。mysql客户端如果也报Lost connection ... waiting for initial communication packet，那就和 Navicat 无关，是服务端或链路问题；如果命令行能连、只有 Navicat 报 2013，才需要怀疑 Navicat 的连接参数。本机 socket 能连说明 MySQL 进程活着、账号密码没问题，故障被锁定在网络路径或服务端监听配置上。这三条命令的顺序不能颠倒，先证伪 TCP，再证伪协议，最后证伪认证，能省掉大量瞎试。

2.3 服务端两个最常被忽略的配置项

定位到服务端后，先看bind-address和skip-name-resolve。bind-address决定 MySQL 监听哪个网卡，默认很多发行版是127.0.0.1，意味着只有本机能连，外部 TCP 到了 3306 也会被拒或超时。改成0.0.0.0或具体内网 IP 才能对外服务。skip-name-resolve决定服务端收到连接后是否对客户端 IP 做反向 DNS 解析，如果 DNS 服务器不可达或解析慢，握手包会一直卡在解析阶段发不出去，表现就是客户端等 initial communication packet 超时。

# /etc/mysql/mysql.conf.d/mysqld.cnf 或 /etc/my.cnf [mysqld] bind-address = 0.0.0.0 skip-name-resolve = ON max_allowed_packet = 64M

bind-address改成0.0.0.0后必须配合防火墙只放行可信来源，不要裸奔在公网。skip-name-resolve打开后，MySQL 授权表里的 host 字段就不能再写域名，必须写 IP 或%，否则会出现「明明密码对却连不上」的新问题。max_allowed_packet设太小会在某些客户端版本上影响握手包构造，设到 64M 是常见安全值。改完配置用systemctl restart mysql重启，再用 2.2 的命令复验。

3. Navicat 侧与链路侧：把 2013 从客户端和中间设备里挤出去

3.1 Navicat 连接配置里真正影响握手的几项

Navicat 本身对 2013 的贡献通常不在「主机名填错」这种低级错误上，而在连接属性和 SSH 隧道配置。如果你走的是 Navicat 自带的 SSH 隧道，隧道建立成功但本地转发到远端 3306 的链路有 MTU 或超时问题，握手包会在隧道里被截断。常见做法是把「使用 SSH 隧道」和「直接连接」分开测：先用直接连接确认服务端可达，再叠 SSH 隧道。Navicat 连接属性里的「保持连接间隔」如果设得太短，可能在握手阶段就触发重连干扰；「初始数据库」填了一个不存在的库，某些版本会在握手后立刻断开，报错也可能被归到 2013。

Navicat 连接关键项建议值： 主机名/IP : 服务器内网 IP，不要用域名先排除 DNS 端口 : 3306 保持连接间隔 : 240 秒（默认即可，不要设 10 秒以内） 初始数据库 : 留空或填一个确定存在的库 SSH 隧道 : 先关闭，直连验证通过后再开

先把 SSH 隧道关掉、初始数据库留空、保持连接间隔恢复默认，用最朴素的配置连一次。如果这样能连上，再逐项加回隧道和初始库，加哪项报 2013 就是哪项的问题。这个「最小配置复现法」比对着 Navicat 一堆选项猜要快得多。

3.2 云安全组、iptables 与 MTU 这三个链路杀手

TCP 能通但握手包被丢，链路层最常见的三个原因是云安全组只放了 TCP 没放应用层、iptables 有string或connlimit模块误伤、以及 MTU 不匹配导致大包被静默丢弃。云安全组一般只做端口放行，不太会挑 MySQL 握手包，但如果前面挂了 WAF 或负载均衡，应用层检测可能把非标准 MySQL 流量拦掉。iptables 里如果有-m string --string "mysql"之类的规则，或者connlimit限制过严，新连接会在握手阶段被 DROP。

# 查看是否有针对 3306 的异常规则 iptables -L -n -v | grep 3306 # 临时清空 filter 表规则验证（生产慎用，先备份规则） iptables -I INPUT -p tcp --dport 3306 -j ACCEPT # 检查路径 MTU，握手包通常不大，但隧道封装后会超 ping -M do -s 1472 10.0.0.20

iptables -L里如果看到 3306 相关规则有大量 DROP 计数，基本就是它。临时插一条 ACCEPT 到最前面，如果立刻能连，再回头精修规则。ping -M do -s 1472是探测路径 MTU 的经典手法，1472 加 28 字节 IP/ICMP 头正好 1500，如果这个尺寸不通而小包通，说明路径 MTU 小于 1500，走 SSH 隧道或 IPsec 时封装开销会让握手包超限被丢，需要在隧道两端调小 MTU 或 MSS。

3.3 用 tcpdump 抓一次握手，看包到底停在哪

前面都是推断，真要一锤定音，在服务端抓包看握手包有没有发出去。在服务器上执行抓包，同时客户端发起连接，观察服务端是否发出了 MySQL 握手包。

# 服务端抓 3306 流量，-A 看 ASCII，-c 抓 20 个包就停 tcpdump -i any -nn -A -c 20 'tcp port 3306 and (tcp[tcpflags] & tcp-syn != 0 or tcp[((tcp[12] & 0xf0) >> 2)] != 0)'

如果只看到 SYN、SYN-ACK、ACK，之后没有任何来自服务端的应用层数据，说明 MySQL 进程没发握手包，问题在服务端配置或进程状态。如果看到服务端发了握手包但客户端没回，或者客户端回了但服务端没收到，问题在链路。如果服务端连 SYN-ACK 都没回，问题在监听或防火墙。抓包结果直接决定下一步查哪，比反复改 Navicat 选项高效得多。注意抓包命令里的过滤表达式在不同 tcpdump 版本上兼容性有差异，抓不到就退化成tcpdump -i any -nn port 3306 -A全抓再人工看。

4. 避坑与排查：2013 反复出现时的五条血泪记录

4.1 现象：命令行能连，Navicat 报 2013

原因：Navicat 默认可能启用了「使用压缩」或特定的字符集协商，在握手阶段发送的 Handshake Response 带了服务端不支持的标志位，服务端直接断开。解决：在 Navicat 连接属性里关闭「使用压缩」，字符集显式设为utf8mb4，高级选项里把「使用 MySQL 字符集」勾上，再连一次。如果还不行，用 Navicat 的「复制连接为 URI」功能拿到完整连接串，和命令行参数逐项对比。

4.2 现象：改完 bind-address 重启后，本机也连不上了

原因：bind-address改成0.0.0.0后，如果服务器有多个网卡或防火墙规则只放行了特定网段，本机走 127.0.0.1 可能被新规则挡住。解决：确认bind-address生效后，本机用mysql -h 127.0.0.1而不是 socket 连一次，同时检查iptables -L里 lo 接口是否被误伤。稳妥做法是bind-address填具体内网 IP 而不是0.0.0.0，减少暴露面。

4.3 现象：开了 skip-name-resolve 后，部分老账号连不上

原因：授权表里 host 字段写的是域名，skip-name-resolve打开后 MySQL 不再解析域名，只按 IP 匹配，域名 host 的账号全部失效。解决：SELECT user, host FROM mysql.user;找出域名 host 的账号，改成对应 IP 或%，执行FLUSH PRIVILEGES;。改之前先确认这些账号的实际来源 IP，别一刀切成%把权限放太宽。

4.4 现象：抓包看到握手包发出，客户端仍报 2013

原因：客户端所在网络有透明代理或深度包检测设备，识别到 MySQL 协议后重置连接。解决：换一个网络环境（比如从办公网换到手机热点）复现，如果换了网络就好，基本是中间设备问题，需要找网络管理员放行或改用加密隧道。这类问题在跨运营商、跨地域访问时尤其常见，属于典型的「玄学」故障，抓包是唯一能拿证据的手段。

4.5 现象：连接偶尔成功偶尔 2013

原因：服务端max_connections接近上限，新连接在握手阶段被排队或拒绝；或者 DNS 解析时快时慢。解决：SHOW STATUS LIKE 'Threads_connected';和SHOW VARIABLES LIKE 'max_connections';对比，接近就调大max_connections并排查连接泄漏。DNS 问题则确认skip-name-resolve已开，或把/etc/hosts里加上客户端 IP 的静态映射作为后悔药。

5. 把 2013 变成可验证的检查清单：一个脚本收尾

排查到后面你会发现，2013 的根因就那么几个，但每次都要重新敲一遍命令很烦。我一般会在跳板机上放一个检查脚本，把 TCP、协议、配置、抓包四步串起来，出问题先跑一遍，把结果贴到工单里，比口头描述「连不上」高效得多。

#!/usr/bin/env bash # check_mysql_2013.sh 用法: ./check_mysql_2013.sh <host> <port> <user> HOST=${1:-127.0.0.1} PORT=${2:-3306} USER=${3:-root} echo "== 1. TCP 可达性 ==" nc -vz -w 3 "$HOST" "$PORT" 2>&1 echo "== 2. MySQL 协议握手 ==" mysql -h "$HOST" -P "$PORT" -u "$USER" -p --connect-timeout=5 -e "SELECT 1;" 2>&1 echo "== 3. 服务端监听与关键配置 ==" mysql -e "SHOW VARIABLES WHERE Variable_name IN ('bind_address','skip_name_resolve','max_allowed_packet','max_connections');" 2>&1 echo "== 4. 当前连接数 ==" mysql -e "SHOW STATUS LIKE 'Threads_connected';" 2>&1

脚本前三步对应 2.2 的三层定位，第四步看连接数是否触顶。nc那行如果失败，后面都不用看，直接查防火墙和bind-address。mysql那行如果报 2013，把--connect-timeout调大再试一次，排除偶发超时。配置查询那行能一次性看到四个关键变量，省得逐个SHOW。连接数那行用来判断是不是并发打满。这个脚本不解决所有问题，但能把「连不上」变成「卡在第几步」，沟通成本立刻降下来。

我自己的习惯是：任何远程数据库连不上，先跑这个脚本，再决定要不要抓包。抓包是最后手段，不是第一手段。2013 这个错看着吓人，拆开就是 TCP 通、协议不通，范围窄得很，别被它牵着去重装 Navicat 或者改密码。希望帮到你。

本文还有配套的精品资源，点击获取