前言：先分清會議卡頓的原因
遠端工作時，視訊會議、即時訊息與雲端文件常同時使用網路。畫面凍結、聲音斷續或 Slack 訊息延遲，不一定代表代理節點太慢，也可能是 Wi-Fi 訊號不穩、上傳頻寬不足、VPN 疊加、DNS 解析異常，或 Clash 把流量送到不合適的線路。若只是不斷切換節點，問題可能短暫改善，卻很難找出真正原因。
Clash 的作用是按規則替不同連線選擇路徑，而不是自動讓所有網路變快。設定時應先確認所在地網路能否直連會議服務，再決定 Zoom、Slack 與 Google Meet 要使用 DIRECT，還是交由穩定的代理策略組。也要保留本地網站直連，避免日常辦公網站繞遠路，增加延遲或造成登入驗證異常。
設定目標
讓會議流量使用經測試較穩定的路徑、避免節點頻繁變動，並讓本地網站與內部服務維持直連；完成後再以實際通話測試確認效果。
1先整理規則與策略組
Clash 依照 rules 的排列順序，由上往下比對，命中第一條規則後便會採用相應策略。因此，會議服務的專用規則應放在較廣泛的規則集和最後的兜底規則之前。若它們排在 GEOIP、通用代理規則或 MATCH 之後，後面的專用設定可能永遠不會生效。
以下範例假設設定檔已有名為「會議線路」與「其他代理」的策略組。策略組名稱必須與你的設定檔完全一致；若沒有相同名稱，請先在客戶端的策略組中建立，或改成現有組名。不要直接把範例整段貼到設定檔任意位置，也不要覆蓋訂閱提供的整份規則。
- 備份目前使用的設定檔，並確認客戶端載入的是你準備修改的配置。
- 在
rules:區塊中，將 Zoom、Slack 與 Meet 的精確網域規則放到通用規則之前。 - 確認每條規則最後的策略名稱存在；本例中的「會議線路」只是示範名稱。
- 保留既有本地網域、私有 IP 與區域直連規則，不要為了加速會議而移除它們。
- 檢查
MATCH或其他兜底規則仍位於最末端，並在套用後查看連線記錄。
不要盲目複製通用網域
Google 服務共用許多網域。把整個 google.com 一律送往會議線路，可能連 Gmail、搜尋或其他服務也一起改道。範例中的 Google 直連規則只適合本地直連穩定的環境；若 Meet 無法正常連線，應透過連線記錄找出實際命中的網域，再加入更精確的規則，而非不加判斷地擴大匹配範圍。
2為 Zoom、Slack 與 Meet 挑選合適路徑
會議品質不只看下載速度。視訊通話同時仰賴低延遲、低抖動、穩定上傳，以及連線不中斷。節點測速結果再高，如果尖峰時段丟包、路由忽快忽慢，實際通話仍可能出現聲音破裂或畫面停格。測試節點時，建議在相近時段進行數分鐘通話，並同時觀察延遲變化、丟包情況與上傳穩定性。
Zoom：先比較直連與固定節點
如果本地網路到 Zoom 服務的路徑順暢，可以先讓 Zoom 直連，通常能避免代理路徑額外增加的延遲。若直連連線不穩、會議無法加入，或當地網路對相關服務有限制，再測試一個穩定的近區節點。選定後盡量固定使用同一地區與策略，不要在會議進行中反覆切換，否則現有連線可能中斷並重新建立。
Slack：重視長連線與固定出口
Slack 不只有訊息頁面，也會使用即時連線與檔案服務。若訊息持續顯示連線中、通知延遲或附件下載失敗，可以檢查連線記錄中命中的 Slack 相關網域，確認是否落到錯誤策略。若工作環境需要代理，為 Slack 使用穩定的策略組，通常比頻繁更換出口更容易維持連線。規則應依照實際記錄補足，不必把所有包含相似關鍵字的網域都導向代理。
Google Meet：避免誤把整個 Google 生態改道
Meet 可能依照瀏覽器、帳戶、地區與會議狀態使用不同服務端點。可先以瀏覽器加入測試會議，檢視 Clash 的連線記錄，再判斷相關連線是否命中預期策略。若公司 Google Workspace、郵件或內部文件平常可正常直連，應避免為了 Meet 將所有 Google 流量改走同一個代理；只調整確實需要的服務網域，並在每次變更後重新測試會議。
節點挑選小撇步
先選地理位置較近、通話時延遲穩定且上傳不易掉速的節點。自動選擇策略可用來初步比較，但重要會議前最好手動固定已測試的線路，並保留可立即切換的備用節點。
3保留本地直連並逐步驗證
遠端工作不代表每個連線都應透過代理。本地銀行、政府入口網站、公司內網、印表機或區域雲端服務，若原本能直接連線，通常應保留 DIRECT 路徑。可沿用訂閱中的區域直連規則、私有網段規則與公司 IT 部門提供的網域清單；避免自行加入範圍過大的規則，否則可能讓原本需要代理的服務意外直連，或讓內部資源被送往外部節點。
在 Clash Verge Rev 或其他 Mihomo 客戶端中，修改設定前先複製一份設定檔作為備份。若使用訂閱配置，留意直接編輯產生的設定可能在更新訂閱時被覆蓋；可使用客戶端支援的覆寫或擴充規則方式，並確認產生後的最終配置仍包含你的會議規則。不同客戶端介面名稱可能不同，原則是檢查「實際載入的規則」與「最終規則順序」，而不是只確認文字曾經貼入編輯器。
按順序做一次完整測試
- 先關閉多餘的 VPN、代理或加速器，避免多層轉發造成路徑難以判斷。
- 使用 Clash 連線記錄確認 Zoom、Slack 或 Meet 連線命中的網域、規則與策略組。
- 分別測試直連和代理路徑，每次只改一項設定，記錄延遲、畫面穩定度、聲音與訊息推送情況。
- 用同一台裝置、同一個網路及相近時段比較結果；若多個裝置同時上傳大型檔案，先暫停同步再測一次。
- 測試本地網站、公司內網與會議服務，確認直連項目沒有被送入代理，會議項目也沒有誤命中兜底規則。
- 確認穩定後保留備份，並把已驗證的節點與回退方式記下來，以便重要會議前快速處理。
若開啟 TUN 模式，請確認客戶端已取得必要權限，且系統防火牆沒有阻擋虛擬網卡或 UDP 連線。TUN 能處理部分不遵循系統代理設定的應用流量，但並不保證每種會議故障都能因此解決；若只有某一款軟體異常，先對照連線記錄與其他裝置測試結果，再決定是否調整模式。DNS 設定也應維持一致，避免解析結果與所選路徑不匹配。
完成判斷
會議能穩定加入、語音與畫面連續，Slack 訊息推送正常，本地網站仍可直連，且連線記錄顯示規則命中預期策略，才算完成設定。若代理路徑反而更慢，恢復原配置並優先排查 Wi-Fi、頻寬或公司網路限制。
不同網路環境、服務端點與訂閱規則都可能影響結果，因此不要把單一網域清單視為永久通用方案。工作帳戶與公司網路也可能受到管理政策限制；涉及內部會議或敏感資料時，請遵循組織的資訊安全要求，並向 IT 管理員確認允許的連線方式。