遠端辦公Clash配置：Zoom、Slack與Meet順暢連線技巧

遠端辦公的分流目標

遠端工作時，網路需求通常不是「所有流量都走代理」這麼簡單。Zoom、Slack、Google Meet 需要穩定的連線與較低的延遲，企業內網、印表機、NAS、視訊會議室設備卻往往只能從本地網路存取；若把所有請求一律送進同一個節點，不但會增加節點負載，也可能讓內網服務失效。比較實用的做法，是讓 Clash 依照網域、IP、程序與連線類型分流，將需要代理的工作服務交給穩定節點，其餘流量維持 DIRECT。

本文以 mihomo 核心的設定思路為主，Clash Verge、Clash Verge Rev、Clash for Windows、ClashX、Clash for Android 等用戶端的介面名稱可能不同，但核心概念相同：先匯入設定檔，再確認策略組，最後透過規則與 TUN 模式接管需要處理的流量。若用戶端仍使用較舊的原版 Clash 核心，GEOSITE、PROCESS-NAME、TUN 或部分新協定可能不受支援，遇到設定載入錯誤時，應先確認核心類型。

Zoom、Slack 與 Meet 的規則規劃

工作服務的網域並不只是一個首頁網址。登入、訊息同步、檔案服務、圖片資源、更新檢查與視訊媒體可能使用不同的主網域或第三方內容網路。因此，規則設計應以官方文件、用戶端連線記錄與實際測試結果為準，不要只加入 zoom.us、slack.com 或 google.com 就認為全部流量已經涵蓋。

上表是規劃方向，不是完整的服務網域清單。尤其是 Meet 與 Zoom 的即時媒體流量，可能依照地區、帳號、會議室位置與網路環境選擇不同的伺服器。若只依賴少數網域規則，可能出現登入正常、但加入會議後沒有聲音或畫面卡頓的情況。

規則順序比規則數量更重要

Clash 會依照 rules 從上到下比對，第一條命中後就停止。遠端辦公設定通常可採用「本地與內網優先、工作服務其次、一般境內服務再次、最後才是代理兜底」的順序：

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,zoom.us,WORK
  - DOMAIN-SUFFIX,slack.com,WORK
  - DOMAIN-SUFFIX,google.com,WORK
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

WORK 與 PROXY 只是示意的策略組名稱，必須與設定檔中實際存在的名稱一致。如果訂閱設定檔已經包含同名策略組，不要重複建立；若名稱不同，應在用戶端的規則頁面確認每一條規則實際指向哪個策略組。對 Google Meet 直接使用整個 google.com 後綴可能會讓部分本地 Google 服務也走代理，若不希望如此，可改用連線記錄找出更精確的網域。

工作節點與代理模式的選擇

節點延遲低不等於視訊會議品質好。一般測速只反映一次或少數幾次 TCP、ICMP 請求，Zoom 與 Meet 的實際媒體傳輸則更重視上傳頻寬、封包遺失與持續穩定度。節點挑選應使用相同裝置、相同網路與相同時間段比較，避免把家用 Wi-Fi 的波動誤判成節點問題。

• 優先看延遲與抖動。工作節點最好在距離自己較近、且到目標服務路由穩定的地區。延遲稍高但抖動小，通常比延遲忽高忽低更適合通話。
• 測試上傳而非只測下載。開啟攝影機與麥克風時，本機會持續上傳影音資料。下載速度很高、上傳不穩的節點，仍可能造成畫面降級或聲音斷續。
• 避免會議中頻繁切換。切換節點會重建 TCP、TLS 或 UDP 連線，Slack 長連線也可能重新連接。應在會議前選好節點，不要用自動測速頻繁輪替。
• 優先使用具備 UDP 支援的節點。部分即時通話會嘗試使用 UDP 以降低延遲；若節點或上游只支援 TCP，通常仍可連線，但互動延遲與畫面品質可能較差。
• 保留一個備用策略組。可使用 fallback 或手動選擇組，準備不同地區的兩至三個穩定節點。備用節點不宜過多，否則測試與排錯會變得困難。

日常模式建議使用 Rule，讓工作服務命中 WORK 策略組，內網與本地站點維持直連。若某個服務疑似因規則不完整而失敗，可以短時間切換 Global 做對照；如果全域模式正常、規則模式異常，問題多半在規則或 DNS，而不是節點本身。Direct 則可用來確認本地網路與服務是否原本就能正常連線。

動手設定：建立遠端辦公分流

以下步驟適合已經有 mihomo 設定檔的使用者。若訂閱服務會定期覆蓋完整設定，直接修改訂閱檔可能在下次更新後消失，應優先使用用戶端提供的「覆寫」「Merge」或「Script」功能，或在服務商允許的情況下建立本地設定檔。

1. 先備份目前正在使用的設定檔，記下原有的代理策略組名稱、混合連接埠與 DNS 設定。不要在沒有備份的情況下大幅改寫訂閱內容。
2. 建立名為 WORK 的選擇策略組，加入兩至三個實際測試過的節點，並將一個延遲較低、上傳較穩定的節點設為目前選項。
3. 在規則清單中加入 Zoom、Slack、Meet 的網域規則，將它們放在一般境內直連規則之前，確保工作服務不會先被 GEOSITE,cn 或 GEOIP,CN 截走。
4. 加入本機與區域網路的 DIRECT 規則。若公司內網使用其他私有網段，例如 100.64.0.0/10，應先向 IT 確認後再加入，不要任意放行未知網段。
5. 在用戶端重新載入設定檔，確認沒有 YAML 縮排錯誤，再開啟系統代理。使用 TUN 時，先確認服務模式、虛擬網卡與系統權限都已完成。
6. 依序測試 Slack 訊息同步、檔案下載、Zoom 測試會議與 Google Meet 測試通話。每次只改一項設定，記錄修改前後的結果。

proxy-groups:
  - name: WORK
    type: select
    proxies:
      - Work-Node-1
      - Work-Node-2
      - Work-Node-3
      - DIRECT

mixed-port: 7890
mode: rule
allow-lan: false

如果需要處理不遵循系統代理的桌面程式、命令列工具或 UDP 流量，可在 mihomo 中啟用 TUN。設定時要特別留意 dns-hijack、路由表與既有 VPN 的衝突：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

TUN 開啟後並不代表所有問題都會自動解決。部分公司 VPN、虛擬機器、Docker 網路、區域網路探索與印表機服務可能需要排除或改用 redir-host。若開啟 TUN 後內網消失，先關閉 TUN 做對照，再檢查私有網段、DNS 與路由規則，不要直接把所有流量改成全域代理。

DNS、TUN 與即時通話的穩定性

Zoom、Slack 與 Meet 的連線建立都依賴 DNS。若網域解析被污染、解析結果與代理出口不匹配，常見症狀是登入頁能開啟，但會議服務載入失敗、Slack 反覆顯示重新連線，或聊天訊息延遲很久。啟用 mihomo DNS 模組時，可將常用解析器分為直連解析與代理解析，避免節點網域本身因解析失敗而無法建立連線。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
    - "localhost"
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://192.0.2.53/dns-query
  proxy-server-nameserver:
    - https://192.0.2.53/dns-query

上面的 192.0.2.53 是文件示例保留位址，不是可直接使用的公共 DNS；實際部署時應替換成自己網路中可用、且符合服務政策的解析器。fake-ip 有利於按照原始網域進行分流，但區域網路、內部主機名稱與部分需要真實 IP 的應用程式應加入 fake-ip-filter。若某個會議設備或企業 VPN 與 fake-ip 不相容，可先針對該網域排除，或改用 redir-host 測試。

DNS 的 ipv6 設定也要與 TUN 和本地網路一致。若本地 IPv6 沒有被完整接管，卻仍回傳 AAAA 記錄，應用程式可能優先走 IPv6 直連，形成「瀏覽器正常、部分工作服務偶爾失敗」的狀況。排查時可以暫時將 ipv6 設為 false，確認問題是否消失；若確實需要 IPv6，則應完整配置 IPv6 路由與 DNS 劫持，而不是只開啟一個開關。

會議品質與連線問題排查

遇到卡頓時，先判斷是所有服務都異常，還是只有某一個服務異常。所有網站與應用程式同時變慢，通常與本地 Wi-Fi、路由器、節點擁塞或 TUN 路由有關；只有 Zoom、Slack 或 Meet 其中一項失敗，則較可能是網域規則不完整、UDP 不通、DNS 結果不一致或服務本身的區域路由問題。

排查時可先在 Clash 的連線頁面搜尋 zoom、slack、meet，觀察請求命中的規則與實際出口。若完全看不到某個應用程式的連線，代表它可能繞過系統代理，這時僅修改網域規則沒有用，需要啟用 TUN 或在該應用程式內手動設定 HTTP/SOCKS5 代理。若看得到連線但規則命中錯誤，則應調整規則順序。

完成調整後，先退出並重新開啟應用程式，清除可能殘留的 DNS 快取，再進行一次短時間測試會議。不要在正式簡報前才第一次啟用 TUN 或更換整份設定檔；最好在非正式會議中測試攝影機、麥克風、螢幕分享、檔案傳送與內網存取，並保留一個可快速切回的備份設定。

日常使用檢查清單

正式開始遠端工作前，可以用一分鐘完成以下檢查：確認 Clash 設定檔沒有過期，工作策略組仍選中已測試的節點；確認系統代理或 TUN 狀態與預期一致；先開啟 Slack 觀察是否能正常同步，再進入 Zoom 或 Meet 測試會議；若需要使用公司內網，確認路由器、檔案伺服器與印表機仍可存取。

工作期間不要同時啟用多個 VPN、代理工具或瀏覽器內建代理。多層代理會讓 DNS、MTU、路由與 UDP 行為難以判斷，也可能使企業安全軟體誤判連線。若公司要求使用特定 VPN，應先確認其流量是否需要繞過 Clash，再依 IT 提供的網段與網域建立明確的 DIRECT 或排除規則。

最後，訂閱連結、外部控制器密鑰與完整設定檔都屬於敏感資料，不要貼入公開聊天、截圖或除錯平台。分享問題時只保留去識別化的規則片段、錯誤訊息與網域名稱。按照「規則命中、DNS 結果、節點品質、TUN 狀態、本地網路」的順序排查，通常比直接切換全域模式或不停更換節點更快找出根因。