从原理到实践：Mihomo/Clash的TUN、DNS与Fake-IP配置取舍与常见误区解析-国外VPS测评

Clash 作为网络代理领域中最经典、生命力最顽强的解决方案之一，经历了 Clash → Clash Premium → Clash Meta → Mihomo 等多个内核的迭代传承，逐步形成了一个极其庞大且成熟的生态系统。

在这个生态中，已经沉淀了大量优秀的文档、订阅转换工具以及配置参考方案。
但在实际使用中你很快会发现：文档并不总是足够细致，教程之间高度趋同，而其中许多被广泛照搬的配置组合，本身就存在值得推敲的设计问题和隐含的坑点。

因此，本文中你会看到不少与常见教程不同的配置选择，我也会逐一解释其背后的原因。

需要特别说明的是：
Clash 的很多配置项并不存在放之四海而皆准的“标准答案”。
它们往往需要结合 TUN、DNS、规则、平台特性等多个维度综合判断，在安全性与性能之间取得平衡。这也意味着，“开了某个选项 ≠ 一定更好”。
理解其工作原理，知其所以然，才是配置稳定、可控代理环境的关键，这正是本文的目的。

本文基于以下环境进行说明与示例：

内核：Mihomo
平台：Android / Windows
客户端：FlClash

文中每一部分我都会给出对应的参考配置，并结合实际行为进行分析。

01 TUN：透明代理并非没有代价

tun:
  enable: true
  stack: mixed
  strict-route: true
  auto-route: true
  dns-hijack:
    - any:53
  mtu: 1280
  disable-icmp-forwarding: true

TUN 是什么，以及它“看起来很美好”的地方

关于 TUN 的基础概念已经有大量文章讲解，这里不再赘述。简单来说：

TUN 是一块三层虚拟网卡
系统流量被路由到这块虚拟网卡
Clash 在此解析、分流并转发流量
对应用程序而言几乎是“无感知”的

也正因如此，我们通常把 TUN 称为一种透明代理方案：
浏览器、桌面程序、命令行工具都无需特殊配置，就像面对一张真实存在的物理网卡。

但问题也恰恰出现在这里。

strict-route 与 Windows 智能多宿主名称解析

在大量“防止 DNS 泄露”的教程中，经常能看到一个建议：

在 Windows 组策略中关闭「智能多宿主名称解析」。

但这个建议本身是有问题的。

什么是智能多宿主名称解析？

这是 Windows 的一项工程级优化策略：

DNS 查询会同时发送到所有网络接口
使用最先返回的结果，或根据接口 metric 选择
目的在于提升解析成功率和速度

问题真正出在哪里？

很多人误以为：

DNS 泄露是智能多宿主解析导致的

但实际上，根源在于 strict-route = false 时的 TUN 行为。

当 strict-route: false：

Clash 不会强制所有流量进入 TUN
系统原有路由表仍然生效
DNS 查询可能同时走：
- 物理网卡（直连）
- Clash 的 TUN 接口

如果物理网卡的 DNS 响应先返回，就会绕过 Clash 的 DNS 处理逻辑，看起来就像“泄露”了一样。

即便你关闭了智能多宿主解析，只要存在：

物理网卡支持 IPv6
Clash 配置中禁用了 IPv6

在 DNS 测试中，依然可能看到本应远端解析的 AAAA 记录被本地解析。

strict-route = true：并非银弹

将 strict-route 设为 true 后：

Clash 会写入更激进的路由规则
所有流量被强制导向 TUN
DNS 不再受多宿主解析策略影响

看起来一切都解决了，但新的问题随之而来。

在相关 issue 中可以看到，当同时开启 strict-route 并禁用智能多宿主解析时：

页面刷新后不会立即发起 DNS 查询
打开新网页会出现极其严重的首包延迟
体验几乎不可接受

正确的实践建议

strict-route: true
不要禁用 Windows 的智能多宿主名称解析（保持默认）
若在 WSL 等环境中出现异常：
- 尝试将 mtu 调整为 1500
- 或使用 IPv6 规定的最小值 1280

ICMP：TUN 的隐藏成本

在 TUN + fake-ip 场景下：

ping 到的永远是 fake-ip 池中的地址
ICMP 包要么被丢弃，要么发往不存在的目标
最终表现为全部超时

此外，在相关 issue 中也可以看到：

本地运行 Tailscale、某些游戏或网络工具时
可能触发 ICMP 回环
导致数万条 ICMP 包
引发长期高 CPU 占用

因此，TUN 并不是免费的午餐。
在我的配置中，选择禁用 ICMP 转发以规避这类问题：

disable-icmp-forwarding: true

02 DNS：最复杂、也最容易被误解的部分

dns:
  enable: true
  prefer-h3: false
  cache-algorithm: arc
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-range6: fc00::/18
  use-hosts: true
  use-system-hosts: true
  respect-rules: false
  rebind: false
  default-nameserver:
    - system
  proxy-server-nameserver:
    - system
  nameserver:
    - system
  fake-ip-filter:
    - geosite:connectivity-check
    - geosite:private
    - geosite:cn
    - +.stun.*.*
    - +.stun.*.*.*
    - +.stun.*.*.*.*
    - +.stun.*.*.*.*.*
    - "*.n.n.srv.nintendo.net"
    - +.stun.playstation.net
    - xbox.*.*.microsoft.com
    - "*.*.xboxlive.com"
    - +.msftncsi.com
    - +.msftconnecttest.com
    - +.teracloud.jp
    - +.lan
    - localhost.ptlogin2.qq.com
    - WORKGROUP

DNS 是 Clash 配置中对使用体验影响最大、同时也是最令人头疼的一部分。下面分点说明。

fake-ip vs redir-host：核心区别

RFC3089 中描述的 Fake IP，被认为是：

四层代理分流场景下
性能最好
体验最好
实现成本最低

的最佳实践。

在 TUN + fake-ip 模式下，访问 Google 的完整流程如下：

应用请求解析 google.com
DNS 请求被劫持至 Clash
Clash：
- 不做真实解析
- 返回一个 198.18.x.x 的 fake-ip
- 建立映射关系
应用向 fake-ip 建立连接
Clash 根据映射还原域名
按规则选择出站
由代理服务器在远端解析真实 IP 并连接

关键点：本地根本没有解析 Google 的真实 IP。

fake-ip 场景下，为什么不需要 fallback

在规则设计合理的情况下：

域名已经在规则阶段完成分流
不想暴露的请求早已被送往代理
即便后续存在 IP 规则判断：
- 被污染的解析结果也不会影响最终走向

因此，在 fake-ip 模式下：

fallback
fallback-filter

本质上是多余的配置。

为什么我选择 system DNS

原因有三：

性能
- fake-ip 场景下不存在 DNS 污染问题
- 本地递归 DNS 能更快返回直连 CDN
内网兼容
- 校园网、公司内网、自建 DNS
- system DNS 可以自动适配
规则兜底
- 即便极端情况下获取到错误 IP
- 也会在规则阶段被正确处理

redir-host 的天然劣势

在 redir-host 模式下：

本地必须完成真实 DNS 解析
需要 fallback 防污染
存在真实 DNS 泄露
增加一次 DNS 往返延迟
在嗅探失败时丢失域名信息

极端情况下甚至会出现：

北京 → 本地解析北京 CDN → 发往美国代理 → 再绕回北京

而 fake-ip 模式完全避免了这一问题。

fake-ip-filter：必要的例外

以下场景不适合 fake-ip：

STUN / P2P
局域网发现
NTP
部分游戏与设备发现协议

这里推荐使用 geosite 进行通配：

减少遗漏
提高稳定性
避免冲突
提升排障可控性

关于嗅探（sniff）

嗅探的存在意义在于 redir-host：

通过 TLS ClientHello 提取 SNI
还原域名信息

而在 fake-ip 场景中：

域名映射表早已存在
嗅探只是在“重复确认已知信息”
反而可能导致 FCM 等服务异常

不推荐 fake-ip + sniff 的组合。

prefer-h3：为什么我选择关闭

官方文档已明确不推荐：

prefer-h3
与 respect-rules 同时使用

此外：

QUIC 在高峰期可能随机丢包
实际体验不一定优于 HTTP/2
可能反而劣化稳定性

因此选择关闭。

浏览器行为补充

Chrome 等浏览器可能启用：

自带 DNS
DoH

在 fake-ip 场景下：

这是多余的
且可能降低性能

建议关闭。

03 分流规则

推荐使用 skkmoe 维护的规则集，原因包括：

CDN / 下载流量可单独分流至低倍率节点
提供 REJECT-DROP 避免广告域名反复重试
规则准确性针对性优化
AIGC 服务单独分组
解决 macOS Telegram 随机 IP 问题

注意事项：

一定要先写域名规则，再写 IP 规则
否则会带来多余解析、性能下降，甚至 DNS 风险。

04 拾遗

WebUI

FlClash 本身体验不错，但：

日志
连接查看

功能有限，且作者暂无优化计划。

可以启用 Mihomo 官方 WebUI：

FlClash → 基本配置
打开「查找进程」
启用外部控制器
浏览器访问 WebUI

用于排障非常方便。

FCM

官方文档指出：

FCM 无法通过网络代理

我曾长期相信这一点，并坚持直连。
但近期发现：

部分代理节点可以稳定连接 FCM
Android 上 tcp-keep-alive 被强制禁用
实际性能并未明显恶化

国行 Android 的省电策略仍会在锁屏断连，目前不 root 基本无解。
但亮屏状态下，Passkey、验证通知等已基本可用。

本文来源：C。―关于Clash配置的侧面― – 开发调优 – LINUX DO