C。―关于Clash配置的侧面―

问题描述：

Clash作为网络代理的经典解决方案，经过了Clash、Clash Premium、Clash Meta、Mihomo等多个核的薪火相传，积累了强大的生态。网络上不乏各种这个庞大生态中涌现的优秀的文档、订阅转换工具、配置参考等。

但很多时候文档未必细致全面，很多被大量使用的教程和参考里面趋同的配置中，各个具体链路的合理性也还有一些值得推敲的问题和坑。所以本文中可以看到和许多教程/参考配置中的不同之处，我也会一一说明。

此外，由于很多Clash配置项并非一成不变的标准答案，很多时候需要根据其它多个配置综合判断，确保安全的同时兼顾性能，并不是说某个配置开了就一定比不开好。这同样要求在使用的过程中知其所以然，这也是本文的目的。

本文以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是一块三层的虚拟网卡，将流量路由到虚拟网卡中进行解析和分流，达到代理的效果。由于TUN理论上对于客户端应用程序来说是透明无感知的，即浏览器、桌面应用、乃至终端程序等各类应用面对TUN的行为不需要变化，就像面对一块真实存在的物理网卡，所以我们说TUN是一种透明代理。

但真的有这么简单美好吗？

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

很多关于防止DNS泄露的帖子中会写到：如果Windows环境发生DNS泄露则在组策略中关闭智能多宿主名称解析。但事实上这样做是有问题的。
所谓多宿主名称解析，是指Windows系统将DNS查询同时发往所有网络接口，采用最先返回的结果或者按照接口metric值选择最佳结果，用来提升DNS体验的工程方案。

前面提到的TUN关于劫持网卡流量进行透明代理的说法很有迷惑性：实际上，strict-route为false时，Clash不会强制劫持所有流量到TUN，系统原有路由表仍然生效。查询同时走物理网卡和Clash的TUN接口，物理网卡直连的DNS响应可能先到达，绕过Clash的DNS处理逻辑。

但智能多宿主名称解析并非问题根源所在。实际实践中，即使禁用了该选项，由于物理网卡支持ipv6但Clash配置禁用了ipv6等原因，在DNS泄露测试中，往往可能出现多条本该远端解析的AAAA记录走本地DNS解析。

如果我们把strict-route设置为true，Clash会添加更激进的路由规则，把所有流量强制导向TUN，避免DNS被多宿主解析策略干扰带来的问题。
你可能认为这就万事大吉了。但与此同时，这条issue中我们看到，开启strict route并禁用智能多宿主解析时，刷新网页不会立即发送DNS请求，这导致打开新网页时延迟极其严重，达到令人几乎无法忍受的程度。

正确做法是，将strict-route设置为true，同时在Windows中将“禁用智能多宿主解析”选项设置为默认或关闭。此时如果WSL等环境出现网络波动，则调低mtu，设置为1500，或设置为ipv6规定的最小值1280。

ICMP

TUN接管系统流量后，使用fake-ip，ICMP ping到的永远是fake-ip池中的地址，最终ICMP包要么被丢弃要么发往不存在的地址最终超时。
同时在这条issue中我们看到，如果本地跑了tailscale或一些游戏软件，可能造成ICMP回环，几万条ICMP包导致长时高CPU占用。所以TUN并非免费的午餐，由于TUN自身的设计，在某些场景下我们可能需要做出妥协。我的配置中禁用了ICMP转发。

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与redir-host，以及如何选择DNS服务器

2001 年 4 月 IETF 通过的 RFC3089 中所描述的 Fake IP，是四层代理分流场景下 性能相对最佳、体验相对最好、实现相对最简单的「最佳实践」。
来源：是什么，为什么，怎么做 —— 谈谈 DNS 泄漏、CDN 访问优化与 Fake IP
链接：https://blog.skk.moe/post/lets-talk-about-dns-cdn-fake-ip/

对深入了解代理DNS解析方式有兴趣的可以看看上面的文章。此外这篇文章也指出了对于所谓DNS泄露的迷思。

虽然很多人诟病fake-ip引入的复杂性以及各种小问题，但fake-ip仍旧良好地解决了分流远端解析DNS的问题，并由于其设计提供了几乎零成本的CDN访问优化。

理解fake-ip的工作流程是后续DNS配置的基础。在TUN+fake-ip场景下，一个访问Google的完整请求流程如下：

1. 应用发起请求：应用调用系统 API 解析 google.com
2. TUN 接管：auto-route: true 让系统路由表指向 TUN 设备，dns-hijack: any:53 劫持所有 53 端口 DNS 请求到 Clash 内置 DNS
3. Clash DNS 处理
   • 检查 fake-ip-filter，google.com 不匹配
   • 返回 fake-ip（198.18.x.x 段内的一个地址）
   • 内部建立映射：198.18.0.5 ↔ google.com
4. 应用向 198.18.0.5:443 发起 TCP 连接
5. Clash 收到目标 198.18.0.5 的流量，通过映射表还原为 google.com
6. 规则匹配：按顺序匹配 rules，走命中的代理组，发给远端（如果国内域名命中了DIRECT规则就直接在本地直连）
7. 代理出站：代理服务器收到请求后，在远端解析 google.com 的真实 IP 并建立连接

可以看到，在fake-ip策略下，Google的DNS根本没在本地进行解析！

即使我们考虑进那些关于所谓DNS泄露的迷思，如果规则写得足够合理的话，Clash在域名规则匹配阶段就将我们不想让国内运营商看到的DNS请求解决了（其实相当于redir-host中nameserver-policy防泄露的作用），此时域名已经由规则拦截过一遍，即使后续有需要解析的IP规则，使用本地或国内的DNS解析也没问题，所以配置fallback和fallback-filter在fake-ip场景下是多余的。对于国内流量，由域名匹配到国内规则直接由国内DNS解析，同时可以享受EDNS带来的性能优势。

剩下的DNS服务器越快越好，选择国内的即可，即使真的需要走IP规则判断路由并获得了被污染的解析结果，在IP规则下也会因为规则匹配和兜底而正确地发送给代理服务器做正确的解析。如果很在意不加密的DNS或者你的网络环境实在太差，可以选择国内的大厂DoT/DoH。很多参考配置会完全选择国外的DNS，其实完全没有必要。

我的配置中选择system，一是由于性能考量，在fake-ip方案中不存在DNS污染的情况下，本地递归DNS解析获取到的直连CDN地址会更快；二是如果你处于校园网或公司局域网等内网环境中，system可以覆盖内网DNS地址解析的问题，避免内网域名访问失败。如果还需要公共DNS来兜底，覆盖系统DNS解析出问题的情况，也可以在nameserver部分自行添加。

以防你真的很在意所谓的DNS泄露，可以看到在规则合理的情况下，使用上述配置测试，也不会存在大陆出口的DNS解析，同时性能上会好很多：
Screenshot_2026-01-15-01-14-12-222_com.microsoft.emmx-202601150115279801076×2202 432 KB

与此同时，另外一边…在redir-host模式下访问流程是这样的：

1. 应用发起请求：应用调用系统API解析google.com
2. TUN接管：同样劫持DNS请求到Clash内置DNS
3. Clash DNS处理
   • 向配置的上游DNS发起真实查询
   • 如果配置了fallback，同时向fallback服务器查询
   • 根据fallback-filter判断使用哪个结果
   • 返回真实IP（如142.250.185.78）给应用
4. 应用向142.250.185.78:443发起TCP连接
5. Clash收到流量，需要反查/嗅探这个IP对应的域名才能做域名规则匹配
6. 规则匹配后走对应代理出站

第3步必须在本地完成真实DNS解析决定了redir-host场景下需要fallback机制回退到Google或Cloudflare等公共DNS解析，否则会被DNS污染返回错误IP，并且会有所谓的DNS泄露问题发生。
此外本地解析后发给代理服务器，代理服务器会再次进行解析，增加了延迟（多一次DNS往返）。
在嗅探失败时域名信息丢失，服务器只能收到裸IP的情况下，性能上也存在问题：举个极端的例子，你在北京，本地DNS返回的是北京CDN节点的IP。这个IP发给一个美国的代理服务器，服务器只能连北京的CDN，流量绕了一大圈最终又绕回来回到北京。如果代理服务器自己解析域名，拿到的则是美国附近的CDN节点，于是更快。

更多配置技巧和解释可以查看此文章。

fake-ip-filter

依赖本地网络发现、stun、P2P连接、局域网设备、NTP时间同步、特殊协议等少部分域名，遇fake-ip会发生冲突而失效。所以需要绕过fake-ip，客户端请求时使用解析到的真实IP返回。

其实各类教程和参考配置里很少见的一点是，这里可以使用geosite进行通配，避免遗漏的同时，可以将常见cn域名都直接解析，不需要返回假IP，提高效率和稳定性，方便排障，同时避免冲突。

关于嗅探

很多教程会在配置了fake-ip后继续配置嗅探（sniff）。但既然我们刚才已经完整讲述了fake-ip的工作过程，就会发现：嗅探在这里也是相对多余的。注意到fake-ip工作流程的第五步，Clash 收到目标 198.18.0.5 的流量，通过映射表还原为 google.com，如果开启嗅探，TLS ClientHello 中提取 SNI，确认域名为 google.com，嗅探到的是映射表里已知的内容。

实际上嗅探是为了redir-host而存在的，在fake-ip场景下必要性相对小。fake-ip场景下sniffer主要用于再次匹配入站流量中没走DNS或未正确获取域名的情况，作为一种边缘情况的兜底让域名匹配规则重新生效，但开启override-destination选项时反而可能导致fcm等服务出现不可预料的连接问题，下面有佬做了详细解释。很多参考配置和教程用fake-ip配合嗅探，本文不太推荐这种方式，即使打开sniffer，也不推荐开override-destination。

关于prefer-h3

官方文档强烈不推荐respect-rules搭配prefer-h3。虽然我的配置或者说fake-ip的配置不需要开respect-rules，但由于HTTP/3是建立在QUIC上的，晚高峰时期可能会出现随机丢包等不可控情况，而且实际上开启并不一定有正面效果，反而可能由于各种原因劣化体验。当前么…虽然我是一个喜欢追新的人，但我选择不开。

关于浏览器行为

Chrome等浏览器可能会使用自己的DNS来解析域名，这对于fake-ip来说是多余且有损性能的。如果你使用fake-ip，建议在设置里关闭。

03 分流规则

建议使用skkmoe维护的这套规则集，可以覆盖大部分场景，不足的可以根据需要自行补充自己的规则。
推荐的主要理由是：

• 可以专门为CDN和下载这类不需要过盾的大流量场景分流，设置低倍率节点/脏节点，节省流量
• 对于一些无良广告域名，如果使用REJECT拦截，可能会大量反复重试请求导致CPU占用升高或发热等问题。这套规则集提供了静默丢弃等待超时的REJECT-DROP规则缓解该问题。
• 对于规则准确性做了针对性优化。
• AIGC类服务有单独规则，可以设置干净的节点或家宽。
• 解决MacOS端Telegram连接随机IP的可疑问题。

唯一需要注意的是：一定要先写域名规则再写IP规则，否则会有多余解析导致的性能问题和DNS泄露风险。

04 拾遗

WebUI

FlClash是一个体验不错的跨平台客户端。但日志和连接查看功能上还是有所欠缺，而且根据issue情况来看作者并无意优化这些部分。别的客户端可能综合体验还不如FlClash。此时可以通过mihomo官方提供的WebUI来弥补：FlClash设置→基本配置→打开查找进程，打开外部控制器。此时可以通过浏览器访问WebUI连接本地的mihomo内核，获得更好的日志和链接查看体验，并方便地排查使用问题。

FCM

FCM官方文档中指出：

FCM 用于向设备传送推送消息的协议无法通过网络代理进行代理。因此，您需要确保网络中设备的 FCM 连接可以直接连接到我们的服务器。

我一直相信官方文档，所以我历来打开Clash禁止应用绕过VPN，使用直连方式连接FCM。但平时直连经常不稳定，遇到特殊时期流量阻断只能一个人躲在被窝里偷偷抹眼泪。
但实际上最近我发现一些支持长连接的代理节点（即idle timeout较长，由于FCM的心跳间隔是15分钟左右）可以长时稳定连接FCM，似乎和官方说法不同。由于tcp-keep-alive在Android端被强制禁用，似乎也没有太大性能问题。

国行安卓会在不连接充电器锁屏时因为省电策略而断开FCM连接，以前可以通过替换电量应用解决但现在似乎也不行了，目前不root很难解决。但目前看来亮屏时连接稳定性很好，至少平时连passkey、收验证通知都没什么问题。

网友解答：

---

--【壹】--： MUTED64:

很多教程会在配置了 fake-ip 后继续配置嗅探（sniff）。但既然我们刚才已经完整讲述了 fake-ip 的工作过程，就会发现：嗅探在这里也是完全多余的。

嗅探在这里并不是完全多余的，在fake-ip场景下sniffer主要用于再次匹配入站流量中没走DNS或未正确获取域名的情况，作为兜底让域名匹配规则重新生效

---

--【贰】--：

好文章，有时间了消化一下

---

--【叁】--：

严肃学习好文，给作者打赏，怎么打赏不了

---

--【肆】--：

正常情况下应该是开了兜底没坏处，但我这里开启sniffer尤其是override-destination时似乎会对FCM连接的稳定性产生一些影响

后来想了一下我能用到sniffer的场景一般只有浏览器内置的DNS解析和Telegram IP，浏览器解析我关掉了，Telegram我使用官方发布的CIDR列表作为规则，实际上对于兜底的需求不强烈

当然这个还是看个人需求吧，可能有些人和我不同的特殊使用场景确实需要？

---

--【伍】--：

已严肃学习。

---

--【陆】--：

佬友有所收获就好

---

--【柒】--：

大佬的文章讲得很细

---

--【捌】--：

支持技术大神

---

--【玖】--：

深度好文

---

--【拾】--：

好文章。但是我还得慢慢消化

---

--【拾壹】--：

学到了，抽空再改造改造我的 mihomo 配置

---

--【拾贰】--：

感谢佬友支持

---

--【拾叁】--：

支持技术大神

---

--【拾肆】--：

已严肃学习

---

--【拾伍】--：

感谢分享，不过还是太难消化了

---

--【拾陆】--：

感谢大佬

---

--【拾柒】--：

严厉谴责小猫

---

--【拾捌】--：

我已打赏

---

--【拾玖】--：

感谢大佬！