典型现象：为什么一开会话就崩？
许多玩家会遇到这类组合症状：浏览器访问外站正常，但联机房间进不去、对战中突然掉线、游戏内语音断续，或 Discord、TeamSpeak 一类语音在开启 Clash 后延迟极高甚至无法连接。它们往往与 UDP 有关——联机匹配、语音通话、部分反作弊心跳都大量使用 UDP；而代理链路对 UDP 的容忍度远低于 TCP，一旦规则把游戏进程或相关域名「误送进节点」，就很容易出现超时、NAT 类型变差或直接断连。
排查时请记住两个层次：流量有没有进 Clash，以及进 Clash 之后被送到了哪里。前者取决于你用的是系统代理还是 TUN；后者取决于规则顺序、策略组选择与 DNS 模式。下面按这个顺序拆开说明，并与本站 TUN 模式指南、规则分流详解 形成互补——前者讲透明代理总貌，后者讲规则语法，本文专注游戏与语音场景下的落地取舍。
系统代理还是 TUN？对游戏与语音意味着什么
系统代理（HTTP/SOCKS）只影响「愿意读系统代理设置」的应用。大量游戏主程序、独立语音客户端不会自动走系统代理，它们仍从物理网卡直接发包。此时你看到的「开代理后游戏反而坏了」，有时是DNS 或分流规则间接影响了解析结果，有时是浏览器走了代理而游戏直连，两边的网络路径不一致造成登录态异常；并不一定是游戏真的走了 SOCKS。
TUN 模式在 IP 层接管流量，只要路由把包指进虚拟网卡，游戏与语音也会经过 Clash 的规则引擎。优点是行为统一、少遇「浏览器能上、游戏不认代理」的分裂；缺点是所有进 TUN 的 UDP 都会按规则裁决，若默认规则偏向代理，联机 UDP 可能被送往境外节点，延迟与丢包立刻恶化。
实务建议：若你主要玩国服、局域网对战或强依赖低延迟的 PVP，优先保证相关流量直连；TUN 仍可使用，但必须在规则里显式提前放行游戏平台、反作弊与语音域名或网段。若你暂时不想处理 TUN 路由，可尝试仅对浏览器等应用使用系统代理，同时观察游戏是否恢复——这能帮助判断问题是否来自「全局接管」。策略组与基础模式概念也可在 使用文档 中先过一遍，再回头改规则会更快。
Clash 与 UDP：哪些情况容易被「误伤」
Clash / mihomo 对 UDP 的支持与具体协议、内核版本及节点是否允许 UDP 转发有关。许多商用线路会对 UDP 限速或干脆丢弃，语音小包与游戏状态同步对抖动又极敏感，一旦被送到不稳定节点，表现就是「偶发卡顿、突然掉线」。此外，部分规则集习惯将「未知域名」归入代理策略组，若游戏联机域名未在直连列表中，就会中招。
另一个常见坑是 NAT 类型：流量经代理出口后，公网侧看到的源地址变为节点，本机与对端的点对点路径被打破，可能从 Full Cone 退化为 Symmetric，匹配与语音中继策略随之改变。解决思路仍是：能让联机与语音走直连的，就不要送代理；确需代理的场景（例如下载外服资源）再单独拆分。
分流规则怎么写：顺序比「有没有规则」更重要
Clash 按从上到下匹配第一条命中的规则。游戏与语音相关条目应放在宽泛的 GEOIP 或 MATCH 之前，否则永远轮不到直连。可以按下面几类组织（具体域名请以你所玩游戏与客户端为准，下列仅为结构示例）：
- 局域网与本机：
IP-CIDR私有网段、DOMAIN-SUFFIX,local等，避免内网广播与发现被截走。 - 游戏平台与反作弊：厂商登录、补丁 CDN、反作弊与对战服务常用独立域名，建议单独
DOMAIN-SUFFIX或引用社区维护的规则集，并指向DIRECT或国内策略组。 - 语音软件：Discord、游戏内建语音网关等，若延迟敏感，通常同样适合
DIRECT；若你必须让语音走代理（例如网络环境限制），请确认节点 UDP 可用，并接受更高延迟。 - 默认策略：在以上条目之后，再交给
GEOIP,cn或MATCH，避免「默认代理」提前吃掉游戏流量。
# Example: put game/voice DIRECT rules above broad proxy rules
rules:
- DOMAIN-SUFFIX,steamserver.net,DIRECT
- DOMAIN-SUFFIX,steampowered.com,DIRECT
- DOMAIN-SUFFIX,discord.gg,DIRECT
- DOMAIN-SUFFIX,discord.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY上述域名仅为说明规则应插在 GEOIP/MATCH 之前；真实环境请结合抓包、客户端日志或可靠规则集补全。更细的语法与策略组配合方式可参考 规则分流详解。
DNS 与 fake-ip：语音掉线时的第二战场
开启 TUN 后，DNS 常和规则一样关键。fake-ip 模式下，部分域名若被错误映射，会导致应用拿到「看似可用」的地址，实际却与真实会话目标不一致，表现为能登录不能语音、能匹配不能进房。做法通常是利用 fake-ip-filter（或等价选项）把游戏、语音、STUN 相关域名排除在 fake-ip 之外，让解析走真实 IP，再配合 IP 规则分流。
同时检查是否启用了 加密 DNS（DoH）旁路：若应用绕过 Clash 直接解析，可能出现「TCP 走了代理、UDP 却仍按错误 IP 直连」的割裂。TUN 下可配合 dns-hijack 与 dns 段统一解析路径，细节见 TUN 模式指南 中的 DNS 小节。
一步步排查清单（建议按顺序做）
第一步：确认问题是否随 Clash 开关消失
完全退出代理或关闭 TUN，仅保留物理网络，重进游戏与语音。若恢复正常，说明问题与代理链路相关，而不是运营商或游戏服务器本身。
第二步：区分系统代理与 TUN
先只用系统代理（关闭 TUN）试一轮，再只开 TUN 试一轮。若仅 TUN 出问题，重点查路由、DNS 与规则顺序；若两者都出问题，还要怀疑 DNS 全局设置或订阅中的宽泛代理规则。
第三步：为游戏与语音加前置直连规则
从官方或社区文档收集当前游戏与语音服务的域名/IP 段，插入到规则列表前部，指向 DIRECT。每次改动后重载配置并冷启动游戏客户端，避免缓存会话沿用旧路径。
第四步：验证节点 UDP
若你必须让部分游戏流量走代理（例如外服），请在同一节点下用简单工具测试 UDP 连通性，或观察内核日志中是否有 UDP 转发失败。若节点不支持 UDP，应更换节点或改回直连。
第五步：收紧 fake-ip 与 DNS
为语音与联机域名配置 fake-ip 排除或改用 redir-host 等更可控模式，并确认没有应用硬编码 DoH 绕过内核 DNS。完成后再测一轮语音与房间稳定性。
安全与合规提示
请仅在遵守游戏服务条款与当地法规的前提下使用代理与分流。部分竞技类游戏对网络路径与第三方工具有明确限制，强行全局代理可能触发风控。本文仅讨论网络排错思路，不构成对任何具体游戏政策的解读。
小结
游戏联机与语音聊天代理场景的核心，是理解 Clash UDP 流量在 TUN 模式下会统一经过规则引擎：要么用分流规则把联机与语音提前导向直连，要么确保代理节点真正具备低延迟 UDP 能力。结合系统代理与 TUN 的差异做对照实验，再配合 DNS 与 fake-ip 调整，大多数「一开 Clash 就掉线」的问题都能定位到具体一层。
相比零散工具链，维护良好的 Clash / mihomo 生态在规则可读性、内核更新与图形客户端配套上往往更省心：同一套配置可以同时照顾日常浏览与游戏直连，减少反复切换。若你希望用可视化界面管理订阅、策略组与 TUN 开关，可以选择与 mihomo 深度集成的现代客户端，在稳定性与易用性上通常优于手动拼凑脚本。