正常，因为防火墙发送的TCP RST使MySQL未收到完整请求，故error log无记录；真正捕获点在内核网络栈，需用tcpdump抓包分析RST来源并检查防火墙、安全组及MySQL监听配置。
MySQL 的 error log 里看不到 RST，这是正常现象
防火墙主动发送 TCP RST 中断连接时，MySQL 服务端通常收不到完整的握手或请求数据包，因此 error log 不会记录“连接被拒绝”或“客户端异常断开”这类信息。你翻遍 mysqld.log 可能只看到几条无关的启动日志，或者压根没新增记录——这不是 MySQL 没出问题，而是它根本没机会处理这次连接。
真正能捕获 RST 的地方在操作系统层面：内核网络栈。所以排查起点不是 MySQL 配置，而是确认连接是否真被防火墙截断。
用 tcpdump 抓包确认 RST 来源
在 MySQL 服务器上执行抓包，过滤目标端口和 SYN/RST 包：
tcpdump -i any -nn 'port 3306 and (tcp-syn or tcp-rst)' -w mysql_rst.pcap
让客户端尝试连接（比如 mysql -h $IP -P 3306 -u test -p），然后立即 Ctrl+C 停止抓包。用 Wireshark 打开 mysql_rst.pcap，重点看：
- 是否有客户端发来的
TCP SYN，但服务器没回SYN-ACK - 是否有服务器（或中间设备）直接发出
TCP RST，且源 IP 不是本机 - 如果 RST 的源 IP 是网关、负载均衡器或跳板机，基本可锁定是它们上的防火墙策略拦截
注意：iptables 或 nftables 默认不记录丢包细节，除非你显式加了 -j LOG 规则；而云厂商的安全组（如 AWS Security Group、阿里云 ECS 安全组）根本不会在实例内留下痕迹，只能去控制台查规则。
检查 MySQL 是否监听在正确地址和端口
即使防火墙放行，MySQL 自身配置错误也会导致连接被系统级 RST（表现为“Connection refused”）：
- 运行
ss -tlnp | grep :3306，确认监听的是*:3306或具体外网 IP，而非仅127.0.0.1:3306 - 检查
my.cnf中bind_address值：设为0.0.0.0表示监听所有接口；设为127.0.0.1则外部连接必然触发 RST -
skip_networking必须为OFF（默认值），否则 MySQL 根本不启用 TCP 协议
改完配置后要 systemctl restart mysqld，不能只 reload —— bind_address 变更必须重启生效。
云环境特别要注意安全组与网络 ACL 的双重过滤
本地测试 telnet $IP 3306 能通，不代表应用能连：云平台通常有两层网络控制：
- 安全组（Stateful）：控制进出实例的流量，按端口/协议/源 IP 设置规则
- 网络 ACL（Stateless）：作用于子网层级，入站和出站规则独立，且默认拒绝所有
常见坑点：
- 安全组开了入站 3306，但忘了开**出站响应端口**（客户端随机端口范围，如
1024-65535）——某些严格 ACL 会因此返回 RST - 数据库实例在私有子网，但 NAT 网关或路由表没配好，导致响应包无法原路返回
- 客户端所在 ECS 和 RDS 实例不在同一安全组白名单中（尤其跨账号、跨 VPC 场景）
这类问题在 tcpdump 里会看到 SYN 进来、RST 出去，但源 MAC 地址可能是网关而非本机，这就是网络设备介入的明确信号。
防火墙导致的 RST 本身不可见于 MySQL 日志，但它的痕迹一定留在网络路径上；最省时间的做法，是先抓包再查规则，而不是反复调 MySQL 配置。
