MongoDB故障码100认证失败怎么办？常见原因与解决方法详解

MongoDB进程异常退出，日志里赫然写着connect() failed with code 18 Authentication failed，控制台最后显示exit code 100，这是不少运维和开发人员都遇到过的问题。故障码100本身是一个泛化的退出码，表示MongoDB因为未捕获的异常或初始化失败而终止，认证失败是其中最常见的诱因之一。这篇文章围绕认证失败这一场景，把排查思路、常见误区和解决办法梳理清楚。

一、先看懂日志里的认证报错

遇到问题第一步不是急着改密码，而是打开日志确认真实原因。MongoDB的认证失败日志通常有几种典型形态。第一种是用户级连接失败：

{"t":{"$date":"2024-03-01T10:22:33.512+00:00"},"s":"W","c":"ACCESS","msg":"Failed to authenticate",
"attr":{"client":"192.168.1.105:52344","db":"admin","username":"root",
"mechanism":"SCRAM-SHA-256","error":"AuthenticationFailed"}} 

这条日志的信息量很大：db字段表示客户端尝试在哪个库上做认证，username是认证用户，mechanism是认证机制。如果日志里db显示的是test而你实际建的用户在admin库，那问题就一目了然了，客户端连的认证库不对。

第二种形态更隐蔽，mongod直接以exit code 100退出，日志中夹杂着Unrecognized field: security.authorization之类的配置错误。这说明问题根本不在密码，而是配置文件写错了键名或结构，导致实例初始化阶段就失败。所以看到100退出码，务必先翻日志末尾的s":"F"级别记录，确认到底是认证失败还是配置解析失败。

二、认证库与用户创建的常见误区

MongoDB的用户是绑定在特定数据库上的，这是和MySQL等关系型数据库很不一样的设计。很多人用下面的命令创建用户：

use admin
db.createUser({
  user: "appuser",
  pwd: "App@123456",
  roles: [ { role: "readWrite", db: "orderdb" } ]
})

这个用户appuser虽然授权操作的是orderdb，但用户本身存在于admin库。客户端连接时必须指定authenticationDatabase=admin，否则MongoDB会到默认的当前库去找用户，自然找不到，报认证失败。

连接串的正确写法应该是：

mongosh "mongodb://appuser:App%40123456@192.168.1.20:27017/orderdb?authSource=admin"

注意两点：一是密码中的特殊字符必须做URL编码，比如@要写成%40，否则URL解析会出错；二是authSource参数决定认证库，默认等于路径中的目标库，很多失败案例都栽在这里。用驱动连接时对应的是authSource或authenticationDatabase选项，写法略有差异但含义相同。

还有一个高频坑：在开启访问控制之前创建的用户，和开启security.authorization: enabled之后重新创建的用户，密码哈希机制可能不同。如果实例升级过版本，建议用db.changeUserPassword()重置一次密码，再验证登录。

三、认证机制不匹配带来的失败

MongoDB 4.0之后默认支持SCRAM-SHA-256，而老版本默认是SCRAM-SHA-1。如果客户端驱动太旧，只支持SHA-1，而服务端用户是用SHA-256创建的，握手阶段就会失败。可以在创建用户时显式指定机制：

db.createUser({
  user: "legacy_app",
  pwd: passwordPrompt(),
  roles: ["read"],
  mechanisms: [ "SCRAM-SHA-1" ]
})

反过来，也可以让用户同时支持两种机制，把mechanisms写成["SCRAM-SHA-1", "SCRAM-SHA-256"]，兼容新旧客户端。查看现有用户的认证机制可以用db.getUser("appuser")，返回结果中的mechanisms字段一目了然。

如果用的是副本集或分片集群，还要注意keyFile认证。keyFile权限必须是400或600，内容长度在6到1024个字符之间，且所有成员的keyFile必须完全一致。keyFile错误同样会让节点以非零码退出，日志中会出现Authentication failed或keyfile authentication failed的记录。检查方法很简单：

chmod 600 /etc/mongo/keyfile
ls -l /etc/mongo/keyfile
# 比对各节点keyfile的md5
md5sum /etc/mongo/keyfile

四、验证与兜底恢复手段

修改完成后，先用mongosh手动验证认证是否通过，再让应用重连：

mongosh --host 192.168.1.20 --port 27017 \
  -u appuser -p 'App@123456' \
  --authenticationDatabase admin \
  --eval 'db.runCommand({connectionStatus: 1})'

如果命令返回了authenticatedUsers数组且包含你的用户，说明认证链路已通。若仍然失败，在服务端开一个临时终端用mongosh --verbose观察ACCESS组件的日志输出，能看到具体的失败原因码。

最坏的情况是管理员密码丢失，谁也连不上。此时可以临时关闭授权启动实例来重置。修改配置文件，注释掉security.authorization相关配置，或以命令行参数覆盖：

mongod --config /etc/mongod.conf --fork
# 临时无授权模式（跳过配置中的authorization）
mongod --dbpath /data/db --port 27017 --bind_ip 127.0.0.1 --fork --noauth

进入后用db.changeUserPassword("root", "NewPass@2024")重置密码，然后恢复配置文件、重启实例即可。切记操作期间绑定127.0.0.1并尽快恢复授权，避免安全窗口扩大。按照日志定位、认证库核对、机制匹配、兜底重置这条链路走下来，绝大多数exit code 100的认证问题都能在十几分钟内解决。

MongoDB认证失败MongoDB故障码100MongoDB连接错误修改时间：2026-09-12 12:40:35