Clash DNS 解析错误与污染修复方案（DNS Probe Finished 解决）

1. 传统明文 DNS 污染（DNS Poisoning / Spoofing）的底层机制#

在互联网的设计之初，域名系统（DNS）采用的是基于 UDP 协议的明文传输（默认端口为 53）。这种架构在设计上完全没有任何身份校验与加密机制，从而给防火墙（GFW）的旁路注入留下了巨大的攻击敞口：

1. 旁路监听与关键字捕获： 当用户在电脑上访问 www.google.com 时，本地操作系统的解析器会组装一个标准的 DNS A 记录查询报文，通过 UDP 53 端口发送给公共 DNS 服务器（如 114.114.114.114 或 8.8.8.8）；
2. 毫秒级抢答注入（Race Condition）： 该 UDP 报文在流经运营商骨干网的国际出口路由器时，部署在旁路的防火墙检测探针会即刻识别出报文中的受限域名特征；
3. 伪造虚假 IP 抢先抵达： 由于合法的海外 DNS 服务器物理距离远（往返时延通常在 100ms 以上），防火墙利用自己位于国内骨干网的地理优势，以光速抢先伪造一个包含虚假 IP（如 127.0.0.1、0.0.0.0 或某个不可达海外黑洞 IP）的 DNS 响应报文发送给你的电脑；
4. 客户端先入为主，真响应被丢弃： 操作系统遵循 UDP 协议的“先到为主”规则，直接采纳了伪造的虚假 IP 并将其写入本地系统缓存；而几百毫秒后真正由海外返回的合法响应则被操作系统当成冗余报文无情抛弃！ 客户端随后向这个被投毒的虚假 IP 发起连接，由于目标地址根本不存在代理服务，连接瞬间超时熔断。

2. 浏览器三大 DNS 报错代码的底层技术语义#

当 Chromium 浏览器（Chrome / Edge）在解析域名的过程中遭遇上述异常时，其内置的连通性诊断模块（DNS Probe）会启动自动化探测，并根据探测失败的断裂点向用户呈现不同的报错：

• DNS_PROBE_FINISHED_NXDOMAIN（域名不存在）：
  • 技术本质：NXDOMAIN 是 DNS 协议中的一个正式响应码（Non-Existent Domain），代表权威 DNS 服务器明确声明该域名尚未在互联网上注册或已被注销。
  • 在翻墙环境下的真实原因：受限域名本身绝不可能不存在！这个报错 99% 是由于浏览器开启了“安全 DNS（DoH）”并尝试直连已被封锁的海外 DoH 节点（如 cloudflare-dns.com），由于网络被直接切断且未能回退到本地网络栈，Chromium 的内部探针判定域名查询彻底落空，只能向用户展示极其误导的 NXDOMAIN；或者是某些国内运营商在拦截时，粗暴地下发了伪造的 NXDOMAIN 报文。
• DNS_PROBE_FINISHED_NO_INTERNET（无网络连接）：
  • 技术本质：Chromium 在解析失败后，会发起针对公共基线网络（如 Google 的连通性探测源）的第二轮探针探测。如果发现不仅当前域名查不到，连基线探测包也全部丢失，浏览器便判定整台电脑已经处于物理断网状态。
  • 真实原因：通常发生在启用了 TUN 模式但虚拟网卡驱动死锁，或者操作系统适配器的 DNS 服务器被篡改为了一个死地址，导致所有 DNS 查询全部超时蒸发。
• ERR_NAME_NOT_RESOLVED（无法解析主机名）：
  • 技术本质：操作系统的套接字接口（如 getaddrinfo）在向本地 DNS 服务器发起系统调用时，在设定的系统超时阈值（如 5 秒）内，没有收到任何符合格式的 UDP 报文应答。多见于本地 Clash 内核未成功监听 1053 端口，或者系统代理与本地环回端口脱节。

3. Redir-Host vs Fake-IP：代理解析的技术救赎#

为了攻克骨干网的明文 DNS 投毒，代理客户端历史上演进出了两大核心模式：

1. 浏览器的“安全 DNS（DoH）”是如何破坏代理分流的？#

Google Chrome 与 Microsoft Edge 等现代 Chromium 浏览器，为了防止公共 Wi-Fi 下的 DNS 劫持，默认推行了一项名为【使用安全 DNS（Use secure DNS）】的技术策略：

1. 绕过操作系统的本地网络栈： 浏览器内置了一套轻量级的 DNS over HTTPS（DoH）客户端。当该开关处于开启状态时，浏览器发出的所有域名解析请求，不再调用操作系统的网络底层接口，也不受系统代理注册表（WinINet）的约束！
2. 越权直连海外公共 DoH 节点： 浏览器会尝试通过标准的 HTTPS 443 端口，直接向 Google 的 https://dns.google/dns-query 或 Cloudflare 的 https://cloudflare-dns.com/dns-query 发起加密连接；
3. 直连海外 DoH 遭遇 GFW 铁壁阻断： 问题在于：中国大陆的国际骨干网早已将 Google 和 Cloudflare 的官方 DoH 服务器 IP 全部列入了黑名单阻断库！ 浏览器试图直连海外安全 DNS 的请求在出境瞬间被丢弃；
4. 拒绝降级与 NXDOMAIN 误报： 浏览器因为启用了“安全 DNS”，傲慢地拒绝接受本地 Clash 返回的 Fake-IP；在死等超时后，浏览器误以为是目标域名本身在全网不存在，于是弹出了刺眼的冷灰色报错：DNS_PROBE_FINISHED_NXDOMAIN！

2. 彻底关闭浏览器内置安全 DNS 的保姆级实操#

要让浏览器的域名解析老老实实听从 Clash 的统一调度，必须坚决彻底地关闭这一越权功能：

1. Fake-IP 的“失忆症”与系统缓存死锁#

很多用户不理解：为什么我的 Clash 明明开着，电脑也没断网，但偶尔就是打不开某些网页？ 这源于 Fake-IP 的工作特质与操作系统缓存生命周期的严重错位：

1. Clash 的易失性映射表： 在 Clash 运行时，每一个域名与虚拟 IP（如 google.com $\leftrightarrow$ 198.18.0.35）的绑定关系，默认仅仅保存在**本地内存的映射表（Pool Table）**中；
2. 客户端重启后的“失忆”： 当你重启了 Clash 客户端、切换了不同的配置文件、或者电脑休眠唤醒导致客户端内核热重载后，Clash 内存中的 Fake-IP 映射表会被清空重建；
3. 操作系统与浏览器的“顽固记忆”： 然而，Windows 系统的 dnscache 服务以及 Chrome 内部的 DNS 缓存（Host Cache），并不知道 Clash 已经经历过一次重生！它们依然死死记录着上一次分配给 google.com 的虚拟 IP；
4. 鸡同鸭讲，流量坠入黑洞： 当你在浏览器再次敲下网址时，浏览器直接拿着缓存里的旧 Fake-IP（198.18.0.35）发送网络请求。Clash 截获后翻看自己的全新映射表，发现当前根本没有任何域名绑定在这个 IP 上！ 由于不知道该把流量送给哪个真实海外服务器，Clash 只能无奈地将数据包丢弃，浏览器随后弹出无网络连接报错。

2. 三大操作系统一键深度自愈与 DNS 缓存大扫除#

针对多级缓存脱节，必须以管理员权限对操作系统的网络缓存进行一次由内而外的彻底清洗。

1
# 1. 深度清空 Windows 系统的 DNS 解析缓存
2
ipconfig /flushdns
3

4
# 2. 重启 Windows 本地 DNS 缓存核心系统服务 (消除顽固坏死句柄)
5
Restart-Service -Name dnscache -Force -ErrorAction SilentlyContinue
6

7
# 3. 彻底重置 Winsock 网络目录，根治残留钩子
8
netsh winsock reset

1
# 同时清空 macOS 的本地 DNS 缓存并重启 mDNSResponder 守护进程
2
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

1. Clash 内核的 DNS 四级决策流与调度体系#

在基于 Mihomo 或 Clash Premium 内核的配置文件中，一个标准的工业级 dns 模块包含四层互为因果的解析层级：

1
dns:
2
  enable: true
3
  enhanced-mode: fake-ip
4
  # 1. 引导启动 DNS (Bootstrap DNS): 仅用于解析 DoH 域名自身
5
  default-nameserver:
6
    - 223.5.5.5
7
    - 119.29.29.29
8
  # 2. 主力域名服务器: 处理所有常规查询与国内流量
9
  nameserver:
10
    - https://223.5.5.5/dns-query
11
    - https://doh.pub/dns-query
12
  # 3. 备用安全服务器: 专门承载海外受限域名解析
13
  fallback:
14
    - https://1.1.1.1/dns-query
15
    - https://8.8.8.8/dns-query
16
  # 4. 判定过滤器: 决定何时采纳 fallback 结果的裁判员
17
  fallback-filter:
18
    geoip: true
19
    geoip-code: CN
20
    ipcidr:
21
      - 240.0.0.0/4

Clash 内核在决定一个域名该怎么解析时，执行以下极其严格的逻辑流：

1. 并发查询机制：当发起一个外部域名解析请求时，内核会同时向 nameserver 和 fallback 发起并发查询；
2. IP 归属地裁判（GeoIP 仲裁）：
   • 如果 nameserver 最先返回的 IP 经过本地 IP 数据库（GeoIP.dat）比对属于中国大陆（CN 网段），内核认为这是一个正常且安全的国内网站，直接采纳 nameserver 的结果并秒级返回；
   • 如果 nameserver 返回的结果非中国大陆 IP，或者落在了 fallback-filter 声明的异常保留网段（如 240.0.0.0/4），裁判员会立即判定该响应极大概率遭到了运营商骨干网的投毒污染！
   • 此时内核会毫不留情地废弃掉 nameserver 返回的假数据，耐心地等待远端加密通道中的 fallback 响应，并将 fallback 返回的权威纯净 IP 交付给系统。

2. 什么是 DNS 泄漏（DNS Leak）？为什么会引发毁灭性风控？#

如果你配置不当（例如未配置 fallback-filter、或者错误地在 nameserver 中填入了海外明文 UDP DNS），就会触发臭名昭著的 DNS 泄漏：

• 泄漏的物理过程： 你在浏览器中输入了某个极其敏感的海外新闻或社交网站；由于没有进行分层加密分流，你的电脑通过本地宽带的明文 UDP 53 端口，向当地电信或联通的 DNS 服务器发送了一个带有该域名的查询包；
• 严重后果： 即便你后续的数据传输走的是完全加密的高等级专线，你的本地运营商已经在日志中完整记录下了你的宽带物理账号在某年某月某日某微秒试图访问该敏感域名！ 这不仅让端到端的隐私防护彻底归零，很多跨国金融应用（如 PayPal、Stripe、海外银行）以及 ChatGPT、Netflix 等严控反欺诈风控的服务，一旦检测到用户的 DNS 解析来源与当前的节点 IP 归属地国家不一致，会立即判定为高危欺诈账号，毫不留情地封停封号！

3. 彻底防泄漏与防投毒的黄金配置准则#

为了彻底消除 DNS_PROBE 报错并筑牢防泄漏屏障，必须遵循以下铁律：

1. 彻底淘汰明文 UDP 53，全量采用加密 DoH（DNS over HTTPS）： 明文 UDP 53 在经过国内骨干网时如同在透明玻璃中穿行，任何人都可以轻易读取和伪造；而 DoH 基于标准的 TLS 1.3 加密传输，数据流完全混杂在正常的 HTTPS 报文中，防火墙根本无法窥视查询内容，更无法进行毫秒级抢答篡改；
2. default-nameserver 严禁填写域名，必须使用纯物理 IP： 引导 DNS 的唯一职责是解析 nameserver 里那些形如 https://doh.pub/dns-query 的域名。如果引导 DNS 自己也是一个域名，系统就会陷入无法自拔的递归解析死锁！

1. 循环依赖死锁是如何发生的？#

请看以下这幕荒诞却极其真实的网络死锁悲剧：

1. 用户开启 TUN 模式，Clash 将操作系统的全局默认网关（0.0.0.0/0）修改为虚拟网卡（Wintun / Mihomo）；
2. 用户的配置文件中，nameserver 设置了阿里的纯净 DoH 地址：https://dns.alidns.com/dns-query；
3. Clash 启动后，准备建立连接，发现必须先知道 dns.alidns.com 的 IP 是多少；
4. 于是，Clash 内核向系统发出了一个针对 dns.alidns.com 的域名解析请求；
5. 悲剧发生：操作系统看到有网络数据发出，忠实地遵从 TUN 模式的最高指令，把这个查询数据包原封不动地重新塞进了 TUN 虚拟网卡！
6. 虚拟网卡把数据包交还给 Clash 核心处理；
7. Clash 核心收到这个包，发现它是一个 DNS 查询，但自己正在等待这个查询的结果才能工作……
8. 数据包在 Clash 核心与虚拟网卡之间像衔尾蛇一样无限打转，双方都在等待对方开口，最终引发操作系统网络栈的全面雪崩，所有网页在几秒钟后集体显示无 Internet 连接！

2. 解开循环依赖死锁的核心配置参数#

要斩断这个死结，必须在配置文件中建立严格的免劫持隔离区：

• 在 dns 模块中开启 fake-ip；
• 在 dns.fake-ip-filter 列表中，必须强行将所有公共 DNS 的域名以及本地局域网域名加入白名单，禁止对其分配 Fake-IP；
• 在 dns.default-nameserver 中，必须硬编码填入纯数字 IP（如 223.5.5.5、119.29.29.29），赋予内核无须解析域名即可直接通信的物理出站通道。

实操一：Clash Verge Rev 中的全局 DNS 调优#

在 Clash Verge Rev 中，你可以通过内置的图形化设置或者全局扩展脚本（Merge Script）实现 DNS 的彻底加固：

1
function main(config) {
2
  config.dns = {
3
    enable: true,
4
    listen: "0.0.0.0:1053",
5
    ipv6: false,
6
    "enhanced-mode": "fake-ip",
7
    "fake-ip-range": "198.18.0.1/16",
8
    "fake-ip-filter": [
9
      "*.lan",
10
      "*.local",
11
      "time.*.com",
12
      "ntp.*.com",
13
      "*.msftconnecttest.com",
14
      "*.msftncsi.com",
15
      "captive.apple.com"
16
    ],
17
    "default-nameserver": [
18
      "223.5.5.5",
19
      "119.29.29.29"
20
    ],
21
    nameserver: [
22
      "https://223.5.5.5/dns-query",
23
      "https://doh.pub/dns-query"
24
    ],
25
    fallback: [
26
      "https://1.1.1.1/dns-query",
27
      "https://8.8.8.8/dns-query"
28
    ],
29
    "fallback-filter": {
30
      geoip: true,
31
      "geoip-code": "CN",
32
      ipcidr: ["240.0.0.0/4"]
33
    }
34
  };
35
  return config;
36
}

实操二：Mihomo Party 中的 DNS 持久化与覆写配置#

Mihomo Party 拥有极高阶的内核特性，支持将 Fake-IP 映射持久化写入本地磁盘数据库，彻底根治重启电脑后的“失忆断网”：

1. 点击左下角【设置】->【覆盖配置（Override）】；
2. 在 DNS 覆盖项中，勾选开启 【Fake-IP 缓存持久化（Store Fake-IP）】：

   1
   dns:
   2
     store-fake-ip: true

3. 这一项开关的威力极大：它会让客户端在每次退出或重启时，把内存中的 Fake-IP 映射表自动存入本地轻量数据库。电脑重新开机后瞬间加载旧映射，彻底杜绝了 Windows 缓存脱节导致的 DNS_PROBE_FINISHED_NO_INTERNET！

实操三：FlClash 移动端 Android 私有 DNS 避坑#

在 Android 手机上使用 FlClash 时，很多用户发现同样会出现 DNS 解析失败，这通常是由于 Android 系统自带的【私人 DNS】冲突所致：

1. 打开手机【系统设置】->【网络和互联网】或【连接与共享】；
2. 找到 【私人 DNS（Private DNS）】；
3. 切勿设置为任何第三方公共 DoT 地址（如 dot.pub 或 dns.google）！如果开启，手机底层会强行接管所有 TLS 853 端口发包，与代理客户端争权导致断网；
4. 将其直接设置为 【关闭（Off）】 或 【自动】，让代理客户端的原生 VPN 框架全权掌控 DNS 调度。

1. 主流公共 DNS 服务商抗污染与性能全景测试矩阵#

在测试中，我们固定向各 DNS 节点并发发送 1,000 次针对国内顶级大厂域名（如 taobao.com、bilibili.com）以及海外受限域名（如 google.com、twitter.com）的解析请求，记录其平均解析延迟（毫秒）、抗污染成功率、国内 CDN 就近调度精准度以及防 DNS 泄漏等级：

2. 三大 DNS 解析工作模式深度技术对比#

很多新手在面对 fake-ip、redir-host 与传统的系统直接解析时常常摸不着头脑。下表深入剖析了这三种模式在底层性能与稳定性上的本质差异：

1. 工业级抗投毒高可用 DNS 模块配置范本#

将以下经过深度调优的配置片段，完整覆盖到你的配置文件（Profile）对应的 dns 区域中：

1
# ===========================================================
2
# 青云宗高可用生产级 DNS 配置范本 (深度防投毒与防泄漏加固版)
3
# ===========================================================
4
dns:
5
  enable: true
6
  listen: 0.0.0.0:1053
7
  ipv6: false
8
  # 强烈推荐 fake-ip 模式，实现 0 毫秒首包解析与彻底防污染
9
  enhanced-mode: fake-ip
10
  fake-ip-range: 198.18.0.1/16
11

12
  # 开启 fake-ip 缓存持久化 (需客户端 Mihomo 内核支持，彻底根治重启失忆)
13
  store-fake-ip: true
14

15
  # 关键避坑过滤列表: 严禁将这些特定域名分配 Fake-IP，防止回环死锁
16
  fake-ip-filter:
17
    # 本地局域网服务与多播域名
18
    - "*.lan"
19
    - "*.local"
20
    - "*.localhost"
21
    # Windows 网络连通性测试 (NCSI) 专用探针
22
    - "*.msftconnecttest.com"
23
    - "*.msftncsi.com"
24
    # 苹果生态连通性测试
25
    - "captive.apple.com"
26
    # NTP 网络授时服务 (确保系统时间永远毫秒级对齐)
27
    - "time.*.com"
28
    - "ntp.*.com"
29
    - "*.pool.ntp.org"
30
    # 游戏战网与主机联机直连通信
31
    - "*.battlenet.com.cn"
32
    - "*.stun.*.*"
33

34
  # 1. 引导启动 DNS (纯物理 IP，严禁写域名，彻底斩断递归死锁)
35
  default-nameserver:
36
    - 223.5.5.5
37
    - 119.29.29.29
38

39
  # 2. 国内主力加密 DNS (通过 TLS 1.3 加密，全国 CDN 极速就近调度)
40
  nameserver:
41
    - https://223.5.5.5/dns-query
42
    - https://doh.pub/dns-query
43

44
  # 3. 海外受限域名专属安全兜底 (杜绝 DNS 泄漏与运营商监听)
45
  fallback:
46
    - https://1.1.1.1/dns-query
47
    - https://8.8.8.8/dns-query
48

49
  # 4. 仲裁过滤器: 精准识别 GFW 伪造投毒响应并强制切换 fallback
50
  fallback-filter:
51
    geoip: true
52
    geoip-code: CN
53
    ipcidr:
54
      - 240.0.0.0/4
55
      - 0.0.0.0/8
56
      - 127.0.0.0/8

2. Windows PowerShell DNS 自动化深度体检与一键自愈脚本#

当你的浏览器频繁弹窗 DNS_PROBE_FINISHED_NXDOMAIN 时，以管理员身份运行以下排障脚本。它会自动对运营商底层解析、DoH 加密连通性、本地缓存状态进行全链路穿透诊断，并自动执行三层缓存深度清洗：

将以下代码保存为 Fix-ClashDNS.ps1，在管理员 PowerShell 中直接粘贴执行：

1
# ===========================================================
2
# 青云宗 Clash DNS 故障深度排查与自动修复工具 (PowerShell 脚本)
3
# ===========================================================
4
Write-Host "======================================================" -ForegroundColor Cyan
5
Write-Host "   Clash DNS 解析异常与 DNS_PROBE 故障一键自愈工具" -ForegroundColor Cyan
6
Write-Host "======================================================" -ForegroundColor Cyan
7

8
# 1. 检测本地运营商底层 DNS 是否遭遇明文投毒
9
Write-Host "[1/5] 正在测试本地运营商明文 DNS 是否遭遇严重投毒..." -NoNewline
10
try {
11
    $pollutedTest = Resolve-DnsName -Name "twitter.com" -Server 114.114.114.114 -ErrorAction Stop | Select-Object -First 1
12
    $pIP = $pollutedTest.IPAddress
13
    Write-Host " [完成]" -ForegroundColor Green
14
    Write-Host "      114 返回结果: $pIP (若为 127.0.0.1 或死地址即为典型 GFW 投毒)" -ForegroundColor Yellow
15
} catch {
16
    Write-Host " [超时未响应 WARN]" -ForegroundColor Yellow
17
}
18

19
# 2. 测试国内纯净 DoH (阿里 223.5.5.5) 的连通性
20
Write-Host "[2/5] 正在测试阿里公共 DoH (https://223.5.5.5/dns-query) 可达性..." -NoNewline
21
try {
22
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
23
    $req = [System.Net.HttpWebRequest]::Create("https://223.5.5.5/dns-query")
24
    $req.Timeout = 3000
25
    $req.Method = "GET"
26
    $res = $req.GetResponse()
27
    $sw.Stop()
28
    Write-Host " [正常 OK] 耗时: $($sw.ElapsedMilliseconds) ms" -ForegroundColor Green
29
    $res.Close()
30
} catch {
31
    Write-Host " [连接失败 FAIL] -> 本地网络可能阻断了 DoH 握手！" -ForegroundColor Red
32
}
33

34
# 3. 检查本地 1053 端口 (Clash 内核 DNS 监听)
35
Write-Host "[3/5] 正在检查 Clash 内置 DNS 监听端口 (1053)..."
36
$dnsPort = Get-NetTCPConnection -LocalPort 1053 -State Listen -ErrorAction SilentlyContinue
37
if ($dnsPort) {
38
    Write-Host "  -> 端口 1053 正在被正常监听 (PID: $($dnsPort[0].OwningProcess))" -ForegroundColor Green
39
} else {
40
    Write-Host "  -> 端口 1053 未处于监听状态 (若开启 TUN 模式可能为虚拟驱动直接接管)" -ForegroundColor Gray
41
}
42

43
# 4. 执行多级缓存与系统套接字彻底清洗
44
Write-Host "[4/5] 正在执行 Windows 本地三层 DNS 缓存深度清洗..."
45
Write-Host "  -> 清空系统 DNS 解析缓存 (ipconfig /flushdns)..." -NoNewline
46
ipconfig /flushdns | Out-Null
47
Write-Host " [完成]" -ForegroundColor Green
48

49
Write-Host "  -> 重启 Windows 本地 DNS 缓存核心服务 (dnscache)..." -NoNewline
50
Restart-Service -Name dnscache -Force -ErrorAction SilentlyContinue
51
Write-Host " [完成]" -ForegroundColor Green
52

53
# 5. 给出最终修复建议
54
Write-Host "------------------------------------------------------" -ForegroundColor Gray
55
Write-Host "[5/5] 自愈与操作建议：" -ForegroundColor Cyan
56
Write-Host "  1. 请务必打开 Chrome/Edge 设置，彻底关闭【使用安全 DNS】开关！"
57
Write-Host "  2. 在浏览器地址栏输入 chrome://net-internals/#dns 点击 Clear host cache。"
58
Write-Host "  3. 若刚切换过节点，请在客户端中重载一次配置以对齐 Fake-IP 映射池。"
59
Write-Host "======================================================" -ForegroundColor Cyan

案例一：Chrome 开启“安全 DNS”导致全网频繁报错 DNS_PROBE_FINISHED_NXDOMAIN#

案例二：客户端非正常退出后系统适配器 DNS 被篡改导致断网#

案例三：开启 TUN 模式后特定局域网服务因 Fake-IP 映射失效全部失联#

Q1: 什么是 DNS_PROBE_FINISHED_NXDOMAIN？和网络超时有什么区别？#

• DNS_PROBE_FINISHED_NXDOMAIN：代表域名解析环节直接落空（权威域名系统告诉你该域名不存在）。通常发生在浏览器开启了海外 DoH 遭到 GFW 丢包、或者本地 DNS 配置错误完全无法翻译域名的时刻。此时通信甚至尚未开始建立 TCP 连接。
• 网络超时（Connection Timed Out）：代表域名解析已经顺利完成并拿到了 IP 地址，但在向目标 IP 发起 TCP 三次握手或等待数据传输时，由于机房宕机、路由丢包或 GFW 阻断导致超时。排查时前者查 DNS 与浏览器，后者查节点与代理路由。

Q2: 为什么开启 Clash 之后，国内某些网站打开速度反而变慢了？#

这属于典型的“国内 DNS 解析偏离与 CDN 负优化”：

• 如果你的配置文件中，nameserver 被错误地填入了海外公共 DNS（如 8.8.8.8 或 1.1.1.1）；
• 当你访问国内的淘宝、腾讯视频或 bilibili 时，海外 DNS 会误以为你身处海外机房，于是给你分配了一个位于美国或香港的海外 CDN 边缘节点；
• 你的电脑被迫绕大半个地球去拉取国内网站的视频和图片，网页加载自然慢如蜗牛；
• 根治方法：确保 nameserver 严格配置国内顶级的阿里 DoH（https://223.5.5.5/dns-query）或腾讯 DoH（https://doh.pub/dns-query），确保国内网站永远就近解析到离你家最近的本省 CDN 机房。

Q3: Fake-IP 和 Redir-Host 到底选哪一个？哪个更适合日常使用？#

毫无疑问，在 2026 年请坚定不移地选择【Fake-IP】模式！

• Redir-Host 模式在现代网络对抗中已经被基本淘汰。由于它必须在本地获得域名的真实海外 IP，极易在本地引发 DNS 污染、DNS 泄漏以及极其明显的几百毫秒首包解析卡顿；
• Fake-IP 模式不仅彻底根除了本地 DNS 污染，更实现了惊人的 0 毫秒首包响应，同时完美支持各类全协议代理分流。目前全网主流的高性能开源客户端均将 Fake-IP 作为默认甚至唯一的推荐架构。

Q4: 怎么判断自己是否存在 DNS 泄漏（DNS Leak）？#

验证是否存在 DNS 泄漏非常简单，只需两步：

1. 打开浏览器无痕隐身窗口，访问国际公认的权威测试平台：https://browserleaks.com/dns 或 https://dnsleaktest.com；
2. 点击进行【Extended Test（深度扩展测试）】：
   • 安全状态：测试结果列表中显示的所有 DNS 服务器 IP，全部位于你的代理节点所在国家（如香港、日本、美国），且绝对不包含任何你家本地宽带运营商（如中国电信、中国联通、中国移动）的 IP；
   • 泄漏状态：如果列表中赫然出现了中国大陆的 IP、或者出现了你所在城市的运营商名字，证明你存在严重的 DNS 泄漏！请立即按照本文第七章的模板重写 dns 模块并启用纯净 DoH。

Q5: 为什么在命令行里 ping google.com 返回的都是 198.18 开头的奇葩 IP？#

这完全是 Fake-IP 模式正常工作的标准标志，绝非系统中毒或故障！

• 198.18.0.0/16 是互联网工程任务组（IETF RFC 2544）专门保留用于网络设备基准性能测试的内网私有网段；
• Clash 正是巧妙地利用了这个合法的保留网段作为虚拟地址池。当你在命令行输入 ping google.com 时，系统收到的是 Clash 临时分配给它的 Fake-IP 代号；
• 只要在浏览器中网页能够秒开，这个 198.18.x.x 就是完全健康且合规的。

Q6: 为什么只有公司的内部局域网域名（如 .local, .corp）打不开？#

由于公司内部域名只存在于公司内网的私有 DNS 服务器中，公网权威 DNS 根本查不到：

• 默认情况下，Clash 可能会尝试将 .corp 域名分配 Fake-IP 并送往海外节点解析，海外机房自然返回解析失败；
• 解决办法：在配置文件的 dns.fake-ip-filter 中追加一行 "- *.corp"，并在 rules 规则顶部添加 DOMAIN-SUFFIX,corp,DIRECT，让内网域名直接走物理网卡向公司内网 DNS 查询。

Q7: 本地物理网卡的 DNS 应该填什么？需要手动改成 223.5.5.5 吗？#

• 绝大多数普通用户：保持【自动获得 DNS 服务器地址】（DHCP 自动分配）即可！ 因为在开启系统代理或 TUN 模式后，所有的有效网络连接都会被 Clash 内部的 DNS 引擎接管，修改本地物理网卡的 DNS 意义不大；
• 特定运营商极端干扰用户：如果你所在地区的运营商存在极其流氓的本地 DNS 弹窗广告劫持，可手动将物理网卡的首选 DNS 改为阿里的 223.5.5.5，备用改为腾讯的 119.29.29.29，有助于提升本地网络基础连通性的纯净度。

Q8: 遇到无法解决的 DNS 故障，如何一键复原操作系统的网络状态？#

如果你此前经过了大量混乱的尝试、导致整个 Windows 网络彻底混乱：

1. 以管理员权限运行 CMD 或 PowerShell；
2. 一口气执行 Windows 网络协议栈三大重置黄金命令：

   1
   netsh winsock reset
   2
   netsh int ip reset
   3
   ipconfig /flushdns

3. 重启一次电脑。系统网络套接字目录与适配器参数将彻底复原到微软出厂纯净状态。