无法通过配置关闭mysql的version_banner，唯一有效方式是修改源码中server_version字符串并重新编译mysqld，或使用支持mysql协议深度解析的自研中间件；代理方案如haproxy、proxysql均不可行。
MySQL 连接时暴露的 version_banner 怎么关
MySQL 默认在 TCP 握手阶段（即客户端发起连接、服务端返回初始包时）明文发送 version_banner，形如 5.7.42-log 或 8.0.33。这个信息不走 SQL 协议，而是 MySQL 协议握手包里的 server_version 字段，任何扫描器（如 nmap -sV、mysql --host=xxx -e "SELECT 1"）都能直接拿到，改配置文件根本无效。
真正能干预的位置只有两个：源码里硬编码的字符串，或在流量入口处做协议层替换。没有第三种“配置开关”。
修改 mysqld 源码屏蔽 version_banner 的实操要点
适用于自建环境、有编译能力且能控制部署链路的场景。关键不是删掉版本号，而是替换成无意义固定字符串（否则部分客户端会解析失败）。
- MySQL 5.7 路径：修改
sql/mysqld.cc中的server_version全局变量赋值，例如改为"5.7.0"或"mysql-server"；不要留空，空字符串会导致某些 JDBC 驱动抛CommunicationsException - MySQL 8.0+ 路径：变量移到
sql/server_components/component_implementation.cc或sql/mysqld.h，搜索server_version_str，同样替换为固定值 - 必须重新编译整个
mysqld，仅替换二进制文件无效；编译后检查mysqld --version输出是否变化（这只是命令行版本，不影响协议 banner） - 验证方式：用
tcpdump -i lo port 3306 -A抓包，连一次，找握手响应包里00 00 00 00 .. .. ..后紧跟的 ASCII 字符串，确认已变更
用 ProxySQL 或 HAProxy 做协议层 banner 替换是否可行
ProxySQL 本身不支持修改 MySQL 协议握手包中的 server_version 字段；HAProxy 的 tcp-request content 也无法精准定位并 patch 二进制协议字段——因为握手包长度可变、含随机数、且 version 字符串位置不固定。
目前唯一可行的代理方案是自研或使用支持 MySQL 协议深度解析的中间件（如 mysql-proxy 的 C 插件、或 vitess 的 query router），但代价高、维护难、易引入连接超时或认证兼容问题。
-
mysql-proxy的 Lua 插件只能拦截 SQL 层，无法修改初始 handshake packet - 有团队用 eBPF 在内核层拦截并重写 TCP payload，但依赖 kernel 版本，生产环境稳定性风险大
- 更现实的做法：用 HAProxy 做 TCP 透传 + 在其后加一层轻量 TLS 终结（如
stunnel），虽不能隐藏版本，但能让基础端口扫描器（如 nmap 默认脚本）无法识别服务类型
比隐藏版本更值得优先做的事
攻击者拿到 8.0.33 并不等于能立刻入侵——真正导致沦陷的是未修复的 CVE、弱密码、公网裸奔、或过度权限账号。把精力花在 banner 上，不如堵住下面这些真实缺口：
- 关闭
skip-networking以外的所有远程监听，用bind_address = 127.0.0.1限制仅本地访问 - 删除默认账号：
DROP USER ''@'localhost'; DROP USER 'root'@'::1'; - 禁用
information_schema.PROCESSLIST和performance_schema对普通用户可见性 - 用
mysql_native_password替代caching_sha2_password时注意：后者在低版本客户端上会暴露更多服务端能力标识
banner 是指纹，不是漏洞。扫出来是 5.7 还是 8.0，只要没公开 exploit、没弱口令、没 SSRF 链，就只是多一行日志而已。真要动手的人，早通过应用层日志、报错回显、或 DNSLog 等方式探完了。
