@johnbobby 其实不太建议使用第三方进行订阅转换，目前还是比较推荐使用 js 覆写脚本导入

@cccmm 仓库中已经增加了适合 openclash 使用的配置，可以查看下载使用。若使用，请务必看下配置里面的说明

简单说明一下这个项目和这个帖子：
一、主要为了给使用 clash 系的朋友提供一个省心的配置选择
1 、对于不想自己折腾配置文件，但希望可以防止 DNS 和 WebRTC 泄露
2 、此配置是通过 codex 完成的，我几乎没有动手，只进行审核和测试。这样的简单配置，并没有杂的代码和逻辑，我认为让 AI 干很合适，效率高出错少。
3 、使用 Claude 对配置进行了“找茬”，目的就是尽可能多的找出需要调整修改的地方，争取使配置打磨的更加实用。
4 、关于文档参考已经对 AI 做了限制，必须以官方文档为依据，保持配置代码精简整洁的同时还要安全无忧的使用此配置，不能产生任何冲突、错误，必须同步官方最新文档。
二、对于使用 AI 回复讨论的答复
1 、对于涉及专业性和技术性的问题，使用 AI 回答。主要原因是 AI 在回答此类问题时用词更精确，逻辑清晰明了，比较适合做为一种科普，方便有兴趣了解此问题的朋友查阅。但凡使用过 AI 应该都可以看得出来，以上几条长回复是用的 AI ，我剔除了无关紧要和冗余的部分，只使用有关问题本身的回答。
2 、发这个帖子，也是希望对这方面感兴趣的朋友可以对配置查看、测试、查漏补缺，目的还是希望发现我没有碰到或 Claude/GPT 没有检查出来的问题，再让 codex 调整，使配置更完善，方便有需求的朋友直接使用，免去自己折腾的麻烦。
3 、因为是开源项目，大家也可以将配置发给自己常用的 AI 模型做分析检查，可以从安全性、隐私性、合理性、是否推荐使用等进行全方面的提问。
三、折腾此配置的原因
我本身对这一块比较感兴趣，虽然主力用 APPLE 生态，但最早之前在使用 Android 时就一直想处理 dns-webrtc 这个问题，但一直没有找到适合自己需求的现用配置，所以现在有条件便想着借助 AI 做一份这样的配置，基于 AI 的快速发展带来的便利，完成度还算比较满意。

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

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

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

@BanShe 对的，人工加 AI

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

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

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

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

@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
客户端就会始终按照你的这行规则走特定节点。

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

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

@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 强大的流量特征嗅探与分流精度。

@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 这类客户端，在上层封装了订阅管理与自动合并功能，不需要在底层配置里手写节点。