MongoDB 5.0 默认允许明文连接且日志不标记，需通过 iftop -P 27017 抓取端口流量观察短连接、小包高频等异常特征来识别未加密连接。
MongoDB 5.0 默认不拒绝未加密连接，也不会在日志中主动标记“明文连接”，仅靠 mongod 日志或 mongosh 客户端输出无法直接识别某次连接是否走的是纯 TCP 明文。必须从网络层抓包或流量特征入手。
用 iftop 实时观察 MongoDB 端口的连接方向与流量模式
iftop 不解析协议，但能快速暴露异常连接行为：
- 默认 MongoDB 服务端口是
27017，运行iftop -P 27017可聚焦该端口 - 若看到大量短连接（
TIME_WAIT或快速建立/断开）、小包高频交互（如每秒数十个 - 对比开启 TLS 后的流量：通常首包会变大（ClientHello 占 ~200–300 字节），后续加密流呈现更均匀的包长分布，而明文连接首包往往极小（如
00000000000000000000类似握手探测） - 加
-n参数禁用 DNS 解析，避免干扰判断；加-t可导出文本便于 grep 过滤
用 tcpdump 抓包识别 TLS 握手缺失
明文连接最确定的证据是抓包里找不到 TLSv1.2+ 的 ClientHello：
- 执行
tcpdump -i any port 27017 -w mongo.pcap -c 100抓 100 个包 - 用
tcpdump -r mongo.pcap -nnA | grep -i "clienthello\|tls"检查是否存在 TLS 握手信号 - 若完全无匹配，且能看到可读字符串（如
isMaster、buildInfo、数据库名明文），基本确认为未加密连接 - 注意：MongoDB 5.0 支持混合模式（同一端口同时接受 TLS 和非 TLS），所以单次抓包可能混有两类连接，需分连接追踪
src:port → dst:port流
通过 mongostat 或 serverStatus 辅助交叉验证
虽然不能直接显示“是否加密”，但可排查配置矛盾点：
- 运行
mongostat --host localhost:27017 -u admin -p pwd --eval "db.runCommand({serverStatus:1}).connections，检查sslEnabled字段是否为true - 若
sslEnabled: false，说明服务端根本没启用 TLS，所有连接必为明文 - 若
sslEnabled: true，但客户端仍走明文，则问题出在客户端——比如连接字符串漏了?tls=true，或驱动版本太旧不支持自动协商 - 特别注意：MongoDB 5.0 的
net.tls.mode配置若设为preferTLS，服务端不会拒绝明文连接，这正是最容易被忽略的“看似启用了 TLS，实则形同虚设”的配置
真正难发现的不是“有没有加密”，而是“本该加密却没走加密”的连接——它们混在正常流量里，既不报错也不告警。抓包看 ClientHello 是唯一可靠手段，其他方式都只是旁证。
