📖 教程 ⏱ 约 16 分钟阅读

Discord 语音断续：Clash UDP 分流与直连例外分步实测

不少游戏与社群用户反馈：一打开 Clash，Discord 里别人说自己声音「一截一截」、频道里突然只剩自己、或语音路由显示异常。这类问题往往不是「再换一个节点试试」就能解决，而是 RTC 媒体（常见为 UDP）与HTTPS 信令走了不一致的出口、被前置规则误直连、或节点本身不支持/不稳定转发 UDP。本文按可观测、可复现的顺序，教你用连接日志判断是节点质量、UDP 路径还是分流规则，并给出直连例外与固定节点两类可复制的 Clash 分流规则写法；与站内面向视频会议、游戏商店的分流文互补，专注 Discord 语音这一高频场景。若你还在理解代理组与默认兜底，可先读Clash 代理组（proxy-groups）完全指南。

先把现象说清楚：卡的是文字图片，还是「语音频道」

Discord 客户端里同时存在多类流量：频道列表、消息与嵌入预览主要是 HTTPS；进入语音后，真正的低延迟通话往往依赖 WebRTC／RTC 通道，其中媒体面大量使用 UDP（具体端口与目标会随地区与通话对象变化）。因此你会看到一种典型分裂：文字与图片都正常，唯独语音断续或延迟飙升——这强烈提示问题在媒体路径而非单纯「上不了 Discord」。

另一种分裂是：关闭 Clash 或切到直连后语音立刻恢复，而开着规则模式就复现。此时应优先怀疑规则命中顺序、TUN 是否接管了 UDP、以及当前节点对 UDP 的支持，而不是先去调麦克风采样率。下文默认你已能稳定登录 Discord；若连登录页都打不开，请先对照自定义规则教程：让指定 App 走指定节点确认基础域名分流无误。

为什么 Clash 特别容易「伤到」语音

规则型代理的核心是按域名、进程或网段把流量分发到不同策略组。语音媒体对丢包、抖动与 NAT 类型极其敏感；一旦 UDP 被送到高延迟、QoS 差或根本未正确转发 UDP 的中转，听感就是断续与爆音。与此同时，若信令走代理而媒体误直连（或相反），也可能出现握手慢、路由混乱，表现为进频道慢或偶发掉线。

仅启用系统代理时，不少应用的 UDP 仍可能不经过 Clash，问题反而不明显；一旦打开 TUN 全量接管，所有 UDP 都会进入内核路径，此时规则与 DNS 的任何不一致都会被放大。关于 TUN 与系统代理的取舍，详见TUN 模式深度解析。与 Zoom、Teams 等会议软件类似，Discord 也属于「实时音视频 + 大量边缘节点」场景，排查方法论可与远程办公 Zoom、Teams 连不上：Clash 分流与 DNS 排查步骤对照阅读，但 Discord 的域名集合与 UDP 行为自有特点，不宜照搬会议软件的规则清单。

分步实测第一步：在日志里区分信令与媒体

打开客户端自带的连接日志／请求记录（名称因 Clash Verge、GUI 等而异），在「进入语音频道、说话十秒、退出」这一窗口内观察三类信息：目标主机名或 IP、协议是 TCP 还是 UDP、以及命中的规则与策略组。信令阶段常见与 discord.com、discordapp.com、discord.gg 等相关的 HTTPS；媒体阶段则可能出现不同区域的裸 IP 或 CDN 边缘主机名，且以 UDP 为主。

若日志里完全看不到 UDP，而系统已开 TUN，仍听不到对方，要回头检查是否被其他 VPN／加速器抢路由，或 Discord 是否走了分流拆分（Split Tunneling）。若能看到 UDP，但策略组在频繁切换，应优先检查 url-test 容差与测速间隔——语音最怕「几秒换一次出口」。固定到一个延迟稳定的节点做 A/B，是区分节点问题与配置问题的最快手段。

分步实测第二步：验证 UDP 是否被当前节点接受

并非所有订阅节点都对 UDP 友好：部分线路仅保证网页浏览 TCP，对游戏与语音类 UDP 限速或丢弃。实测建议：在日志确认 UDP 已进入 Clash 后，暂时把 Discord 相关流量固定到同一「已知支持 UDP」的节点（若订阅提供游戏／专线标签可优先尝试），再复测语音。若固定后立刻改善，则根因在出口质量，应调整选路或换组，而不是继续堆域名规则。

在 Mihomo／Clash Meta 系配置中，部分代理需要显式允许 UDP（视订阅与内核版本而定，常见字段如 udp: true）。若你使用游戏分流或全局「偏好 UDP」类选项，务必确认没有与规则中的 DIRECT 冲突。任何「示例配置」都应以你本机实际命中为准迭代，而不是一次性抄大段规则集。

分步实测第三步：检查规则顺序与「误直连」

很多断续来自前置的 GEOIP 或大陆直连规则：Discord 的某些边缘 IP 被误判为可直连地址，媒体走了运营商国际出口质量差的路径；而信令仍走代理，于是出现能进频道但音质差。反之，若媒体被送进不支持 UDP 的代理链，也会直接断流。

处理方式是把与 Discord 明确相关的主机名规则放在过于宽泛的 IP 规则之前，并用日志验证「改顺序前后」UDP 命中策略是否变化。若你启用了嗅探（sniffing），个别场景下 SNI 与真实目标不一致会干扰规则匹配，可参考Clash Meta 嗅探导致网页异常？关闭与分流例外写法分步实测中关于 skip-domain 与例外列表的思路，对语音类应用谨慎开启「过度嗅探」。

可复制规则 A：Discord 走固定代理组（适合 UDP 稳定节点）

将下列 PROXY_VOICE 替换为你配置里真实存在的 proxy-groups 名称；域名集合请按你日志里出现的主机名增补或收紧。顺序上建议放在私有网段与局域网规则之后、过于宽泛的 GEOIP 之前。

# Example — replace PROXY_VOICE with your proxy-groups name
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,discord.com,PROXY_VOICE
  - DOMAIN-SUFFIX,discord.gg,PROXY_VOICE
  - DOMAIN-SUFFIX,discordapp.com,PROXY_VOICE
  - DOMAIN-SUFFIX,discordapp.net,PROXY_VOICE
  - DOMAIN-SUFFIX,discord.media,PROXY_VOICE
  - DOMAIN-SUFFIX,discordcdn.com,PROXY_VOICE
  - DOMAIN-SUFFIX,discordstatus.com,PROXY_VOICE
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

说明：MATCH 行仅作示意，请与你自己的默认策略一致。若语音仍异常，回到日志确认是否有未列入后缀的独立域名或裸 IP，用 DOMAIN 或更精细的规则补位，而不是无限加宽 DOMAIN-SUFFIX 以免误伤其他站点。

可复制规则 B：语音相关直连例外（适合「只卡代理 UDP」）

当你确认直连时语音完美，但走代理后 UDP 质量差，且暂时无法换到更好的节点时，可以让 Discord整体或部分域名直连，与其他仍需代理的流量共存。注意：直连意味着暴露真实运营商出口，请自行评估隐私与地区政策风险。

# Example — Discord direct; other traffic still uses your groups
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,discord.com,DIRECT
  - DOMAIN-SUFFIX,discord.gg,DIRECT
  - DOMAIN-SUFFIX,discordapp.com,DIRECT
  - DOMAIN-SUFFIX,discordapp.net,DIRECT
  - DOMAIN-SUFFIX,discord.media,DIRECT
  - DOMAIN-SUFFIX,discordcdn.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_DEFAULT

其中 PROXY_DEFAULT 表示你原有的默认代理组占位符，请改成真实组名。若直连后仅文字通、语音仍失败，说明还有未覆盖的媒体目标未命中 DIRECT，继续用日志补域名或地址段；若直连后一切正常，则可逐步把「最影响 UDP 的子域」保留为 DIRECT，其余仍走代理，以减小暴露面。

DNS、fake-ip 与「规则写了但不生效」

与游戏商店场景类似（参见Steam 与 Epic 在 Clash 里怎么分流），DNS 解析路径与规则所见的域名不一致时，会出现「配置看起来对，命中却不对」的错觉。使用 fake-ip 时，务必让 rules 与 dns 段配套，谨慎使用 no-resolve，并避免系统 DoH 与 Clash DNS 混用导致分流漂移。排查时每次只改一类变量：先固定 DNS，再动规则，或反之，否则无法归因。

和 Steam／游戏下载类问题的本质区别

游戏平台下载更关心TCP 吞吐与连接保持；Discord 语音更关心UDP 抖动与丢包。因此 Steam 那套「商店组与 CDN 组拆分」经验，只能部分迁移到「信令与媒体分离」思路，却不能把大文件下载节点直接当成语音节点使用。给语音单独一个低抖动、UDP 稳定的组，往往比盲目堆带宽数字更有效。

推荐排查清单（可当作工单记录）

  1. 关旁路：退出其他 VPN／游戏加速器，避免双隧道抢路由。
  2. 定模式：明确当前是系统代理还是 TUN，对照日志看 UDP 是否进入 Clash。
  3. 抓窗口：仅在进出语音频道时记录主机名、协议、命中规则。
  4. 固定节点：用同一节点复测，排除自动选路抖动。
  5. 改顺序／补域名：处理误直连或误代理，再测一轮。
  6. 最后才直连例外：作为稳定语音的兜底，而非第一选择。

常见问题

写了 discord.com，为什么语音还是卡？

媒体流量可能命中其他子域、CDN 或裸 IP。请以语音过程中的 UDP 日志为准补规则，并检查是否有更靠前的规则将其送到错误组。

开 TUN 后反而比系统代理更卡，正常吗？

有可能。TUN 会强制更多流量（含 UDP）进入内核路径；若规则或 DNS 未跟上，问题会更明显。可对照TUN 模式深度解析逐项收紧。

直连 Discord 安全吗？

直连意味着该部分流量不经代理加密隧道，由本地网络直接访问目标服务；是否接受取决于你对网络环境与隐私的要求。可与「仅媒体相关子域直连」折中。

小结

Discord 语音断续在 Clash 用户中极高频，根因却很少是「客户端坏了」，而是RTC／UDP 路径与规则、DNS、TUN 接管方式不匹配。用连接日志把TCP 信令与UDP 媒体分开看，再用固定节点做 A/B，你能快速判断是节点还是规则顺序；在此之上，用本文的固定代理组或直连例外 YAML 片段按日志增量维护，就能把语音稳定下来，而不必整机关代理。

相比一次性全局隧道，Clash 的可编排分流更适合「既要日常浏览可管，又要游戏与社群语音可预期」的桌面环境——把清单当作可版本化的小配置，长期成本远低于反复试错。若你尚未安装或希望使用仍在积极维护的客户端，可从本站下载页获取安装包，并参考使用教程完成订阅与基础分流，再按本文为 Discord 补齐 UDP 与分流规则。→ 立即免费下载 Clash，开启流畅上网新体验。