遠距辦公的分流思路：只代理會議與協作服務
在家工作時，最常見的困擾不是「所有網站都打不開」，而是 Zoom 會議偶爾卡住、Slack 訊息延遲，或切換節點後公司內部網站反而無法登入。這類情況不一定代表節點速度太慢，也可能是流量走錯出口、DNS 解析不一致，或代理用戶端沒有接管該應用程式的連線。設定前先把目標說清楚：讓需要穩定連線的辦公服務依規則使用代理，其他日常網站與公司內部資源則維持直連，避免把整台電腦的流量都送往同一個節點。
Clash Verge Rev、Mihomo 等用戶端通常提供規則模式、全域模式與直連模式。遠距辦公建議以規則模式作為起點，再觀察 Zoom、Slack 的連線是否命中預期策略。全域模式雖然方便測試，卻可能讓公司 VPN、內網入口、印表機或視訊設備也跟著改走代理；如果同時使用公司提供的 VPN 或零信任客戶端，更可能發生路由競爭。遇到受公司管理的裝置或網路時，請先確認相關政策允許使用代理工具，不要擅自變更受管理的安全設定。
Zoom 與 Slack 都不一定只連到一個固定網域。Zoom 會議可能涉及登入、會議控制、媒體傳輸與更新等不同連線；Slack 也可能使用不同主機處理工作區、檔案及即時通訊。服務端點會隨產品、地區與版本變動，因此不宜把網路上找到的長串網域清單直接貼進設定。較可靠的做法是先從 Clash 的連線紀錄觀察實際目的網域，再逐項確認哪些連線確實與會議或訊息功能相關。
- Zoom 會議不穩：留意登入與會議相關連線是否命中代理策略，並確認目前出口節點在開會時沒有明顯丟包或延遲波動。
- Slack 訊息延遲：觀察工作區、即時連線及檔案傳輸是否都經過預期規則；不要只測試 Slack 網站能否開啟，就認定 App 的連線路徑正確。
- 公司內網受影響：確認內部網域與私有 IP 範圍仍走直連，避免代理規則攔截公司入口、單一登入頁面或內部服務。
挑選代理模式與節點：先穩定，再比較速度
Zoom 的體感品質不只取決於下載速度。視訊和語音對延遲、抖動與封包遺失都很敏感；測速結果看起來很快的節點，如果路由不穩或高峰期容易丟包，仍可能讓畫面凍結、聲音斷續。選節點時，請在接近你實際工作時段的時間測試，並以同一場測試會議比較不同節點，而不是只看一次延遲測試的數字。
| 設定方式 | 適用情況 | 需要留意 |
|---|---|---|
| 規則模式＋指定策略群組 | 只希望 Zoom、Slack 等特定連線使用代理 | 規則必須排在可能提前命中的廣泛規則之前，且策略群組名稱要與設定檔一致 |
| 全域模式短時間測試 | 用來判斷服務是否受直連路徑影響 | 測試後切回規則模式，避免內網與一般流量長時間經過同一出口 |
| TUN 模式 | 應用程式不理會系統代理，或部分連線未出現在一般代理紀錄中 | 可能與公司 VPN、端點防護或其他路由工具衝突，啟用前先確認管理政策 |
特別要注意視訊媒體傳輸。部分 Zoom 連線可能使用 UDP，而一般系統 HTTP／HTTPS 代理不一定能接管這類封包。若連線紀錄顯示登入與會議控制已依規則走代理，但會議仍持續卡頓，問題可能在媒體傳輸路徑、Wi-Fi 品質、出口節點或公司網路限制，不應只靠增加網域規則處理。這時可先比較直連與代理的會議品質，再依用戶端支援情況檢查 TUN；如果公司 VPN 已接管流量，先詢問管理員是否允許並存，避免自行疊加多套網路接管功能。
動手設定：新增 Zoom 與 Slack 規則並確認命中
以下以 Mihomo 常見的 YAML 規則格式說明。不同訂閱可能使用不同策略群組名稱，也可能透過線上設定檔管理規則；修改前先備份目前可用的設定，並確認你編輯的是實際載入中的設定檔。若訂閱每次更新都會覆蓋本機修改，請使用用戶端支援的覆寫、合併或本地規則功能，不要直接改動無法持久保存的生成檔。
- 先確認策略群組。在代理頁面找到你準備使用的群組名稱，例如訂閱中實際存在的「工作代理」或「自動選擇」。名稱及大小寫必須與 YAML 完全一致；不要照抄範例名稱後就假設設定會生效。
- 確認目前規則的順序。查看設定檔裡是否已有 Zoom、Slack 相關規則，以及一般直連或兜底規則的位置。Clash 通常會依規則順序套用，新增的細部規則應放在會提前攔截它們的廣泛規則之前。
- 先加入最小範圍的測試規則。下列網域僅是格式示意；實際需要的網域應以你自己的連線紀錄、官方文件及目前設定為準。
rules:
- DOMAIN-SUFFIX,zoom.us,工作代理
- DOMAIN-SUFFIX,slack.com,工作代理
- MATCH,原有兜底策略貼上規則後，請確認範例中的「工作代理」確實是你的策略群組，並保留原設定中的兜底規則，不要為了測試把整份規則表替換成這幾行。若你在連線紀錄發現某個必要服務使用其他網域，先記下完整主機名稱與所屬應用，再逐項新增；不要因為網域名稱看起來相似，就把大量第三方或公司網域一概導向代理。對 Slack 的檔案、通知等功能尤其如此：某項功能若仍異常，先從該次操作對應的連線紀錄查起，而不是猜測並堆疊規則。
- 重新載入設定。在用戶端確認設定檔成功更新，並查看是否出現 YAML 格式錯誤或無效策略名稱。若核心拒絕載入，先還原備份，再檢查縮排、逗號與群組名稱。
- 分開測試服務。先打開 Slack，確認訊息收發與檔案操作，再加入一場 Zoom 測試會議，觀察語音、視訊與螢幕分享。每次只改一項條件，才容易判斷改善來自規則、節點還是網路變化。
- 對照連線紀錄。搜尋 Zoom 或 Slack 相關連線，核對命中的規則、策略群組與實際使用的節點。若顯示 DIRECT，代表目前規則沒有命中或被更前面的規則攔截；若已命中代理但仍不穩，則應進一步檢查節點品質、UDP 路徑及本地網路。
測試時可同時記錄日期、使用的 Wi-Fi 或有線網路、節點名稱、會議品質及規則命中狀況。若只有 Slack 檔案上傳慢、訊息本身正常，這與整個應用程式完全連不上是不同問題；若只有 Zoom 分享畫面卡頓，也不代表登入網域需要更多規則。把症狀分開記錄，比同時改全域模式、DNS、TUN 和節點更容易找到真正原因。
會前檢查與故障排除：把問題分成網路、規則與應用程式
重要會議開始前，預留幾分鐘做簡短檢查：確認 Clash 核心正在執行、設定檔沒有更新失敗、策略群組選到預期節點；再確認公司 VPN、Wi-Fi 或乙太網路的狀態與平常一致。接著試開 Slack 並收發一則訊息，再進入 Zoom 測試會議確認麥克風、喇叭、攝影機與畫面分享。這些檢查可以及早發現權限或裝置問題，但不能取代實際會議中的網路品質觀察。
若會議開始後突然中斷，先不要立刻清除設定或連續切換多個模式。可以依序確認：其他網站是否正常、Zoom 或 Slack 的連線是否出現在 Clash 紀錄、相關規則是否命中、切換一個已知穩定的節點後狀況是否改變。若應用程式完全沒有相關紀錄，代表流量可能未進入 Clash；可檢查系統代理是否啟用，以及該應用是否使用自己的網路設定。只有在確認系統代理未涵蓋該流量、且政策允許時，才進一步測試 TUN。
如果所有應用程式都同時變慢，優先檢查家中 Wi-Fi、路由器負載、背景下載與網路服務狀態；若只有 Zoom 媒體品質差，則要把 UDP、節點的即時穩定度與會議服務端狀況列入排查。若 Slack 可以傳文字但檔案載入失敗，查看當時新增的檔案連線與規則命中情形。公司內網或登入頁面出問題時，先確認相關網域是否誤走代理，並依公司 IT 指引處理，不要把登入憑證、訂閱連結或含有內部資訊的連線紀錄貼到公開論壇。
對比把整台電腦長期設為全域代理，或使用無法細分應用流量的簡單代理工具，Clash 的規則模式能讓你依實際連線將辦公服務與一般瀏覽分開處理，連線紀錄也方便定位「規則沒命中」還是「節點品質不佳」。如果你希望在 Windows、macOS 或其他支援平台上管理訂閱、策略與分流規則，可以先查看適用的用戶端，再依公司政策和自身網路環境選擇合適設定。