MongoDB分片集群的白名单不由mongos实现，必须依赖云平台安全组、系统防火墙等外层网络控制；mongos无内置IP过滤机制，其net.bindIp仅指定监听接口，不校验客户端IP。
mongos 自身配置实现的，它根本**不支持内置 IP 白名单机制**。所有对 mongos 的网络访问控制，必须落在外层——云平台安全组、系统防火墙或 MongoDB 实例级白名单上。
为什么 mongos 没有 bindIpAll 或 accessList 配置项
mongos 是无状态路由进程，设计上不处理认证前的 IP 过滤逻辑。它的 net.bindIp 仅决定监听哪些本地接口（如 127.0.0.1 或内网IP），但不会校验客户端来源是否在“白名单”里。试图在 mongos.conf 里加 accessControl.enabled: true 或类似字段，完全无效——该参数只对 mongod 生效。
-
mongos不读取security.authorization，也不加载用户角色体系 -
mongos的日志里不会出现 “client denied by IP filter” 类错误 - 所有“连不上 mongos”的现象，99% 出现在 TCP 层（连接超时/拒绝），而非 MongoDB 协议层（AuthenticationFailed）
阿里云 MongoDB 分片集群白名单实际生效位置
你在控制台看到的「白名单设置」页面，操作对象是整个分片集群实例（含所有 mongos、configsvr、shard 节点），但规则只作用于最外层的网络入口：即云厂商为该实例分配的公网/私网 VIP 所绑定的安全策略。
- 添加的 CIDR（如
192.168.10.0/24）会被映射为安全组入方向规则，限制的是流向mongos所在节点的 27017 端口流量 - 如果你用的是 ECS 内网直连，必须勾选「加载ECS内网IP添加」，否则即使 ECS 和 MongoDB 在同一 VPC，也会被拦截
- default 白名单分组不能删除，但可以编辑；新增分组名必须符合规则：
^[a-z][a-z0-9_]{1,31}[a-z0-9]$ - 填
0.0.0.0/0能通，但等于把mongos暴露在公网上——而mongos默认不启用认证，极易被暴力扫库
真正起作用的 Security 权限控制在 mongod 层
分片集群的数据安全防线不在 mongos，而在每个 shard 和 configsvr 的 mongod 进程上。它们必须开启访问控制，并通过密钥文件或 x.509 实现内部组件互信。
- 所有
mongod节点（shard + config）需统一配置security.keyFile: /data/key/security，且权限为600 -
mongos启动时必须指定--keyFile参数，否则无法连接到已启用内部认证的shard - 客户端连接
mongos时，仍需提供数据库用户凭证（如myapp用户），该用户权限由shard上的db.createUser()定义，mongos本身不存用户表 - 若跳过这步直接连
mongos，会收到错误：not authorized on admin to execute command { getCmdLineOpts: 1 }
连不上 mongos 的三个高频原因和对应检查点
别急着改配置文件，先确认链路是否通到底层。
- 用
telnet <mongos-ip> 27017测试端口可达性——不通？立刻查云平台白名单和 ECS 安全组 - 能 telnet 通但
mongosh --host <mongos-ip>:27017报错Authentication failed？说明mongos已连上shard，但客户端没传正确用户名密码，或用户没在admin库创建 - 连接成功却查不到分片数据（如
db.collection.find()返回空）？检查sh.status()是否显示 chunks 均衡、sh.addShard()是否执行成功，和白名单无关
