SHOW REPLICA STATUS\G 是验证 MySQL 复制 SSL 加密是否生效的最直接方式，关键字段包括 Slave_SSL_Allowed 必须为 Yes、Master_SSL_Cipher 必须非空，二者缺一不可。
只看配置文件或命令是否执行成功，无法确认加密是否真正在用——必须查运行时状态。
查 SHOW REPLICA STATUS\G 里的关键字段
这是最直接、最不可绕过的验证方式。MySQL 不会因为你在 CHANGE REPLICATION SOURCE TO 里写了 SOURCE_SSL = 1 就强制走加密；它静默降级，且不报错。
-
Slave_SSL_Allowed: Yes—— 必须为Yes，不是No或空值 -
Master_SSL_Cipher—— 必须非空（如ECDHE-RSA-AES256-GCM-SHA384），空值代表未协商出加密套件 -
Seconds_Behind_Master正常变动（非NULL或持续为0）可佐证通道活跃，但不能替代前两项
确认主库 require_secure_transport 已生效且证书加载正确
从库连得上 ≠ 主库在用加密。如果主库没真正启用强制 TLS，攻击者仍可用复制账号发起明文连接。
- 登录主库执行：
SHOW VARIABLES LIKE 'require_secure_transport';，结果必须是ON - 同时检查：
SHOW VARIABLES LIKE 'have_ssl';返回YES，且ssl_ca/ssl_cert/ssl_key均指向有效路径 - 注意：
SET GLOBAL require_secure_transport = ON;无效，必须写进[mysqld]段并重启mysqld - 重启后检查错误日志：
tail -n 50 /var/log/mysqld.log | grep -i ssl，出现Failed to set up SSL说明证书权限（私钥需600）或路径不对
验证复制账号是否真被强制 SSL
即使主库开了 require_secure_transport = ON，如果复制用户没加 REQUIRE SSL，就等于给锁配了把能拔下来的钥匙。
- 执行：
SELECT user, host, plugin, ssl_type FROM mysql.user WHERE user = 'repl'; -
ssl_type字段必须为ANY、X509或SPECIFIED，不能是NONE - 若插件是
caching_sha2_password，且ssl_type = NONE，则必然触发Authentication requires secure connection错误 - 创建账号时必须显式指定：
CREATE USER 'repl'@'192.168.10.5' IDENTIFIED BY 'xxx' REQUIRE SSL;，禁止用%通配
抓包验证（终极手段，但别在生产环境乱试）
当所有状态都显示“已加密”，但你仍存疑，Wireshark 抓 3306 端口流量是最硬核的验证方式。
- 过滤条件：
tcp.port == 3306 and ip.addr == [主库IP] - 正常加密连接中，
TLSv1.2或TLSv1.3握手包之后，所有 payload 应为密文（看不到UPDATE、INSERT、密码等明文） - 若能看到
mysql-bin.000001、repl、SET PASSWORD等字符串，说明某处配置失效，流量仍是明文 - 注意：Docker 容器内抓包需进容器命名空间，或在宿主机桥接网卡上抓；云环境可能受安全组或虚拟网络限制
最容易被忽略的是：主库 require_secure_transport = ON 和从库完整传入 SOURCE_SSL_CA 这两件事必须同时成立，缺一不可。只做一半，表面看起来一切正常，实际全是裸奔。
