TUN 模式用 Android 的 VpnService 建一張虛擬網卡，把裝置流量整包接進 v2rayNG 內建的 Xray 核心。全文按四步展開：先比較它和預設本機代理的差別，再拆開資料路徑，然後給出開啟與授權順序，最後用三個可重現的檢查確認接管範圍，並列出背景存活與 DNS 解析的常見問題。
TUN 模式與預設本機代理的差別
v2rayNG 預設的連線方式只在本機開兩個入站：SOCKS 在 127.0.0.1:10808，HTTP 在 127.0.0.1:10809。只有會讀取代理設定的 App（瀏覽器、部分下載工具）才會把請求送進這兩個連接埠，其餘應用程式照舊直連。Android 也沒有面向全部應用程式的全域代理開關，Wi-Fi 進階選項裡的代理只對遵守該設定的應用程式生效。
TUN 模式換了一條路徑：v2rayNG 透過 Android 的 VpnService 申請一張虛擬網卡，系統把裝置送出的 IP 封包寫進這張網卡，應用程式端不需要填任何代理位址。網卡裡的封包交給內建的 tun2socks 轉送元件，還原成 TCP 連線與 UDP 工作階段之後，再以 SOCKS5 交給 Xray 核心分流。
| 比較項目 | 預設本機代理 | TUN 模式 |
|---|---|---|
| 接管對象 | 主動設定代理的 App | 裝置全部 IP 流量，可依 App 篩選 |
| App 端設定 | 需要填 127.0.0.1:10808 | 不需要 |
| DNS 處理 | 由 App 自行解析 | 隨流量進核心，依網域解析策略處理 |
| 權限 | 無 | 需要系統 VPN 授權 |
| 耗電 | 低 | 略高，多一次使用者空間轉送 |
| 典型情境 | 瀏覽器與支援代理的工具 | 不支援代理設定的 App、需要全域接管 |
資料路徑：從應用程式到出站
一次請求在 TUN 模式下要經過五個環節，每一段都能單獨排查。
前兩段由系統與轉送元件完成。VpnService 建立網卡後，預設路由 0.0.0.0/0 指向這張網卡，應用程式送出的連線被整包寫進 TUN；tun2socks 從網卡讀出原始 IP 封包，還原出 TCP 連線與 UDP 工作階段，再以 SOCKS5（含 UDP ASSOCIATE）交給 127.0.0.1:10808。
後三段在 Xray 核心裡完成。請求進入 socks 入站後先依 routing 規則比對，再決定走 outbound 代理還是 freedom 直連。網域什麼時候解析成 IP，由「設定」裡的「網域解析策略」控制：選 IPIfNonMatch 時先用網域比對規則，比對不上才發起解析，能省掉一次無謂的 DNS 查詢；選 AsIs 則完全依網域比對；選 IPOnDemand 只在遇到 IP 規則時才解析。
{
"inbounds": [
{ "tag": "socks", "listen": "127.0.0.1", "port": 10808, "protocol": "socks", "settings": { "udp": true } },
{ "tag": "http", "listen": "127.0.0.1", "port": 10809, "protocol": "http" }
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{ "type": "field", "outboundTag": "direct", "ip": ["geoip:private"] },
{ "type": "field", "outboundTag": "direct", "domain": ["geosite:cn"] }
]
}
}上面截取的是入站與路由兩段，outbounds 與具體節點由匯入的訂閱產生。可以看到 TUN 模式沒有新增協定：網卡裡出來的流量最終仍然走 10808 這個 SOCKS 入站，握手與加密方式完全由節點決定，VMess、VLESS、Trojan、SS 都一樣。
開啟 TUN 模式的操作順序
下面的順序對應 v2rayNG 1.9.x 的繁體中文介面。個別版本的選單文案有一兩個字差異，步驟本身不變。
- 先匯入訂閱並確認節點可用。在節點列右側選單執行「測試真連線延遲」，延遲顯示 -1 的節點代表握手失敗，先換一個能通的，避免把節點問題誤判成 TUN 的問題。
- 打開側邊欄 →「設定」，確認連線方式為 VPN（TUN）模式。v2rayNG 用 VpnService 建立虛擬網卡，部分版本這裡是一個「VPN 模式」開關，部分版本沒有獨立開關、點連線直接走 VpnService，不影響後續步驟。
- 側邊欄 →「路由設定」→「預先定義規則」，選「繞過區域網路與中國大陸」。內網裝置與中國大陸站點走 direct，只有需要代理的流量進節點。
- 「設定」→「網域解析策略」選 IPIfNonMatch。這個選項決定網域在規則比對的哪個階段被解析，後面驗證 DNS 時會用到。
- 需要依 App 控制時，進「設定」→「分應用程式代理」，打開開關並選擇「僅代理所選應用程式」或「繞過所選應用程式」，在應用程式清單裡勾選目標 App。
- 返回主畫面點連線。首次會彈出系統的「連線要求」對話框，點「允許」；之後狀態列出現 VPN 鑰匙圖示，通知列出現 v2rayNG 的執行通知，接管開始。
分應用程式代理和 TUN 是同一層機制
分應用程式代理不是第二條通道。它和 TUN 用的是同一個 VpnService，允許清單與排除清單由系統在 VPN 層過濾，被排除的 App 流量根本不會進虛擬網卡，自然也不會進 Xray。所以「開了 TUN 再開分應用程式代理」不會形成雙重代理，只是把接管範圍縮小。
權限與背景存活
授權在系統層，存活卻取決於廠商的行動裝置後台策略。中國大陸品牌 ROM 常在螢幕關閉幾分鐘後回收 VPN 服務，表現是狀態列鑰匙圖示消失、流量統計停止增加、重新打開應用程式時連線狀態已經回到未連線。
- 電池：系統「設定」→「應用程式」→「v2rayNG」→「電池」，選「不受限制」或關閉電池最佳化。
- 自啟動：在「自啟動管理」裡允許 v2rayNG 自啟，並在最近使用的應用程式清單中給它加鎖，避免一鍵清理時被關掉。
- 背景彈出介面：v2rayNG 彈出「連線要求」時不能被系統攔截，允許這項權限可以減少授權失敗。
- 永遠開啟的 VPN：Android 7.0 起在「設定」→「網路與網際網路」→「VPN」裡有「永遠開啟的 VPN」，可把 v2rayNG 設為常駐，斷線後由系統重新拉起。
- 封鎖沒有 VPN 的連線：同一頁面裡的這個選項會讓所有流量在 VPN 中斷時被切斷，除錯階段先別開，否則排查時會把斷網原因搞混。
結論：先設背景，再查規則
同一份設定在不同手機上表現不一致，多數來自背景存活策略而不是核心。把電池不最佳化、自啟動、背景鎖定三項設好並觀察一天，再回頭排查 DNS 與路由規則，順序反過來會浪費大量時間。
驗證接管範圍
連線狀態只說明 VpnService 建鏈成功，不說明流量真的進了核心。用三個可重現的檢查確認接管範圍。
- 出口位址比對：先用瀏覽器造訪一個顯示出口 IP 的頁面，記下直連時的結果；連上 TUN 後再存取同一頁面，IP 應變成節點所在地區的位址，電信業者欄位也隨之改變。
- 分應用程式代理反證：在「分應用程式代理」裡把某個 App 設為繞過，重開該 App 後它應顯示本機 IP；把勾選取消再重開，它應顯示節點 IP。兩次結果不同，說明 TUN 的 App 層過濾生效。
- 流量統計：打開「設定」→「啟用流量統計」，連線後在統計頁看上下行是否隨瀏覽增加；數字不動說明流量沒有進核心。
常見問題與排查
中斷 v2rayNG 後狀態列鑰匙圖示還在？
鑰匙圖示由系統 VPN 框架繪製。先在 v2rayNG 主畫面點一次中斷，圖示會隨 VpnService 一起消失；如果仍然存在，去系統「設定」→「網路與網際網路」→「VPN」查看是否有其它設定處於連線狀態，逐一中斷。
開了 TUN，某個 App 還是顯示本機 IP？
先看「設定」→「分應用程式代理」：模式選成「繞過所選應用程式」時，清單裡被勾選的 App 就是不走代理的；模式選成「僅代理所選應用程式」時，沒勾的 App 不走代理。兩種模式各檢查一遍，再重開該 App 複測。
瀏覽器外掛裡還填著 127.0.0.1:10808，要改嗎？
建議清掉。留著的話請求會先被外掛送進本機入站，繞過 TUN 的 App 層過濾——如果分應用程式代理把瀏覽器排除了，外掛這一層卻仍在代理，排查時會得出互相矛盾的結論。
點連線時系統彈出「連線要求」，點了取消還會再彈嗎？
會。下次點連線會重新要求授權，不會因為取消一次就永久拒絕。如果彈窗完全不出現，去系統 VPN 清單裡刪除 v2rayNG 的項目再連一次，授權流程會重新走一遍。
TUN 模式比本機代理耗電嗎？
會多一些。多出來的開銷是 tun2socks 的使用者空間轉送與一次記憶體複製，長時間掛在背景時更明顯。只在瀏覽器裡用時把 TUN 關掉，或者用分應用程式代理把範圍縮小到必要的 App。
排查順序建議固定下來：先看背景是否存活，再看路由規則是否把目標流量直連，最後看 DNS 解析位置。三步都走過一遍仍然不通，再回到節點本身做一次真連線延遲測試。