MongoDB认证失败导致连接假死的主因是未配置authSource=admin、mongod未启用authorization、副本集用户不同步及客户端未处理失效连接。
连接字符串里没加 authSource 参数
MongoDB 开启认证后，默认会把用户信息存在 admin 数据库里，但客户端如果没明确告诉它“去哪验证”，就会默认查当前连接的数据库（比如 myapp），结果找不到用户，连接卡住或超时假死。
常见错误现象：SocketTimeoutException、Authentication failed 但日志里没报错、应用线程长时间阻塞在 mongoClient.connect()。
- Java 驱动必须显式指定
authSource=admin，哪怕你连的是mongodb://user:pass@host:27017/myapp?authSource=admin - Node.js 的
MongoClient同样要加?authSource=admin，否则即使用户名密码对，也会在握手阶段 hang 住 - Python 的
pymongo.MongoClient如果用字典传参，得写authSource='admin'，不能只靠 URI 里的数据库名
mongod 启动时没配 --auth 或配置文件漏了 security.authorization: enabled
看起来开了认证，其实压根没生效——这时候应用能连上，但一执行带权限的操作（比如写某个 collection）就失败，表现像“部分功能突然不可用”，容易误判为网络或代码问题。
检查方法很简单：进 mongo shell 运行 db.runCommand({connectionStatus: 1})，看返回里 authInfo.authenticatedUsers 是否为空；或者直接 db.adminCommand({getCmdLineOpts: 1}) 确认 security.authorization 是不是 true。
- Linux 下用
ps aux | grep mongod查进程参数，确认有没有--auth - Docker 启动记得加
-e MONGO_INITDB_ROOT_USERNAME并挂载配置文件，否则docker run mongo --auth不生效（因为 entrypoint 覆盖了命令） - 配置文件里如果写了
security:但缩进不对（YAML 对空格敏感），mongod会静默忽略 authorization 配置
应用复用连接但没处理认证失败后的重连逻辑
很多框架（如 Spring Boot 的 spring-boot-starter-data-mongodb）默认开启连接池，一旦某次认证失败（比如密钥轮换后没更新配置），连接池里已有连接可能处于半死状态，后续请求持续 fallback 到这些连接，造成大面积假死。
这不是 MongoDB 本身的问题，而是客户端没主动清理失效连接，导致请求一直等在旧连接上。
- Java 驱动建议设
maxConnectionLifeTimeMS和maxConnectionIdleTimeMS，强制回收老连接 - Node.js 的
MongoClient要监听serverHeartbeatFailed事件，必要时手动close()再重建 - Python 的
pymongo在connect=False模式下不会预热连接，但首次操作仍可能卡住，建议加serverSelectionTimeoutMS=5000防止无限等待
副本集环境下 authSource 指向了非主节点的本地 admin
副本集里每个节点都有自己的 admin 数据库，但用户必须在主节点上创建，并且所有节点的 admin 用户数据要同步。如果误在从节点上建用户，或者没启用 keyFile / x.509 做内部认证，从节点无法拉取用户数据，客户端连到从节点时就会认证失败或卡住。
典型表现：应用偶尔正常、偶尔超时，重启服务后暂时恢复，过一阵又出问题——其实是读请求被路由到了没同步好用户的从节点。
- 务必在主节点上运行
db.createUser(...)，并确认rs.status().members[n].stateStr === "PRIMARY" - 检查
rs.conf()里各成员是否都开启了security.authorization: enabled - 避免用
readPreference=secondary连接带认证的副本集，除非你确定所有节点的用户表完全一致
最麻烦的不是配不配得上，而是认证失败时不报错、不抛异常、只卡住——这种“静默失败”会让排查绕很大一圈。盯住连接字符串、启动参数、副本集一致性这三处，基本就能定位八成问题。
