MongoDB 加上业务库名后 Authentication failed：核对 authSource

MongoDB 连接串不带库名时能登录，加上 /appdb 后却报 Authentication failed，先检查 authSource。对使用用户名、密码的连接，未显式指定认证库时，URI 中的数据库部分会参与决定去哪里查找用户。

例如，同一账号能连接 mongodb://db.example.net:27017/，却不能连接 /appdb，而用户实际创建在 admin，可以保留业务库并显式指定 authSource=admin。这个判断成立的前提是两次连接指向同一套实例、使用相同凭据，并且用户确实属于 admin。

本文针对自建 MongoDB 的 SCRAM 用户认证。外部认证机制、Atlas 用户管理和 SRV DNS 配置有各自规则，不能一律套用 admin。

用户所属的库与业务操作的库可以不同

MongoDB 用户是在某个数据库中创建的，其身份包含用户名和认证数据库。用户可以在其他库拥有角色，因此认证库不能从“应用要读写哪个库”推断。

对普通用户名、密码 URI，认证库的选择顺序是：显式的 authSource 优先；没有它时使用 URI 的数据库部分；两者都没有时使用 admin。这解释了为什么增加业务库名会改变认证结果。

以下是连接配置示例，账号、地址和库名均需替换。密码由程序的独立凭据配置提供，不写进示例 URL：

mongodb://db.example.net:27017/appdb?authSource=admin

它把 appdb 留作默认业务库，把 admin 作为认证库。若用户是在 appdb 中创建的，应使用 authSource=appdb。不存在“改成 admin 总能解决”的规则。

用已有管理连接确认用户在哪个库

管理员可在已有合法连接中执行以下只读检查示例：

db.getSiblingDB("admin").getUser("app_user")
db.getSiblingDB("appdb").getUser("app_user")

查看其他用户通常需要对应数据库上的 viewUser 权限；不要把查询失败误读成用户不存在。返回的用户记录包含 db 与 roles，分别用于确认认证库和授权范围；返回 null 表示该查询位置没有这个用户。

同名用户可以存在于不同认证库，并具有不同密码与权限。应确认应用本来要使用哪一个，而不是创建第二个同名用户去凑连接成功。

MongoDB 官方容器的 MONGO_INITDB_ROOT_USERNAME 与 MONGO_INITDB_ROOT_PASSWORD 在初始化新数据目录时创建的管理用户属于 admin。设置 MONGO_INITDB_DATABASE 不会把该管理用户迁移到业务库，修改初始化变量也不能自动修改已有数据目录中的账号。不要通过删除数据卷修复认证库选择问题。

脱离 URI 密码编码，单独核对认证

使用 mongosh 可以让密码交互输入，减少 URI 特殊字符与日志泄露的干扰。下面是用户在 admin 的示例：

mongosh "mongodb://db.example.net:27017/appdb?authSource=admin" \
  --username app_user --password

远程环境原本要求 TLS、证书或副本集参数时，应一并保留，不能为了诊断删掉这些条件。每次比较使用新进程，避免在已有会话叠加不同用户权限。

若这样能连接而程序仍失败，检查程序最终生效的 authSource、凭据字段与驱动选项。密码含 $ : / ? # [ ] @ 且嵌入 URI 时，需要百分号编码；只编码用户名、密码部分，不能把整个 URI 一起编码。已经编码的凭据不要再编码一次。

若明确指定正确认证库仍失败，回到账号密码、实际实例、认证机制和账号限制检查。容器内服务端口与宿主机映射端口可能连接到不同实例；连接目标不一致时，反复修改 authSource 没有意义。

能认证但不能读写，需要检查角色

连接成功后，可以查看当前连接的身份，示例：

db.runCommand({ connectionStatus: 1 })

authInfo.authenticatedUsers 中应出现预期用户及其认证库。然后在应用本来需要访问的库中，确认角色覆盖实际操作。

如果错误变成 not authorized on appdb，认证已经通过，但目标操作缺权限。不要继续改密码或认证库，也不要直接赋予 root。由管理员按业务读写、迁移和维护需求分别分配权限。

应用不宜长期使用容器初始化的管理账号。需要迁移为专用账号时，先保留原配置和有效管理连接，为专用账号授予明确业务权限，再逐个切换应用实例。切换失败可暂时恢复原应用凭据；确认新账号工作正常后再处理旧权限，避免提前删除管理入口。

处理完成的标准是新连接能通过认证，当前身份属于预期认证库，且应用所需操作在目标业务库中成功。只看到 shell 提示符，或使用管理账号测试成功，都不足以证明应用配置已经修复。