MongoDB怎么确认当前连接是加密的_在shell中运行isMaster并检查ssl项-MongoDB-PHP中文网

用 db.runCommand({isMaster: 1}) 查 ssl 字段：值为 true 表示当前连接已启用 TLS/SSL 加密；字段缺失或 false 表示未加密，该结果仅反映本次连接协商状态，不表示服务端全局配置。

mongodb怎么确认当前连接是加密的_在shell中运行ismaster并检查ssl项

直接运行 db.runCommand({isMaster: 1})，看返回结果里的 ssl 字段值。如果值为 true，说明当前连接（即客户端到服务器的这条 TCP 链路）是加密的；如果字段不存在或为 false，则未启用加密传输。

注意：这个 ssl 字段反映的是**本次连接的协商结果**，不是服务器全局配置。即使服务端支持 SSL，如果客户端没配证书、没加 --ssl 参数或没设 ssl=true 连接字符串，这里仍会是 false 或缺失。

除了顶层的 ssl，还要关注这几个字段：

me 和 hosts 中的域名/IP 是否带端口（如 mongodb.example.com:27017）——若只显示 IP 且无端口，可能绕过了 SSL 代理或负载均衡器
canonicalizationHostname 字段存在，通常表示服务端开启了主机名规范化，常见于启用了 TLS 的部署
sslEnabled（部分版本有）：服务端编译时是否支持 SSL，但不等于当前连接已加密
sslAvailable（旧版有）：同上，仅表示能力，非连接状态

因为 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 只能说明“这次成功了”，不代表所有连接都如此。