rowenorbert

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

@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`，结合起来才是最绝对的双保险。