典型現象：文字勉強有、語音一直「連線中」或秒斷

許多讀者在國內、宿舍、公司或校園網路使用 Discord 時，遇到兩類問題：一是客戶端或網頁長時間轉圈、無法登入或載入頻道；二是文字與圖片尚可，一進語音頻道就出現延遲飆高、同伴聽不到你、或數秒後自動斷線。第二類尤其容易被誤判成「節點太慢」，但實務上更常與UDP 沒有跟著代理一起走、或 WebRTC／TURN 相關連線被規則漏接有關。

與本站以「商店／下載 CDN」為主的遊戲平台文章不同，Discord 同時依賴多種連線型態：HTTPS 承載帳號與文字，語音通道則大量使用 UDP，並可能經由中介伺服器轉發。若你的 Clash 僅以系統代理讓瀏覽器走 SOCKS／HTTP，而應用程式其餘流量仍嘗試直連，就會出現「看得到訊息、聽不到聲音」的割裂體感。以下先建立正確心智模型，再談UDP 分流與代理規則怎麼接起來。

為什麼 Discord 特別在意 UDP 與 TURN？

語音通話為了低延遲，普遍採用 RTP／WebRTC，底層以 UDP 為主；當端到端無法直接穿透 NAT 時，會改走 TURN 中繼。這代表：只確保 discord.com 這類網域走代理仍可能不足，因為實際語音可能指向其他主機名、IP 段或動態協商的埠位。若核心或規則層對 UDP 支援不完整、或被「直連兜底規則」更早命中，語音封包就可能落到錯誤的出口或直接失敗，表現為語音斷連或無限重連。

另有一點常見誤解：把責任全推給「延遲」。延遲過高確實傷害體驗，但若封包根本沒進入你預期的策略群組，換再多節點也無法修復結構性問題。因此排查順序應該是先確認「這筆 UDP 連線有沒有被核心看見、規則有沒有命中、落點是否為代理」，再評估節點品質與區域選擇。

覆蓋面優先：系統代理、tun 與 UDP

在 Clash Meta（常與 Mihomo 核心並稱）環境下，若你希望 Discord 桌面版與瀏覽器行為一致，通常需要足夠的流量覆蓋。僅開啟「系統代理」時，部分程式仍可能繞過代理直連；語音所使用的 UDP 更容易落在這類路徑。需要廣覆蓋時，可依 Clash TUN 模式詳解 讓流量由虛擬網卡進入核心，再交由規則分流。實務上許多「語音死活走不進代理」的案例，在啟用 tun（並確認防火牆允許）後會明顯改善。

不同用戶端與作業系統細節各異，請以你所用的圖形介面說明為準；核心重點是：確認 UDP 不會在規則之前就偏離核心。若同時使用公司 VPN 或第二張虛擬網卡，也要留意路由優先順序是否讓 Discord 流量沒有進到 Clash。

代理規則：讓 Discord 相關流量落到同一出口

分流規則的寫法與順序決定每一筆連線要問哪個策略群組。Discord 相關主機名會隨產品更新而變動，因此本文不給「永久不變」的清單，而是提供可維護的方向：在規則表前段用 DOMAIN-SUFFIX／DOMAIN-KEYWORD（關鍵字請謹慎使用，避免誤傷）接住已知核心網域，並確保更早的 GEOIP 或過寬的 DIRECT 不會先搶走命中。

若你尚未建立「境內直連、境外代理」的分層，建議先閱讀 Clash 分流規則配置教學，理解由上而下匹配與 MATCH 兜底；再回到本文把 Discord 家族規則插到正確深度。搭配 連線日誌與規則命中，你可直接觀察「UDP、目標位址、命中規則、策略落點」是否一致。

下面是一段示意用的 YAML 片段（欄位請對照你的核心版本與訂閱模板；註解使用英文以利維護）。實際網域請以連線紀錄為準並定期更新：

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

rules:
  # Discord family — verify hostnames in your logs (app + region may differ)
  - DOMAIN-SUFFIX,discord.com,PROXY
  - DOMAIN-SUFFIX,discordapp.com,PROXY
  - DOMAIN-SUFFIX,discord.gg,PROXY
  - DOMAIN-SUFFIX,discord.media,PROXY
  - DOMAIN-SUFFIX,discordcdn.com,PROXY
  - DOMAIN-KEYWORD,discord,PROXY

  # Rule-sets and other rules follow...

再次提醒：DOMAIN-KEYWORD 覆蓋面大，可能誤傷與 Discord 無關但名稱碰巧含字串的流量，建議作為過渡或補洞手段，長期仍以觀察到的主機名補上更精準的 DOMAIN／DOMAIN-SUFFIX 規則為佳。

語音區域與節點：穩定比「延遲顯示數字」更重要

Discord 會依伺服器區域與後端調度選擇語音中繼路徑；若你使用的出口與伺服器所在區域跨度很大，即使延遲數字看起來勉強可接受，UDP 抖動與掉封包仍會造成聽感上的卡頓與斷續。實務上建議在客戶端內檢視語音區域設定，並在 Clash 策略群組中優先選擇與該區域路徑較一致、丟包率低的節點，而不是盲目追求最低 ping。若你與友人同頻道，可請對方也確認彼此是否都落在同一種網路與出口條件，排除單側 NAT 或雙重代理造成的語音單通。

部分機場節點對 UDP 支援度或頻寬策略不同；若連線日誌顯示 UDP 已正確命中代理但仍頻繁斷線，可優先用同一套規則切換不同節點或伺服器地區做對照實驗，縮小問題是「節點相容」還是「規則／覆蓋面」。

實務排查清單（建議按順序）

  1. 在連線紀錄中確認 Discord 相關目標是否命中預期的 PROXY（或自訂群組），特別留意是否有 UDP 仍落在 DIRECT。
  2. 若僅文字通、語音不通，優先懷疑 UDP／tun 覆蓋，而不是先換十個節點。
  3. 變更 DNS 模式（如 fake-ip／redir-host）或上游 DNS 後，重啟 Discord 讓長連線重建，避免把短暫重連當成規則失效；細節可與 fake-ip 與 redir-host 對照一併閱讀。
  4. 對照瀏覽器版與桌面版：若僅其中一邊異常，檢查是否一邊走系統代理、另一邊走獨立設定或未覆蓋 UDP。
  5. 確認本機防火牆、安全軟體或公司政策是否攔截虛擬網卡或指定 UDP 埠位。
⚠️
合規與風險提醒 請在所在地法令、校園／公司資訊政策與服務條款允許的範圍內使用代理與通訊服務；本文僅從網路工程角度討論連線與設定，不提供任何違法用途的指引。請妥善保管訂閱與設定檔，並僅從可信來源安裝用戶端。

結語：把語音穩定當成「規則＋覆蓋＋節點」的組合題

Discord Clash 共能不能只靠一句「開全局」就完結；語音場景裡，UDP 分流是否完整、代理規則是否攔到對的主機名、以及語音斷連時能否從日誌還原真相，才是能否長期維運的關鍵。相較於四處搜尋來路不明的安裝包，先從本站取得對應平台用戶端，再回到設定檔逐步對齊 tun、規則與策略群組，通常更能同時顧及安全與除錯效率。延伸閱讀可見 Clash 說明與教學文件。→ 立即免費下載 Clash，開啟流暢上網新體驗