前言：先找出視訊卡頓的原因
居家辦公時，視訊會議卡頓不一定代表代理節點速度太慢。Zoom、Slack 與 Google Meet 都會同時使用網頁請求、即時訊息、檔案傳輸與影音連線；若流量被錯誤分流、節點延遲過高，或 Wi-Fi 本身不穩，就可能出現聲音斷續、畫面凍結、訊息延遲或會議無法加入等狀況。
Clash 的分流設定可以讓不同服務使用合適的連線路徑，但不存在適用所有網路環境的唯一答案。若服務在本地網路可直接穩定連線，DIRECT 通常能減少額外延遲；若服務遭遇連線限制或本地路由品質不佳，則可讓相關流量走穩定的代理節點。本文以 Mihomo 相容的 YAML 規則為例，說明如何先建立獨立策略組，再逐一測試 Zoom、Slack 與 Meet。
設定原則
先維持本地網站直連，再針對會議工具細分規則；一次只調整一項，並用實際通話比較延遲、抖動與斷線情況。
1設定前先確認 Clash 與網路狀態
開始之前，先確認客戶端使用的核心支援目前配置中的規則與策略組。Clash Verge、Clash Verge Rev 等桌面客戶端的選單名稱可能不同；使用 Mihomo 核心時，可在設定或核心資訊中確認目前版本。若你使用的是由服務提供者管理的訂閱設定，請先確認客戶端是否提供覆寫或合併設定功能，避免直接修改訂閱檔後，在更新訂閱時被覆蓋。
接著記錄一組基準狀態：不開啟 Clash 時測試一般網站及會議服務；開啟 Clash 後，確認系統代理或 TUN 模式是否正常生效。記下會議中的體感延遲、是否有聲音破碎，以及共享畫面時的穩定程度。這樣調整後才能分辨改善來自規則、節點，還是網路狀況剛好改變。
先選好策略組，再添加規則
建議建立一個獨立的辦公策略組，避免會議工具和其他代理流量共用一個容易頻繁切換的自動選擇組。以下範例使用名為 RemoteWork 的策略組；請將範例中的節點名稱換成自己配置內實際存在的名稱。如果已有合適的策略組，也可以直接沿用，但規則中的組名必須完全一致。
小撇步
先選擇固定節點進行測試，不要在重要會議中頻繁切換地區或使用快速變動的負載均衡組。切換出口 IP 後，部分服務可能需要重新連線或重新驗證。
2為 Zoom 選擇低延遲路徑
Zoom 對延遲與抖動較敏感，下載速度高並不一定代表通話品質好。若本地網路能直接穩定連線，先測試直連；若加入會議失敗、媒體連線不穩，或直連時品質明顯較差，再將 Zoom 相關網域交給辦公策略組。不同地區、網路供應商與帳戶使用情況可能不同，因此不要只根據網域名稱就假設所有流量都必須走代理。
在規則中使用較明確的網域後綴，並將規則放在較寬泛的規則之前。以下範例提供一種可測試的做法；如果你的目標是直連，將 RemoteWork 改為 DIRECT 即可。
- 開啟配置檔案或客戶端提供的覆寫設定，找到
rules區段。 - 將 Zoom 規則放在一般網域規則與最終規則之前。
- 儲存並重新載入配置，確認規則語法有效後再加入 Zoom 會議測試。
如果你所在網路可直接連到 Zoom，可以把以上三條規則的策略改為 DIRECT，或先只測試其中一種路徑。不要同時加入過寬的關鍵字規則，再把大量無關網域導向代理；過度匹配可能令其他網站也改變路徑，反而增加排查難度。若會議只在共享畫面或特定網路下出問題，也要檢查本機防火牆、路由器及網路品質，因為單靠域名分流不一定能解決影音傳輸問題。
3配置 Slack 與 Google Meet 分流
Slack 除了網站與訊息連線，也會使用不同網域傳送檔案、圖片及其他資源。若只有主站可以開啟，但訊息長時間顯示連線中、檔案預覽失敗或通知延遲，可以逐步測試是否有相關子網域未套用預期策略。為避免規則影響不相關的服務，可先從已知的 Slack 網域後綴開始，並檢查客戶端的連線記錄或規則命中資訊。
Google Meet 的網頁入口、會議服務與媒體連線不一定都能由單一網域規則完整涵蓋；媒體路徑也可能依網路環境而不同。以下只列出可供排查的明確網域範例，不代表涵蓋所有連線。尤其 googleapis.com 等較廣泛的網域可能被其他 Google 服務共用，不建議未經測試就一律加入代理規則。
將 Slack 或 Meet 設為 DIRECT 或 RemoteWork，應以實際測試結果決定。若本地路徑穩定，直連往往能減少繞路；若直連無法登入、訊息無法更新，才測試固定且延遲較低的節點。Slack 工作區或企業管理者也可能設定登入與安全政策，遇到驗證問題時應先確認帳戶狀態，不要只靠更換節點反覆嘗試。
注意規則順序
Clash 通常依序比對規則，先命中的規則會決定流量去向。若前面已有涵蓋 Slack、Google 或全部流量的規則，新增的細分規則可能永遠不會命中；請把辦公工具規則移到較泛用的規則之前。
4逐項測試並處理常見問題
配置載入成功後，不要只用瀏覽器開啟網站來判斷設定是否有效。先確認 Clash 的連線記錄中，Zoom、Slack 與 Meet 的請求是否命中預期規則，再分別進行登入、訊息收發、檔案傳送與視訊通話測試。每輪只變更一個策略或節點，並在相同網路與相近時段比較結果。
| 測試項目 | 觀察重點 | 建議排查方向 |
|---|---|---|
| Zoom 通話 | 音訊延遲、畫面抖動、重新連線 | 對比 DIRECT 與固定節點，並檢查 Wi-Fi 訊號及網路抖動 |
| Slack 協作 | 訊息更新、檔案上傳及預覽 | 檢查相關網域是否命中預期策略，避免節點頻繁切換 |
| Google Meet | 加入會議、麥克風與攝影機、螢幕分享 | 分開測試入口與媒體品質，檢查瀏覽器權限及防火牆 |
| 本地網站 | 常用網站是否仍可正常載入 | 確認本地網域規則與原有直連規則未被新規則覆蓋 |
遇到問題時的排查順序
- 確認規則有命中：在客戶端連線記錄中查看實際網域、命中規則與使用的策略。如果沒有命中，檢查規則位置、網域拼寫及核心支援情況。
- 分別測試直連與代理：保持其他設定不變，只切換該服務的策略。若兩種路徑都不穩，問題可能在本機網路、服務端或防火牆，而非分流規則。
- 確認 TUN 與系統代理狀態：有些應用不完全遵循系統代理設定。需要接管系統流量時，可確認 TUN 模式是否啟用、權限是否允許，以及是否與其他 VPN 或虛擬網卡軟體衝突。
- 保留回復方式：修改前備份原配置；若載入失敗、網站分流異常或會議品質變差，先還原新增規則，再逐條加入測試。
DNS 設定也可能影響網域解析與規則判斷。若遇到解析結果不一致，可先檢查目前配置的 DNS 模式及客戶端記錄，避免同時更改 DNS、節點與規則，導致無法判斷問題來源。完成測試後，保留已確認有效的最小規則集，並在更新訂閱或核心後再次檢查規則是否仍然生效。穩定的遠端辦公配置，重點不是把所有流量都送進代理，而是讓每一類連線走可預期、容易維護的路徑。
如果尚未安裝客戶端，可先依照使用的平台選擇合適版本，再匯入配置並套用規則。