现象对齐：是全机断网，还是只有 Discord「半截能用」

不少人遇到的是：浏览器和其它软件正常，但 Discord 桌面客户端在安装或更新阶段进度条长时间停在 0%，或是能登录、能看文字频道，一进语音房就卡顿、断续甚至秒掉。这类问题往往不是因为「彻底上不了网」，而是 HTTPS/API、CDN 下载与网关长连接走了不该走的节点，以及语音链路依赖的 UDP（承载 RTP 类实时媒体）没有完整进入你希望的那条路径。

若把 Clash 直接切成全局有时能暂时缓解，却会把所有应用一并带走，不利于定位根因。更稳妥的是在 mode: rule 下，把 Discord 相关业务拆开命名：哪些域名只管静态资源与更新包，哪些只管网关 WebSocket，哪些会话最终会落到UDP 语音端口。本文面向 Windows 桌面客户端（可执行文件通常为 Discord.exe），并与站内 Steam／UDP 联机、Epic 启动器 CDN 等同构场景共用一套排查直觉。

动手前若需要复习规则自上而下命中、DOMAIN-SUFFIX 与 GEOIP／MATCH 谁该靠前，请先读 规则分流指南，下文默认你已会在面板里查看实时连接日志。

先把症状拆开：更新 CDN、网关与语音是三件事

更新卡在 0%或下载安装包异常，多与分发域名、大型附件 CDN 有关。Discord 的安装与增量更新常会命中诸如 dl.discordapp.net 一类主机名（具体以你客户端版本与连接日志为准），若这条流量被过早送进延迟高或受限的出口，就会表现为进度不动。此时浏览器仍能打开 discord.com，并不代表桌面进程也在同一策略组里。

文字频道正常、一进语音就崩，往往是网关或UDP 语音服务器其一出问题。gateway.discord.gg 一类主机承载实时信令与控制面的长连接；真正传输语音媒体时，客户端会与地域语音节点建立 UDP 会话，日志里可能出现 discord.media 相关解析结果或裸 IP。若你只开了系统 HTTP(S) 代理而没有让游戏级 UDP进入内核／TUN 路径，就很容易出现「看得见在线状态，听不见稳定声音」的矛盾现象。

头像、表情包、大图预览加载慢，多与 cdn.discordapp.com、media.discordapp.net、discordcdn.com 等静态与附件 CDN有关，应与更新分发主机名分开观察，否则你会误以为「整条 Discord 都需要同一个节点」。

分流骨架：独立策略组 + Discord 后缀置顶

实践上建议新建策略组（例如 PROXY-DISCORD），在 rules: 中用 DOMAIN-SUFFIX 收纳常见业务后缀，并把这些行放在会把流量送去无关默认策略或过早「直连／回国」匹配之前。下列后缀在教学场景中经常出现：discord.com、discord.gg、discordapp.com（历史兼容）、discord.media、discordcdn.com，以及对网关主机名的精确 DOMAIN（如 gateway.discord.gg）。CDN 主机名亦可按需写成 DOMAIN-SUFFIX,discordapp.net,PROXY-DISCORD，以便覆盖分发子域。

订阅自带的远程规则若含有「社交媒体」「微软服务」等宽泛分类，要注意自定义 Discord 行与远程集的先后顺序：一旦被更早的 GEOIP,CN、广告拦截集或宽泛 MATCH 抢先命中，你在面板里「明明选了节点」却仍然走错组。开启 mihomo Sniffer 时，请对照 Sniffer 排障文，核对嗅探域名与策略命中是否一致，避免出现日志里有域名、策略却落在默认组的错位感。

YAML 骨架：示例结构（请按日志改写）

以下为结构示意，务必结合自己面板字段、节点名称与连接日志补全；切勿当作唯一生产配置复制即用。

proxy-groups:
  - name: PROXY-DISCORD
    type: select
    proxies:
      - 低延迟节点
      - 高带宽节点
      - DIRECT

rules:
  - DOMAIN,gateway.discord.gg,PROXY-DISCORD
  - DOMAIN-SUFFIX,discord.com,PROXY-DISCORD
  - DOMAIN-SUFFIX,discord.gg,PROXY-DISCORD
  - DOMAIN-SUFFIX,discordapp.com,PROXY-DISCORD
  - DOMAIN-SUFFIX,discord.media,PROXY-DISCORD
  - DOMAIN-SUFFIX,discordcdn.com,PROXY-DISCORD
  - DOMAIN-SUFFIX,discordapp.net,PROXY-DISCORD
  # 其余 CDN / IP 命中请根据连接记录追加

Windows：系统代理、「仅浏览器」与 TUN，Discord.exe 到底走哪条链

Discord 桌面端不是浏览器插件里的页面，它是独立进程。若你只在浏览器装了 SwitchyOmega 一类扩展，与 Discord.exe 无直接关系；若在 Windows「代理设置」里填了本地端口，也要确认对应 GUI 是否真的执行了设置为系统代理，以及 Discord 版本是否完整遵循系统代理链。更稳妥且易于对照文档的做法，是为需要全局分流的应用启用 TUN 模式（或等价的全局捕获），让TCP 与 UDP一并进入 mihomo 决策面。

TUN 与系统代理的差异、以及与「全局规则」的配合，详见 TUN 模式与全局代理 与 仅浏览器／系统代理差异。若本机同时存在 Hyper-V、WSL2、虚拟机网卡导致默认路由抖动，也会出现「有的应用偷偷直连」的假阳性，可先交叉阅读 WSL2 与 Clash 路由 再回头看 Discord 规则。

更新与 CDN：为什么进度条能「假装在工作」

当分发主机名落在错误的策略组（例如走了超高延迟的国际中继，或被某些审计规则间歇丢弃）时，安装器可能在 UI 上长时间停在初始百分比。排查时请打开连接面板，在点击「检查更新」或重装触发下载时，观察进程名是否为 Discord 相关、远端主机名是什么，再把缺失的后缀加入上文策略组或使用 Rule Provider 维护。

与此同时务必核对 DNS：解析是否统一由 Clash/mihomo 处理，fake-ip 是否与域名分流策略一致，避免「解析在新加坡、握手却奔向另一个大区」的分裂状态。IPv6 若绕开代理栈，有时也会表现为看似随机的失败，可按需在阶段性测试中收紧变量。

语音断续与 RTP：UDP 不是「附带功能」，要和 TCP 分流一起看

Discord 语音通道建立后，媒体面依赖UDP传输加密负载（工程上常笼统称为 RTP 语义）；这与加载网页用的 TLS TCP不是同一类故障。若所选节点禁用 UDP、抖动极高，或本机映射路径中出现多重 NAT，你就会听到断续、延迟飙升或直接掉线。

请对照 节点 UDP／DNS／STUN 排障：延迟测试长期异常时，优先验证内核是否放行 UDP、换一组确认支持 UDP 的中继，再在「仅 TCP 走代理、UDP 直连」与「全套进 TUN」之间做有意图的取舍，而不是来回全局试错。

若你希望「游戏 UDP 直连、仅 Discord Web 走代理」，必须在规则里明确写出各自去向，并意识到语音 UDP 可能与游戏占用同类注意事项：擅自把一大批 UDP 无脑直连，有时反而绕过你想要的 QoS 路径。

和游戏一起用时：推荐的排查顺序

许多用户同时挂 Steam、Epic 或主机转发规则。为避免互相牵连，建议顺序如下：① 确认 Discord 相关 DOMAIN-SUFFIX 已在宽泛匹配之前命中正确策略组；② 确认 Windows 侧TUN／系统代理确实覆盖 Discord.exe；③ 单独验证语音 UDP（换节点、对比 TUN 开关）；④ 若仍有异常，再打开游戏客户端重复①～③，避免把两条产品线混在同一个「全局直连／全局代理」开关里试错。

Steam 侧的 CDN 与联机 UDP 拆分可参考前述 Steam 专文；Epic 侧补丁链路则有独立的 CDN 域名习惯，请勿混抄 YAML。

可打印检查清单

1. mode: rule，Discord 自定义规则位于会提前回国／默认兜底的匹配之前。
2. 分别在「登录」「浏览附件」「检查更新」「加入语音房」四次操作中抓取连接日志，记录主机名与策略组。
3. 核对 DNS、fake-ip、IPv6 是否与面板一致；缩小变量后再测语音。
4. 语音异常时单独测 UDP：换节点、确认 TUN、排除对称 NAT 或多代理串联。
5. 与游戏共用机器时，按上文顺序拆分 Discord 与游戏各自命中记录。

小结

Clash 分流 Discord的关键，是把CDN／API／网关／UDP 语音分层看清，再用规则顺序与Windows 代理路径保证 Discord.exe 真正进入决策面；更新卡住多看 CDN 与 DNS，语音断续多看 UDP 与节点质量。相比反复切换全局，按清单推进通常更快收敛。

需要各平台客户端安装包时，请优先访问本站 下载页；开源仓库适合查阅协议与反馈渠道，与「获取安装包」的主路径区分开即可。若你已习惯给流媒体、开发工具分别建策略组，把 Discord 单独成章会让桌面协作稳定得多。→ 立即免费下载 Clash，开启流畅上网新体验