遠距工作用Clash：Zoom與Google Meet視訊分流實用設定

遠距視訊為什麼需要分流，而不只是挑最快節點

居家辦公時，Zoom、Google Meet 與 Slack看起來都是「能連上網就能用」的服務，實際上卻不只依賴單一網站連線。視訊會議可能同時使用登入與會議控制、訊號交換、音訊、視訊及螢幕分享等不同連線；Slack 也會分別載入工作區、訊息同步與檔案內容。若 Clash 把這些流量一概送往同一個延遲最低的節點，會議控制頁面雖然載入成功，音訊或畫面傳輸卻未必穩定；反過來，若所有流量都直連，部分網路環境下又可能遇到服務連線緩慢或不穩。

因此，分流的目標不是「讓所有視訊流量都走代理」，而是先辨認哪些服務需要特定出口、哪些服務適合直連，再用一致的策略組管理。Zoom 的登入與會議流量、Meet 所依賴的 Google 服務，以及 Slack 的工作區和檔案主機，應依照你的實際網路環境、公司政策與連線日誌決定路徑。不要因為某個服務的網域屬於大型平台，就把整個平台的所有流量都納入同一條代理規則。

另一個容易誤判的地方，是把「代理節點延遲低」直接等同「視訊品質好」。視訊通話需要持續傳輸，短時間的丟包、抖動、上行頻寬不足，往往比一般網頁多幾十毫秒更容易造成卡頓或聲音斷續。若你使用的桌面客戶端提供規則模式、系統代理或 TUN，先確認目前採用哪種接管方式；不同模式對應用程式、UDP 流量與 DNS 的涵蓋範圍並不相同。

ℹ 先定義分流目的：找出會議是否卡在登入、加入會議或媒體傳輸；確認 Zoom、Meet、Slack 分別命中哪條規則；最後才比較直連與不同節點的結果。

先替 Zoom、Meet 與 Slack 設定清楚的策略

開始編輯設定前，先列出你每天使用的服務，以及它們應該採取的路徑。公司內部網站、單一登入入口、內部檔案伺服器與視訊服務，不一定要走同一條線；若公司提供正式的 VPN、代理或端點管理政策，應以 IT 部門要求為準，不要自行把內部流量導向未核准的第三方節點。對個人使用者而言，也建議把台灣常用網站、銀行與本機區域服務保留直連，避免無關流量繞遠路。

Zoom：分開看登入控制與會議媒體

Zoom 桌面程式除了登入和會議控制，也會建立會議音訊、視訊與螢幕分享所需的連線。你可以先把 Zoom 官方使用的服務網域納入觀察範圍，再依連線日誌確認目前版本與會議情境實際連到哪些主機。常見網域可能包含 zoom.us 及其子網域，但不應只憑一份過時清單就假定涵蓋所有部署；企業帳號、區域服務或應用程式更新都可能改變連線細節。

若 Zoom 登入正常，加入會議後卻出現聲音斷續或畫面停格，先不要急著追加大量網域規則。檢查會議期間的連線紀錄，確認媒體連線是否被送到預期策略組，並比較代理與直連時的丟包、抖動及上行狀態。某些網路會以 UDP 傳送即時媒體，某些環境則會降級或改用其他傳輸方式；你的 Clash 核心、TUN 狀態與防火牆規則，都可能影響實際結果。若公司網路要求視訊服務直連，便不應為了測試而擅自把會議媒體送往外部節點。

Google Meet 與 Slack：避免誤傷整個平台

Google Meet 可能與 Google 帳號登入、日曆邀請、瀏覽器資源及其他 Google 服務共用部分基礎設施。若將整個 Google 網域範圍都指定到代理，Gmail、雲端硬碟、搜尋或公司管理服務也可能一起改變路徑。較穩妥的作法是從 Meet 會議期間的連線紀錄開始，使用你能確認的精確網域或可信維護的規則集，再以測試會議驗證。若同一裝置同時開著 Google 日曆與 Meet，請分別觀察服務，不要把瀏覽器中所有 Google 連線都當成視訊流量。

Slack 同樣不只有工作區首頁：訊息同步、檔案預覽、圖片與通話可能牽涉不同的服務端點。若只有 Slack 工作區載入變慢，問題可能在網頁或控制連線；如果文字訊息正常、檔案下載卡住，則要另外檢視檔案相關主機的規則命中情形。Slack 通話也應與一般訊息流量分開測試。你不必一開始就建立極細的規則表，但至少要能回答「目前是哪一類連線經過哪一個策略組」，而不是讓所有流量不分用途地落到 MATCH。

策略組可以先保持簡單，例如為需要代理的工作服務建立一個手動選擇組，並讓你能在穩定節點、備援節點與直連之間切換。初期不建議用頻繁自動測速的組直接承載正在進行的視訊會議：測速、切換節點或節點狀態變動可能造成既有連線中斷。先用固定、穩定的出口完成會議測試；只有在會議以外的使用情境確認切換不會干擾工作，再評估自動選擇或備援策略。

Zoom：以會議期間的連線紀錄確認登入、控制與媒體流量的路徑，不要只測試登入頁。
Google Meet：只調整可確認與 Meet 相關的範圍，避免把所有 Google 服務一起改道。
Slack：分別測試工作區、訊息、檔案與通話，不要用首頁載入結果代表所有功能正常。
台灣服務：將常用本地網站與不需代理的內部資源明確保留直連，降低不必要的繞行。

動手設定：從備份、規則到會議驗證

以下流程適用於使用 Mihomo 核心的桌面客戶端，例如 Clash Verge Rev 或 Mihomo Party；Clash Verge、ClashX 等介面的按鈕名稱可能不同，但先備份、再改規則、最後檢查命中結果的順序相同。若你使用的是核心版本較舊的客戶端，部分 YAML 欄位或 TUN 行為可能不支援，應先確認目前載入的核心版本與該版本文件。請勿把範例當成一份可以直接覆蓋訂閱設定的完整設定檔。

備份目前設定：在客戶端確認正在使用的設定檔，另存一份副本，並記下現有系統代理、TUN 與 DNS 狀態。若設定由訂閱自動更新，先確認本機修改不會在更新後被覆蓋；必要時使用客戶端提供的覆寫或合併方式，不要直接破壞遠端訂閱內容。
準備策略組：在目前設定可用的前提下，確認有一個可手動選擇的工作服務策略組。組內節點名稱必須與設定檔中的節點名稱完全相同。建議至少保留一個你已測過的穩定出口，並讓直連策略也能被規則明確選取，方便做對照測試。
加入規則並檢查順序：將你確認需要調整的服務網域放在較寬泛規則之前，避免它們先被其他規則攔截。下面僅示範規則的排列概念；請把網域和策略名稱換成依官方文件、客戶端日誌及你實際設定確認的值。

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK-VIDEO
  - DOMAIN-SUFFIX,slack.com,WORK-VIDEO
  - DOMAIN-SUFFIX,example-meet-service.invalid,WORK-VIDEO
  - DOMAIN-SUFFIX,tw,直連
  - MATCH,預設策略

上例中的 example-meet-service.invalid 是占位字串，不能直接當作 Google Meet 的正式網域規則；真正設定時，應以目前版本的官方網路需求文件和你的連線紀錄為依據。DOMAIN-SUFFIX 適合匹配某個已確認的網域及其子網域，但它不會自動替你辨識「這條連線一定是視訊媒體」。若核心沒有取得可用的網域資訊，或流量以不同協定、不同連線方式抵達，規則結果也可能與預期不同。另請確認你使用的規則語法、策略組名稱與直連策略名稱符合目前核心設定，不要直接照抄範例的中文標籤。

重新載入並查看連線紀錄：儲存後先確認設定檔能正常解析、核心仍在運作，再開啟連線紀錄或規則命中面板。分別啟動 Zoom、Google Meet 與 Slack，觀察它們的連線是否命中預期策略；若出現超時或無法解析，先記下主機名、策略名稱與發生時間，再決定是否需要補充規則。
用真實工作情境測試：先以短時間測試會議確認加入、音訊、視訊與螢幕分享，再做一場較長的會議觀察穩定度。每次只變更一個條件，例如節點、直連或 TUN，並在相同網路、相近時段重複比較。若同時更換 DNS、規則集和節點，即使結果改善，也很難判斷是哪項調整真正有效。

如果桌面版客戶端只啟用系統代理，並非所有應用程式都會自動採用該代理；有些程式使用自己的網路堆疊，有些連線也可能不依照一般瀏覽器代理設定。若規則命中面板看不到預期流量，可先檢查應用程式是否支援系統代理、TUN 是否已啟用，以及作業系統防火牆是否允許相關連線。啟用 TUN 前，請了解其權限需求與對其他網路軟體的影響，並避免同時啟用多套互相衝突的 VPN 或流量接管工具。

⚠ 變更前先確認政策：公司管理的裝置、會議服務或內部資源可能有指定代理與資料傳輸規範。不要為了繞過管理政策而修改路由；遇到企業限制、封鎖或憑證警告時，先詢問 IT 管理者。

畫面卡頓、聲音延遲時的排查順序

視訊品質不佳時，先判斷問題發生在哪個階段。若登入頁載入很慢，但會議連線穩定，優先看 DNS 解析、登入主機與策略命中；若能加入會議卻沒有聲音，則要檢查音訊裝置、作業系統權限、防火牆與即時媒體連線；若只有螢幕分享停頓，還要排除 CPU 負載、無線網路訊號及上行頻寬不足。這些現象未必都由 Clash 引起，先把應用程式本身、區域網路與代理路徑分開驗證，會比一次重寫整份規則更有效率。

建議依序檢查：第一，查看 Clash 是否仍正常運作、目前模式是否為預期的規則模式；第二，從連線紀錄確認服務命中的是哪個策略，而不是只看主視窗顯示的目前節點；第三，在同一個網路環境下對照直連與固定節點的結果；第四，檢查 DNS 是否由預期的解析路徑處理，以及是否存在舊快取；第五，確認路由器、無線訊號、系統防火牆與公司網路沒有另外限制 UDP 或即時通訊流量。排查中應逐項還原，避免為了修復一次會議而留下無法解釋的全域設定。

如果問題只出現在某一個服務，請把那個服務的連線紀錄與發生時間留下來，再依其官方網路需求文件核對必要網域或連線條件。不要把日誌截圖連同訂閱 URL、帳號識別資訊或公司工作區資料公開貼出；這些內容可能包含敏感資訊。遇到公司會議服務、單一登入或內部系統無法使用時，交由 IT 管理者確認是否有指定出口、憑證檢查或 DNS 政策，通常比嘗試更多不明規則安全得多。

相較於只提供全域開關、難以看出每條連線命中結果的簡易代理工具，Clash 系列搭配 Mihomo 核心能以規則、策略組與連線紀錄逐步整理 Zoom、Google Meet、Slack 及台灣服務的路徑；但若客戶端核心過舊、規則全部塞進同一組，或沒有核對實際命中情形，功能再多也不會自動換來穩定視訊。完成備份、分流與實測後，你可以依作業系統選擇合適的桌面客戶端，從下載頁取得 Clash 客戶端，再用自己的工作網路逐項驗證設定是否符合需求。