Windows 11 上折腾 Mihomo Party 和 FlClash：一次 DNS / WebRTC 泄露排查记录

自用备忘｜记录于 2026-11-05
环境：Windows 11；Mihomo Party（也常被称为 Clash Party）；FlClash 0.9.x；Mihomo 内核。
使用项目：Niklaus88 / Clash-Config。
本文根据一次真实排查整理，菜单名称可能随客户端版本变化。截图中的公网 IP 已做遮挡。

先说结论：下次只记住这 5 点

  1. 开启 TUN 不等于 DNS / UDP 就一定不会绕过代理。 尤其 Windows 11，值得检查 strict-route。
  2. 使用 Niklaus88 的分流脚本时，要用「规则（Rule）」模式，而不是「全局（Global）」模式。 全局模式下不能指望脚本中的 WebRTC 拦截分流规则生效。
  3. Mihomo Party： 将 JS 覆写绑定到现有机场订阅，切换到规则模式后，这次的 DNS 检测从国内解析出口变成了 Cloudflare，WebRTC 测试没有再返回真实公网 IP。
  4. FlClash 0.9.x： 脚本策略组出现不代表 DNS 接管一定正常。这次最终配置已经有 Cloudflare DNS，但开启 「严格路由」 后，检测才从中国联通变成 Cloudflare；同时补齐了 UDP / TCP 的 53 端口劫持。
  5. WebRTC 显示「连接错误」不一定是坏事。 如果 WebRTC防护 选的是 REJECT-DROP，STUN 探测被阻断可能正是预期效果；重点是不要再显示真实公网 IP。

注意：DNS 检测显示 Cloudflare、WebRTC 探测连接失败，只能说明这次测试未发现相应泄露，并不等于所有程序、协议和网络环境都获得绝对防护。

一、从哪里开始：加载 Niklaus88 的 JS 规则

项目地址：https://github.com/Niklaus88/Clash-Config
通用脚本：https://raw.githubusercontent.com/Niklaus88/Clash-Config/main/clash-script.js

我原本已经有机场订阅，只想在现有节点上增加分流、DNS 与 WebRTC 防护，因此使用通用 JS 覆写脚本，而不是直接用仓库里的完整 YAML 替换机场配置。

这份 JS 并非只追加一两条规则：它会生成/改写代理组、分流规则及 DNS 等配置。动手前先备份原订阅配置，别把它当成零风险的“小补丁”。

在 Mihomo Party（Clash Party）中

  1. 打开左侧 「覆写」，通过链接或本地文件导入 clash-script.js。
  2. 进入 「订阅管理」，找到现有机场订阅，点右上角 「⋮」→「编辑信息」。
  3. 在 「覆写」 一栏选中刚导入的 JS 脚本，保存，再重新激活该订阅。
  4. 进入 「代理组」，确认出现 WebRTC防护、节点选择、漏网之鱼 等策略组。
  5. 选择真实可用的节点，将运行模式设为 「规则（Rule）」，WebRTC防护 选 REJECT-DROP。
  6. 启用 TUN（虚拟网卡）；不要同时运行另一个可能争夺系统代理或 TUN 的客户端。

这次踩到的坑： 刚开始用「全局模式」排查，虽然网页公网 IP 已经是台湾出口，但 DNS / WebRTC 仍有异常。切回「规则模式」后，DNS 检测变为 Cloudflare，WebRTC 探测显示连接错误。这是我在 Mihomo Party 上最终保留的模式。

二、我看到的“DNS 泄露”和 WebRTC 异常是什么样

一开始 DNS 检测返回中国联通的解析出口，和所选境外代理出口不一致。

最初 DNS 检测显示中国联通解析出口

之后曾出现更明显的对照：浏览器网页出口在台湾，但 WebRTC STUN 测试返回中国联通公网地址；DNS 同时显示中国大陆解析出口。 这证明仅看网页 IP 正常是不够的。

网页出口为台湾的测试截图（公网 IP 已遮挡）

WebRTC 暴露中国联通公网地址、DNS 为国内解析出口的对照截图（WebRTC IP 已遮挡）

随后在规则模式 + WebRTC防护 = REJECT-DROP 的检测中，几个 STUN 服务器返回「连接错误」，没有返回中国联通公网地址。

STUN 测试显示连接错误的示例

这种报错需要结合策略来判断：如果我们主动丢弃 STUN，连接错误可能意味着阻断奏效，不是“测试出错所以一定发生了泄露”；反过来，它也不能保证其他 WebRTC 场景或其他应用绝不泄露。WebRTC 会议/通话可能因拦截而受影响。

三、FlClash 0.9.x：脚本策略组有了，DNS 怎么还是中国联通？

换到 FlClash 后，JS 脚本的策略组已经出现，但 DNS 检测还是中国联通。我最初怀疑 FlClash 没加载好 DNS，想在 「工具 → 进阶配置 → DNS」 中手动添加 Nameserver。

后来发现：这个 DNS 覆写页面是空的，并不代表没有 DNS 配置。 FlClash 0.9.x 采用逐项覆写机制；在这里新增字段，反而可能覆盖 JS 或订阅已有的值。

FlClash 0.9.x 的 DNS 覆写页：还没添加额外覆写项

于是我检查了当前订阅的 「最终配置（Final config）」。主要 DNS 字段已经正确写入：

# 从当时的最终配置摘取，省略无关字段
dns:
  enable: true
  listen: "127.0.0.1:1053"
  enhanced-mode: "fake-ip"
  respect-rules: true
  nameserver:
    - "https://1.1.1.1/dns-query"
    - "https://8.8.8.8/dns-query"
    - "https://8.8.4.4/dns-query"
  proxy-server-nameserver:
    - "https://223.5.5.5/dns-query"
    - "https://doh.pub/dns-query"
  direct-nameserver:
    - "https://223.5.5.5/dns-query"
    - "https://doh.pub/dns-query"
  nameserver-policy:
    geosite:private,cn:
      - "https://223.5.5.5/dns-query"
      - "https://doh.pub/dns-query"

这里的 listen: 127.0.0.1:1053 是 Mihomo 本地 DNS 服务监听端口，不等于 TUN 无法劫持 53 端口。而 nameserver 有 Cloudflare / Google，也不意味着每次 DNS 查询都会用它们：direct-nameserver、proxy-server-nameserver 和 nameserver-policy 还专门指定了国内上游。

因此不能只根据“中国 DNS 出现了”就认定某一个字段错了。接下来要看 TUN 实际接管方式。

四、真正有效的修复：FlClash 打开「严格路由」

当时 FlClash 的最终 TUN 配置大致是：

# 修改前的关键项
tun:
  enable: true
  device: "FlClash"
  stack: "gvisor"
  dns-mode: ""
  dns-hijack:
    - "any:53"
  auto-route: true
  auto-detect-interface: true
  # 当时没有 strict-route: true

我做了两处调整：

① 打开「严格路由（Strict Route）」

FlClash → 工具 → 进阶配置 → TUN（部分界面归在网络配置）→ 添加覆写项 → 严格路由 → 开启。

在 FlClash 中开启严格路由

② DNS 劫持保留两项

点击 「DNS 劫持」，保留 any:53，再增加 tcp://any:53，点击右上角 ✓ 保存。

FlClash DNS 劫持：UDP 53 与 TCP 53 两项

最终需要在「最终配置」中核对这些关键值（只是片段，不要替换整份配置）：

tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-mode: ""
  dns-hijack:
    - any:53
    - tcp://any:53

实测结果：在开启严格路由后，FlClash 的 DNS 检测从中国联通变成了 Cloudflare，WebRTC 的 STUN 测试也显示「连接错误」且未返回真实公网 IP。 我同时补齐了 TCP 53 劫持，所以不把本次结果写成“单独某一项百分之百解决一切”；不过从操作与结果的先后顺序看，严格路由是这次最明显的转折点。

两个容易搞错的点

五、我最终保留的配置速查表

项目Mihomo PartyFlClash 0.9.x
JS 规则绑定 clash-script.js 覆写当前配置已正确应用同一 JS 脚本
模式规则（Rule）规则（Rule）
代理节点选择真实可用节点选择真实可用节点
TUN开开
自动路由 auto-route检查开启true
严格路由 strict-routeWindows 上建议检查true（这次的关键改动）
DNS 劫持检查 UDP/TCP 53any:53、tcp://any:53
WebRTC 防护REJECT-DROPREJECT-DROP
DNS 最终配置由 JS / 客户端合并生成已确认载入 Cloudflare / Google DoH
检测结果DNS 显示 Cloudflare，STUN 阻断DNS 显示 Cloudflare，STUN 阻断

本文没有保存修复后的 DNS 检测截图；“恢复为 Cloudflare”是当时重新检测后记录的结果。上面的国内 DNS 截图均为修复之前的状态，不要误当成最终效果。

六、以后出问题，按这个顺序排查

第 1 步：先确认网页公网 IP。 使用 IPCheck.ing 或 IP.SB，看是否为自己选择的代理出口。检测网页 IP 正常不代表 DNS / WebRTC 也正常。

第 2 步：确认处于规则模式。 特别是脚本里依赖 DST-PORT、DOMAIN-KEYWORD 等规则阻断 STUN 的场景。全局模式不会按普通规则列表进行这类分流。

第 3 步：看策略组有没有。 如果没有 WebRTC防护、漏网之鱼 等组，先检查 JS 覆写是否绑定并成功运行；如果有，再检查最终 dns: 和 tun:，别急着叠加新的覆写。

第 4 步：Windows 上检查 TUN、严格路由和 DNS 劫持。 重点是 auto-route: true、strict-route: true，以及 UDP/TCP 53；如果启用严格路由后局域网、虚拟机或其他 VPN 异常，就撤销这一项并进一步排查路由冲突。

第 5 步：检查浏览器自身的 DNS。 Chrome/Edge 可能启用安全 DNS（DoH）；常规 53 端口劫持无法直接拦截所有加密 DNS。必要时临时关闭浏览器安全 DNS 做对照测试，测完再决定是否恢复。

第 6 步：WebRTC 看 IP，不要只看红字。 REJECT-DROP 下连接失败可能是合理结果；但如果显示了与代理出口不同的真实公网 IP，就要排查 UDP 路径、代理模式和浏览器设置。

第 7 步：一次只运行一个代理客户端。 Mihomo Party 和 FlClash 不要同时争夺 TUN、系统代理或 DNS 接管。每次修改后保存、重新应用配置，必要时重启浏览器再测。

七、这次真正学到的东西

过去我以为“网页 IP 已经变成境外 + TUN 开启 = 没有泄露”。这次实测才发现，节点出口、分流模式、DNS 上游、系统 DNS 劫持、WebRTC UDP 拦截，是不同层面的问题。同一份 JS 在两个客户端上，最终效果也可能因为客户端配置合并、Windows 路由设置不同而不一样。

下一次如果重新安装 Windows、重装 FlClash 或更换机场，我就按这篇文章的速查表恢复，不再盲目堆 DNS 地址或反复切换全局模式。

参考资料

说明：这是一份个人环境中的排障记录，不是所有 Windows 11 / Clash 客户端的通用安全保证；不同版本或网络环境可能需要调整。

#Clash #WebRTC
comments powered by Disqus