必须先在无认证状态下创建admin库的root用户再启用authorization，否则无法登录；创建时role必须为{role:"root",db:"admin"}，配置需正确缩进并重启服务验证。
启用认证前必须先创建管理员用户
很多人在配置文件里加了 security.authorization: enabled 就直接重启服务，结果连 mongosh 都进不去——因为启用认证后，所有操作（包括创建用户）都要求已认证，而此时还没任何用户。正确顺序是：先不启用认证，连接本地 mongosh，在 admin 库中创建管理员用户，再改配置、重启。
常见错误现象：mongosh -u admin -p xxx --authenticationDatabase admin 报错 Authentication failed，但其实根本没创建过这个用户；或者重启后连 mongosh 都提示 not authorized on admin to execute command，说明认证已生效但无可用凭据。
- 务必先用无认证方式连接：
mongosh（不带-u），再执行use admin - 创建用户时角色必须含管理权限，推荐用
root或userAdminAnyDatabase，不要只写字符串"root"，要写完整对象：{role: "root", db: "admin"} - 密码不能太弱，MongoDB 6.0+ 会拒绝
123456、password等常见弱口令
监听地址必须显式放开，不能只靠注释 bind_ip
bind_ip 默认值是 127.0.0.1，意味着只接受本机连接。即使开了认证，远程客户端仍会卡在“连接被拒绝”或超时。仅注释掉 bind_ip = 127.0.0.1 行是不够的——MongoDB 会 fallback 到默认值，不会自动监听 0.0.0.0。
正确做法是明确指定监听地址：
- 允许所有 IPv4 地址：
net.bindIp: 0.0.0.0 - 允许多个具体 IP（如内网 + 云服务器公网）：
net.bindIp: 127.0.0.1,192.168.1.100,10.0.0.5 - 若需 IPv6，必须同时写
::1，例如：net.bindIp: 127.0.0.1,::1,0.0.0.0
注意：Linux 下修改 /etc/mongod.conf 后，需确认 YAML 缩进正确（net: 和 security: 是同级顶格），否则服务启动失败且日志只报 Failed to parse config，不提示哪行出错。
远程连接命令和连接字符串里的 authenticationDatabase 很关键
用户是在哪个数据库里创建的，就必须用哪个库做认证入口。比如你在 admin 库执行了 db.createUser(...)，那么连接时 --authenticationDatabase admin 就不能写成 test 或省略——否则认证直接失败，和密码对错无关。
常见误用场景：
- 用
mongosh -u myuser -p pwd -d mydb连接，但用户实际建在admin库 → 报错Authentication failed - Node.js 用
mongodb://myuser:pwd@host:27017/mydb，没指定认证库 → 默认用mydb认证，失败 - 正确写法：
mongodb://myuser:pwd@host:27017/mydb?authSource=admin（authSource即--authenticationDatabase）
防火墙和云服务器安全组是最后一道关卡
配置完 bindIp 和认证，仍连不上？大概率是网络层拦截。MongoDB 默认端口 27017 必须显式放行：
- Ubuntu/Debian：
sudo ufw allow 27017（如果启用了 ufw） - CentOS/RHEL：
sudo firewall-cmd --permanent --add-port=27017/tcp && sudo firewall-cmd --reload - 阿里云/腾讯云/AWS：必须在控制台的安全组规则里添加入方向规则，协议 TCP，端口
27017，源 IP 建议限制为可信段（如192.168.1.0/24），而非全放开0.0.0.0/0
容易被忽略的一点：有些云厂商的“内网互通”默认不开启，即使两台机器在同一 VPC，也需额外配置安全组互信或网络 ACL 规则。测试时可先用 telnet your-server-ip 27017 确认端口可达，再排查认证逻辑。
