bindIp不是IP白名单，而是指定mongod监听的本地网卡地址列表；它决定服务在哪些IP上接受连接请求，不校验客户端来源IP，正确做法是显式列出所有合法通信IP（含127.0.0.1及各节点内网IP），并配合防火墙/安全组实现真正访问控制。
bindIp 不是白名单，是监听地址列表
很多人搜 bind_ip_whitelist，但 MongoDB 官方根本没有这个配置项。bindIp 的作用不是“过滤谁来连”，而是告诉 mongod 自己该在哪些网卡地址上开 socket。设成 bindIp: 127.0.0.1，它就只监听本地回环；设成 bindIp: 0.0.0.0，它就监听所有接口——但此时请求还没到防火墙那层，就已经由内核直接拒绝或丢弃了。
常见错误现象：
- 副本集节点配了
bindIp: 127.0.0.1，结果rs.status()显示其他成员状态为DOWN - 以为
bindIp: 0.0.0.0+ iptables 就安全了，却漏掉云平台的安全组规则，端口仍暴露在公网 - 用 hostname 写进
members数组，但没配/etc/hosts或 DNS，rs.initiate()直接报No host described in new configuration
正确写法：显式列出所有合法通信 IP
bindIp 不支持 CIDR（如 192.168.1.0/24）或通配符，只能填逗号分隔的具体 IP 或可解析主机名。每个节点的配置必须包含：
-
127.0.0.1（否则本地mongosh连不上） - 本机对外服务的 IP（如
192.168.1.10） - 其他副本集成员能访问它的 IP（即同网段内其他节点的 IP）
示例（三节点副本集）：
net: port: 27017 bindIp: 127.0.0.1,192.168.1.10,192.168.1.11,192.168.1.12
改完必须重启服务：systemctl restart mongod。重载配置（mongod --reload）对 bindIp 无效。
防火墙才是真正的访问控制层
bindIp 只决定进程听哪个地址，真正拦住非法 IP 的是系统或云平台防火墙。Ubuntu 上推荐用 ufw：
- 仅允许运维机访问：
sudo ufw allow from 192.168.1.105 to any port 27017 - 允许整个子网：
sudo ufw allow from 192.168.1.0/24 to any port 27017 - 务必加拒绝规则：
sudo ufw default deny incoming
云环境（AWS/Aliyun/ECS/Docker）要注意：bindIp 绑的是实例内部网络接口 IP。如果你走的是 SLB、Nginx 或容器网络，MongoDB 看到的永远是转发 IP（比如 172.17.0.1），不是客户端真实 IP。这时候靠 bindIp 限制“某台办公电脑”毫无意义，得靠安全组 / NetworkPolicy。
验证不能只靠 telnet，必须用 mongosh 实测
很多人用 telnet 192.168.1.105 27017 或 nc -zv 测试，连得上就以为 OK —— 但这只说明 TCP 握手成功，不代表 MongoDB 真接收你的连接请求或认证通过。
必须实测：
- 从被允许的 IP 执行：
mongosh "mongodb://admin:xxx@192.168.1.105:27017/admin?authSource=admin" - 从被禁止的 IP 执行同样命令，应返回连接拒绝或认证失败
- 查日志：
journalctl -u mongod -n 50 --no-pager，确认是否有connection refused或Authentication failed类错误
最容易被忽略的一点：bindIp 配错会导致连接根本建立不了；而认证失败（authSource 指错库、用户没建）看起来像 IP 被拦，其实只是权限问题。两者错误现象相似，但排查路径完全不同。
