Discord 語音總掉線？Clash TUN 與 UDP 規則逐步排查（2026）| Clash

為什麼「文字正常、語音掉線」特別像代理路徑問題？

Discord 的文字與頻道列表多半走常見的 HTTPS（TCP）連線；只要規則大致正確，您會覺得「能用」。但語音通話牽涉大量UDP 與即時媒體，常見症狀是延遲突刺、每秒斷音、他人聽不到您、或顯示連線品質極差。若同一時間文字仍順，優先懷疑的不是「Discord 伺服器全面掛掉」，而是只有 UDP 沒走您預期的代理出口，或走了代理但節點對 UDP 不友善，或規則／DNS 對 UDP 與 TCP 給了兩套答案。

另一個容易誤判的點是：您以為開了「系統代理」＝整個 Discord 都走了 Clash。實際上，許多桌面程式仍會依自身邏輯選路，或以 QUIC／HTTP3 走不同通道；在沒有TUN 或沒有完整路由接管時，日誌看起來就像「同一個 App、兩種網路行為」。因此排查的第一步永遠是把觀測寫進連線日誌，而不是只靠主觀感受換節點。

Discord 語音背後：UDP、WebRTC 與可能的 QUIC

實務上您不需要先背協議細節，但要有一個心智模型：TCP 承載的網頁與登入與承載語音的 UDP 流，在作業系統裡可能是兩條完全不同的路徑。Clash 系客戶端若要統一它們，通常依賴規則模式加上正確覆蓋應用程式的轉送層；而TUN往往比單純 HTTP／HTTPS 系統代理更容易把這些流量抓進同一套規則表。

當瀏覽器或客戶端使用 HTTP/3（QUIC） 時，您也可能在日誌裡看到UDP 443 類型的連線。若域名尚未被 Sniffer 還原，規則仍可能先以 IP 命中，表象就是「同樣是 Discord，有時走對策略、有時像直連」。因此本文後段會把 Sniffer 與規則順序放在一起談，而不是只寫域名清單。

系統代理與 TUN：語音行程更需要哪一種？

系統代理（System proxy）對瀏覽器一般有效，但對部分桌面 VoIP／遊戲類流量未必完整；TUN 模式則在較底層分配流量，通常更容易讓「不知道為什麼沒跟系統代理的行程」也進入 Clash。若您目前只用系統代理而語音仍異常，請不要先堆規則，而是先確認客戶端是否已用下列方式完成基礎設定：Windows 可對照 Clash Verge Rev Windows 安裝與初始設定；接著閱讀 Clash Verge Rev TUN 模式開啟教學，檢查虛擬網卡、服務模式與權限是否就緒。

實務建議：排查時一次只改一個變數：先固定節點，再切換「僅系統代理」與「TUN 啟用」，比較同一段語音測試中的日誌差異。

1步驟一：在連線日誌中明確找 UDP 與策略名稱

請在 Mihomo（Clash Meta）圖形客戶端開啟詳細連線／日誌，進入語音頻道後觀察：是否出現大量目標為公網 IP 的 UDP？這些連線命中哪個策略組（或直接顯示哪個 outbound）？如果您只看到 Discord 相關 TCP、卻幾乎沒有 UDP，代表語音根本沒進入您預期的轉發路徑；若 UDP 有，但命中策略與您所想不同，則回到規則順序修正即可。

同時請留意客戶端是否把某些連線標記為「繞過」或落在 DIRECT：語音類流量一旦被前置的大型 RULE-SET 或 GEOIP 規則提前定案，後面那條專門寫給 discord 的規則永遠不會生效。這也是「我明明寫了規則卻沒用」的最高頻原因，與 AI 類網頁長文常見坑位相同。

2步驟二：把 Discord 流量寫進規則，並讓 UDP「跟著走」

具體域名會隨 Discord 調整而變動，因此下列清單是起點，仍需以您的日誌為準補齊；重點在於規則類型與插入位置，而不是背誦每個子網域。一般可優先檢查是否出現 discord.com、discordapp.com、discord.gg、CDN 類主機與語音伺服器 IP 段；實際仍以連線日誌中的 SNI／Host／IP 為準。

下列 YAML 片段僅示範結構，請將 PROXY 替換為您實際策略組名稱，並合併進既有 rules:；註解使用英文以符合設定檔慣例。

# Example — replace PROXY; verify UDP/TCP hits in client logs
rules:
  - DOMAIN-SUFFIX,discord.com,PROXY
  - DOMAIN-SUFFIX,discordapp.com,PROXY
  - DOMAIN-SUFFIX,discord.gg,PROXY
  # Add log-observed hosts (CDN, voice region, updates), e.g.:
  # - DOMAIN-SUFFIX,cloudflare.com,PROXY
  - MATCH,DIRECT

請記得：PROXY 指的是「選定的節點／策略組必須真的能轉發 UDP」；若您用的是對 UDP 支援不佳或供應商限制的出口，日誌即使命中策略，體感仍可能是「反覆重連」。這屬於節點能力問題，不是再多寫兩行 DOMAIN 就能解決。

規則優先順序：別讓 GEOIP／大規則集先終結比賽

Clash 系由上而下匹配，第一條命中的規則就定案。很多使用者把 Discord 相關行放在清單底部，但上方已有寬鬆的 GEOIP、國內直連或大規則集，導致 TCP 誤打誤撞還能連，UDP 卻落到另一個出口，於是出現「文字湊合、語音炸裂」的組合症狀。調整期間，建議先把 Discord 相關條目移到您理解的安全區段（仍保留區網與本機例外），每改動一次就重新對照日誌。

Sniffer 與 QUIC：HTTPS 規則為什麼要「看得到域名」？

當連線以 IP 呈現在日誌裡，而您又使用 DOMAIN／GEOSITE 類規則時，可能出現匹配失敗；Clash Meta 上的 Sniffer 可用於從 TLS／QUIC 等資訊還原域名，讓規則命中回到可預期軌道。設定觀念請讀 Clash Meta Sniffer：HTTPS 域名分流逐步配置，並把它與本節的 UDP 觀察一起做——否則您會看到「偶發正常」的錯覺。

補充：若您使用 relay 雙跳，UDP 多一層風險

在 proxy-groups 使用 type: relay 串兩跳時，TCP 已比單跳更敏感；UDP 轉發更容易出現「其中一跳不吃 UDP」或延遲倍增。若您確實啟用鏈式代理，請同步閱讀 Clash Meta relay 雙跳與故障排查，並在語音測試時對照該文提到的 UDP／QUIC 檢查項目。

DNS、FakeIP 與 TUN：別讓「解析」和「實連」各說各話

與多數場景文相同：FakeIP、redir-host 與上游 DNS 若與實際連線不一致，會讓您覺得「規則寫了等於沒寫」。語音情境下，錯配往往表現為偶發加入頻道失敗、語音伺服器輪替時突然卡死。完整觀念請讀 Meta 核心 DNS 防洩漏指南，並以「規則命中 → DNS 視圖 → 實際 UDP 出口」三段互相印證。

提醒：若同時開啟本機其他 VPN、公司安全軟體或路由器層代理，容易造成路由與 DNS雙重接管；請先縮成單一路徑再測試語音。

3建議排查順序（可列印核對）

出口是否含 UDP：固定同一節點，開啟 TUN 後再測語音；對照日誌是否出現預期數量的 UDP，並命中同一策略。
規則是否先於寬鬆條目命中：調整 Discord 相關 DOMAIN／DOMAIN-SUFFIX 的位置；若走 HTTPS／QUIC，確認 Sniffer 是否需要開啟。
DNS 與 FakeIP：排除解析落差造成的「斷在換語音區域之間」；對照 dns 區段與 TUN 是否一致。
節點與協議能力：在規則與 DNS 都乾淨的前提下，再更換不同出口；若僅在 relay 雙跳下出問題，先簡化成單跳驗證。

若您已完成以上順序仍未改善，再將問題縮小到「Discord 服務狀態／頻寬／麥克風裝置」等非代理因素；但在 Clash 使用者群體中，前四步往往能消滅多數「語音總掉線」的假性災情。

開源資訊與安裝包取得方式

Mihomo 與各圖形前端多為開源專案，原始碼與問題追蹤可在 GitHub 查閱；但日常下載與更新客戶端，仍建議以本站 Clash 下載頁為主，並搭配設定說明文件，將「安裝取得」與「開源資訊」分開理解。

結語

Discord 語音問題本質上常是UDP／WebRTC 路徑與Clash 規則／TUN 接管範圍是否一致；把文字正常的現象當成「代理已經OK」會讓排查走冤枉路。相較於來回切換節點，依「日誌裡的 UDP → 規則命中 → DNS／Sniffer → 節點能力」順序收斂，更容易定位是沒進代理、規則被別條吃掉，還是出口不適合語音。同一套可觀測流程也適用其他 VoIP／會議軟體。

在常見方案中，Clash Meta／Mihomo 加上清楚的策略組命名與日誌對照，能把「感覺卡頓」轉成可驗證的網路事實；若您希望長期穩定使用語音與翻牆並存，值得先花時間把TUN與規則表整理到可讀、可維護。

→ 立即免費下載 Clash，開啟流暢上網新體驗

Discord 語音總掉線？Clash TUN 與 UDP 規則逐步排查（2026）