MySQL连接频繁被重置本质是TCP层RST包强制终止，90%以上非MySQL主动关闭，而是防火墙、NAT网关或负载均衡器等中间设备因空闲超时（通常300–900秒）主动发送RST；需同步调优Linux内核tcp_keepalive_time等参数并确保客户端驱动启用SO_KEEPALIVE。
频繁收到 RST 包，往往不是应用代码写错了，而是网络环境在“悄悄动手”。真正要稳定连接，得先看清中间环节——防火墙、NAT 网关、负载均衡器这些设备，才是 RST 的高发源头。
企业防火墙主动干预
很多企业防火墙默认启用连接跟踪（conntrack），对空闲连接设 5 分钟超时（net.netfilter.nf_conntrack_tcp_timeout_established=300）。一旦连接无数据交互超过该阈值，防火墙会直接发 RST 清理会话。RST 源 IP 显示为防火墙 VIP，且紧随最后一个 ACK 出现，毫秒级响应，就是典型特征。排查时用 tcpdump -i any 'tcp[tcpflags] & tcp-rst != 0' 抓包，比对源 IP 是否与后端服务 IP 一致。
- 确认防火墙策略：检查 ACL 是否限制了长连接、是否启用了 DPI 并误判协议
- 调整会话老化时间：如支持配置，将 established 超时延长至 1800 秒（30 分钟）
- 客户端加保活：设置
SO_KEEPALIVE或应用层心跳，避免被判定为空闲
云 NAT 网关资源耗尽
AWS、阿里云等 NAT 网关有连接跟踪表容量上限。当并发连接数过高或大量短连接未及时释放，表项打满后，新 SYN 或已有连接的后续包会被丢弃，并由网关伪造 RST 回复。现象是同一五元组（srcIP:srcPort→dstIP:dstPort）反复出现 RST，间隔接近超时值（如 300s），且 RST 源 IP 是 NAT 出口地址。
- 监控 NAT 网关指标：重点关注 “Connection Tracking Table Utilization”
- 客户端端口复用优化：避免短时间内创建大量新连接；可启用
net.ipv4.tcp_tw_reuse = 1（需确保net.ipv4.tcp_timestamps = 1） - 服务端开启连接复用：HTTP Keep-Alive、gRPC keepalive 参数（如
time: 60s）降低连接频次
负载均衡器健康检查与连接劫持
某些 LB（如 Nginx、HAProxy）在后端节点健康检查失败时，会主动向客户端发送 RST 中断现有连接；也有 LB 在连接迁移、权重调整或会话同步异常时，对“非预期”流量直接 reset。错误日志中常见 upstream prematurely closed connection 或 connection reset while reading response。
- 检查 LB 日志和指标：确认是否有 backend server marked down、session sync timeout 等告警
- 统一健康检查路径与超时：避免因检查响应慢导致误判下线
- 关闭“连接劫持”类功能：如 Nginx 的
proxy_http_version 1.1+proxy_set_header Connection ''防止代理层干扰 TCP 状态
安全组与 ACL 规则拦截
云平台安全组、主机 iptables 或 eBPF 过滤器可能在连接建立后动态封禁 IP 或端口。例如：某客户端 IP 被临时限速或拉黑，后续数据包到达时，内核或中间设备无法匹配已有连接状态，直接回 RST。特点是 RST 出现无规律，但源 IP 与目标服务 IP 不符，且常伴随连接建立成功但首次请求即失败。
- 检查安全组入/出方向规则：确认是否设置了基于连接状态的宽松策略（如 `ESTABLISHED,RELATED`）
- 排查主机级防火墙：
iptables -t raw -L -n -v查看 RAW 表是否 DROP 或 REJECT 了 ESTABLISHED 流量 - 禁用非必要连接限制模块：如
xt_connlimit或nf_conntrack相关限速规则
