bindIp 必须显式指定具体IP或可解析主机名，不支持CIDR/通配符；仅设0.0.0.0依赖防火墙是危险误区，必须配合security.authorization和管理员用户启用认证，并通过mongosh实测连接与命令响应验证生效。
bindIp 配置项必须显式指定允许的 IP，不能只靠防火墙
MongoDB 默认监听 127.0.0.1，对外不可访问；但一旦开放外网，bindIp 就成了第一道防线。很多人误以为配了防火墙就安全了，其实 MongoDB 进程自己没绑对地址，请求根本到不了防火墙那层——它直接被内核丢弃或拒绝连接。
关键点是：bindIp 不支持 CIDR 或通配符（如 192.168.1.0/24），只能填逗号分隔的具体 IP 或主机名：
- 只允许本地 + 一个固定运维 IP：
bindIp: 127.0.0.1,192.168.1.105 - 想加域名？得确保该主机名能被
getaddrinfo()解析成功，否则启动失败报错：Failed to get address info for host xxx - 千万别写
bindIp: 0.0.0.0再指望靠iptables挡——这是典型“双保险变单薄纸”
必须配合 auth 身份验证，否则 bindIp 形同虚设
bindIp 只控制「谁能连上端口」，不控制「谁能在连上后干啥」。如果没开认证，任何能连上的 IP 都可以直接执行 db.dropDatabase()。
启用认证要两步缺一不可：
- 配置文件里打开：
security.authorization: enabled - 启动前必须已创建管理员用户（用
mongosh连localhost后执行db.createUser({user:"admin",pwd:"xxx",roles:["root"]})） - 重启后所有远程操作都需带凭证，例如：
mongosh "mongodb://admin:xxx@192.168.1.105:27017/admin?authSource=admin"
常见错误：改完配置重启服务，远程连不上，查日志发现是 Authentication failed —— 其实不是 IP 拦错了，是压根没建用户或 authSource 指错了库。
云环境要注意：bindIp 对 NAT、负载均衡无效
在 AWS EC2、阿里云 ECS 或 Docker 容器里，bindIp 绑的是实例内部网络接口的 IP。如果你走的是公网 SLB 或 Nginx 反向代理，MongoDB 看到的永远是内网转发 IP（比如 172.17.0.1），不是客户端真实 IP。
这意味着：
- 你不能靠
bindIp限制“某台办公电脑”，得靠安全组 / 网络 ACL / 容器网络策略 - Docker 启动时别用
--network=host，否则bindIp: 127.0.0.1会失效（宿主机 loopback 映射进容器） - Kubernetes 中建议用
NetworkPolicy限定 Pod 间通信，比单纯调bindIp更可靠
验证是否生效：别只 ping 端口，要用 mongosh 实测
很多人用 telnet 192.168.1.105 27017 或 nc -zv 测试，连得上就以为 OK —— 但这只说明 TCP 握手成功，不代表 MongoDB 真接收你的请求。
真正有效的验证方式是：
- 从被允许的 IP 执行：
mongosh --host 192.168.1.105 --eval "db.runCommand({ping:1})"，返回{ "ok" : 1 }才算通 - 从禁止的 IP 执行同样命令，应看到：
connect ECONNREFUSED 192.168.1.105:27017（未绑定）或Authentication failed（绑了但没权限） - 检查 MongoDB 日志：
grep "connection accepted" /var/log/mongodb/mongod.log，确认来源 IP 是否符合预期
最常被忽略的是：开发机和测试服务器可能在同一内网段，你以为封了公网就安全了，结果同事随手从 192.168.1.200 连上来删了测试库——因为那个 IP 正好在你写的 bindIp 列表里。
