為什麼 Discord「打得開網頁、語音卻像壞掉」？先分清 TCP／UDP 兩條路

Discord 在遊戲與社群場景裡普及度極高，但檢索上仍常見「打不開」「語音卡頓」「一直連線中」這類關鍵字；原因往往不是單一網址被擋，而是應用同時依賴兩套傳輸行為：登入、頻道列表、圖片與嵌入內容多走 TCP／HTTPS；而語音通話、部分即時互動則高度仰賴 UDP 的低延遲與無連線狀態封包特性。若你的 Clash 只「分流了看得見的主機名」，卻沒有讓UDP 流量與網域規則、傳輸路徑對齊，就很容易出現「文字聊天勉強可用、一進語音頻道就爆音或斷線」的割裂體感。

本文刻意與本站ChatGPT／Grok 等網頁分流、或開發者 IDE 分流那類「偏瀏覽器／桌面工具 HTTPS」的思路區隔：聚焦即時通訊＋語音，說明 Clash Discord 場景下如何把UDP 分流納入整體規劃，而不是只抄幾條 DOMAIN-SUFFIX。以下是可依序實作的概念架構，實際網域與策略組名稱請以你的訂閱與連線日誌為準。

先把流量拆成兩層：「看得到的主機名」與「語音承載」

在多數桌面與行動客戶端裡，Discord 會先完成帳號、Gateway、REST 與靜態資源的 HTTPS 請求；當你加入語音頻道時，客戶端再協商媒體路徑。對使用者而言，這代表除錯時要分兩張清單：一張是你在 Clash 連線預覽裡能對上網域規則的「信令與網頁型」主機名；另一張則是與媒體伺服器、地域選路相關、可能以 IP／埠或較不透明方式呈現的「語音承載」流量。若只處理前者而忽略後者，就會出現能進伺服器、語音品質卻差的經典症狀。

實務上建議把 Discord 相關需求寫進獨立策略組，例如拆成 DISCORD_APP（應用主體、登入、API、CDN）與 DISCORD_MEDIA（你願意單獨微調語音與延遲的出口；若暫時不想細分，也可先合併到同一策略組，但要在心理上區分「這組規則同時背負 UDP 語音期待」）。這種拆法與純「按網站名」分 AI、Docker 映像倉庫的路由不同：本題的核心是語音代理與傳輸型態，不是換一個網址清單就好。

網域分流：讓 Discord 相關主機名「靠前命中」

Clash 的規則自頂向下匹配，命中即停止。想讓 Clash Discord 規則真的生效，請先檢查是否有過寬的 GEOIP、MATCH 或第三方規則集把流量提前收走。建議順序大致是：本機與內網直連；公司或校園必要網域；接著才是你為 Discord 明確寫下的 DOMAIN-SUFFIX／DOMAIN-KEYWORD（請以連線日誌中實際出現的主機名為準，而非複製過期清單）；最後才落到一般分流。

網路上流傳的「Discord 網域大全」會隨 CDN、協定與客戶端版本改變；最穩的作法是在重現問題的當下觀察：登入階段、載入頻道、加入語音時，各出現哪些目標主機名與連線類型。你可以先固定一顆延遲可接受、且確認相容 UDP 的節點，只為觀察到的後綴建立規則，對照症狀是否緩解，再決定是否引入更大範圍的規則集。

若你尚未熟悉規則優先順序與 proxy-groups 寫法，可先閱讀Clash YAML 配置深度解析，再回到本文把「Discord」視為同時有 HTTPS 與 UDP的產品線來規劃，而不是多幾行關鍵字就結束。

UDP 分流與傳輸路徑：為什麼只開「系統代理」常常不夠

許多應用的語音元件會直接使用 UDP，或有與作業系統路由互動的路徑；若你只開HTTP／SOCKS 系統代理而沒有讓這類流量進入 Clash 的轉發邏輯，就可能只剩部分 HTTPS「剛好被帶上」、UDP 卻仍走預設出口，造成網頁版看似正常、桌面客戶端語音很差的落差。當你改用 TUN、或客戶端支援的等效整機／虛擬網卡級接入時，較有機會讓 UDP 與 TCP 走同一套路徑決策——但同時也更容易遇到與其他 VPN、公司零信任客戶端或路由表競爭的問題。

因此本文建議把「UDP 分流」理解成三件事的組合：其一，策略上是否允許該連線走代理鏈（含協定支援與節點能力）；其二，實際生效模式是系統代理、TUN 還是混合；其三，網域規則有沒有在 UDP 與 TCP 上一致以同一策略組為目標。單獨改其中一項，往往只能改善部分現象。

若你在開啟 TUN 後出現整機斷網或路由異常，請交叉參考Windows TUN 與防火牆排查，先確保環境層沒有與 Clash 搶路由，再回頭微調 Discord 規則；否則你會一直在「規則好像對了、底層卻打架」裡空轉。

DNS、Fake-IP 與「解析正確卻仍走錯策略」

即時通訊客戶端大量使用 TLS，若 DNS 解析與連線決策分裂，會出現「看起來解析到了、規則卻對不上」的困惑。本站文件頁的 DNS 與 Fake-IP 說明從機制面解釋了常見設定；在 Discord 場景下，若你啟用 Fake-IP，請特別留意少數服務是否需列入 fake-ip-filter 才與憑證驗證相容，以及規則集中是否假設了「真實 IP」語意。

另一個常見誤區是：以為只要把手機或電腦的 DNS 改成公共解析器就萬事大吉。實際上 Clash 內部的 DNS 模組、覆寫與策略路由要一起看待；否則可能出現規則命中看似正確、實際連線卻仍繞遠路或反覆重試，在語音場景會放大成爆音與掉包感。

設定檔示意：獨立策略組、靠前網域規則（概念範例）

下列為概念示意，策略組名稱、節點與網域請以你的訂閱與連線日誌為準；合併進正式設定檔前請先備份。範例中網域僅為佔位，請替換成你環境中實際觀察到的主機名或後綴，並遵守你使用的規則語法版本。

proxy-groups:
  - name: DISCORD_APP
    type: select
    proxies:
      - YOUR_PROXY_NODE
      - DIRECT
  - name: DISCORD_MEDIA
    type: select
    proxies:
      - YOUR_UDP_FRIENDLY_NODE
      - YOUR_PROXY_NODE
      - DIRECT

rules:
  # Observed Discord-related hostnames (examples — replace with your logs)
  - DOMAIN-SUFFIX,discord.com,DISCORD_APP
  - DOMAIN-SUFFIX,discordapp.com,DISCORD_APP
  - DOMAIN-SUFFIX,discord.gg,DISCORD_APP
  # …append CDN / media hostnames you actually see when joining voice

若你一開始不想拆兩組，也可以讓 DISCORD_APP 同時承載你觀察到的語音相關後綴；重點是規則要能覆蓋真實流量，而不是複製別人的「萬用表」。撰寫時也建議在檔案內保留簡短註解，說明每一條後綴是從哪次連線日誌加入，方便未來產品改版時回頭清理。

驗收方式：用「可重現步驟」對照連線日誌

完成調整後，請用固定流程驗證：首先只在文字頻道活動，確認登入、頻道列表與圖片載入相關主機名命中預期策略組；接著加入語音頻道，觀察是否出現新的目標位址或不同的連線類型；最後再測試螢幕分享或其他高頻寬功能（若你有使用）。每一步都對照 Clash 連線預覽或日誌，確認UDP 分流沒有被默默落到你不想用的預設出口。

若語音仍有明顯延遲，請先縮小變因：暫停會自動切換節點的策略、改用手動固定少數延遲穩定的節點，並排除同時開啟的其他 VPN；這能避免把「節點路由品質」誤判成「規則寫錯」。對即時語音而言，穩定往往比峰值頻寬數字更重要。

現象對照：先猜哪一層出問題

下表方便你在排查時快速收斂方向（仍須以實際日誌為準）。

合規與使用條款提醒

透過代理或第三方節點使用 Discord 等服務時，仍須遵守相關服務條款、授權與所在地法規；節點提供者亦有各自政策。本文僅從網路工程角度說明 Clash 規則與傳輸路徑的搭配思路，請讀者自行確認合規性。

結語：把 Discord 當成「HTTPS＋UDP」一起設計的產品

Discord 那種「社群＋語音」混合體驗，決定了在 Clash 裡不能只談網域分流而忽略UDP 分流與實際傳輸路徑。把登入／API／CDN 與語音承載拆成可讀的策略組與規則順序，並用連線日誌驗證——才能把「打不開」與「語音卡頓」從模糊抱怨，收斂成可逐步量測的調參問題；也比硬套 Docker、AI 或 IDE 類題材的規則更有針對性。

若你尚未安裝合適的用戶端，可先從本站用戶端下載頁取得對應平台版本，再依本文思路為即時通訊與語音流量建立獨立分流。→ 立即免費下載 Clash，開啟流暢上網新體驗