TUN stack 究竟是什么：别把「延迟」只在节点上猜
TUN 本质是操作系统上的虚拟网卡：应用程序认为自己照常访问互联网，但实际数据包会先被送进 Mihomo（Clash Meta）的规则与策略管线。真正把 IP 分组「喂」进内核里这段用户态逻辑的，就是 stack 选项所指的网络栈实现：system 侧更贴近宿主系统的协议栈通路；gvisor（来自 Google gVisor 思路的用户态 IPv4/v6、TCP、UDP 实现）则更像是「先在用户态过完一遍再在边界与系统对齐」的路径。
这不是玄学：同一种规则同一条节点，只因为 stack 换成另一种，你可能会看到UDP 丢包体感不同、CPU 占用波形不同，甚至少数驱动与杀软钩子在与「内核旁路」共舞时表现出的兼容性差异。正因如此，当你在《TUN 开启教程》后仍卡住，非常值得先把 stack 做一次单次变量实验，再继续堆规则。
gvisor 与 system：逐项对照（兼谈 mixed）
站点文档与常见版本中，还会在二者之外看到 mixed：许多场景下它代表「在 TCP 与 UDP 等路径上做折中与组合」，综合延迟与兼容性折中——若客户端已提供且为默认策略，可以保持为第一道基线；当你需要二分法锁定问题时，再在 纯 gvisor 与 纯 system 两头做对称试验往往更利落。下面仍以用户最常手动对比的二元为主。
偏向选 gvisor 的典型信号
- 某些杀毒、零信任套件或内核扩展对「绕过方式」的路径特别敏感：切到用户在栈内完整模拟后反而少闪断。
- 你能观察到兼容性问题集中在少数「不走寻常路」的程序，而吞吐绝对值要求不高，更能容忍一点额外延迟毛刺换取稳定。
- 在虚拟化或容器化的桌面（如老式嵌套 Hyper-V/WSL 与物理网卡之间夹多层桥）环境中，操作系统栈与你的期望出口偶尔分叉，gvisor 路径有时更自闭环。
偏向选 system 的典型信号
- 主要诉求是游戏、竞技类场景的帧时间稳定与低延迟 UDP：把更多工作放回系统栈常常是减少中间层复制的方向。
- 大量 QUIC / HTTP3 或大流量 P2P 时，你看到 CPU 单核飙升而怀疑用户态拷贝过多：可尝试对齐 system 观察占用是否回落。
- 你已确认没有其他安全钩子干扰 TUN（或愿意白名单 Mihomo）：此时 system 往往能给出更「顺滑」的主观手感。
以上都是优先级提示而非法律：同一台机器会随着系统更新、杀毒策略与 Wi-Fi ↔ 以太网切换而漂移——请永远以当天复现为最终裁判。
配置在哪儿改：YAML 里最小编辑面
Meta 内核的 TUN 通常在顶层 tun: 映射里声明。下列片段仅供结构与键名对齐，具体默认值与可用枚举请对照你安装的内核版本文档与 GUI 导出结果：
# Example skeleton — tune keys per your release and overlay (mixin/profile)
tun:
enable: true
stack: system # or: gvisor (sometimes: mixed — see docs)
若你用 mixin 覆写，请记得「合并之后的最终顺序」才是真正生效的那一份——细节见站内 Mihomo mixin 覆写与订阅合并。服务端或 Linux systemd 常驻场景可参考 Linux 下 Mihomo、TUN 与 systemd 理解路由钩子与开机顺序；Windows / macOS 桌面端则更依赖 GUI「开关 TUN」「管理员权限」「堆栈下拉框」三件事是否一致触发。
游戏与 QUIC（HTTP/3）为何对 stack 更敏感
游戏里除了下载更新走 TCP，很多对战与语音桥接大量使用 UDP；QUIC 同样运行在 UDP 之上并且强调0-RTT、连接迁移等路径特性。若在 Mihomo 中这条 UDP 在用户态多做一次排队或重组，体感上往往不是「慢了 80ms」这么简单，而是以微卡顿、偶发拉回、语音爆音呈现。
先别急着把锅甩给 GEOIP：分流规则是否把游戏进程与 QUIC 宿主（浏览器内核、CDN 的边缘 IP）放到了一致的策略组仍然是第一战场——语法与优先级请顺带复习 GEOIP 与 GEOSITE 写法。但在确信规则已收敛后，再回到本文的 stack二进制对照，常能解释「为什么我明明直连/代理写对了却仍抖」的余量部分。
1推荐试验顺序（控制变量）
- 记录当前症状窗口：卡顿发生时的连接日志里是否出现大批量
UDP；目标进程名称与命中规则。 - 仅改一项：
tun.stack在 gvisor ←→ system 间切换一次，重启内核/服务使配置下沉（必要时重插拔 TUN 开关）。避免同时改动节点与健康检查间隔。 - 对同一小游戏局或同一 QUIC 基准页面回放三次，分别记录主观延迟与 CPU——哪怕只是手机秒表打点也有价值。
- 若两者各有长短：把「日常使用」设为较稳的一侧，再在专项场景临时切另一侧，并在记事本里写明回滚旋钮防止遗忘。
2堆栈敲定之后：DNS、规则与环境变量查漏
Stack 对齐后仍存在解析漂移或多出口打架，才把精力移向 DNS：FakeIP、DoH 与兜底链路的先后顺序请按 Meta 内核 DNS 防泄漏 逐条自检。它与「堆栈选型」是正交维度：栈解决数据面如何从系统进入 Mihomo；DNS 决定「看见的 IP」与后继规则命中是否一致——两者同时错了会互相放大成片状故障。
规则一侧，善用连接日志校准：若只有裸 IP，可参阅 HTTPS 域名嗅探 把维度补齐再回到「首条命中」逻辑。环境里若存在公司 PAC、浏览器独立代理或多个 VPN，请收窄到单一入站路径再谈 stack——否则你是在给未知变量做拟合。
坑位提示：别把「体感延迟」误认为出口质量
Panel 上用 ICMP 或单次 TCP Ping 的结论，常与语音、QUIC、小游戏 UDP 的生存条件脱节。更糟的是：TUN 一开，误把 NAS、局域网打印或内网 OA 送进代理也会让 CPU 与白名单规则「看起来很忙」，从而掩盖栈的问题。请先确保 DIRECT/LAN bypass 合理——思路与站内「局域网直连」「Fake IP 过滤」类文章一致——再回来谈 gvisor/system 的微差。
分发入口：安装包请以 本站下载页 为准；若在 GitHub 跟踪内核变更，可把 Release 备注与本站教程对照阅读。
合规：请遵守所在地法律法规及网络服务商政策；企业或教育机构网络请遵循本地信息安全规定。
小结
Clash Meta（Mihomo）的 TUN 并不止于「勾选虚拟网卡」：tun.stack 在 gvisor 与 system 间的切换，是解决兼容性、游戏与 QUIC 体感差异时成本最低的一组对照实验——它补全了你搜索链条里夹在「教程」与「DNS/GEOIP」之间缺失的一环。先试栈、再收口 DNS 与分流规则，比在未知变量下堆环境变量更有意义。
相比在不同工具之间来回卸载安装，把注意力放在「可记录的旋钮」上会省掉大量的周末时间；当你在「规则已经合理」却仍觉得 UDP 怪怪的，不妨再回到上文关于 gvisor 与 system 的对照小节，把手上的三次复现打点收成自己的长期基线——这才是工程化的上网排错该有的样子。