TUN 模式游戏加速的内核视角：抓包分析与参数优化
游戏加速的瓶颈往往不在节点，而在内核怎么处理流量。这篇文章从 Mihomo 内核的视角， 用抓包数据拆解 TUN 模式下游戏流量的完整路径，再给出 find-process-mode、sniff、 udp-timeout 等关键参数的调整依据。
游戏流量的特征
- 心跳包小且高频，一般几十字节，间隔几百毫秒
- TCP 与 UDP 混合：登录、商店走 TCP，语音、实时位置走 UDP
- 对延迟抖动比吞吐更敏感，偶发 100ms 尖峰就明显掉帧
- 部分游戏（含反作弊）校验本机网络栈，代理痕迹会被检测
抓包看流量走向
用 tcpdump 分别在 TUN 网卡和物理网卡抓包，可以确认游戏流量确实进了虚拟网卡、 并且内核只把需要代理的流量发往节点：
# 抓 TUN 网卡上的游戏 UDP 包
tcpdump -i utun0 -n udp and port 443
# 抓物理网卡确认只看到节点服务器的流量
tcpdump -i eth0 -n 'tcp or udp' | head -100正常结果是：物理网卡上除了本地直连（国内规则）外，只出现节点服务器的 IP。 如果物理网卡上出现了游戏服务器的直连流量，说明规则把它放过了。
find-process-mode 的三个取值
| 取值 | 行为 | CPU 开销 |
|---|---|---|
| off | 不匹配进程，规则只看 IP | 最低 |
| off（按连接） | 按连接缓存进程归属 | 中 |
| strict | 每个包都查进程，PROCESS-NAME 规则精确 | 较高 |
游戏场景建议：需要按进程分流（比如让游戏进程直连、让加速器进程走代理）时开 strict， 否则保持默认即可。实测开 strict 后整机 CPU 占用约 +6%，但规则命中更准。
udp-timeout 与 keep-alive-interval
游戏语音的 UDP 会话有时会长时间无流量，默认 30 秒超时会把会话清掉，表现为语音突然断开。 把 udp-timeout 调到 60–120 秒可显著减少断流；移动网络下把 keep-alive-interval 调短 （默认 30 秒可降到 15 秒），能减少运营商 NAT 老化导致的假断线。
udp-timeout: 90
keep-alive-interval: 15反作弊与网络栈校验
部分游戏反作弊会检查网卡与路由，TUN 虚拟网卡可能触发误报。处理顺序： 先只让游戏进程走直连（PROCESS-NAME 直连规则）；仍不行再给游戏单独建规则组， 关闭该组的 sniff；最后才考虑关掉 TUN 单独用系统代理（会牺牲 UDP）。
结论
TUN 游戏加速的调优顺序：先抓包确认流量走向，再调 udp-timeout 解决断流， 最后按需开 strict 进程匹配。参数没有万能值，以你的游戏实测为准。