遠距會議的連線品質不只取決於 Shadowrocket 是否顯示已連線；辦公室網路、Wi-Fi 或行動網路、代理路徑與視訊媒體傳輸都可能影響 Zoom、Teams。本文以「會議流量先直連、需要時再為指定資料搜尋網站加上代理規則」為例，說明如何使用 Config 分流、檢查規則命中情形，並依封包與網路表現逐項排查。網域範例僅供說明，實際規則應以你使用的服務和組織政策為準。
一、先釐清：會議順暢不等於所有流量走代理
Zoom 或 Teams 的會議連線可能包含登入與會議控制、音訊與視訊媒體，以及螢幕分享等不同請求。它們不一定使用同一個網域或相同的傳輸方式；實際路徑也可能受公司網路政策、DNS、裝置設定和服務端選擇影響。因此，把所有 Microsoft 或 Zoom 相關網域一概設為代理，未必能改善視訊品質，還可能增加延遲或讓登入、會議控制與媒體流量走上不同路徑。
建議先把「辦公 App 能否正常登入與參加會議」和「瀏覽資料搜尋網站是否需要代理」分開處理。若目前網路允許直接連線，讓會議流量維持 DIRECT 通常較容易判斷問題；資料搜尋則可針對實際需要的網域設定 PROXY。若公司要求特定流量必須使用指定網路路徑，應以組織政策和 IT 管理者提供的設定為優先，不要自行建立可能違反政策的例外。
不要用單次 Speed Test 的數字推斷某個代理一定適合視訊。開會品質還與上行頻寬、Wi-Fi 干擾、丟包、抖動和裝置負載有關。若會議只在特定網路出問題，請先記下網路類型、問題發生時間和會議功能，再比較同一台裝置在 Wi-Fi 與行動網路上的表現。
二、以 Config 讓會議流量直連、搜尋網域按需代理
Shadowrocket 的規則依設定檔內容和順序匹配。若要為特定網域指定策略，須先確認目前使用的設定檔確實包含這些規則，並讓 Home → Global Routing 使用 Config。選擇 Proxy 或 Direct 時，流量會按該模式處理，不會得到本文所說的網域分流效果。
以下片段是規則格式示意，不是完整設定檔，也不是官方列出的 Zoom 或 Teams 全部網域。example.com 是文件示範網域，應替換為你確認過、確實需要代理的資料搜尋網域。Zoom、Teams 的服務網域與連線需求可能隨功能、地區或組織部署而異；不要看到一個產品網域就推論所有會議流量都由它承載。
[Rule]
DOMAIN-SUFFIX,zoom.us,DIRECT
DOMAIN-SUFFIX,teams.microsoft.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIX,zoom.us,DIRECT會比對zoom.us本身及其子網域；這只是示範，不代表所有 Zoom 會議流量一定只用這個網域。DOMAIN-SUFFIX,teams.microsoft.com,DIRECT是限定範圍的例子，不等於涵蓋 Teams 依賴的全部網域。避免直接把範圍很廣的microsoft.com設為 DIRECT，因為可能一併改變其他 Microsoft 服務的路由。example.com請替換成你實際需要透過代理存取的資料搜尋網站網域；不要把完整網址、路徑或連接埠貼進網域欄位。FINAL,DIRECT是前面規則都未命中時的兜底。若你的設定檔已有更早匹配的規則，請先檢查其順序和策略。
三、實際操作：備份設定檔、調整規則並確認命中
開始前請確認 Shadowrocket 中已有你自己的可用連線設定，並知道目前使用哪一份 Config。訂閱和規則是不同內容：既有訂閱請向你的服務商取得；本文只處理本機的流量分流方式，不提供或推薦任何節點或訂閱。若設定檔是遠端更新的，先確認本機修改是否可能在下一次更新時被覆寫。
-
確認目前設定檔
前往 Config，辨認目前使用中的檔案，先匯出或保留備份。若有多份設定檔，請記下名稱，避免修改了未啟用的檔案，卻在會議時以為規則已生效。
-
整理規則順序
在有效設定檔的
[Rule]段落中，先檢查是否已有涵蓋 Zoom、Teams 或搜尋網站的規則。將已確認的較具體網域規則放在可能涵蓋範圍較廣的規則之前，並確認每行使用英文逗號和正確策略名稱。 -
選擇 Config
返回 Home → Global Routing，選擇 Config。確認 Home 顯示的連線項目是你要測試的設定；只修改規則但仍停在 Proxy 或 Direct，不能驗證網域規則。
-
先做短測試
儲存設定後重新連線，先開啟 Zoom 或 Teams，確認登入、加入會議與基本音訊是否正常。再開啟一個你已設定為 PROXY 的搜尋網域，檢查是否能按預期存取；不要同時更改多條規則或其他連線參數。
-
核對請求記錄
查看 Shadowrocket 的請求記錄，對照請求網域、命中的規則與實際策略。若記錄中沒有預期網域，可能是目前功能使用了其他網域，或請求尚未重新產生；關閉並重新開啟 App 或重新加入測試會議，再查看新記錄。
一次只調整一個變因：先確認規則確實命中，再測試會議；接著才比較 Wi-Fi 與行動網路，最後再依服務商提供的資料確認連線參數。這樣較容易區分是網域分流、網路品質，還是代理連線本身造成影響。
四、UDP、連接埠與網路品質：不要只盯著 443
登入頁面或一般網頁常見 HTTPS 連線，但視訊會議的音訊、視訊和螢幕分享可能需要不同的媒體傳輸條件。媒體可能使用 UDP，也可能在 UDP 不可用時改用其他傳輸方式；具體連接埠和回退行為須依 Zoom、Teams 的當前文件、組織網路政策及實際請求記錄確認。不能因為 TCP 443 可以開啟，就推定會議媒體也已具備理想的連線條件。
先看會議端
- 登入正常
- 確認帳戶驗證與會議控制流程
- 媒體表現
- 觀察音訊、視訊、分享是否分別異常
- 規則結果
- 在請求記錄核對網域與 DIRECT / PROXY
- 連線協定
- UDP 條件依服務文件與管理政策確認
網頁能開啟不代表音訊、視訊與分享都走同一條連線。
再看使用網路
- Wi-Fi
- 檢查訊號、擁塞與路由器限制
- 行動網路
- 比較同地點的會議表現與訊號變化
- 上行品質
- 留意上傳頻寬、丟包與抖動
- 政策限制
- 公司網路依 IT 指示設定例外
先用相同裝置、相同會議情境比較網路，再決定是否調整規則。
如果只有畫面凍結或聲音斷續，先觀察視訊 App 自身提供的網路狀態資訊，並確認同一時段其他裝置是否也受影響。若其他裝置正常，檢查目前裝置的 Wi-Fi 訊號、背景上傳工作與 Shadowrocket 規則；若多台裝置同時出現問題，則更可能需要檢查路由器、網路供應或公司網路策略。這些線索只能協助縮小範圍，不能單獨證明根因。
遇到公司網路封鎖 UDP 或限制特定媒體連線時，不要自行猜測連接埠範圍並建立大量例外。請向 IT 管理者確認受管理網路允許的服務與傳輸條件，再按實際政策測試。用戶端的分流規則無法取代網路端的允許清單或防火牆設定。
五、Wi-Fi 與行動網路分開測試，避免一次改太多
可用相同裝置、相同帳戶和相近會議情境做兩輪測試：第一輪使用常用 Wi-Fi，第二輪切換至行動網路。每輪記下加入會議所需時間、音訊是否中斷、視訊是否降級、螢幕分享是否正常，以及請求記錄中相關網域的策略。記錄時間與網路類型，會比只留下「今天很卡」更能幫助後續排查。
- 先在目前 Wi-Fi 下，以 Config 模式確認會議服務的規則命中情形；測試期間不要切換 Global Routing。
- 結束測試會議後切換至行動網路，以相同會議功能重新測試。若行動網路表現改善，先檢查 Wi-Fi 或路由器條件，不要立刻擴大代理規則。
- 若兩種網路都只有特定功能異常，檢查會議 App 的狀態資訊、請求記錄與管理政策；必要時向組織 IT 支援提供發生時間和錯誤現象。
- 每次只改一條已確認相關的網域規則。修改後重新產生請求，確認記錄顯示預期的策略，再測試會議功能是否有可重複的變化。
Teams 登入正常，但會議聲音一直斷?
先分別測試 Wi-Fi 與行動網路，並查看會議 App 的網路狀態。再檢查請求記錄和公司網路是否允許所需媒體傳輸；不要只因登入頁正常，就認定會議媒體連線也正常。
加了 DIRECT 規則，為什麼看不出差別?
確認 Home → Global Routing 是否選 Config、修改的檔案是否為目前使用的設定檔，並在新請求的記錄中核對網域和命中策略。已有較早的廣泛規則時，需先檢查規則順序。
搜尋網站能開，但會議還是卡?
搜尋網站和視訊媒體可能走不同網域、傳輸條件與網路路徑。分開檢查音訊、視訊和分享功能，再比較不同網路；不要把搜尋網站成功當成會議品質正常的證據。
六、讓設定可回復，並保留明確的排查順序
遠距會議前避免臨時大量修改設定。建議保留一份可還原的 Config，修改時記下新增或調整的規則、測試網路和結果。如果調整後會議表現變差，可先還原最近一次變更，再重新確認 Global Routing 與請求記錄；不要同時修改代理參數、DNS、規則和系統網路，否則難以判斷哪項改動造成結果變化。
常用的檢查順序是：確認使用中的設定檔 → 確認 Home → Global Routing 為 Config → 確認相關請求的網域和命中策略 → 比較 Wi-Fi 與行動網路 → 依組織政策核對 UDP 和防火牆條件。若問題只發生在某個會議室、公司網路或特定帳戶，請一併記錄這些條件，提供給管理者或服務支援協助判斷。