MongoDB 驱动在建立 TCP 连接之前，必须把连接字符串中的主机名交给操作系统做 DNS 解析。如果解析返回 NXDOMAIN、查询超时或者只拿到无法路由的回环地址，驱动就会抛出 1160 错误。这个错误最典型的特点是数据库进程本身没有异常，mongod 日志也不会记录连接失败，因为客户端请求压根没有到达 27017 端口。排查时要把重心放在客户端配置、DNS 服务链和主机名拼写上，而不是急着重启数据库。
第一步：确认错误码 1160 的触发位置
在 MongoDB 官方驱动和 mongosh 中，错误码 1160 通常会伴随 DNS resolution failed 或 Could not resolve host 等说明。它可能由连接字符串里的主机名拼写错误触发，例如把 mongo-prod.internal 写成 mongo-prod.internal.（多了一个点）或 mongo_prod.internal。这类错误在测试环境切换到生产环境时非常常见，因为不同环境使用了不同的内部域名。
另一个容易被忽略的触发点是 MongoDB 复制集。如果连接字符串里填写的是复制集名称，客户端会先解析第一个节点，再根据 replicaSet 参数获取成员列表。若成员列表中的主机名在客户端机器上无法解析，即使主节点本身可以连接，驱动仍然可能报 1160 错误。因此不能只看直接连接是否成功，还要确认所有副本集节点名称都能被当前环境解析。
# 直接连接单个节点，先排除复制集干扰 mongosh "mongodb://appuser:apppass@mongo-node1.internal:27017/appdb?authSource=admin" # 复制集连接串必须保证所有节点都可解析 mongosh "mongodb://appuser:apppass@mongo-node1.internal:27017,mongo-node2.internal:27017/appdb?replicaSet=rs0&authSource=admin"
如果上面第二条命令报 1160，可以逐个验证 mongo-node1.internal 和 mongo-node2.internal 的解析结果。只有所有节点在客户端侧都解析成功，复制集连接才会稳定。
第二步：用系统命令逐层验证 DNS 解析链路
出现 1160 后，第一件事是确认系统解析器能否正确返回 IP。Linux 和 macOS 可以使用 nslookup、dig 或 host 命令，Windows 可以优先使用 nslookup。如果这些命令返回 NXDOMAIN，说明 DNS 服务器上确实没有对应记录；如果返回超时，则需要检查 DNS 服务器地址是否可达、防火墙是否放行 53 端口。
# Linux 下查看解析结果 nslookup mongo-prod.internal # 查看详细解析过程，确认使用的是哪台 DNS 服务器 dig mongo-prod.internal # 简单测试网络层是否已经阻断了 DNS 查询 ping -c 2 10.0.0.53
如果 nslookup 在命令行里能解析成功，但 MongoDB 仍然报 1160，还需要检查应用运行环境和命令行环境是否使用同一套网络配置。容器场景尤其典型：宿主机能解析某个内网域名，不代表容器内部也能解析，因为容器可能使用了不同的 /etc/resolv.conf，或者没有继承宿主机的搜索域。可以进入容器执行同一条 nslookup 命令进行对照。
解析成功但连接失败的情况还可能是 IPv6 与 IPv4 的选择问题。某些系统会优先返回 IPv6 地址，而 MongoDB 实例只监听了 IPv4。如果 dig 查询返回的是 AAAA 记录，而数据库实际绑定在 0.0.0.0，就可能表现为 1160 或连接超时。此时可以在连接字符串中直接使用 IPv4 地址测试，或者调整系统解析优先级。
第三步：修复连接字符串、hosts 文件和复制集配置
最快的恢复方式是先绕过 DNS，直接在连接字符串里写 IP 地址。对于单节点连接，只要网络可达，使用 10.0.0.8:27017 就能绕过域名解析环节。但要注意，如果 MongoDB 启用了 TLS，证书中的 SAN 通常包含的是域名而不是 IP，直接写 IP 可能导致证书校验失败。此时应该优先修复 DNS 记录，保证域名可用。
# 临时绕过 DNS 解析，直连 IP mongosh "mongodb://appuser:apppass@10.0.0.8:27017/appdb?authSource=admin" # 如果启用了 TLS，需要确认证书允许该 IP mongosh "mongodb://appuser:apppass@10.0.0.8:27017/appdb?tls=true&authSource=admin"
在内部开发或测试环境中，可以手动维护解析记录。Linux 下编辑 /etc/hosts，Windows 下编辑 C:\Windows\System32\drivers\etc\hosts，追加一条类似 10.0.0.8 mongo-prod.internal 的记录。保存后可以用 ping mongo-prod.internal 验证。若修改 hosts 后仍然报错，Windows 还需要执行 ipconfig /flushdns 清除本地 DNS 缓存，Linux 通常不需要但可以重启网络服务。
对于复制集，强烈建议在初始化时使用所有节点都能解析的标准主机名，而不是 IP 或短主机名。如果 init 配置中写成了 node1，客户端连接时也会收到 node1:27017，如果客户端环境里没有 node1 的解析记录，就会再次触发 1160。需要修改成员主机名时，可以使用 rs.reconfig 更新，确保每个节点的 host 字段与 DNS 记录完全一致。
# 重新配置复制集成员主机名
rs.reconfig({
_id: "rs0",
members: [
{ _id: 0, host: "mongo-node1.internal:27017" },
{ _id: 1, host: "mongo-node2.internal:27017" },
{ _id: 2, host: "mongo-node3.internal:27017" }
]
})
最后，如果应用部署在 Kubernetes 或 Docker Compose 中，要确认服务名是否与 MongoDB 主机名一致。容器内部的 DNS 通常由编排系统维护，服务名拼写错误、Pod 重启后 DNS 记录未更新、或者使用了带命名空间的短名称，都可能产生 1160。将客户端和数据库放在同一网络或同一个 namespace 下，并用完整服务名连接，通常可以避免这类问题。
MongoDB故障码1160DNS解析失败MongoDB连接错误修改时间：2026-09-21 18:38:33