遠距工作時，視訊會議的音訊與畫面、Slack 訊息，以及公司內部或本地網站，未必適合走同一條網路路徑。本文以 Windows 版 v2rayN 為例，說明如何先確認代理入口，再規劃 Zoom、Slack、Google Meet 的路由，並檢查 UDP 是否真的可用。路由規則只能處理已進入核心的連線；若應用程式忽略系統代理，或視訊媒體流量沒有經過可轉送 UDP 的代理出口，單純新增網域規則並不能保證視訊順暢。
先分清代理入口與路由出口
視訊卡頓時，先不要急著新增網域或修改核心設定。v2rayN 是管理節點、啟動核心及設定本機代理的用戶端；Xray 或 V2Ray 核心負責接收流量、套用路由規則並連線至目標。系統代理則是應用程式進入本機代理的其中一種方式。這幾個環節任一處未接通，路由表就不會自動替應用程式接管連線。
一般網站多以 TCP 連線至 443 連接埠，使用系統 HTTP 代理時，常能透過 v2rayN 設定的本機入口轉送。但 Zoom、Slack Huddles、Google Meet 的即時音訊與視訊可能使用 UDP。傳統系統代理設定不等於完整接管 UDP；若應用程式直接建立 UDP 連線，流量可能不經過本機代理，也可能因網路限制而改走 TCP、品質下降或連線失敗。即使網頁能正常登入，也不能據此認定會議媒體已走預期路徑。
系統代理入口
- 常見對象
- 遵循系統代理設定的應用程式連線
- 本機位址
127.0.0.1- 連接埠範例
10808，以目前核心監聽設定為準- 注意事項
- 不保證所有 UDP 流量都會進入核心
請在「設定」→「參數設定」確認實際連接埠與入口類型，不要直接套用範例值。
TUN 網路入口
- 常見對象
- 需要接管一般應用程式網路流量的情境
- 處理方式
- 由虛擬網路介面將流量交給核心
- 需確認項目
- 核心、權限、路由與 UDP 轉送支援
- 注意事項
- 仍須確認實際規則與防火牆行為
TUN 能擴大流量入口範圍，但不會自動修復節點或伺服器端的 UDP 問題。
辦公環境通常需要同時照顧外部服務與本地資源。可先以「一般網路預設規則」為基礎，再按實際需求加入必要的網域或網段規則，讓公司內部網域、印表機及區域網路位址維持直連。若公司服務以 VPN、專用 DNS 或受管理的網路連線提供，應遵循組織的網路政策；不要為了讓會議軟體連上，就把所有流量改成全域代理，或把私人網路範圍一概送往遠端節點。
為會議與協作工具規劃分流
Zoom、Slack、Google Meet 都可能使用多個網域、CDN、登入服務及媒體中繼服務。服務端點會依帳戶、區域、版本與網路狀況改變，因此只加入一個主網域，無法涵蓋所有連線；只依應用程式顯示名稱建立規則，也不代表核心一定能識別其每一條連線。先確認流量是否進入核心，再透過記錄觀察實際目標網域、IP、連接埠及選中的出站。
| 工具或流量 | 常見連線特性 | 分流規劃 | 驗證重點 |
|---|---|---|---|
| Zoom 會議 | 登入及控制流量常見 TCP 443；音訊、視訊及螢幕分享可能使用 UDP，媒體端點會變動 | 先依組織政策決定直連或代理；不要只依賴單一網域規則 | 查看會議連線統計、核心記錄及防火牆是否允許所需傳輸 |
| Slack 訊息與檔案 | 一般協作功能多使用 HTTPS；Huddles 的即時媒體另有連線需求 | 可先測試一般 Slack 功能，再獨立測試 Huddles，不要把兩者視為同一種流量 | 確認訊息、檔案及 Huddles 是否呈現不同的連線結果 |
| Google Meet | 網頁控制連線與即時媒體連線的傳輸方式可能不同；常見 UDP 媒體連接埠包括 3478，亦可能使用其他端點 | 以目前網路政策及 Meet 診斷結果為準，避免只按固定 IP 清單分流 | 進入會議後查看 Meet 的連線診斷，留意傳輸協定、延遲與封包遺失 |
| 公司內部與區域網路服務 | 可能使用私有 IP、內部 DNS 名稱或專用連接埠 | 將已確認的內部網域或網段設為直連，並保留組織要求的 VPN 或 DNS 設定 | 測試內部入口網站、檔案服務及本地設備，不要只測試公共網站 |
表中的連接埠是常見情況，不是完整且永久不變的服務清單。實際連線規格會依服務端、用戶端版本與管理政策而異；若是公司管理的 Zoom、Slack 或 Google Workspace，應優先使用管理員提供的網路需求文件。不要憑空把某個媒體連接埠硬寫成唯一允許值，也不要把服務網域解析出的 IP 長期固定在規則中，因為 CDN 與服務端點可能調整。
建議方案：先保持辦公網路可達，再逐項測試代理
一般遠距辦公
- 保留已驗證的本地與內部網域直連規則。
- 先用系統代理測試一般網頁與協作訊息。
- 會議媒體失敗時，再確認 UDP 是否進入核心。
需要接管更多流量
- 在確認核心支援後評估 TUN 模式。
- 保留區域網路直連，並檢查 DNS 與防火牆。
- 分別測試 TCP 控制連線與 UDP 媒體流量。
不要同時切換節點、路由模式與 TUN；一次只變更一項，才容易定位是哪個環節影響會議品質。
判斷原則：網頁能開，不等於視訊媒體已通
若登入、聊天正常，但加入會議後音訊中斷或畫面停格，優先檢查 UDP 媒體連線、應用程式是否繞過系統代理，以及防火牆和網路限制；不要先把問題歸因於路由網域清單不完整。
v2rayN 設定與分流測試：每次只改一項
以下以 Windows 上的 v2rayN 7.x 常見操作方式為例，實際選單名稱可能因版本、介面版型與核心而略有差異。先記下目前節點、路由模式、代理入口及核心版本；需要 TUN 時，也先確認目前核心及系統權限符合該版本的要求。下列連接埠 10808 僅為示例，請依「設定」→「參數設定」及核心啟動記錄確認真實值。
-
記錄現有設定
記下 v2rayN 版本、目前活動節點、核心名稱與版本，以及底部顯示的系統代理和路由狀態。若正在進行重要會議，先不要在會議中切換核心或重啟代理；在會議前用可重現的測試條件完成調整。
-
確認本機入口
開啟「設定」→「參數設定」，查看本機監聽位址、連接埠與代理類型。一般本機使用應確認監聽在回環位址，例如
127.0.0.1；若系統代理指向的連接埠與核心實際監聽值不同，先修正入口，不要先新增路由規則。 -
建立基準測試
先選一個已知可用的節點，維持目前路由模式，依序測試一般 HTTPS 網頁、Slack 訊息與一場短時間測試會議。記錄每項功能是否可用、加入會議耗時、音訊是否中斷，以及應用程式或核心記錄中的錯誤訊息。
-
檢查實際路由
在 v2rayN 的核心或執行記錄中搜尋測試時段的目標連線，留意網域、IP、連接埠與出站標籤。若完全沒有相應連線，先查應用程式是否使用系統代理或是否需要 TUN；若已有記錄，再確認它被分配至直連還是代理出站。
-
逐項調整並回測
按需要新增或調整一條規則，重新啟動核心或依介面提示套用設定，再重複同一組測試。不要一次加入大量服務網域、改 DNS、切換節點並開啟 TUN；若結果變差，恢復上一個已記錄的設定，再檢查下一項。
對照時可先分開測試「一般網頁」與「會議媒體」：若前者成功、後者失敗，問題通常不在一般 HTTPS 代理入口本身。再測試相同節點下的另一個網路，或相同網路下的另一個已知可用節點，可以協助區分本機設定、接取網路與節點端問題。這些比較只能縮小範圍，不能單靠一次測試判定伺服器故障。
UDP 排查與手機設定差異
UDP 是即時媒體常用的傳輸方式之一，但「核心支援 UDP」不代表端到端必然可用。節點協定與伺服器端設定、代理核心、用戶端入口、作業系統防火牆、路由器及企業網路都可能影響 UDP。部分網路會封鎖或限制 UDP，服務也可能改用 TCP 備援；此時會議能連上，不代表延遲與音訊品質已達最佳狀態。
Slack 訊息正常，Huddles 卻沒有聲音？
先退出 Huddle，確認系統音訊裝置與 Windows 防火牆，再查看會議期間是否有媒體連線記錄。訊息多為 HTTPS，不能用訊息能傳送來證明 UDP 媒體已正常轉送。
新增 Zoom 網域後，仍然卡在連線中？
檢查記錄中的實際目標是否命中該規則，並確認會議媒體流量是否進入核心。服務可能使用不同的媒體端點；依管理員提供的網路文件核對，不要只新增猜測的網域。
開啟 TUN 後，公司內部網站無法使用？
先檢查內部網域 DNS、私有 IP 路由及現有 VPN 設定，再確認內部網段是否被錯誤送往代理出站。一次恢復一項設定，避免同時變更 DNS 與路由而難以定位原因。
v2rayNG 匯入同一份訂閱就會完全相同嗎？
不一定。節點資料可以共用，但 Android 端的 VPN 權限、分應用代理、路由選項及核心支援各自獨立。請在 v2rayNG 內確認目前模式與 UDP 相關設定，並分別測試會議應用程式；不要假設桌面端規則會自動同步。
若使用 v2rayNG，先確認應用程式已取得系統要求的 VPN 權限，並檢查分應用代理清單是否把 Zoom、Slack 或 Meet 排除在外。手機端切換節點或模式後，需重新建立 VPN 連線並再次測試；桌面版 v2rayN 的本機連接埠、TUN 狀態及路由規則不會自動成為手機端設定。若帳戶或網路由組織管理，分流與 VPN 使用方式應先符合其政策。
- 一般網站與聊天失敗：先檢查節點狀態、系統代理入口、DNS 解析與核心啟動記錄。
- 只有音訊或視訊失敗：確認媒體流量是否使用 UDP、應用程式是否被代理入口接管，以及本機和上游網路是否允許所需連線。
- 切換路由後仍像舊設定：關閉並重新加入會議，必要時完全結束應用程式再啟動，避免既有連線沿用先前的路由。
- 所有工具同時變慢：固定節點與網路測試不同時間，並確認是否有背景下載或頻寬競爭；不要只靠節點延遲數字推斷視訊品質。
完成調整後，至少分別驗證一次一般 HTTPS 網頁、協作訊息、本地或公司內部服務，以及一場短時間的視訊會議。會議中觀察延遲、封包遺失與傳輸方式，並保留測試時間、節點、路由模式和核心記錄。若組織提供 Zoom、Slack 或 Google Meet 的網路診斷工具與端點清單，應以其當前文件為準。需要重新核對用戶端基本操作時，可參閱快速上手；完成設定後，再依日常使用情境選擇穩定的直連與代理分流，不必為了讓一個工具連線而永久改成全域代理。