先判断：Discord 卡在哪一步
Discord 一直显示“正在连接”、消息发不出去，或者能正常聊天但语音频道没有声音，表面上看都是连接问题，背后的原因却可能完全不同。使用 Clash 时，故障通常出在四个环节：当前节点不可用或不适合实时通信、Discord 流量被规则分到错误策略、DNS 解析结果与代理路径不一致，以及语音所需的 UDP 流量没有被正确转发。
排查时先记下具体表现：应用是否能登录？文字频道能否加载？图片是否显示？语音频道是一直“RTC 正在连接”，还是已经进入频道但听不到声音？这些现象能帮助你区分网站访问、消息连接和语音传输问题。Discord 的文字消息和语音通话并不完全走同一条网络路径，因此“聊天正常”并不能证明语音代理也正常。
排查原则
一次只改一个设置，并在每次修改后重新连接 Discord。这样才能判断是节点、规则、DNS 还是 UDP 设置带来了变化，避免多个改动叠加后更难定位。
1先检查节点、模式与分流规则
不要一开始就重写整份配置。先在 Clash Verge、Clash Verge Rev 或其他客户端中确认代理已经启动，并检查当前策略组实际选中的节点。节点测速低延迟不代表一定适合 Discord：测速通常只能说明测试请求能连接，不一定能反映 WebSocket 长连接和语音 UDP 的稳定性。可以换一个已知可用、延迟较稳定的节点进行对照，并避免在测试过程中频繁切换地区或策略。
确认代理模式没有误设
在“规则”模式下，Discord 是否走代理取决于配置中的分流规则；在“全局”模式下，通常所有请求都会指向所选代理；“直连”模式则会跳过代理。建议先检查当前模式，再打开客户端的连接记录或日志，搜索 discord、discord.com 等关键字，观察相关请求最后匹配到的策略。如果命中 DIRECT，而你的网络无法直接访问该服务，文字连接就可能一直等待；如果命中代理组，也要确认该组当前确实选中了可用节点。
可以将 Discord 的域名规则放在较宽泛的规则之前，再把策略组名称改成你配置中实际存在的名称。下面只是规则写法示例，不能直接假设每份配置都含有 Proxy 这个策略组：
这里的 Proxy 必须替换成你配置文件里真实存在的策略组名称，例如某个“手动选择”或“节点选择”组。规则应放在最终兜底规则（如 MATCH）之前，否则后面的 Discord 规则不会有机会匹配。若客户端提供连接详情，也要确认实际请求命中了预期策略，而不是只看规则文本是否已经写入。
修改前先备份
不同订阅和客户端的配置管理方式并不相同。使用配置覆写、Merge 或脚本功能时，优先通过客户端提供的方式添加规则，不要直接覆盖订阅文件；订阅更新可能会重置手工修改。
2动手操作：按顺序定位故障来源
下面这组测试适合 Windows、macOS 和 Android 用户。客户端界面名称可能略有差异，但检查逻辑相同。操作期间先关闭其他代理软件或 VPN，避免多个网络接管组件同时修改路由；每个阶段都记录结果，尤其要区分文字连接和语音连接。
- 确认基础网络：暂时关闭 Clash，测试普通网页和其他常用服务是否正常。若整体网络都断开，先处理本地网络、系统代理残留或路由器问题，而不是先改 Discord 规则。
- 测试单个节点：重新启动 Clash，手动选择一个稳定节点，暂时不要使用自动测速组或负载均衡组。完全退出 Discord 后重新打开，观察登录和文字频道能否恢复。
- 检查请求命中：在 Clash 的连接页面或日志中查看 Discord 相关请求，确认它们进入预期代理组。若显示直连，检查规则位置和规则提供者是否已加载；若显示代理但失败，换节点做对照。
- 再测试语音：文字消息恢复后，加入一个语音频道并等待连接完成。若仍停留在 RTC 连接，或进入后没有声音，重点检查 UDP 支持、TUN 接管和节点转发能力，不要继续重复添加相同的域名规则。
- 逐项恢复设置：先保持代理模式和节点不变，再依次测试 DNS、TUN 和系统代理选项。每次只调整一项，恢复到修改前状态也属于有效测试，能够帮助排除配置因素。
如果浏览器版 Discord 正常而桌面应用不正常，可以先完全退出桌面客户端并重新启动，检查系统代理是否生效，也可短暂用浏览器进行对照。反过来，如果桌面版和浏览器版都卡住，问题更可能位于节点、规则或 DNS。不要仅凭一次测速结果判断节点可用；长连接稳定性最好通过保持连接一段时间、发送消息和加入语音频道来验证。
3文字正常但语音失败：检查 UDP、DNS 与 TUN
语音通话重点检查 UDP
Discord 语音连接对实时传输的要求不同于普通网页。网页文字和图片通常通过 TCP 或基于 TCP 的连接完成，而语音通话还可能使用 UDP。即使代理节点的网页访问没有问题，如果节点本身不支持 UDP 转发，或客户端没有将相关流量交给内核处理，Discord 也可能一直显示 RTC 连接、反复重连，或者进入频道后听不到声音。
先查看节点或订阅说明是否支持 UDP，再检查客户端内核和对应节点配置是否启用了 UDP 转发。若使用 Mihomo，应确认所使用的节点类型和上游服务器确实支持 UDP；仅在配置里添加一个 UDP 开关，无法让不支持 UDP 的服务器自动获得转发能力。不同协议、订阅格式和客户端对字段的处理可能不同，应以实际生成的配置和连接日志为准。也不要把“UDP 开启”当成必然修复：本地网络、防火墙或节点侧限制都可能继续阻断语音。
DNS 异常时先确认解析路径
DNS 解析异常可能导致 Discord 域名无法解析、解析到不可达地址，或因本地 DNS 与代理出口不一致而造成连接不稳定。可以先重新载入配置、刷新 Clash 的 DNS 缓存（若客户端提供此操作），并确认 DNS 模块是否启用。使用 fake-ip 或 redir-host 等增强模式时，需确保客户端的 DNS 接管、系统网络设置和现有规则彼此兼容；切换模式可能影响其他应用，不建议把它作为第一步。
排查期间可以观察日志里是否出现域名解析失败、超时或反复重试。如果只对 Discord 域名有问题，可先对照不同节点下的解析及连接结果；如果许多网站都无法解析，更可能是 DNS 服务器、局域网设置或 DNS 接管冲突。不要在没有判断的情况下同时填入多个互不相关的 DNS 地址，也不要把某个公共 DNS 地址当成必然可用的解决方案。
系统代理不够时再测试 TUN
桌面客户端的系统代理通常只影响遵循系统代理设置的应用；若 Discord 桌面版的部分网络请求没有按预期走系统代理，可以测试 TUN 模式。TUN 会通过虚拟网卡接管更多系统流量，但它需要客户端获得相应权限，并且可能与其他 VPN、虚拟网卡、企业安全软件或防火墙冲突。开启前先关闭其他网络接管工具；开启后若连接反而变差，立即关闭 TUN 并恢复原设置，再检查日志和系统权限。
Android 上 Clash 类客户端通常需要使用系统 VPN 接口接管流量，因此一般不能同时让另一个 VPN 应用也占用该接口。遇到 Discord 语音失败时，应先确认当前 Clash 客户端确实处于运行状态、系统 VPN 授权没有被撤销，并排除省电策略或后台限制导致的断连。不同平台的 TUN 和 VPN 工作方式不同，桌面端的操作不能直接照搬到手机上。
根据表现快速缩小范围
网页与文字都失败，优先查节点、规则和 DNS；只有语音失败，优先查 UDP 支持和防火墙；仅桌面应用失败，检查系统代理或 TUN 接管；切换节点后短暂恢复又掉线，则重点观察节点稳定性和连接日志。
常见问题
为什么浏览器能打开 Discord，桌面版却一直连接中？
两者可能采用不同的代理方式，也可能命中不同规则。浏览器可能遵循系统代理，而桌面客户端的部分请求未被同样接管。先在 Clash 连接记录里对照两者的 Discord 请求，再检查规则命中；如果系统代理无法覆盖相关请求，可在确认没有其他 VPN 冲突后测试 TUN。
文字消息正常，语音频道仍然没有声音，怎么办？
这通常说明基础连接已经建立，但语音传输路径仍有问题。检查节点是否支持 UDP、Clash 是否接管 UDP 流量，以及防火墙是否拦截 Discord。换节点测试时一次只换一个节点，并确认不是客户端静音、频道权限或输入输出设备选择错误。
添加 Discord 规则后仍然没有改善，最可能漏了什么？
先确认规则中的策略组名称确实存在，并且规则位于兜底规则之前；随后查看连接详情，判断请求是否命中该规则。还要考虑实际问题可能是 DNS、节点质量或 UDP 支持，而不是域名规则缺少一行。规则生效只代表流量被分配到某策略，不代表该策略对应的节点一定可用。
要不要直接重置 Clash 配置或重装客户端？
一般不必。优先备份配置并按节点、规则、DNS、UDP、TUN 的顺序逐项测试。只有在配置明显损坏、客户端无法加载内核，或排查确认存在软件故障时，才考虑重置或重新安装；操作前保留订阅信息和自定义规则，避免丢失可恢复的设置。
如果仍未解决，整理故障时间、客户端和内核版本、运行模式、所选节点类型，以及已脱敏的错误日志，再联系节点服务商或客户端维护者。分享日志前务必删除订阅链接、服务器地址、账号标识等敏感信息。