一、為什麼開了 Clash，語音仍可能異常
在 Windows 上，Clash 常透過「系統代理」或「TUN 虛擬網路卡」把流量導入核心，再由規則與策略組決定出口。問題在於：Discord 桌面版是獨立程式，並非一定會像 Edge 或 Chrome 那樣讀取系統代理；即使登入、載入頻道列表看似正常，語音頻道仍可能走另一條路徑，或需要 UDP 而未被既有模式完整覆蓋。
因此你會看到兩種典型割裂：文字與圖片正常，一按「加入語音」就卡頓；或狀態列長時間顯示連線中、延遲跳動極大。此時若只在訂閱裡堆疊網域規則，卻未確認「流量是否真的進入 Clash」與「UDP 是否被同一套路由邏輯處理」，很容易誤判成「節點不好」而不斷換機房。
若你已在 訂閱與規則 中為常見服務寫了分流，建議先打開連線日誌：在語音連線發生問題的當下，是否能看到與 Discord 相關的連線紀錄、通訊協定欄位是否出現 UDP。若日誌安靜得異常，首先要懷疑的是應用程式繞過了代理路徑，而不是上游線路品質。
.exe、哪種通訊協定）與「走哪個策略組」。兩者對齊之後，再來談節點地區與延遲才有意義。
二、Discord 流量輪廓：登入與語音並不相同
從使用者可感知的行為來看，Discord 至少包含兩類網路需求：一是帳號、頻道、訊息、嵌入網頁等，多半以 TCP 為主，與一般網頁應用相近；二是語音／視訊通話所依賴的即時傳輸，高度依賴 UDP 與較穩定的端到端路徑。前者有時會「跟著系統代理」或剛好被規則命中；後者若未進入同一套路由與 NAT 行為，就容易出現聲音斷續或無法完成握手的狀況。
此外，Discord 在背景可能還有更新程式、覆蓋層或硬體加速相關元件，不同版本與安裝方式下的行程名稱可能略有差異。實測時請以工作管理員與 Clash 日誌中顯示的名稱為準，而不要只依賴網路上過期的清單。
與遊戲平台的差異（為何要單獨談 Discord）
本站 Steam 與進程分流專文 已說明遊戲平台下載與聯機對 UDP 的依賴；Discord 則更常出現在社交與開黑語音場景，且使用者往往同時開著遊戲與 Discord。此時除了分流規則，還要留意CPU 佔用、音效驅動與藍牙耳機等疊加因素；網路路徑只是其中一環，但卻是 Clash 最能著力的一環。
三、系統代理、TUN、進程分流三條路
在 Windows 上，可粗分三類做法，彼此可搭配，但解決的問題不同。
- 系統代理：對會讀取系統代理的程式有效；對 Discord 桌面版不一定涵蓋完整，尤其對 UDP 語音未必可靠。
- TUN 模式：在系統層把符合條件的 IP 流量導入核心，較有機會讓不依系統代理的程式與部分 UDP 納入同一套路由邏輯。細節與防火牆、路由表可參考 Clash TUN 於 Windows 的排查文。
- 進程分流（PROCESS-NAME 等）：在核心與客戶端支援的前提下，依行程名稱決定策略組，適合「只讓 Discord 走代理、其餘維持直連」或與遊戲流量分開策略組，降低互相干擾。
實務上，語音問題若伴隨「日誌裡幾乎沒有 Discord 連線」，優先順序往往是：先讓流量進核心（常需 TUN 或正確的模式組合），再用進程或規則精準指向適合即時語音的節點。若你同時在區網內共享代理，亦請核對監聽位址與防火牆，可對照 混合埠與區網共享 一文。
四、進程分流實測：鎖定 Discord 行程
為什麼要指到「行程」而不只寫網域
僅依賴 DOMAIN-SUFFIX 類規則時，容易遇到兩個痛點：一是 Discord 相關主機名與 CDN會變動，靜態清單難免漏網；二是同一台電腦上還有瀏覽器、遊戲啟動器與其他程式，寬鬆規則可能讓非 Discord 流量誤入同一策略組。以行程名稱為條件，可以把「只要是這個程式發起的連線」導向指定出口，較貼近「我就是要管 Discord」的直覺。
實測時請以本機為準的執行檔
不同通道（穩定版、測試版、安裝路徑）可能略有差異，以下僅作排查起點，請以工作管理員為準：
Discord.exe：主程式與多數使用者可見連線。Update.exe：部分安裝架構下的更新相關行程，若更新長期失敗，也可能間接影響元件完整性。- 若使用覆蓋層、硬體加速或第三方外掛，可能還有額外子行程；關鍵仍是在出問題的當下對照日誌是否命中規則。
在支援 Mihomo（Clash Meta） 類核心的設定中，常會見到 PROCESS-NAME（或圖形介面中的「進程規則」）。撰寫時請注意規則順序：較具體的進程規則應放在過寬的 GEOIP 或最後 MATCH 之前，否則可能永遠匹配不到。
五、UDP／RTC：為何語音比文字更挑路徑
語音通話對封包遺失、抖動、延遲尖峰非常敏感。當 UDP 流量未被穩定導向同一出口，或在中途被錯誤的 NAT／防火牆行為處理時，耳朵聽到的就是斷音、金屬音或整段靜音。相較之下，文字訊息多走 TCP，重傳機制讓「能連上」的體感較寬容。
TUN 與核心的 UDP 轉發能力，會影響語音流量是否按你的規則進入指定節點。不同版本的核心與客戶端，可能還有與堆疊（stack）、轉發開關相關的進階選項；名稱與預設值會隨版本變動，請以你所用版本的官方文件與發行說明為準，本文不寫死參數以免過時。
實測建議分兩段觀察：先在僅文字頻道下確認基本連線；再於語音頻道開啟時檢視日誌是否出現對應 UDP 連線、策略組是否與預期一致。若第二段才異常，就應優先懷疑 UDP 與模式，而不是先更換訂閱連結。
六、Discord 與 Windows 端可並行的設定
下列項目不取代 Clash 的路由設定，但能減少「網路其實已通，卻被用戶端或系統疊加干擾」的誤判成本。
- Discord 設定：在「語音與視訊」中檢查輸入／輸出裝置、噪音抑制、迴音消除；若懷疑相容性問題，可暫時關閉硬體加速或改用最簡音效設定做對照。
- 伺服器區域與路由：若組織允許，選擇與同伴較近、且與你節點路徑較一致的語音區域，有時能減少跨洲折返。
- Windows 防火牆：確認 Clash 核心、TUN 介面與 Discord 未被誤判阻擋；企業環境若有額外安全軟體，也可能攔截 UDP。
- 同時開啟的其他 VPN 或過濾驅動：多個程式同時改寫路由表時，容易造成路徑競態；建議排查時暫時關閉其一以縮小範圍。
客戶端選型方面，可參考 Clash Verge 與 Clash for Windows 比較，但實際能否使用進程規則、TUN 與日誌細節，仍以你所安裝的版本為準。
七、實測排查順序建議
建議依序縮小問題範圍，避免同時改動訂閱、節點、TUN、規則與 Discord 設定導致無法回溯。
- 確認流量是否進核心：語音連線問題發生時查看日誌，是否有 Discord 相關紀錄。
- 驗證進程規則是否命中：對照行程名稱與規則順序；未命中時先查模式與核心能力。
- 區分 TCP 與 UDP 現象：文字正常而語音異常時，優先檢查 UDP 與 TUN 相關選項。
- 用戶端與系統對照：短暫關閉硬體加速、更換音效裝置測試，排除非網路因素。
- 最後再調整節點與地區：在路徑已正確的前提下，再比較延遲、丟包與頻寬。
| 現象 | 優先檢查 |
|---|---|
| 文字正常，語音一直連線中 | UDP 是否納入；是否僅依賴系統代理；TUN 與防火牆；進程規則是否命中 |
| 日誌幾乎沒有 Discord | 流量是否未進核心；是否需開啟 TUN；是否有其他 VPN 改寫路由 |
| 延遲數字低但聲音仍斷續 | 抖動與丟包；藍牙耳機與音效驅動；Discord 硬體加速；CPU 佔用 |
| 特定節點才發生 | 該節點對 UDP 的處理；改以其他協定或機房對照；仍先確認規則命中無誤 |
八、常見誤區與合規提醒
常見誤區包括：以為「節點越貴越穩」卻忽略流量根本沒進代理；或同時開啟多個會改寫路由的軟體，造成路由表衝突。建議一次只調整一類設定，並保留可還原的備份。
請遵守你所在地法律與 Discord 服務條款；本文僅討論網路路徑與用戶端設定思路，不鼓勵任何違反服務條款或法律的使用方式。若你僅想改善家庭或工作室網路下的通話品質，亦可同步檢查路由器 QoS、DNS 與有線連線等基礎環境。
九、小結
在 Windows 上把 Clash 用於 Discord 語音，關鍵是理解：能打字不代表語音走對了路。語音依賴 UDP 與穩定的 RTC 路徑，往往需要先透過 TUN 或正確模式讓流量進核心，再以進程分流鎖定 Discord.exe 等行程，最後才輪到挑節點與地區。與只堆疊網域規則相比，這條思路更貼近「畫面上發生什麼，日誌裡就應該看到什麼」的實測方法。
相比功能單一、只能切換少數開關的工具，Clash 生態在規則可組合性與核心可替換性上更利於長期維護；把 Discord、遊戲與一般瀏覽拆成不同策略組後，日常多半只需微調節點與觀察日誌即可。
若你尚未安裝或希望使用圖形介面更易上手的客戶端，可從本站取得安裝包並匯入訂閱，再依本文順序啟用進程分流與 TUN／UDP 相關選項逐步驗證。