@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 里点击 [配置] ➔ [覆写] ➔ 页面最下方 [前往配置脚本

@zachary99 完全可以，操作很简单。 脚本自带 16 个常用策略组，如果策略组中没有你需要的策略，例如 WhatsApp 。有两种方式操作： 比如，节点选的 HK ，想让 WhatsApp 走 JP ，策略中又没有 WhatsApp 的策略。 以 FLClash 为例 (二选一) 一、在 FlClash 界面点选（推荐） 1. 在 FlClash 里打开 [配置] ➔ [覆写] ➔ [自定

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

@xiaoxiannv #7 是的，如果日常需求只是看看流媒体、玩玩游戏、日常家庭打打视频，确实默认的直连+分流最省心，没必要对 WebRTC 严防死守；（我也测试过 Apple 生态，日常跨设备或家庭通话是正常的） 这套配置的核心目标受众，是深度使用 Claude / ChatGPT 等高风控 AI 平台、或者对账号防封和反指纹有强迫症的用户。因为这类场景下，WebRTC 一旦穿透暴露出国内真实

@DearFox 老兄提的这个点很有代表性，社区里确实很多人推崇 Sing-box 的“纯 Sniffer （嗅探）+ 真实域名路由”，但实际上这是两个层面的事情： 1. 官方内核原生支持并重构了 Fake-IP： Sing-box 官方一直支持 Fake-IP ，在 1.12+ / 1.14+ 版本中更是把它重构成了内联的 DNS Server （`type: "fakeip"`），文档也有专门

@565656 Sing-box 官方内核在设计哲学上一直坚持保持底层纯粹，所以官方一直没有内置类似 Clash 的 `proxy-providers`（远程节点定时拉取与解析）功能。 对于不想“把节点写死在本地配置”的需求，目前社区和生态有以下成熟的解决路径： 1. Sub-Store 远程托管（最推荐） 用 Sub-Store 的 Artifact 功能： 将这份配置上传到你的 Gist /

@xiaoxiannv 感谢指出这个关键痛点！你说的非常对，如果仅仅是靠“域名分流”（把常见国外的 STUN 域名分流到 PROXY ），遇到国内直连的 STUN 服务器或者未知 IP ，是必然会穿透泄露的。 我在规则设计上并不是靠域名分流来防，而是采用了更前置的传输层端口级拦截 + 静默丢弃策略： 1. 无差别端口全量拦截：在最顶部直接对 WebRTC STUN 协议的标准端口和常见非标端口（