為什麼「會議軟體＋Clash」特別容易半套故障？
多數使用者直覺以為：既然瀏覽器能上網，桌面版 Zoom／Teams 也該一樣順。實務上，會議用戶端同時依賴多條通路：帳戶登入、行事曆與附件、會議信令（通常為 TCP／TLS），以及即時音視訊（高度依賴 UDP 與 WebRTC 家族行為）。Clash 在「規則模式」下會依網域、IP、處理序等條件把連線導向 DIRECT 或某個策略組；只要其中任一條腿走向延遲高、丟包嚴重、或與公司防火牆策略互斥的出口，你就會看到「看得到投影片、聽不出聲音」「別人說你在機器人音效」或視訊定格。
另一個隱性因素是系統代理與 TUN 的覆蓋範圍不同：僅開啟系統 HTTP 代理時，部分應用程式的 UDP 仍可能繞過你以為的鏈路；改開 TUN 後，路由較一致，卻也可能讓本來靠直連才通的內部媒體中繼改走錯誤節點。兩者沒有絕對好壞，必須用症狀＋日誌交叉驗證。若你對規則骨架與策略組命名仍不熟，建議先讀Clash YAML 規則分流完全指南，再回來調會議專用覆寫。
信令與媒體：先把兩條路從腦中拆開
實務排查時，請刻意把流量分成兩類，避免「全都丟同一個自動測速組」：
- 控制面／信令：登入 OAuth、會議室建立、出席者列表、螢幕共享協商等，多走已知網域名上的 HTTPS。這裡適合用
DOMAIN-SUFFIX精準命中，並觀察是否與你期望的出口國別一致（影響授權與合規偵測）。 - 媒體面／RTC：音訊、視訊編碼後的RTP／RTCP流，可能在動態埠與多個後端 IP間遷移；遇到 NAT 嚴格或企業網路時，又會退回 TURN 中繼。這裡的典型症狀是延遲飄高、馬賽克、單向無聲，且與節點 TCP 延遲不一定相關。
當兩條路徑的出口國別或延遲特性不一致時，客戶端常出現「會議顯示已連線但媒體統計丟包飆升」的怪現象。此時盲目切換訂閱裡的自動測速, 只會讓信令與媒體更難對齊；應先固定一組穩定代理或刻意全部直連做對照實驗，再用日誌收窄真正的斷點。
Zoom：建議優先覆蓋的網域與思路
Zoom 生態高度品牌化，實務上常見的登入與網頁資源分布在 zoom.us、zoom.com 與相關子網域；桌面／行動用戶端亦會連到 CDN 與更新檢查主機。由於細分子網域會隨產品線更新，本文不宣稱「一份規則用到退休」；你應在出問題當下開啟連線日誌，把實際出現的 SNI／Host截下來補進自己的 rule-providers 或手寫清單。
操作上可為 Zoom 建立獨立策略組（例如 ZOOM），把下列類型條目置於寬鬆 GEOIP／MATCH 之前（名稱僅示意）：
# Illustrative snippets — replace ZOOM with your proxy-group name
rules:
- DOMAIN-SUFFIX,zoom.us,ZOOM
- DOMAIN-SUFFIX,zoom.com,ZOOM
- DOMAIN-SUFFIX,zoomgov.com,ZOOM
若你任職政府或受管制單位，可能使用與商業版不同的主機命名空間；請以 IT 公告與實測日誌為準。若 Zoom 網頁能開、進房後卻長時間「連線中」，下一節的 UDP／TURN 排查通常比再加更多 DOMAIN 規則更關鍵。
Microsoft Teams：Office 365／Microsoft 365 邊界
Teams 並非孤島，它嵌在 Microsoft 365 服務邊界內，與 Exchange、SharePoint、OneDrive、Identity 平台共享大量身分驗證與 API。微軟官方維護可下載的端點清單（依產品與區域會變動），企業管理員亦常設定分流或代理旁路。對個人用戶而言，實務建議是：不要用「一條 *.microsoft.com 打天下」這種過寬規則，而是把日誌裡真的出現的會議相關主機收斂到同一策略組，並保留對登入與授權主機的正確處置。
常見症狀「Teams 聊天與檔案正常，會議卻進不去」往往代表：Graph／SharePoint 類網域已命中預期出口，但媒體／TURN相關目標仍落在錯誤策略，或被公司網路要求固定出口 IP。此時可暫時關閉「會議中自動切換節點」行為，改用手動固定節點對照；若改用 TUN 後明顯改善，則可回頭檢視系統代理時UDP 漏路徑問題。更全面的系統代理與虛擬網卡差異，可交叉閱讀Clash TUN 與系統代理教學。
STUN、TURN 與防火牆：為什麼「媒體規則」難寫
STUN負責在複雜 NAT 後方探測可連線的位址／埠映射，讓端點彼此知道往哪裡送 RTP。TURN則在點對點失敗時強制中繼，保障會議能成立，但會帶來額外延遲與頻寬成本。許多企業防火牆會限制 UDP 或未知目標埠，導致客戶端悄悄退回 TCP 中繼或直接放棄音訊。
對 Clash 使用者而言，重點不是背誦 STUN 封包格式，而是理解：媒體連線可能以 IP:port 形態出現，不一定再帶你熟悉的 zoom.us 字樣。此時過度依賴 DOMAIN 規則會漏網；你可能需要：
- 在可信環境短暫改用 全域規則或固定代理，觀察媒體是否恢復，藉此判斷「策略組選錯」還是「節點不轉發 UDP」。
- 對照客戶端內建的網路統計／診斷（若企業政策允許），看是否顯示 RTP 丟包或 TURN 逾時。
- 若同網路下的手機 4G／5G正常、公司 Wi‑Fi 異常，多半是內網 UDP 或 TLS 檢查造成，與 Clash 規則無關；此時應找 IT 開通或改用個人熱點對照，而非無限堆規則。
步驟一：用連線日誌畫出「真實路徑」
開始改規則前，請固定一個可重現場景（例如「加入同一測試會議室三十秒」），並在 Clash 面板或日誌檔中記錄：
- 出現的目標網域與首次命中規則：是否先被某條寬鬆規則攔走？
- TCP 與 UDP 是否分別記錄：若完全看不到 UDP，可能代表沒有走 TUN／或客戶端根本沒發出。
- 同一會議中是否有大量不同 AS／國家 IP：可能觸發供應商風控或 QoS。
這套記錄要能回答兩個問題：「信令走哪？」與「媒體走哪？」若答不出第二個，請勿急著下結論換訂閱商；先把日誌補齊。與語音類 App 類比的排查節奏，亦可參考Discord 語音與 UDP 分流專文——情境不同，但「TCP 正常、UDP 慘」的分割思路相通。
步驟二：對照 TUN 與系統代理，縮小「漏 UDP」區間
若你目前僅使用系統代理，且症狀集中在音訊，建議安排兩輪對照：同一組規則下先測系統代理，再測 TUN（或作業系統允許的全域透明代理）。若第二輪顯著好轉，則優先懷疑應用程式未正確接入系統代理堆疊，而非規則本身錯誤。
開啟 TUN 後若反而全斷，常見原因是覆寫路由與公司 VPN 衝突、或 DNS loop。可把「內網段直連」「本機直連」類規則放回首段，必要時暫停與虛擬網卡互斥的第三方安全軟體再做實驗。記住：TUN 是放大器——它讓正確規則更穩，也會讓錯誤路由更明顯。
步驟三：確認節點與協定能力（UDP、IPv6）
不是所有獨立伺服器線路都願意或能夠穩定轉發大量會議用 UDP。若日誌顯示媒體類連線頻繁重試或瞬断，而同一節點瀏覽 YouTube 沒事，仍可能是對 UDP 不友善。可嘗試：
- 暫時改用手動選擇的低負載節點，避免「自動測速每十秒換出口」干擾長連線。
- 若你家裡網路啟用IPv6，確認是否發生「應用走 v6、規則卻只覆蓋 v4」的錯配；雙堆疊議題可對照IPv6 與分流核對專文。
- 在路由器或公司邊界已存在另一層 NAT 時，考慮讓會議直連做對照，確認問題是否純粹累積延遲。
步驟四：整理了網域，還要把規則順序寫對
會議相關 DOMAIN-SUFFIX 建議集中成單一策略組，並放在過寬的媒體／GEOIP 規則之前。若你把 Netflix、Disney+、泛用「國際媒體」類規則寫得太前段，且底下意外涵蓋了共用 CDN 名稱，可能把 Zoom／Teams 的一部分切片送去不適合的節點。這也是為什麼本文強調與串流解鎖類需求分開思考：後者多半容忍短暫切點；前者要求長連線穩定。
若你使用 fake-ip，也要確認解析與規則命中是否讓日誌「看得懂」；必要時對特定網域改用 redir-host 做 A／B 測試。DNS 模式與本機解析互動，可延伸閱讀Fake-IP 與 Redir-Host 教學以免誤判。
什麼時候該讓會議直連？
以下情境常見且合理：你在公司內網，IT 已為 Teams／Zoom 配置專用 SBC 或本地突破；此時強制把流量塞進海外節點反而造成媒體繞地球。另一種情況是供應商鎖企業授權地區，頻繁換出口 IP 會觸發裝置驗證或會議權限降級。
相反地，若你必須在受限網路下連到境外帳戶，且直連幾乎不可能建立媒體通道，就必須找一條真能扛 UDP、且延遲可接受的代理出口，並接受這可能與公司資安政策衝突——這屬於合規範疇，技術文章無法代你拍板。務必在允許範圍內測試。
常見問答（精簡版）
只做「規則分流」、不開全域，為什麼還會卡？ 規則分流只決定命中後走向；若命中本身太寬鬆、DNS 行為與預期不符、或 UDP 根本沒進代理，仍會卡。
手機客戶端比桌面穩，是不是電腦壞了？ 不一定是硬體問題；手機可能走行動網路直連或不同 API，請用同一網路條件對照。
需要把 TURN 伺服器域名全背下來嗎？ 不需要；以日誌與官方端點清單迭代補齊即可，重點是迭代流程而不是一次寫死。
寫在最後：把會議當「多協定專案」來分流
Zoom 與 Microsoft Teams 的卡頓、無聲、掉線，在 Clash 語境裡多半是信令網域、WebRTC 媒體、UDP／TURN／STUN 與本機代理型態（系統代理或 TUN）之間沒對齊，而非單一「爛節點」可解。當你願意用連線日誌畫出兩條路徑，並用本文的順序先縮小 UDP 漏路徑、再收斂 DOMAIN 規則順序，調參會快很多，也比反覆重置客戶端來得科學。
若你需要可匯入的訂閱、較新的 Meta 核心與圖形化策略控制，歡迎從本站下載頁面取得對應平台版本，把力氣花在會議本身而不是反覆試錯。
更多場景化教學可在技術專欄依分類瀏覽；把 YAML 骨架跑通後，企業會議覆寫只需小步迭代即可長期維護。