一、先拆开两类现象：更新 0% 不等于「语音坏了」

Discord 更新失败或进度长期停在 0%，通常表示安装程序在拉取清单、差分包或完整安装包时，某些 TCP 443 连接没有完成握手或被错误策略反复重试。此时文字频道可能仍能用，因为即时消息与网关长连接已经建立，只是下载管线卡住了。

语音侧则不同：语音 RTC 往往依赖低延迟的 UDP 路径与稳定的区域中继。若你只对浏览器或部分进程开了系统代理，而语音走了另一条路由，就会出现「能打字、一进语音就爆 ping」或「连接语音路由失败」一类提示。把两类问题分开记录，有助于在 Clash 里决定是先补 CDN 分流规则，还是先确认 TUN 与 UDP 放行。

若尚未导入可编辑配置或不清楚当前策略组名称，建议先完成《Clash 订阅链接怎么用？机场配置文件一键导入完整教程》，再回到本文做域名级细化，避免改的是未生效的配置副本。

二、推荐排查顺序（先证据，后换节点）

下面顺序刻意把「换节点」放在中后段，先证明流量确实进了内核，且规则没有自相矛盾。

  1. 确认当前是系统代理还是TUN，以及 Discord 进程是否被客户端或安全软件加入「绕过」列表；必要时以连接日志为准。
  2. 复现Discord 更新失败时，在连接面板过滤 discord、discordapp、discordcdn、cloudflare 等关键字，观察每条连接的策略是 DIRECT 还是代理组，是否在同一秒内混用。
  3. 单独复现语音问题：关注是否有大量 UDP 连接、是否出现特定远端 IP 段超时；若 TUN 未启用或内核未处理 UDP，语音可能仍走直连却与信令出口不一致。
  4. 检查 DNS：是否启用 fake-ip、海外域名的上游是否可达；解析与连接目标不一致时，优先调整 nameserver-policy 或等价字段（以所用 Mihomo 文档为准）。
  5. 把日志里失败或长时间 pending的主机名分类为「网关与 REST」「附件与媒体 CDN」「更新与安装包」「语音与中继」，再在规则中显式指向同一策略意图或你拆好的两组。
  6. 在规则顺序已合理的前提下，再为语音与下载分别选择延迟方差小、UDP 表现稳定的节点，避免对同一主机名过于激进的自动切换。

端口占用、订阅拉取失败等通用问题，可对照《Clash 常见报错解决方案》；本文只聚焦 Discord Clash 场景下的多域名与实时流量。

三、Windows 上系统代理与 TUN：谁覆盖 Discord 全量流量

仅开启系统代理时，遵循系统代理的应用会把 HTTP(S) 流量送到 Clash 的 mixed 端口；但并非所有桌面程序都完整尊重系统代理，且UDP 语音通常不会自动走 HTTP 代理端口。于是常见状态是：文字与部分 HTTPS 正常，语音 RTC 仍按系统路由表直连，导致与信令所见的「对外 IP」不一致，从而被服务器侧判定为异常路径或遭遇 NAT 限制。

若你已确认文字频道正常而语音异常，可评估TUN 模式：在网卡层接管路由，使 TCP 与 UDP 更一致地经过内核分流。开启前建议阅读《Clash TUN 模式开启方法》，并在启用后回到连接日志，确认 Discord 相关连接确实经 Clash 显示，而不是仍落在 DIRECT。

若你从 Microsoft Store 安装 Discord 或相关依赖组件，且发现「浏览器已通、商店或 UWP 仍不走代理」，可另读《Windows 应用商店下载失败？用 Clash 为 UWP 开启回环代理完整步骤》，厘清 UWP 回环与 TUN 的差异，避免把商店隔离问题误判成节点故障。

无论采用哪种模式，都请在图形客户端里核对「当前加载的配置」与你在编辑器中修改的 YAML 为同一文件，避免出现「规则写了却不生效」的假象。新手可先按《Clash Verge Rev 完整配置教程》跑通基础链路，再叠加本文的 Discord 条目。

四、更新卡在 0%：优先对齐下载与 API 的主机名出口

检查更新时，客户端通常会请求版本清单、增量包或完整安装包，并可能经过多家CDN 边缘。若 discord.com 或网关类主机名已走代理，而实际承载安装包的边缘主机名被前置规则打成 DIRECT，就会表现为进度条长期为 0% 或偶发「正在启动更新程序」后无下文。

建议在复现时打开实时连接列表，按时间排序，关注长时间无响应或反复 TLS 握手的条目。若同一秒内既有代理命中又有直连命中，且直连侧对应下载域，就应把这些主机名并入与 API 相同的策略组，或单独建立 DISCORD_CDN 组并在规则里显式挂载。

与站内《Steam 商店与创意工坊打不开？用 Clash 分流 Steam CDN 与下载域名（实测步骤）》类似，核心思路都是以连接日志为准做 CDN 分流，而不是凭记忆堆后缀。Steam 与 Discord 的主机名集合不同，请勿照搬规则条目，只借鉴排查顺序。

五、语音掉线与 RTC：UDP、区域节点与「半代理」状态

语音通道除了依赖信令与 REST，还依赖UDP 到媒体中继的稳定路径。若信令走代理而 UDP 直连，可能遇到运营商对 UDP 的限速或 NAT 类型不匹配，表现为断续、爆音、延迟抖动或短暂掉线重连。

在 Mihomo 系内核上，是否处理 UDP、是否对游戏流量做绕过，取决于你的模式、策略与可能的进程规则。务实的做法是：先在日志里确认语音阶段的 UDP 连接是否出现、策略命中是否符合预期；若完全看不到 UDP 经内核，则说明流量仍绕开了当前模式，应回到上一节的 TUN 与系统路由讨论。

若你对传输协议与丢包特性不熟，可对照《Shadowsocks vs Trojan vs Hysteria2》，结合自身网络选择更抗波动的线路，再把 Discord 相关规则挂到对应策略组。语音对「测速榜第一名但抖动大」的节点往往比网页更敏感。

六、域名怎么归类：以日志为准，表格仅作自检方向

Discord 会调整边缘节点与主机名，任何静态清单都可能过期。下表给出排查时常见的分类方向，请始终以你本地连接日志与实际失败请求为准。

类型常见主机名方向（示例）配置提示
主站与网关discord.com、discord.gg与登录、邀请跳转保持同一策略意图，避免被宽泛「国内直连」误伤。
API 与附件discordapp.com、discordapp.net、media.discordapp.net 等方向REST 与媒体拉取常与更新检查共用出口；半通时表现为频道能开、图裂或更新卡死。
CDN 与边缘各类云厂商边缘、以日志为准的具体主机名CDN 分流先加观测到的 DOMAIN，再考虑后缀，避免波及其他业务。
语音与实时日志中出现的语音中继相关 IP/主机名、UDP 会话与 TCP 规则分开验证；必要时为语音单独策略组并选用 UDP 友好节点。

若你希望「浏览与更新」和「语音」使用不同节点，可在 proxy-groups 中定义两个组，例如 DISCORD_WEB 与 DISCORD_VOICE，再在规则里按主机名或进程分别挂载。名称变更后务必保持 YAML 自洽，防止配置无法加载。

七、DNS 与 fake-ip：半通状态从哪里来

启用 fake-ip 后，解析阶段与连接阶段的一致性更依赖内核行为与规则顺序。Discord 这类依赖大量子域与第三方边缘的产品，一旦部分请求在解析路径上不一致，就可能出现TLS 握手重试、资源长时间 pending 或更新进度假死。

务实的顺序是：先确认 DNS 上游本身可达、无污染；再考虑为 discord.com、discordapp.com 等后缀配置更明确的解析策略。若调整 DNS 后失败请求显著减少，说明瓶颈在解析链路，此时再微调 Clash 分流会更省力。

八、分流规则：示例片段（请替换策略组名）

下列 YAML 演示如何把常见 Discord 后缀显式指向代理组。将 PROXY 换成你的策略组名，并保证片段位于过于宽泛的 GEOIP 或 MATCH 之前，且不与订阅自带的「国内直连」条目冲突。

# Example only — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,discord.com,PROXY
  - DOMAIN-SUFFIX,discord.gg,PROXY
  - DOMAIN-SUFFIX,discordapp.com,PROXY
  - DOMAIN-SUFFIX,discordapp.net,PROXY

对日志中出现的具体 CDN 主机名，按需追加 DOMAIN 规则。若某后缀与其他站点共用，则需权衡是否改用更窄的匹配或进程级规则（视内核与客户端能力而定）。语音若主要体现为 IP 段而非域名，可能还需要结合路由与 TUN 文档中的高级选项，本文不展开具体内核开关，以免与版本差异冲突。

九、与订阅规则冲突时怎么收敛

许多订阅自带「国内直连、国外代理」的大块规则。Discord 部分主机名可能被误判为应直连，或相反被错误地套进不适合的代理组。处理方式是：把 discord 相关后缀写成靠前、更具体的规则，并在修改后观察连接日志是否整体统一到预期策略。

若你同时开启局域网共享给其他设备，注意网关与 DNS 是否一致指向运行 Clash 的机器，可参考《Clash 开启局域网代理：Windows 与 macOS 多设备共享完整步骤》，避免只有本机 Discord 正常、旁路设备仍异常。

十、节点选择：稳定与 UDP 表现优先于测速榜

文字与更新场景会并发大量短连接；语音则长时间占用 UDP。测速第一的节点未必适合后者：短时抖动会让媒体中继反复迁移，听感上就是断续与掉线。更稳妥的是选择一段时间内延迟方差小、UDP 丢包可控的线路，并避免对 Discord 相关主机名过于频繁地自动故障转移。

十一、小结：把「0% 与掉线」拆成可验证的主机名与协议清单

Discord 代理 Windows 场景下的Discord 更新失败与语音 RTC问题，多数是模式、DNS、规则顺序、UDP 与节点稳定性叠加的结果，而不是单一域名故障。按本文顺序，你可以在连接日志里看到明确命中记录，再决定要不要为 CDN 与语音分别建策略组。

当你希望少手写 YAML、用图形界面统一管理连接记录与策略切换时，成熟客户端在 Mihomo 内核上的整合度较高，也能降低配置错误率。相比零散工具组合，一体化体验在长时间语音与更新场景里往往更省心。→ 立即免费下载 Clash，开启流畅上网新体验