bindip 配置为 0.0.0.0 或留空即等于主动暴露 mongodb 至公网，99% 的爆破事件源于此；须限定为 127.0.0.1 或内网 ip，配合防火墙及重启生效验证。
直接结论：bindIp 配置成 0.0.0.0 或留空 = 主动把 mongod 暴露在公网，99% 的 MongoDB 被爆破事件都源于此，和密码强弱无关。
检查 /etc/mongod.conf 中的 net.bindIp 是否安全
打开配置文件，定位到 net 区块，重点看 bindIp 的值：
- ✅ 正确写法（仅允许本地或内网访问）：
bindIp: 127.0.0.1,192.168.1.100（多个 IP 用英文逗号分隔） - ❌ 危险写法：
bindIp: 0.0.0.0、bindIp: ""（空字符串）、bindIp: ::,0.0.0.0、或压根没写这一行（默认行为因版本而异，但新版默认只绑localhost，老版本可能隐式绑全部） - ⚠️ 注意：即使你写了
127.0.0.1，但如果同时启用了net.bindIpAll: true，它会覆盖bindIp并强制监听所有地址
改完配置后必须重启 mongod 才生效
很多人改了 /etc/mongod.conf 就以为完事了，其实不重启等于没改：
- 执行
sudo systemctl restart mongod（systemd 系统）或sudo service mongod restart（SysVinit） - 验证是否生效：
sudo ss -tlnp | grep :27017，输出中应只出现127.0.0.1:27017或你指定的内网 IP，**绝不能出现*:27017或0.0.0.0:27017** - 如果重启失败，常见原因是配置语法错误（比如多了一个冒号、缩进不对），用
mongod --config /etc/mongod.conf --dryRun可提前校验
bindIp 和防火墙必须双保险
仅靠 bindIp 不够 —— 它只是应用层绑定，一旦配置错、被覆盖、或进程被劫持，端口仍可能暴露。防火墙是最后一道防线：
- Linux 上用
ufw：运行sudo ufw deny 27017，再sudo ufw allow from 192.168.1.0/24 to any port 27017（按需放行内网段） - 确认
ufw status显示规则已启用，且Status: active - Windows 用户请检查
Windows Defender 防火墙入站规则，禁用所有对TCP 27017的“公用”配置文件允许项 - 云服务器（如 AWS/Aliyun）额外检查安全组，确保 27017 端口未对
0.0.0.0/0开放
别忽略 bindIpAll 和命令行参数的干扰
bindIpAll: true 是个“静默炸弹”，它优先级高于 bindIp，而且容易被忽略：
- 搜索配置文件里是否有
bindIpAll: true或bind_ip_all字样，有就删掉或设为false - 检查启动命令（
ps aux | grep mongod），确认没有带--bind_ip_all或--bind_ip 0.0.0.0这类参数 —— 命令行参数会覆盖配置文件 - 如果你用的是 Docker，检查
docker run是否加了-p 27017:27017；容器内bindIp: 127.0.0.1也挡不住宿主机端口映射
最常被忽略的一点：配置改对了、防火墙开了、ss 看起来也正常，但数据库仍能从公网连上 —— 很可能是云厂商的安全组或 NAT 网关做了端口转发，绕过了本机防火墙和 bindIp。这类基础设施层的暴露，得去对应控制台查，不是改 mongod.conf 能解决的。
