一、先對齊現象：更新卡住與語音掉線常是兩條不同的路

Discord 桌面用戶端同時依賴多種連線：登入與設定同步、文字頻道與嵌入內容、貼圖與頭像等靜態物件、以及語音通話所需的即時媒體路徑。當你遇到Discord 更新失敗或進度條不動時，瓶頸多半落在下載／CDN與 TLS 握手是否能在合理時間內完成；當你遇到語音「偶發正常、多數時間掉線」或延遲極高時，瓶頸更常落在UDP 是否被阻擋、WebRTC 候選路徑是否一致、以及媒體伺服器主機名稱是否被規則拆到不同出口。

因此，請避免一開始就把所有問題都歸咎到單一策略群組。較務實的做法是：先用連線日誌把「更新階段」與「已進入主介面後的語音階段」分開觀察，確認各自命中的規則與 DNS 行為，再決定要不要把 CDN 與 RTC 拆到不同群組。若你尚未成功匯入訂閱或策略名稱不確定，建議先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教程》，避免在錯誤的群組名稱上反覆試錯。

二、為什麼要把 CDN 與 RTC 拆開思考

CDN 類流量通常以 TCP 為主，目標是把大型檔案與靜態資源盡快送到你的電腦；這與語音通話追求的「穩定低抖動、UDP 可達」並不完全相同。若你把兩者硬塞在同一個「只看延遲數字」的節點選擇裡，可能出現下載看起來很快、語音卻頻繁切換路由的體感；也可能出現語音勉強可用、更新卻永遠卡在 0%，因為某一條下載子網域仍被地區策略或前置直連規則截走。

在撰寫 CDN 分流規則時，請優先對齊你環境中實際出現的主機名稱，而不是只抄一份過期清單。Discord 會依區域與版本調整邊緣節點命名；最可靠的方式仍是在你電腦上，於更新與加入語音頻道兩種動作下各收集一次日誌，再把重複出現的後綴整理成 DOMAIN-SUFFIX。這與我們在 Steam 場景強調的「客戶端多子網域」邏輯一致，但主機名稱集合不同，請勿混用規則。

三、Windows 重點：為什麼「只開瀏覽器代理」常常不夠

Discord 桌面程式並不等同於 Edge 或 Chrome；即使你已在 Windows 設定中開啟系統 HTTP 代理，仍可能遇到部分連線以不同方式發起，或被其他安全軟體、公司政策、以及應用程式自身的網路堆疊影響。實務上，若症狀主要發生在Discord 代理 Windows桌面版，而不是網頁版，我們通常會優先建議你驗證 TUN 模式是否能讓用戶端相關程序一致進核心，因為它能在網路層統一接管符合條件的流量。

啟用 TUN 會涉及路由與系統權限，請先閱讀《Clash TUN 模式開啟方法》再操作，並在開啟後回到連線清單確認 Discord.exe 相關連線是否出現在核心中。若你同時使用 WSL2 或 Docker Desktop，也可對照《WSL2 共用本機 Clash 代理》理解「哪些流量預設不會自動跟著 Windows 代理走」，避免把問題誤判成單一聊天軟體故障。

四、建議排查順序（先證明流量有進核心，再談節點）

下列順序刻意把「換節點」放在中後段：先確認 Discord 相關連線有經過 Clash，且規則命中符合預期，再談線路品質與 UDP。

  1. 確認 Clash 正在執行，並依場景選擇系統代理或TUN；若問題主要出在桌面用戶端，優先驗證 TUN。
  2. 在觸發「檢查更新」與「下載安裝檔」時，於連線日誌中檢查是否出現常見的 Discord CDN／下載主機名稱，以及策略是否為預期的代理群組，而非被過寬的 DIRECT 規則提前截走。
  3. 進入語音頻道後，再次檢視日誌：是否有大量 UDP 相關連線、是否出現區域媒體伺服器後綴，並確認它們沒有被錯誤導向與登入流量不一致的出口。
  4. 檢查 DNS 模式（是否 fake-ip）、以及 Discord 相關後綴是否在 fake-ip-filter 或 nameserver-policy 中有合理設定，避免解析與連線策略互相打架。
  5. 在規則已正確命中的前提下，再為 CDN 與 RTC 分別挑選穩定、掉包低的節點；若 UDP 被上游網路或節點政策限制，語音仍可能異常，此時才需要回到網路供應商或節點型態層面處理。

若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文聚焦 Discord 場景下的CDN 分流與語音 RTC對齊。

五、網域怎麼收集：以日誌為準，不要只抄懶人包

Discord 會隨時間調整邊緣與媒體伺服器命名，第三方整理的清單可作起點，但最可靠的方式仍是在你自己的環境收集主機名稱。Windows 上可搭配「工作管理員 → 效能 → 開啟資源監視器 → 網路」觀察連線時的遠端位址對應名稱，或在 Clash 用戶端的連線清單中依程序或關鍵字篩選 discord。

將觀察到的名稱依後綴分組後，優先使用 DOMAIN-SUFFIX 對齊整棵子網域樹，比過寬的 DOMAIN-KEYWORD 更不易誤傷其他服務。若你看到圖片或更新檔來自第三方公有雲邊緣，請只加入「該次失敗時間點實際命中」的後綴，避免把整個超大後綴一刀切進代理，拖慢其他網站。

六、實務上常見的 Discord 網域方向（以實測為準）

下列方向為多數環境下登入、文字、圖片與更新會出現的典型後綴家族；實際是否全部需要、以及是否應走同一策略群組，請以你的連線日誌為準：

  • discord.com：主站、部分 API 與網頁流程常見。
  • discordapp.com：歷史與相容路徑中仍常見於 CDN、API 與附件相關主機名稱。
  • discord.gg：邀請連結與短流程相關請求。
  • discord.media：語音與媒體伺服器相關主機名稱家族在實務上經常出現（實際前綴會依區域變化）。
  • 下載與更新模組亦可能使用獨立的下載子網域；若日誌在「檢查更新」時出現與上述不同的主機名稱，請個別補規則。

重點在於：介面看得到、圖片卻載很久時，優先懷疑 CDN 類子網域仍直連；文字大致正常、語音一進房就爆時，優先核對媒體與 RTC 相關主機名稱是否與登入流量同一出口，並檢查 UDP 是否被阻擋。

七、DNS 與 fake-ip：別讓解析鏈放大「卡住 0%」的感受

在 fake-ip 模式下，Clash 會先回傳虛擬位址再在連線階段決策出口。若 DNS 與規則配合不當，可能出現「解析看起來成功、實際 TLS 對錯出口」或反覆重試。Discord 用戶端在更新時會持續嘗試多個子網域，任一條解析被汙染或指向不理想的路徑，進度條就可能長時間停在 0%。

實務上可以分兩步：第一，確認你的 DNS 上游對海外網域可信且可達；第二，對反覆出問題的後綴在用戶端支援的欄位中設定較穩定的解析策略（例如指定 DoH），並在調整後用連線日誌比對命中是否與預期一致。若改 DNS 後更新明顯推進，代表瓶頸有相當比例在解析鏈路，而非單純節點速度。

八、分流設計檢查清單（請以你的日誌為準）

下表整理撰寫 Discord Clash 規則時的檢查角度；欄位中的後綴會隨營運調整，務必以實測主機名稱為準。

類型常見主機名稱方向設定提示
登入與設定discord.com、discordapp.com 等與帳號工作階段同一策略脈絡，避免 API 走代理、附件直連。
CDN 與附件cdn.discordapp.com 等圖片與大型物件常落在此類；更新卡住時優先核對是否誤直連。
下載與更新日誌中出現的 dl.* 或更新專用子網域與語音分流拆開時，可避免下載搶佔延遲敏感連線；但別讓其中一條直連遭區域干擾。
語音與 RTC*.discord.media 等與 WebRTC／UDP 關聯高；需同步確認 TUN 與防火牆是否阻擋媒體埠位。
邀請與短連結discord.gg若邀請連結開啟異常，請確認未被前置攔截規則誤傷。

九、分流規則範例（請替換為你的策略群組名稱）

下列 YAML 片段示範「把 Discord 相關後綴明確指向代理群組」的寫法；請將 PROXY 替換為實際策略群組名稱，並維持規則順序：更具體的 Discord 條目應放在過寬的 MATCH 與地區直連清單之前。若你希望「下載更新」與「語音媒體」分流到不同群組，可定義 PROXY_DL 與 PROXY_RTC，再依日誌微調。

# Example only — replace PROXY_DL / PROXY_RTC with your policy group names
rules:
  - DOMAIN-SUFFIX,discord.com,PROXY_DL
  - DOMAIN-SUFFIX,discordapp.com,PROXY_DL
  - DOMAIN-SUFFIX,discord.gg,PROXY_DL
  - DOMAIN-SUFFIX,discord.media,PROXY_RTC

若日誌中出現其他專用主機名稱，請以 DOMAIN-SUFFIX 逐條補上；不確定時寧可先記錄完整主機名稱，再查後綴歸屬，避免關鍵字規則過寬。

十、語音與 UDP：規則正確之後仍要檢查「能不能通」

即使 語音 RTC 相關網域都已命中代理群組，若你的網路環境或節點型態對 UDP 不友善，語音仍可能表現為高延遲或頻繁斷線。此時請把觀察重點從「延遲數字」轉成「UDP 是否實際可到」與「WebRTC 候選是否穩定」。部分公司網路會阻擋非標準埠或非 HTTP 流量，這不是 Clash 規則能單獨解決的範疇。

協定層面也可參考《Shadowsocks vs Trojan vs Hysteria2》，理解不同傳輸方式對 UDP 與長連線的差異。請記得：節點再快，若規則讓某一條 Discord 子網域直連失敗，使用者體感仍會是「更新永遠 0%」或「語音一進房就爆」。

十一、圖形用戶端中如何少踩坑

在 Clash Verge Rev 等用戶端中，建議開啟即時連線清單，篩選 discord 或上述後綴關鍵字，逐條確認策略。若某條顯示 DIRECT，請回到規則表檢查是否有廣告攔截、地理分流或「繞過區域網」類規則前置命中。

若桌面端基礎設定尚未完成，可先依《Clash Verge Rev 完整設定教學》跑通訂閱與模式，再回到本文補 Discord 專用規則，可節省大量試錯時間。

十二、小結：把「卡住與掉線」變成可驗證的規則問題

2026 年在 Windows 上遇到 Discord 更新失敗或語音頻道異常時，可依序確認：用戶端流量是否進核心、DNS 與 fake-ip 是否一致、CDN 分流與語音 RTC 是否各自命中，以及UDP 與節點型態是否支援你的使用方式。當連線日誌能清楚對應主機名稱與策略，你就不需盲目更換節點卻無法改善體驗。

當你希望把觀測、規則與核心更新集中在同一套成熟用戶端時，官方維護方案通常能降低手寫 YAML 的低階錯誤；相較其他同類工具，Clash 在規則透明度與日誌對照上往往更一致。→ 立即免費下載 Clash，開啟流暢上網新體驗