Discord 连不上或语音中断？用 Clash 开 TUN 并分流相关域名实测步骤（2026）

1. 为什么仅系统代理不够：进程、UDP 与域名三条线

系统代理主要影响「尊重系统代理环境变量或 WinHTTP/macOS 网络代理」的那一类进程，典型是 Chromium 内核浏览器、部分用系统网络栈下载更新的应用。但 Discord 桌面端与许多游戏一样，会用自己的网络栈发起连接；在部分环境下它不会自动走你在 Clash 里勾选的系统代理，于是出现「浏览器里 discord.com 能打开，客户端却一直Connecting」的割裂现象。第二条线是UDP：语音通道大量依赖 UDP 数据报，而传统 HTTP/SOCKS 系统代理路径对 UDP 的覆盖往往不完整或依赖额外转发能力。第三条线是域名：即便你全局开了 TUN，若 Clash 分流规则把某些 discordapp 或网关主机误送到 DIRECT，在受限网络里仍会表现为间歇断连。三条线要一起看清，才不会把问题简单归结为「换个节点试试」。

因此更稳妥的切入顺序是：先用连接日志确认Discord 进程产生的目标主机名与协议，再判断是否需要 TUN 把流量纳入内核，最后用域名分流把这些主机统一送到延迟稳定、出口一致的目标策略组。Windows 上若你还遇到 UWP 或回环相关边缘情况，可与 TUN 与进程规则专篇 对照阅读；本文侧重 Discord 常见主机名与 语音 UDP 的验证方法。

2. 典型症状：网页能开、客户端异常、语音掉线

在代理已开启的前提下，若出现「网页版能浏览频道文字，桌面端卡在启动或更新」「能进服务器但一进语音频道就掉线或只有单向声音」「语音延迟图表剧烈波动」等，应优先怀疑：客户端流量未走 Clash、UDP 未进入 TUN 或未命中正确策略、或部分 CDN 主机仍直连。与 Steam 商店分流 类似，Discord 也会把静态资源、附件与实时信令拆到不同域名；差别在于 Steam 更偏下载大块 TCP，而 Discord 的实时语音对 UDP 与时延抖动更敏感，规则漏一条就可能只在语音场景暴露。

另一类症状是「登录与文字消息正常，语音却频繁提示 RTC Connecting」：这往往说明HTTPS 信令已走代理，但媒体或 RTC 相关 UDP仍走了直连或被防火墙干扰。此时仅增加几条 DOMAIN 可能不够，需要确认 Clash TUN 是否对该进程生效，以及内核是否允许相关 UDP 出口。请遵守当地法律法规与所在网络的使用政策；本文只讨论技术路径与配置排错。

3. 建议在规则里覆盖的 Discord 与 CDN 后缀

下列后缀在 2026 年仍常见于 Discord 客户端、网页端与语音网关相关请求；实际产品迭代会引入新主机名，因此务必以你本机连接日志里的真实 Host / SNI为准，把本节当作起点而非封闭清单。若订阅规则集已含 GEOSITE 或社区维护的 Discord 分类，可与自定义段落组合使用：自定义靠前表达明确意图，大类在后兜底。请把 Discord 相关规则放在过于宽泛的直连、广告拦截或超大 GEOIP 规则之前，顺序细节见 高级规则分流指南。

• discord.com、discord.gg（站点、邀请与部分 API 路径）
• discordapp.com、discordapp.net（客户端、网关与附件常见承载，具体子域以日志为准）
• discord.media、discordstatus.com（媒体与状态页相关请求可能出现）
• cdn.discordapp.com、media.discordapp.net 等 CDN 主机：头像、表情与语音外设资源加载失败时，优先核对这些是否误直连

不建议用过于粗暴的 DOMAIN-KEYWORD,discord 一刀切：容易误伤无关站点。更稳妥是后缀 + 日志补全：某次客户端更新后若只余少数主机名未命中，再在本地覆写里追加即可。

4. 专用策略组与 mihomo 域名分流示例

建议单独建一个面向即时通讯与低延迟语音的 select 或 url-test 策略组（示例名：💬 Discord），只放入UDP 表现稳定、与你账号常用区域一致的节点。将上一节后缀显式指向该组后，再打开客户端执行一次「冷启动 → 登录 → 加入语音频道」的完整路径，观察日志是否仍有请求落到 DIRECT 或错误策略组。若尚未完成基础安装与订阅导入，可先按 订阅导入教程 建立连通，再叠加本节覆写。

proxy-groups:
  - name: "💬 Discord"
    type: select
    proxies:
      - NODE-SG-01
      - NODE-JP-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,discord.com,💬 Discord
  - DOMAIN-SUFFIX,discord.gg,💬 Discord
  - DOMAIN-SUFFIX,discordapp.com,💬 Discord
  - DOMAIN-SUFFIX,discordapp.net,💬 Discord
  - DOMAIN-SUFFIX,discord.media,💬 Discord
  - DOMAIN-SUFFIX,discordstatus.com,💬 Discord
  # Append hosts seen in connection logs (CDN edges, voice regions)
  # ... GEOIP / MATCH below

mihomo 与 Clash Meta 系内核在规则匹配与日志字段上较成熟；若你使用图形客户端，请确认覆写保存后内核已重载，避免「改 YAML 了但界面未应用」的假阴性。

5. 开启 Clash TUN 后与语音 UDP 路径对齐的注意点

在确认域名分流已写全的前提下，若语音仍异常，下一步通常是开启 Clash TUN（或客户端等价的全局虚拟网卡模式），让操作系统层流量进入内核，再由内核按规则分发。这样UDP 与不走系统代理的进程更容易被统一接管。注意与学校或公司802.1X、透明代理、零信任客户端等并存时，可能出现多虚拟网卡抢路由的情况；此时应先关闭冲突软件做对照，再逐项恢复。

部分客户端提供「仅代理 TCP」或「绕过局域网」等选项；若你遇到「文字正常、语音掉线」，请核对是否无意中限制了 UDP 或排除了 Discord 进程。Windows 11 用户若刚接触 Verge 系界面，可与 Windows 11 Verge Rev 首次配置 对照，先分清系统代理与 TUN 的验证顺序，再进入语音专项测试。

6. DNS、Fake-IP 与 Sniffer：登录正常却不能稳定说话

在 Fake-IP 模式下，本地会先得到虚拟地址，再在真实连接阶段还原域名并匹配规则。若 DNS 由浏览器 DoH、路由器或系统单独绕过 Clash，则可能出现解析与连接策略不一致：HTTPS 信令走了代理，后续 UDP 却按另一套解析结果直连。修改 DNS 或 Fake-IP 段落后，建议清理本机 DNS 缓存并重启内核再测。

对 HTTPS 流量，Sniffer 可在缺少早期域名信息时，通过 TLS SNI 补全匹配依据；对「已建立连接但先前按 IP 走错组」类问题有对照价值。示例（请按你内核版本文档调整字段名与端口列表）：

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
  # See upstream docs for skip-domain / override-destination

语音大流量场景下，嗅探会带来额外 CPU 开销；一般做法是先保证域名规则写全与 TUN 生效，仅在仍出现异常时短期打开嗅探对照。

7. 可复现的连通与语音测试步骤

建议按固定顺序做2026 可复现测试，避免一次改多个变量。第一步：仅开系统代理，在浏览器打开 discord.com 与状态页，记录是否正常。第二步：开启 Clash TUN，完全退出并重启 Discord 桌面客户端，观察启动阶段是否仍卡在更新或登录。第三步：打开连接日志，过滤进程名或目标端口，确认 discordapp、discord.gg 等是否命中 💬 Discord 策略组且无关键请求直连。第四步：进入任意服务器的语音频道，保持两分钟，观察延迟图表与是否出现单向无声。第五步：若仍异常，临时切换到另一同区域节点重复第四步，以区分「规则问题」与「单节点 UDP 质量」。

移动端可额外对照：同一 Wi‑Fi 下桌面端与手机端是否表现一致；若仅某一端异常，往往说明该端未走 TUN 或未安装证书类组件（如部分抓取 HTTPS 的环境）。测试完成后把新增主机名写回本地规则，形成你自己的最小可用集合。

8. 排查清单（2026 实测向）