根本原因是internalAuth配置不一致：mongos未启用keyFile/x.509认证而shard已启用，导致认证失败被静默拒绝；需三步验证——查mongos与shard的getCmdLineOpts中keyFile配置是否一致、可读、内容字节相同，并检查mongos日志中的认证失败线索。
分片集群认证失败，90%以上不是密码或用户权限问题，而是 internalAuth 配置不一致——mongos 和 shard 用的 keyFile 内容不同、路径不可读、或一方根本没配。这个问题不会报明确认证错误，只会静默断连，表现为 sh.status() 显示 shard 状态异常、查询卡住、flushRouterConfig 无效。
查 mongos 和 shard 的 getCmdLineOpts 是否启用 internalAuth
别看配置文件，直接查运行时参数：
- 在 mongos 上执行
db.runCommand({getCmdLineOpts: 1})，检查返回中parsed.security.keyFile是否存在且非null；若为undefined或空字符串，说明 mongos 启动时没传--keyFile或配置里没写 - 在每个 shard 的 primary 上执行同样命令，确认其
parsed.security.keyFile已设置，且路径与 mongos 使用的完全一致（注意：不是“看起来一样”，是同一文件或内容字节相同） - 如果 mongos 没配而 shard 配了，mongos 就会以无认证模式连接，shard 直接丢包，日志里只显示超时或 “No route to host”
验证 keyFile 内容和权限是否真正一致
即使两边都写了 --keyFile /etc/mongod-keyfile，也可能因以下原因失败：
-
cat /etc/mongod-keyfile | sha256sum在 mongos 和所有 shard 节点上运行，输出必须完全一致；差一个换行符都会失败 - 文件权限必须是
400（即chmod 400 /etc/mongod-keyfile），否则 mongod/mongos 启动时会忽略该 keyFile 并静默 fallback 到无认证 - 确保 mongos 进程对 keyFile 路径有读权限（比如用
sudo -u mongod cat /etc/mongod-keyfile测试）
盯紧 mongos 日志里的认证线索
出问题时，唯一能定位根因的日志来源是 mongos 自己的日志（不是 config server 或 shard 的）：
- 搜索关键词：
Failed to authenticate、Authentication failed、Unable to authenticate using SCRAM-SHA-1 - 若搜不到这些，但看到大量
connection refused或No route to host，大概率是 internalAuth 失配后连接被内核重置，属于假象 - 日志路径通常为
/var/log/mongodb/mongos.log，启动时加--logpath指定的为准
sh.addShard() 成功 ≠ mongos 能连上 shard
这个最容易被忽略：config server 只记地址，不校验连通性或认证有效性。
-
sh.addShard("rs0/shard1:27017")返回 { "ok" : 1 }，只代表 config.shards 插入成功，不代表 mongos 能建立连接 - 后续所有路由请求都会卡在连接建立阶段，现象是查询无响应、
sh.status()中 shard 显示UNKNOWN或状态为空 - 此时
flushRouterConfig没用——缓存没坏，是底层连接根本建不起来
真正要动手的地方就三处：mongos 启动参数、shard 的 keyFile 字节一致性、mongos 日志里那几行认证失败记录。其他地方调得再细，只要这三处不匹配，集群就永远处于“半瘫痪”状态。
