MySQL应用连接失败常见原因是bind-address配置为127.0.0.1导致仅监听本地；需改为0.0.0.0或指定IP并重启服务，再用ss确认监听*:3306。
telnet 和 nc 能连上，但应用连接失败？先看 MySQL 的 bind-address 配置
很多情况下 telnet your_host 3306 或 nc -zv your_host 3306 显示端口通，但程序报 Connection refused 或 Lost connection，根本原因常是 MySQL 只监听了本地回环地址。
- 登录 MySQL 执行
SHOW VARIABLES LIKE 'bind_address';，如果返回127.0.0.1，说明它拒绝所有非本机来的 TCP 连接 - 修改配置文件（如
/etc/mysql/mysql.conf.d/mysqld.cnf），把bind-address = 127.0.0.1改成bind-address = 0.0.0.0（仅限可信内网）或指定业务网卡 IP - 改完必须重启服务：
systemctl restart mysql；不重启，配置不会生效 - 注意：改完后用
ss -tlnp | grep :3306确认监听的是*:3306而不是127.0.0.1:3306
ping 通、telnet 通，但连接几秒后断开？检查防火墙和安全组的「状态跟踪」
Linux 防火墙（如 ufw 或 firewalld）默认允许新建连接，但可能因连接跟踪（conntrack）异常丢弃已建立连接的后续包，表现为“能握手但查不到数据”或“连接中途重置”。
- 临时关闭防火墙测试：
ufw disable或systemctl stop firewalld，确认是否恢复 - 若关闭后正常，不要直接永久关，而是放行连接状态：
ufw allow from any to any port 3306 proto tcp - 云服务器（阿里云/AWS/腾讯云）务必检查**安全组入方向规则**——只开 3306 不够，还要确保规则作用于正确网段（比如 CVM 和 RDS 在同一 VPC）
- 特别注意：某些云平台的安全组默认拒绝所有入向流量，即使你开了 3306，也可能被更靠前的“拒绝全部”规则拦截
MySQL 日志里反复出现 Aborted connection？可能是网络中间件在杀空闲连接
MySQL 错误日志中看到类似 [Warning] Aborted connection 123 to db: 'unconnected' user: 'someuser' host: '10.0.1.5' (Got an error reading communication packets)，不代表 MySQL 本身出错，往往是网络路径上的设备主动中断了长空闲连接。
- 常见诱因：负载均衡器、NAT 网关、企业防火墙设置了较短的 TCP 会话超时（如 300 秒），而 MySQL 的
wait_timeout设为 28800（8 小时） - 验证方法：在客户端执行
SELECT @@wait_timeout, @@interactive_timeout;，再对比网络设备文档中的 idle timeout 设置 - 解决思路不是调高 MySQL 超时，而是让客户端启用连接池并配置
ping或testOnBorrow，或者在连接串加?autoReconnect=true&failOverReadOnly=false（Java JDBC） - 别忽略
max_allowed_packet：如果客户端发大包被中间设备截断，也会触发这类错误，且日志里不提示具体原因
想抓包分析丢包位置？Wireshark 过滤 MySQL 流量要避开两个坑
用 Wireshark 抓 MySQL 包本意是定位丢包点，但过滤写错或环境没配对，抓出来的全是干扰项，白忙活。
- 捕获过滤器必须用
tcp port 3306（不是port 3306），否则会混入 UDP 包；若改了默认端口，得同步替换数字 - 显示过滤器用
mysql可解码协议，但前提是 Wireshark 已识别为 MySQL 流——如果握手阶段就断了，可能还没协商好协议，此时要用tcp.stream eq 5（根据 TCP 流编号筛选）人工追踪 - 别在数据库服务器本机抓包：loopback 接口（如
lo）上的包不经过网络栈，看不到真实丢包；应分别在客户端、服务端、中间跳转设备（如网关）上抓包比对 - 抓包时记得开启时间戳和 TCP 重传标记（
tcp.analysis.retransmission），一眼就能看出哪段有丢包重传
