MongoDB 3.6起默认仅绑定localhost，是为堵住旧版绑定0.0.0.0导致公网暴露删库的风险；需显式配置net.bindIp并同步启用认证、防火墙放行及正确建用户，方能安全开放远程访问。
MongoDB 3.6 及以上版本默认只监听 localhost，不是 bug，是明确的安全加固行为——它直接堵死了“装完就能被公网扫到并拖库”的高危路径。
为什么 3.6 改成只绑 localhost？
因为 3.6 之前（尤其是通过非官方包安装的旧版本），mongod 默认绑定 0.0.0.0，意味着一启动就暴露在所有网络接口上。没有密码、没开防火墙、没改端口，黑客用 nmap 扫一遍 27017 就能连上删库。3.6 把这个默认行为统一收窄为仅 localhost，强制用户显式声明“我需要谁来连”，属于防御性设计。
常见错误现象：
- 本地用
mongo --host 192.168.1.100连不上，报connection refused - 同一台机器上用
mongo --host 127.0.0.1能连，但换成本机 IP 就失败 - Docker 容器内应用连宿主机 MongoDB 失败，但宿主机
mongoshell 能用
如何安全地放开 bind_ip？
放开监听不能只改 bind_ip，必须同步做最小化授权。否则等于把门打开又不锁柜子。
实操建议：
- 优先用
net.bindIp: localhost,172.16.0.5（填你内网实际 IP），不要写0.0.0.0或启用bind_ip_all: true - 如果走 Docker，宿主机 MongoDB 想被容器访问，
bind_ip至少得包含宿主机在 docker0 网桥上的地址（如172.17.0.1），而非仅localhost - 修改配置后必须重启
mongod，systemctl reload mongod不生效 - 确认生效：运行
lsof -i :27017或ss -tlnp | grep 27017，看 LISTEN 地址是否含你指定的 IP
放开 bind_ip 后为什么还连不上？
大概率卡在下一层：认证没开、防火墙拦了、或客户端连错了库。
关键检查点：
- 是否启用了访问控制？
security.authorization: enabled必须设为true，否则即使能连，也进不了带权限的库 - Linux 防火墙（
ufw/firewalld）是否放行 27017？仅改 MongoDB 配置不够 - 创建管理员用户时，是否在
admin库下执行？3.6+ 默认连接库是test，但db.createUser()在test下建的是 test 库用户，不是全局 admin - 远程连接命令是否带认证参数？例如：
mongo --host 192.168.1.100 --authenticationDatabase admin -u myuser -p
IPv6 场景下容易忽略的细节
只要配置里有 net.ipv6: true 或启动加了 --ipv6，mongod 会自动额外监听 ::1（IPv6 的 localhost）。这本身没问题，但容易掩盖真实问题：
- 你以为自己绑了
0.0.0.0，结果lsof显示只监听::1和127.0.0.1——说明bind_ip根本没生效，可能配置文件路径错、格式缩进错、或被 include 覆盖 - 某些云主机禁用 IPv6，但 MongoDB 因
--ipv6参数启动失败，日志里报Failed to set up listener: Address not available，此时必须显式关掉net.ipv6
真正要对外提供服务时，bind_ip 的值、防火墙规则、认证开关、用户创建库这四者必须全部对齐，漏一环都会表现为“连得上但登不进”或“根本连不上”。安全不是单点配置，是一条链。
