连接MongoDB时如果直接抛出 Connection refused 或 Authentication failed，通常不是服务端崩溃这么简单，而是进程状态、网络策略、绑定配置或认证信息中某个环节没有打通。遇到这种情况，如果上来就重启服务器或重装数据库，往往会掩盖真正的根因。建议按照从底层到应用层的顺序逐项检查，先确认服务是否存活，再看端口和网络通路，最后核对认证参数与驱动版本。本文整理了一套适用于 Linux 和 Windows 环境的排查思路，尽量减少无效操作。
下面将分五个环节展开，每个环节都给出可执行的命令和判断依据。
一、确认mongod进程是否真正存活
在 Linux 系统中，先执行 sudo systemctl status mongod 查看服务状态。如果输出里显示 active (running)，说明服务在运行；如果显示 inactive、failed 或 exited，就需要先看启动失败的原因。此时不要盲目执行 restart，因为如果配置有语法错误，restart 只会再次失败。正确做法是查看日志文件，通常位于 /var/log/mongodb/mongod.log。用 sudo tail -n 50 /var/log/mongodb/mongod.log 可以看到最后几十行记录，常见错误包括数据目录权限不足、缺少 keyfile、配置文件缩进错误或端口被其他进程占用。
Windows 环境可以打开服务管理器，搜索 MongoDB Server 服务，看状态是否为“正在运行”。也可以打开命令提示符执行 tasklist | findstr mongod，如果没有输出说明进程不存在。启动失败时事件查看器里的应用程序日志会留下痕迹，但更直接的方式是手工在前台启动一次："C:\Program Files\MongoDB\Server\7.0\bin\mongod.exe" --config "C:\Program Files\MongoDB\Server\7.0\bin\mongod.cfg"，终端会立刻打印出错误原因。很多情况下，dbPath 目录不存在或权限不对，就会在这里暴露出来。
还有一种情况是进程存在，但并没有处于监听状态，比如启动过程中卡在初始化或正在恢复大量数据。此时可以用 ps aux | grep mongod 确认进程是否占用 CPU，或者看日志是否有“waiting for connections”字样。只有看到这个提示，才说明 mongod 已经准备好接受连接。如果日志停在前面的步骤，需要先解决启动阶段的报错，而不是继续排查网络。
二、检查端口监听与客户端连接参数
服务确认存活后，下一步是检查 mongod 实际监听的端口。默认端口是 27017，但生产环境经常修改。Linux 执行 ss -lntp | grep 27017 或 netstat -lntp | grep 27017，Windows 执行 netstat -ano | findstr 27017。如果没有任何输出，说明 mongod 没有监听这个端口，可能是配置文件里 port 设置为其他值，或 bindIp 导致只监听在回环地址。客户端连接字符串中的端口必须与服务端一致，例如 mongosh "mongodb://192.168.1.10:27018" 连接的是 27018，如果服务在 27017 上就会超时。
可以使用简单的 TCP 连通性测试快速验证网络链路是否通：Linux 下 nc -zv 127.0.0.1 27017，Windows PowerShell 下 Test-NetConnection -ComputerName 127.0.0.1 -Port 27017。如果 TCP 能通但 Mongo 协议层握手失败，可能是驱动或认证问题；如果 TCP 都不通，则问题在网络或防火墙。连接字符串方面要注意副本集格式：mongodb://host1:27017,host2:27017/?replicaSet=rs0。如果忘记指定 replicaSet，驱动可能默认直连第一台主机，在副本集主节点切换时就会连接失败。
下面是一个用 Node.js 驱动测试连接的最小示例，适合在应用侧快速验证：
const { MongoClient } = require('mongodb');
const uri = 'mongodb://admin:password@127.0.0.1:27017/admin?retryWrites=true&w=majority';
const client = new MongoClient(uri, { serverSelectionTimeoutMS: 5000 });
async function testConnection() {
try {
await client.connect();
console.log('连接成功');
} catch (err) {
console.error('连接失败:', err.message);
} finally {
await client.close();
}
}
testConnection();
三、绑定地址和防火墙是常见拦路虎
mongod.conf 中的 bindIp 默认值是 127.0.0.1，也就是只允许本机连接。如果应用部署在其他服务器上，这个默认值会直接导致跨机连接失败。修改配置前先确认应用与数据库是否在同一台机器，如果不在，需要把 bindIp 改成 0.0.0.0 或具体的内网地址。配置文件片段如下：
net: port: 27017 bindIp: 0.0.0.0
修改后执行 sudo systemctl restart mongod 重启服务。0.0.0.0 表示监听所有网卡，方便测试，但也意味着任何能访问到这台机器的来源都可以尝试连接，所以必须配合防火墙规则限制来源 IP。
Linux 的防火墙可能由 firewalld 或 ufw 管理。使用 ufw 时，可以执行 sudo ufw allow from 192.168.1.0/24 to any port 27017，只放行内网网段。云服务器还要检查安全组入方向规则，是否放行了 TCP 27017 端口。很多开发者在本地用 localhost 测试正常，部署到云主机后连不上，就是因为安全组默认只开放 22、80、443 等常用端口。此时可以通过 telnet 公网IP 27017 快速判断：如果一直等待或直接拒绝，大概率是安全组拦截。
使用 Docker 部署时还要注意端口映射和容器内绑定地址的叠加影响。例如执行 docker run -d -p 27017:27017 mongo，宿主机端口虽然映射了，但如果容器内 MongoDB 配置的 bindIp 是 127.0.0.1，容器外部仍然无法访问，因为映射流量到达容器后会被回环地址拒绝。此时需要进入容器检查监听情况，或直接通过环境变量设置绑定地址。多层网络环境下一层层用 docker exec 和 ss -lntp 确认，能避免在宿主机上消耗过多时间。
四、认证、权限与驱动版本问题
当 TCP 连接已经建立，但客户端报错 Authentication failed 或 not authorized，问题就转移到认证与权限层。MongoDB 启用认证后，连接字符串必须包含用户名、密码以及正确的认证库。例如管理员用户通常创建在 admin 库，连接时必须写成 mongosh "mongodb://admin:password@localhost:27017/admin"。如果省略最后的 /admin，驱动默认使用当前业务库作为认证库，用户就会因找不到对应记录而认证失败。普通数据库用户也需要用 authSource=admin 参数明确指定认证库，否则会出现表面密码正确但始终登录不上的情况。
权限不足是另一类典型问题。用户虽然能登录，但执行写入或管理命令时被拒绝，例如报错 not authorized on testdb to execute command。此时可以先在 mongo shell 中执行 db.auth("用户名", "密码") 验证登录是否成功，再用 db.runCommand({connectionStatus: 1}) 查看当前连接的用户和角色。管理员可以通过 db.getUser("用户名") 检查用户绑定了哪些角色。生产环境应当按最小权限原则分配角色，例如应用只需要读写某个库，就只授予 readWrite 角色，而不是把所有用户都设置成 root。
驱动与 MongoDB 服务端的版本兼容性也可能表现为连接失败。常见报错如 maximum wire version 6, but this version of the Node.js Driver requires at least 7，说明驱动要求的协议版本高于服务端支持的范围。解决思路是升级 MongoDB 服务端，或者把驱动降级到与服务端匹配的大版本。连接池耗尽也会导致间歇性无法获取连接，错误信息通常是 pool cleared 或 connection pool closed。此时需要检查应用的连接管理，确保客户端实例被复用，并设置合理的 serverSelectionTimeoutMS 和 maxPoolSize，避免短时间创建大量连接。
五、利用日志快速定位并建立排查习惯
排查到最后，日志仍然是最可靠的信息来源。mongod.log 会记录每一次连接尝试、认证结果以及心跳超时。Linux 下执行 tail -f /var/log/mongodb/mongod.log，然后让客户端发起连接，观察日志是否出现新的记录。如果日志没有任何变化，说明请求根本没有到达 MongoDB 服务端，问题在网络层、防火墙或绑定地址；如果日志出现 authentication failed 或 connection ended，说明请求已经到达，接下来要看认证信息或会话异常。Windows 下日志默认位于安装目录的 log 文件夹中，也可以在 mongod.cfg 的 systemLog.path 中查看具体位置。
可以整理成一条简单的排查决策链：先执行 systemctl status mongod 或 tasklist | findstr mongod 确认进程；再执行 ss -lntp | grep 27017 确认端口监听；接着用 nc 或 Test-NetConnection 测试 TCP；然后检查 mongod.conf 中的 bindIp 和防火墙规则；最后核对连接字符串、用户角色和驱动版本。按照这个顺序，大部分连接故障都能在几分钟内定位到具体环节。
另外建议在应用侧设置合理的超时和重试机制，避免数据库短暂重启导致服务雪崩。例如 Node.js 驱动可以配置 serverSelectionTimeoutMS: 5000，这样在服务不可用时能快速失败并记录日志，而不是让请求一直挂起。每次修改 MongoDB 配置前先备份原始文件，改完用 mongod --config /path/to/mongod.conf 做一次启动测试，确认无误后再重启正式服务。长期来看，这类习惯比出了问题到处找原因更有效。