这是一套可回滚、可验证的 macOS 分流方案：
- 国内、局域网和指定应用走本机物理网络。
- 其他流量优先走 VPS 上的 WireGuard。
- WireGuard 暂时失效时，后续 TCP 连接改走同一台 VPS 的 SSH SOCKS。
- System Proxy 与 TUN 同时开启；TUN 扩大覆盖到遵循正常内核路由、未被 route exclusion 排除的 IPv4 UDP/WebRTC 等流量。
它不是“完美隐藏”方案。主线保留国内直连，因此不同网站看到不同出口是 预期；SSH 备用也不支持 UDP。需要所有公网目标统一使用 VPS 出口时，应 改成另一套单一出口策略，并接受国内访问可能变慢。
本次公开基线在以下环境完成验证：
- macOS 26.5.2，Apple Silicon
- Clash Verge Rev 2.5.2
- Mihomo 1.19.29
这些版本是证据锚点，不是照着攻略操作的硬门槛。其他近期版本通常沿用 相同架构；UI、DNS 合并、服务生命周期或字段默认值出现差异时，再读取本机 版本和对应 release notes。
2026-07-28 的 TUN 开/关/恢复 A/B 共完成 105 次经同一 mixed-port 入口的
真实请求，全部成功。关闭 TUN 没有表现得更快，部分海外请求反而更慢；这
只能支持“未发现 TUN 拖慢 System Proxy 路径”，不能证明 TUN 会提速，也
不外推到 TUN-only UDP。恢复后，两个独立 raw STUN IPv4 目标
的 UDP 响应与代理出口一致，普通公网路由重新进入 TUN。真实浏览器
WebRTC/ICE 在 Google Chrome 150 连续 3 轮均只得到与 HTTP 出口一致的
srflx，没有公网候选错配或 IPv6 candidate；本机检查还未观察到全局 IPv6
route。该结果不自动覆盖微信内嵌 WebView、Safari 或 Firefox。完整结果见
验收与性能基线。
flowchart LR
A["遵循 macOS 代理设置的应用"] --> B["System Proxy"]
C["未被排除的 IPv4 UDP/WebRTC 等流量"] --> D["TUN + auto-route"]
B --> E["Mihomo Rule"]
D --> E
E -->|"国内 / 局域网"| F["DIRECT-WIFI"]
E -->|"其他目标"| G["AUTO-FAILOVER"]
G -->|"主路径，TCP + UDP"| H["Mihomo 原生 WireGuard"]
G -->|"备用，仅 TCP"| I["本机 SSH SOCKS"]
H --> J["VPS"]
I --> J
System Proxy 和 TUN 是两个独立开关，可以同时为真。Clash Verge Rev
首页停留在“系统代理”区域，只代表当前显示的卡片，不代表 TUN 没运行。
进入 Mihomo 之后，真正决定 DIRECT-WIFI、WireGuard 或 SSH 的是规则和
策略组。详见 架构与边界。
| 当前状态 | 阅读入口 |
|---|---|
| 还没有 VPS | 购买 VPS 前的选择 |
| 已有纯 Ubuntu VPS，需要 WireGuard 服务端 | VPS 服务端配置 |
| 已有 VPS、WireGuard Peer 与 SSH | macOS 客户端安装 |
| 已部署，需要完整验收 | 验收与性能基线 |
| 发生慢、断网或泄露检测异常 | 排障矩阵 |
| 准备交给本地智能体协助 | 智能体协作手册 |
- 备份当前 Clash profile、应用设置和系统代理状态，记录回滚入口。
- 迁移用户保留一条已经通过真实请求的海外路径；全新部署保留 VPS 控制台 和管理员 SSH，直到第 4 步建立第一条 SSH SOCKS 海外路径。
- 在 VPS 建立 WireGuard 服务端与这台 Mac 的独立 Peer。
- 先建立
127.0.0.1:7898的 SSH SOCKS，确认真实 HTTPS 请求成功。 - 把 WireGuard 私钥放进 Mihomo home 内权限为
0600的私密 provider。 - 根据 公开 profile 模板 推导物理 接口和 route exclusions；不要复制别人的 VPS、DNS 或局域网值。
- 导入副本 profile，使用
Rule，同时开启 System Proxy 与 TUN。 - 按 验收清单 检查入口、路由、DNS、规则、主备、 WebRTC/STUN、IPv4/IPv6 与性能。
公共模板中的 REPLACE_WITH_...、example.com 和示例接口都必须在私密
副本中替换；真实副本不得提交到 Git。
公开模板已把两个 provider 的持续健康检查设为 enable: true、
lazy: false，并把 fallback 失败门槛设为 2。当前机器仍运行旧 profile
中的遗留健康检查值；本次重写没有把公开模板静默部署到当前运行态。
- 国内目标走物理网络，速度和区域兼容性优先。
- 海外目标与被 TUN 捕获的 STUN/UDP 走 VPS WireGuard。
- 中国检测站若命中国内规则，看到中国出口属于设计结果。
- 所有公网目标都走 VPS，出口一致性优先。
- 需要删掉或收窄公网 DIRECT 规则和公网 route exclusions。
- 国内访问不再保证直连性能。
给某个 IP 检测域名单独加 PROXY 规则，只改变该站点，不会把分流模式
变成单一出口模式，也不能用来证明匿名。
- 经典系统代理可能被 WebRTC 的 STUN UDP 绕过；本方案用 TUN 从更底层 扩大覆盖。raw STUN 脚本不等于浏览器 WebRTC/ICE 验收，两者都不能只看 开关。
dns-hijack把匹配的 UDP/TCP DNS 导入 Mihomo，不等于自动接管任意 DoH、DoT、局域网 DNS 或 Bonjour/mDNS。- profile DNS 与 Clash Verge 全局 DNS 覆写必须只有一个配置所有者。
route-exclude-address会让目标绕过 TUN。只排除确需直连的物理 LAN、 VPS underlay 和直连 DNS，并逐项验证。- WireGuard 主节点支持 UDP；SSH SOCKS 备用仅支持 TCP。主节点故障时， UDP 可能失败，fallback 不保证同一个失败请求透明重试。
- WireGuard 与 SSH 共用同一台 VPS，不能覆盖 VPS 整机、账号、主机商或 上游共同故障。
至少确认：
- controller 返回
mode=rule、TUN 开、auto-route=true。 - macOS HTTP/HTTPS 系统代理指向活动 mixed listener。
- 普通公网 IPv4 路由进入 TUN；被排除的 LAN/DNS/VPS underlay 走物理 接口。
- 国内与海外请求交错重复，实际规则命中符合预期。
- WireGuard 与 SSH 分别真实可用；WireGuard handshake 和 transfer counters 在真实请求后更新。
- 假故障演练后，新 TCP 连接切到 SSH；恢复后回到 WireGuard。
- 两个独立 raw STUN IPv4 目标不显示本地 ISP 公网 IPv4；当前 Chrome 复核也通过，但实际发生问题的其他浏览器或 WebView 仍要单独测试。
- Mihomo IPv6、系统全局 IPv6 route 与浏览器 candidate 被分开记录； 网络或配置变化后重新验收。
- TUN A/B 没有新增失败或超过预设性能门槛。
诊断脚本只读系统与 Mihomo 状态，但会发送少量真实请求：
NETWORK_SERVICE="Wi-Fi" zsh scripts/diagnose.zsh主动候选探测会更新健康历史，只在保存故障现场后使用：
ACTIVE_NODE_PROBES=1 NETWORK_SERVICE="Wi-Fi" zsh scripts/diagnose.zsh需要比较显式代理、无显式 HTTP proxy 的请求和两个 raw STUN IPv4 出口时：
STUN_PROBES=1 NETWORK_SERVICE="Wi-Fi" zsh scripts/diagnose.zsh这会向公共 IP 回显与 STUN 服务发送请求；脚本只报告是否一致，不打印实际 出口 IP。结果不能代替浏览器 WebRTC/ICE candidate 检查。
输出可能包含网关、接口和网络结构，公开分享前按 安全说明 脱敏。
- 架构与边界
- VPS 购买
- VPS 服务端配置
- macOS 客户端安装
- 验收与性能基线
- 排障矩阵
- 迁移与事故记录
- 智能体协作手册
- Mihomo profile 模板
- WireGuard provider 模板
- 客户端诊断
- HTTP 性能 A/B runner
- VPS 诊断
- 离线仓库校验
- 证据来源
- 公开安全边界
运行仓库检查：
bash scripts/test-validate-repo.sh
bash scripts/validate-repo.sh静态 CI 只能证明公开文件、结构与安全扫描通过，不能代替目标机器的端到端 网络验收。