Discord 语音与游戏 UDP 延迟高？Clash TUN 与中继节点逐项优化
很多人把 Clash 当成「让浏览器能上网」的工具，却忽略了一个事实：语音通话与多数竞技游戏的实时通道高度依赖 UDP。一旦整台设备在 TUN 或系统代理下被统一导向境外节点，Discord 的语音区段、游戏内的语音模块或对战服握手，就可能出现延迟飙升、间歇掉线、单向无声等现象——这往往不是你耳机坏了，而是路径、NAT 行为与节点对 UDP 的支持方式叠加后的结果。本文从真实搜索意图出发，帮你区分「仅代理网页」与「UDP 友好或可预期的代理出口」，并结合 PROCESS-NAME、中继跳数与节点协议做逐项优化；与侧重商店分流的 Steam／Epic 专题互补，专门覆盖 UDP 语音与游戏流量。
典型症状：你可能遇到的是哪一类问题
在开启 Clash 后，如果 Discord 里朋友抱怨你「声音断续」或「只有你听不到别人」，而关闭代理立刻恢复，这通常指向语音 RTP／WebRTC 路径被送到了不合适的出口。游戏侧则常表现为：匹配变慢、语音频道进不去、对局中偶发掉线，或延迟条从十几毫秒跳到几十毫秒并伴随抖动。浏览器访问网页仍然正常，会让人误以为是「节点带宽不够」；但对 UDP 小包来说，带宽测速几乎没有意义，关键在往返时延、丢包与对称性。
- 单向无声或一方卡顿：常见于 NAT 类型与打洞失败，代理出口若不支持完整锥形或 UDP 映射不稳定，语音会退化为中转或反复重协商。
- 延迟「台阶式」上升：多半叠加了中继或多段隧道；每一跳都会增加排队与重传概率。
- 仅游戏内语音异常、系统其他网络正常：说明命中规则的不是整网卡，而是特定进程或端口段；适合用进程级规则精确拆解。
为什么 UDP 语音与游戏比「刷网页」更难伺候
HTTPS 网页以 TCP 为主，内核会替你处理重传与拥塞控制；语音与实时对战更依赖低抖动的小包连续到达。代理软件把流量封装进另一层隧道后，UDP 报文要么被端到端转发（对节点与实现要求高），要么被限制或降级（例如部分链路只保证 TCP）。此外，Discord 与许多游戏客户端会并行建立多条会话：信令走 TCP／TLS，媒体走 UDP；若规则只按域名把「discord.com」交给代理，却漏掉边缘媒体主机名，仍可能出现「文字频道正常、语音不正常」的割裂感。
中继（链式代理）在隐私与可达性上有价值，但对实时 UDP 几乎是「按跳计费」：每一中继都引入额外 RTT 与失败面。若你的订阅里默认组套了两段甚至三段中继，而浏览器测速仍「好看」，请不要惊讶——测速大流量与几十毫秒的语音帧完全不是同一类负载。
心智模型
把流量分成三类：只要可达的网页与 API、需要稳定 UDP 的语音／对战、大体积下载。Clash 的价值是让三类走不同策略组，而不是共用一个「最快测速节点」。
Clash TUN 与 PROCESS-NAME：先抓住「是谁发的包」
系统代理对很多游戏无效；TUN 把拦截点放到更靠近内核的位置，让「不听话」的进程仍经过 Clash 决策。现代 Clash Meta／Mihomo 系内核支持 PROCESS-NAME 与 PROCESS-PATH，你可以在规则靠前位置声明：Discord 客户端走专用策略组，目标游戏进程直连（DIRECT），浏览器继续走你习惯的代理组。这样比单纯堆域名表更接近用户真实意图：只代理网页并不等价于「只代理浏览器进程」——还要考虑独立安装的 Discord、启动器内嵌语音与反作弊子进程。
在 Windows 上，桌面版 Discord 常见进程名为 Discord.exe；请在本机任务管理器或连接日志中核对大小写与是否多开。若同名进程较多，可用 PROCESS-PATH 收窄到安装目录。macOS 上应用包路径不同，务必按本机路径填写，不要照搬论坛片段。
若尚未完成 Windows 侧 TUN 基线，请先跟随 《Clash for Windows 安装与配置》完成订阅与模式切换；DNS 异常会放大语音问题，可对照 《DNS 泄漏与 fake-ip 排查》先排除解析层故障，再叠进程规则。
规则顺序示意：别让 MATCH 吞掉进程行
以下 YAML 仅为结构示意，请把 PROXY、DISCORD-UDP 等替换为你的真实策略组名，并在日志中验证命中顺序。
# Illustrative — verify process names and policy group names locally
rules:
- PROCESS-NAME,Discord.exe,DISCORD-UDP
- PROCESS-NAME,SomeCompetitiveGame.exe,DIRECT
- DOMAIN-SUFFIX,discord.com,PROXY
- DOMAIN-SUFFIX,discordapp.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
要点：更具体的进程规则应出现在宽泛的 GEOIP 与最终 MATCH 之前；否则你永远看不到进程命中。若你使用合并后的远程规则集，请确认本地覆写段仍位于合并结果顶部附近，而不是被大段第三方规则提前 MATCH。
中继与节点协议：逐项削减「多余的路」
当你确认语音或游戏确实需要走代理（例如区域限制或运营商 QoS）时，下一步是减少无效跳数。中继节点本质上是「你的流量先进 A，再由 A 去连 B」；对 TCP 下载有时还能忍受，对 UDP 语音则非常敏感。优化顺序建议如下。
- 能单跳就不多跳：在订阅或策略组中优先选择直达出口，避免默认套娃中继。
- 为语音单独建策略组：与「大流量下载组」分离，健康检查间隔不要太激进，以免 UDP 会话频繁换链。
- 理解协议差异：不同传输在弱网下的表现不同；部分基于 QUIC 或专门优化 UDP 的协议栈在相同 RTT 下抖动更小，但这取决于服务端实现与运营商对 UDP 的放行程度——请以实测语音 MOS 与游戏内延迟条为准，而不是只看握手延迟。
| 因素 | 对 UDP 语音／游戏的影响 | 实操建议 |
|---|---|---|
| 中继层数 | 每跳增加 RTT 与失败概率 | 语音组选低跳数；必要时直连 |
| 节点协议／传输 | 封装方式影响丢包恢复与小包排队 | 为实时流量单独测几类节点并固定胜者 |
| DNS／fake-ip | 错误解析会导致「连上却无声」 | 语音异常时先对照 DNS 专题逐项收紧 |
直连与代理的边界：什么时候应该 DIRECT
若你的核心诉求是「国内对战服低延迟」，而 Discord 仅用于与朋友开黑，常见折中是：游戏进程 DIRECT，Discord 走延迟可控的中继组，浏览器与其他应用按域名分流。这样即使 Discord 仍经代理，也不会把游戏本体的 UDP 一同拖进隧道。若你主要用网页版 Discord，记得浏览器进程名与独立客户端不同，PROCESS-NAME 行也要分开写。
另一种极端但干净的做法是：游戏与语音全部直连，仅对明确需要翻墙的域名与浏览器进程走代理。这对「只想科学上网、不想动游戏」的用户最省心，但需要维护好自己的域名列表与规则优先级。
合规与条款
请遵守当地法律法规与游戏、Discord 等服务条款；部分竞技游戏对网络隧道与修改路由的行为有限制。本文仅讨论你有权配置的设备上的网络工程问题。
用连接日志做「证据驱动」排查
不要凭感觉换节点城市。打开日志后，同时观察三列：进程名、目标地址与端口、命中的策略与链。若游戏进程仍显示走 PROXY，说明进程规则被其他更高优先级规则覆盖或写错进程名。若 Discord 已走直连但仍无声，则转向 NAT、防火墙与耳机权限等系统因素，避免在代理层空转。
建议排错顺序（每次只改一项）
- 确认
Rule模式与 TUN 已按文档正确启用。 - 在日志中记录异常时刻的进程名与目标 IP／端口。
- 暂时去掉中继，仅保留单跳出口对比语音。
- 为 Discord 与游戏分别指定策略组并复测。
- 最后才调整 DNS／fake-ip 与远程规则大表。
常见问题
单向无声但文字频道正常
优先查 UDP 路径与中继层数；同时排除本机输入设备权限与蓝牙编码器问题。代理层重点看媒体相关目标是否误走直连或被防火墙拦截。
只有游戏内语音坏、系统其他应用正常
多为游戏进程命中了错误策略或反作弊子进程被拦。用进程规则把游戏主体与已知反作弊服务放在一致且可达的路径上，避免一半直连一半代理的「分裂路由」。
测速很快但语音仍卡
测速多是大 TCP 流；语音是小包 UDP。请用语音通话与游戏内延迟条做判据，并对比去掉中继前后的差异。
实操检查清单
- TUN +
Rule工作正常，日志可读到进程列。 PROCESS-NAME／PROCESS-PATH位于 GEOIP／MATCH之前。- 语音与游戏策略组分离，中继跳数最小化。
- DNS 与 fake-ip 行为与规则一致，无「解析成功但路径错」现象。
- 用一局游戏 + 一次语音通话联合验证，再考虑微调域名表。
从可读规则与稳定客户端开始
Clash 系客户端的优势在于：策略、规则与日志一体化，适合这种「既要网页又要实时 UDP」的细粒度需求。把 Discord、浏览器与游戏拆清楚之后，维护成本会显著低于反复全局换节点。