先釐清目標：讓會議服務走代理，不等於把整台電腦切成全域模式
遠距工作時，最常見的困擾不是「完全沒有網路」，而是 Zoom 音訊偶爾中斷、Slack 訊息延遲，或 Google Meet 開得起來卻在加入會議時卡住。這些現象可能與節點品質、無線網路、公司 VPN、DNS 或應用程式本身有關；Clash 的分流設定能做的是，讓指定服務的連線依照你選擇的策略群組處理，並在連線紀錄裡確認規則有沒有命中。它無法保證特定節點一定適合即時通話，因此仍要實際測試延遲、丟包與音訊狀況。
本文以支援 Mihomo／Clash 規則的用戶端為例，適用於已匯入可用設定檔、知道如何切換代理策略的使用者。核心做法是建立一個專供會議流量使用的策略群組，再把 Zoom、Slack 與 Meet 的相關網域規則排在較寬泛的規則之前。日常瀏覽則維持原設定，例如仍由既有的直連、地區規則或其他策略處理，避免為了修正單一會議問題而改成全域代理。
先分清楚三個層次會比較容易排錯：應用程式產生連線、Clash 核心依規則選擇策略，以及作業系統或 TUN 將流量送進核心。若連線根本沒有進入 Clash，單純新增網域規則不會生效；若連線已出現在紀錄中但套用錯誤策略，才應優先檢查規則順序與匹配範圍。這個區分能避免一直重複貼上規則，卻沒有確認流量實際走向。
準備專用策略群組與規則位置
在修改前，先確認正在編輯並已載入的是哪一份設定。許多訂閱型配置會由遠端設定、覆寫設定或本機設定組合而成；直接修改未生效的 YAML，即使語法正確，執行中的核心也不會採用。若用戶端提供設定檔預覽或覆寫編輯功能，請在儲存後確認核心已重新載入，並保留一份原始設定作為還原點。
接著在既有的 proxy-groups 區段加入會議策略群組。以下片段只示意結構，工作節點必須換成你目前設定中確實存在的節點名稱；如果訂閱中的節點名稱會變動，可改用已存在的代理集合或地區群組。不要把範例原封不動貼進去後，就假設核心已知道如何建立不存在的節點。
proxy-groups:
- name: 會議流量
type: select
proxies:
- 工作節點
- DIRECTselect 群組讓你能在開會前手動選擇出口，也能在特殊情況下切回 DIRECT 進行對照。若希望自動選擇，需依你的核心版本與實際節點設計改用相容的策略類型；自動切換可能會在通話中更換出口，因此不一定適合對連線連續性敏感的會議。測試階段先使用手動選擇，通常較容易分辨是節點問題還是規則問題。
網域規則應放在設定中較寬泛的規則之前，因為 Clash 會依序比對，命中後便使用指定策略。若相關服務已被更早的規則送往其他策略，排在後面的會議規則就不會生效。使用遠端規則集或覆寫功能時，也要確認規則插入位置，而不是只確認文字已經存進檔案。
動手設定：加入 Zoom、Slack 與 Meet 分流規則
以下是便於開始測試的網域範例。服務供應商可能調整網域、呼叫方式或媒體傳輸端點，實際連線也可能因帳號、地區、版本與企業網路政策而不同，因此不要把這份清單視為完整或永久不變的網域清冊。先加入必要項目，再依連線紀錄中實際出現的目的地補充，範圍會比一次把整個大型網域家族送進代理更容易掌控。
rules:
- DOMAIN-SUFFIX,zoom.us,會議流量
- DOMAIN-SUFFIX,zoom.com,會議流量
- DOMAIN-SUFFIX,slack.com,會議流量
- DOMAIN-SUFFIX,slack-edge.com,會議流量
- DOMAIN,meet.google.com,會議流量這些規則以常見服務網域作為起點，不代表 Zoom、Slack 或 Meet 的每一種功能都只會連到列出的主機。Slack 工作區可能使用額外的媒體或檔案端點；Google Meet 也可能依賴其他 Google 服務。若連線紀錄顯示某個必要目的地未命中，先核對該連線是否確實屬於會議功能，再決定要新增精確網域、網域後綴，或改用更合適的既有規則。不要為了讓一次測試通過，就直接把範圍擴大到所有 Google 流量。
套用設定後，在用戶端重新載入設定檔，確認核心沒有回報 YAML 格式錯誤或找不到策略群組。接著選定「會議流量」中的測試節點，先開啟規則模式，再依序啟動 Zoom、Slack 通話與 Meet。若你的使用環境平常使用系統代理，可先用系統代理測試；只有在應用程式沒有把連線送入 Clash、而且你熟悉 TUN 與系統路由影響時，才把 TUN 作為進一步檢查方式。
- 開啟 Clash 的連線或流量紀錄，清除舊紀錄或記下目前時間，方便辨認新連線。
- 啟動一項會議服務，進入會議或測試通話，等待幾十秒，讓登入、訊號與媒體連線有時間建立。
- 在紀錄中搜尋服務網域，確認每筆相關連線使用的規則與策略是否符合預期；不要只看首頁顯示的目前節點。
- 測試完成後，換另一個服務重複檢查，再測試一般網站，確認日常流量仍依原本規則處理。
檢查是否命中，並處理語音與視訊異常
判斷分流是否成功時，請同時查看目的地、匹配規則與最終策略。只看到「會議流量」群組被選取，並不能證明 Zoom 或 Meet 的連線已套用它；反過來說，某個網域出現在紀錄裡，也不保證所有影音資料都經過同一條路徑。登入、訊號交換與媒體傳輸可能是不同連線，測試時應觀察會議期間新出現的多筆紀錄，而不是只憑第一筆請求下結論。
若服務網域出現在紀錄中，但策略仍是 DIRECT 或其他群組，先確認規則是否排在較寬泛規則之前，再檢查規則名稱是否與策略群組名稱完全一致。若完全看不到相關連線，可能是應用程式未使用系統代理、連線走了不同的網路層，或目前測試尚未觸發相關功能。此時可以在同一個網路環境中比較瀏覽器版與桌面版，或短暫啟用 TUN 做診斷；測試完應恢復平常設定，不要把「開 TUN 後能通」直接當成最終配置。
視訊與語音還有一個容易忽略的差異：網域規則主要協助核心依目的地識別連線，但會議媒體可能使用 UDP 或其他即時傳輸方式。若用戶端、核心或目前節點對這類流量的支援有限，即使網域規則命中，畫面仍可能延遲、音訊斷續，或通話退回較慢的傳輸方式。這時請比較同一節點下的直連與代理結果，並查看 Clash 的連線紀錄和應用程式提示；不要在沒有證據時，盲目加入大量 IP 規則或把所有流量改成全域代理。
當只有某一項服務不穩時，逐項變更比一次調整多個設定更有效：先固定節點，確認規則命中；再換一個節點比較；最後才檢查 TUN、DNS 或公司 VPN 等其他因素。會議中途切換節點也可能重建連線，測試最好安排在正式會議之外。若你使用公司管理的電腦或網路，還要遵守組織的代理與 VPN 政策，避免私自改動受管控的網路設定。
讓規則容易維護：記錄測試結果與使用邊界
把會議分流做好之後，建議記下用戶端名稱與版本、核心類型、使用的策略群組、測試日期、服務端點以及結果。這份紀錄不必包含節點密鑰、訂閱網址或帳號資料，只要能說明「哪個服務在什麼條件下命中哪條規則」即可。日後升級用戶端、更新訂閱或服務端調整連線方式時，你就能針對有變化的項目重新測試，而不必從頭重寫整份設定。
規則範圍應採取由窄到寬的原則：先以服務明確使用的網域測試，再依紀錄補充確實需要的目的地。過寬的網域後綴可能把郵件、文件、登入或一般瀏覽一併導向代理，既增加排錯難度，也可能改變原本的資料路徑。若某項服務的流量無法可靠地用網域區分，應先評估目前核心與用戶端支援的其他識別方式，而不是把所有背景連線都當成視訊媒體。
如果你正在比較其他代理工具，部分產品雖能快速開啟全域模式，卻不一定方便檢視每筆連線的命中規則；另一些工具則可能缺少可重用的策略群組，讓 Zoom、Slack 與 Meet 必須分別切換。Clash 的優點在於規則與策略可以明確組合，且能透過連線紀錄逐項驗證；只要先確認流量確實進入核心，再以小範圍規則測試，就能保留日常直連方式，同時更清楚掌握會議流量的去向。若你想依照自己的系統選擇合適用戶端，可前往下載頁查看可用版本。