前言：讓視訊會議走對網路路徑
居家工作時，視訊會議卡頓不一定是頻寬不足。Wi-Fi 訊號、尖峰時段的國際出口、DNS 解析結果，以及 Clash 規則是否命中，都可能影響 Zoom、Google Meet 或 Slack 的連線品質。若把所有流量一律送進同一個代理節點，可能讓原本能直連的服務繞遠路；反過來，若會議流量意外直連，也可能遇到連線不穩或服務無法正常載入。
比較實用的做法，是先為工作工具建立明確的分流策略，再根據實際網路狀況測試直連與代理。不同地區、網路供應商及服務端點的狀況並不相同，因此「全部直連」或「全部代理」都不是通用答案。本文以 Mihomo 核心常見的 YAML 規則為例，說明如何安排 Zoom、Google Meet 和 Slack 的策略組、規則順序與測試流程；Clash Verge、Clash Verge Rev 等用戶可依客戶端介面調整，其他使用不同核心的客戶端則應先確認規則語法相容性。
設定目標
讓本地網站維持直連，會議服務則依所在地網路品質選擇 DIRECT 或穩定代理；降低音訊中斷、畫面凍結與 Slack 長連線反覆重連的機率。
1先規劃分流策略與規則順序
Clash 會依序比對 rules，遇到第一條符合的規則就採用其策略。因此，工作工具的專屬規則應放在較寬泛的規則之前，並且放在最終兜底規則之前。若它們排在一般的 Google、國際網站或代理規則之後，專屬策略可能根本不會被執行。修改前先複製一份設定檔或使用客戶端的設定檔複製功能，方便遇到問題時立即還原。
建議先在客戶端的策略頁面確認現有策略組名稱，再決定使用哪種安排。若訂閱已經提供「自動選擇」「手動選擇」或地區策略組，直接沿用通常比自行重建整套節點清單簡單。以下規則中的 工作會議 是示範用的策略組名稱，請換成設定檔中實際存在的名稱；若目前沒有這個組別，可先將規則目標改成已存在且經過測試的組別。
小撇步
先以較少的規則驗證效果，再逐步補齊域名。不要一次加入涵蓋範圍很廣的關鍵字規則，否則可能把不相關的網站或應用程式也導向同一條路徑。
選擇 DIRECT 或代理策略
如果本地網路直連會議服務時延遲較低、丟包少，可將該服務指向 DIRECT；若直連連線不穩或服務端點無法正常連線，則可指向穩定的代理策略組。此處的代理組應優先選擇單一、固定地區的低延遲節點，而不是會在會議進行中頻繁切換的負載均衡策略。更換節點可能導致長連線中斷，參與者需要重新連線，或短時間內出現音訊和畫面停頓。
規則目標並不會自動替你建立策略組。若示範的 工作會議 未在設定中定義，Clash 可能提示策略不存在或規則載入失敗。請先確認策略組名稱完全一致，包括大小寫、空格與中文字，再重新載入設定。
2為 Zoom、Google Meet 與 Slack 加入規則
域名規則可協助把服務的連線導向指定策略，但不能保證涵蓋每一個服務端點，也不代表能單靠域名規則修復所有網路問題。以下提供保守的起點：先使用服務主要域名後綴，觀察 Clash 連線記錄中的實際命中結果；若某項功能仍未走到預期策略，再根據記錄補充規則。不要在尚未確認影響範圍前，直接把整個 Google 或 Microsoft 等大型服務網域都指定為代理。
將下列規則放在 rules: 清單中較前的位置，並把 工作會議 換成已存在的策略組名稱。範例以代理策略組為目的；若你已測得直連更穩，可將相應行的目標改為 DIRECT。
Zoom 可能使用不同主機名稱提供登入、會議連線與網頁資源；Google Meet 的媒體連線也會受網路環境和瀏覽器影響；Slack 則包含工作區、訊息及檔案等不同連線。上面的規則是便於開始測試的基本清單，不是服務供應商公布的完整域名清冊。尤其不要只憑一次連線失敗，就任意加入 DOMAIN-KEYWORD,google 這類寬泛規則，因為它可能改變大量 Google 服務的路徑。
如果使用規則集或訂閱自動更新設定，確認自訂規則位於適當位置，並避免與遠端規則集的目標策略互相覆蓋。遇到設定檔顯示語法錯誤時，先檢查縮排、逗號、冒號及策略名稱，再查看客戶端的核心日誌。YAML 通常使用空格縮排，不要用 Tab；也不要把範例中僅供說明的註解或佔位名稱誤當成已經存在的策略。
3節點挑選、DNS 與會議實測
選節點時不要只看測速網站上的下載速度。即時會議更在意延遲、抖動與丟包；一條下載速度很高、但延遲忽高忽低的線路，仍可能造成發言延遲或畫面不連續。可先挑選地理位置相近、回應穩定的節點，分別在相同時段測試 DIRECT 與代理策略。測試時記錄連線延遲、是否出現丟包、語音是否連續，以及切換策略後是否需要重新加入會議。
按順序確認每一層設定
- 更新或重新載入設定檔，確認客戶端沒有顯示 YAML 解析錯誤，且工作會議策略組確實存在。
- 在 Clash 的連線或日誌頁面啟動一場測試會議，查看 Zoom、Meet 或 Slack 的連線是否命中預期規則與策略。
- 在相同裝置與相近時段比較直連和代理，不要同時更改節點、DNS 與規則，否則難以判斷是哪項調整造成差異。
- 確認瀏覽器或桌面應用程式的系統代理、TUN 模式及權限狀態。部分應用程式可能不完全遵循系統代理設定，必要時再檢查 TUN 是否正常接管流量。
- 測試會議穩定後再開啟螢幕分享、攝影機與雲端錄影等實際工作情境，觀察數分鐘而非只看能否連上會議。
DNS 設定不宜只因「開啟代理」就全部改成某一種模式。DNS 解析錯誤或快取過期，可能導致域名規則與實際連線狀況不一致；但盲目啟用新的 DNS 或覆寫現有設定，也可能讓本地服務解析變慢。先確認問題是否只發生在某個服務，再依目前核心支援的 DNS 設定調整。修改後重新載入配置，必要時重新啟動應用程式，並以連線記錄確認新設定確實生效。
避免在會議中切換節點
節點或出口 IP 改變時，既有的視訊與訊息長連線可能中斷。請在會議開始前完成測試；若必須更換策略，先通知與會者並預留重新連線時間。
4融入日常遠距工作流程
設定完成後，建議把「工作會議」策略組固定在經過測試的線路，並保留可手動選擇的備用節點。平常可讓本地網站和常用本地服務依既有規則直連，只有確認需要時才把 Zoom、Google Meet 或 Slack 指向代理。這樣能避免不必要的繞行，也方便出現問題時快速判斷是單一服務、特定節點，還是整體網路造成的影響。
可以建立簡單的變更紀錄，例如記下日期、使用的網路、策略選擇與測試結果。若某條線路只在晚間變得不穩，先換用已驗證的備用節點，並於會議後再調整規則；若只有 Slack 檔案載入慢、訊息卻正常，則可在連線記錄中確認檔案域名是否命中預期策略。比起不斷增加規則，根據實際連線逐項排查更容易找到原因。
Clash 負責依照設定轉送流量，並不能保證服務端狀態、家庭 Wi-Fi 或網路供應商線路永遠穩定。若所有策略下都出現卡頓，可先檢查路由器訊號、其他裝置是否大量占用頻寬，以及應用程式和作業系統是否有更新。若問題只在使用代理時出現，回到直連測試並檢查節點品質；若只有某項服務異常，則從該服務的域名命中記錄開始查起。
最後，請只使用你信任的代理服務與設定檔，避免分享含有訂閱連結、帳號憑證或內網資訊的配置檔。規則調整應以穩定、可回復及符合服務所在地區政策為原則。做好備份、先測試再投入正式會議，便能讓分流設定更可靠地融入每天的遠距工作流程。