根本原因是Navicat 17（≤17.0.12）不支持MongoDB 6.0+默认的SCRAM-SHA-256协议，需在mongod.conf中设置disableScramSHA256:true、重启服务，并删除旧用户后以mechanisms:["SCRAM-SHA-1"]重建用户。
Navicat 17 连接本地 MongoDB 报 “connection refused” 的根本原因
不是 Navicat 17 本身坏了，而是它默认尝试走 SCRAM-SHA-256 认证协议，而你本地 MongoDB（尤其是 6.0+ 版本）虽启用了认证，但 Navicat 17 桌面版（≤17.0.12）仍未完整支持该机制的握手流程——服务端拒绝建立连接，错误却只显示泛泛的 connection refused 或 No suitable servers found，掩盖了真实症结。
检查 MongoDB 是否真的在监听本地 27017（或你指定的端口）
很多人以为“本地运行了 mongod 就等于可连”，其实不然。必须确认服务端 socket 真实对外暴露：
- 运行
netstat -tuln | grep :27017（Linux/macOS）或netstat -ano | findstr :27017（Windows），看输出是否含0.0.0.0:27017或[::]:27017；若只有127.0.0.1:27017，说明只接受 localhost 回环连接，Navicat（即使运行在同一台机器）也可能因 DNS 解析、IPv6 优先等原因无法命中 - 检查配置文件中
bindIp是否为0.0.0.0（或显式包含你的本机 IP），而非注释状态或仍为127.0.0.1 - 若改过端口（比如用了
port: 27018），Navicat 连接字符串里必须显式写localhost:27018，不能只填localhost
为什么改了 bindIp 还是连不上？防火墙和端口占用常被忽略
即使 MongoDB 配置正确，两个底层拦路虎经常被跳过：
- Windows Defender 防火墙或第三方安全软件可能拦截了入站连接，哪怕只是本地回环流量。临时关闭防火墙测试一次，若立刻连通，就需添加入站规则放行
27017（TCP） - 端口被占：用
lsof -i :27017（macOS/Linux）或netstat -ano | findstr :27017查 PID，再kill -9 [pid]或taskkill /f /pid [pid]清理。常见冲突进程是旧版 mongod、其他数据库、甚至某些 IDE 的调试服务 - Docker 用户注意：如果 MongoDB 运行在容器内，且你用
docker run -p 27017:27017映射，还需确认容器内mongod配置的bindIp是0.0.0.0，否则只监听容器内部网络
Navicat 17 必须配合 MongoDB 降级到 SCRAM-SHA-1 才能稳定认证
这是最隐蔽也最关键的一步。MongoDB ≥6.0 默认禁用 SCRAM-SHA-1，但 Navicat 17 不会主动协商降级，服务端直接拒连。仅改客户端设置无效，必须动服务端：
- 编辑
/etc/mongod.conf（Linux）或mongod.cfg（Windows），在setParameter下添加：setParameter: disableScramSHA256: true scramIterationCount: 10000
- 重启服务：
sudo systemctl restart mongod（Linux）或 Windows 服务管理器中重启 - 删除旧用户（原哈希仍是 SHA-256 格式）：
use admin→db.dropUser("myuser") - 重建用户并强制指定机制：
db.createUser({user:"myuser", pwd:"mypass", roles:[{role:"readWrite", db:"test"}], mechanisms:["SCRAM-SHA-1"]}) - Navicat 连接时，“Authentication Database” 字段必须填
admin（或你创建用户时指定的库），不能为空
复杂点在于：这个降级不是“选一个选项”，而是服务端协议层的硬性切换；一旦漏掉重建用户这步，新配置对旧凭证完全无效——看起来一切配对，实际密码校验永远失败。
