Clash 遠端辦公怎麼設定？Zoom、Slack 與 Meet 分流實用指南

先釐清遠端辦公的分流目標

使用 Clash 或 FlClash 處理遠端辦公時，重點不是把所有流量都送進代理，而是按照服務特性分配路徑。Zoom、Slack 與 Google Meet 可能需要穩定的跨區連線、即時通訊或較完整的網域解析；台灣、香港常用的銀行、公司內網、政府網站與本地影音服務，則通常更適合直連。將兩類流量全部混在同一個「節點選擇」策略組中，容易增加延遲，也可能讓公司服務觸發異常登入或地區驗證。

開始修改設定前，先確認目前使用的是 FlClash、Clash Verge Rev、ClashX 或其他圖形客戶端，以及實際執行的核心是否為 mihomo。客戶端的名稱不一定等於核心名稱。若設定檔使用 rule-providers、TUN、進階 DNS 或較新的代理協定，建議使用支援 mihomo 的客戶端，並先備份原始訂閱 URL 與目前生效的 YAML。

流量類型	建議路徑	主要考量
Zoom、Google Meet	低延遲代理	連線穩定、UDP 能力、尖峰時段丟包率
Slack 文字與檔案	代理或自動選擇	工作區登入、訊息同步、檔案 CDN 可達性
台港銀行、政府與公司內網	直連	保留本地 IP、降低不必要的繞路
一般新聞與未知網站	依預設規則	避免規則過度擴張造成誤分流

先建立適合視訊會議的節點組

視訊會議的「節點延遲」不是唯一指標。Clash 客戶端顯示的延遲通常只是對測試網址發出 HTTP 請求後得到的往返時間，不能完全代表 Zoom 或 Meet 媒體伺服器的實際品質。對遠端工作而言，應同時觀察延遲、丟包、抖動與連線持續時間。一般來說，延遲低於 80 ms 且長時間沒有斷流，比偶爾測得 40 ms 但經常重連的節點更實用。

可以將訂閱中的節點分成「工作代理」與「一般代理」兩個策略組。工作代理只放入距離較近、連線穩定的節點，例如台灣、日本、香港、新加坡等區域；一般代理則保留完整節點清單。若服務提供者的節點名稱不可靠，先透過客戶端的延遲測試與實際通話測試篩選，不要只根據旗標或地區名稱作決定。

proxy-groups:
  - name: Work
    type: url-test
    proxies:
      - 台灣 01
      - 日本 01
      - 香港 01
      - 新加坡 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Default
    type: select
    proxies:
      - Work
      - DIRECT
      - 台灣 01
      - 日本 01

url-test 會依測試結果在候選節點中選擇較快者，但它不等於完整的通話品質測試。interval: 300 代表每 300 秒重新測試；若工作期間不希望節點頻繁切換，可以使用 select 手動固定一個穩定節點。頻繁切換可能造成視訊會議重新建立連線，也可能讓 Slack WebSocket 連線短暫中斷。

用三個指標測試節點

延遲：在相同網路環境下連續測試 5 至 10 次，記錄平均值與最高值，不要只看單次最低數字。
穩定性：播放一段長時間音訊或進行 30 分鐘測試通話，觀察是否出現斷線、聲音機械化或畫面凍結。
UDP 表現：Zoom 與 Meet 的媒體流量可能使用 UDP。若 TCP 瀏覽正常，但會議頻繁顯示網路不穩，應檢查節點與上游網路是否支援 UDP，而不是只更換 DNS。

動手設定 Zoom、Slack 與 Meet 分流

在 FlClash 中，通常可以進入「設定檔」或「Profiles」頁面，選擇目前使用的 YAML，透過「編輯設定」「覆寫」或本機設定功能加入規則。不同客戶端的按鈕名稱可能不同，但原理相同：先確保存在名為 Work 的策略組，再將服務網域規則放在一般規則之前。Clash 規則會由上而下比對，較早出現的規則優先套用。

rules:
  - DOMAIN-SUFFIX,zoom.us,Work
  - DOMAIN-SUFFIX,zoom.com,Work
  - DOMAIN-SUFFIX,zoomcdn.net,Work
  - DOMAIN-SUFFIX,zoomgov.com,Work

  - DOMAIN-SUFFIX,slack.com,Work
  - DOMAIN-SUFFIX,slack-edge.com,Work
  - DOMAIN-SUFFIX,slack-msgs.com,Work
  - DOMAIN-SUFFIX,slack-files.com,Work

  - DOMAIN,meet.google.com,Work
  - DOMAIN,accounts.google.com,Work
  - DOMAIN-SUFFIX,gstatic.com,Work
  - DOMAIN-SUFFIX,googleapis.com,Work

  - DOMAIN-SUFFIX,gov.tw,DIRECT
  - DOMAIN-SUFFIX,gov.hk,DIRECT
  - DOMAIN-SUFFIX,edu.tw,DIRECT
  - GEOIP,PRIVATE,DIRECT
  - MATCH,Default

上面的網域只是一個可調整的起點。Zoom、Slack 與 Meet 可能使用額外的登入、設定、圖片、檔案或媒體網域，也可能因地區、企業租戶與版本而改變連線目的地。加入規則後，應打開客戶端的連線記錄，實際觀察被拒絕、逾時或走錯策略的網域，再逐項補充。對於不確定用途的 Google 或 Slack 網域，不建議直接使用過寬的 DOMAIN-SUFFIX,google.com,Work，因為這會把大量與工作無關的流量一併送入代理。

規則順序與直連例外

本地服務規則與工作服務規則之間沒有固定的先後答案，重點是避免同一網域被更早的廣泛規則攔截。例如，若訂閱前段已有 GEOIP,CN,Proxy 或某個大型規則集，後面才加入 Zoom 規則，Zoom 可能永遠不會走到 Work。修改後應查看實際命中的規則與策略，而不是只確認 YAML 能成功載入。

DOMAIN：只比對完整網域，例如 meet.google.com。
DOMAIN-SUFFIX：比對指定網域及其子網域，適合 slack.com 這類服務入口。
DOMAIN-KEYWORD：只在確認網域命名規律後使用，過度寬鬆時容易誤傷其他服務。
GEOIP：依目的地 IP 判斷地區，對使用 CDN 或共享 IP 的服務不一定準確。
MATCH：作為最後兜底規則，必須放在規則清單末端。

若公司內網使用私有網域，例如 corp.example.com，可以明確指定 DOMAIN-SUFFIX,corp.example.com,DIRECT，但前提是公司網路、VPN 或 DNS 本身允許解析。若公司要求所有內網流量經過企業 VPN，則不能僅靠 Clash 的 DIRECT 規則取代企業 VPN；兩者處理的是不同層級的網路連線。

DNS、TUN 與系統代理的搭配方式

分流規則是否有效，取決於核心能否取得正確的目標網域。若 DNS 在規則判斷前已被錯誤解析、回傳污染位址，或應用程式只提供 IP 而沒有網域資訊，規則命中結果可能與預期不同。使用 FlClash 時，先以系統代理模式完成基本驗證；只有不遵循系統代理的應用程式仍無法分流，才考慮開啟 TUN。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

tun:
  enable: false
  stack: mixed
  auto-route: true
  auto-detect-interface: true

這段內容不是所有環境都能直接套用。企業網路可能禁止外部 DoH，內網名稱也可能必須交給公司 DNS 解析。若啟用 fake-ip 後出現公司內網、印表機、區域網路檔案分享或部分登入流程異常，應先增加必要的 fake-ip-filter 項目，或改用符合環境的 DNS 模式。

模式	適合情境	常見限制
系統代理	瀏覽器、Slack 桌面版及支援 HTTP/SOCKS 的軟體	不遵循系統代理的程式不會被接管
TUN	需要接管命令列、部分會議程式或其他非代理應用程式	需要網路權限，可能影響 DNS、路由與區域網路
全域代理	短時間排查是否為直連路徑造成問題	不適合長期遠端辦公，容易增加本地服務延遲

完成後的驗證與故障定位

設定完成後，不要只用瀏覽器開啟首頁判斷成功。先在 FlClash 的連線記錄中搜尋 zoom、slack、meet，確認命中的策略組是 Work；再檢查台港常用網站是否命中 DIRECT。如果某個網域顯示為 IP 連線、沒有對應的網域規則，可能需要檢查 TUN 的嗅探功能或應用程式本身的連線方式。

Zoom 可以登入但會議音訊斷續：先比較不同節點的丟包與 UDP 表現，再嘗試固定 select 節點。
Slack 訊息延遲或頻繁重新連線：查看 WebSocket 相關網域是否被錯誤分到 DIRECT，並避免在通話期間自動切換節點。
Meet 能開啟但無法加入會議：檢查 Google 登入網域、瀏覽器權限，以及媒體連線是否被防火牆或 UDP 政策限制。
公司內網無法開啟：確認公司 DNS、企業 VPN 與私有網域規則，不要直接把所有內網流量改成代理。
所有網站都變慢：暫時關閉 TUN，恢復系統代理後逐項檢查 DNS、兜底策略與節點是否過載。

若需要查看核心狀態，可以在客戶端的日誌頁確認啟動錯誤、DNS 解析失敗與連線重試。控制介面若使用 127.0.0.1:9090，應搭配密鑰並只允許本機存取；不要將 external-controller 綁定到公共網路位址，也不要在截圖或文章中公開訂閱權杖與控制密鑰。

curl -H "Authorization: Bearer change-this-secret" \
  http://127.0.0.1:9090/version

最後，建議為遠端辦公保留一份簡潔的覆寫檔，並在訂閱更新後重新檢查策略組名稱是否仍然一致。若訂閱服務重新命名節點，proxy-groups.proxies 中的固定名稱可能失效；使用客戶端提供的節點篩選、正規表示式或代理提供者功能，通常比手動維護大量節點名稱更穩定。完成測試後，讓一般流量維持規則模式，僅將確實需要的工作服務送往低延遲代理，才能在會議品質與台港本地速度之間取得平衡。