用 db.runCommand({isMaster: 1}) 查 ssl 字段：值为 true 表示当前连接已启用 TLS/SSL 加密；字段缺失或 false 表示未加密，该结果仅反映本次连接协商状态，不表示服务端全局配置。
怎么用 isMaster 判断 MongoDB 连接是否启用了 TLS/SSL
直接运行 db.runCommand({isMaster: 1})，看返回结果里的 ssl 字段值。如果值为 true，说明当前连接（即客户端到服务器的这条 TCP 链路）是加密的；如果字段不存在或为 false，则未启用加密传输。
注意：这个 ssl 字段反映的是**本次连接的协商结果**，不是服务器全局配置。即使服务端支持 SSL，如果客户端没配证书、没加 --ssl 参数或没设 ssl=true 连接字符串，这里仍会是 false 或缺失。
isMaster 返回里还有哪些 SSL 相关字段值得看
除了顶层的 ssl，还要关注这几个字段：
-
me和hosts中的域名/IP 是否带端口（如mongodb.example.com:27017）——若只显示 IP 且无端口，可能绕过了 SSL 代理或负载均衡器 -
canonicalizationHostname字段存在，通常表示服务端开启了主机名规范化，常见于启用了 TLS 的部署 -
sslEnabled（部分版本有）：服务端编译时是否支持 SSL，但不等于当前连接已加密 -
sslAvailable（旧版有）：同上，仅表示能力，非连接状态
为什么有时候 ssl: true 但数据还是明文？
因为 isMaster 只确认「连接层是否加密」，不保证「应用层数据安全」。常见陷阱包括：
- 客户端用
mongosh连接时忘了加--tls，却误以为 URI 里的?tls=true自动生效（实际 mongosh 1.8+ 才默认读取该参数） - 连接字符串中混用了
ssl=true（旧参数名）和tls=true（新标准），驱动可能忽略其中一个 - 中间有 MongoDB Proxy（如 Mongos、Atlas 负载均衡器），它跟 client 加密了，但跟 backend shard 没加密——
isMaster查的是前端连接，看不到后端链路 - 服务端配置了
net.ssl.mode: preferSSL，允许非加密连接进来，此时连上来的每个连接要单独判断
更可靠的验证方式：抓包或看连接详情
单靠 isMaster 不够稳，尤其在调试网络中间件时：
- 用
db.currentOp({secs_running: {$gt: 0}})查当前活跃连接，看client字段的 IP:port，再在服务器上执行ss -tnp | grep :27017，观察对应连接是否有ESTABLISHED状态且无明显明文特征（如可读的 JSON） - 在客户端机器用
tshark -i any -Y 'mongodb && tcp.port==27017' -T fields -e mongodb.fullcollectionname，如果抓不到明文 collection 名，大概率是 TLS 流量（TLS 1.3 下更难解析） - 连接字符串中显式加上
?tlsInsecure=false&tlsCAFile=/path/to/ca.pem，并确保文件可读——这能强制驱动校验证书，失败时会报错，比静默降级更可靠
真正容易被忽略的是：MongoDB 的 SSL/TLS 握手发生在连接建立阶段，而 isMaster 是第一个发往服务器的命令。如果握手失败，你根本进不了 shell，也就看不到这个结果。所以看到 ssl: true 只能说明“这次成功了”，不代表所有连接都如此。
