Clash 遠端辦公設定：Zoom、Slack 穩定連線完整方案

遠端辦公最怕的不是沒有代理，而是流量沒有被正確分流：Zoom 視訊會議突然卡住、Slack 訊息延遲數十秒、公司內網被錯誤送到代理節點，甚至所有網站都繞行海外後導致本地服務變慢。Clash 或 Mihomo 可以透過策略組、域名規則、節點故障切換與 DNS 分流，將會議、協作工具、公司服務和一般網站分別處理。本文以 Windows、macOS 及 Linux 桌面端常見的 Clash Verge、Clash Verge Rev 與 Mihomo 為例，整理一套適合日常遠端工作的穩定配置方案。

先規劃遠端辦公的流量路徑

穩定配置的第一步不是直接貼上一份 YAML，而是先確認不同服務的網路需求。Zoom 需要持續且穩定的雙向連線，除了登入和會議控制頁面之外，還可能使用多個媒體伺服器傳送音訊、影像與螢幕分享資料。Slack 則同時包含登入、訊息同步、檔案預覽、圖片載入和 WebSocket 長連線。若只加入一個主域名，常會出現「能登入但訊息不更新」或「文字正常、檔案打不開」的情況。

建議把工作流量分成四類：第一類是需要穩定代理的遠端協作服務；第二類是公司 VPN、內網、印表機和區域網裝置，應保持直連；第三類是本地常用網站與影音服務，通常直連速度更快；第四類才是其他未分類流量，交給預設策略處理。這種設計比單純使用 G​​LOBAL 更容易排錯，也能避免整台電腦的流量不必要地繞行。

節點選擇也要符合工作情境。不要只看測速頁面的延遲數字：一個節點可能對測速網址延遲很低，但跨區連線品質不穩，Zoom 會議中仍會出現聲音斷續。遠端辦公應優先觀察丟包率、晚間尖峰穩定度、TCP 建連時間，以及是否支援 UDP。若公司網路限制 UDP，則要準備一個 TCP/TLS 節點作為備用。

建立 Zoom 與 Slack 專用策略組

建議不要讓 Zoom 和 Slack 直接使用同一個會自動跳動的 url-test 策略組。自動測速雖然方便，但會議進行期間切換出口，可能造成連線重建、登入狀態失效或語音短暫中斷。更穩妥的做法是建立一個「辦公代理」策略組，平時手動選擇主節點，並建立一個「辦公備援」組在主節點無法使用時提供切換。

proxy-groups:
  - name: 辦公代理
    type: select
    proxies:
      - 辦公主節點
      - 辦公備援
      - DIRECT

  - name: 辦公備援
    type: fallback
    proxies:
      - 節點-HK-01
      - 節點-JP-01
      - 節點-SG-01
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: true

fallback 會依照節點順序使用第一個可連線的節點，適合會議進行時的主備切換；url-test 則會根據測速結果自動選優，適合開始工作前或日常瀏覽。若你有多個品質相近的節點，可以另外建立「辦公自動選優」組，但最好在 Zoom 會議前手動固定一個穩定節點，不要讓測速組在會議中自由切換。

Slack 的流量不一定全部集中在 slack.com。實際使用時還可能遇到工作區自訂域名、檔案 CDN、圖片服務和第三方登入域名。因此，規則應先覆蓋常見主域名，再透過 Dashboard 的 Connections 頁面檢查實際命中的域名。Zoom 同樣可能使用區域媒體伺服器；如果會議畫面正常但音訊品質很差，應查看連線紀錄，而不是盲目更換整份配置。

動手配置辦公分流規則

以下步驟適合在 Clash Verge Rev 或其他支援 Mihomo 配置的客戶端中操作。請先備份目前使用的配置檔案，再依序加入策略組與規則。不同客戶端的訂閱配置可能由遠端生成，若本地修改在更新訂閱後消失，應將內容放入客戶端的覆寫或 Merge 配置，而不是直接修改訂閱原檔。

1. 開啟客戶端的配置管理頁面，確認目前使用的是 Mihomo 或相容的 Clash 核心，並匯出一份備份。
2. 在 proxy-groups 中加入辦公代理策略組，將實際節點名稱替換為你配置中已存在的名稱。
3. 在 rules 中先加入 Zoom、Slack 和公司內網規則，再放入一般本地直連規則，最後才使用兜底規則。
4. 重新載入配置，打開 Dashboard 的連線列表，依序啟動 Slack、開啟 Zoom 登入頁，再測試會議預覽。
5. 確認每條連線的命中規則與策略組。若發現某個檔案或圖片仍失敗，記下實際域名後補充規則，不要直接把所有流量切換成全局代理。

rules:
  # Collaboration services
  - DOMAIN-SUFFIX,zoom.us,辦公代理
  - DOMAIN-SUFFIX,zoom.com,辦公代理
  - DOMAIN-SUFFIX,slack.com,辦公代理
  - DOMAIN-SUFFIX,slack-edge.com,辦公代理

  # Company network and private addresses
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
  - 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

  # Local services
  - GEOIP,CN,DIRECT
  - MATCH,辦公代理

如果公司使用正式的 VPN 客戶端，請先確認 VPN 的路由模式。部分 VPN 會接管預設閘道，導致 Clash 規則看似正確但實際流量沒有經過 Clash；另一部分 VPN 只為公司網段建立路由，則可以讓公司域名與私有 IP 直連。遇到內網無法開啟時，檢查作業系統的路由表、VPN DNS 和 Clash 的 TUN 設定，比單純增加代理節點更有效。

DNS、TUN 與會議穩定度調整

DNS 會直接影響 Slack 登入、Zoom 伺服器選擇和首次連線速度。使用 Mihomo 時，可以考慮以 fake-ip 搭配域名規則，讓 Clash 在取得真實 IP 前就能根據域名分流。對於區域網主機、公司內部解析域名和依賴真實 IP 的特殊應用，則應加入 fake-ip-filter，避免它們收到假 IP 後無法工作。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '*.corp.example.com'
    - 'localhost'

TUN 模式適合希望統一接管桌面應用的使用者，因為 Zoom、Slack、瀏覽器和其他不支援系統代理的程式，都能透過虛擬網卡交給 Clash 處理。不過，啟用 TUN 後應留意系統權限、路由衝突和 VPN 相容性。若只是瀏覽器與 Slack 使用代理，系統代理模式通常更簡單；若需要管理多個原生應用，才值得使用 TUN。

會議前可以做一次固定檢查：先用 Zoom 的測試會議確認音訊，再讓 Slack 發送一則訊息並上傳小型檔案，最後開啟公司內網與本地網站。若三者都正常，代表代理、直連和 DNS 分流基本符合預期。會議期間如果出現卡頓，先查看 Clash 即時連線中的上行、下行流量和節點延遲；持續丟包通常應更換節點或網路，而不是反覆清除 DNS 快取。

常見問題與排錯順序

Slack 能登入但通知延遲：先檢查 WebSocket 或長連線相關域名是否命中辦公代理，再確認系統是否啟用了省電或休眠網路限制。若 Slack 桌面版與瀏覽器結果不同，查看兩者是否使用不同的代理設定。

Zoom 可以進入會議但沒有聲音：確認防火牆是否限制 UDP，並檢查音訊媒體連線是否走了與登入頁不同的路徑。可以先切換到支援 UDP 的節點；若企業網路封鎖 UDP，改用穩定的 TCP/TLS 節點，通常比強行恢復 UDP 更可靠。

公司內網變慢或無法訪問：檢查公司域名是否被寬泛的代理規則攔截，也要確認私有網段規則已加入 no-resolve，避免 Clash 為內部 IP 額外執行 DNS 解析。若公司 VPN 提供專用 DNS，應按照企業 IT 文件設定，而不是直接套用公共 DNS。

切換訂閱後規則失效：多數情況是修改了訂閱原檔，更新後被新內容覆蓋。請使用客戶端提供的覆寫、Merge 或腳本功能保存自訂策略組和規則，並在每次核心更新後確認欄位名稱是否仍受支援。

完成配置後，建議連續觀察幾個工作日，記錄 Zoom 會議時段、Slack 同步狀態、節點延遲和網路切換情況，再決定是否調整策略。當分流規則清楚、DNS 路徑正確、節點主備關係穩定時，Clash 就能在不拖慢本地網站的前提下，為遠端協作提供更可靠的連線體驗。