TUN 虚拟网卡、系统代理、NAT 类型与 GeoIP/Rule-Set 智能分流引擎底层原理
核心问题：客户端是如何在 0.05 毫秒内决定一个数据包该走国内宽带直连，还是走香港 IEPL 专线的？
这背后依靠的是现代代理客户端的两大核心引擎：底层流量截获机制（系统代理 vs TUN 虚拟网卡） 与 高性能规则匹配引擎（GeoSite / GeoIP / Rule-Set）。理解这两大机制，能彻底解决命令行无法翻墙、外服游戏 NAT 严格受限与国内软件误走代理耗流量等顽疾。
1. OSI 网络协议栈视角：系统代理 (Layer 7) vs TUN 虚拟网卡 (Layer 3)
| 技术指标 | 传统系统代理 (System Proxy) | TUN 虚拟网卡模式 (Wintun / utun / VpnService) |
|---|---|---|
| 工作层级 | OSI 第 7 层（应用层 HTTP / SOCKS5 协议） | OSI 第 3 层（网络层 IP 数据包截获） |
| 底层实现方式 | 修改 Windows 注册表 Internet Settings 或 macOS 网络偏好设置，监听 127.0.0.1:7897 |
通过 WireGuard Wintun 驱动 ↗ 或系统内核虚拟网卡，修改系统路由表接管全部 IP 流 |
| 不服从管教的软件 | CMD/PowerShell、Git、Docker、Python、Steam 游戏、Discord 语音默认全部绕过系统代理 | 0 漏网之鱼！操作系统内核层强制把整机所有进程 TCP/UDP 流量送入代理内核 |
| 移动端对应机制 | 仅限局域网手动填写 HTTP 代理 | iOS NetworkExtension (小火箭) 与 Android VpnService (CMFA) 均原生基于 TUN |
2. 为什么玩外服游戏、Switch 联机与 Discord 语音必须关注 UDP 与 NAT 类型？
浏览网页和看 YouTube 视频主要使用 TCP（或基于 UDP 443 的 QUIC），而多人实时联机游戏（Apex、使命召唤、任天堂 Switch 喷射战士）与实时语音（Discord RTC、Telegram 通话）100% 依赖原生 UDP 协议：
- 开启 TUN + UDP 转发：在 Clash Verge Rev 中开启 TUN 模式后，确保机场节点配置中已包含
udp: true（本站推荐的 速界机场、神行加速、可信云 均全节点默认开启 UDP 转发）； - FullCone NAT (全锥形 NAT / NAT 1 / 类型 A)：Mihomo 与 Sing-box 内核在开启 TUN 时会自动启用用户态 TCP/IP 协议栈（如
gVisor或Mixed栈），支持完整的 UDP FullCone 映射，让 Switch 联机测试直接达到 NAT 类型 A/B，告别联机掉线。
3. 分流引擎匹配优先级：为什么 GEOIP,CN,DIRECT 必须放在最后？
当一个网络请求进入 Mihomo (Clash Meta) 或 Sing-box 的分流引擎时，内核会从上到下逐行匹配规则，一旦命中立即执行出站，不再往下看。科学的规则排列顺序如下：
🔀 科学分流规则匹配金字塔（从高优先级到兜底规则）
rules:
# 第 1 层：进程名匹配（无需网络开销，直接放行国内下载工具与网银进程）
- PROCESS-NAME,WeChat.exe,DIRECT
- PROCESS-NAME,baidunetdisk.exe,DIRECT
# 第 2 层：域名后缀与 Rule-Set 规则集匹配（纯字符串/前缀树匹配，耗时 < 0.01ms，不触发本地 DNS 解析）
- RULE-SET,openai,AI专线
- RULE-SET,youtube,🚀 节点选择
- RULE-SET,cn_domain,DIRECT
# 第 3 层：IP-CIDR 与 GEOIP 国家库匹配（若未加 no-resolve 会触发本地 DNS 解析，因此放在域名规则之后）
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- GEOIP,telegram,🚀 节点选择,no-resolve
- GEOIP,CN,DIRECT
# 第 4 层：最终兜底规则（所有未命中的海外长尾网站全部走代理）
- MATCH,🚀 节点选择核心秘诀：在为海外 IP 规则（如 Telegram IP 段）编写分流时，务必在末尾加上 no-resolve 参数，防止客户端为了匹配一条 IP 规则而在本地提前解析海外域名，从而与 Fake-IP 防泄漏机制 完美配合！