现象：为什么常常是「文字OK、语音崩」
Discord 的文字与媒体多走基于 TCP 的 HTTPS/WebSocket 路径；而语音通话、屏幕分享里实时性要求高的部分，往往依赖 UDP 做传输（具体端口与主机名会随客户端版本和地区变化）。若你只开了「系统代理」或规则只覆盖了常见 443 出口，TCP 侧看起来一切正常，语音却会在NAT 打洞、UDP 被丢或未经过代理栈时频繁掉线。排查时请不要先换节点，先把「语音这一层到底有没有进 Clash、进的哪条规则」搞清楚。
先对齐心智模型：System 代理、TUN 与「谁接管了 Discord」
在 Clash Meta / Mihomo 系客户端里，常见两种接管方式：一是让操作系统把「支持代理的 HTTP(S)」交给本地端口（常称 System Proxy）；二是通过 TUN 模式创建虚拟网卡，在更底层把更多 IP 层流量交给内核。对桌面端 Discord 而言，并非所有连接都会老老实实尊重系统代理；若你只靠前者而语音走了直连或被其他安全软件重写，就会出现「一半像走了代理、一半又像没走」的分裂感。
若你希望同一进程的 TCP 与 UDP 决策尽量一致，通常需要让流量进入同一套策略栈：要么确认应用确实遵循系统代理，要么使用 TUN 把需关注的范围收进来。完整开启步骤可参考 Clash Verge Rev TUN 模式完整教程；Linux 服务端场景可对照 Linux 下 Mihomo 与 TUN、systemd 路由 一文，理解路由与自启动层的差异。
1第一步：打开连接日志，盯住协议与进程
无论你用的是图形客户端还是外置面板，都请打开实时连接日志，在出现语音卡顿的十秒内观察三件事：① 目标主机名是否为 discord 相关域、CDN 或区域边缘节点；② 连接类型是否为 UDP 以及大致端口范围；③ 命中了哪条 rules、落到哪个 proxy-groups。如果日志里根本没有语音时段的 UDP 记录，往往说明语音没有进入 Clash（或走了其他网卡）；此时先回退到「接管方式」问题，而不是忙着换机场。
若日志里出现大量 IP 而不是域名，可结合 Clash Meta Sniffer 与 HTTPS 域名分流 的说明，评估是否需要对特定握手做嗅探；语音 UDP 不一定总有可读的「域名」，因此进程级与 IP 级信息同样重要。
2第二步：规则是否把 Discord 送到了「能用的」那一组
在 规则排查里，顺序就是优先级：rules 中越靠前的条目越先匹配。若远程规则集把即时通讯归到「直连」而你的网络环境对 Discord 不友好，你会看到文字勉强可用、语音却因为 UDP 走错位而崩；反过来，若错误地让语音走了一条对 UDP 极不稳定的中继，也会表现为「只有语音烂」。务必将「从日志里抓到的真实主机名 / IP 段」写进本地覆写，并放在会误伤你的宽泛规则（例如过宽的 GEOIP 或 MATCH）之前。
实务上很多人会用到基于集合的 GEOSITE、RULE-SET；它们是否包含你当前客户端实际连接的域，要以日志为准而非静态记忆。更系统的写法见 Clash Meta GEOIP 与 GEOSITE 规则怎么写。下面片段仅示意类型与顺序，占位名需换成你配置里真实存在的策略组名，域名行请以日志核对为准：
# Example only — replace PROXY / DIRECT with your real policy or proxy-groups names
# Expand domain rows from your live connection logs when voice stutters
rules:
- PROCESS-NAME,Discord.exe,PROXY
- DOMAIN-SUFFIX,discord.com,PROXY
- DOMAIN-SUFFIX,discord.gg,PROXY
- DOMAIN-SUFFIX,discordapp.com,PROXY
- MATCH,DIRECT
macOS 或 Linux 上进程名并非 Discord.exe；使用 PROCESS-NAME 时请改成你在任务管理器或日志里看到的真实名称。进程级规则可与 进程名规则与分流 一文一起阅读，避免「写对了关键字却匹配不到」的低级错误。
3第三步：确认节点与上游是否支持 UDP
即便规则把 Discord 送到了代理组，若该组当前选用的协议或节点供应商对 UDP 支持不佳（或被上游禁用），语音依然会表现为周期性掉线。面板中的「延迟测试」多为 ICMP/TCP 类探活，无法替代「语音真实 UDP」体验。务实的对照是：临时为 Discord 映射到一个你确信全协议可用的节点，若症状立刻缓解，则问题重心在出口能力而非本机；若仍失败，再回到 TUN、防火墙与 DNS。
若你在使用链式代理或复杂嵌套策略，UDP 可能在某一跳被丢弃；排查顺序可与 relay 链式代理与故障排查 对齐：先确保每一跳对 UDP 的行为符合预期，再谈优选与负载。
DNS、FakeIP 与「听起来像网络问题」的细节
与纯网页场景不同，语音掉线有时伴随着「区域语音路由」重试；若 DNS 把某些记录解析到了你规则未覆盖的侧，仍会出现间歇抖动。请确认 Clash DNS 与 FakeIP 配置不会造成「看得见域名、出去却是另一路径」的错位，具体步骤可参考 Meta 内核 DNS 防泄漏指南。另外，TUN 环境下 MTU 过小也可能放大 UDP 碎包问题；若仅在语音时 burst 丢包，可在排除规则与节点后，再查系统网卡与虚拟网卡的 MTU 设定是否为常见上网瓶颈。
本机防火墙、同伴安全软件与「第二条代理」
Windows 上 Defender 或其他管家可能为 Discord.exe 单独放行/拦截；若 Clash 监听端口未被允许入站，也可能影响部分中继拓扑。请检查是否同时运行了另一款 VPN、公司 ZTNA 或浏览器侧「独立代理」，它们会与 Clash Meta 争抢路由表。最省时间的验证是：只对单一出口做最小复现——关闭多余软件，保留 Clash + Discord，再看日志与语音是否同向改善。
推荐排查顺序（可收藏对照）
为减少来回试错，建议固定顺序：① 在卡顿发生当下抓取连接日志，确认 UDP 是否进入 Clash、命中哪条规则；② 对照当前是 System 代理还是 TUN 模式，判断接管范围是否覆盖语音；③ 临时固定节点，验证是否为上游 UDP 能力问题；④ 再检查 DNS/FakeIP、防火墙与其他代理冲突。多数「仅语音坏」的案例会在前两步现形。
合规提醒：请仅在法律与网络使用政策允许的范围内使用代理与加密隧道；企业或校园环境应遵守本地管理规定。
关于下载：开源仓库可在 GitHub 查阅；获取安装包请优先使用 本站下载页。
小结
Discord 的语音通话对 UDP 与端到端路径更敏感；在 Clash Meta / Mihomo 体系里，务必把 TUN 模式、规则排查与节点UDP 能力放在同一套逻辑里思考。先日志、后规则、再出口与系统环境，比盲目开启「全局」更能稳定定位问题。若你尚未完成客户端安装与基础订阅导入，可先按 Windows 下 Clash Verge Rev 安装与上线路径 搭好基线，再回到本文处理语音专项。
相比在多款工具之间手动切换协议，在同一套图形客户端里维护订阅与覆写，长期更容易复盘；当语音与文字表现不一致时，优先怀疑「协议与接管面」而不是单点带宽——这与站内许多纯分流/DNS 类文章形成了场景互补。