一、先拆开：文字正常但语音异常意味着什么
在动手改规则之前，建议先把现象说清楚。若服务器列表、频道文字、图片预览都流畅，唯独加入语音频道后卡顿、绿圈闪烁、别人听自己像「机器猫」，通常说明TCP 侧的 HTTPS 已走通，而语音所需的 UDP/WebRTC 路径仍可能被错误路由、被防火墙拦截，或根本没有进入你期望的策略组。
另一种常见误判，是把所有问题都归结为节点延迟。语音对抖动与丢包远比对「绝对延迟」敏感：即便 ping 看起来不高，若 UDP 在代理链路上未转发、被对称型 NAT 反复改写，或本机同时存在多网卡优先级混乱，听感仍会像「断续」。因此排查时应优先确认：语音流量是否按预期进入 Clash 内核、内核是否处理 UDP、以及当前模式（系统代理 / TUN）是否覆盖到 Discord 进程。
PROXY 或你指定的游戏/社交组。没有日志的盲调，很容易变成「一晚上换了十个节点仍无效」。
二、Discord 语音链路：为什么域名规则常常不够
Discord 客户端会访问大量与账号、网关、CDN、媒体中继相关的主机名；不同版本与地区解析结果也会变化。若你只靠几条 DOMAIN-SUFFIX 规则，有可能出现文字频道命中了代理、而语音握手或媒体流因子域未覆盖、DNS 解析顺序或直连回源走了另一条路径的情况。
进程分流的价值在于：把判断从「猜域名」改成「认进程」——凡是来自 Discord 主程序（以及必要时其更新/辅助进程）的连接，统一进入同一策略组。在 Mihomo（Clash.Meta）系内核中，常见写法为基于进程名的规则（具体关键字以你所用内核与客户端版本为准，详见 配置文档）。这样即使后台域名列表微调，只要可执行文件名不变，策略仍保持一致。
需要强调的是：进程分流解决的是谁走了哪条策略，并不自动保证UDP 在整条链路上可用。下一节会说明如何把进程规则与模式选择结合起来。
三、进程分流：在 Windows 上锁定 Discord 主进程
图形界面里如何操作
不同 Windows 客户端对「进程规则」的入口不同：有的在规则编辑器里可直接按可执行文件指定策略组，有的需要手写 YAML。无论哪种方式，核心建议是：至少覆盖 Discord 主程序，并在你发现更新器单独拉起网络时，视情况为更新相关进程单独建组或并入同一组，避免「主程序走代理、更新器仍直连」造成版本与路由状态不一致。
YAML 示意（需按你的内核与客户端调整）
下面是一段仅作结构示意的配置片段；代理组名、策略名与规则类型请替换为环境中的实际值，并确认你的 Clash Verge、Clash for Windows 等所用内核版本是否支持进程级规则。
# Example only — replace proxy group names and rule keywords per your kernel build
rules:
- PROCESS-NAME,Discord.exe,SOCIAL_PROXY
- PROCESS-NAME,Update.exe,SOCIAL_PROXY
- GEOIP,CN,DIRECT
- MATCH,DIRECT若写了进程规则仍不生效，请依次检查：客户端是否以足够权限运行（部分环境下进程枚举受限）、规则顺序是否被更靠前的 DIRECT 或 REJECT 截断、以及是否存在多份配置（例如托盘里一份、磁盘上另一份）导致你以为改对了、实际加载的却是旧文件。
四、UDP、TUN 与系统代理：语音场景怎么选
系统代理（HTTP/SOCKS）主要面向「会读系统代理设置」的应用。许多桌面程序对代理的支持并不完整；UDP 在 SOCKS 路径上的行为也因客户端实现而异。若你发现文字正常、语音异常，而日志里几乎看不到语音相关的 UDP 进入内核，往往要考虑TUN 模式：它从路由层更统一地接管流量，使不感知代理的程序也能进入 Clash 内核（具体覆盖范围取决于实现与规则）。
TUN 的代价是全局副作用更明显：默认路由、DNS 与 Windows 防火墙规则都会变化，配置不当会出现「一开 TUN 整台电脑断网」。若你遇到这类情况，请按站内 《TUN 断网与防火墙排障》 逐步核对 Wintun、路由表与放行规则，而不是在 Discord 设置里反复开关「硬件加速」却忽略底层路由。
关于 NAT 与打洞：即便 UDP 已进入代理，对称型 NAT 或双重 NAT仍可能导致语音质量下降——这是拓扑限制，并非单靠换节点即可消除。建议在对比测试时每次只改一个变量（仅换模式、或仅换节点、或仅加进程规则），并保留截图或日志，避免结论被噪声淹没。
与局域网共享场景的关系
若你关心的是把 PC 上的代理分享给同局域网设备，而不是本机 Discord，请参阅 《混合端口与局域网共享》：那里讲的是监听地址与防火墙入站。本文聚焦本机 Discord 进程与 UDP 语音，两者可叠加使用，但解决的问题不同。
五、Discord 客户端侧：值得核对的语音与网络项
在确认 Clash 侧进程与 UDP大致正确后，仍建议在 Discord 内做一次「低成本核对」，避免与代理打架：
- 语音区域与服务器区域：若你长期跨区使用，尽量选择与实际物理位置或常用节点区域一致的设置，减少无谓绕路（具体选项名称可能随版本变化）。
- QoS 与流量整形：部分路由器或运营商会对 UDP 做激进整形；在 Discord 设置中关闭或调整与服务质量标记相关的实验项（若你的版本提供），有时能改善被错误降级的语音包。
- 硬件加速与音频子系统：驱动异常会导致「听起来像网络卡」；可在排除网络因素后，尝试更新声卡驱动或临时关闭相关加速项做对照（以官方文档为准）。
- 代理感知行为：Discord 桌面端通常不像浏览器那样完整遵循系统代理；因此「系统代理已开、Discord 语音仍异常」并不矛盾，反而提示你要看 TUN 或进程分流。
若你同时使用其他 VPN 或过滤软件，请确认它们没有与 Clash 争抢虚拟网卡或路由表；多栈并存时，优先保证只有一条明确的默认出口，否则语音最容易出现间歇性抖动。
六、建议的实测顺序（可记录、可复现）
下面是一条由浅入深的排查顺序，便于你在同一台电脑上做对照实验。
- 确认基础连通与 DNS：按 文档 完成订阅导入与浏览器侧测试，再进入 Discord。
- 看日志再加语音：进入语音频道前后对比日志，确认是否出现 UDP、策略是否为预期组。
- 加进程规则：为
Discord.exe（及必要的辅助进程）指定策略组，重复上一步。 - 在系统代理与 TUN 间做单变量对比：每次只切换一种模式，观察语音是否稳定；若启用 TUN 后整网异常，先修 TUN 再谈 Discord。
- 核对 Windows 防火墙与本机安全软件：确保 Clash 与虚拟网卡相关组件未被静默拦截（尤其是首次启用 TUN 时）。
- 最后再比较节点：在规则与模式正确的前提下，再测试不同地区线路的抖动与丢包。
把「网络层」与「客户端设置层」分成两个晚上测试，往往比一晚上同时改七处更容易得到可靠结论。
七、现象与检查项对照表
| 现象 | 建议优先检查 |
|---|---|
| 文字正常，语音断续或掉线 | UDP 是否进入内核；是否需 TUN；进程分流是否命中 Discord.exe |
| 长时间「连接中」进不了语音 | 防火墙 / 多 VPN 抢路由；DNS 与规则顺序；节点是否阻断相关端口 |
| 规则显示走代理，语音仍像直连或更差 | 是否仅 TCP 走代理；是否存在更前序的 DIRECT；本机多网卡优先级 |
| 开启 TUN 后整台电脑断网 | 路由表、Wintun、防火墙；详见 TUN 专文 |
八、小结
在 Windows 上已开启 Clash 的前提下，要解决 Discord 语音断续、掉线与连接异常，关键是把问题拆成「文字 TCP」与「语音 UDP/WebRTC」两条线：进程分流能稳定把 Discord.exe 等进程送进你信任的策略组，减少对频繁变更域名的依赖；UDP 与 TUN 则是多数语音场景绕不开的组合，需要与系统代理模式对照理解，并结合客户端内设置做最后一轮排除。
相比功能单一的轻量代理工具，Clash 生态在规则粒度、内核能力与客户端选择上更统一，适合既要照顾浏览器、又要兼顾游戏与社交语音的用户。若你尚未安装或希望换用维护积极的图形客户端，可从本站获取安装包后导入订阅，再按本文顺序完成进程规则、模式与 Discord 设置的自检。