是，但仅限加密层启动；+srv默认启用TLS，却不自动加载私有CA根证书、不校验跨区域服务器域名是否匹配证书SAN，需显式配置tlsCAFile、确保统一CA签发及主机名验证。
跨机房 MongoDB 数据传输必须启用 TLS，但光靠 mongodb+srv:// 自动开启加密远远不够——它只打开 TLS 握手通道，不解决证书信任链断裂、主机名验证失败、CA 文件加载路径错误这三类高频阻断问题。
用 mongodb+srv:// 连接时 TLS 是否真正生效？
是，但仅限“加密层启动”，不等于“连接能通”。+srv 默认设 tls=true，但不会自动加载你私有 CA 的根证书，也不会校验目标实例域名是否在证书的 SAN（Subject Alternative Name）中列出。比如你有两个机房：mongo-us-west.example.com 和 mongo-ap-northeast.example.com，而证书里只写了前者，连接后者就会因 SSL routines:ssl3_get_server_certificate:certificate verify failed 报错中断。
验证方法：
- 运行
openssl x509 -in server.pem -text -noout | grep -A1 "Subject Alternative Name"，确认输出包含所有机房域名 - 用
mongosh --tls --tlsCAFile /path/to/ca.pem --host mongo-ap-northeast.example.com单点直连测试，绕过 SRV 解析，定位是 DNS 还是证书问题
tlsCAFile 必须指向统一 PEM 格式根证书
所有跨机房 MongoDB 实例必须由同一私有 CA 签发证书；客户端也必须用同一个 tlsCAFile 文件验证任意节点。常见错误是各机房自建 CA，又没做交叉签名，导致 driver 无法构建信任链。
注意点：
- 文件必须是 PEM 格式，且含完整根证书（不能只放中间证书）
- 路径需被进程可读：容器部署时，确认已挂载，如
/etc/mongo/ca.pem，并检查权限ls -l /etc/mongo/ca.pem - Go driver 示例中，必须调用
AppendCertsFromPEM()显式加载，不能只传空RootCAs对象
禁用主机名验证或跳过证书校验是危险操作
tlsAllowInvalidHostnames=true 或 tlsAllowInvalidCertificates=true 在生产环境等同于裸 TCP —— 加密存在，但 MITM 防御完全失效。区域出口网关、负载均衡器或中间网络设备可能劫持并解密流量。
真实风险场景：
- 测试阶段开了
tlsAllowInvalidCertificates，上线后忘记关闭 - 用
localhost或 IP 直连开发环境，误把该配置带到生产连接字符串中 - CI/CD 流水线中硬编码了绕过选项，不同环境未做隔离
唯一可接受的例外：离线集成测试，且必须配合防火墙策略限制源 IP 范围。
多数据中心建议启用双向 TLS（mTLS）
单向 TLS（仅服务端证书）只能防窃听，不能防冒充。跨机房场景下，应让每个 MongoDB 节点也验证客户端身份，强制使用 tlsCertificateKeyFile 提供客户端证书，并在服务端配置 tls.mode: requireTLS + tls.clusterFile（副本集）或 tls.allowConnectionsWithoutCertificates: false（7.0+）。
这样做能堵住两个漏洞：
- 防止非授权节点接入集群（比如误配的灾备节点）
- 避免某机房证书泄露后，攻击者伪造客户端身份横向移动
证书管理复杂度会上升，但这是跨机房可信通信不可省略的一环——信任不能靠网络隔离维持，必须靠密码学锚定。
