為什麼要先分開看「文字」與「語音」？

在開始改規則之前，值得花一分鐘建立正確心智模型：Discord 用戶端與網頁版要載入介面、同步訊息、顯示大頭貼與嵌入內容，主要仍是基於 TLS 的 HTTPS 連線，走 TCP 為主；當你加入語音頻道，客戶端會建立即時通訊，核心技術通常是 WebRTC，並高度依賴 UDP 做媒體傳輸與穿透。換句話說，你在 Clash 裡「看得到文字」只代表：至少有一部分主機名與 TCP 443 類型的路徑被正確帶到了代理或預期出口。

語音是否穩定，還取決於：UDP 是否進入同一套分流邏輯、是否被錯誤直連到不適合的網路環境、以及你的節點是否完整支援 UDP 轉發。因此排查時請避免一開始就「換十個節點試手氣」，而是先確認規則命中與模式是否讓語音流量真的進了 Clash。若你同時遇到「部分網站解析怪、內網域名異常」，可延伸閱讀《Clash DNS：Fake-IP 與 Redir-Host 排查》，避免 DNS 與規則兩邊打架。

第 1 步：補齊 Discord 相關網域，別讓 discord.gg 落在規則死角

多數使用者會先注意到 discord.com，但實務上還會遇到邀請連結、重新導向與 API 端點分散在不同後綴的情況；其中 discord.gg 是常見的短網址與邀請入口。若你的訂閱規則集沒有涵蓋這個後綴，或你的自訂規則順序讓請求先命中了過寬的 GEOIP／MATCH，客戶端可能出現「點了邀請卻轉圈」「語音房進不去一半」這類難以描述的症狀。

在 Clash／Clash Meta（mihomo）中，請牢記：規則由上而下匹配，第一條命中即停止。建議為 Discord 建立獨立的策略組（例如命名為「Discord-Voice」或併入既有的「國際服務」組，但務必可識別），並在兜底規則之前加入後綴級條目。下列為常見骨架（策略組名請替換為你設定檔中實際存在的名稱）：

rules:
  - DOMAIN-SUFFIX,discord.com,Discord
  - DOMAIN-SUFFIX,discord.gg,Discord
  - DOMAIN-SUFFIX,discordapp.com,Discord
  - DOMAIN-SUFFIX,discordapp.net,Discord
  # Add CDN or client-specific hosts seen in your connection logs if needed
  # ... your other rules ...
  - GEOIP,CN,DIRECT
  - MATCH,手動選擇
與 Rule Providers 並存時 若你載入了大型第三方規則集，請確認合併後的實際順序：被放在較上方的規則集若已將流量導向別組，你後面才手寫的 DOMAIN-SUFFIX 可能永遠不會被評估。必要時把手寫條目改到訂閱規則之前，或在 Rule Providers 使用覆寫段落。

實務上還有一個常見誤區：以為「全域代理」就必然覆蓋所有主機名。若客戶端或系統層對特定程式繞過代理、或 DNS 解析路徑與 Clash 設定不一致，仍可能出現部分連線未進入核心。此時應以連線日誌中的真實 SNI／Host 為準補規則，而不是只憑印象加域名。

第 2 步：確認 UDP 有進代理管線，且節點真的支援 UDP

語音斷續時，第二個要檢查的是 UDP。許多代理協定與節點組態預設偏重網頁瀏覽場景，若服務端未開啟 UDP、或用戶端未允許 UDP 轉發，WebRTC 可能會反覆降級、重試，表現為聲音卡頓或頻繁重新連線。

你可以在客戶端檢視當前選用節點的說明：是否標示支援 UDP、是否適合遊戲／語音類場景。若你使用依賴傳輸層的協定組合，請確認伺服器端與用戶端設定一致，避免「TCP 網頁正常、UDP 媒體全掛」的半套狀態。這一步與「規則寫對沒」是兩件事：規則決定流量走哪個策略組，節點與協定決定該組能不能扛住 RTC。

若你同時使用訂閱來源提供的多組節點，建議為 Discord 固定一個延遲穩定、丟包低的成員，並避免讓語音流量落在會頻繁自動切換、但對 UDP 不友善的測速策略上——自動選路有時對網頁很好，對即時語音卻不一定。

第 3 步：比較 TUN 與「僅系統代理」——UDP 常卡在這裡

在桌面作業系統上，許多使用者習慣開啟「系統代理」或僅讓瀏覽器走 HTTP 代理。這對一般網頁往往足夠，但對 Discord 這類 Electron 或獨立通訊程式而言，語音所需的 UDP 不一定會被同一機制完整帶入 Clash。結果就是你觀察到：介面載入與文字同步尚可，但語音頻道長時間顯示連線中或聲音斷來斷去。

若你的客戶端支援 TUN（透明代理／虛擬網卡）模式，通常能讓更多類型的流量進入 Clash 的分流管線，包括不少原本繞過系統 HTTP 代理的連線。啟用 TUN 可能涉及權限、驅動程式與防火牆放行，且不同系統（Windows 11、macOS）細節不同；建議依序完成官方或本站相關教學中的環境檢查，再回來測語音。需要完整對照時，請直接閱讀《Clash TUN 模式在 Windows 與 macOS 上怎麼開》，避免在錯誤的開關上反覆試錯。

與遊戲主機、區網分享場景的差異 若你曾讀過主機或區網相關文章，會看到類似「UDP／NAT」的討論；Discord 桌面版與行動版的網路拓樸不同。本文聚焦「同一台電腦或手機上 Clash 客戶端如何接管語音」，與路由器閘道、主機 DMZ 等設定不盡相同，請勿混用步驟。

第 4 步：用連線日誌對照「規則命中」與實際協定

當你依前述步驟調整後，請不要只靠「感覺有比較好」收工。打開客戶端的連線紀錄或日誌檢視：目標主機名、命中規則、使用的策略組與節點名稱是否與預期一致；若客戶端能顯示傳輸類型，請特別留意語音階段是否仍出現大量直連或錯誤出口。

若你發現某些主機名反覆出現卻沒被你的 DOMAIN-SUFFIX 覆蓋，請以日誌為準新增條目，而不是猜測。若命中規則正確但延遲與丟包仍高，優先在同一策略組內更換節點，並分開判斷「規則問題」與「線路品質問題」。養成「先看命中、再看節點、最後才懷疑客戶端壞掉」的順序，能顯著縮短徹夜重裝的時間。

第 5 步：可列印的自檢清單（建議照順序勾選）

  1. 確認 Clash 核心與設定檔可正常載入，客戶端版本與功能（是否具備 TUN／UDP 相關選項）符合預期。
  2. 在 rules 中為 discord.com、discord.gg、discordapp.com／discordapp.net 建立清楚命中的條目，並置於過寬兜底規則之前。
  3. 檢查所用節點與協定是否支援 UDP，避免語音流量落在半套可用的線路上。
  4. 若僅開系統代理仍斷語音，評估改為 TUN 或客戶端提供的完整透明代理方案，並處理系統權限與防火牆。
  5. 以連線日誌驗證：語音階段的主機名、命中規則與出口是否一致；必要時依日誌補齊遺漏網域。
  6. 長期維護：Discord 與 CDN 可能調整子網域，保留「以後綴級規則為主、單點 DOMAIN 為輔」的習慣，降低訂閱規則更新帶來的衝擊。

若你使用訂閱連結自動更新節點與規則，請記得：訂閱內容與本站客戶端分發是兩條線——取得節點資料後，仍須在本機完成匯入與除錯。關於訂閱更新失敗、時間戳與 HTTPS 等議題，可參考《Clash 訂閱自動更新失敗怎麼修》。

延伸問答：Discord 語音與 Clash 的常見誤解

「全域模式」為什麼還會斷語音？

全域模式描述的是規則層預設走向，但流量是否進入 Clash、以及進入後能否完整處理 UDP，仍取決於客戶端模式、系統與節點能力。請用日誌確認實際路徑，而不是只靠開關名稱判斷。

語音伺服器顯示的區域異常，一定是節點國家錯嗎？

不一定。區域顯示與路由、平台偵測與你實際出口位址都有關；若規則命中與出口一致但仍覺得異常，可先固定節點觀察，再與朋友交叉測試，避免過度解讀單一標籤。

手機上問題與桌面相同嗎？

不完全相同。行動網路、背景限制與系統對 VPN／代理類 App 的策略各異；若你主要在 iOS 上使用 Clash 系客戶端，可延伸閱讀《iOS 18 下 Clash 系客戶端》以對照蜂巢式網路與背景連線變因。

寫在最後：把「能上網頁」與「能講語音」拆成兩套驗收標準

Discord 這類即時通訊產品，本質上同時是網頁技術與即時媒體管道的混合體；在 Clash 的世界裡，它們對分流規則、UDP、代理模式的要求並不一致。把「文字能上」與「語音穩定」分開驗收，你會更快定位問題是在網域漏匹配、UDP 未進管線，還是節點不適合 RTC。

相較四處複製來路不明的規則清單，更值得投資的是：能讀懂自己的 YAML 結構、能從日誌反推主機名、能為特定服務保留乾淨的策略組。若你希望客戶端整合訂閱匯入、視覺化切換策略組與連線日誌，並內建最新 Meta 核心，不妨從我們的下載中心取得適用作業系統的版本，讓設定與觀測在同一個介面完成。

→ 立即免費下載 Clash 客戶端，以視覺化管理訂閱、策略組與連線日誌，讓 Discord 語音走對出口、斷續原因一眼可見

需要更多主題與更新，歡迎在技術專欄持續追蹤；若你想系統化掌握規則全貌，亦可延伸閱讀Clash YAML 規則分流完全指南、Clash TUN 模式教學與Clash DNS 模式排查。