遠端工作最常見的網路問題：不是所有流量都該走同一條路
在家工作時，Zoom、Slack、Google Meet通常會同時執行，旁邊還可能開著公司內網、雲端硬碟、GitHub、新聞網站與本地影音服務。若 Clash 長期使用全域代理，所有連線都被送往同一個代理出口，視訊會議或 Slack 通話雖然可能變得穩定，卻也可能讓本地網站載入變慢；反過來，若全部使用直連，某些會議控制面板、Slack WebSocket 或 Google Meet 的媒體連線又可能在公司網路、公共 Wi-Fi 或特定 DNS 環境下逾時。
遠端辦公真正需要的不是「所有流量都代理」，而是讓不同類型的流量各自走合適的路徑。視訊與即時通訊重視的是延遲、抖動、封包遺失與長連線穩定度；公司內網重視的是可達性與存取政策；一般本地服務則更適合直連。Clash 的規則分流可以把這些需求拆開處理，先讓會議服務進入穩定的代理策略組，再把公司網域、區域網站與內部 IP 保留為 DIRECT，避免不必要的繞路。
還要注意，Zoom、Slack 與 Meet 並不是只連到一個固定網域。登入、工作區同步、聊天訊息、檔案預覽、會議控制與影音媒體可能使用不同的主機或 CDN。只把首頁網域加入規則，常會出現「能登入但不能加入會議」「文字訊息正常但通話中斷」或「瀏覽器版正常、桌面版異常」等情況。因此，設定完成後應以 Clash 的連線紀錄確認實際命中的目的地，而不是只看 YAML 是否能成功儲存。
先建立分流策略：依服務類型，而不是只靠國家或地區判斷
對遠端工作而言，最容易維護的做法是建立一個專用策略組，例如 WORK-REMOTE，並準備至少兩個可用節點。不要只依賴「自動選擇」後就不再觀察，因為自動測試通常只反映短時間的 TCP 或 HTTP 延遲，未必能代表 Zoom 會議中持續上傳音訊、Slack 即時連線或 Meet 螢幕分享的實際表現。建議先選一個延遲較低、長連線穩定的節點，再保留另一個不同線路的備援。
| 流量類型 | 建議路徑 | 設定重點 | 驗證方式 |
|---|---|---|---|
| Zoom 登入與會議控制 | WORK-REMOTE | 觀察登入、加入會議與會議中重新連線是否命中同一策略 | 查看連線紀錄及會議內網路統計 |
| Slack 工作區與即時通訊 | WORK-REMOTE | 注意 WebSocket、檔案預覽及通知服務是否被規則漏掉 | 測試訊息延遲、檔案開啟與通話 |
| Google Meet 與 Google 登入 | WORK-REMOTE 或可信策略組 | 登入、會議頁面與媒體相關連線可能分屬不同主機 | 加入測試會議並觀察封包遺失與抖動 |
| 公司內網、印表機、NAS | DIRECT | 保留內部網域及 RFC1918 私有位址直連 | 確認內網 DNS、檔案分享與列印仍可用 |
| 一般本地網站與影音 | DIRECT | 避免所有日常瀏覽流量佔用遠端節點頻寬 | 比較直連與代理時的載入速度 |
規則順序同樣重要。通常應先處理明確的公司內網、區域網路與工作服務，再處理較寬泛的 GEOIP 或 FINAL 規則。若先放一條過大的直連規則，後面的 Zoom、Slack 或 Google 規則可能永遠不會命中；若先使用過大的代理規則，也會把印表機、NAS 與公司 VPN 流量一起送走。修改前最好先備份目前真正載入的設定檔，並確認是訂閱原檔、覆寫檔，還是本地設定檔在生效。
網域名稱應以實際連線紀錄為準。常見的基礎觀察對象包括 Zoom 相關網域、Slack 工作區與 API 網域，以及 Google Meet 使用的 Google 服務網域，但不同版本的桌面客戶端、瀏覽器與企業租戶可能會出現額外主機。不要把整個大型服務的所有網域無條件代理，也不要只憑網路文章複製一份過時清單；較穩妥的方式是先加入核心網域，測試一項功能，再依紀錄補規則。
動手設定：在 Clash Verge Rev 中完成遠端工作分流
以下流程以支援 Mihomo／Clash Meta 核心的 Clash Verge Rev 為例。不同版本的選單名稱可能略有差異，但判斷邏輯相同：確認組態、建立策略、加入規則、啟用系統代理，最後用實際會議驗證。若你使用 Clash for Windows、ClashX、Clash for Android 或其他 Mihomo 用戶端，也可以沿用同一套規則設計，只需將設定項目放到對應介面。
- 確認目前設定檔：開啟 Clash Verge Rev 的設定檔頁面，確認你要修改的檔案已載入並處於使用中。若訂閱更新後會覆蓋手動修改，請將自訂規則放進覆寫或 Merge 檔，而不是直接改動遠端訂閱。
- 確認代理策略組：建立或找出一個專門給工作流量使用的策略組，例如
WORK-REMOTE。至少準備兩個節點，先以延遲、丟包及長時間連線穩定性綜合判斷，不要只看單次速度測試。 - 加入精確規則：將你在 Zoom、Slack、Meet 測試時看到的核心網域，依序指向
WORK-REMOTE。規則要放在寬泛的直連、代理或 GEOIP 規則之前。公司內網網域、區域網路 IP 與本地服務則保留 DIRECT。 - 開啟系統 Proxy：先只啟用系統代理，不要一開始就同時開啟 TUN、其他 VPN 與多套代理工具。這樣較容易判斷瀏覽器與支援系統代理的桌面程式是否已進入 Clash。
- 重新載入並查看連線：儲存設定後重新載入配置，開啟連線列表，依目的地搜尋 Zoom、Slack、Google 或 Meet。確認策略欄顯示的是預期的工作策略組，而不是 DIRECT 或錯誤的節點。
- 執行分階段測試：先測登入，再測加入會議、開啟鏡頭與麥克風、螢幕分享、Slack 檔案下載及 Meet 聊天。每完成一項就看連線紀錄，這比一次同時啟動所有程式更容易定位漏規則的位置。
如果桌面版 Zoom 或 Slack 完全沒有出現在連線列表，問題可能不是規則，而是程式沒有遵循系統代理設定。此時可先查看應用程式本身是否有獨立的 Proxy 選項；對瀏覽器版服務，則確認瀏覽器沒有被其他擴充功能或公司 VPN 接管。只有在確認請求確實繞過系統代理時，才考慮啟用 TUN。TUN 能涵蓋更多不遵循系統設定的程式，但也可能與公司 VPN、零信任客戶端、虛擬機器或 Docker 網路產生路由衝突。
若需要以 YAML 表達大致結構，可以先用下列概念檢查規則順序，再按照你的訂閱格式調整策略組名稱：
rules:
- DOMAIN-SUFFIX,example-work-domain.com,WORK-REMOTE
- DOMAIN-SUFFIX,company.internal,DIRECT
- GEOIP,LAN,DIRECT
- MATCH,DIRECT上面的網域只是結構示例，不代表 Zoom、Slack 或 Meet 的完整官方清單。實際使用時，應以你自己的連線紀錄、企業網路文件與服務供應商說明為依據。若把不存在的網域大量加入規則，除了增加維護成本，也可能讓你誤以為所有相關連線都已被覆蓋。
會議品質驗證與故障排查：把「卡頓」拆成可觀察的原因
視訊會議卡頓不一定是節點速度慢。Zoom、Slack Huddle 與 Google Meet 都會根據即時網路狀況調整解析度、音訊位元率與畫面更新頻率，因此應把問題拆成延遲、抖動、丟包、上傳頻寬和 DNS 解析五個方向。若只有畫面模糊但語音穩定，可能是上傳頻寬不足；若語音斷續、人物突然消失，則更像丟包或抖動；若進入會議前一直轉圈，才需要優先檢查登入與控制面板網域。
- 能登入但無法加入會議：檢查登入服務與會議控制連線是否走同一策略，並查看瀏覽器是否被快取的登入狀態誤導。
- 文字訊息正常但 Slack 通話中斷：不要只測試 Slack 網頁能否開啟，還要觀察通話建立後的長連線與媒體連線；必要時比較桌面版與瀏覽器版的連線列表。
- Meet 進入後沒有聲音或鏡頭：先確認作業系統的麥克風與攝影機權限，再確認代理規則。權限被拒絕時，單純更換節點不會解決問題。
- 本地網站突然變慢：查看是否有過寬的
MATCH,WORK-REMOTE或全域代理模式，並確認公司內網與本地服務規則位於正確位置。 - 只有開啟 TUN 後才正常：代表某個程式可能未讀取系統 Proxy，或它使用了不同的網路堆疊。先記下 TUN 的改善效果，再評估是否能用應用程式 Proxy 或環境變數替代，避免長期承擔路由衝突。
遠端工作還有一個容易忽略的因素：公司資安政策。部分企業會要求使用指定 VPN、零信任代理或受管理的 DNS，這些系統可能與 Clash 同時改寫路由。遇到公司服務異常時，不應直接停用安全工具或繞過管理政策；應先確認允許的網路路徑，再把 Clash 的分流範圍縮小到個人允許使用的流量。對機密會議、客戶資料與公司檔案，也要遵守雇主的記錄、傳輸與端點安全要求。
與只提供單一全域開關的工具相比，某些簡化型代理程式在臨時瀏覽時很方便，但遇到 Zoom、Slack、Meet 同時運作，往往難以分辨是 DNS、長連線還是特定網域未命中；另一類只靠瀏覽器擴充功能的方案又可能完全覆蓋不到桌面版會議與背景同步。Clash 的優勢在於可用規則把工作服務、公司內網與一般本地流量分開，並透過連線紀錄逐筆驗證；如果你希望依本文的分流思路建立更可控的遠端工作環境，可以前往下載適合自己平台的 Clash 用戶端。