TUN 模式全域接管流量原理詳解：v2rayN 與 v2rayNG 啟用教學

TUN 模式接管流量的實際流程

TUN 是一種運作於網路層的虛擬介面。啟用後，系統會將符合路由條件的 IP 封包交給虛擬網卡，客戶端再讀取這些封包，還原目標位址與協定，依據路由規則決定直連、代理或封鎖。對應用程式而言，仍是在存取原本的網域與連接埠，不需要知道本機 SOCKS 或 HTTP 代理連接埠。

系統代理的作用位置更接近應用程式層。瀏覽器等遵循系統代理設定的軟體，會主動將請求傳送至本機代理連接埠，但部分命令列程式、遊戲元件、更新程式與採用自有網路堆疊的軟體可能忽略這項設定。TUN 不依賴應用程式主動配合，因此能涵蓋更多流量類型，也能處理需要代理的 UDP 請求。

「全域接管」指的是流量進入客戶端的判斷流程，並不代表所有連線都必須經過遠端節點。客戶端仍可依網域、目標 IP、區域網路網段與協定進行分流。例如存取家用路由器可直連，符合代理規則的網站經由節點，DNS 請求則交由指定的解析策略處理。

TUN 與系統代理該如何選擇

如果主要使用瀏覽器與明確支援代理設定的軟體，系統代理通常較輕量，故障範圍也較小。只要客戶端監聽的本機連接埠正常，且應用程式遵循系統設定，就能完成連線。需要讓不讀取系統代理的程式也進入分流流程時，再啟用 TUN 會更合適。

排查時不要同時頻繁切換系統代理、TUN 與路由模式。較穩妥的做法是先確認節點在系統代理下可用，再關閉其他暫時性的網路工具，單獨啟用 TUN。如此一來，若連線出現變化，原因就能集中在虛擬網卡、路由或 DNS，而不是節點本身。

在 v2rayN 中啟用 TUN 模式

以下操作以 v2rayN 7.12.5 的 Windows 介面為參考。不同小版本的按鈕位置可能調整，但準備節點、授予虛擬網卡權限、啟用 TUN、檢查路由模式這四個環節不變。開始前，先在一般系統代理模式下測試一次節點延遲與網頁連線，避免將節點無法使用誤判為 TUN 故障。

1. 選擇可用設定。在 v2rayN 主視窗選取已測試可用的 VMess 或 VLESS 設定，將其設為作用中伺服器。
2. 檢查系統代理狀態。首次測試 TUN 時，可先將系統代理切換為關閉，減少兩種接管方式同時變動造成的干擾。
3. 啟用 TUN。在主視窗或系統匣選單找到「TUN 模式」開關並啟用。Windows 跳出權限確認時，允許這次操作；客戶端需要建立虛擬介面並寫入路由。
4. 檢查分流方式。進入「設定」→「參數設定」，查看 TUN 相關設定與目前的路由模式。需要讓中國大陸與區域網路直連時，選擇採用規則分流的設定，不要只憑「全域接管」字樣判斷出站方式。
5. 驗證 DNS 與存取路徑。先造訪常用網頁，再測試原先不遵循系統代理的應用程式。兩者都能連線後，繼續確認路由器管理介面與區域網路裝置仍可存取。

運作穩定後，可以恢復所需的自動啟動設定。若每次重新啟動系統後都無法建立 TUN，應檢查客戶端啟動權限與相關服務狀態，而不是反覆刪除訂閱。訂閱只提供伺服器與協定參數，虛擬網卡能否建立屬於本機環境問題。

在 v2rayNG 中啟用系統層級接管

v2rayNG 在 Android 上透過系統 VPN 介面建立虛擬網路，其作用與桌面版 TUN 接管相近。以下以 v2rayNG 1.10.4 的介面為參考。首次啟動時，系統會顯示連線授權視窗；確認授權後，應用程式流量才能進入 v2rayNG 的路由與代理流程。

1. 匯入並選取設定。更新訂閱後，選取已完成連線測試的 VMess 或 VLESS 節點。
2. 檢查 VPN 設定。進入「設定」→「VPN 設定」，確認不要將需要代理的應用程式加入繞過範圍。首次使用建議關閉按應用程式篩選，先驗證整體連線。
3. 返回主介面啟動。點選主介面的啟動按鈕。系統詢問是否允許建立 VPN 連線時選擇允許，狀態列出現 VPN 狀態後再進行測試。
4. 檢查路由模式。依使用目的選擇規則分流或全域代理。規則分流可讓區域網路與指定目標直連；全域代理則會將更多已接管的連線交給代理出站。
5. 分別測試網域與 IP。先開啟常用網頁驗證網域解析，再測試目標應用程式。網頁能開啟但應用程式失敗時，檢查按應用程式代理設定；IP 可連線但網域失敗時，重點檢查 DNS。

Android 的背景限制可能在螢幕熄滅後暫停客戶端。若前景存取正常、鎖定螢幕一段時間後連線中斷，應在系統應用程式設定中允許 v2rayNG 在背景執行，並檢查電池策略是否限制其網路活動。這個現象與節點協定沒有直接關係。

DNS、MTU 與路由迴圈為何容易出錯

TUN 將更多連線納入統一處理後，DNS 與路由設定之間的依賴會更加明顯。網域首先需要解析為 IP，解析請求本身也必須選擇直連或代理路徑。如果 DNS 請求被錯誤送回同一個尚未完成初始化的 TUN 介面，可能出現網頁長時間等待、直接輸入 IP 卻能連線的現象。

MTU 表示單一網路層封包在目前介面上的最大傳輸大小。數值與實際鏈路不相符時，小型網頁可能正常載入，但較大的上傳、圖片或特定握手卻反覆逾時。遇到這種特徵時，可以記錄目前數值後逐步降低測試，每次只修改一個參數，不要同時變更節點傳輸方式、安全設定與 MTU。

TUN 啟用後無法連網的排查清單

排查的核心是確認故障發生在哪一層。先判斷虛擬介面是否成功建立，再確認預設路由是否存在，接著驗證 DNS，最後才檢查個別應用程式與協定。每完成一步都記錄結果，可避免在多個設定頁面之間反覆切換。

• 確認節點本身可用：關閉 TUN，使用系統代理完成一次網頁連線測試。
• 確認建立權限：Windows 檢查 v2rayN 是否取得建立虛擬介面的權限；Android 檢查系統 VPN 授權是否仍然有效。
• 排除介面衝突：暫時退出會建立其他虛擬網卡或修改預設路由的軟體，然後重新啟動 TUN。
• 檢查私有網段：需要存取路由器或區域網路服務時，確保目前網段走直連。
• 檢查 DNS：網域失敗而目標 IP 可連線時，查看客戶端記錄中的解析逾時資訊。
• 檢查按應用程式規則：v2rayNG 中只有個別應用程式無法連線時，確認它是否被排除。
• 檢查時間：裝置時間偏差過大，可能導致使用 TLS 的 VMess 或 VLESS 設定握手失敗。

Windows 可使用系統內建命令查看介面、路由與 DNS。執行命令僅用於觀察，不要在不了解含義時批次刪除路由。重點查看是否出現新的虛擬介面、預設路由指向是否合理，以及網域解析是否有回應。

ipconfig /all
route print
nslookup example.com

如果記錄顯示連線逾時，還要區分是代理伺服器連線逾時，還是目標網站經由出站連線逾時。前者通常與節點位址、網路可達性或路由迴圈有關；後者可能是目標服務無法連線。若記錄中持續重複相同的 DNS 請求，應先處理解析鏈路。

常見問題與使用限制

TUN 更適合解決應用程式不讀取系統代理、需要統一處理 UDP，以及依目標規則分流等問題。它不會改善節點本身的頻寬、延遲或可達性，也無法修復錯誤的伺服器位址、連接埠、驗證資訊與傳輸參數。

穩定設定的判斷標準不是開關能否點亮，而是連續使用期間網域解析、網頁存取、目標應用程式與區域網路連線都符合預期。完成驗證後，保存目前的路由與 DNS 選擇，後續發生問題時就能與這組基準設定比較。