遠端辦公最怕的，不是沒有代理而是路徑混在一起
對遠端工作者來說，Zoom 視訊、Slack 訊息、瀏覽器文件、公司內網與本地開發服務，往往同時在同一台電腦上運作。真正讓人困擾的通常不是「Clash 能不能連上」，而是不同流量應該走哪條路徑：Zoom 需要穩定的音訊與視訊連線，Slack 需要長時間維持 WebSocket 或事件連線，公司的 Git、NAS、ERP 與印表機則應該留在直連或內網路由。如果所有流量都交給同一個節點，延遲、頻寬與公司資源存取就容易互相牽制。
常見的錯誤做法是只開啟系統代理，然後期待所有應用程式都自動遵守設定。瀏覽器可能因此正常載入網頁，但 Zoom 桌面版、Slack 原生客戶端、終端機或背景更新服務未必使用相同的代理介面。另一種極端則是直接開啟全域代理，雖然看似簡單，卻可能讓公司內網、銀行網站、區域服務或本機開發環境繞遠路。比較穩妥的思路是先確認客戶端能正常工作，再用網域分流、策略群組與必要的 TUN 模式建立可觀察、可回復的配置。
合規提醒：Clash／mihomo 是本機流量轉送與規則管理工具，不提供遠端節點。請使用自己合法取得的訂閱或設定檔，並遵守公司網路政策、Zoom／Slack 服務條款與所在地法規。
先分清 Zoom、Slack 與本地服務的網路需求
在編寫規則前，建議不要先搜尋一份「Zoom 全域名清單」直接貼上。遠端辦公的穩定性更依賴流量分類是否合理，以及連線是否持續使用同一個策略。Zoom 的會議流量包含登入、會議控制、音訊、視訊與螢幕分享，不同版本和地區可能使用不同的主機；Slack 則包含工作區登入、訊息同步、檔案預覽、通知與長連線。最可靠的做法，是先在 Clash 的連線列表中觀察實際出現的主機，再補充規則。
| 流量類型 | 建議路徑 | 設定重點 |
|---|---|---|
| Zoom 會議與螢幕分享 | 固定的低延遲策略組 | 避免會議期間自動切換節點，優先測試延遲、丟包與上傳穩定性 |
| Slack 工作區與訊息同步 | 穩定代理策略組 | 注意長連線、通知與檔案主機，不要只規則化登入頁 |
| 公司內網、NAS、印表機 | DIRECT | 保留區域網路與公司網段直連，避免代理節點無法回到內部服務 |
| 一般本地網站與銀行服務 | DIRECT 或本地策略 | 以所在地與公司要求為準，避免不必要的繞路與驗證風險 |
Zoom 分流的實務原則
Zoom 的問題常被誤判為「節點速度不夠快」。實際上，視訊會議更在意持續延遲、丟包率、上傳品質與路徑是否中途改變。即使某個節點測速結果很漂亮，只要會議中策略組重新選擇節點，既有的 UDP、TCP 或加密連線就可能受到影響。建議建立一個專門給會議使用的策略組，手動選定已測試過的節點，先不要使用會頻繁切換成員的自動測速組。
規則可以從常見的 Zoom 相關主機開始，例如 zoom.us、zoom.com 以及連線日誌中實際顯示的 API 或會議服務網域。但不要把所有含有「zoom」字樣的流量無條件送往同一出口，也不要把會議規則寫成過於寬泛的 DOMAIN-SUFFIX,us。如果 Zoom 可以登入卻無法加入會議，應優先檢查連線列表是否出現新的主機、規則是否命中預期策略，以及防火牆是否允許桌面客戶端存取網路。
Slack 設定不能只處理登入頁
Slack 桌面版的使用體驗，取決於工作區登入、訊息 API、通知通道、檔案服務與即時連線能否保持一致。只為 slack.com 加上一條規則，有時足以載入首頁，卻不代表頻道訊息、提醒或檔案預覽也會走同一路徑。遇到「訊息延遲很久才出現」「通知偶爾消失」「頻道能開但檔案載入失敗」時，請打開 Clash 連線紀錄，在問題發生的當下記下實際主機與命中規則。
Slack 的長連線對節點切換同樣敏感。若策略組採用 url-test，測試間隔太短可能使工作時段頻繁更換出口；若使用 fallback，則應先確認備援成員的連通性與地區是否符合工作需求。比較保守的做法是把 Slack 放到穩定策略組，在工作時間固定節點，只有確認斷線或延遲持續異常時才手動切換。檔案下載與預覽若出現獨立 CDN 網域，則按照日誌逐步補規則，不建議一開始把整個雲端服務網域全部代理。
動手設定：在 Clash 中建立遠端辦公分流
以下流程適用於 Clash Verge Rev、Mihomo Party 及其他支援 Mihomo 設定的客戶端。不同版本的按鈕名稱可能略有差異，但判斷方式相同：先讓設定檔生效，再確認規則命中，最後才處理 TUN 或應用程式代理。
- 備份目前設定：先複製正在使用的 YAML 或 profile，另存一份遠端辦公版本，例如
remote-work.yaml。不要直接在唯一設定檔上大幅修改，這樣測試失敗時才能快速回復。 - 建立策略組：新增「工作會議」策略組，放入兩至三個已確認可用的節點；再建立「工作訊息」策略組。若實際節點品質相近，也可以共用一個穩定代理組，但會議期間最好保持手動選擇。
- 加入網域規則：將 Zoom、Slack 的實際主機放在對應策略組之前，並把公司內網、區域網路與本機服務保留為
DIRECT。規則由上而下匹配，不能把寬泛的 GEOIP 或 MATCH 規則放在應用程式規則前面。 - 重新載入設定：儲存並重新載入 profile，確認 YAML 縮排、策略組名稱與規則引用完全一致。若核心拒絕啟動，先看錯誤行號，不要在未定位問題前連續修改多項設定。
- 先測試 Slack：重新開啟 Slack，傳送一則測試訊息、切換兩個頻道並下載一個小型檔案，接著在 Connections 中確認相關主機命中「工作訊息」策略組。
- 再測試 Zoom：用測試會議檢查登入、加入會議、麥克風、攝影機與螢幕分享。記錄延遲、畫面凍結和音訊斷續情況，測試期間不要讓策略組自動換節點。
- 最後決定是否啟用 TUN：若終端機、Slack 或 Zoom 沒有遵守系統代理，再考慮 TUN 模式；完成權限授權後重新測試，並避免同時開啟多個互相衝突的虛擬網路工具。
測試技巧：一次只改一個變數。先固定節點，再確認規則；先測試系統代理，再測試 TUN。若同時更換核心、DNS、策略組與網路環境，最後即使恢復正常，也很難知道真正原因。
TUN、DNS 與會議中斷的排查方法
如果瀏覽器正常、Slack 正常，但 Zoom 桌面版完全沒有連線紀錄，通常代表該應用程式沒有使用系統代理，或流量被其他安全軟體攔截。這時可以在支援的客戶端啟用 TUN，讓核心在網路層接管更多未遵守代理設定的程式。啟用前要完成管理員權限、虛擬網卡與防火牆授權，並先記錄原本的系統代理狀態，方便出現問題時還原。
TUN 並不是「一開就一定更快」。它可能改善應用程式不走 HTTP／SOCKS 代理的問題，也可能因 DNS、路由表、VPN、企業端點防護或其他虛擬網卡產生衝突。若開啟 TUN 後公司內網失效，應檢查內網網段是否有 DIRECT 規則，以及 DNS 是否仍能解析公司內部名稱。若只有 Zoom 斷線，則要觀察 UDP 是否被當前節點或網路環境限制；必要時可在客戶端或設定檔中測試 TCP 相容方案，但應以實際音訊品質為判斷，不要只看連線狀態。
DNS 方面，最重要的是讓「解析結果」與「實際出站策略」不要互相矛盾。若啟用 fake-ip 或 redir-host，請確認 Zoom、Slack、公司內網網域的處理方式符合你的環境；部分企業內部名稱只能由公司 DNS 解析，不能一概交給外部 DNS。遇到登入循環、TLS 錯誤或服務偶爾顯示離線時，可依序檢查：連線列表中的主機、命中規則、DNS 回應、策略組成員、系統時間，以及公司防火牆或安全代理是否介入。
| 問題現象 | 優先檢查 | 不要先做的事 |
|---|---|---|
| Zoom 可登入但加入會議失敗 | 會議主機是否命中固定策略、UDP／TCP 連通性與防火牆 | 不要立即把所有 Google、Microsoft 網域全部加入代理 |
| Slack 訊息延遲或通知消失 | 長連線是否中途換節點、檔案或事件主機是否被漏規則 | 不要只重裝 Slack 而忽略 Clash Connections |
| 開 TUN 後內網無法使用 | 公司網段、內部 DNS 與 DIRECT 規則 | 不要用全域代理掩蓋路由設計問題 |
| 會議中途頻繁卡頓 | 節點丟包、上傳頻寬、策略組自動切換與 Wi-Fi 品質 | 不要只用一次延遲測試結果判斷節點長期穩定 |
把設定變成可維護的工作流程
完成初次設定後，建議為遠端辦公保留一份獨立 profile，而不是每天手動修改主設定。這份 profile 可以只放工作所需的策略組與規則，並在註解中記錄測試日期、使用過的節點和已確認的主機。當 Zoom 或 Slack 更新客戶端後，先觀察新的連線紀錄，再決定是否增加規則；不要因為某次短暫失敗，就把整個服務改成全域代理。
工作前可用三分鐘完成自檢：先確認 Clash 核心正在運作，接著檢查策略組仍選中預期節點，再傳送 Slack 測試訊息，最後加入 Zoom 測試會議。若公司網路、家用 Wi-Fi 和手機熱點之間切換頻繁，應分別測試 DNS、TUN 與節點表現，因為同一份設定在不同網路下可能有完全不同的結果。會議進行中不建議更新訂閱或觸發自動測速，避免策略組重排造成既有連線中斷。
與許多只提供全域開關的同類工具相比，部分方案在 Zoom 長連線、Slack 通知與公司內網並存時，容易遇到設定層級混亂、規則命中不可見，或不同平台的操作說明不完整等限制；Clash 官網 則把策略分流、TUN／系統代理差異、連線日誌與逐步排錯放在同一套清楚的操作脈絡中，方便你依實際主機和工作環境調整，而不是盲目套用寬泛規則。若你正準備為遠端辦公建立一份可回復、可檢查的 Clash 設定，不妨前往下載合適的客戶端，再按照本文流程逐項驗證。