SASL认证失败表明服务端已接收请求但拒绝挑战响应，主因是SCRAM-SHA-1与SHA-256机制错配或authSource未正确指定为admin库，密码需URL编码，且需确认服务端支持的认证机制及副本集同步状态。
连接时提示 SASL authentication failed 是什么信号
这不是网络不通或服务未启动的错误，而是认证流程卡在 SASL 协商阶段——服务端已收到请求，但拒绝了客户端发来的挑战响应。核心问题几乎都落在 SCRAM-SHA-1 与 SCRAM-SHA-256 的机制错配，或者客户端根本没把认证凭据送到对的地方。
authSource 不指定就默认去目标库找用户？
MongoDB 用户账户不绑定在业务数据库里，而是存在特定认证源库（通常是 admin）。如果连接字符串写成 mongodb://u:p@host:27017/mydb，多数驱动（包括 Node.js 的 mongodb、Go 的 mgo）会默认用 mydb 作为 authSource，结果就是“用户不存在”。
- 必须显式加
?authSource=admin（除非你真在mydb里创建了用户） - 密码含
@、:、/等字符时，得先做 URL 编码，否则解析直接截断 - 用
mongosh测试时，别只试mongosh "mongodb://..."，要加上--eval "db.runCommand({connectionStatus: 1})"看实际认证库是否命中
SCRAM-SHA-1 和 SCRAM-SHA-256 怎么判断该用哪个
从 MongoDB 4.0 开始支持 SCRAM-SHA-256，5.0+ 默认启用它；但很多旧应用、容器镜像、或云服务（如早期 Atlas 实例）仍跑在 SCRAM-SHA-1 模式下。服务端不会主动告诉客户端“我只认 SHA-256”，它只会静默拒绝不匹配的协商包。
- 查服务端配置：登录后执行
db.runCommand({getCmdLineOpts: 1})，看parsed.security.authenticationMechanisms字段 - 驱动端强制指定：在连接串末尾加
&authMechanism=SCRAM-SHA-256（注意是&，不是?） - Node.js 客户端若用老版
mongodb@3.x，默认不发 SHA-256，必须升级到@4.0+或手动设authMechanism - Docker 部署时，
mongod启动参数里若漏了--setParameter authenticationMechanisms=SCRAM-SHA-1,SCRAM-SHA-256，新驱动连不上旧机制
副本集里新用户连不上 secondary 节点？
用户数据写入 primary 后，需同步到所有节点的 admin 库才生效。如果刚 db.createUser(...) 就立刻连 secondary，可能因复制延迟导致认证失败——这不是协议问题，是状态没跟上。
- 检查同步状态：
rs.status().members[n].stateStr应为SECONDARY，且optimeDate与 primary 接近 - 临时绕过：连接时加
&readPreference=primary，确保只打主节点 - 长期方案：等
rs.printSecondaryReplicationInfo()显示延迟
最常被忽略的一点：改完 mongod.conf 或启动参数后，只 reload 不够，必须 kill -SIGTERM 再启进程，否则 authenticationMechanisms 设置不生效。
