先確認流量接管方式：系統代理不等於視訊流量全接管
遠距會議要穩定，不能只把 Zoom、Slack 和 Google Meet 網域指向代理策略組，還要確認會議程式的連線是否真的進入 Clash 核心。Clash 的規則只處理已交給核心的連線；應用程式是否使用系統代理、核心是否接收到 UDP 流量，以及所選節點是否支援 UDP，都會影響語音與視訊。
- System Proxy（系統代理）：會將作業系統的 HTTP、HTTPS 或 SOCKS 代理設定指向本機連接埠。遵循系統代理的瀏覽器通常會使用它，但不遵循系統代理的程式、部分背景服務及 UDP 媒體流量，未必會經過 Clash。
- TUN：透過虛擬網路介面接收符合接管範圍的 IP 流量，再交由核心依規則處理。桌面用戶端要依自身實作啟用 TUN，並確認系統權限、路由及 DNS 設定正常。
- 節點與核心：視訊可能使用 UDP 傳送即時媒體。即使規則命中代理策略，若節點協定、服務端或核心不支援所需的 UDP 轉送，會議仍可能出現無聲、畫面停頓或連線改走 TCP 的情況。
會議前可先測試兩種情況：只開系統代理時，查看 Zoom 或 Meet 的連線是否出現在核心的 Connections（連線）頁面；若媒體連線沒有進入核心，再依用戶端支援情況測試 TUN。測試時先使用一個已確認可用、且支援 UDP 的節點，不要同時修改 DNS、規則和節點，否則很難判斷問題出在哪一層。
Zoom、Slack 與 Google Meet：用服務需求決定代理策略
三種服務都可能使用 HTTPS 控制連線與即時媒體傳輸，但實際使用的網域、IP 位址和傳輸方式會隨用戶端版本、功能及網路環境改變。下表是設定分流時的判斷方向，不代表固定且完整的服務網域清單。
| 服務 | 規則設計方向 | 連線檢查重點 | 常見注意事項 |
|---|---|---|---|
| Zoom | 將已確認的 Zoom 服務網域送往工作代理策略；以連線記錄確認實際命中結果。 | 確認會議媒體連線是否進入核心，以及節點是否能轉送 UDP。 | 會議可登入不代表音訊、視訊媒體也使用同一路徑；公司網路政策可能另有要求。 |
| Slack | 先處理 Slack 工作區及通話相關網域，再依記錄補充所需網域。 | 分別測試訊息、檔案和 Slack 通話，這些功能的連線需求可能不同。 | Slack 通話可能涉及即時媒體連線；只測試訊息送出成功不足以驗證通話品質。 |
| Google Meet | 對 Meet 使用的明確網域做精確分流；避免未經評估就將整個 Google 網域送往代理。 | 確認瀏覽器媒體連線、UDP 通道及 DNS 結果，並在實際會議中查看連線記錄。 | Google 多項服務共用網域與基礎設施，過寬的網域規則可能改變 Gmail、雲端硬碟等流量路徑。 |
在網域規則中，DOMAIN-SUFFIX 會比對指定網域及其子網域；它比把流量全部切到 Global 更適合建立局部規則。Zoom 常見服務網域包含 zoom.us，Slack 常見網域包含 slack.com，Google Meet 的網頁入口則使用 meet.google.com。這些只適合作為排查起點，不是涵蓋所有功能的完整清單；實際端點應以服務端、用戶端記錄和組織網路文件為準。
不建議只為了 Meet 就直接加入範圍很大的 google.com、googleapis.com 或其他共用網域後綴。這可能讓大量無關服務改走代理，也可能造成工作帳號的登入、驗證或內部管理流量與原先路徑不同。若服務使用動態 IP，也不要長期抄寫單次查詢結果作為固定 IP 規則；IP 可能變更，且共用位址可能同時承載其他服務。
動手設定：備份設定檔、加入規則，再逐項驗證
以下示範的是規則片段，不是可以直接使用的完整訂閱。工作代理必須已存在於設定檔的策略組中；若你的策略組名稱不同，請將規則中的名稱改成實際名稱。先匯出或複製一份設定檔，再透過用戶端支援的覆寫或 Mixin 功能修改，避免訂閱更新時自訂內容遭到覆蓋。
rules:
- DOMAIN-SUFFIX,zoom.us,工作代理
- DOMAIN-SUFFIX,slack.com,工作代理
- DOMAIN,meet.google.com,工作代理
- MATCH,原有兜底策略範例只列出少數起始網域，不能保證覆蓋所有登入、檔案、通話或媒體端點。請保留原設定中的其他必要規則，並將新增規則放在會匹配同一流量的廣泛規則之前。規則按清單順序比對，通常命中後便使用該規則指定的策略；若更早的規則已匹配，後面的服務規則就不會生效。MATCH 是兜底規則，應保留在規則清單末端。
- 確認策略組：在 Proxies（代理）頁面查看「工作代理」能否選到可用節點。若使用自動策略組，可先手動選擇一個穩定節點測試，避免節點切換干擾結果。
- 確認規則載入：儲存覆寫內容並重新載入設定檔。查看啟動記錄是否有 YAML 解析錯誤、未知欄位或策略組不存在等訊息；出現錯誤時先還原，再逐條加入規則。
- 測試一般連線：開啟 Zoom、Slack 或 Meet，分別測試登入、訊息、檔案與會議。不要只以首頁能開啟作為成功標準。
- 檢查命中結果：在 Connections（連線）頁面查看目的網域、連線程序（若用戶端提供）及最終策略。確認服務連線命中預期策略，而不是更早的兜底或直連規則。
- 測試媒體路徑：加入測試會議並開啟麥克風、攝影機，觀察是否有 UDP 連線及是否穩定。若系統代理模式看不到相關媒體流量，再依用戶端支援方式測試 TUN。
- 逐項縮小範圍：若特定功能失敗，先記錄該次連線的網域、協定和策略，再一次只補一條精確規則。不要直接將整個 Google、Microsoft 或所有 HTTPS 流量切換至同一代理組。
節點選擇、UDP 與視訊品質：先排除最常見的瓶頸
視訊會議對延遲變化和封包遺失較敏感。節點測速數字低，不代表從你的裝置到節點、再到會議服務的整段路徑都穩定。工作會議建議先挑選地理位置與網路路徑較合適的節點，測試數分鐘後再決定是否長期使用；頻繁更換地區可能讓工作服務看到不同出口位置，也可能觸發組織的登入風險控管。
- 會議能加入但沒有聲音：檢查應用程式是否經由 TUN 接管、節點是否支援 UDP，以及防火牆或公司網路是否限制媒體連線。不要只反覆修改網域規則。
- 畫面卡頓或聲音斷續：分別測試直連與代理路徑，檢查本地 Wi-Fi、上傳負載、節點壅塞及其他裝置的佔用。視訊品質也會受攝影機、無線訊號和背景同步影響。
- 登入正常但檔案或通話失敗：對照 Connections 記錄，確認是否有相關網域未命中預期策略；若端點是動態產生的，依服務文件及實際記錄補充，不要猜測大範圍網域。
- 切換節點後工作帳號要求重新驗證：先固定一個符合組織政策的出口測試。公司服務可能依出口位置、裝置管理或安全政策限制連線，遇到限制應向管理員確認。
節點的 UDP 支援需要從整條路徑確認：核心是否接收到 UDP、代理協定是否提供 UDP 轉送、伺服器端是否允許，以及目前網路是否封鎖相關連線。若其中一處不支援，可能改用 TCP、連線失敗或由應用程式自行選擇其他傳輸方式。不要把「策略規則命中」誤認成「UDP 已成功經代理傳送」。
Zoom、Slack 和 Meet 的企業版環境可能有管理員指定的網域、連接埠、代理伺服器或資料區域要求。實際工作環境應優先遵守公司提供的網路文件；服務供應商的網路需求也可能更新。遇到組織網路限制時，不要以擴大規則或繞過管理政策作為預設處理方式。
多裝置使用與日常維護：避免規則互相覆蓋
桌面電腦、手機與平板可能使用不同 Clash 類用戶端、核心版本和流量接管方式。同一份訂閱可以提供節點與策略組，但不代表每個裝置都能套用相同的 TUN 欄位或覆寫格式。先確認每台裝置的規則是否載入，再分別檢查系統代理、VPN/TUN 權限及實際連線記錄。
手機上的 VPNService 或桌面上的 TUN 會影響裝置流量進入核心的方式；啟用後也要留意公司 Wi-Fi、區域網路、印表機與內部資源是否仍按預期直連。若公司要求指定 VPN 或禁止其他網路工具，請依管理政策設定。不要在同一裝置上同時啟用多個會建立 VPN 介面的程式來測試，因為系統通常只能讓其中一個連線成為作用中的 VPN。
日常使用時，將規則修改、節點選擇與 TUN 設定分開管理，並保留一份可還原的設定檔。訂閱更新後，重新確認自訂規則仍在、策略組名稱沒有改變，並用一場短測試會議檢查聲音與畫面。若只在特定網路發生問題，也記錄網路類型、用戶端版本、核心、模式及連線時間，方便向管理員或服務支援人員描述問題。
遠距工作分流的目標不是讓所有流量都經過代理，而是讓需要的工作連線使用合適路徑，其他流量維持原本的直連或既有策略。從精確網域規則開始，透過連線記錄驗證，再視實際 UDP 和 TUN 需求調整，通常比直接切換 Global 或大範圍代理更容易定位問題。