平台部署 閱讀時間約 8 分鐘

遠距辦公用 Clash 穩定連線 Zoom 與 Slack 的分流設定指南

在家開 Zoom 會議或用 Slack 協作，常遇到語音延遲、畫面不順，未必需要把所有網路流量都交給代理。這篇指南整理 Clash 的節點挑選、視訊會議網域規則與直連設定，帶你依工作情境安排分流，讓會議連線更穩，也保留本地網站的瀏覽速度。

先釐清分流目標：會議流量走穩定節點，其他服務維持原路徑

遠距辦公時，Zoom、Slack 與 Google Meet 的連線品質，不只取決於節點測得的延遲。節點到會議服務的路由、尖峰時段的頻寬、封包遺失，以及用戶端是否支援 UDP，都可能影響語音、畫面分享與即時訊息。較容易維護的做法，是將會議服務交給專用策略群組，再由群組選擇節點；一般網站則繼續使用原有規則，不必把所有流量都送進同一條代理線路。

本文以 mihomo 核心支援的 Clash YAML 規則為例。不同用戶端的設定入口名稱可能不同，常見位置包括「覆寫」、「擴充設定」或「設定檔編輯」。開始前，先確認目前使用的核心確實支援設定內容，並備份原設定。若直接編輯訂閱下載的檔案，訂閱更新可能覆蓋修改；長期使用時，應採用用戶端提供的持續性覆寫方式。

服務分流建議驗證重點
Zoom將確認過的 Zoom 網域交給會議策略群組測試語音、攝影機、螢幕分享及 UDP 連線
Slack先涵蓋 Slack 主網域，再按連線記錄補充檔案或媒體網域測試訊息、工作區登入、檔案上下載與通話
Google Meet優先只分流 Meet 本身，不要直接代理所有 Google 網域測試加入會議、音訊、視訊與螢幕分享
其他流量保留現有規則及兜底策略確認一般網站沒有意外改走會議節點

挑選節點：延遲之外還要看晚間穩定度與 UDP 支援

可先在代理頁面選擇數個地理位置相近、平常能穩定連線的節點，使用 url-test 群組協助比較。測試網址回應較快，只代表該次健康檢查的結果較好，不代表 Zoom 或 Meet 的媒體流量一定有較低延遲，也不代表節點能承受長時間視訊。若工作時段固定，建議在上班尖峰時段進行測試，而不是只依離峰時段的數值決定。

下方是策略組範例。請將「香港節點 01」等名稱換成設定檔內實際存在的節點名稱；若原設定已經有可用的自動選擇群組，也可以直接引用既有群組，不必重複建立。健康檢查網址與時間間隔可依核心及網路環境調整，不能視為會議品質保證。

proxy-groups:
  - name: 會議低延遲
    type: url-test
    proxies:
      - 香港節點 01
      - 日本節點 01
      - 新加坡節點 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 會議代理
    type: select
    proxies:
      - 會議低延遲
      - 香港節點 01
      - 日本節點 01
      - DIRECT
  • url-test 會按健康檢查狀況選擇候選節點；測得延遲相近時，適度的 tolerance 有助減少因小幅波動而頻繁切換。
  • select 讓使用者在自動選擇、指定節點與直連之間切換。若會議期間不希望出口變動，可先手動固定已測試過的節點。
  • 確認節點支援 UDP，且用戶端目前使用的核心及代理協定能轉送 UDP。只有 TCP 可用時，部分會議功能仍可能連線，但媒體品質或連線方式可能不同。

不要把 ICMP ping、單次延遲測試或下載速度，當成通話品質的唯一指標。實際測試時應比較語音是否中斷、畫面是否凍結、分享畫面是否延遲，並留意用戶端是否顯示網路品質警告。若群組自動切換後會議反而中斷，可改為手動固定節點，再於會議結束後重新測試。

建立網域規則：會議服務放在一般兜底規則之前

規則由上而下比對，第一條符合的規則會決定流量出口。因此，Zoom、Slack 和 Meet 的明確規則必須放在可能先行命中的廣泛規則之前，也要放在最末尾的 MATCH 之前。以下片段假設前一節的 會議代理 群組已存在，並且原設定中已有其他策略群組與兜底規則。

rules:
  - DOMAIN-SUFFIX,zoom.us,會議代理
  - DOMAIN-SUFFIX,zoom.com,會議代理
  - DOMAIN-SUFFIX,zoomcdn.net,會議代理

  - DOMAIN-SUFFIX,slack.com,會議代理
  - DOMAIN-SUFFIX,slack-edge.com,會議代理
  - DOMAIN-SUFFIX,slack-files.com,會議代理
  - DOMAIN-SUFFIX,slack-imgs.com,會議代理
  - DOMAIN-SUFFIX,slack-msgs.com,會議代理

  - DOMAIN,meet.google.com,會議代理
  - DOMAIN,meetings.googleapis.com,會議代理

  # 保留原有其他規則，並將原本的兜底規則放在最後
  - MATCH,代理選擇

網域清單需依實際連線紀錄確認。若 Slack 檔案傳輸、Zoom 登入或 Meet 媒體連線仍未按預期分流，先在用戶端「連線」頁面查看目標主機名稱、命中的規則與最終出站，再補上確實觀察到的網域。不要直接加入 googleapis.com 這類範圍較大的後綴，否則可能連帶改變其他 Google 應用程式的路由。

將片段合併進現有設定時，只保留一個頂層 rules 清單；不要把新清單貼在另一個同名鍵下，也不要將完整範例覆蓋原有訂閱規則。若設定使用規則提供者或覆寫機制，先確認該機制是合併規則還是取代規則。儲存後使用用戶端的設定檔檢查功能，確認 YAML 可解析、策略群組名稱完全一致，再重新載入核心。

動手操作：分階段套用並測試 Zoom、Slack 與 Meet

  1. 備份並確認入口：匯出目前設定，確認用戶端使用 mihomo 核心，並找到可保留自訂內容的覆寫或設定編輯入口。記下目前代理模式、系統代理狀態與 TUN 狀態，方便測試失敗時還原。
  2. 建立專用策略群組：先加入「會議低延遲」與「會議代理」，將範例節點名稱替換為實際名稱。若核心回報找不到代理，先檢查名稱與縮排，不要立刻更改 DNS 或防火牆。
  3. 加入網域規則並檢查順序：將已確認的服務網域規則放到廣泛規則及 MATCH 之前。使用用戶端提供的設定檢查功能，確認設定載入成功，再重新載入設定檔。
  4. 分別驗證三項服務：先開啟 Zoom 測試會議，再測 Slack 訊息與檔案功能，最後測 Google Meet。每測一項，就查看連線記錄中的規則、策略群組、節點與連線狀態；不要一次同時更改多項設定。
  5. 記錄並比較結果：在相同網路與相近時段，用一個已知可用的節點進行語音、視訊及螢幕分享測試。若故障只發生在特定功能，記下時間、目標網域、傳輸類型及錯誤訊息，再針對該功能排查。

系統代理通常只影響會遵循作業系統代理設定的應用程式；若某項功能沒有出現在核心連線記錄中，可能是該應用程式未採用系統代理。此時才考慮測試 TUN，並先確認沒有其他 VPN、虛擬網路介面或企業安全軟體造成路由衝突。TUN 涉及更廣泛的流量接管，啟用後仍須檢查 DNS、區域網路直連與 IPv6 路徑。

觀察到的情況優先檢查建議處理
連線記錄沒有服務請求應用程式是否使用系統代理，或流量是否進入 TUN檢查應用程式代理方式，再單獨測試 TUN
規則命中，但出站是 DIRECT策略組選擇及規則是否被更早的規則攔截檢查規則順序與群組目前選取的出口
文字訊息可用，語音或視訊不穩節點 UDP 支援、媒體連線及尖峰時段品質查看連線細節並改用已確認支援 UDP 的節點比較
切換節點後短暫中斷會議期間出口是否變更會議中固定節點，避免測試或自動切換
Meet 正常但其他 Google 服務變慢是否加入範圍過廣的 Google 網域規則移除不必要的廣泛後綴，只保留已驗證的目標

維持設定穩定：更新後複測，避免擴大規則範圍

服務網域、用戶端版本與訂閱節點都可能改變，規則設定不宜一次加入大量猜測的網域。每次更新訂閱或核心後，先確認設定仍能載入，再用連線記錄核對 Zoom、Slack 與 Meet 的實際路由。若某條規則長期沒有命中，應確認它是否仍有必要；若新功能未被涵蓋，則根據觀察到的主機名稱逐條補充。

公司或學校網路可能限制代理、UDP、VPN 或虛擬網路介面。若只在特定場所無法連線，先比較不同網路環境下的連線記錄，並遵守組織資訊安全政策；不要為了讓會議接通而繞過管理限制。若是節點本身不穩，優先更換節點或聯絡服務提供者，不要用不斷縮短健康檢查間隔的方式掩蓋線路品質問題。

設定完成後，建議保留一個可手動選擇的備用節點，並在重要會議前做一次短時間測試。這樣遇到自動選擇結果不理想時，可以快速切換；而一般網站仍可依原有規則處理，不會因為會議需求而全面改變日常上網路徑。

下載 Clash