居家辦公時，視訊會議卡頓不一定是節點速度不足。問題也可能出在應用程式沒有使用系統代理、會議媒體流量走了不同路徑、DNS 回覆與實際出口不一致，或家中 Wi-Fi 上傳頻寬不足。設定 Clash 分流前，先確認要解決的是哪一類問題：公司服務無法連線、語音與畫面不穩，還是一般網站不希望跟著代理。
本文以採用 mihomo 核心的用戶端為例，說明如何讓 Zoom、Slack 與 Google Meet 使用指定代理策略，同時讓其他流量維持原有路徑。不同服務會調整網域、媒體伺服器與連線方式，規則範例只能作為起點；應以實際連線記錄和會議測試結果確認，不要把範例當成完整服務網域清單。
先規劃工作流量：分清代理、直連與接管
Clash 的規則只會處理已進入核心的連線。系統代理通常只影響遵循作業系統代理設定的程式；若 Zoom 或其他桌面應用程式忽略系統代理，單靠切換規則模式不會讓它自動經過節點。TUN 可透過虛擬網卡接管更多 IP 流量，包含部分不遵循系統代理的應用程式，但仍受權限、路由排除、其他 VPN 與核心設定影響。
開始設定前，先確認用戶端正在使用的核心名稱與版本。Clash Meta 後續以 mihomo 名稱發展，不同核心支援的規則類型和設定欄位可能不同。也要確認訂閱中的策略群組名稱，例如 PROXY、手動選擇 或 自動選擇；下方的 Work-Proxy 只是示意名稱，必須替換成目前設定中確實存在的群組。
| 流量類型 | 常見處理方式 | 適用考量 |
|---|---|---|
| Zoom、Slack、Meet 會議服務 | 指定工作用代理群組，或按測試結果直連 | 以公司政策、服務可達性和實際媒體品質決定 |
| 公司內網、印表機、NAS | 通常保留直連 | 確認內部網域與私有 IP 不會被一般代理規則攔截 |
| 一般網站與非工作應用程式 | 依個人設定維持直連或使用原有代理群組 | 避免把所有流量一併送往工作節點 |
| 未命中上述條件的連線 | 由最後的兜底規則處理 | MATCH 應放在規則清單末尾 |
挑選會議出口：延遲不是唯一指標
視訊會議同時涉及訊號控制、音訊、視訊與螢幕分享等連線。頁面能開啟或節點延遲測試成功，不代表會議媒體流量也穩定。部分連線可能使用 TCP/TLS，媒體則可能使用 UDP；若 UDP 不通，應用程式有時會改用其他傳輸方式，但是否能順利回退及其品質，會受網路與服務端狀況影響。
選節點時，優先比較實際會議中的延遲波動、丟包、音訊連續性和畫面凍結情形，而非只看用戶端顯示的單次延遲。出口位置也會影響路徑：選擇距離與服務端網路路徑較合適的節點，未必等同選地理位置最近的節點。若公司要求特定地區出口，應依政策選擇，不能只追求測試數字。
| 觀察項目 | 可能代表的問題 | 建議測法 |
|---|---|---|
| 音訊斷續、延遲明顯 | 上傳壅塞、無線訊號不穩、路徑抖動或丟包 | 先改用有線網路或靠近路由器，再固定節點比較 |
| 會議可加入但沒有畫面 | 媒體連線與登入控制流量可能走不同路徑 | 查看核心連線記錄，確認會議期間是否有 UDP 連線失敗 |
| 只有某個節點無法加入 | 出口被服務限制、DNS 結果不同或節點本身不穩 | 保持其他設定不變，換一個已知可用出口重測 |
| 一般瀏覽正常，會議仍卡頓 | 網頁測試不等同即時媒體測試 | 在相同會議、相同網路下比較直連與代理 |
家用網路的上傳頻寬常比下載頻寬更容易成為瓶頸。多人同時備份檔案、同步雲端資料或上傳影片，可能讓視訊品質下降；此時更換節點未必能改善。測試前暫停大型上傳，並記錄有線或 Wi-Fi、測試時間、選用節點與會議狀況，才能比較出真正有效的調整。
動手設定：建立工作群組並逐條驗證
步驟一：確認策略群組
先在目前設定或用戶端的策略群組頁面確認可用群組。可以沿用訂閱提供的手動選擇群組，也可以在自訂設定中建立工作群組，但群組引用的節點或子群組必須已存在。若使用覆寫或合併設定，請先確認訂閱更新不會覆蓋自訂內容，且最終執行設定沒有重複定義同一個 YAML 鍵。
如果目前沒有合適的群組，不要直接照抄未知名稱。以下範例中的 Work-Proxy 必須換成真實策略群組；若要測試直連，則將工作服務規則的目標暫時改為 DIRECT。每次只改一種路徑，較容易判斷是代理出口還是規則本身造成差異。
步驟二：在兜底規則之前加入網域規則
在現有 rules 中加入經核對的服務網域，並置於 MATCH 等兜底規則之前。下方只示範常見網域形式，不是 Zoom、Slack 或 Google 的完整清單；服務可能使用登入、訊號、媒體及 CDN 等不同網域。避免直接把整個 google.com 或大型共用 CDN 網域全部送往同一出口，否則可能連一般搜尋、雲端服務也一起改道。
rules:
- DOMAIN,meet.google.com,Work-Proxy
- DOMAIN-SUFFIX,zoom.us,Work-Proxy
- DOMAIN-SUFFIX,zoom.com,Work-Proxy
- DOMAIN-SUFFIX,slack.com,Work-Proxy
- MATCH,原有兜底策略此片段必須合併至現有設定，不能在同一個 YAML 層級另建一份重複的 rules:。示例中的最後一行也要保留原設定實際使用的兜底策略名稱。規則由上而下比對；若前面已有涵蓋範圍更廣的網域或 IP 規則，後面的工作規則可能永遠不會命中。變更後先使用用戶端的設定檢查功能，確認 YAML 可解析、群組名稱存在，再套用設定。
步驟三：確認應用程式流量確實進入核心
啟用規則後，打開核心連線記錄，開始一次測試通話，查看 Zoom、Slack 或 Meet 相關連線的網域、連線類型與命中的策略。若只看到瀏覽器連線，桌面版應用程式卻沒有相應記錄，可能是應用程式未遵循系統代理；在支援的 mihomo 用戶端上，可評估啟用 TUN，並確認系統授權、路由和 DNS 接管設定。不要在未了解用途時直接複製其他人的完整 TUN 區塊，欄位與預設值可能因核心版本及作業系統而異。
若記錄顯示規則已命中，但會議媒體仍不穩，檢查是否有 UDP 連線、是否被其他 VPN 或防火牆阻擋，以及服務是否改用未涵蓋的網域或 IP。mihomo 可依設定對連線進行網域嗅探，但嗅探不是萬無一失的域名清單替代品；若連線使用 IP 直連、加密方式限制辨識，或 DNS 資訊沒有保留，單靠網域規則可能無法分類。請以核心記錄和服務端的連線診斷為準，不要為了讓規則「看起來完整」而大量加入未驗證網域。
測試分流與排錯：一次只改一個變數
完成規則後，依序測試登入、加入會議、雙向音訊、攝影機畫面及螢幕分享。每一輪固定相同裝置、網路、會議服務與測試時間，先測直連，再測指定代理；不要同時切換節點、DNS、TUN 和規則模式。若直連穩定而代理失敗，問題較可能與出口、節點路由或代理對 UDP 的處理有關；若兩者都不穩，優先排查 Wi-Fi、上傳佔用、路由器和本機防火牆。
- 在 Clash 用戶端確認目前生效的設定、核心名稱與核心版本，並記下規則模式和工作群組所選出口。
- 清楚記錄測試條件，例如使用 Wi-Fi 或乙太網路、是否有其他 VPN，以及是否正在上傳大型檔案。
- 開始會議後查看核心連線記錄，確認目標網域命中預期群組，且實際出口不是另一個巢狀群組意外選出的節點。
- 若服務網域沒有命中，檢查規則順序、DNS 與嗅探結果、TUN 是否接管該應用程式，以及是否有更早命中的廣泛規則。
- 只更換一個節點或只調整一條規則，再重複同一項測試；每次變更後記錄結果，避免多項修改互相遮蔽。
DNS 設定與代理規則也要分開判斷。DNS 上游負責解析網域，規則則決定已進入核心的連線使用哪個策略；把 DNS 改成 DoH 不會自動令 Zoom 或 Slack 經代理，也不保證瀏覽器、桌面程式和 TUN 流量使用相同解析路徑。若改規則後仍連到舊位址，可關閉並重新開啟應用程式、等待 DNS 快取更新，再查看新的連線記錄。
讓工作與一般流量各走合適路徑
完成驗證後，再決定兜底流量要直連或使用原有代理群組。工作網域規則只影響命中的連線；瀏覽器中的其他網站、雲端硬碟與系統更新仍由後續規則處理。若目標是只代理會議服務，請保持規則範圍精簡，並避免使用涵蓋整個大型服務商網域的寬泛匹配。若公司服務仰賴多個動態網域，應透過連線記錄逐步補充，且每次核對是否誤傷其他網站。
當會議結束後，不需要為了恢復一般瀏覽而頻繁切換全域模式。保留規則模式，讓明確的工作網域走指定策略，其餘連線依既有規則處理，通常更容易維護。若更新訂閱或切換核心後分流突然改變，先比較最終生效設定與核心記錄，再檢查群組名稱和規則順序；不要只因用戶端介面顯示「已連線」就判定所有工作流量已按預期分流。