遠距工作時，視訊畫面卡頓不一定代表節點速度不足；DNS、路由方式、UDP 是否能通過，以及本機網路都可能影響 Zoom、Slack 通話與 Google Meet。若工作平台需要代理、常用本地網站又希望直連，建議先確認流量如何進入 v2rayN，再逐項測試節點與會議連線，不要一開始就同時更換核心、路由和 DNS。
本文適合使用 v2rayN 處理遠距工作連線的桌面使用者。你會了解系統代理與 TUN 的差異、如何安排本地直連和工作服務代理規則，以及怎麼確認 UDP 流量是否走上預期路徑。Zoom、Slack 和 Google Meet 的伺服器與連線方式可能隨服務、版本及網路環境改變，因此本文提供的是可驗證的設定方向，不是固定不變的網域清單。
先拆解視訊卡頓的連線環節
視訊會議通常同時使用多條連線：登入與介面可能透過 HTTPS，音訊、視訊或即時協作則可能使用 UDP。實際流量會依服務、用戶端版本、會議功能及網路政策調整。只讓瀏覽器或系統 HTTP 代理生效，不代表所有即時媒體流量也一定經過代理；反過來，開啟 TUN 也不代表節點支援所需的 UDP 傳輸。
先分清楚三個環節：應用程式的流量有沒有進入 v2rayN、路由規則把流量送往直連還是代理，以及代理節點是否能轉送該類流量。若會議可以登入，但加入會議後無聲、畫面延遲或頻繁重連，應優先比較 UDP 路徑與直連路徑，而不是只看節點延遲測試結果。
連接埠資訊只能用來理解可能的傳輸方式，不能據此建立涵蓋所有服務的永久規則。企業網路、防火牆、會議區域及服務端的調度，都可能改變實際使用的端點。若組織提供官方網路需求文件，應以該文件和實際連線記錄為準。
先選流量接管方式：系統代理或 TUN
系統代理適合先做基本驗證：瀏覽器及會讀取作業系統代理設定的程式，通常可使用 v2rayN 設定的本機 HTTP 或 SOCKS 入口。不過，不同應用程式採用系統代理的方式不同，部分即時媒體連線可能另行建立 UDP 通道；只看到系統代理已啟用，不能推論 Zoom 或其他會議程式的全部流量都已被接管。
TUN 會建立虛擬網路介面，接收更多系統網路流量，適合不讀取系統代理設定的程式。但它通常影響範圍較大，也需要確認權限、路由及 DNS 設定。TUN 本身不是「指定某個程式走代理」的同義詞；能否依應用程式程序分流，要看目前 v2rayN 版本、TUN 實作與所用核心是否提供並正確啟用相應能力。
先用簡單路徑驗證，再擴大接管範圍
系統代理
- 先測試會讀取系統代理的瀏覽器與工作網站。
- 保留本機網站直連規則，減少不必要的代理流量。
- 若會議媒體流量未進入代理，再檢查應用程式支援與 UDP。
TUN 模式
- 用於需要接管一般系統網路流量的情況。
- 啟用前確認系統權限、DNS 與路由行為。
- 先用網域或 IP 規則驗證，不假設所有版本都能依程序分流。
先讓一種接管方式穩定工作，再考慮切換；同時啟用多套代理或 VPN，會增加判斷流量路徑的難度。
安排工作服務與本地網站分流
路由規則通常依序比對網域、IP 或其他條件，並將符合條件的連線送往指定出站。規則順序很重要：若前面的廣泛規則已接管所有流量，後面的本地直連規則可能永遠不會生效。建議先保留必要的區域網路與本機位址直連，再加入工作服務規則，最後才設定一般流量的預設出口；實際規則欄位名稱依使用中的核心與設定格式而異。
| 流量類型 | 建議方向 | 設定與驗證要點 |
|---|---|---|
| 本機裝置與區域網路 | 直連 | 保留回環位址及實際使用的區域網路網段，避免連線印表機或公司內部設備時誤送遠端節點。 |
| 常用本地網站 | 依需求直連 | 可用適合目前資料庫的網域分類或明確網域規則；不要只靠 IP 所在地判斷服務歸屬。 |
| 工作平台介面與登入服務 | 依服務政策選擇代理或直連 | 規則應參考官方網路需求與實際記錄；服務可能使用多個網域、CDN 或動態端點。 |
| 未命中規則的其他流量 | 使用既定預設出口 | 明確決定採用代理或直連，避免因規則缺漏而產生難以預測的回退行為。 |
不要把單一服務的網域名稱當作永久完整清單，也不要把整個視訊平台所有網域一概代理，卻忽略登入、檔案分享或企業自訂網域可能使用不同路徑。若目標是讓工作平台走代理，應以服務端點和會議實測逐步補充規則，並在每次變更後確認規則是否命中。
依序完成 v2rayN 設定與測試
不同 v2rayN 版本可能調整選單名稱或位置，以下以常見的桌面操作流程說明。先備份目前可用的路由設定，並記下作用中的節點及核心。新增規則時一次只處理一類流量，避免遇到異常後無法判斷是哪項變更造成。
-
確認節點與核心
在主畫面確認目前作用中的伺服器，並查看「設定」中的核心選項或啟動記錄，辨識實際使用的是 Xray 還是 V2Fly。節點協定、傳輸方式及 UDP 支援情況，應以訂閱內容和服務提供者說明為準。
-
選擇接管方式
先從系統匣或主畫面的「系統代理」選單啟用自動設定，測試瀏覽器能否使用預期出口。若工作程式不讀取系統代理，再評估「設定」或「參數設定」中提供的 TUN 選項；確認權限與路由後才啟用。
-
設定規則順序
開啟目前版本提供的路由設定入口，先核對區域網路與私有位址規則，再加入工作服務所需的網域條件，最後確認預設出站。規則名稱及欄位會隨核心設定格式而異，保存前檢查每條規則實際指向的是直連還是代理。
-
測試工作網站
保持同一節點與網路，依序測試登入、開啟訊息或協作頁面，以及加入一場測試會議。記錄是否能登入、音訊是否穩定、視訊是否中斷，並在 v2rayN 記錄中確認相關連線是否進入預期路由。
-
比較 UDP 表現
若介面正常但會議媒體異常，確認接管路徑、核心和節點是否能處理所需 UDP。可在允許的情況下比較系統代理與 TUN，或使用服務提供的連線診斷；每次只改一項設定，並在測試後恢復不需要的接管模式。
測試時不要同時開啟多個代理用戶端，也不要讓另一個 VPN、公司網路代理或安全軟體改寫路由。若有企業管理政策，應先確認是否允許自行變更代理、DNS 或虛擬網路設定；某些內部服務必須維持指定的公司出口。
UDP 與節點選擇的實際判斷
視訊會議的即時媒體對延遲波動、丟包與上行穩定度都敏感。節點清單上的連線延遲，只反映特定測試方式下的一部分資訊，不能代表會議中的 UDP 品質。某些網路或節點只適合 TCP 流量；即使網頁與登入都正常，媒體封包仍可能無法走同一條代理路徑。
如果服務可以改用 TCP 備援，會議仍可能連線，但延遲或互動體驗不一定理想。不要把「成功加入會議」當成 UDP 一定正常，也不要把畫面卡頓直接歸因於某個協定名稱。應在相同裝置、同一場測試會議與相同網路條件下，比較不同節點及接管方式，並記錄結果。
- 優先選穩定而非只看最低延遲：比較數分鐘內的音訊中斷、畫面凍結與重連情況，並在不同時段重測。
- 確認節點能力：向服務提供者確認節點是否支援 UDP 轉送；用戶端能選取節點，不代表遠端出口必然提供所有傳輸能力。
- 分開測試上行與下行：能清楚聽見同事但別人聽不清楚，可能與本機上行、無線訊號或媒體路徑有關，不一定是下載頻寬不足。
- 保留直接連線作對照：若政策允許，暫時以直連測試同一服務。直連正常而代理異常，才優先追查代理、節點或路由；兩種方式都異常則要檢查本機網路與服務端狀態。
常見異常的排查順序
會議登入成功但沒有聲音、工作平台載入正常卻無法加入通話，往往是不同連線走了不同路徑。排查時先確認故障範圍，再查規則命中、UDP 路徑和節點能力；不建議未查看記錄就一次加入大量網域或切換多種核心。
網頁能開，為什麼會議一直轉圈？
網頁可能只驗證了 HTTPS 連線。先確認會議程式的流量是否進入預期接管方式，再查看核心記錄和服務診斷；若只有媒體階段失敗，檢查 UDP 是否被本機網路或節點阻擋。
開啟 TUN 後，本地網站也走了代理嗎？
有可能，取決於 TUN 的路由設定與規則順序。檢查本地網域規則是否存在、是否排在廣泛代理規則之前，再以記錄或實際出口測試確認，不要只憑 TUN 開關判定路由結果。
換了節點，影像還是會卡嗎？
先固定節點與其他設定，改用有線網路或不同 Wi-Fi 測試；若所有節點在同一網路都出現相同問題，應檢查本機上行、無線丟包、網路限制及服務狀態。
測試結果可簡單記錄時間、網路類型、節點名稱、接管方式、會議服務及故障現象。分享記錄或截圖前，請遮蔽訂閱網址、伺服器位址、帳號識別資訊與可能包含存取權杖的內容。遇到企業內部服務或管理政策相關問題，請交由組織網路管理人員確認，以免個人分流規則與公司安全要求衝突。