这大概率是中间网络设备（如防火墙）因空闲超时主动中断MySQL长连接，而非MySQL服务本身问题；telnet/nc仅验证TCP握手成功，无法暴露后续RST断连。
telnet 或 nc 能连上但 mysql 客户端报错 Lost connection to MySQL server
这大概率不是 MySQL 服务本身的问题，而是连接建立后被中间网络设备（尤其是防火墙）主动中断。MySQL 协议是长连接，防火墙常对空闲连接做超时清理，而 telnet/nc 只测试 TCP 握手成功就退出，掩盖了后续中断问题。
实操建议：
- 用
mysql -h host -P port -u user -p --connect-timeout=5 --wait_timeout=10加上短超时参数，让失败更快暴露 - 在客户端和服务端同时抓包：
tcpdump -i any 'host target_ip and port 3306' -w mysql.pcap，重点看是否有 RST 包来自非两端 IP（比如防火墙的 IP） - 检查防火墙会话超时设置：常见企业防火墙（如 Palo Alto、FortiGate）默认 TCP 会话空闲超时为 1800 秒，而 MySQL 的
wait_timeout默认是 28800 秒，不匹配就会被断
Linux 服务器本地能连，远程连不上且无拒绝提示
说明 SYN 包可能被丢弃而非拒绝，典型表现是客户端卡在 Connecting to MySQL server...，最终超时。这不是 iptables 的 REJECT（会有明确 Connection refused），而是 DROP 或防火墙策略静默丢包。
实操建议：
- 在服务端运行
ss -tlnp | grep :3306确认 mysqld 确实在监听0.0.0.0:3306（而非仅127.0.0.1） - 临时关闭系统防火墙验证：
sudo systemctl stop firewalld（CentOS）或sudo ufw disable（Ubuntu），再试连 - 若关闭后正常，检查 firewalld 规则：
sudo firewall-cmd --list-all，确认3306/tcp在 public zone 中且状态为enabled
云厂商安全组放行了 3306，但连接仍不稳定
安全组只控制入方向，但很多云平台（如阿里云、AWS）的底层网络设备会对“半开连接”或“无响应连接”主动回收，尤其当客户端未正确发送 quit 包就断开时。MySQL 的 interactive_timeout 和 wait_timeout 若远大于安全组/网络设备的会话超时，就会出现“看似连上了，过几分钟突然断”。
实操建议：
- 将 MySQL 的
wait_timeout和interactive_timeout设为略小于云平台会话超时（例如阿里云默认 900 秒，可设为 600） - 应用层加连接池保活，比如在 JDBC URL 中加
?autoReconnect=true&socketTimeout=30000，避免依赖单个长连接 - 不要依赖
skip-name-resolve来绕过 DNS 延迟——它解决的是反向解析慢，和防火墙中断无关
排查时误判为 MySQL 配置问题的典型现象
看到 ERROR 2013 (HY000): Lost connection to MySQL server during query 就调 max_allowed_packet 或 net_read_timeout，其实这类错误只要发生在非查询执行中（比如刚连上几秒就断），基本和包大小无关，而是网络层被截断。
实操建议：
- 对比错误时间戳和系统日志：
journalctl -u mysqld --since "2 minutes ago"，如果 mysqld 日志里没有对应记录，说明断连发生在 MySQL 接收请求前 - 检查
/var/log/messages或dmesg是否有内核级丢包提示，如nf_conntrack: table full（连接跟踪表溢出，本质也是防火墙资源耗尽） - 避免在测试时用
mysql -e "SELECT SLEEP(10)"模拟长查询——这会让问题看起来像 MySQL 自身超时，实际是防火墙在第 5 秒就发了 RST
真正难定位的是那些只在特定时间段、特定出口 IP 下复现的中断，这时候得盯住防火墙的会话日志，而不是反复调 MySQL 参数。
