遠距工作用 Clash 分流，先把「會議」和「一般瀏覽」分開
使用 Zoom、Google Meet 與 Slack進行遠距協作時，最常見的困擾不是完全連不上，而是會議開始後聲音斷續、畫面延遲，或 Slack 訊息明明送出卻過一陣子才同步。這些狀況不一定都由代理節點造成，Wi-Fi 訊號、公司 VPN、視訊平台負載和出口路由都可能影響體驗；不過，如果會議流量被送到高延遲或不穩定的節點，或者一般網站也被不必要地繞遠路，確實會增加排查難度。
比較容易維護的做法，是讓 Clash 依目的地規則決定流量去向：會議與協作服務走一個可切換、經過實測的策略群組；不需要代理的一般網站維持直連；其他未列入規則的流量則交由原有規則處理。這並不代表所有人的視訊服務都應該代理。若所在地網路直連服務穩定，直連可能延遲更低；若直連連線受限或品質不佳，才透過節點比較效果。重點是建立可驗證的選擇，而不是把所有流量一律送往同一出口。
本文以 Clash Verge Rev 等圖形用戶端的操作概念說明，實際選單名稱會因版本、作業系統與核心不同而略有差異。設定前先確認目前載入的是哪份設定檔、規則模式已啟用，並確保你有權在公司或學校網路上使用代理工具。公司管理的裝置或網路若有明確政策，應先向管理員確認。
視訊會議流量有哪些特性：網域規則不是完整的網路地圖
Zoom、Meet 和 Slack 並非只連到一個固定網域。登入、訊息同步、會議控制、音訊與視訊媒體可能使用不同的服務端點；有些媒體連線還會採用 UDP，或依網路情況改走其他傳輸方式。因此，從搜尋結果複製一串網域清單，不保證能涵蓋每個帳號、版本與地區的連線；反過來說，把整個 Google 或 Microsoft 相關網域都送代理，也可能讓原本直連的服務一起改道。
Clash 規則常以網域、IP 位址或既有規則集匹配流量。當用戶端已取得可辨識的目的網域時，網域規則通常較容易閱讀與維護；但若連線紀錄只顯示 IP、或應用程式的媒體流量沒有經過系統 Proxy，單靠新增網域規則未必能改變它的路徑。此時應先判斷流量是否進入 Clash，再查策略命中結果，而不是不斷擴大網域範圍。
| 服務或流量 | 常見用途 | 設定時要留意 |
|---|---|---|
| Zoom | 登入、會議控制、音訊與視訊連線 | 網域與媒體連線可能分開；留意即時連線紀錄，不要只用登入頁測試。 |
| Google Meet | Google 帳號驗證、會議控制及即時媒體 | 相關服務可能共用 Google 網域或基礎設施；避免未經測試就代理過大的網域範圍。 |
| Slack | 工作區登入、訊息、檔案與通話功能 | 訊息正常不代表通話媒體也走相同路徑；以實際通話期間的紀錄為準。 |
| 一般網站 | 搜尋、新聞、常用本地服務及公司內部資源 | 可依現有規則維持直連；公司內網網域應遵循組織設定，不要任意改道。 |
如果你只在會議中遇到卡頓，先記下會議開始時間、所用網路、選取的節點，以及連線紀錄裡目的地和策略名稱。這些資訊比「某個網站打不開」更能協助判斷問題是在網路、規則匹配，還是媒體傳輸路徑。測試時盡量一次只改一項設定，避免同時換節點、切模式、重啟 VPN，最後無法知道是哪個變更真正有用。
先選合適的代理模式：系統 Proxy、TUN 與直連各有用途
圖形用戶端的系統 Proxy 通常適合先做基本測試：支援作業系統代理設定的瀏覽器與應用程式，會把 HTTP 或 HTTPS 請求送到 Clash，再由規則選擇直連或代理。這種方式較容易觀察，也不必一開始就接管整台電腦的所有網路連線。但它不會自動涵蓋每一種應用程式流量，特別是部分 UDP 媒體連線或不讀取系統 Proxy 設定的程式。
TUN 模式會在更底層攔截或導入網路流量，可能讓更多不理會系統 Proxy 的連線進入 Clash 規則判斷。它適合用來驗證某個程式是否繞過系統代理，或在必要時涵蓋更多流量；但也可能與公司 VPN、端點防護、虛擬網路介面或其他代理工具互相影響。若公司裝置有受管理的路由或 VPN，先確認政策，不要為了測試而停用安全軟體或改寫受管理設定。
| 方式 | 適合情境 | 可能的限制 |
|---|---|---|
| 系統 Proxy＋規則模式 | 先測試瀏覽器或支援系統 Proxy 的桌面應用程式 | 某些程式或媒體流量可能不讀取系統代理設定。 |
| TUN＋規則模式 | 需要確認更多系統連線是否進入 Clash，或涵蓋未使用系統 Proxy 的流量 | 可能與其他 VPN、路由或安全工具衝突；應逐項測試。 |
| 直連 | 所在地網路連線穩定，且服務可正常使用 | 若直連路徑不穩，會議品質可能受網路環境影響。 |
建議的排查順序是先以規則模式和系統 Proxy 建立基準，確認連線清單是否出現相關請求；若紀錄完全沒有會議流量，再評估是否需要 TUN。啟用 TUN 後若公司內網或其他 VPN 異常，應先關閉並恢復原狀，再尋求管理員協助。不要把「TUN 開啟後看起來有變化」直接當成設定正確，仍要用實際通話與連線紀錄驗證。
建立會議策略群組與分流規則
在 Clash Verge Rev 或其他 Mihomo 圖形介面中，先找到目前生效的設定檔和代理群組。若訂閱設定檔不適合直接編輯，使用用戶端支援的覆寫、合併或自訂規則功能，並依該用戶端文件確認設定如何持續保留。直接修改會被訂閱更新覆蓋的原始檔，常會造成「剛剛有效、更新後又消失」的情況。
策略群組可以將候選節點集中管理，例如建立名為「會議」的選擇群組，讓使用者在測試後手動選擇節點；也可以依用戶端能力設定延遲測試或故障切換。會議期間不宜只看一次測速數字：節點的網頁載入速度很好，不代表長時間語音與視訊連線就一定穩定。應觀察延遲波動、封包遺失、會議是否中斷，以及切換節點後能否恢復。
以下是規則排列的概念示例，實際網域應以你自己的連線紀錄、服務文件和設定檔語法為準。示例中的策略群組名稱必須與設定檔中實際存在的名稱一致；若不存在，核心可能無法載入規則。
rules:
- DOMAIN-SUFFIX,zoom.us,會議
- DOMAIN-SUFFIX,zoom.com,會議
- DOMAIN-SUFFIX,slack.com,會議
- MATCH,原有預設策略這段範例只呈現「特定服務規則放在較廣泛預設規則之前」的排列方向，不是完整網域清單，也不保證能涵蓋 Meet 或每種媒體連線。Meet 相關流量可能與其他 Google 服務共用基礎設施，若只因為 Meet 卡頓就把所有 Google 網域代理，可能連帶改變 Gmail、雲端硬碟或公司所需服務的路徑。先在連線紀錄中確認目的地，再決定是否新增更精確的網域或 IP 規則。
規則順序尤其重要。若較前面的廣泛規則已經把一類網域送往直連或其他策略，後面新增的會議規則可能永遠不會命中。調整後重新載入設定檔，檢查核心是否回報語法錯誤，再實際開啟服務測試。若你使用規則集，需確認自訂規則和規則集的先後關係；不要只看到 YAML 裡有某一行，就假設它已經生效。
用連線紀錄與延遲測試找出真正的瓶頸
完成基本分流後，先不要立刻把會議策略群組設成自動選擇。選兩到三個可用節點，於相同的網路與相近時段進行短時間對照：先直連，再測節點 A、節點 B；每次只改出口，並記錄進入會議、開啟攝影機、播放分享畫面和通話數分鐘後的狀況。延遲測試可用來排除明顯不合適的節點，但它只是參考值，不能代替真實會議測試。
- 確認流量有進 Clash：開啟 Zoom、Meet 或 Slack 的相關功能，查看連線紀錄是否出現新的請求。如果沒有，先檢查系統 Proxy 是否生效、應用程式是否使用其他網路介面；需要時再評估 TUN。
- 確認規則命中：檢查連線的目的地、匹配規則與策略群組。若顯示 DIRECT，確認網域是否被正確辨識，以及前方是否有更早命中的規則。
- 比較節點與直連：以相同裝置、同一 Wi-Fi 和相近時間測試，記錄會議品質，而不只比較測速網站的結果。
- 觀察長連線：至少維持一段實際通話，留意語音斷續、畫面凍結、重新連線或共享畫面延遲。剛連上時正常，不代表長連線穩定。
- 一次修改一項：每次只改策略、節點或代理模式其中一項，並在確認結果後再進行下一步。
若 Zoom 或 Meet 只有畫面分享正常、音訊或視訊不穩，應特別留意媒體流量是否使用不同傳輸方式；只看網頁登入頁或聊天訊息正常，不能證明整場會議都走了預期出口。若連線紀錄顯示策略正確，但通話品質仍差，可比較直連與不同節點，並檢查 Wi-Fi 訊號、路由器負載、公司 VPN 和背景下載。若所有路徑都不理想，問題可能不在 Clash 規則本身。
會議中途通常不適合頻繁切換節點。部分即時連線在出口變更後需要重新建立，短暫中斷反而會比原有延遲更影響討論。可以在會議前先測試並固定當次使用的策略；只有在連線明顯惡化、且你確認切換不會違反組織政策時，才切換到已測試的備用節點。若策略群組提供延遲測試，注意測試結果和實際連線品質可能不同，不要只依排名選擇。
常見問題
Zoom、Meet 和 Slack 一定要走代理嗎？
不一定。若直連時服務可正常使用，而且延遲與穩定性較好，直連可能更合適；若特定網路環境下連線不穩，則可透過策略群組比較節點。請以所在地網路、公司政策與實際測試結果為準，不要把「代理」視為所有會議問題的通用解法。
為什麼只新增一條 Google 網域規則，Meet 還是卡？
Meet 的登入、控制與媒體連線不一定使用同一個目的地，媒體流量也可能沒有經過系統 Proxy。先在實際會議期間檢查連線紀錄，確認請求是否進入 Clash、使用什麼策略，再依可靠資料補充規則。避免直接代理過大的 Google 網域範圍，以免影響其他服務。
開啟 TUN 就能解決所有視訊問題嗎？
不能。TUN 可能讓更多流量進入 Clash，但不會自動改善節點品質、Wi-Fi 訊號或服務端負載，也可能與公司 VPN 或安全工具衝突。應先用連線紀錄確認問題是否出在流量沒有進入 Clash，再決定是否測試 TUN。
為什麼延遲測試很低，實際會議仍然不順？
延遲測試通常只反映特定測試目的地和當下狀態，不能完整代表即時音訊、視訊長連線或 UDP 媒體流量的品質。請以實際會議觀察為主，並將測試時間、網路、節點及連線紀錄一併記下。
有些做法看似省事，例如全程開全域代理或臨時換一個測速最快的節點，卻容易讓公司內網、一般網站和會議流量一起改道，也不容易重現問題；部分只提供簡單開關的工具，則可能缺少清楚的規則命中與連線紀錄，排查時只能反覆猜測。Clash 的價值在於能用策略群組、規則排序和即時連線資訊分別測試 Zoom、Meet、Slack 與一般流量，讓你按實際網路選擇直連或節點，而不是一次改動整台裝置的所有連線。如果你想依自己的系統建立這套分流流程，可以先查看可用用戶端與平台資訊。