如何開啟 TUN 模式：虛擬網卡接管全域流量的原理與設定步驟

TUN 模式解決的不是「節點能否連線」

一般系統代理主要是向作業系統登錄 HTTP 或 SOCKS 代理位址。會讀取系統代理設定的瀏覽器與應用程式，會將請求傳送至本機入站連接埠；忽略該設定、使用自有網路堆疊或直接建立 UDP 連線的程式，則可能繼續透過預設網卡直連。此時節點本身可以正常運作，但程式沒有將流量交給用戶端。

TUN 模式改變的是流量入口。用戶端會建立一張虛擬第三層網卡，並將接管規則寫入系統路由表。應用程式發出的 IP 封包會先進入虛擬網卡，再由 v2rayN 或 v2rayNG 交給 Xray 核心處理。核心會依據網域名稱、目標 IP、連接埠與協定比對路由規則，最後選擇直連、代理或阻擋出站。

「接管全域流量」不代表把所有資料無條件送入遠端節點。區域網路位址、用戶端自身連線、系統保留網段與明確設定的直連規則，仍應繞過代理。正確的 TUN 設定必須避免代理迴圈：核心連線伺服器所產生的流量不能再次進入同一條代理鏈路，否則可能出現連線逾時、CPU 使用率升高或網路完全中斷。

• 系統代理：導入門檻低，適合遵循代理設定的瀏覽器與一般桌面應用程式。
• TUN 模式：涵蓋範圍更完整，可處理未讀取系統代理的 TCP 與多數 UDP 程式。
• 路由分流：決定流量進入核心後的走向，與是否開啟 TUN 屬於不同層級。
• 節點協定：VMess、VLESS 等負責用戶端與伺服器之間的傳輸，不負責讓本機應用程式主動使用代理。

開啟前先確認權限、核心與現有網路元件

建立虛擬網卡及修改系統路由表需要較高權限。Windows 上的 v2rayN 通常需要以管理員權限啟動 TUN；macOS 與 Linux 會在首次建立網路介面或寫入路由時要求系統授權。Android 上的 v2rayNG 會使用系統提供的 VPN 服務建立虛擬介面，首次啟動時會彈出連線授權提示。

以下資料用於標示本文的參考環境，不代表協定相容性的最低版本。不同版本可能調整選單文字，但檢查順序不變：先確認核心可啟動，再確認虛擬網卡存在，最後檢查預設路由與 DNS 是否已切換。

1. 先在一般系統代理模式下連線至同一個節點，確認伺服器位址、連接埠、使用者識別碼、TLS 或 REALITY 參數有效。
2. 退出其他會建立虛擬網卡、修改預設路由或接管 DNS 的網路程式，避免兩套規則同時生效。
3. 記錄目前使用的區域網路網段。例如家用路由器常見位址為 192.168.1.0/24，該網段通常應保留直連。
4. 檢查本機連接埠是否衝突。若 10808 已被其他程序占用，應在用戶端參數設定中更換連接埠後重新啟動核心。
5. 保留一個可正常運作的節點作為基準。訂閱中有多個節點時，不要在排查 TUN 的同時頻繁切換節點。

v2rayN 桌面端開啟 TUN 的完整步驟

先更新訂閱，並選擇一個已通過一般代理驗證的節點。VMess 與 VLESS 都可作為 TUN 的代理出站；TUN 不會變更節點欄位，也不要求重新產生訂閱。若匯入後的節點無法在一般模式下連線，應先修正節點設定，再處理虛擬網卡。

1. 啟動權限：完全退出 v2rayN。在 Windows 中以管理員權限重新執行；macOS 或 Linux 出現系統提示時，請核准網路設定變更。
2. 檢查入站參數：開啟「設定」→「參數設定」，確認本機混合連接埠未被占用。本文範例使用 10808。
3. 檢查 TUN 參數：進入「設定」→「參數設定」→「TUN 模式設定」。先保留預設堆疊與預設 MTU，不要同時修改多個進階欄位。
4. 選擇路由模式：在主介面選擇所需的路由規則。首次驗證可使用代理涵蓋範圍較高的規則，確認接管成功後再恢復依網域名稱與 IP 分流。
5. 開啟 TUN：啟用主介面的「TUN 模式」開關。狀態列應顯示核心正在執行，系統網路清單中也應出現新的虛擬介面。
6. 驗證連線：分別測試瀏覽器、命令列程式與原先無法使用代理的應用程式。若只有瀏覽器成功，應繼續檢查路由表與 DNS，而不是只查看系統代理開關。

開啟後不要只用網頁判斷結果。可以在終端機執行一次網域解析，再存取一個依 IP 規則分流的目標，同時觀察 v2rayN 日誌中的入站記錄。如果日誌出現來自 TUN 的新連線，表示資料已進入核心；若日誌完全沒有記錄，問題更可能出在權限、虛擬介面或系統路由。

v2rayNG 在 Android 上的接管步驟

v2rayNG 會透過 Android 的 VPN 服務建立虛擬網路介面；連線按鈕啟動的不只是本機 HTTP 代理。使用 Xray 核心時，應用程式流量進入虛擬介面後，會再交由路由模組處理，因此未讀取系統代理設定的應用程式也能套用規則。

1. 匯入設定：使用訂閱連結更新伺服器清單，或匯入完整的 VMess、VLESS 設定。選取節點後，先執行一次真實連線延遲測試。
2. 檢查執行模式：開啟「設定」→「模式」，確認使用 VPN 接管方式，而不是僅向區域網路提供本機代理連接埠。
3. 檢查 VPN 參數：進入「設定」→「VPN 設定」，先保留預設 MTU。若目前網路出現部分頁面載入停滯，再以小幅度逐步調低。
4. 設定分應用程式規則：需要所有應用程式遵循同一路由時，關閉不必要的應用程式排除項目；只接管指定程式時，明確選擇包含模式或繞過模式。
5. 開始連線：返回主介面點選連線，接受系統網路連線授權。狀態列出現連線狀態後，再測試目標應用程式。
6. 核對日誌：從主選單開啟日誌，觀察 DNS 查詢、路由命中與代理出站。持續重新連線通常表示節點失敗或底層網路切換，而不是應用程式未被納入清單。

Android 通常只允許一個 VPN 服務保持啟用。若另一個網路工具仍處於連線狀態，v2rayNG 可能無法建立虛擬介面，或剛連線就被系統終止。省電策略也可能在螢幕關閉後限制背景程序；若出現鎖定螢幕後斷流，應檢查系統對 v2rayNG 的背景執行與電池使用設定。

• 只有單一應用程式失敗：檢查分應用程式代理清單，以及該應用程式是否使用獨立 DNS 或特殊 UDP 通道。
• 所有應用程式都失敗：先檢查節點、系統授權，以及目前 Wi-Fi 或行動網路是否可用。
• 連線後無法存取區域網路裝置：確認私有位址沒有被錯誤送往代理出站。
• 行動網路正常但 Wi-Fi 異常：重點檢查 Wi-Fi 的 DNS、IPv6 與 MTU 差異。

路由、DNS 與 MTU 決定接管後的實際表現

TUN 只負責將資料送入處理鏈路，最終結果仍由路由規則決定。常見規則會依網域名稱、目標 IP、連接埠或網路類型進行比對。私有位址與本機位址通常直連，需要代理的網域名稱進入代理出站，廣告或風險網域則可進入阻擋出站。規則順序非常重要：範圍過大的前置規則會遮蔽後續的精確規則。

DNS 是 TUN 排查中最容易被忽略的部分。應用程式請求網域名稱後，用戶端需要取得可用於路由判斷的網域名稱或 IP 資訊。如果查詢仍被其他本機服務攔截、回傳的位址無法連線，或網域解析結果與路由規則使用的位址族不一致，就會出現「用戶端已連線，但某些網域無法開啟」的情況。

MTU 不宜一次調得過低。可以依序測試 1500、1460、1400，每次修改後重新連線，並使用同一個節點、同一個網路與同一個下載目標進行比較。MTU 過大可能觸發分片或路徑封包遺失，過小則會增加封包數量與處理負擔。

建議的分流優先順序：
1. 本機位址與用戶端程序 → 直連
2. 區域網路及私有位址 → 直連
3. 明確阻擋的網域或 IP → 阻擋
4. 需要代理的網域與位址範圍 → 代理
5. 其餘流量 → 依目前策略處理

依現象逐項定位常見衝突

排查 TUN 不應從「重新安裝用戶端」開始。更有效的方法是依入口、解析、路由、出站四個層面讀取日誌。每次只修改一個變數，並記錄修改前後的連線時間、日誌關鍵字與失敗範圍。

哪些情境適合長期使用 TUN

TUN 適合需要統一接管多個程式、處理 UDP，或無法逐一設定代理位址的裝置。它能減少為每個應用程式單獨填寫 SOCKS 連接埠的工作，但也會擴大故障影響範圍：一條錯誤的預設路由可能讓整台裝置無法上網，一條過於寬泛的代理規則也可能讓區域網路存取繞遠路。

• 建議開啟：程式不讀取系統代理、需要代理 UDP、多個應用程式需要統一分流，或命令列工具經常切換。
• 可以不啟用：只有瀏覽器需要代理，且瀏覽器已穩定遵循系統代理設定。
• 建議使用規則分流：同時存取區域網路裝置、中國大陸直連服務與代理目標，且希望控制出口範圍。
• 建議暫時停用：正在排查本機網路、路由器設定或 DNS 故障，需要先恢復最簡單的實體網路鏈路。

一套易於維護的設定，應保持三條邊界清楚：用戶端自身連線直連，區域網路與保留位址直連，需要代理的目標則進入 VMess 或 VLESS 出站。訂閱更新只替換伺服器清單時，通常不需重新設定 TUN 與路由規則；若新訂閱變更了協定欄位或核心需求，則應先在一般代理模式下驗證節點。

完成設定後，建議保留一組固定測試：瀏覽器存取、終端機網域解析、區域網路裝置存取、一個 UDP 應用程式，以及一個大型檔案下載。五項結果可分別涵蓋系統代理、DNS、私有網段、UDP 接管與 MTU。日後升級版本或變更路由規則時，依相同順序重新測試即可。