插件配置¶
不开启仅核心
procd 配置¶
参考：procd-配置
配置文件¶
点击 添加 来添加你的节点订阅
订阅后端 docker-compose 如下：
原后端 subconverter不支持如下新协议：
mihomo 内核目前支持部分原 Clash 内核暂未支持的协议。包括：
[!TIP] 这里更推荐使用作者的订阅转换后端： 公共后端地址：
https://api.asailor.org
订阅前端 docker-compose :
ip:58080 进入前端：
按上图这么设置，填入你机场订阅链接，注意，订阅链接只能包含节点格式数据，不能用机场成品的模板,通常复制不带任何软件前缀的订阅链接即可，自建节点可以忽略，下面自定义添加我们使用的模板：
这里使用标准模版，按需更改。
加速链接：
Custom_Clash.ini
Custom_Clash_GFW.ini
Custom_Clash_Lite.ini
Custom_Clash_Full.ini
[!TIP] 这里也更推荐使用作者的订阅转换前端： 公共订阅转换前端地址：
https://sub.asailor.org/
然后点击 生成订阅链接，去nikki那里订阅链接粘贴保存并订阅
(可选) 搭建的订阅后端有时候可能还未支持最新的字段，可以先用订阅转换拉取下来后，在订阅里面将优先改为 本地 ：
然后来到系统的
选择对应的yaml配置文件，保存到本地进行编辑，只需要编辑 proxies 字段即可。转换后的格式看着不太好编辑的话，可以来到下面这个网址：
https://it-tools.tech/yaml-prettify
复制 proxies 字段到里面格式化一下YAML进行编辑，不放心的话可以compose拉取这个网址自建使用。
例如：
hy2节点使用订阅后端目前还不能识别到端口跳跃，需要手动添加 ports: 7443,20000-50000，这样的字段，以及支持上下行速率的up: "30 Mbps", down: "500 Mbps"，添加后可以使用比BBR更激进的、类似Brutal的拥塞控制方式.
vless节点使用加密字段需要自行添加 encryption: "mlkem768x25519plus.native/xorpub/random.1rtt/0rtt.(padding len).(padding gap).(X25519 Password).(ML-KEM-768 Client)..." ，以及传输安全不套TLS的话需要修改TLS字段为false。
套用TLS的节点建议配合fingerprint使用，skip-cert-verify设置为 false ，防止 MITM 攻击.
具体的参考下面来修改：
https://wiki.metacubex.one/config/proxies/
Alpha内核：
https://github.com/MetaCubeX/mihomo/blob/Alpha/docs/config.yaml#L362
Meta内核：
https://github.com/MetaCubeX/mihomo/blob/Meta/docs/config.yaml#L350
混入配置¶
混入配置对应的是openclash的覆写设置，按下面这么设置
全局配置¶
外部控制设置¶
入站配置¶
TUN 配置¶
参考：
默认开启但未使用的 TUN 模式是否可能影响稳定性？ #713
某些订阅文件如果没有声明启用 TUN，会导致启动失败，因此默认全局启用以避免兼容性问题。
DNS 配置¶
fake-ip-filter填入geosite内容如下:
参考:
引入域名集合fake-ip-filter
#rule-set:个人使用直连域名 (这个是自己添加的，详细参考https://wiki.metacubex.one/config/dns/#fake-ip-filter,以及https://wiki.metacubex.one/config/rule-providers/content/,推荐加入自己的DDNS域名，跑BT/PT加入tracker域名.
2025.11.10更新：支持fake-ip6，见下
可以填入fdfe:dcba:9876::1/64，效果如下：
在被代理的客户端查询未被fake-ip-filter过滤的域名时，会返回双栈的fake-ip，个人感觉的好处是让ipv6代理效果更好，以及解决一些兼容性问题，比如：
有些系统或 App ：在解析域名时 优先请求 AAAA（IPv6）记录；如果系统或 DNS 只返回 IPv4 Fake-IP（比如 198.18.x.x），那些程序可能会直接忽略解析结果或报错。
有了 Fake-IP6： 代理能在 AAAA 查询时返回假 IPv6 地址（如 fc00::1234），App 认为拿到了 IPv6 地址，照常访问，代理再拦截该 IPv6 假地址并转发到真实目标。📈 兼容性更高，避免 IPv6 优先的程序“卡壳”。
DNS 服务器 设置：
DNS这么设置，用运营商下发的，同时在系统 DHCP/DNS 设置里面这么设置：
DNS 服务器查询策略 (Nameserver-policy) 设置：
Nameserver-policy 作 DNS查询 的分流，设置为 直连 走 DIRECT 的规则会去使用配置好的 direct-nameserver 里面的国内DOH服务器、运营商DNS服务器去解析，如果fake-ip-filter里面也有配置直连的规则，需要开启，添加需要走国外DOH解析的域名规则和去广告规则以及fake-ip-filter里面配置直连的规则，推荐最小化的规则，见下图：
Nameserver-policy 顺序推荐（自上而下）：广告隐私拦截 --> 需要代理的最小规则 --> fake-ip-filter 里面配置的规则
当一个域名在 fake-ip-filter 中时（黑名单模式，这是默认模式）：
1. 跳过 FakeIP 处理
- 域名匹配 fake-ip-filter 后，会跳过 FakeIP 机制
- 进入真实 DNS 解析流程
2. Nameserver 选择优先级（从高到低）：
优先级 1: nameserver-policy
- 如果域名匹配 nameserver-policy 中的规则，使用对应的 nameserver
- 例如：
"geosite:cn": ["223.5.5.5"]优先级 2: fallback-filter.domain
- 如果域名匹配 fallback-filter.domain，仅使用 fallback nameserver
- 完全跳过主 nameserver
优先级 3: nameserver（主要 DNS）
- 如果以上都不匹配，使用 nameserver 配置的 DNS 服务器
- 这是 fake-ip-filter 域名的默认解析路径
优先级 4: fallback（回退 DNS）
- 仅在主 nameserver 返回的 IP 匹配 fallback-filter 条件时使用
- 条件包括：GeoIP 匹配、IP-CIDR 匹配等
由于我们不会去配置 fallback nameserver 和 fallback-filter（配置这些会导致额外的 DNS 查询，还需要轮询 geoip/geosite 数据库，浪费时间），直连就走 direct-nameserver ，nameserver 配置通过代理走国外DOH服务器，因此需要特别设置 nameserver-policy ，让 fake-ip-filter 里面的域名走运营商DNS、国内DOH查询，避免通过 nameserver 查得到较慢的结果，大多数情况下可以这么认为，fake-ip-filter 里面的规则通常是需要直连且客户端查询需要得到真实IP的域名。
例如：fake-ip-filter 加入 Tracker 服务器，BT/PT下载客户端（这里假设进入核心，即被Nikki代理和DNS劫持）做种需要定期向Tracker服务器汇报信息，Tracker服务器通常也是需要直连，由于fakeip映射，客户端查tracker服务器始终得到的都是一个假的IP（198.18.0.1/16），只有核心知道具体的连接信息，相当于在双端之间又NAT了一遍，自然就连接不上Tracker服务器了，导致无法汇报做种信息。
在 fake-ip-filter 里面加入的域名规则需要配合相应的 nameserver-policy 一起使用。
推荐在编辑器-用于混入的文件里面配置，参考如下：
最终的 DNS 查询路径见下图所示：
总结一下思路就是：
域名 和 目标IP 按照追加规则和模板的顺序自上而下遍历路由，域名/目标IP → 自上而下匹配路由 → 匹配到对应规则即停
1.域名 [Geosite,规则集(rule-set)里面的DOMAIN]
匹配到geosite、ruleset里面走直连（Direct）的域名一定会走 direct-nameserver（即使用国内DOH,运营商DNS）去查询，匹配到geosite、ruleset里面走代理的域名会把要解析的域名发送到远端节点，交给节点去进行DNS解析，走到最后是 MATCH FINAL，模板默认设定的是走代理，同上大部分还是会走代理节点来解析.
2.目标IP [GeoIP,规则集(rule-set)里面的 IP-CIDR ]
假设路由规则如下：
匹配到目标IP解析域名的前提是：
域名(Domain)遍历到在路由规则里面设定好的IP的时候要不要决定进行对该域名进行DNS解析。(对应ip的no-resolve字段)
例如：
有遗漏的CN域名按照路由规则自上而下路由匹配不到任何geosite，rule-set(DOMAIN)，nameserver-policy的规则，路由到GEOIP,cn,no-resolve时不会触发内核对这个域名的DNS解析，按照模版设置而是直接路由到最后MATCH交给代理去解析，这时候可以去上游规则仓库PR提交这些域名让它们被收录到geosite:cn中.
而已知CN域名路由到GEOSITE,CN,DIRECT后先使用 fake-ip-filter并配置 nameserver-policy (内容同direct-nameserver) 去进行dns 解析，即在更早更上面的匹配中触发了 dns 解析，则依旧会匹配到添加了 no-resolve 选项的 目标IP 类规则，得到的结果仍然会匹配到GEOIP,cn,no-resolve，即还是走直连direct.
然后是内核直接进入ip,但是我感觉基本上是用不到的，因为后面插件外面设置了绕过了大陆的V4和V6的IP网段，就不会进入核心来路由了，可能会有遗漏的大陆网段，但模板写的基本很完善，模板最后还有GEOIP,cn,no-resolve直连路由兜底，特殊服务的geoip在模板里面有对应的代理规则,其他地理地区的geoip也是匹配到MATCH走代理（可以自定义走代理还是直连），大多数情况下，客户端发起连接的情况是域名，不会直接去访问ip,而域名已经有 direct-nameserver 和 代理节点 来处理了。
简而言之，国内的域名就走本地DNS(运营商DNS,云服务厂商DOH）查询，国外的域名就交给代理节点查询，特定在国内国外都有的，但需要强制走国外的就设置 nameserver-policy 通过走代理的国外DOH查询，这是最简单高效的方式，在 fake-ip-filter 里面过滤的规则（大多数情况下是直连且需要查询得到真实IP），通过指定 nameserver-policy 直接查询，避免再去 nameserver 查询得到较慢的结果。
混入文件内容 设置¶
如果设置 luci界面 麻烦也可以保持默认：
然后开启 混入文件内容 ：
编辑器选择 用于混入的文件 ：
参考如下dns配置：
嗅探器配置¶
这里嗅探luci可以也不设置，使用编辑器混入，同上DNS的设置一样，加入下面这段：
规则配置¶
追加规则设置：
对应规则集合
规则地址仓库如下：https://github.com/levi882/OpenClash_SmartDNS_BTPT_Rules/tree/main/rule_converted_mrs
对应链接内容如下：
1.（按需）去广告：
[!TIP] 这里更加推荐使用作者的去广告规则： 对上游规则(如anti-AD、AWAvenue Ads Rule等)进行了合并、去重、去除无效域名，不做任何修改，更加精确. - 全量规则加速链接 - Lite 规则加速链接
2.配合模板使用：
3.OpenClash默认的fakeip过滤域名,内容同ShellCrash，主要用于fake-ip-filter搭配相应Nameserver-policy(这里指定system，即通过OpenWrt的Dnsmasq去查询使用),不会用来路由(即在 追加规则[rules] 里面指定 代理 还是 直连)：
注意文件格式，有的是yaml，有的是mrs.
(可选）去广告按下面设置：
同时在 DNS 服务器查询策略（nameserver-policy） 里面添加下面内容：
使用作者的：
添加在 nameserver-policy 所有最上面。
参考下图，在 追加规则 添加路由上面的规则：
对应：路由规则
需要注意，追加规则里面的规则，会按照从上往下的顺序遍历，优先命中上位规则，规则重复无影响 ，修改顺序会影响分流效果，建议保持和图里面类似的顺序，即按照 广告隐私拦截-->需要代理的最小规则-->直连最小规则 的优先级顺序来。同时追加规则里面的规则会追加到最上游，即模板的上游，需要谨慎添加，geosite 建议仅添加最小的域名规则,同时尽量避免ip类的规则，ip类的规则都是放在最后面，建议还是用域名类的规则。
上面的 规则提供者 无需按顺序来，但还是建议和 追加规则 保持同序。同时 规则提供者 里面添加的规则不一定需要在下面 追加规则 里面使用（即 rule-providers 不一定需要放入 rules 里面去路由） 有时候仅需要 fake-ip-filter 不返回 fake-ip、DNS查询策略(Nameserver-policy)需要分流，就填入到 编辑 Fake-IP 过滤列表 和 编辑 DNS 服务器查询策略 里面，或者在编辑器-用于混入的文件里面自己填写到对应的模块中。
对应到 Zashboard面板 里面，规则提供者 是 规则提供商 ，追加规则 是 规则，而且 追加规则 会追加到 模板 定义的规则的上游，按照顺序遍历，规则提供商(规则提供者)的规则可以不在规则(追加规则)里面使用，就像商贩提供的货物，包含了所有，但可以有选择性的不选，仅挑选需要的货物一样。
如需要禁用 Youtube 的 QUIC流量 ，参考如下这么设置，路由顺序同上述一样：
对应Openclash的*禁用 QUIC设置：
GeoX配置¶
GeoX设置，务必开启DAT版,内存不够选 为内存受限设备优化的加载器
在 编辑器 里面对应的混入设置：
(可选)GeoX和追加规则的一些玩法¶
模板使用的分流也是基于 geosite 和 geoip 的，这里甚至可以只使用 lite 模版作为最小化的锚点，不需要那么多的分流规则，等有需要(例如流媒体nf,appletv+,hbo)再去查找添加对应的 geosite 和 geoip 到追加规则里面并设置走对应地区的节点，加载规则也是只加载需要分流的那一部分，查询效率约等于使用 mrs格式 转换后（domain/ipcidr）的 rule-set(规则集），而且使用 geosite 和 geoip 是最便捷的方式，因为规则是每天定时更新的，且定期有维护者维护，省去自己写rule-set(规则集）再去转换为 mrs格式 定期去维护的时间与精力。
我们可以不只局限于模板里面的一些写好的geosite,可以自己使用 geosite.dat 里面其他的定义好了的 geosite 规则，由于我们使用的是 Loyalsoldier/v2ray-rules-dat ，其兼容V2ray的geosite格式，因此转到下面的网址来查询需要的geosite：
https://github.com/v2fly/domain-list-community/tree/master/data
例如输入category-ads，出现的是广告域名的合集，我们选择category-ads-all，回到nikki的 规则配置-追加规则-编辑规则
选择 域名(Geo)
填入category-ads-all，选择 REJECT (或者 REJECT-DROP ,即静默丢弃，防止客户端一直发出查询请求），保存并应用。
同时在 nameserver-policy 上方追加：
这样我们就配置好了一个 geosite 的广告拦截的规则，和上面的规则集(rule-set)的广告拦截作用类似，建议选择一个就行，个人建议使用作者的广告拦截即可。
这里仅抛砖引玉，其他的玩法，比如像是一些金融、学术的域名需要某些特定的节点来分流，还有一些模板里面未涉及到的分流规则，还是在里面输入category目录，或者特定的网站来查找。这里还是推荐使用最小的具体的规则.
比如一些金融网址需要走日本节点来解锁，就这么设置，回到模板里面定义的分组复制：
只复制 custom_proxy_group= 后面的具体部分，例如🚀 手动选择、♻️ 自动选择、🇭🇰 香港节点，这些
然后回到nikki填入节点里面保存应用就行了。
打开面板显示刚刚添加的 geosite 分流规则显示成功加载，代表分流成功：
这里再举一个案例，即不仅需要走代理，同时DNS分流也需要走国外DOH，这里拿Nikke国际服举例，
首先还是查询：
我们可以来到下面这个网址来查询 nikke 具体属于哪个分组：
可以看到，nikke 在多个分组里面，依次为category-entertainment、category-games、category-games-!cn、china-list、cn，
注意到如果我们还是用上面的DNS查询分流规则的话，如果不单独配置一个走国外DOH的规则，就会走 geosite:cn ，而我们上面配置的 geosite:cn 都是用国内DOH、运营商DNS服务器来解析的，会导致如下的问题：
nikke的网址被解析到了本地，itdog解析也被丢到本地，无论是运营商的还是阿里的，都会被解析到 127.0.0.1 这个本机地址，造成无法连接，因此需要设置 DNS分流 ：
顺序参考这么设置：
这样就可以解析到了和海外的一致。
还需要在 混入配置-规则配置-追加规则 里面设置走代理：
然后检验成功，效果如下：
下载走的是节点流量（443常用端口），需要注意。
进入游戏可以选择区服，不再卡29.
其他游戏的分流也是同理，这里有一个仓库可以参考：
https://github.com/FQrabbit/SSTap-Rule
如果要使用这类规则，通常需要先将它们下载并转换为 mrs 格式，或者写一个 workflow 定期获取、转换后再追加到自定义规则中。不过需要注意的是，列表中大部分是 IP-CIDR，如果包含域名，还必须额外加入到 fake-ip-filter，并相应配置 Nameserver-policy。
更加详细的分流请参考：
https://www.aloxaf.com/2025/04/how_to_use_geosite/
最终用于混入的配置(未包含追加规则以及模板部分)¶
整个混入设置的最终设置，不使用luci设置的话可以参考，同时不包含上面 (可选)GeoX和追加规则的一些玩法 里面的设置。
对应 编辑器-用于启动的配置文件
参考如下：
https://github.com/MetaCubeX/mihomo/blob/Meta/docs/config.yaml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 | |
代理配置¶
参考：插件与配置文件的交互
如果遇到访问网页、下载断流，请把 TCP 模式 改为 TPROXY模式 ，IPv4 DNS 劫持 , IPv6 DNS 劫持 都保持开启, 防止DNS污染/分流错误的的情况发生,参考如下：
路由器代理配置¶
个人觉得比openclash更好，不再是全部tun接管进入内核，路由本机有的服务也可以选择性不走代理，同时在这里排除的服务service就可以不用再去写内核路由规则去定义了，不进入 clash(mihomo)内核 ( 对应find-process-mode: off # 即不匹配进程，推荐在路由器上使用此模式）对性能开销更低，对嵌入式有限资源机型更友好。
上面是默认添加不走dns劫持和代理的服务，下面按需添加，除了 ttyd,dropbear命令行使用 wget 等命令例如获取软件源要走代理，还有 nlbwmon，appfilter 这些统计软件，需要监听lan流量，以及 dockerd 拉取镜像需要代理，cron表达式 执行一些需要连通外网的服务需要被劫持DNS和代理，其他的服务可以设置绕过nikki不走DNS劫持和代理。不清楚的服务建议询问chatgpt。
带docker的固件，这里还能添加容器绕过dns劫持和代理，比如 qbittorent,transmission,这里需要是设置为 host网络 的容器才行。
参考如下：
查看固件内核的 cgroup版本:
查看 Docker 守护进程的 cgroup版本:
查看容器内部的 cgroup版本
都出现 cgroup2 代表可以通过插件在内核外部写相应的nftables防火墙规则链来路由对应的服务service，不用去内核rules写对应的路由规则了，性能更好.
不建议在 OpenWrt 上跑大量的docker服务，如果条件允许，推荐把 docker 迁移到 podman （不再需要dockerd守护进程)，或者使用 OpenWrt 主路由下的 NAS 或 专门的服务器运行。
局域网代理配置¶
局域网代理设置，参考这里配置黑/白名单模式：
在这里配置的客户端，就也不用去内核再去配置路由规则了：
需要添加走/不走DNS劫持、代理的容器如上图所示，这里的容器是处于桥接模式的，不是之前的 host模式 的容器。
个人推荐的组网方式如下：就只需要主路由拨号，光猫开启桥接模式仅作为单纯的光电转换器，不应该在光猫上跑服务，wifi什么的交给主路由下面的AP，整个网络应该只有主路由能分配DHCP，应该避免二次NAT。
不推荐使用这样的：不推荐使用旁路由
我仅使用主路由，nikki有更加详细的局域网代理，比Openclash更好，Openclash默认使用 dnsmasq转发 ，需要切换到 防火墙转发 才能进行对局域网的设备访问控制，nikki直接使用防火墙转发，设置不走代理和DNS劫持的设备不会有任何影响，就算nikki挂了（这里指mihomo内核，但大多数情况不会）也不会影响整个网络，个人觉得按照我这么设置的流量过程如下：
“仅主路由 + nikki ”
如下图所示，如果使用旁路由的理由只是拿来代理访问国内国外的网站的话，按照我的“仅主路由+我的设置”这个模式就相当于下图使用网关互指所谓的旁路由。
同“仅主路由 + openclash ”的：
Nikki 相比 OpenClash 最大的不同在于，它不依赖 TUN 模式即可实现完整代理功能。 在 Nikki 中，流量通过 redir-host 与 TProxy 模式透明劫持，无需虚拟网卡转发，从而避免了 TUN 模式带来的全局接管风险。
即使启用了 TUN，Nikki 也不会改写系统默认路由或全局接管网络栈，而是仅在 fake-ip 回流时使用虚拟接口进行内部通信。 相对地，OpenClash 的 TUN 模式会修改系统默认出口，在更底层（网络层）截获所有流量，这使得其强大但也更容易影响整个系统稳定性。参考如下：
在 OpenClash 的 TUN 模式 下，核心通过虚拟网卡（utun）直接接管系统的 网络层与部分传输层流量，几乎所有数据包都会被强制重定向至 Clash 内核。 这种方式确实能够实现完整的流量接管，但由于它修改了系统默认路由，一旦内核异常、路由表错误或虚拟设备失效，整个系统网络可能中断。
相比之下，Nikki 的 redir-host / TProxy 模式 仅针对进入其核心的流量进行透明劫持。 它不会修改默认路由，而是通过策略路由和 nftables 精准控制，从而在 网络层与传输层 实现细粒度流量调度，并能在 应用层 继续区分处理。
例如：
局域网的组播、单播服务（如 IPTV、mDNS）可直接通过插件写ucode和nftables防火墙规则来实现绕过核心； 路由器本机服务（如 Samba、NFS、Web 管理面板等）可配置为直连，ttyd、dropbear需要使用wget的服务可以经由nikki核心来代理； 因此，TUN 模式适合需要完整栈接管和跨平台透明代理的场景； 而 Nikki 的 redir-host / TProxy 模式 更适合路由器主机环境，具有更高的稳定性、安全性与可控性， 尤其在运行 Docker容器，QB下载器等多服务并行时，能够保持系统连通性与性能的平衡，以及能制订更加细致的分流策略。
具体见下图所示：
绕过设置¶
最后绕过这么设置，端口不全部代理了，只代理常用端口，免得下载走代理。有关 DSCP、FWMark, 参考下面内容：
Support dscp-based traffic bypass (such as bittorrent) #295
同理地，这里设置的绕过DSCP内容也不用去内核去定义路由规则：
Zashboard面板设置¶
设置好后回到插件配置能打开 Zashboard面板：
规则能分流：
点击规则下面的按钮可以临时去禁用这条规则，规则旁边的!可以查看此规则命中和未命中次数：
这里可以更新核心，追求快就选Alpha ,追求稳定就选 Release ,依次点击 清空DNS缓存，清空Fake IP，可以清理一下缓存，再点击 更新GEO 防止有的国内地址走代理
节点支持ipv6可以开启 IPV6测试
开启 分离概览页 可以拆分概览为单独页面，并且可以查看实时分流拓扑图：
连接统计 选择 聚合方式 为 按进程 显示结果应该仅有 mihomo 和 - 进程：
启动后打开面板中显示的规则集(rule-set)，GEOSITE,规则提供商参考大致如下：
内存占用参考：
使用Full模板，追加mrs规则，节点协议SS,节点数量100+左右，连接数<50,内存占用大概100M左右。
检验成果¶
最后检验成果，经过nikki代理的设备/服务应该是有ipv6，同时访问不在cn国内的域名，dns出口查询不会发送到国内dns服务器（即dns泄露），不经过代理设备/服务的同理，只是dns测试里面的都会是本地isp的dns和你的isp ip，节点支持ipv6的话可以自行测试。
相关测试结果参考如下：
网址(测试国内v6):
网址(测试dns出口查询):
https://ip.skk.moe/dns-exit-lookup
网址(测试节点国外v6):
国内测试V6：
国外测试V6：
DNS出口查询测试：
「DNS 泄漏」并非真正的安全风险。 它只是递归 DNS（例如 Cloudflare、Google）向权威 DNS 发起请求时暴露的「出口 IP」。这个出口 IP 无法精确对应具体用户，也无法被用于风控。所谓“检测 DNS 泄漏”的网站，本质上只是让你的递归 DNS 去请求一个随机域名，从而看见请求来自哪台 DNS 出口服务器。所以，“DNS 泄漏”更多是营销词汇，对普通用户没有实质风险。
参考：
https://blog.skk.moe/post/lets-talk-about-dns-cdn-fake-ip/
出现故障/服务跑不起来？¶
检查你的日志
1.要么是订阅下载下来文件格式不对
参考 订阅说明 ：
2.要么是规则集设置不对，fakeip-filter那里设置的规则集(rule-set)内容出现了ip-cidr，使用 classic格式 的 规则集 只能包含 DOMAIN，不能混DOMAIN,IP-CIDR,SRC/DST PORT.
参考：
3.同时也确保 DNS 服务器查询策略(Nameserver-policy) 里面也只能有 domain 类型的 规则集，
参考：
规则集内容的样式只能如下：
参考 rule-providers 文件内容 :
不能出现的：
启动成功后应该如下图所示，出现 Hijack successful 代表成功启动：