分享一套开源的 Clash 系防 DNS 与 WebRTC 泄露配置

[rowenorbert]

平时使用各类客户端时，发现很多机场默认订阅或通用配置都存在两个容易被忽视的隐私问题：

1. DNS 泄露：域名解析未能做到严格隔离，导致本地真实 ISP 的 DNS 出口直接暴露在检测网站上。
2. WebRTC 泄露：浏览器或即时通讯工具通过 STUN 协议向外探测，轻松穿透代理拿到国内真实公网 IP 。

为此，我整理并长期维护了一套针对 Mihomo / Clash Meta 官方内核的开源配置规则，主要做了以下优化与解决：

核心改进

• 彻底解决 DNS 泄露：采用 Fake-IP 模式 + 国内外安全 DoH 分流（阿里 / 腾讯 DoH 负责大陆域名，Cloudflare / Google DoH 负责国外解析），兼顾国内访问速度与海外绝对隐私。
• 彻底解决 WebRTC 泄露：针对 STUN 探测端口与域名关键词采用 REJECT-DROP 静默丢弃策略，彻底截断浏览器探测通道。
• iOS 客户端专项优化：针对 iOS 网络扩展（ Network Extension ）极其严苛的 15MB 内存限制，专门制作了轻量化版本，改用内置 GeoSite / GeoIP ，将常驻内存压到 2MB 以内，彻底告别“连不上：内存不够”的报错。
• 默认安全加固：静态 YAML 配置默认关闭局域网共享（allow-lan: false）并预设了强访问密钥（secret），防御恶意网页跨站探测 9090 端口窃取节点凭据。
• 开箱即用体验：整理了 16 个常用分流策略组（ AI 、流媒体、Telegram 、YouTube 等），节点自动启用 UDP ，并预置了精选全彩图标。

---

项目地址与订阅链接已全部开源在 GitHub： 👉 https://github.com/Niklaus88/Clash-Config

欢迎大家体验与交流，也可以在 IPPure 或 BrowserLeaks 上实测效果。

[alsa]

马克一下

[xiaoxiannv]

理论上国内 DIRECT 、国外 PROXY ，想做到 WebRTC 绝不暴露真实出口，单靠分流规则很难做到百分之百可靠吧

[565656]

问一下博主，singbox 有没有 clash 的 provider 一样的，现在写死节点不行啊

[rowenorbert]

@xiaoxiannv 感谢指出这个关键痛点！你说的非常对，如果仅仅是靠“域名分流”（把常见国外的 STUN 域名分流到 PROXY ），遇到国内直连的 STUN 服务器或者未知 IP ，是必然会穿透泄露的。

我在规则设计上并不是靠域名分流来防，而是采用了更前置的传输层端口级拦截 + 静默丢弃策略：

1. 无差别端口全量拦截：在最顶部直接对 WebRTC STUN 协议的标准端口和常见非标端口（ 3478 、5349 、19302-19309 ）实施了拦截。无论 STUN 服务器位于国内还是国外、目标是 IP 还是域名，只要命中这些端口，全部直接阻断。
2. 使用 REJECT-DROP 静默丢弃：不使用普通的 REJECT （避免返回 ICMP Unreachable 导致浏览器立即切换其他 fallback 途径），而是让 UDP 探测包直接黑洞超时，从而使浏览器的 ICE 候选地址收集流程直接挂起并失效。
3. 关键词兜底：配合 `DOMAIN-KEYWORD,stun,REJECT-DROP` 拦截绝大部分常规 STUN 解析请求。

当然，网络层规则确实存在一个理论极限：如果恶意站点极其罕见地把私有 STUN 服务直接架设在 80 / 443 端口上，且 IP 刚好属于国内直连范围，网络层就无法简单按端口无差别阻断（否则会误杀正常网页浏览）。

所以我在 README 里也特别写了提示：网络层规则解决的是 99% 的常见探测；如果对隐私有极端严苛要求的场景，在浏览器端搭配扩展（如 WebRTC Control ）彻底关闭接口，或者在 Firefox 中直接关闭 `media.peerconnection.enabled`，结合起来才是最绝对的双保险。

[DearFox]

singbox 不是不用 fake ip 么,咋也是同样的写法?

[rowenorbert]

@565656 Sing-box 官方内核在设计哲学上一直坚持保持底层纯粹，所以官方一直没有内置类似 Clash 的 `proxy-providers`（远程节点定时拉取与解析）功能。

对于不想“把节点写死在本地配置”的需求，目前社区和生态有以下成熟的解决路径：

1. Sub-Store 远程托管（最推荐）
用 Sub-Store 的 Artifact 功能：
将这份配置上传到你的 Gist / 私有库作为模板；
在 Sub-Store 关联你的机场订阅和这份模板；
最终 Sub-Store 会生成一个包含最新节点的 Sing-box 完整配置链接。
在 Sing-box 客户端中新建配置时，类型选择 远程（ Remote ），直接填入该链接并设置定时自动更新，就能像 Clash 一样自动同步机场节点了。

2. 使用具备订阅拉取能力的客户端
像 Karing 、Hiddify 或 GUI.for.SingBox 这类客户端，在上层封装了订阅管理与自动合并功能，不需要在底层配置里手写节点。

[xiaoxiannv]

@rowenorbert 鱼和熊掌，不可兼得。端口全拦+REJECT-DROP 更适合专门的反指纹/隐私浏览环境，不太适合我这种日常比如 iPhone+FaceTime 的家庭环境，毕竟 facetime 这类本身就依赖 NAT 穿透的。没别的意思，感觉 op 搞得有点复杂了，感觉用的场景不多。想靠谱只能全局。

[rowenorbert]

@DearFox 老兄提的这个点很有代表性，社区里确实很多人推崇 Sing-box 的“纯 Sniffer （嗅探）+ 真实域名路由”，但实际上这是两个层面的事情：

1. 官方内核原生支持并重构了 Fake-IP：
Sing-box 官方一直支持 Fake-IP ，在 1.12+ / 1.14+ 版本中更是把它重构成了内联的 DNS Server （`type: "fakeip"`），文档也有专门说明，并非“不用 Fake-IP”。（ 附 Sing-box 官方 Fake-IP 文档： https://sing-box.sagernet.org/zh/configuration/dns/server/fakeip/ ）

2. 为什么坚持在 Sing-box 里开 Fake-IP ？
纯嗅探（ Sniffer ）虽然好，但在防泄露和延迟上有两个局限：
本地提前解析风险：某些应用在发起 TCP/UDP 连接前，会强制调用系统底层的 `getaddrinfo` 先向系统 DNS 要一个 IP 。如果不用 Fake-IP ，这个先行的解析请求就极易穿透到本地真实 ISP 导致 DNS 泄露。而 Fake-IP 能瞬间返回 `198.18.x.x` 的虚拟地址，在最源头掐断本地外部解析。
连接延迟（ 0 RTT 解析）：有了 Fake-IP ，浏览器不用等待远程 DNS 往返解析，可以直接把包丢给 TUN ，由远端代理节点去并发解析并握手，体验上明显比单纯等待远端 DoH 更丝滑。

3. 双重保险：
在配置中采用的是 Fake-IP （兜底本地系统解析与加速）+ Sniffer （嗅探真实 TLS SNI / HTTP Host 纠偏） 的模式。既兼顾了 Fake-IP 的瞬时响应与防漏能力，又保留了 Sing-box 强大的流量特征嗅探与分流精度。

[xiaoxiannv]

@rowenorbert 日常家庭网络我还是倾向不过度处理，真要求绝对不泄露的话，全局代理或浏览器侧限制 WebRTC 会更可靠。

[rowenorbert]

@xiaoxiannv #7
是的，如果日常需求只是看看流媒体、玩玩游戏、日常家庭打打视频，确实默认的直连+分流最省心，没必要对 WebRTC 严防死守；（我也测试过 Apple 生态，日常跨设备或家庭通话是正常的）
这套配置的核心目标受众，是深度使用 Claude / ChatGPT 等高风控 AI 平台、或者对账号防封和反指纹有强迫症的用户。因为这类场景下，WebRTC 一旦穿透暴露出国内真实宽带 IP ，很容易直接触发平台的安全风控。
开源出来也是为了给有这类防泄漏刚需的朋友多一个开箱即用的选项，大家根据自己的实际场景各取所需就好。

[vultr]

默认代理，直连用白名单最安全。

[zachary99]

这么复杂。flclash 脚本覆写以后，我想指定某个地址走某个节点，能修改吗

[rowenorbert]

@vultr 懂行！这正是最稳妥的防漏思路。这套配置在分流逻辑的底层实际上就是这么设计的：
除了明确命中规则的直连域名以及 CN/LAN IP 白名单走直连之外，规则的最末尾通过 MATCH 兜底全部交给了 [漏网之鱼] 策略组，而 [漏网之鱼] 默认绑定的就是 [节点选择] （代理）。所以任何未知的境外流量和生僻域名，绝对不会意外滑落到直连，本质上就是白名单直连模式。

[rowenorbert]

@zachary99 完全可以，操作很简单。
脚本自带 16 个常用策略组，如果策略组中没有你需要的策略，例如 WhatsApp 。有两种方式操作：
比如，节点选的 HK ，想让 WhatsApp 走 JP ，策略中又没有 WhatsApp 的策略。
以 FLClash 为例 (二选一)

一、在 FlClash 界面点选（推荐）
1. 在 FlClash 里打开 [配置] ➔ [覆写] ➔ [自定义] ➔ [规则] 。
2. 点击添加一条规则：
类型：DOMAIN-KEYWORD （或 DOMAIN-SUFFIX ）
内容：whatsapp （或 whatsapp.com ）
目标：直接下拉选择你的那个日本节点名称（比如 JP 01 ）。
3. 保存即可。FlClash 的“个人规则”优先级高于脚本的所有规则，只要命中就会直接穿透走到你的日本节点上。

二、直接在脚本里编辑
[配置] ➔ [覆写] ➔ [前往配置脚本] 选中脚本进入编辑模式
在 rules 数组最上方加一行：
DOMAIN-KEYWORD,whatsapp,JP 01
客户端就会始终按照你的这行规则走特定节点。

[rowenorbert]

@zachary99 抱歉补充勘误一下上面那楼：刚刚去翻看了一下 FlClash 的底层源码，发现 [脚本模式] 和界面的 [自定义规则] 在底层是互斥的三选一关系。当开启覆写脚本时，界面上的自定义规则是不会并入生效的。

如果你想让 WhatsApp 单独走日本节点，且保留脚本防泄露与全彩策略组，操作方法是：

1. 在 FlClash 里点击 [配置] ➔ [覆写] ➔ 页面最下方 [前往配置脚本] 。
2. 点进你正在使用的脚本，找到里面的 const rules = [ 这一行。]
3. 在中括号的第一行加上你的规则：
"DOMAIN-KEYWORD,whatsapp,JP 01",
4. 保存即可。

把规则放在最顶上优先级最高，WhatsApp 就会直接走指定的日本节点，同时完全不影响脚本的其他防泄露功能。再次为上面的粗心回复致歉！

[BanShe]

op 的回复 AI 味浓厚

[rowenorbert]

@BanShe 对的，人工加 AI

[youdoit]

哎，doh 这个你都搞错了，还整泄露，Google 都不支持 ip ，而且你最后那么几个，必定会导致很多 cn 走出去，不行你看看。

[rowenorbert]

@youdoit 使用 https://dns.google/dns-query 和 https://8.8.8.8/dns-query 都是可以的。
复查了你说的最后几个规则顺序，的确有逻辑缺陷，现已校正。感谢指出问题哈！🤝

[youdoit]

@rowenorbert #19 除了 cf ，如果没有记错，是不允许，因为证书问题，你去官方看文档。

[youdoit]

不知道你这文档哪里看的，有不少地方都是有错

[rowenorbert]

@youdoit #20 官网文档确实都写的域名，所以大家可能默认以为它不支持 IP 。其实你也可以测试一下，并不会发生证书报错。

[rowenorbert]

@youdoit #21 如果有任何错误的地方也欢迎指正，这个配置就是靠大家多找找问题、多实测希望尽可能打磨得更完美。

[cccmm]

openwrt 的 openclash 该如何使用呢

[safilar]

@youdoit #21 他这个恢复一个就是 AI