根本原因是internalauth配置不一致：mongos未启用keyfile/x.509认证，而shard已启用，导致认证失败被静默拒绝；需三步验证——查mongos与shard的getcmdlineopts中keyfile配置是否一致、可读、内容字节相同，并检查mongos日志中的认证失败线索。
mongos 连不上 shard 的根本原因不是网络，而是 internalAuth 配置不一致
mongos 启动时若未正确配置 internalAuth（即 keyfile 或 x.509 内部认证），它会以“无认证模式”尝试连接 shard 节点；而 shard 若启用了 keyFile 或 x.509 认证（常见于生产分片集群），就会拒绝该连接，报错看似是超时或无法联系，实则是认证失败静默丢弃。这种问题在添加新 shard 后尤其高发——sh.addShard() 成功不代表 mongos 能连上，只代表 config server 记录了地址。
验证 internalAuth 是否生效的三步检查法
别猜，直接查运行时状态：
- 在 mongos 上执行
db.runCommand({getCmdLineOpts: 1})，检查返回中parsed.security.keyFile是否存在且路径可读；若为null或缺失，说明 mongos 未启用 internalAuth - 在目标 shard 的 primary 上执行相同命令，确认其
parsed.security.keyFile已设置且文件内容与 mongos 使用的完全一致（字节级相同） - 查看 mongos 日志（不是 config server 或 shard 日志），搜索关键词
"Failed to authenticate"或"No route to host"—— 后者常是认证失败后连接被内核重置的假象
keyFile 不一致的典型表现和修复动作
即使两个节点都配了 keyFile，只要内容不同、权限不对、路径不可读，就会导致 mongos 认证失败并 fallback 到无认证连接，进而被 shard 拒绝：
- 错误现象：
sh.status()显示 shard 状态为UNAVAILABLE或UNKNOWN，但telnet shard-host 27017网络通、rs.status()在 shard 上显示正常 - 关键区别：用
mongo --host shard-host:27017 -u __system -p $(cat /path/to/keyfile) --authenticationDatabase admin手动测试，能连通说明 shard 认证本身没问题，问题出在 mongos 配置 - 必须统一的操作：
chmod 400 /etc/mongod-keyfile（所有节点），且确保 mongos 启动时通过--keyFile参数或配置文件中的security.keyFile显式指定同一文件
为什么 sh.addShard() 成功后还要检查 internalAuth
sh.addShard() 只写 config server 的 config.shards 集合，不校验 mongos 是否真能连上 shard。一旦 internalAuth 失配，mongos 会在后台反复尝试连接并失败，但不会报错给用户，只会让后续查询卡在路由阶段——表现为 ShardNotFound 或长时间无响应。此时执行 flushRouterConfig 也无效，因为问题不在路由缓存，而在连接建立环节就断了。
