遠端工作時，Zoom 與 Slack 為什麼特別需要分流
遠端工作最怕的不是完全無法上網，而是看似連得上、實際卻不穩定：Zoom 會議可以登入，進入會議後卻反覆顯示「連線不穩定」；Slack 頻道能載入，訊息通知卻延遲數十秒，檔案預覽與圖片下載也時好時壞。這些問題經常被誤判為節點速度不足，但真正影響體驗的因素還包括 DNS 解析、路由距離、封包丟失、TCP／UDP 相容性，以及不同服務是否被錯誤地送往同一個出口。
Zoom 與 Slack 的流量特性並不相同。Zoom 視訊會議需要持續的低延遲連線，語音與畫面對抖動、丟包非常敏感；Slack 則同時包含 WebSocket 即時訊息、API 請求、檔案服務與外部整合，每一類請求的目的地可能不同。若你直接使用全域代理，所有本地網站、公司內部系統、印表機服務與雲端硬碟都被送往遠端節點，未必能改善 Zoom 或 Slack，反而可能增加延遲與管理風險。
使用 Clash 的重點，是先確認哪些連線真的需要代理，再用規則把它們導向合適的策略群組。對一般遠端工作者而言，較穩妥的方向通常是「本地與公司資源維持直連，指定的跨境協作服務使用代理」，而不是長時間開啟不加區分的全域模式。這樣既能保留本地網站速度，也比較容易在會議出現卡頓時，從 Clash 的連線紀錄找出實際原因。
開始前也要留意公司資安政策。若公司要求使用指定 VPN、零信任用戶端或受管理的 DNS，請不要為了測試 Clash 而繞過這些控制。本文只討論一般的網路分流與用戶端排錯；工作帳號、會議內容與公司資料仍應依照雇主的資訊安全規範處理。
先規劃 Zoom、Slack 與本地服務的流量邊界
修改 YAML 之前，建議先把日常服務分成三類。第一類是必須保持穩定的即時協作流量，例如 Zoom 登入、會議控制、音訊與視訊連線，以及 Slack 的即時訊息通道。第二類是可依實際網路環境調整的內容，例如 Slack 檔案、圖片、Canvas 或外部應用程式預覽。第三類則是本地或公司內部資源，例如內網入口、Git 伺服器、NAS、印表機與本地視訊會議服務。三類流量不應只用「全部代理」或「全部直連」兩個選項粗略處理。
| 流量類型 | 建議策略 | 判斷原因 | 排錯重點 |
|---|---|---|---|
| Zoom 登入與會議服務 | 低延遲節點或穩定策略組 | 對連續性、抖動與丟包較敏感 | 觀察會議期間的延遲、連線持續時間與節點切換 |
| Slack 即時訊息 | 穩定策略組，避免頻繁自動切換 | WebSocket 長連線中斷會造成通知延遲 | 確認訊息服務與登入網域是否命中相同規則 |
| Slack 檔案與外部預覽 | 依連線紀錄補充網域 | 檔案可能使用不同 CDN 或儲存服務 | 下載卡住時不要只測試 Slack 主頁 |
| 公司內網、NAS、印表機 | DIRECT | 通常需要區域網路路由與內部 DNS | 避免被 TUN 或過寬的代理規則攔截 |
| 本地新聞與一般網站 | DIRECT 或既有本地規則 | 不需要代理，直連延遲通常更低 | 確認沒有被一條兜底代理規則覆蓋 |
網域清單不應盲目照抄網路文章。Zoom 與 Slack 會因地區、版本、登入方式、CDN 與功能開關而產生不同目的地；同一家公司也可能把登入、API、媒體與檔案放在不同網域。最可靠的方法是先讓應用程式正常運作一次，再在 Clash 的連線列表中依時間、程序名稱或目的地搜尋，記下實際出現的主機名稱，接著以最小範圍建立規則。
規則順序同樣重要。若前面已經有較寬的規則集，例如把某個大型網域後綴全部設為 DIRECT，後面新增的 Zoom 或 Slack 規則可能永遠不會命中。修改後應重新載入設定，並確認目標規則位於會攔截它的泛用規則之前。對不確定的網域，寧可先觀察連線紀錄，也不要一次加入大量模糊的通配符，否則日後很難知道是哪條規則造成異常。
動手設定：在 Clash 中建立可驗證的工作分流
以下流程適合使用 Clash Verge、Clash Verge Rev 或其他基於 Mihomo／Clash Meta 核心的桌面用戶端。不同版本的按鈕名稱可能略有差異，但操作邏輯相同：先備份、再確認埠位，接著建立分流，最後用實際會議驗證，而不是只看設定頁面顯示「已啟用」。
- 備份目前設定：先匯出或複製正在使用的 YAML。若設定來自訂閱，請確認你修改的是實際生效的覆寫檔或合併設定，而不是下載資料夾裡尚未載入的副本。
- 確認代理埠與模式：記下
mixed-port或用戶端顯示的本機代理埠。先使用「規則」模式，不要在第一輪測試就同時開啟全域模式、TUN 與另一套 VPN，避免多個路由層互相干擾。 - 準備策略群組：建立一個適合長時間工作連線的群組，例如工作代理或低延遲節點群組。測試時不要頻繁啟用自動切換；若節點在會議中被重新選擇，短暫斷線可能比固定使用稍慢但穩定的節點更明顯。
- 加入最小規則：將你在連線列表中確認的 Zoom、Slack 目的地放到工作策略群組，內網與本地服務則保留 DIRECT。規則語法必須符合目前核心支援的格式，修改前可先用一兩個網域測試，不要一次替換整份訂閱。
- 重新載入並確認命中：儲存設定後重新載入配置，關閉並重新開啟 Zoom 或 Slack。只要應用程式保留舊連線，畫面上的結果就可能不能代表新規則；重新啟動能讓測試條件比較乾淨。
- 分別測試功能：先登入 Slack、傳送訊息，再上傳一個小型檔案；Zoom 則先進入測試會議，確認麥克風、鏡頭、畫面分享與會議聊天。每測一項就回到 Clash 連線紀錄，記下目的地、策略、延遲與是否重連。
# Example structure only; adapt names to your active configuration
mixed-port: 7890
mode: rule
rules:
- DOMAIN-SUFFIX,example-work-service.test,WORK
- DOMAIN-SUFFIX,example-internal.test,DIRECT
- MATCH,DIRECT上面的網域只是結構示例，不代表 Zoom 或 Slack 的完整官方網域，也不應直接複製到正式設定。實際操作時，請用連線紀錄看到的目的地替換示例內容，並依你所在的公司網路與訂閱格式調整。若你使用的是訂閱提供的規則集，優先透過覆寫功能新增少量規則，避免直接修改每次更新都會被覆蓋的原始檔。
用連線紀錄判斷卡頓原因，而不是盲目換節點
如果 Zoom 影像卡住，先看會議期間是否出現大量重連、策略頻繁切換或連線在短時間內消失。延遲低並不代表品質一定好：某個節點可能測速結果漂亮，卻在長時間 UDP 媒體流量下丟包嚴重。若用戶端或網路環境不適合 UDP，可能需要比較不同節點與傳輸路徑；不要只根據瀏覽器下載速度判斷會議品質。
Slack 的問題則要拆開看。能收到文字訊息但檔案下載失敗，通常表示即時訊息通道已經正常，真正需要檢查的是檔案 CDN、儲存服務或公司安全閘道。若 Slack 整個工作區反覆顯示離線，應查看 WebSocket 相關連線是否持續、是否被規則送到不同策略，以及系統時間、DNS 和公司 VPN 是否正常。每次只改一個變數，才能知道改善到底來自規則、節點還是應用程式重新建立了連線。
遇到「瀏覽器正常、Zoom 或 Slack 不正常」時，常見原因是應用程式沒有使用系統 Proxy。有些桌面程式讀取系統代理，有些程序則使用自己的網路堆疊；這時可以先在應用程式設定中確認代理選項，或在受控的測試終端設定 HTTP_PROXY、HTTPS_PROXY 與必要的 NO_PROXY。但請注意，將內網網域加入 NO_PROXY 後可能改變路徑，應依公司政策與實際需求配置，不要把整個網路範圍粗略排除。
TUN 模式可以涵蓋更多不遵循系統代理的程式，但它不是所有問題的萬用解法。開啟後若公司 VPN、虛擬網卡、零信任客戶端與 Clash 同時搶著管理路由，可能造成內網無法存取、DNS 循環或會議連線忽好忽壞。建議先用系統代理完成最小測試，再在確認必要時單獨啟用 TUN，並記錄啟用前後的路由、DNS 與連線列表差異。
安全性方面，請避免在排錯時把完整工作區名稱、邀請連結、會議網址或公司內部網域公開貼到論壇。訂閱連結、代理憑證與環境變數也應視為敏感資料。完成測試後，可以刪除臨時規則、關閉不必要的除錯日誌，並把穩定的設定以版本化方式保存，讓日後更換電腦或節點時仍能快速復原。
相比只提供單一全域開關、遇到會議卡頓就只能反覆換伺服器的同類工具，Clash 能把 Zoom 的低延遲需求、Slack 的長連線與檔案流量，以及公司內網的直連路徑分開管理，還能透過連線紀錄和規則命中結果逐項驗證；如果你希望在不拖慢本地工作服務的前提下整理遠端協作網路，使用 Clash 會更容易建立一套可觀察、可回復的工作環境。