先分清流量入口與出站策略
遠距工作時，Zoom、Slack 或 Google Meet 開會卡頓，不一定是「節點太慢」，也可能是會議流量根本沒有進入 Clash、UDP 無法透過目前的出口傳送，或規則將工作工具送到不合適的地區。排查時先拆成兩個問題：應用程式的連線有沒有進入核心？進入後又由哪一個策略群組出站？
系統代理只會影響遵循作業系統代理設定的應用程式。瀏覽器和部分桌面程式可能會使用它，但不能假設所有通話媒體流量都會跟著走；有些應用程式使用自己的網路堆疊，視訊與音訊也可能透過 UDP 傳送。TUN 透過虛擬網卡與路由接管符合條件的 IP 流量，適合用來檢查未遵循系統代理的連線，但仍須確認核心、作業系統權限、路由及節點的 UDP 支援。
本文建議保留規則模式：工作服務明確交給一個代理群組，本地網站、印表機與公司內網則保留直連。全域模式會改變已接管連線的整體出站決策，並不是視訊最佳化開關；為了改善單一會議而長期全域代理，反而可能讓內部服務繞遠路。
| 症狀或需求 | 先檢查什麼 | 建議處理方向 |
|---|---|---|
| 網頁可開，通話無聲或畫面停格 | UDP 是否進入核心；節點是否支援 UDP | 查看連線記錄，必要時測試 TUN 與另一個支援 UDP 的節點 |
| 加入會議很慢或頻繁重新連線 | 工作服務命中的規則、代理群組選擇及節點延遲 | 將工作工具分到較穩定且適合服務區域的策略 |
| 公司入口網站或區域網路設備無法使用 | 內網網域、私有 IP 是否被代理 | 將確認過的內網網域與網段放在工作服務規則之前並設為直連 |
用窄範圍網域規則分流工作服務
Zoom、Slack 與 Google Meet 會使用多個網域提供登入、訊息、檔案、會議控制和媒體服務，實際端點也可能隨用戶端版本、帳戶類型和服務區域改變。只靠一份固定網域清單，不能保證涵蓋所有連線。可先從常見服務網域建立有限範圍的規則，再依 Clash 的連線記錄補充實際命中的主機名稱；不要因為一個登入頁面使用某個網域，就把整個大型平台的所有流量一併代理。
以下是 mihomo 規則寫法示意，假設現有設定已定義「工作代理」群組。它不是完整設定檔，也不包含節點或 DNS 設定。請將規則放在較寬泛的工作、國別或兜底規則之前；若設定已有 MATCH，新增項目必須放在它前面。群組名稱需與 proxy-groups 中的名稱完全相同。
mode: rule
rules:
- DOMAIN,meet.google.com,工作代理
- DOMAIN-SUFFIX,zoom.us,工作代理
- DOMAIN-SUFFIX,zoom.com,工作代理
- DOMAIN-SUFFIX,slack.com,工作代理
- DOMAIN-SUFFIX,slack-edge.com,工作代理
- DOMAIN,公司入口.example,DIRECT範例中的公司入口網域只是佔位文字，請替換為組織實際使用的網域，不要原樣貼入設定。若某個服務需要的連線在記錄中顯示為其他主機，先確認它確實屬於該服務，再新增精確的 DOMAIN 或範圍適當的 DOMAIN-SUFFIX 規則。規則只依據核心取得的網域或 IP 等連線資訊比對，並不會辨識「這是 Zoom 應用程式」或「這是一次視訊通話」。
- 先用精確規則：只需處理單一主機時使用
DOMAIN，可避免把不相關的子網域一併納入。 - 確認策略群組存在：規則右側的策略名稱必須與目前設定完全一致；名稱不符會造成設定驗證錯誤或無法依預期選擇出站。
- 保留內網直連：若現有設定已有私有 IP、區域網路及公司網域規則，先確認順序，不要為了加入工作服務而刪除它們。
- 避免過度擴大網域：把整個大型雲端或搜尋服務網域都改走代理，可能增加不必要的流量，也會讓工作與一般瀏覽難以分開排查。
動手設定：新增規則並逐步驗證
建議一次只改一組規則，先測試一項服務，再加入其他工作工具。這樣能辨認問題是規則沒有命中、群組選錯，還是連線入口或節點本身不適合。不同版本的 Clash Verge、Clash Verge Rev 與其他圖形介面入口名稱可能不同；請找設定檔覆寫、規則或連線記錄等相應功能，不要假設所有用戶端的選單完全相同。
- 備份並確認模式：匯出或複製目前設定，確認目前使用的核心與設定檔，並將出站模式設為規則模式。確認「工作代理」群組確實存在，且已選取可用節點或策略。
- 加入一條測試規則：先選一個需要測試的服務，新增一條精確網域規則，放在兜底規則之前。使用圖形介面編輯時，也要檢查修改後的最終 YAML 是否保留原有規則。
- 重新建立連線：完全退出並重新開啟應用程式，或離開後重新加入會議。既有連線可能仍沿用修改前的路徑，單看舊連線記錄不一定能證明新規則已生效。
- 查看連線記錄：在用戶端的連線頁面搜尋服務網域，檢查命中的規則、出站策略及連線是否成功。若只看到 IP，核心可能沒有可用的網域資訊；可再檢查 DNS 接管、TUN 與應用程式是否使用自訂 DNS。
- 測試音訊與視訊：進入測試會議或短暫通話，分別確認加入速度、雙向音訊、畫面穩定度和螢幕分享。再用同一網路與相同會議條件比較另一個節點，避免同時更改多個變數。
- 補充其他網域或回復：確認記錄中的其他主機確實與服務相關後才新增規則。若設定驗證失敗或本地服務受影響，先回復備份，再重新檢查規則縮排、策略名稱與排序。
如果規則記錄顯示工作流量已送往預期群組，但視訊仍不穩，應改查節點和傳輸能力，不要繼續盲目增加網域。某些服務會讓控制訊號與媒體流量走不同連線；只看到登入或聊天連線命中代理，不足以證明音訊、視訊也走同一路徑。
UDP、節點與 DNS：視訊連線的關鍵檢查
視訊會議常使用即時媒體傳輸，連線可能包含 UDP；部分情況也會使用 TCP 或 HTTPS 作為替代路徑。不同服務、平台與網路環境的連接埠及端點可能不同，服務供應商也會更新需求。若要檢查防火牆或企業網路限制，請以服務供應商當前的網路需求文件為準，不要把某一組連接埠當成所有用戶端都固定使用的規則。
一般系統 HTTP 代理不會自動接管任意 UDP 流量。若連線記錄中有 TCP 控制連線，卻找不到預期的媒體連線，請確認應用程式是否遵循系統代理，以及目前是否需要透過 TUN 接管。使用 TUN 時，除了確認核心的虛擬網卡與路由已生效，也要確認選中的節點及其傳輸方式能承載所需 UDP；TUN 已開啟不代表所有節點都支援 UDP。
| 觀察結果 | 可能原因 | 下一步檢查 |
|---|---|---|
| 網頁與聊天正常，通話媒體不穩 | 媒體連線未進入核心，或 UDP 出站不受支援 | 檢查 TUN、連線記錄與節點 UDP 能力，並以另一個節點交叉測試 |
| 代理記錄中看不到服務網域 | 連線只提供 IP，或 DNS 查詢與連線未走同一解析路徑 | 檢查核心 DNS、應用程式自訂 DNS 與 TUN 接管情況 |
| 使用代理後延遲反而增加 | 節點所在地、路由或目前負載不適合會議服務 | 比較不同候選節點的實際通話穩定度，不只比較延遲測試數字 |
| 本地網站或公司服務變慢 | 範圍過大的代理規則排在直連例外之前 | 將已確認的內網與本地直連規則前移，再檢查命中記錄 |
節點選擇可先排除連線失敗、丟包明顯或頻繁切換的節點，再比較會議實測。節點地理位置較近不必然代表路徑較好，還要考慮服務端接入區域、網際網路路由和高峰時段負載。工作期間需要穩定時，宜選擇可預期的固定策略；自動切換或延遲測試群組雖方便，但若節點頻繁改變，也可能讓既有會議連線中斷。
保留本地直連並建立安全的回復方式
分流規則不應只列出要代理的服務，也要保留辦公環境需要的直連條件。公司內部入口、檔案伺服器、印表機、路由器管理頁面及本地開發服務，可能使用私有 IP 或組織自訂網域。若工作設備依賴 VPN、裝置管理或內部 DNS，請遵循組織的網路政策；不要為了改善會議品質而移除企業設定或繞過存取控制。
完成設定後，記錄核心名稱與版本、使用的策略群組、變更過的規則，以及測試時的節點。若升級核心或更新訂閱後行為改變，可先載入備份確認是否與新版本或新訂閱有關，再逐項套回修改。排查期間不建議同時開啟多個代理用戶端或 VPN，避免系統代理、DNS 與虛擬路由彼此競爭。
- 本地網站仍可直連，且公司內網服務能正常解析與連線。
- Zoom、Slack 或 Google Meet 的連線記錄顯示預期規則與策略，而不只是瀏覽器首頁走了代理。
- 實際會議中雙向音訊、視訊與分享功能穩定，且節點沒有頻繁切換。
- 測試結束後恢復原本不需要的 TUN 或系統代理設定，並確認沒有留下過時的手動代理。