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

19 小时 55 分钟前
 rowenorbert

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

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

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

核心改进


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

欢迎大家体验与交流,也可以在 IPPureBrowserLeaks 上实测效果。

1514 次点击
所在节点    DNS
17 条回复
alsa
19 小时 44 分钟前
马克一下
xiaoxiannv
19 小时 34 分钟前
理论上国内 DIRECT 、国外 PROXY ,想做到 WebRTC 绝不暴露真实出口,单靠分流规则很难做到百分之百可靠吧
565656
19 小时 31 分钟前
问一下博主,singbox 有没有 clash 的 provider 一样的,现在写死节点不行啊
rowenorbert
19 小时 15 分钟前
@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
19 小时 10 分钟前
singbox 不是不用 fake ip 么,咋也是同样的写法?
rowenorbert
19 小时 9 分钟前
@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
19 小时 1 分钟前
@rowenorbert 鱼和熊掌,不可兼得。端口全拦+REJECT-DROP 更适合专门的反指纹/隐私浏览环境,不太适合我这种日常比如 iPhone+FaceTime 的家庭环境,毕竟 facetime 这类本身就依赖 NAT 穿透的。没别的意思,感觉 op 搞得有点复杂了,感觉用的场景不多。想靠谱只能全局。
rowenorbert
19 小时 0 分钟前
@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
18 小时 57 分钟前
@rowenorbert 日常家庭网络我还是倾向不过度处理,真要求绝对不泄露的话,全局代理或浏览器侧限制 WebRTC 会更可靠。
rowenorbert
18 小时 47 分钟前
@xiaoxiannv #7
是的,如果日常需求只是看看流媒体、玩玩游戏、日常家庭打打视频,确实默认的直连+分流最省心,没必要对 WebRTC 严防死守;(我也测试过 Apple 生态,日常跨设备或家庭通话是正常的)
这套配置的核心目标受众,是深度使用 Claude / ChatGPT 等高风控 AI 平台、或者对账号防封和反指纹有强迫症的用户。因为这类场景下,WebRTC 一旦穿透暴露出国内真实宽带 IP ,很容易直接触发平台的安全风控。
开源出来也是为了给有这类防泄漏刚需的朋友多一个开箱即用的选项,大家根据自己的实际场景各取所需就好。
vultr
18 小时 9 分钟前
默认代理,直连用白名单最安全。
zachary99
17 小时 14 分钟前
这么复杂。flclash 脚本覆写以后,我想指定某个地址走某个节点,能修改吗
rowenorbert
15 小时 4 分钟前
@vultr 懂行!这正是最稳妥的防漏思路。这套配置在分流逻辑的底层实际上就是这么设计的:
除了明确命中规则的直连域名以及 CN/LAN IP 白名单走直连之外,规则的最末尾通过 MATCH 兜底全部交给了 [漏网之鱼] 策略组,而 [漏网之鱼] 默认绑定的就是 [节点选择] (代理)。所以任何未知的境外流量和生僻域名,绝对不会意外滑落到直连,本质上就是白名单直连模式。
rowenorbert
14 小时 41 分钟前
@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
14 小时 0 分钟前
@zachary99 抱歉补充勘误一下上面那楼:刚刚去翻看了一下 FlClash 的底层源码,发现 [脚本模式] 和界面的 [自定义规则] 在底层是互斥的三选一关系。当开启覆写脚本时,界面上的自定义规则是不会并入生效的。

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

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

把规则放在最顶上优先级最高,WhatsApp 就会直接走指定的日本节点,同时完全不影响脚本的其他防泄露功能。再次为上面的粗心回复致歉!
BanShe
3 小时 33 分钟前
op 的回复 AI 味浓厚
rowenorbert
3 小时 17 分钟前
@BanShe 对的,人工加 AI

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1241564

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX