📖 教學 ⏱ 約 17 分鐘閱讀

Discord 語音斷續：Clash UDP 分流與直連例外分步實測

許多人在電腦上開著 Clash（含 Clash Meta／Mihomo）同時掛 Discord 語音頻道，最常抱怨的不是文字聊天，而是語音一陣一陣、像被切斷、或乾脆掉出頻道。這類症狀往往同時牽涉UDP、RTC（即時通訊）路徑、以及分流規則是否把語音封包送去不適合的節點。本篇從「使用者真正想搜到的答案」出發：先判斷是節點品質、UDP 轉發、還是規則把流量送錯出口，再給可複製的直連或固定節點規則起手式，並用連線日誌做分步實測收斂問題。若你也在意「為什麼只有語音怪、瀏覽器卻正常」，這篇會把檢查順序寫清楚，避免你在設定檔裡盲目堆規則。

先把症狀翻成技術語：Discord 語音到底在用什麼？

Discord 的文字與圖片多數走常見的 HTTPS（TCP 443），而語音通話本質上更接近即時串流：需要穩定的UDP路徑、較低的抖動（jitter），以及對 NAT 型態友善的RTC握手。當你開啟 Clash 並使用規則分流時，只要「語音相關」的連線被送去延遲高、丟包嚴重、或根本沒有好好轉發 UDP的代理出口，你聽到的就會是斷續、機器人聲、或頻繁重連。反過來，若 Discord 桌面程式沒有完整被核心攔截（例如只吃系統 Proxy 的程式沒走代理、但語音卻走了另一條路），也會出現「文字正常、語音怪」的割裂感。

因此，排查時請在心裡分成兩條軸：① 流量有沒有進核心；② 進核心之後，UDP／RTC 被哪一條規則接走。這和單純「換一顆節點」不完全相同——有些節點對 TCP 網頁很穩，但對語音 UDP 就是容易抖；也有些訂閱規則很寬，會在細粒度規則之前就提前命中，讓你以為自己已經幫 Discord 寫了例外，實際上語音仍被送去預設群組。

為什麼它和 Steam／Epic 商店類問題不一樣？

本站已有Steam／Epic 在 Clash 分流專文，核心痛點偏向大檔下載、CDN 與商店 API，TCP 比例高、對吞吐與路由正確性敏感。Discord 語音則更偏向低延遲 UDP與連線狀態維持：同樣叫「卡」，背後可能是抖動而不是頻寬不足。若你把遊戲平台的規則原封不動套到 Discord，有時能「蒙到」一部分主機名稱，但語音仍可能走漏，因為 RTC 還會涉及不同子網域、媒體伺服器、以及本機對外埠位區間與供應商調度。

另一個易混淆點是視訊會議：Zoom／Teams 分流與 DNS 排查同樣強調規則與 DNS，但企業視訊的網域集合與客戶端行為和 Discord 不同；請不要直接把該篇的網域清單貼過來當作 Discord 的「萬靈丹」，除非你已在連線日誌裡確認命中主機一致。

第一步：確認 Discord 的流量「真的被 Clash 看見」

在 Windows 或 macOS 上，若你只開系統 Proxy，部分程式仍可能略過系統代理，或只把部分連線交給核心。Discord 桌面版常見狀況是：介面與文字走你預期的路徑，但語音模組的連線型態不同，導致你怎麼改 YAML 都不像有效果。實務上會建議優先檢查你是否啟用TUN／透明代理或客戶端提供的等效能力，讓「不吃系統 Proxy 的 UDP」也納入分流；細節可對照Clash TUN 模式深度解析，先把流量覆蓋範圍做對，再談規則怎麼寫。

驗證方式很務實：開啟客戶端的連線日誌或即時連線列表，進入一個語音頻道說幾句話，觀察是否出現與 discord 相關的主機名稱、以及協定欄位是否出現 UDP。若你完全看不到 Discord 相關連線，代表問題不在「規則寫錯」，而在「流量沒進核心」；此時應回到模式與權限設定，而不是繼續堆 DOMAIN-SUFFIX。

第二步：判斷是不是「節點不適合 UDP／RTC」

當日誌顯示語音相關連線確實命中某個代理群組，下一步是評估該出口對 UDP 的體感。某些線路對 TCP 網頁表現良好，但對即時語音就是容易抖；也有環境會限制或劣化 UDP 轉發。此時你可以做一個低成本的 A／B 測試：暫時把與 Discord 相關的規則改成直連（DIRECT），若語音立刻穩定，幾乎可以直接判定「瓶頸在代理鏈路或該節點對 UDP 不友善」，而不是 Discord 本身壞掉。

當然，直連並不是每個網路環境都可行：有些人直連 Discord 會遭遇業者路由或區域性限制，此時反而需要一條對 UDP 友善的節點。重點是：不要用「延遲最低」當唯一指標，語音更看重抖動與丟包。若你發現訂閱本身就不穩，請先回到訂閱連結常見問題釐清上游狀態，否則你會一直在客戶端內無效切換。

第三步：用規則把 Discord「接到對的出站」

在確認流量有進核心、且你已理解「直連 vs 代理」的對照結果後，才把精力放在 YAML 規則。下列是一段教學用起手式（請把 DISCORD-OUT 換成你實際存在的群組名稱；若要直連，改成 DIRECT 即可）。Discord 後端與子網域會隨時間調整，請務必搭配日誌補齊漏網之魚，而不是背一份「永久正確」清單。

# Example starter rules — extend with hostnames from your connection logs
rules:
  - DOMAIN-SUFFIX,discord.com,DISCORD-OUT
  - DOMAIN-SUFFIX,discord.gg,DISCORD-OUT
  - DOMAIN-SUFFIX,discordapp.com,DISCORD-OUT
  - DOMAIN-SUFFIX,discordapp.net,DISCORD-OUT
  - DOMAIN-SUFFIX,discord.media,DISCORD-OUT
  - DOMAIN-SUFFIX,discordcdn.com,DISCORD-OUT
  - DOMAIN-SUFFIX,discordstatus.com,DISCORD-OUT
  - MATCH,Main

說明：① 規則由上而下匹配，先命中先贏；若訂閱內建規則很寬鬆，可能會在你自訂的 Discord 條目之前就接走流量，請把 Discord 相關條目放在會提前命中的位置。② DISCORD-OUT 可以指向 DIRECT、也可以指向一個只放「低延遲、UDP 穩」節點的 select 群組；若你還不熟悉群組命名與策略差異，可先讀Clash 代理群組（proxy-groups）完全指南。③ 最後的 MATCH 請依你的設定檔調整，不要複製貼上後忘記改。

進階：用「程式名稱」縮小誤傷（Windows／支援環境）

若你希望只讓 Discord 客戶端走特定策略、避免過寬的網域規則影響其他軟體，可在支援的程序規則環境下，將可執行檔名稱作為補強條件。這對「同一台電腦同時開很多遊戲與通訊軟體」的使用者特別實用。實務限制是：客戶端更新後檔名或路徑若變動，規則可能需要跟著維護；寫法與注意事項見自訂規則教學：讓指定 App 走指定節點。

UDP 與「更細的條件」：什麼時候要用到 AND／NETWORK？

在 Clash Meta／Mihomo 系譜中，有時候僅靠 DOMAIN-SUFFIX 仍不足以描述「只要語音 UDP」這種需求，因為同一主機可能同時承載不同型態流量。進階使用者會考慮以邏輯規則把 NETWORK,UDP 與網域或埠位條件組合，盡量縮小影響面。必須強調：過寬的 UDP 埠區間規則很容易誤傷其他應用程式；若沒有足夠的日誌依據，寧可先用網域／程序規則收斂，再逐步加條件。

下方是一段示意寫法（需核心版本支援對應規則運算子；請以你實際版本文件為準），重點在於展示「把 UDP 從 TCP 分開思考」的方向：

# Advanced example (Mihomo-style) — verify support on your build before use
rules:
  - AND,((NETWORK,UDP),(DOMAIN-SUFFIX,discord.gg)),DISCORD-OUT
  - DOMAIN-SUFFIX,discord.gg,DISCORD-OUT

若你啟用 TUN 並搭配 QUIC／嗅探相關功能，少數環境會遇到「解析看起來對、連線行為卻怪」的現象；此時可交叉閱讀Clash Meta 嗅探與分流例外，避免把單純的節點問題誤判成規則問題。

DNS、fake-ip 與「RTC 握手看起來不穩」

與其他情境相同，DNS 決策會影響域名如何進入規則匹配流程。使用 fake-ip 時，本機看到的位址可能與傳統解析不同；若系統、路由器或第三方 DNS 軟體同時介入，可能出現規則命中與實際連線目標不一致的落差。對 Discord 來說，這種落差有時表現為「能登入、文字能刷、語音卻反覆重連」。建議在排查期間一次只保留一套 DNS 決策，並用日誌對照主機名稱與出站是否符合預期。

若你想先建立「規則型代理 vs 全隧道 VPN」的心智模型，也可讀Clash 與 VPN 有什麼差別？，避免用全隧道方式長期壓測，反而讓語音更難定位瓶頸。想把安裝、訂閱與模式選擇一次串起來核對，可搭配本站Clash 使用教學逐步對照自己的環境。

建議分步實測順序：一次只改一個變因

為了避免越改越亂，建議用下列順序做可重複的驗證。每一步都只改一個變因，並在語音頻道內用固定說話節奏測試十到二十秒，觀察是否仍斷續。

  1. 確認流量進核心：開日誌進語音頻道，是否看得到 Discord 相關連線與 UDP。
  2. 確認規則命中：檢查實際命中的規則名稱與群組，排除「被更寬鬆的訂閱規則提前接走」。
  3. 對照直連：暫時將 Discord 出站改為 DIRECT，若語音立刻穩定，偏向節點或 UDP 轉發問題。
  4. 對照固定節點：改接到一個你已知 TCP／UDP 都穩的群組，觀察抖動是否下降。
  5. 檢查 DNS 與 fake-ip：觀察是否有反覆重試、異常位址或解析來源不一致。
  6. 縮小環境：分別在住家 Wi‑Fi、行動熱點測試，判斷是否為特定 ISP 路由或 IPv6 行為造成。

合規與風險提醒

代理工具可以改變連線路徑；上游節點供應商亦可能在其伺服器側觀察流量型態。請遵守服務條款與適用地區規範，並留意帳號安全。本文僅討論網路路徑與設定思路，不提供任何規避法律、違反服務條款或侵害他人權益的操作指引。

若你需要查核開源授權、原始碼或回報問題，可自行前往專案頁；一般使用者取得安裝檔與更新，建議優先遵循本站下載頁所整理的方式，避免誤用來路不明的安裝包。

常見問題

我把 Discord 相關網域都代理了，語音還是斷，為什麼？

請先用日誌確認「語音當下」實際命中的主機名稱與協定。若仍有大量 UDP 連線落在預設群組，代表你的網域清單沒蓋到實際媒體伺服器，或規則順序被訂閱規則蓋掉；也可能是節點對 UDP 不友善，需要改走直連或更合適的群組。

為什麼一關 Clash 語音就正常？

關閉 Clash 等於回到另一套網路路徑，通常代表瓶頸發生在代理鏈路、UDP 轉發、或規則把流量送去不適合的出口。建議用本文的分步實測把原因拆開，而不是長期依賴「關掉就好」。

手機上的 Discord 也能用同一份邏輯嗎？

觀念相同，但攔截方式與客戶端能力因平台而異。部分 Android 方案可用套件識別輔助分流；核心仍是先確認流量是否進入你的代理核心，再用日誌收斂網域與出站。

整體來說，要把 Discord 語音在 Clash 環境下調到「可長期使用」的狀態，關鍵通常是：先讓 UDP／RTC 流量被正確看見，再用分流規則把 Discord 接到直連或真正適合即時語音的節點，並用連線日誌持續補齊主機名稱與檢查命中順序。這比盲目全域代理更可控，也比單純「換節點」更容易定位根因。若你正在找能長期承載規則型代理與 TUN 流程的客戶端，不妨從本站取得對應平台版本，實際感受規則命中與切換是否順手——→ 立即免費下載 Clash，開啟流暢上網新體驗。