遠端工作時，Zoom、Slack 與 Google Meet 的連線問題，通常不是單純把「系統代理」打開就能解決。視訊會議同時涉及登入網頁、API 請求、WebSocket 即時訊息、音訊與視訊串流，部分情況還會優先嘗試 UDP。若所有流量都經過同一條不穩定的節點，可能出現 Slack 訊息延遲、Zoom 會議反覆重新連線，或 Google Meet 已進入房間卻沒有聲音的情況。
本文以 v2rayN 7.x 常見介面為基準，整理遠端辦公的實用設定：先選擇低抖動且支援 UDP 的節點，再建立工作服務優先走代理、一般網站維持直連的分流規則，最後透過日誌、連接埠與實際會議測試確認效果。設定前請先保留原有分組與目前可用節點，方便發生問題時快速復原。
先理解遠端辦公流量的差異
Zoom、Slack 與 Google Meet 並不是各自只有一個固定網域。登入、帳戶驗證、圖片與檔案服務、訊息同步、會議控制與媒體轉送，可能分別使用不同的主機名稱。Slack 的桌面程式還會長時間維持即時連線；Zoom 與 Google Meet 則會在加入會議後產生持續的音訊、視訊與螢幕分享流量。因此，只加入首頁網域，往往只能改善登入頁，無法保證會議媒體正常。
代理模式也會影響結果。「PAC」或規則模式可以讓指定工作服務經過代理，未列入規則的網站直接連線；「全域模式」則會把瀏覽器、同步工具、更新程式與所有其他應用一併送入代理。若節點頻寬有限，全域模式容易與雲端硬碟同步、系統更新或影音播放競爭，造成會議時延遲升高。遠端辦公通常應先使用規則模式，確認必要服務已納入後，再視網路環境調整。
上面的連接埠只是常見範例，不代表每個版本都使用相同數值。請在 v2rayN 的「設定」→「參數設定」→「本機設定」查看實際 SOCKS、HTTP 或混合代理連接埠。瀏覽器通常透過 HTTP 或系統代理工作，部分支援 SOCKS 的程式則需要另外填寫 SOCKS5 位址；把 10808 與 10809 顛倒，會造成某些程式完全無法連線。
選擇適合會議的節點與核心
視訊會議不應只按照節點清單中的最低延遲排序。一次測得 45 ms 並不表示整場會議都穩定，還要觀察延遲抖動、封包遺失、上傳速度與 UDP 是否能正常建立。可在同一個網路、同一時段連續測試候選節點 3 次，記錄例如 72、76、79 ms 的中位數與波動；若結果是 48、190、逾時，即使最低值漂亮，也不適合拿來作為工作主力。
節點協定與核心也要配對。一般 VMess、VLESS 或 Trojan 設定可能使用 TCP、WebSocket、gRPC 或 TLS；若分享連結含有 security=reality、pbk、sid 或 flow=xtls-rprx-vision，通常應使用支援這些欄位的 Xray 核心。不要為了追求較低延遲而刪除 flow、SNI 或 Reality 公開金鑰，伺服器端參數不一致時，結果通常是握手失敗而不是速度變快。
VLESS + Reality
- 核心
- Xray
- 傳輸
- TCP
- 必要欄位
- pbk、sid、sni、fp
- UDP
- 依節點與網路支援
適合新式節點；匯入後先核對安全層與流量控制欄位。
VMess + WS + TLS
- 核心
- 相容核心
- 傳輸
- WebSocket
- 常見連接埠
- 443
- UDP
- 須確認伺服器轉送能力
適合既有訂閱；會議前應額外確認長時間連線是否穩定。
UDP 支援需要分開理解。用戶端核心能接收 UDP 請求，不等於節點出口、伺服器轉送或中間網路一定允許 UDP。某些工作服務在 UDP 不可用時會回退到 TCP，但回退後可能增加延遲或降低畫面品質。若 v2rayN 日誌反覆出現 UDP timeout，而一般網頁正常，應先換一個明確支援 UDP 的節點測試，不要只修改瀏覽器代理。
| 觀察結果 | 可能含義 | 工作用途建議 |
|---|---|---|
| 延遲 70 至 100 ms，波動小 | 互動請求與語音通常較穩定 | 列為主要會議節點 |
| 延遲低但每次差距超過 80 ms | 線路抖動或入口負載較高 | 不作為長時間會議首選 |
| 網頁正常，UDP 持續逾時 | 節點或中間網路未提供 UDP 路徑 | 更換支援 UDP 的節點 |
| 下載速度高但上傳不穩 | 上行頻寬或回程路由不足 | 避免用於螢幕分享與多人會議 |
結論：會議節點先看穩定性，再看峰值速度
遠端辦公的主要瓶頸常是抖動與上行封包遺失，而不是短時間下載速度。能連續維持 60 秒語音、畫面與螢幕分享的節點，通常比測速頁面顯示最高速度的節點更值得保留。
在 v2rayN 建立工作分流
建議先把分流目標限定為工作服務，不要一開始加入過多模糊的關鍵字。可在 v2rayN 的路由設定中建立「工作服務」規則，將 Zoom、Slack、Google Meet 相關的官方網域與必要子網域導向代理出站，再把其他流量維持直連。實際網域會隨服務版本、地區與登入流程變動，規則應以目前服務的連線日誌為依據逐步補充。
對網域規則而言，完整網域、網域後綴與關鍵字的涵蓋範圍不同。將 slack.com 作為完整或後綴規則，可能無法涵蓋服務使用的其他主機；只寫 slack 關鍵字，則可能誤攔截無關網站。優先使用明確的網域後綴，並在測試完成後清理過度寬鬆的關鍵字規則。Google Meet 的媒體連線還可能使用 Google 相關基礎服務，不能只測試 meet.google.com 登入頁。
更新訂閱
開啟「訂閱分組」→「更新目前訂閱」，確認匯入後的節點資料是最新版本。先保留一台原本可用的備用節點，不要在測試前刪除整個分組。
指定核心
進入「設定」→「參數設定」→「Core 類型」，依節點欄位選擇 Xray 或相容核心。若使用 Reality 或 Vision，先確認核心能辨識相關參數。
設定代理
在主視窗啟用「系統代理」，先選擇規則模式。確認 v2rayN 顯示的本機 HTTP 與 SOCKS 連接埠，再避免其他代理程式同時監聽相同連接埠。
加入工作規則
進入「設定」→「路由設定」，新增 Zoom、Slack 與 Google Meet 的明確網域規則，出站指定目前代理伺服器；未命中規則的流量保留直連。
測試實際會議
先用瀏覽器登入，再加入測試會議，依序測試語音、鏡頭、螢幕分享與 Slack 即時訊息。每項至少觀察 60 秒，並同步查看核心日誌。
測試時要分辨「代理沒有接到請求」與「代理接到但出口失敗」。若日誌中完全沒有目標網域，可能是程式未遵循系統代理、規則沒有命中，或 DNS 請求在另一條路徑完成。若日誌顯示已建立出站但隨後 timeout，則應檢查節點、UDP 路徑、MTU 或服務端限制。修改一項規則後重新測試，才能知道哪個變更真正有效。
| 服務 | 優先測試內容 | 常見失敗表現 | 判斷方向 |
|---|---|---|---|
| Zoom | 加入會議、語音、鏡頭、螢幕分享 | 加入房間後無聲音或畫面卡住 | 檢查 UDP、上行頻寬與會議媒體日誌 |
| Slack | 登入、頻道切換、即時訊息與檔案預覽 | 訊息延遲、頻道載入不完整 | 檢查長連線與相關網域是否命中規則 |
| Google Meet | 加入房間、麥克風、攝影機與分享畫面 | 反覆重新連線、畫質自動下降 | 觀察上行封包與 UDP 回退狀況 |
會議前後的檢查與復原方法
正式會議前，先停止大型下載、雲端同步與不必要的節點測速，避免測試本身搶占頻寬。確認 v2rayN 核心正在執行、系統代理狀態為開啟、目前伺服器名稱正是剛測試的節點，然後用瀏覽器開啟一般網站與工作服務各一個。一般網站可正常直連，不代表工作流量一定已走代理；應從日誌或路由命中資訊核對。
若會議只有聲音中斷而網頁仍正常，優先檢查 UDP 與上行品質；若 Slack 訊息延遲但 Zoom 正常，可能是 Slack 長連線的網域未加入規則，或桌面程式沒有遵循系統代理。若所有工作服務都無法連線，則先切回原本可用節點或暫時使用全域模式作為診斷，不要立即重建整份設定。
開啟系統代理後，Slack 還是沒有新訊息？
先完全退出並重新啟動 Slack，再查看 v2rayN 日誌是否出現 Slack 相關請求。若沒有記錄，檢查程式代理設定或補充正確的網域規則。
Zoom 能加入會議，但鏡頭和語音不穩？
換用明確支援 UDP 的節點，停止其他上傳工作，並在會議測試中觀察 60 秒。若 UDP 仍逾時，改用另一條節點線路比較，不要只重複啟動核心。
Google Meet 只有直連才能開啟，該怎麼辦？
檢查路由規則是否把登入網頁與會議相關網域送往同一代理出站；逐步查看日誌補充缺少的網域，完成後重新整理瀏覽器連線。
規則模式不穩定，可以一直使用全域模式嗎？
全域模式適合短時間定位問題，但長期使用會增加節點負載與資料量。確認工作網域後，建議回到規則模式，並保留一台已驗證的備用節點。
完成設定後，建議建立一份簡短紀錄：v2rayN 版本、核心類型、節點別名、代理模式、UDP 測試結果，以及 Zoom、Slack、Google Meet 各自的測試時間。下次網路環境變更或訂閱更新後，可依同一順序重測。這比單純記住「某個節點很好用」更可靠，因為節點負載、服務網域與本地網路條件都可能在 2026 年內持續變化。