為什麼會「更新卡 0%」又或「語音一陣一陣」？

在桌上型 Windows 環境裡，許多人已用 Clash 或 Mihomo 穩定瀏覽一般網站，但一開 Discord 桌面版就出現安裝或更新進度長時間停在 0%、語音頻道聲音斷續、一進語音房就掉回待機狀態。這類問題常常不是 Discord 服務全面故障，而是分流規則命中不一致：客戶端實際連線的網域名稱與 CDN 邊緣、長連線 Gateway（閘道），和您在瀏覽器裡看到的頁面並不是同一批主機；其中一部分被較寬鬆的規則提前送去 DIRECT，另一部分走代理或落到錯誤策略群組，認證、清單拉取與大型檔案路徑便會分裂，更新進度條就像凍結。

第二條獨立線是語音鏈路。RTP／UDP 類流量不一定能以「再多加幾行 DOMAIN-SUFFIX」就收斂乾淨：語音伺服器常以連線目的地 IP 與 UDP 埠為主體，若僅開啟系統 HTTP 代理、或用訂閱裡不轉發 UDP 的節點組合，就可能出現「文字與圖片都正常，一上麥就卡」的典型症狀。處理順序應先用日誌證明 Discord 的 HTTPS 與 Gateway 有進入您正在調校的核心，再把語音單獨拉到 TUN／UDP 能力檢查，才不會在 YAML 裡無限試錯。

若策略群組名稱與訂閱節點仍對不起來，建議先完成 訂閱匯入教學，避免複製規則後卻指向不存在的 proxy-groups 條目。

和 Steam、Epic、遊戲主機情境有什麼同構之處？

站內 Steam 商店／下載／UDP、Epic Launcher 與 CDN 等文，核心心法都是：獨立客戶端會拉出比一般網頁更多樣的主機集合，必須置前具體網域規則，並用連線日誌補齊單行 DOMAIN，而不是只靠巨型 RULE-SET 賭運氣。Discord同樣混合了HTTPS API／CDN、長連線 Gateway，以及語音 UDP；因此排查順序可以刻意對齊「先 HTTPS／CDN／Gateway → 再 UDP／TUN」的遊戲平台路徑，減少心智切換成本。

若您也處理過主機下載，可對照 Switch eShop 與任天堂 CDN 一文中「流量是否進核心、DNS 與規則順序」的收斂方式；只是 Discord 桌面板直接跑在與 Clash 同一台 PC 上，與系統代理、TUN、他款 VPN疊加時的路由優先順序衝突會更常見，下段會分開說明。

症狀分層：更新、閘道、語音不一定是同一個瓶頸

安裝或更新卡 0%、下載不走多與發佈 CDN、差分更新主機有關，日誌中常出現 dl.discordapp.net 這類依版本／頻道前綴變化的主機名（實際字串請以您環境為準）。若規則只覆蓋 discord.com 主站而漏掉下載子網域，就會呈現「登入頁能開、進度條不動」。

頻道列表載入不完全、線上狀態跳動、無法連線較常牽涉 Gateway WebSocket（例如日誌裡可見 gateway.discord.gg）與 API 路徑；若 HTTPS 走的出口與 Gateway不一致，客戶端可能反覆重連。

語音房內爆音、延遲飄高、甚至被踢回則要把焦點轉到 UDP、TUN、節點轉發與本機 NAT；此時就算 DOMAIN-SUFFIX,discord.com 置前完美，也未必能修語音。可延伸閱讀 節點全紅與 UDP／STUN 排查，建立與 Steam 語音類問題共用的觀念。

Windows 建議排查順序（與「遊戲三步驟」對齊）

1. 拓樸：確認 Discord 行程的流量會出現在核心連線日誌；若完全沒有紀錄，先回到系統代理／TUN／防火牆與路由優先順序，不急著堆規則。
2. 規則順序：將 Discord 常用後綴放在寬鬆 GEOIP、巨型 RULE-SET、兜底 MATCH之前；哲學可對照 規則分流國內外。
3. HTTPS／CDN／Gateway：用日誌收斂更新與附件主機，必要時為單一媒體主機補 DOMAIN 行。
4. 語音 UDP：確認已啟用能接管程式流量的 TUN（或等同完整堆疊），並確認所用節點／協定在您的客戶端組態下確實轉發 UDP。
5. DNS：對齊 fake-ip 模式時「誰解析、誰連線」，避免規則命中與實際出站分裂。

步驟一：確認 Discord 流量有進 Clash（系統代理與 TUN）

在 Windows 上，若僅依賴「系統 Proxy」，少數程式仍可能略過系統設定；Discord Electron 客戶端在多數環境會跟隨系統，但與其他 VPN、安全軟體、公司套件並存時，實際路徑可能與預期不同。TUN 模式通常較有利於讓語音類 UDP 與一般 TCP一起進入可被規則看見的堆疊，但仍需閱讀您所用前端（例如 Verge、FlClash）是否真的對 Discord 行程開啟了規則模式接管。

建議在重現問題時開啟連線日誌，搜尋是否有對 discord 字根的域名解析記錄或 CONNECT／TLS紀錄；若 HTTPS 完全缺席，請優先對照 TUN 模式指南，確認虛擬網卡與路由是否生效，而不是先在規則檔末尾無限追加清單。

步驟二：規則優先序與 Discord 網域骨架（務必置前）

在 mode: rule 下，rules: 由上而下命中即停。任何會把大量網名送去 DIRECT 或錯誤群組的寬鬆條目若排在 Discord 專用規則前面，您新增的 DOMAIN-SUFFIX 可能永遠輪不到。請維持「LAN／內網直連 → 目標業務後綴 → 細粒度規則集 → GEOIP／MATCH」這種具體在前、兜底在後的習慣。

下列為教學用骨架；實務上請以您環境日誌中實際出現的主機名為準補齊單行 DOMAIN，勿盲目複製過時清單。註解使用英文以利版本控管。

YAMLproxy-groups:
  - name: "DISCORD_PROXY"
    type: select
    proxies:
      - "DISCORD_STABLE"
      - DIRECT
  - name: "DISCORD_STABLE"
    type: url-test
    proxies:
      # Replace with nodes from your subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Discord — place BEFORE broad RULE-SET / GEOIP / MATCH
  - DOMAIN-SUFFIX,discord.com,DISCORD_PROXY
  - DOMAIN-SUFFIX,discordapp.com,DISCORD_PROXY
  - DOMAIN-SUFFIX,discord.gg,DISCORD_PROXY
  - DOMAIN-SUFFIX,discord.media,DISCORD_PROXY
  - DOMAIN-SUFFIX,discordcdn.com,DISCORD_PROXY
  - DOMAIN-SUFFIX,discordstatus.com,DISCORD_PROXY
  # Add DOMAIN lines from logs: gateway.discord.gg, cdn.discordapp.com,
  # media.discordapp.net, dl.discordapp.net, stable.dl.discordapp.net, etc.

gateway.discord.gg 建議在日誌確認後單獨列出（若您的規則方言支援 DOMAIN 單機），以免與其他業務的子網域策略混淆。CDN 與附件主機（例如常見的 cdn.discordapp.com、media.discordapp.net）若被國外／國內規則集提早分流到錯誤出口，會表現為貼圖與嵌入預覽載入失敗、語音以外的功能間歇異常。

步驟三：更新卡 0% 時——固定出口並對照日誌

大型更新與分段下載對長連線穩定度敏感。若 DISCORD_PROXY 內部綁的是高頻切換的 url-test 自動選路群組，可能在 TLS 會話之間漂移到不同節點，體感就像進度永遠不回頭。較穩的做法是：在重現更新問題時，暫時將群組改為手動 select 並固定單一節點，確認曲線恢復後再恢復自動選路。

同時請比對同一時間點日誌：若下載主機仍顯示 DIRECT 或落到預設 PROXY 而非您預期的 DISCORD_PROXY，代表問題在規則順序或後綴缺漏，與節點頻寬無關。此時應回到步驟二的骨架，把日誌裡新出現的品牌或區域化子網域補進置前區塊。

步驟四：語音 RTP／UDP——與 HTTPS 規則「分線」排查

Discord 語音並非只靠域名規則即可完整描述：RTP 往往以UDP 目的埠與對端 IP為核心，若您的堆疊只在 SOCKS／HTTP 埠做轉發，語音封包可能根本不經過 Clash，或在離開本機後才撞上錯誤路由。實務上通常需要：

• 確認前端已啟用適當的 TUN（或等同機制），讓 Discord 行程的全系統流量可被核心看見並套用規則。
• 在訂閱與協定相容前提下，檢視代理節點是否支援所需的 UDP relay；若節點明確捨棄 UDP，語音再多的域名規則也無濟於事。
• 將 Steam／遊戲語音類問題讀過一遍：Steam 文的 UDP／NAT 段落 與本站 UDP 總覽可交叉驗證「延遲顯示」與「實際語音不通」的差異。

家用路由器雙層 NAT、電競加速器、或其他全域 VPN若與 Clash TUN搶路由，也可能讓 UDP 走錯介面。遇到「只有 Discord 語音怪、其他軟體正常」時，請刻意做一次暫時關閉他牌 VPN／加速器的對照實驗，以免誤判為訂閱節點品質問題。

步驟五：DNS、fake-ip 與 Gateway 一致性

在 fake-ip 模式下，若 Discord 或系統某條查詢路徑仍繞過 Clash DNS，可能出現規則看似命中、實際連線卻從另一出口離開的分裂。請習慣先問「誰負責解析、誰負責連線」，必要時暫時關閉瀏覽器 DoH 或系統硬寫的第三方解析器做A／B 對照；TUN 與 DNS 劫持是否閉環，可回到 TUN 指南 複習。

Gateway 類長連線對時間偏移與中間設備插入 HTTPS 檢查也較敏感；若您在公司網路或透明代理環境，請同步確認系統時間與憑證鏈是否正常，這類問題無法單靠 YAML 規則根治。

實測檢查清單（濃縮）

1. 日誌有無 Discord 連線：沒有則先修拓樸與接管。
2. 規則順序：Discord 後綴是否早於寬鬆 RULE-SET／GEOIP。
3. CDN／更新主機：是否與 API／Gateway同一策略出口，必要時依日誌補單行 DOMAIN。
4. 節點穩定度：更新測試期間先固定節點，排除自動選路抖動。
5. 語音 UDP：TUN、UDP 轉發、路由器 NAT／加速器另線排查。
6. DNS：fake-ip 與透明代理路徑一致，避免分裂解析。

常見踩坑

• 只配主網域、忘記 CDN／dl：能登入卻不能更新，是典型的規則缺角。
• 把語音問題完全丟給域名規則：RTP／UDP 與 Gateway／HTTPS 應分線處理。
• 以為延遲數字好看就等於語音穩：UDP 遺失與抖動才是語音主觀卡頓來源。
• 與其他 VPN 疊加卻未對照實驗：路由搶占會讓 YAML 調整看似無效。

結語

Discord 同時包含HTTPS／CDN 更新、Gateway 長連線與語音 UDP三類流量；在 Clash 生態裡，最有效的起手式仍是先讓客戶端流量進核心、再用日誌收斂主機名，並以置前 DOMAIN-SUFFIX 與獨立 DISCORD_PROXY 讓 API、CDN 與 Gateway盡可能走同一出口。當更新與頻道載入恢復後，若語音仍異常，請把 UDP、TUN 與路由器環境當成另一條平行線，與 Steam／Epic 類排查共用同一套心智模型。

在同一套規則語意下管理桌面程式，長期維護成本通常低於多款工具拼湊。若您尚未安裝 Clash 系列用戶端，可先從本站取得對應平台版本，並搭配 教學文件完成基礎設定。