AAO！名侦探破案笔记：用 v2rayN 的 TUN 模式让 Meta Horizon Link 老实走代理

AAO！我是名侦探橘雪莉！今天本站立案的是一起「流量失踪案」——

「明明系统代理好好设着，Meta Horizon Link 却装作完全看不见，公网请求全都裸奔出门。」
可恶，这起案件，站在有趣的一边的我必须查清楚！

案情背景

目标很明确：让 Meta Horizon Link（以及 Meta Quest Developer Hub）的联网流量走本地代理 127.0.0.1:16589，同时满足两个「不在场证明」：

• 其他程序不被强制进代理——要走代理的自己手动指到 16589；
• 和头显之间的串流、设备发现保持直连，不能被代理绕路拖延迟。

难点在于：这个应用根本不理会系统代理，设置里填什么它都当没看见。传统的「设置 → 代理」路线直接宣告死案。

名侦探的选型会议

TUN 的本质：装一块假网卡，把全机流量在路由层劫进代理核心。应用完全无感知，配不配合都一样。

正式搜查：配置步骤

第一步：开启 TUN

v2rayN → 参数设置 → TUN 模式，打开开关（需要管理员权限）。底层配置长这样，一般保持默认即可：

"TunModeItem": {
  "EnableTun": true,       // 开关本体
  "AutoRoute": true,       // 自动接管系统路由
  "StrictRoute": true,     // 严格路由，防泄漏
  "Stack": "mixed",        // 协议栈，mixed 兼容性好
  "Mtu": 9000,
  "EnableIPv6Address": true,
  "IcmpRouting": "rule"
}

第二步：设计路由规则（本案的核心证据墙）

v2rayN → 参数设置 → 路由规则，编辑当前规则集。顺序即判定顺序，从上到下第一条命中生效，最终形态如下表：

这套顺序翻译成人话：只有「Meta 两个应用」和「主动连 16589 的程序」走代理，其他一律直连；局域网永远排在进程规则前面，保证串流不会被卷进代理。

第三步：进程规则怎么写

规则编辑界面里有专门的 Process 文本框，每行一条。Xray 的三种写法（本应用两种混用）：

C:/Program Files/Meta Horizon/     ← 以 / 结尾 = 目录前缀，目录下所有进程全中
Client                             ← 无斜杠 = 进程名（自动去掉 .exe，区分大小写）
C:\Program Files\...\foo.exe       ← 含斜杠 = 绝对路径精确匹配（JSON 里反斜杠需转义）

实战教训：只写目录有翻车风险（路径大小写、短路径形态都可能让前缀匹配落空），所以每个目录后面再补一串进程名兜底，两条腿走路。另外 v2rayN 开 TUN 后会自动生成 xray/、self/ 防回环规则，别删。

案中案一：兜底直连把 DNS 也一起端了

把第 10 条兜底改成 direct 之后，第一版测试直接翻车：两个应用还是连不上，日志里躺满这种尸体——

[Error] app/dns: failed to retrieve response for graph.oculus.com.
        > Post "https://cloudflare-dns.com/dns-query": context deadline exceeded
from DNS accepted https://cloudflare-dns.com/dns-query [dns-module -> direct]

推理时间：域名都解析不出来，连接当然建不起来——看起来「没走代理」，其实是 DNS 先死了。原因：v2rayN 生成配置时，把「dns-module → 代理」这条规则排在了用户规则之后。兜底还是 proxy 时它顺风车搭对了；兜底一改成 direct，DoH 查询先被兜底截胡，直连去问 Cloudflare——国内直连 DoH，必然超时。

修复只有一行：把 「入站 dns-module → 代理」插到兜底直连之前。DNS 流量走代理拿到真实 IP，后续连接再按第 5~7 条规则分流，案件重见天日。

要点：改兜底规则时，永远检查一遍 v2rayN 追加在末尾的 DNS 相关规则有没有被你「抢跑」。

验证行动

参数设置 → 核心基础设置 → 开启日志、等级选 debug，重启核心后开应用登录，看日志里的流向标记：

from tcp:127.0.0.1:4398 accepted tcp:github.com:443 [socks -> proxy]   ← 手动走16589的程序 ✅
from DNS accepted https://cloudflare-dns.com/dns-query [dns-module -> proxy]  ← DNS修复 ✅
from tcp:... accepted tcp:...:443 [tun -> proxy]                      ← Meta流量进代理 ✅
from tcp:... accepted tcp:...:443 [tun -> direct]                     ← 其他流量直连（预期）✅

三类标记各就各位，案件终结。验证完记得把日志关掉，别让它一直写盘。

注意事项清单（贴在案发现场门口）

1. 动配置前关 v2rayN。路由规则存在 guiConfigs\guiNDB.db（SQLite），应用开着会锁库；改之前先复制一份 guiNDB.db.bak-日期，翻车可回滚。
2. 改完必须重启核心，且重启目标应用。已建立的连接不会被重新路由，Meta 的后台服务要完整退出再开，否则旧连接还挂在直连上。
3. 局域网/组播规则永远排在进程规则前面，顺序反了串流就进代理了。
4. v2rayN 的 TUN 样例规则会优先阻断组播/广播和 NetBIOS、mDNS（5353）端口——靠 mDNS 自动发现设备可能受影响，串流本身走局域网单播不受影响。
5. UDP 443 阻断会让 QUIC 应用回退 TCP，一般无感；介意可删。
6. 进程名匹配区分大小写，且裸进程名是全机匹配——机器上若有其他叫 Client.exe 的程序也会被带进代理（只是多走一圈，无害）。
7. TUN 需要管理员权限，且别和其他 VPN/TUN 同时开，两块虚拟网卡会抢路由。
8. 出问题的逃生路线：关 TUN + 恢复备份数据库，立刻回到改配置前的世界。
9. 写博客分享时记得脱敏：节点地址、UUID、Reality 密钥、账号密码一律打码——名侦探也不会把证物袋贴在网上！

结案陈词

「应用不认系统代理」听起来像死局，换到网络层动手术就迎刃而解：TUN 截流 → 进程/域名精准放行 → 兜底直连 → DNS 单独走代理，四步破案，两不耽误——头显串流照常，该走代理的一个都跑不掉。

站在有趣的一边，就是我的信条！这起案件，完美结案——AAO！