当 Chrome 提示 ERR_NAME_NOT_RESOLVED：这其实是一次 DNS 解析失败

下文尽量用通俗的语言把浏览器网络栈、DNS 解析链路、典型现场与排查步骤串起来。文中所有英文成对双引号已改为反引号，中文与 English 混排处保留必要空格。

这条报错在说什么

在 Chrome 地址栏里输入一个域名，浏览器需要把这个人类可读的名字解析为服务器的 IP 地址，才能发起 TCP 或 QUIC 连接。ERR_NAME_NOT_RESOLVED 的字面含义就是 名字解析失败：DNS 体系没有给出能用的 IP，浏览器就无法继续。很多网站把这归纳为 浏览器找不到这个域名对应的 IP 或 DNS 无法解析该域名。这一定义与主流运维文章和厂商知识库一致。(IONOS)

从 Chromium 源码视角看，Chrome 的网络错误都有枚举值，ERR_NAME_NOT_RESOLVED 就是其中之一，表示 DNS 查询失败这一类场景。Chromium 开发者也在邮件列表中解释过，过去一些无网络连接的情况也会被粗略地映射到这条错误，为了帮助用户定位，现在会更细分，例如区分 未联网 与 解析不到主机。(Chromium Git Repositories)

和它关系密切的另一条 Chrome 常见提示是 DNS_PROBE_FINISHED_NXDOMAIN。其中 NXDOMAIN 是 DNS 术语，表示 该域名不存在。两者都在描述 DNS 解析失败，但含义的颗粒度略有差别：ERR_NAME_NOT_RESOLVED 更泛，NXDOMAIN 明确告诉你权威或递归 DNS 回答了 这个名字不存在。(Cloudflare)

背后的解析链路在做什么

把 www.example.*** 变成 IP，一般会经历这样一个路径：

1. Chrome 先问操作系统的 stub resolver，也会参考自己的 host resolver cache。某些版本与设置下，Chrome 还能启用 Secure DNS，直接用 DoH 向支持的递归解析器发起加密查询。(Chromium Blog)
2. 递归解析器如果本地无缓存，会自顶向下问 根、TLD、权威。权威服务器才真正持有目标域的记录，例如 A 或 AAAA。(Cloudflare)
3. 若权威返回 NXDOMAIN，递归解析器就把这个 不存在 的结论传回；若网络中断、路由阻断、或查询超时，也会造成无法得到 IP 的结果。(Cloudflare)

因此，只要链路上任一环出错，都可能触发 ERR_NAME_NOT_RESOLVED。这也解释了为何你会在不同环境里看到它：从本机 hosts 配置错误，到公司内网的 split DNS 规则冲突，再到域名本身记录配置有误，都在可能范围内。(SupportHost)

三类最常见根因与它们的浏览器学表现

1) 域名自身配置问题

域名刚接入或迁移时，如果 A 或 AAAA 记录缺失、***AME 指向链条断裂、或者 DNSSEC 签名校验失败，外界就会看到解析失败。站点所有者还会在不同地区观察到不一致现象，因为递归解析器缓存与全球同步存在时延。面向站点维护者的运维文档将 DNS 记录缺失或错误 视作一类主因。(IONOS)

附带一笔：DNSSEC 的工作机理是用 RRSIG 等记录对应答签名，能验证数据完整性；当链路上签名或信任链配置不当时，也会表现为无法解析。(Wikipedia)

2) 本地或网络侧解析问题

家庭路由器卡死、ISP 递归解析器异常、企业网关的 DNS 过滤策略误杀，都会让 名字解析不到。不少社区帖子都提到过 换成公共 DNS 就临时恢复 的现象，本质上是换了递归解析器。(Reddit)

3) 浏览器或系统缓存与策略导致的假阳性

陈旧条目留在浏览器 host cache 或操作系统 DNS 缓存里，会让浏览器拿到过期的 IP；某些版本中，Chrome 的预加载 preload pages、Socket 池状态、或 Secure DNS 回退逻辑也可能叠加影响。清理 host cache 与 socket pool 经常能验证是否属于这一路径。(Managed WordPress Hosting)

四个真实世界的小案例

案例 A｜拼写错误与子域名级别的 NXDOMAIN

某团队把 media.example.*** 错写成 medai.example.*** 嵌入到页面。Edge 能打开主站，因此大家以为网络没问题；Chrome 控制台却连出一串 ***::ERR_NAME_NOT_RESOLVED 的静态资源加载失败。排查后发现请求的就是一个不存在的二级域，于是权威 DNS 合理地回了 NXDOMAIN。这类问题通过 DevTools 的 ***work 面板一眼就能看出域名拼写。对于 NXDOMAIN 的释义可以参考 Cloudflare 的学习文档与运维说明。(Cloudflare)

案例 B｜企业内网 split DNS 与外网同名域冲突

公司内部把 api.***pany.test 在内网 DNS 指向 10 网段，开发者出差在酒店 Wi-Fi 下访问，解析落到公网权威，结果是 不存在。浏览器呈现 ERR_NAME_NOT_RESOLVED。一旦连上公司 VPN，递归解析器切换为内网 DNS，页面恢复。这个现象完美契合 解析器不同 → 结论不同 的机制说明。(Cisco Umbrella)

案例 C｜递归解析器异常

某日部分 ISP 的解析器抖动，用户报告访问常见网站偶发 This site can’t be reached，细节是 ERR_NAME_NOT_RESOLVED。将本机 DNS 改为公共解析器 8.8.8.8 或 1.1.1.1 后恢复，说明问题发生在递归侧。类似经历与经验在社区问答与运营商论坛中屡见不鲜。(Hosted.***)

案例 D｜浏览器缓存条目陈旧

站点迁移至新 IP，当晚仍有用户打不开。让对方在 Chrome 访问 chrome://***-internals/#dns 清理 Host cache，并在 chrome://***-internals/#sockets 刷新 Socket 池，问题即刻消失。这一做法在多篇实操文章与 Super User 的回答里都有记录。(Super User)

面向开发者与运维的系统化排查清单

面向客户端与浏览器：

• 用命令行确认 是否解析得到 IP。

  • Windows：nslookup example.*** 或 ping example.***。
  • macOS 或 Linux：dig +trace example.***。
    如果权威返回 NXDOMAIN，浏览器报 ERR_NAME_NOT_RESOLVED 是符合预期的。对 NXDOMAIN 的解释可参考 Cloudflare 与厂商知识库。(Cloudflare)

• 清理本机与浏览器缓存，排除假阳性。

  • Windows 刷新系统缓存：ipconfig /flushdns。
  • macOS 刷新缓存：sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。
  • Chrome 清缓存方式：在地址栏访问 chrome://***-internals/#dns，执行 Clear host cache，再到 chrome://***-internals/#sockets 执行 Flush socket pools。这些路径在多篇实践帖中被证实有效。(Super User)

• 观察 Secure DNS 的影响。Chrome 83 起支持基于 DoH 的 Secure DNS，默认自动模式，如果加密查询异常，会自动回落到传统明文 DNS。排查时可以暂时改用系统 DNS 或指定可信 DoH 提供者，验证是否由中间网络策略导致。(Chromium Blog)

面向网络与 DNS 侧：

• 切换递归解析器试验。换到公共解析器 8.8.8.8 或 1.1.1.1，判断是否为当前 ISP 递归侧抖动或劫持引起。社区问题与贴子常用此法隔离问题域。(Hosted.***)
• 检查域名记录。站点所有者需要核对 A 或 AAAA、***AME、以及 TTL，确认没有误删、未生效或指向死链。多家托管与运维文档都将其列为头号原因。(IONOS)
• 关注 DNSSEC 配置。若启用了 DNSSEC，确保 DS 与 DNSKEY 链条正确，避免因为签名不通过导致解析失败。(Wikipedia)
• 警惕 DNS 劫持。某些网络会把 不存在 的域名强行指向广告或告警页，既破坏协议预期，也可能造成混淆。百科与行业报道对这类行为有专门条目与案例。(Wikipedia)

和浏览器内核实现相关的几个细节

• 错误归因与可观测性：Chromium 在 ***_error_list.h 中定义了所有网络错误枚举，***_error_list.*** 会将其转成人类可读短语。浏览器在不同阶段返回更明确的错误，有助于遥测与开发者定位。(Chromium Git Repositories)
• 预解析与并行解析：Chrome 会对页面上的链接做 DNS 预解析以提升首包速度，这可能把解析请求提前发出，从而在 console 里更早看到资源级别的 ERR_NAME_NOT_RESOLVED 日志。这类 Failed to load resource: ***::ERR_NAME_NOT_RESOLVED 的报错在前端调试时很常见。(Stack Overflow)
• DoH 回退策略：出于兼容性考虑，Chrome 的 Secure DNS 在遇到不支持或拦截时，会自动回退为传统 DNS，这也是为什么同一环境下 关掉或更换 DoH 提供者 能改变现象的根源。(Google Help)

把抽象落地：两段可复现实验

下列步骤不会修改系统持久配置，适合在开发机上快速自查。

实验 1｜验证本机缓存导致的假阳性

1. 打开 example.invalid 这种保留的无效域名，在 Chrome 会立刻看到 ERR_NAME_NOT_RESOLVED。
2. 在命令行运行 ipconfig /flushdns 或者在 macOS 上运行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。
3. 访问 chrome://***-internals/#dns 点击 Clear host cache，再到 chrome://***-internals/#sockets 执行 Flush socket pools。
4. 再刷新页面，结论保持一致，说明错误来自权威 不存在 响应，而非本机缓存。上述页面与步骤出自多篇社区解答与实操文。(Super User)

实验 2｜验证递归解析器差异

1. 任选一个你能访问的域名 example.***。
2. 先用默认网络配置访问，确认一切正常。
3. 暂时把网络的 DNS 指定为 1.1.1.1，或用浏览器里的 Secure DNS 指定提供者。
4. 如果某个问题域名在一种解析器下可达、在另一种解析器下不可达，基本可以断定问题出在递归侧或其上游。关于 Secure DNS 的工作方式与自动回退策略，Chromium 官方博客与帮助中心有明确描述。(Chromium Blog)

面向不同角色的简明行动指南

• 作为普通用户：尝试切换网络、清除系统与浏览器 DNS 缓存、改用公共 DNS、暂时关闭安全软件观察。多数入门文章都给出了手把手步骤。(Kinsta®)
• 作为前端开发者：用 DevTools 定位到底是主文档、子资源，还是第三方脚本挂了；检查链接与子域名拼写；避免把私网域名硬编码到公共环境。console 中的 Failed to load resource: ***::ERR_NAME_NOT_RESOLVED 日志能直接定位到具体资源。(Stack Overflow)
• 作为站点运维：核对权威 DNS 记录、观察全网传播、检查 DNSSEC 链路、准备回滚或应急记录；结合外部监测验证是否 NXDOMAIN。Cloudflare 的学习材料对常见 DNS 故障与 NXDOMAIN 有系统梳理。(Cloudflare)

一个易被忽略的边角知识

当看到 ERR_NAME_NOT_RESOLVED，直觉会认为 域名不存在。可在现代浏览器里，它也可能是 查询超时、中间网络拦截、系统没有网络 等导致的 没有解析到 IP 的总称。Chromium 开发者提到过他们努力把这些情况区分得更清晰，因为 无网络 与 域名不存在 对诊断和统计的意义完全不同。(Google Groups)

结语

把 ERR_NAME_NOT_RESOLVED 记成一句话：浏览器这次没拿到域名的 IP。但真正的原因可能在浏览器缓存、系统网络、递归解析器、权威记录，乃至 DNSSEC 的任何一环。顺着解析链路从近到远核对，配合 Chrome 的 ***-internals 工具页和 Secure DNS 设置，你就能把抽象的报错翻译成具体的根因，并用最小代价快速恢复访问。(Managed WordPress Hosting)

延伸阅读

• 如何清理 Chrome DNS 缓存 与 刷新 Socket 池 的操作页与实践帖。(Super User)
• Chrome Secure DNS 的推出背景与机制。(Chromium Blog)
• NXDOMAIN 背景与常见 DNS 故障。(Cloudflare)