先釐清遠端工作流量：為什麼 Zoom、Slack 不該一律走同一條路
遠端工作時，視訊會議、聊天同步、檔案分享與公司內部服務通常同時發生，但它們對網路的要求並不相同。Zoom、Google Meet需要穩定的 UDP 或長時間媒體連線，最怕高延遲、丟包與節點在會議中途切換；Slack則除了訊息 API，還會連到檔案、圖片、通知與工作區相關的多個網域。另一方面，公司內網、印表機、NAS、銀行網站或所在地的公共服務，通常更適合維持直連。
因此，Clash 的重點不是把所有流量都丟進代理，而是先建立清楚的分流邏輯：需要穩定出口的協作服務交給代理策略組，需要低延遲或必須留在本地的服務則使用 DIRECT。這樣做可以避免「會議能連上，但公司內網打不開」或「Slack 訊息正常，Zoom 卻在切換節點後斷線」等問題。若你使用 Clash Verge、Clash Verge Rev 或 Mihomo，以下方法都能作為通用排錯方向；實際選單名稱則可能因用戶端版本而略有差異。
開始前也要確認你擁有可正常使用的訂閱與節點，並遵守公司資訊安全政策、所在地法規以及 Zoom、Slack、Google Meet 的服務條款。本文討論的是一般代理分流、連線穩定性與本機排錯，不涉及繞過企業存取控制或未授權存取內部資源。
把 Zoom、Slack、Google Meet 拆成可觀察的服務群組
許多使用者只把 zoom.us 或 slack.com 加進規則，卻忽略實際連線可能使用其他 API、CDN、圖片或登入網域。這會造成主頁能開啟，但登入、檔案預覽、通知或會議媒體仍然逾時。比較可靠的做法，是先啟用 Clash 的連線紀錄，依照實際使用流程記錄目的地，再決定規則範圍。
| 服務 | 主要需求 | 觀察重點 | 建議策略 |
|---|---|---|---|
| Zoom | 會議控制、音訊、視訊與螢幕分享 | 登入網域、會議連線、長連線是否中斷 | 使用穩定節點，避免會議期間手動切換 |
| Slack | 訊息、通知、檔案與工作區同步 | 工作區網域、檔案預覽與 CDN 請求 | 依連線紀錄補充實際命中的網域 |
| Google Meet | 瀏覽器訊號交換與即時媒體 | Google 登入、Meet 頁面與媒體連線 | 避免與公司 Google Workspace 直連規則互相覆蓋 |
| 公司內部服務 | 內網 DNS、ERP、NAS、SSH 或印表機 | 內部網段與公司專用網域 | DIRECT 或依公司 VPN 的指定路由 |
這張表不是一份可以盲目複製的固定網域清單。雲端服務會因地區、版本、登入方式與企業方案而改變連線目標，最有效的方式仍是「先使用、再觀察、後收斂」。例如先開啟 Slack，等待訊息、檔案與通知都完成同步，再在 Clash 連線頁面搜尋 slack、slack-edge 或相關目的地；Zoom 則應在加入測試會議、開啟攝影機與分享畫面後再檢查紀錄。
建立協作專用策略組，避免節點選擇互相干擾
如果所有代理流量都共用一個「自動選擇」群組，日常瀏覽可能很方便，但視訊會議不一定適合。自動測速通常以短時間 HTTP 請求判斷延遲，未必能反映長時間 UDP、WebSocket 或音訊串流的穩定度。建議在設定檔中建立一個用途明確的策略組，例如「Work-Meeting」，將延遲合理、近期實測穩定的節點放在其中。
規則順序同樣重要。較具體的網域規則應放在較寬泛的規則集之前，否則可能先被一般的 GEOIP、地域規則或大型 RULE-SET 接走。概念上可以依照以下順序整理：
- 先處理公司內網、區域網路與本機服務，避免遠端工作時失去內部資源。
- 再處理 Zoom、Slack、Google Meet 等協作服務，指向 Work-Meeting 策略組。
- 接著放置其他工作 SaaS、文件平台與開發工具規則。
- 最後才使用一般直連、代理或兜底規則。
若你以 YAML 編輯設定，修改前請先備份原始檔，並確認縮排、冒號與策略組名稱完全一致。不要直接把整份訂閱內容複製到公開論壇，也不要將包含帳號資訊的訂閱網址放進團隊聊天。訂閱更新後，手動修改的內容可能被覆蓋，因此更穩妥的方式是使用用戶端支援的覆寫、Merge 或獨立規則檔功能，並在更新後再次確認規則仍然存在。
系統 Proxy 與 TUN：先用最小改動驗證問題
排錯時建議先開啟系統 Proxy，再測試瀏覽器中的 Slack、Google Meet 或 Zoom 網頁登入。這種方式對支援系統代理的程式影響較小，也容易從連線紀錄確認請求是否進入 Clash。如果應用程式能正常出現紀錄，卻套用到 DIRECT，問題多半在規則順序或目的地網域；如果完全沒有紀錄，則可能是程式不讀系統代理、連線使用了不同協定，或流量被其他 VPN 接管。
TUN 模式可以涵蓋更多不遵循系統 Proxy 的程式，但它同時會改變系統路由，可能與公司 VPN、零信任軟體、Docker 網路或安全防護工具衝突。因此不建議一開始就長時間開啟全域 TUN。可以先在非正式會議中短時間啟用，觀察 Zoom 的音訊、攝影機與螢幕分享是否都正常，再決定是否保留。
若你在公司電腦上工作，應特別留意企業 VPN 的優先順序。有些 VPN 會強制所有流量經過公司閘道，有些則只接管內部網段。當兩者同時啟用時，可能出現 Slack 可以傳訊息、但檔案下載失敗，或 Meet 能進入會議、媒體卻沒有聲音的情況。這時不要只更換節點，應先停用非必要的第二套代理，並把「是否進入 Clash」「使用哪個策略」「是否經過公司 VPN」三件事分開確認。
用可重複的流程測試視訊與協作品質
不要只用「網頁打得開」判斷設定成功。遠端工作真正需要的是連續使用時仍然可靠，因此建議在正式會議前完成一次固定的 A／B 測試。先記下目前節點、模式與測試時間，再依序測試登入、加入會議、開啟音訊、開啟攝影機、分享畫面，以及在 Slack 傳送文字與小型檔案。每個步驟至少維持幾分鐘，讓連線紀錄有足夠資料可比較。
- 延遲：高延遲會讓對話出現明顯停頓，但單看延遲數字不足以判斷會議品質。
- 抖動：延遲忽高忽低時，音訊容易斷續，應優先更換策略組中的節點或協定。
- 丟包：畫面模糊、聲音機械化或分享畫面頻繁停止，往往比單純網頁載入慢更能反映丟包。
- 長連線：測試至少持續十至十五分鐘，確認不是只有剛加入時正常。
- 恢復能力：暫時關閉再開啟 Wi-Fi，觀察 Clash 與協作軟體能否重新建立連線。
如果只有 Zoom 異常，先在連線紀錄中確認會議相關請求是否都套用同一策略；如果所有服務都在同一時間變慢，則更像是節點、出口頻寬、家用網路或公司 VPN 的問題。Slack 檔案傳輸失敗而訊息正常，則應檢查檔案 CDN 或工作區專用網域，而不是直接把整個 Slack 設為全域代理。每次只改一個變數，並保留測試結果，才能知道改善究竟來自規則、節點，還是網路環境本身。
日常使用與故障排除清單
完成設定後，不需要每天重新編寫 YAML，但仍應建立簡單的維護習慣。首先，會議開始前避免臨時更新訂閱或切換多個節點；若必須更新，應在非工作時段確認策略組名稱和規則覆寫沒有被重置。其次，為 Work-Meeting 保留至少兩個經過實測的備援節點，並記錄它們在不同時段的表現。晚間尖峰時穩定的節點，未必在白天公司網路高負載時仍然適合。
遇到問題時，可以依以下順序縮小範圍：
- 確認 Clash 核心正在執行，且目前載入的是正確設定檔。
- 確認系統 Proxy 或 TUN 狀態，避免以為流量已接管但實際仍然直連。
- 在連線紀錄搜尋實際目的地，確認規則是否命中預期策略。
- 短時間切換另一個已知穩定節點，分辨規則問題與節點問題。
- 檢查公司 VPN、瀏覽器擴充功能與其他代理是否同時運作。
- 最後才考慮清除應用程式快取、重新登入或重建設定檔。
對大多數遠端工作者而言，最實用的成果不是一份永遠不變的規則，而是一套可以重複驗證的流程：知道哪些服務需要代理、哪些服務必須直連，知道如何從連線紀錄找出真正的目的地，也知道何時應該更換節點而不是繼續修改規則。相較於部分只提供單一全域開關的工具，Clash 能以策略組、規則模式、連線紀錄與 TUN 選項分層處理 Zoom、Slack 和 Google Meet；當同類工具遇到平台支援有限、規則難以追蹤或切換後無法判斷原因時，Clash 的可觀察性與跨平台設定彈性，會讓遠端協作的調整更容易被驗證與維護。若你正準備把這套工作流套用到自己的電腦與手機，可以先從適合你平台的版本開始了解。