为什么「能上网站」却不等于「语音正常」
Discord 同时长了好几类连接：网页与桌面端要拉取网关接口、CDN 静态资源、更新与崩溃上报；一旦你进入语音频道，客户端还要做 WebRTC 协商——典型的组合是 TLS 上的信令 加上 UDP（或经 TURN 转发的 UDP） 承载实际媒体流。国内运营商、校园网或企业防火墙里，常见情况是 TCP 443 被「温和放行」或可通过代理绕开，但对 UDP 大端口随机性 或海外 TURN 主机并不友好。
于是你会看到代理规则层面的「分裂」：网页版能加载出频道列表，桌面端却卡在登录转圈；或好友文字聊天正常，一进语音就出现 语音断连、持续重连、麦克风图标闪烁。把问题简单归咎于「节点不够快」往往不得要领——更优先要问：这组 RTC 连接有没有进入 Clash、进入后有没有被错误地 DIRECT 到不可达路径，以及 UDP 分流是否被内核或客户端正确处理。
Discord 流量粗略分层：别只对域名「许愿」
公开资料与长期社群经验都指向一点：Discord 大量使用 discord.com、discordapp.com、discord.gg 等域名承载 API 与信令入口；语音与实时业务还会涉及各类边缘与区域主机名，且实际媒体目的地址常常是动态分配的 IP 段，而不是你事前一条一条能背下来的列表。单纯「把几个域名写进规则」有时只能覆盖信令与初始化；若连接建立阶段走了代理，而后续 UDP 因应用自身或系统路由绕开虚拟网卡，就会表现为「能听见半句、然后掉线」。
因此，与其堆域名关键词，不如建立两层意识：第一，协议层上确保 TCP 与 UDP 在被统计与匹配时走同一策略意图；第二，观察层上学会从连接日志读出：语音阶段是否出现大量短生命周期 UDP、是否频繁换远端端口——这与本站在 Clash 连接日志与规则命中 一文中强调的方法一致，只是把观察对象从「网站打不开」换成「RTC 抖动」。
TUN 优先：让 UDP 没有「后门」可绕
仅启用系统代理（HTTP/SOCKS）时，不少程序仍会用自己的一套套接字策略，或以不被系统代理钩子的方式发起 UDP。对 Discord 桌面端尤其如此：要想稳定做 Clash UDP 分流，业界更稳妥的做法是开启 TUN，由虚拟网卡在路由层接手流量。本站 TUN 模式详解 已从通用视角写过适配范围，这里只强调语音场景：TUN + 正确的排除列表（若你需要局域网或校园内网直连），往往比反复调 `system-proxy` 开关更省事。
移动端（Android/iOS）与桌面端的差异也要心里有数：部分定制系统会对 VPN/TUN 并行数目、省电策略做激进干预，表现为切后台后语音立即掉线——这类问题不完全在 Clash YAML 里，但若你确认前台仍大量 UDP 直连，就应当回头检查是否真的进了 TUN，以及有没有其它「加速器」或安全软件抢路由。
Clash Meta（Mihomo）与 UDP：你在配置里要盯什么
在 Clash Meta / Mihomo 系内核中，UDP 并非魔法开关，而是一系列相互配合的能力：出站协议是否支持 UDP 转发、DNS 解析路径是否与规则匹配、以及 TUN 是否把本地应用流量正确导入 Clash。若你使用基于 VMess / VLESS / Trojan 等现代协议，一般期望是「UDP 跟随 TCP 同类出口」，但实际仍取决于节点提供商是否允许与是否正确声明。
当你在图形界面里看到「UDP 未转发」「握手失败」一类提示时，请先区分：是节点本身拒绝 UDP（机场常见问题），还是规则把语音命中到了错误的策略组（例如误走直连），或是DNS 先把主机解析到了一个「看起来在国内」、但 RTC 需要海外出口的结果。这与 fake-ip 与 redir-host 一文讨论的 DNS 增强模式强相关——竞技游戏与实时语音都对「解析稳定、规则一致」极其敏感。
为 Discord 单独留一个稳定策略组
语音比网页下载更怕「自动测速每十秒换一次最快节点」。建议新建一个手动 select 型的策略组（名字自定，例如 DISCORD_VOICE），日常固定一枚你验证过能完整承载 UDP的节点；把自动 URL 测速组留给浏览器或下载类规则即可。若必须用时延测速，也请拉长间隔、降低并发，避免正在进行的 RTC 会话被频繁打断。
语音区域（客户端里选择的区域）并不替你做「物理翻墙」，它主要影响 Discord 试图把你接入哪一套语音基础设施与测量路径。区域选得离出口太远，可能徒增 RTT；但若你出口本身到某区域长期拥塞，反而可以尝试相邻区域做 A/B。关键是：区域切换必须与「节点所在地区」联合观察——出口在美国而语音区强行设在法兰克福，有时不如统一到美洲区内再试。
规则骨架：域名先入组，再谈 GEOIP
下面是一段教学用 YAML 骨架，演示如何把常见 Discord 域名放入专用策略组。合并进现有配置时，请把片段放在过于宽泛的 GEOIP,CN 或笼统的 MATCH 之前，以免被提前判为直连。具体域名是否仍完整以当前客户端版本为准，若日志出现新主机名，应以日志为准增补；更系统的国内/海外分层见 Clash 分流规则配置教程。
proxy-groups:
# Stable selector for Discord signaling + voice-related egress
- name: DISCORD_VOICE
type: select
proxies:
- PROXY
- DIRECT
rules:
- DOMAIN-SUFFIX,discord.com,DISCORD_VOICE
- DOMAIN-SUFFIX,discordapp.com,DISCORD_VOICE
- DOMAIN-SUFFIX,discord.gg,DISCORD_VOICE
- DOMAIN-SUFFIX,discord.media,DISCORD_VOICE需要再次强调：域名规则解决不了「已解析成 IP 的纯 UDP 五元组」全部历史问题，但可以把绝大多数初始化与回退流程放进可预期出口。余下的命中要靠 TUN、较少冲突的 DNS 模式，以及你对连接日志的复盘——而不是盲目复制网上的巨型 IP 列表。
TURN / STUN 与语音断连：日志里长什么样
当 NAT 或防火墙导致 UDP 端到端打不通时，客户端会尝试走 TURN 中继。中继多了额外一跳，延迟上升，但总比完全听不到强。若你怀疑 TURN 始终建不起来，可以在客户端网络调试工具（若可用）或 Clash 日志中观察：是否在同一策略意图下频繁出现 UDP 超时、是否与 DNS 解析到的 TURN 主机不一致。此类问题常被误报为「语音区域坏了」，其实是代理规则某一段仍把特定 SNI 或 IP 命中到了直连。
另一个常见误区是把「关了代理就能语音」当成解决方案：那往往只是说明你当前网络对直连 UDP「偶尔能通」，一旦运营商策略变化又会复现。我们要做的是稳定复现路径，而不是赌概率。
DNS 与规则对齐：减少「假连通」
在 fake-ip 模式下，若系统仍绕开 Clash 做 DNS，可能出现解析与连接跟踪不一致：信令域名像是走了代理，但应用缓存了一个不被 Clash 劫持的解析结果，后续 UDP 又与规则层脱节。临时对照时可切到 redir-host 观察语音是否立刻改善；若改善明显，再回头微调 fake-ip-filter、nameserver 列表与 fallback 触发条件——细节以你所用内核文档为准。
校园网环境还要留意认证门户与「仅 HTTP 放行」场景：未登录前一切全被劫持到认证页，Clash 自然全程异常；这类问题须先完成网络登录，再谈 Discord Clash 分流。
排障清单：从「进没进 Clash」到「UDP 走哪」
建议按下述顺序自检，把玄学问题拆成日志可对齐的工程步骤。
- 确认使用 TUN，并在语音复现时打开连接日志，查看相关进程是否命中预期策略组。
- 暂时固定
DISCORD_VOICE（或你的等价组）为单一节点，关闭激进自动切换，排除「换节点导致 RTC 重握手」。 - 核对
rules顺序：Discord 相关规则是否早于宽泛国内直连；合并远程规则集时注意最终顺序与覆盖关系。 - 若仅有语音异常而网页正常，优先怀疑 UDP 与 DNS：必要时对照切换 DNS 增强模式做 A/B。
- 向节点提供商确认 UDP 是否被限速或禁用；更换一枚明确支持 UDP 的中继再试。
症状：登录循环或验证码无限加载
多见于 API 与脚本域名被拦截或 SNI 异常，优先对照浏览器能否完成 OAuth 流程，再检查是否有中间人证书或企业 HTTPS 检查干扰。
症状：频道内持续「正在连接」或间隔性全部静音
优先检查 UDP 进入 Clash 与策略组稳定性，其次再看节点地区和 语音区域组合是否合理。
小结
Discord 场景里，「网页能开」与「语音不断」分属不同层面的网络能力：UDP 分流与 TUN、DNS、策略组共同决定 RTC 是否能在你可控的出站闭环里跑完。把 Discord 相关域名先送进独立、稳定的策略组，再让 TUN 接管系统流量，最后借助日志确认语音断连时究竟卡在解析、规则还是节点——大多数令人头秃的掉线都能落到具体一行命中记录上。
相比许多黑箱工具，Clash 在可观测性与规则组合上更适合这类问题；若你尚未安装客户端或需要完整操作路径，可先前往本站 下载页 获取安装包，并结合 文档中心 把 TUN 与订阅基线搭好，再按本文细化代理规则。→ 立即免费下载 Clash，开启流畅上网新体验