mysql无监听外网连接的首要原因是bind-address仍为127.0.0.1，导致仅响应本地请求；需改为0.0.0.0并重启服务，再配合用户host权限、防火墙、云安全组等多层配置方可实现远程访问。
MySQL 本身没有连接监听器功能
MySQL 不提供类似 Nginx 的 access_log + geoip 或 Redis 的 MONITOR 那样的实时连接监听/拦截模块。所谓「连接监听器」是误用概念——它不解析、不阻断、不记录连接请求的 IP 元数据，只在认证阶段才检查 user@host 是否匹配。连接建立前的 TCP 握手、SYN 包、来源 IP 封装等，完全由操作系统协议栈和防火墙处理。
真正起作用的是 bind-address + 防火墙组合
MySQL 的 bind-address 参数只是告诉 mysqld 监听哪个本地地址，不是过滤器。它不拒绝任何 IP，只决定“从哪儿收包”。实际拦截必须靠外层机制：
-
bind-address = 127.0.0.1：让 MySQL 拒绝所有非本机进程的 TCP 连接（内核直接丢弃，连不到认证环节） -
iptables或ufw：在进入网络协议栈早期就 DROP 特定源 IP 的--dport 3306包，不触发 MySQL 任何日志或开销 - 云安全组：比 iptables 更前置，流量根本到不了服务器网卡
执行 ss -tlnp | grep :3306 看输出是否为 127.0.0.1:3306，如果不是，说明 bind-address 没生效，防火墙规则再严也白搭。
如何快速封禁已发现的可疑 IP
一旦从 mysql.general_log 或系统日志里发现异常连接（如大量 Access denied for user），立刻在系统层封禁，不要等 MySQL 层响应：
- Ubuntu 上用 ufw：
sudo ufw insert 1 deny from 203.0.113.45 to any port 3306（insert 1 确保优先于 allow 规则） - CentOS/RHEL 用 firewalld：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.45" reject' - 封禁后务必 reload：
sudo ufw reload或firewall-cmd --reload - 别依赖 MySQL 的
DROP USER 'xxx'@'203.0.113.45'——如果该 IP 本来就没对应用户，这操作毫无意义
为什么不能靠 MySQL 日志实时拦截
MySQL 的错误日志（mysqld.err）和通用查询日志（general_log）都是事后记录，且默认不开启。即使开启，写入有延迟，无法做到毫秒级响应。更关键的是：
- 日志里出现
Access denied，说明连接已完成三次握手、MySQL 已分配线程、完成身份验证尝试——资源已被消耗 - 攻击者可利用这点发起慢速连接洪水（slowloris 变种），绕过防火墙连接数限制
- MySQL 不提供 hook 或插件接口让你在
connect阶段动态拒绝，validate_password插件只管密码强度，不管 IP
真正的防御水位线不在数据库里，而在网卡驱动之上。把拦截逻辑放在 MySQL 外面，不是妥协，是分层设计的必然选择。
