外观
网页提示「找不到服务器」「DNS_PROBE_FINISHED_NXDOMAIN」，或者订阅、节点域名解析失败，都属于 DNS 解析问题。DNS（域名系统）负责把 example.com 这样的域名翻译成 IP 地址；开着代理时，这一步可能由系统、浏览器和代理客户端三方分别处理，排查起来容易混乱。本页先用「两步速查」表按症状定位问题类型，简要讲清解析链路后，按第一步到第十一步的顺序排查：先确认是不是 DNS 问题，再分清系统、浏览器、客户端三层设置，分系统检查、对照报错、刷新缓存、判断解析结果、检查客户端 DNS、换网络对照、用命令诊断，最后说明修改配置后如何验证、恢复和预防复发。
两步速查：先定位问题类型
第一步对照下表找到最接近的症状，判断问题在系统、浏览器、客户端还是当前网络；第二步点「先看哪一节」直接跳到对应步骤，比从头逐项排查快得多。表中「优先检查」一列是按出现概率排序的第一个动作。
| 症状 | 可能原因 | 优先检查 | 先看哪一节 |
|---|---|---|---|
| 所有网站都提示找不到服务器，关代理也一样 | 系统 DNS 不可用或被改成失效地址、网络未连接 | 系统 DNS 设置、ping 223.5.5.5 | 第二步：全部域名或部分域名无法解析 |
| 开代理正常，退出代理后全部打不开 | 客户端改过系统 DNS 或系统代理没有恢复 | 系统 DNS 是否为 127.0.0.1 之类的本地地址 | 第十一步：配置变更后的验证与恢复 |
| 只有国外网站解析失败 | 流量没走代理，或客户端 DNS 配置异常 | 客户端运行模式与 DNS 设置 | 第八步：检查代理客户端 DNS 配置 |
| 只有某一个网站解析失败 | 域名本身失效、拼写错误、被拦截或解析污染 | 用不同 DNS 服务器查询对比 | 第十步：进阶诊断命令 |
| 订阅更新或节点连接提示 no such host | 服务商域名变更，或本地 DNS 无法解析该域名 | 换网络、换 DNS 查询订阅域名 | 订阅更新失败 |
| 能查到 IP，网页仍打不开 | 问题不在解析，在连接、节点或分流 | 解析结果是否合理 | 第七步：域名可以解析但目标无法连接 |
查到的是 198.18.x.x | fake-ip 模式的虚拟地址，属正常现象 | 关闭客户端后再查一次 | DNS 解析原理简述 |
查到 127.0.0.1 或 0.0.0.0 | hosts 文件或拦截规则屏蔽了该域名 | hosts 文件、广告拦截设置 | 第七步：判断解析结果 |
| 浏览器打不开，命令行能解析 | 浏览器安全 DNS 或浏览器缓存 | 关闭浏览器安全 DNS、清浏览器缓存 | 第三步：三层 DNS 的关系 |
| 首次访问很慢，第二次正常 | 上游 DNS 响应慢，或先尝试 IPv6 失败 | dig 查询耗时、IPv6 解析 | 第十步：进阶诊断命令 |
| 只在某个 Wi-Fi 下失败 | 该网络的路由器或 DNS 服务器有问题 | 换手机热点对照 | 第九步：换网络环境做对照 |
名词速查
- 解析器（resolver）：替你完成域名查询的 DNS 服务器，通常由路由器或运营商分配，也可以是公共 DNS。
- DoH / DoT：DNS over HTTPS / DNS over TLS，把 DNS 查询放进加密连接里传输，浏览器的「安全 DNS」和 Android 的「私人 DNS」分别基于这两种技术。
- fake-ip：代理客户端先返回一个虚拟地址给应用，等应用真正发起连接时再按域名决定走向的一种 DNS 处理模式。
核心结论
核心结论
- 先确认是不是 DNS：报错里出现「NAME_NOT_RESOLVED」「NXDOMAIN」「no such host」「Could not resolve host」才是解析问题，超时和拒绝连接不是。
- 搞清楚谁在解析：系统 DNS、浏览器安全 DNS、客户端 DNS 可能同时存在，结果不一致时先关掉多余的一层。
- fake-ip 不是错误：开着客户端时查到 198.18 开头的地址，通常是 fake-ip 模式的正常表现。
- 改完要刷新缓存：系统、浏览器和客户端都有缓存，修改设置后不刷新，看到的还是旧结果。
- 用对照法缩小范围：关代理对比、换网络对比、换 DNS 服务器对比，三次对照基本能定位问题所在层级。
- 改之前先记录：手动修改 DNS 前记下原设置，排查完恢复成「自动获取」，避免退出代理后上不了网。
DNS 解析原理简述
一次正常的解析，是应用把域名交给某个解析器、解析器返回 IP、应用再连接这个 IP；代理客户端介入后，「谁来解析」和「在哪里解析」都可能改变。理解这条链路，是判断问题出在哪一层的前提。
不开代理时的解析路径
- 应用（浏览器、命令行工具等）向操作系统请求解析域名；
- 系统先查 hosts 文件和本地缓存，命中就直接返回；
- 没命中则发给系统配置的 DNS 服务器（通常是路由器，再由路由器转发给运营商 DNS）；
- DNS 服务器返回 A 记录（IPv4 地址）或 AAAA 记录（IPv6 地址），系统缓存一段时间（由记录的 TTL 决定）；
- 应用拿到 IP 后发起连接。
这条路径上任何一环出错——hosts 被改、缓存了错误结果、路由器 DNS 卡死、运营商 DNS 返回异常——都会表现为解析失败或解析到错误地址。
开代理后的三种情况
| 代理方式 | 解析发生在哪里 | 特点 |
|---|---|---|
| 系统代理（HTTP / SOCKS） | 浏览器通常把域名直接交给代理，由客户端或远端节点解析 | 不读系统代理的应用仍走系统 DNS |
| TUN 模式 + fake-ip | 客户端拦截系统 DNS 查询，先返回虚拟地址，连接时按域名分流 | 本机查到 198.18.x.x 属正常；需走代理的域名由代理侧解析 |
| TUN 模式 + 真实 IP 模式（redir-host 等） | 客户端用自己配置的 DNS 服务器查到真实 IP 再返回 | 结果受客户端 DNS 配置直接影响，配置错误会导致解析失败 |
fake-ip 模式的好处是应用不用等真实解析完成就能发起连接，且需要走代理的域名不会在本地被解析；代价是本机看到的地址都是虚拟的，用 nslookup 排查时容易误判。以 mihomo 内核为例，官方文档给出的默认 fake-ip 地址段是 198.18.0.1/16，具体以你所用客户端和配置为准。
为什么同一个域名会查到不同结果
- 按地区返回：很多大型网站会根据查询来源返回就近的服务器，不同 DNS 服务器查到的 IP 不同是正常的。
- 缓存未过期：域名换了 IP，但某一层缓存还没到期，仍返回旧地址。
- 解析被干扰：部分网络环境中，某些域名的查询结果可能被篡改，返回无法连接的地址，这就是常说的「DNS 污染」。客户端让这类域名在代理侧解析，就能避开本地干扰。
- fake-ip 映射：开着 fake-ip 时，本机看到的永远是虚拟地址。
第一步：确认是不是 DNS 问题
很多「上不了网」并不是 DNS 问题，先用报错文本和两条命令把 DNS 与连接问题分开，能省掉大半无效操作。判断标准是：域名能否被解析成 IP，与这个 IP 能否连通，是两个独立的问题。
三步判断
- 看报错文本：出现
ERR_NAME_NOT_RESOLVED、DNS_PROBE_FINISHED_*、no such host、Could not resolve host、Non-existent domain等，属于解析问题；出现ERR_CONNECTION_TIMED_OUT、ERR_CONNECTION_REFUSED、ERR_CONNECTION_RESET、i/o timeout，属于连接问题。 - 用 IP 测网络：运行
ping 223.5.5.5（或任意一个你确定可达的公共 DNS IP）。能通说明网络本身连通。部分网络会屏蔽 ping，不通时再访问一个国内网站对比。 - 用域名测解析：运行
nslookup www.baidu.com。能返回 IP 说明系统 DNS 基本正常；报超时或Non-existent domain，问题集中在 DNS。
| ping IP | nslookup 域名 | 结论 |
|---|---|---|
| 通 | 成功 | 系统 DNS 正常，问题在特定域名、浏览器或代理链路 |
| 通 | 失败 | 网络正常、DNS 有问题，重点查 DNS 设置 |
| 不通 | 失败 | 网络本身没连上，先排查 Wi-Fi、网线、路由器 |
| 不通 | 成功 | 可能该网络屏蔽 ping，或解析结果来自缓存，用浏览器实测 |
开着客户端时先关掉再测
如果客户端处于 TUN 模式，上面的 nslookup 实际是被客户端接管的，结果反映的是客户端的 DNS 配置。想测系统本身的 DNS，先完全退出客户端；想测客户端的 DNS，再打开客户端测一次，两次结果对照着看。
第二步：全部域名或部分域名无法解析，按范围排查
先区分范围：是所有域名都解析失败，还是只有个别域名有问题。范围不同，原因和处理方向完全不同。
判断方法
| 现象 | 可能原因 | 优先检查 |
|---|---|---|
| 所有网站都提示找不到服务器 | 系统 DNS 不可用、DNS 被改成了失效地址、网络未连接 | 系统 DNS 设置，关闭代理对比 |
| 只有国外网站解析失败 | 客户端 DNS 配置异常，或流量没有走代理 | 客户端 DNS 设置与运行模式 |
| 只有某一个网站解析失败 | 该域名本身失效，或被本地 DNS 污染 | 用不同 DNS 服务器查询对比 |
| 订阅或节点域名解析失败 | 服务商域名变更，或本地 DNS 无法解析该域名 | 更新订阅，查看服务商公告 |
| 国内网站解析失败、国外正常 | 客户端把国内域名也交给了远端 DNS，或直连 DNS 配置错误 | 客户端的直连 DNS 与分流规则 |
排查顺序
- 关闭代理，访问几个常用国内网站。仍然打不开，问题在系统 DNS 或本地网络。
- 用 IP 直接测试网络：例如
ping 223.5.5.5。能通说明网络连通，问题集中在 DNS。 - 查看系统 DNS 设置，确认没有被改成失效的地址。
- 用 nslookup 指定不同 DNS 服务器查询，对比结果（见「第十步：进阶诊断命令」）。
- 打开代理后再测，看问题是否只在代理开启时出现。
- 只在代理开启时失败：先切换到客户端的默认配置或重新导入订阅，排除自定义 DNS 配置的影响。
示例场景：退出客户端后只有部分网站打不开
某用户退出客户端后，常用网站能打开，新打开的网站却提示找不到服务器。检查发现系统 DNS 仍是客户端写入的本地地址，而常用网站之所以能打开，是因为浏览器和系统缓存里还留着之前的解析结果。缓存过期后，这些网站也会陆续打不开。处理方法是把系统 DNS 改回自动获取，再刷新缓存。
第三步：分清系统、浏览器和客户端三层 DNS 设置
开着代理客户端时，一个域名可能经过三层不同的 DNS 处理。很多「明明设置了却不生效」的问题，都是因为不清楚当前到底是哪一层在解析。
三层 DNS 的关系
| 层级 | 作用范围 | 说明 |
|---|---|---|
| 系统 DNS | 所有未单独设置的应用 | 在系统网络设置中配置，默认由路由器或运营商分配 |
| 浏览器安全 DNS | 仅该浏览器 | Chrome、Edge、Firefox 等支持 DNS over HTTPS，开启后绕过系统 DNS |
| 客户端 DNS | 经过客户端的流量 | 客户端可接管 DNS，并按分流规则决定用哪个 DNS 服务器 |
优先级的一般规律是：浏览器开启安全 DNS 时，浏览器自己解析，不经过系统；客户端开启 TUN 并接管 DNS 时，系统发出的查询会被客户端截获；只开系统代理时，浏览器通常把域名原样交给代理，本地并不解析。
安全 DNS 可能干扰分流
浏览器开启安全 DNS 后，浏览器自己完成解析再把 IP 交给代理，客户端可能无法按域名规则正确分流。排查分流问题时，可以先关闭浏览器的安全 DNS 对比。
浏览器安全 DNS 的位置
| 浏览器 | 设置位置 | 说明 |
|---|---|---|
| Chrome | 设置 → 隐私和安全 → 安全 → 高级 → 使用安全 DNS | 默认可能处于自动模式，系统 DNS 支持时才启用 |
| Edge | 设置 → 隐私、搜索和服务 → 安全性 → 使用安全的 DNS（菜单名称以浏览器为准） | 与 Chrome 逻辑类似 |
| Firefox | 设置 → 隐私与安全 → 基于 HTTPS 的 DNS | 提供默认保护、增强保护、最大保护和关闭等选项 |
| Safari | 无单独设置 | 跟随系统 DNS 与系统级加密 DNS 配置 |
Firefox 官方文档说明，「默认保护」级别在检测到 VPN、家长控制、企业策略，或网络声明不使用安全 DNS 时会自动停用 DoH；「最大保护」级别则始终使用安全 DNS，连不上时会显示警告页。这意味着同一台电脑上，Firefox 的解析行为可能与 Chrome 不同。
各系统查看和修改 DNS 的位置
| 系统 | 设置路径 |
|---|---|
| Windows 11 | 设置 → 网络和 Internet → 选择当前网络（WLAN 或以太网）→ 硬件属性或属性 → DNS 服务器分配 → 编辑 |
| Windows 10 | 控制面板 → 网络和共享中心 → 更改适配器设置 → 右键当前网络 → 属性 → Internet 协议版本 4 → 属性 |
| macOS | 系统设置 → 网络 → 选择当前网络 → 详细信息 → DNS |
| Android 9 及以上 | 设置 → 网络和互联网 → 私人 DNS（不同品牌菜单名称和位置略有差异） |
| iOS / iPadOS | 设置 → 无线局域网 → 点当前网络右侧的 ⓘ → 配置 DNS |
Windows 11 在「DNS 服务器分配」的手动模式里，每个 DNS 地址下方还有一个「DNS over HTTPS」选项。如果你曾开启它，系统 DNS 也会走加密通道，排查时要把它记录在案。
命令行查看当前 DNS 服务器
bash
# Windows：查看每块网卡的 DNS 服务器
ipconfig /all
# Windows PowerShell：只列出各网卡的 DNS 服务器地址
Get-DnsClientServerAddress
# macOS：查看系统当前使用的 DNS 配置
scutil --dns
# macOS：查看某个网络服务手动设置的 DNS（Wi-Fi 换成你的服务名）
networksetup -getdnsservers "Wi-Fi"
# Linux（systemd-resolved）：查看每块网卡的 DNS
resolvectl statusipconfig /all 输出里如果出现名称类似客户端的虚拟网卡（TUN 模式创建），它的 DNS 服务器往往是客户端的内部地址，这是正常的；需要关注的是物理网卡（WLAN、以太网）上的 DNS 是否被改成了失效地址。
第四步：分系统排查步骤
不同系统的 DNS 机制差异较大，下面按系统列出完整的排查顺序，每一步都给出「正常应该看到什么」，按顺序执行到某一步出现异常，就停下来处理这一步。
Windows 10 / 11
- 完全退出代理客户端（在系统托盘右键退出，而不是只关窗口）；
- 打开 设置 → 网络和 Internet → 代理，确认「使用代理服务器」处于关闭状态；
- 以管理员身份打开命令提示符，运行
ipconfig /all，查看物理网卡的「DNS 服务器」一行，正常应是路由器地址（如192.168.x.1）或运营商分配的地址； - 如果显示
127.0.0.1、198.18.0.2之类你没有主动设置的地址，按上表路径把 DNS 改回自动； - 运行
ipconfig /flushdns刷新缓存； - 运行
nslookup www.baidu.com，确认能返回地址； - 打开浏览器访问国内网站，确认正常后再启动客户端测试。
如果第 6 步仍然失败，可以在管理员 PowerShell 中运行 Clear-DnsClientCache 后再试，或用 Resolve-DnsName www.baidu.com -Server 223.5.5.5 绕过系统 DNS 指定服务器查询，判断是本机配置问题还是上游 DNS 问题。
macOS
- 完全退出代理客户端（菜单栏图标 → 退出）；
- 打开 系统设置 → 网络 → 当前网络 → 详细信息 → 代理，确认没有残留代理；
- 在同一窗口的 DNS 页，确认没有不认识的手动 DNS 服务器（灰色文字的地址是自动获取的，可以保留）；
- 终端运行
scutil --dns，查看resolver #1下的nameserver是否合理； - 运行
sudo dscacheutil -flushcache和sudo killall -HUP mDNSResponder刷新缓存； - 运行
dscacheutil -q host -a name www.baidu.com，按系统实际方式解析一次； - 浏览器实测。
macOS 上要额外留意「iCloud 专用代理」（iCloud Private Relay）和系统中安装的描述文件：两者都可能改变 Safari 或整个系统的 DNS 行为。排查时可以暂时在当前网络的设置中关闭专用代理，或在 设置 → 通用 → VPN 与设备管理（不同版本位置可能不同）中检查是否有不认识的 DNS 描述文件。
Linux
- 运行
resolvectl status（使用 systemd-resolved 的发行版）或cat /etc/resolv.conf查看 DNS 配置； - 注意
/etc/resolv.conf中常见的127.0.0.53是 systemd-resolved 的本地监听地址，属于正常现象； - 用
dig @223.5.5.5 www.baidu.com +short绕开本机解析器直接查询； - 直接查询成功、系统查询失败，问题在本机解析器配置，运行
resolvectl flush-caches后重试； - 如果
/etc/resolv.conf被代理工具改写过，恢复为发行版默认（通常由网络管理器自动生成）。
Android
- 关闭代理应用，并在 设置 → 网络和互联网 → VPN 中确认没有处于连接状态的 VPN；
- 在「私人 DNS」中暂时选择「关闭」，排除加密 DNS 的影响；
- 关闭再打开一次飞行模式，刷新网络配置；
- 用浏览器访问国内网站，正常后再开启代理；
- 开启代理后仍有问题，检查客户端内的 DNS 设置，或换回默认配置。
Android 的私人 DNS 有三个选项：关闭、自动、指定主机名。选择「指定主机名」且该主机无法连接时，可能出现所有网站都打不开的情况。
iOS / iPadOS
- 关闭代理应用，在 设置 → 通用 → VPN 与设备管理 中确认没有连接中的 VPN 配置；
- 在 设置 → 无线局域网 → ⓘ → 配置 DNS 中确认为「自动」；
- 检查是否安装过 DNS 相关的描述文件，不认识的建议移除；
- 开关一次飞行模式，或忘记该 Wi-Fi 后重新连接；
- 浏览器实测，正常后再开启代理。
第五步：对照报错信息
浏览器和客户端给出的报错文本是最直接的线索，下表列出与 DNS 相关的常见报错及其含义。Chrome 的错误代码取自 Chromium 源码中的错误列表，客户端报错以 Go 语言网络库为基础的内核为例，实际文字可能因版本和语言设置略有差异。
浏览器
| 浏览器 | 报错代码或提示 | 含义 | 处理方向 |
|---|---|---|---|
| Chrome / Edge | ERR_NAME_NOT_RESOLVED | 主机名无法解析 | 按本页排查顺序检查 DNS |
| Chrome / Edge | ERR_NAME_RESOLUTION_FAILED | 尝试解析时发生错误 | 检查 DNS 服务器是否可用 |
| Chrome / Edge | DNS_PROBE_FINISHED_NXDOMAIN | DNS 服务器正常，但该域名不存在 | 检查拼写、hosts，换 DNS 对比 |
| Chrome / Edge | DNS_PROBE_FINISHED_BAD_CONFIG | DNS 配置有误，或 DNS 服务器不可用 | 检查系统 DNS 是否被改成失效地址 |
| Chrome / Edge | DNS_PROBE_FINISHED_NO_INTERNET | 没有网络连接 | 先排查网络本身 |
| Chrome / Edge | DNS_PROBE_FINISHED_BAD_SECURE_CONFIG | 安全 DNS 配置有误或其服务器不可用 | 关闭浏览器安全 DNS 或更换提供商 |
| Chrome / Edge | ERR_INTERNET_DISCONNECTED | 系统认为没有联网 | 检查网卡和 Wi-Fi |
| Firefox | 「找不到该网站」类提示页 | 无法解析域名 | 同上；注意 Firefox 可能开着自己的 DoH |
| Safari | 「找不到服务器」类提示 | 无法解析域名 | 检查系统 DNS 和 iCloud 专用代理 |
命令行与客户端
| 来源 | 报错文本 | 含义 |
|---|---|---|
| Windows nslookup | Non-existent domain | 等同 NXDOMAIN，域名不存在 |
| Windows nslookup | DNS request timed out | DNS 服务器没有响应 |
| dig | status: NXDOMAIN / SERVFAIL / REFUSED | 见下文状态码表 |
| dig | connection timed out; no servers could be reached | 无法连接到指定的 DNS 服务器 |
| curl | curl: (6) Could not resolve host | 无法解析目标主机 |
| curl | curl: (5) Could not resolve proxy | 无法解析代理服务器的地址 |
| 客户端日志（Go 内核） | lookup xxx: no such host | 解析结果为不存在 |
| 客户端日志（Go 内核） | lookup xxx: i/o timeout | 向 DNS 服务器查询超时 |
| 客户端日志 | 订阅更新失败并提示解析错误 | 订阅域名无法解析，见 订阅更新失败 |
浏览器中文提示与代码的对应
中文界面的 Chrome 通常在错误页显示「无法访问此网站」和一句说明，具体错误代码在页面下方以灰色小字显示。排查和反馈时以错误代码为准，比描述文字更精确。
第六步：刷新 DNS 缓存，排除旧解析结果
系统和浏览器都会缓存解析结果。修改 DNS 设置、切换代理模式或服务商更换域名后，如果不清理缓存，你看到的可能仍是旧结果。
刷新系统 DNS 缓存
bash
# Windows（在命令提示符或 PowerShell 中运行）
ipconfig /flushdns
# macOS（在终端中运行，需要输入开机密码）
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Linux（使用 systemd-resolved 的发行版）
resolvectl flush-cachesWindows 还可以用 ipconfig /displaydns 查看当前缓存了哪些记录。
清除浏览器 DNS 缓存
| 浏览器 | 方法 |
|---|---|
| Chrome | 地址栏打开 chrome://net-internals/#dns，点击清除主机缓存 |
| Edge | 地址栏打开 edge://net-internals/#dns，点击清除主机缓存 |
| Firefox | 地址栏打开 about:networking#dns，点击清除 DNS 缓存 |
| Safari | 跟随系统缓存，刷新系统缓存后重启 Safari |
Chrome 清除主机缓存后，已经建立的连接可能仍在复用。如果刷新后现象不变，可以在 chrome://net-internals/#sockets 页面清空连接池，或直接完全退出浏览器再打开。
移动设备
Android 和 iOS 没有面向普通用户的刷新命令。最简单的方法是开关一次飞行模式，或者断开再重新连接 Wi-Fi，系统会重新获取网络配置。
客户端也有缓存
代理客户端通常有自己的 DNS 缓存，fake-ip 模式下还会保存域名与虚拟地址的映射。修改客户端 DNS 设置后，重启客户端或重新开关代理，确保新配置生效；部分客户端提供清除 fake-ip 映射的选项，具体以客户端文档为准。
缓存导致的典型现象
| 现象 | 原因 | 处理 |
|---|---|---|
| 改了 DNS 设置，结果不变 | 系统或浏览器缓存未过期 | 刷新系统和浏览器缓存 |
| 服务商换了域名，旧地址仍被使用 | 客户端缓存或订阅未更新 | 更新订阅后重启客户端 |
关了客户端，某些应用仍连 198.18.x.x | 应用内部缓存了 fake-ip 地址 | 重启该应用 |
| 同一域名时好时坏 | 多个 DNS 服务器返回不同结果，缓存交替生效 | 固定使用一套 DNS 后再测 |
第七步：域名可以解析但目标无法连接，判断解析结果
nslookup 能查到 IP，但网页仍然打不开，说明问题不在解析这一步，而在之后的连接。这时要先看解析结果是否合理，再看连接本身。
用 nslookup 和 dig 查询
bash
# 使用系统默认 DNS 查询
nslookup example.com
# 指定 DNS 服务器查询，对比结果
nslookup example.com 223.5.5.5
# macOS / Linux 可用 dig，+short 只输出 IP
dig example.com +short
dig @223.5.5.5 example.com +shortdig 输出中的 status 字段可以直接说明结果：
| status | 含义 |
|---|---|
NOERROR | 查询成功（若没有返回地址，说明该域名没有对应类型的记录） |
NXDOMAIN | 域名不存在 |
SERVFAIL | DNS 服务器处理失败，常见于上游故障或校验失败 |
REFUSED | DNS 服务器拒绝了这次查询 |
Windows 的 nslookup 中出现「Non-existent domain」，含义与 NXDOMAIN 相同。
macOS 上的查询差异
macOS 的 nslookup 和 dig 直接向 DNS 服务器发起查询，不经过系统解析器，结果可能与浏览器等应用看到的不一致。想按系统实际方式查询，可用 dscacheutil -q host -a name example.com。
判断解析结果
| 查到的地址 | 说明 | 下一步 |
|---|---|---|
198.18.x.x | 客户端 fake-ip 模式返回的虚拟地址，属正常现象 | 问题在代理链路，见 节点连接失败 |
127.0.0.1 或 0.0.0.0 | 被 hosts 文件或拦截规则屏蔽 | 检查 hosts 文件和广告拦截设置 |
| 不同 DNS 服务器结果差异很大 | 可能存在解析污染，或该网站按地区返回不同地址 | 让该域名走代理侧解析 |
| 地址正常但连接超时 | 解析无误，问题在连接 | 检查分流规则与节点状态 |
| 浏览器提示证书错误 | 可能解析到了错误的服务器 | 见 TLS 与证书错误 |
| 只返回 IPv6 地址或优先返回 IPv6 | 当前网络或节点不支持 IPv6 时会连不上 | 关闭客户端 IPv6 解析后对比 |
内网地址（如 10.x、192.168.x） | 被路由器或公共 Wi-Fi 劫持到认证页 | 先完成网络认证，再开代理 |
hosts 文件位置：Windows 为 C:\Windows\System32\drivers\etc\hosts，macOS 和 Linux 为 /etc/hosts。修改 hosts 需要管理员权限，正常情况下只有 localhost 相关的几行；出现你不认识的域名映射，先备份再删除。
IPv6 带来的「能解析但打不开」
当域名同时有 A 和 AAAA 记录时，系统可能优先尝试 IPv6。若本地网络分配了 IPv6 地址但实际不通，或者节点不支持 IPv6 出站，就会出现首次访问很慢、甚至失败的现象。分别用 dig example.com A +short 和 dig example.com AAAA +short 查询，再结合客户端的 IPv6 开关对比，即可确认。
第八步：检查代理客户端 DNS 配置
客户端 DNS 配置写错，是「只有开代理时解析失败」的主要原因；大多数用户使用订阅自带的默认配置即可，只有确实需要时才手动修改。下面以 mihomo（Clash Meta）内核的 DNS 字段为例说明各项作用，其他内核的名称不同但思路相通，字段细节以官方文档为准。
常见字段的作用
| 字段 | 作用 | 常见错误 |
|---|---|---|
enhanced-mode | 选择 fake-ip 或 redir-host 处理方式 | 切换模式后没重启客户端，旧映射仍在 |
default-nameserver | 解析其他 DNS 服务器自身的域名，必须填 IP | 填了域名，或填的 IP 不可达，导致加密 DNS 全部失效 |
nameserver | 日常解析域名使用的服务器 | 只填了当前网络无法访问的服务器 |
proxy-server-nameserver | 专门解析节点域名 | 无法解析节点域名，表现为所有节点都连不上 |
nameserver-policy | 为特定域名指定解析服务器，优先级高于 nameserver | 规则写反，国内域名被送去远端解析 |
fake-ip-filter | 不返回虚拟地址的域名列表 | 局域网设备、游戏、时间同步等域名未加入，出现异常 |
ipv6 | 是否解析 IPv6，关闭时 AAAA 查询返回空 | 网络不支持 IPv6 却开着 |
use-hosts / use-system-hosts | 是否使用配置内 hosts 和系统 hosts | 系统 hosts 中的旧映射影响结果 |
示例：一个仅作说明用途的 DNS 片段
下面是示例，用于理解字段关系，不建议照抄；地址请使用你信任且当前网络可达的服务器，或直接使用订阅提供的配置。
yaml
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
ipv6: false
default-nameserver:
- 223.5.5.5
nameserver:
- https://dns.alidns.com/dns-query
fake-ip-filter:
- "*.lan"
- "+.local"修改客户端 DNS 的原则
- 先用默认配置确认问题存在：默认配置也失败，问题多半不在 DNS 配置；
- 一次只改一个字段，改完重启客户端并刷新系统缓存；
- 加密 DNS 依赖 default-nameserver：DoH 地址本身是域名，需要先被解析；
- 节点域名单独考虑：节点域名解析失败会让所有节点超时，此时检查
proxy-server-nameserver或对应字段； - 订阅更新可能覆盖本地修改：长期修改应使用客户端提供的覆写或合并功能，具体以客户端文档为准。
第九步：换网络环境做对照
DNS 服务器通常由当前网络自动分配，换一个网络就换了一套 DNS。通过对照可以快速判断问题是否与当前网络有关。
对照方法
- 手机关闭 Wi-Fi，改用移动数据访问同一个网站；
- 电脑连接手机热点，再查询同一个域名；
- 在同一网络下，把系统 DNS 临时改为另一个公共 DNS 再测。
| 对照结果 | 判断 |
|---|---|
| 换网络后恢复 | 原网络的 DNS 服务器有问题，或路由器 DNS 设置异常 |
| 换 DNS 服务器后恢复 | 原 DNS 服务器对该域名解析异常 |
| 所有网络都失败 | 域名本身问题，或设备、客户端设置问题 |
| 只有代理开启时失败 | 客户端 DNS 配置问题，检查客户端 DNS 设置或换回默认配置 |
路由器层面的 DNS
很多家庭路由器会把自己设为 DNS 服务器，再转发给运营商。路由器长时间运行后可能出现解析缓慢，重启路由器是简单有效的尝试。在路由器上运行代理的情况，见 路由器与软路由。
特殊网络环境
| 网络环境 | 常见 DNS 现象 | 建议 |
|---|---|---|
| 公司或学校网络 | 只能使用内部 DNS，外部 DNS 被禁止 | 遵守所在单位网络管理规定，不擅自修改 |
| 酒店、机场等公共 Wi-Fi | 认证前所有域名被解析到认证页 | 先关代理完成网页认证 |
| 手机热点 | 由运营商移动网络 DNS 解析 | 适合作为对照组 |
| 软路由 / 旁路由 | DNS 由路由器上的代理程序接管 | 检查路由器端 DNS，而不只是本机 |
第十步：进阶诊断命令
普通排查用 nslookup 已足够，下面这些命令用于更精确地判断「哪一层在出错」，适合需要提交工单或自己深入分析的场景。所有命令都只读查询，不会修改系统设置。
dig（macOS / Linux，Windows 需另行安装）
bash
# 查看完整应答，关注 status、ANSWER SECTION 和 Query time
dig example.com
# 分别查询 IPv4 与 IPv6 记录
dig example.com A +short
dig example.com AAAA +short
# 指定 DNS 服务器，对比不同服务器的结果
dig @223.5.5.5 example.com +short
dig @119.29.29.29 example.com +short
# 从根服务器开始逐级查询，查看委派链路
dig example.com +trace
# 查询 CNAME 记录，确认域名是否指向其他域名
dig example.com CNAME +shortQuery time 可以反映 DNS 服务器的响应速度：同一服务器多次查询差异很大，或长期明显偏高，说明上游不稳定。+trace 会绕开你配置的解析器直接向根服务器查询，在部分网络环境下可能无法完成，失败本身不一定说明问题。
Windows PowerShell
powershell
# 用系统解析器查询
Resolve-DnsName example.com
# 指定 DNS 服务器查询，并只查 A 记录
Resolve-DnsName example.com -Server 223.5.5.5 -Type A
# 查询 IPv6 记录
Resolve-DnsName example.com -Type AAAA
# 清空 DNS 客户端缓存（需管理员权限）
Clear-DnsClientCachenslookup 的进阶用法
bash
# 查询指定类型的记录
nslookup -type=AAAA example.com
nslookup -type=CNAME example.com
# 显示调试信息，可看到完整的请求与应答
nslookup -debug example.com用 curl 区分「解析」和「连接」
bash
# 跳过 DNS，强制把域名指向某个 IP 发起请求（IP 为示例占位）
curl -v --resolve example.com:443:203.0.113.10 https://example.com -o /dev/null
# 输出解析耗时与连接耗时，判断慢在哪一步
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} total:%{time_total}\n" https://example.com--resolve 让 curl 不经过 DNS，直接使用你指定的 IP：用它测试「换一个 IP 是否就能连上」，可以判断问题是否真的出在解析结果上。time_namelookup 明显偏大，说明慢在解析；解析很快但 time_connect 很大，问题在连接。Windows 下把 -o /dev/null 换成 -o NUL，并使用 curl.exe。
进阶判断表
| 观察结果 | 结论 |
|---|---|
| 指定公共 DNS 成功，系统默认 DNS 失败 | 本机或路由器 DNS 有问题 |
| 所有公共 DNS 都返回 NXDOMAIN | 域名确实不存在或已过期 |
| 某 DNS 返回 SERVFAIL，其他正常 | 该 DNS 服务器上游异常或校验失败 |
--resolve 指定正确 IP 后可访问 | 本地解析结果有误 |
--resolve 后仍失败 | 问题在连接、证书或节点，不在 DNS |
第十一步：配置变更后的验证与恢复
排查 DNS 时经常需要临时修改设置。修改不当可能导致退出代理后反而上不了网，所以每一步都应该可验证、可恢复。
修改前
- 截图或记录当前的系统 DNS 设置；
- 记录客户端当前的 DNS 配置和运行模式；
- 备份 hosts 文件；
- 一次只改一个地方。
修改后的验证步骤
- 刷新系统和浏览器的 DNS 缓存；
- 用 nslookup 或 dig 查询目标域名，确认返回结果符合预期；
- 用浏览器实际访问，确认能打开；
- 关闭代理，确认国内网站仍能正常解析和访问；
- 重启一次设备，确认设置在重启后依然符合预期。
恢复默认设置
| 系统 | 恢复方法 |
|---|---|
| Windows | 在 DNS 服务器分配中改回「自动（DHCP）」，或在 IPv4 属性中选「自动获得 DNS 服务器地址」 |
| macOS | 在网络详细信息的 DNS 页面删除手动添加的服务器，或运行 networksetup -setdnsservers "Wi-Fi" empty |
| Linux | 恢复网络管理器的自动 DNS 设置，确认 /etc/resolv.conf 由系统管理 |
| Android | 私人 DNS 选择「关闭」或「自动」 |
| iOS / iPadOS | 配置 DNS 改回「自动」 |
| 客户端 | 恢复默认配置，或重新导入订阅 |
退出客户端后上不了网
如果退出代理客户端后所有网站都打不开，先检查系统 DNS 是否被改成了 127.0.0.1 之类的本地地址，以及系统代理是否残留。后者见 代理与系统冲突。
预防复发的习惯
- 正常退出客户端：用菜单里的「退出」而不是强制结束进程，让客户端有机会恢复系统设置；
- 不在系统层面手动写死 DNS：需要特殊 DNS 时，优先在客户端里配置，影响范围更可控；
- 只保留一种加密 DNS：浏览器安全 DNS、系统 DoH、私人 DNS、客户端 DNS 同时开启时，结果难以预测；
- 保存订阅的备用域名：服务商通常会公布备用访问方式，域名失效时能第一时间切换；
- 定期更新客户端和订阅：DNS 相关默认配置会随客户端更新而调整。
一页排查清单
遇到问题时按下面的清单逐项核对，基本能覆盖本页所有常见原因，也方便在提交工单时说明已经做过哪些尝试：
- 报错文本属于解析错误，而不是超时或拒绝连接；
- 退出客户端后，系统代理已关闭，物理网卡的 DNS 为自动获取；
- hosts 文件中没有不认识的域名映射；
- 系统、浏览器、客户端缓存都已刷新，浏览器已完全重启；
- 浏览器安全 DNS、系统 DoH、Android 私人 DNS 已暂时关闭做过对比；
- 换过一个网络（如手机热点）和一个公共 DNS 做过对比；
- 客户端已切回默认配置或重新导入订阅，并重启过客户端；
- 分别查询过 A 与 AAAA 记录，排除了 IPv6 的影响。
清单全部完成仍然失败，说明问题大概率不在本机，而在服务商域名、上游 DNS 或网络环境本身。
何时联系服务商
- 订阅域名或节点域名在多个网络、多个公共 DNS 下都解析失败；
- 服务商要求使用的特定 DNS 配置无法生效；
- 按服务商提供的默认配置导入后仍有解析问题。
提交工单时附上这些信息
完整的报错文本、nslookup 或 dig 的输出、使用的网络类型（宽带、移动数据）、客户端名称与运行模式、发生时间。发送前遮挡订阅链接、账号和 IP 等隐私信息。
常见问题
开着代理时用 nslookup 查到 198.18 开头的地址，是不是解析错了？
不一定。部分客户端的 fake-ip 模式会返回 198.18.0.0/16 网段的虚拟地址，真实解析由客户端在代理侧完成，这是正常现象。关闭客户端后再查，应能看到真实地址。
怎么刷新电脑的 DNS 缓存？
Windows 在命令提示符中运行 ipconfig /flushdns；macOS 在终端运行 sudo dscacheutil -flushcache 和 sudo killall -HUP mDNSResponder。浏览器有自己的缓存，必要时一并清除或重启浏览器。
为什么关闭代理后有些网站反而打不开了？
可能是客户端修改过系统 DNS 设置，退出时没有恢复，或者你曾手动把 DNS 改成了客户端的本地地址。检查系统网络设置里的 DNS 服务器，改回自动获取即可。
手机上的私人 DNS 会影响代理吗？
可能会。Android 的私人 DNS 和浏览器的安全 DNS 会绕过客户端的 DNS 处理，导致分流判断与预期不一致。排查时可以先关闭这些设置对比。
Chrome 提示 DNS_PROBE_FINISHED_NXDOMAIN 和 DNS_PROBE_FINISHED_BAD_CONFIG 有什么区别？
NXDOMAIN 表示 DNS 服务器工作正常，但查不到这个域名，先检查拼写和域名是否还在使用；BAD_CONFIG 表示 DNS 配置有误或 DNS 服务器不可用，应检查系统 DNS 设置和客户端是否残留了失效地址。
订阅链接或节点域名解析失败，是不是机场跑路了？
不能直接下结论。先换一个网络、换一个公共 DNS 查询，并查看服务商公告或备用域名；只有在多个网络、多个 DNS 下都长期解析失败时，才说明域名本身出了问题。
客户端里的 default-nameserver 和 nameserver 有什么不同？
以 mihomo 内核为例，default-nameserver 只负责解析其他 DNS 服务器自身的域名，必须填 IP；nameserver 才是日常解析网站域名用的服务器。前者填错会导致加密 DNS 全部无法启动。
网站能解析出 IPv6 地址但打不开怎么办？
如果当前网络或节点不支持 IPv6，系统优先尝试 IPv6 地址时就可能失败或变慢。可以在客户端关闭 IPv6 解析，或用 dig AAAA 和 dig A 分别查询对比，确认问题是否只出在 IPv6。
延伸阅读
- 如何挑选一个靠谱的机场：DNS 问题多数出在本地配置，换机场通常解决不了；确认是服务商域名长期解析异常时，再按这里的原则考虑备用服务。
- 代理与分流：分流规则如何根据域名决定走代理还是直连。
- 客户端配置教程：客户端 DNS 设置与配置文件说明。
- 代理与系统冲突：系统代理残留、多个网络软件冲突的处理。
- 节点连接失败：解析正常但仍然连不上时的排查。
- 节点全部超时排查：节点域名解析失败导致全部超时时的专项排查。
- TLS 与证书错误：解析到错误服务器导致证书报错时看这里。
- 订阅更新失败：订阅域名无法解析、更新报错时的处理。
- 路由器与软路由：在路由器上接管 DNS 时的设置要点。
更新记录
| 日期 | 变更 |
|---|---|
| 2026-10-07 | 首次发布完整内容 |
| 2026-10-07 | 扩写为深度指南 |
| 2026-10-08 | 按搜索结果页结构调整：开头加「两步速查：先定位问题类型」表，正文小标题改为第一步到第十一步的排查顺序 |
本专题文章
暂无文章，敬请期待。