v2rayN TUN 模式原理與啟用步驟：接管全域流量的正確做法

TUN 模式與系統代理的接管範圍

系統代理本質上是向作業系統登記 HTTP 或 SOCKS 代理位址，例如 v2rayN 常見的本機混合連接埠 127.0.0.1:10808。瀏覽器與遵循系統代理設定的桌面程式會將請求交給該連接埠，但自行建立連線、固定使用直連或不讀取系統代理的程式可能繞過它。因此，啟用系統代理不代表所有處理程序的網路流量都會進入 Xray 核心。

TUN 模式會建立一張虛擬三層網卡，並透過系統路由將目標流量送入這張網卡。客戶端讀取 IP 封包後還原連線資訊，再交由分流規則判斷應使用代理、直連或阻斷。應用程式通常不需要個別填寫代理位址，因此遊戲平台、命令列工具及使用自訂網路堆疊的軟體也更容易受到統一接管。

兩種模式並非單純的強弱關係

• 系統代理：變更範圍較小，啟用與退出都更直接，適合瀏覽器、辦公軟體及明確支援代理設定的程式。
• TUN 模式：接管範圍更完整，需要建立虛擬網卡、寫入路由並取得提升後的權限，適合無法個別設定代理或需要統一分流的應用程式。
• 全域流量：表示流量會先進入 TUN 接管鏈路，不代表所有目標都必須經由遠端代理；最終出站仍由路由規則決定。
• 本機迴路：127.0.0.0/8、區域網路位址與客戶端自身連線需要正確排除，避免形成代理套代理的迴圈。

要判斷是否需要 TUN，可以先關閉系統代理並測試目標程式。如果程式完全不受系統代理開關影響，但業務又要求其流量接受統一規則，TUN 才是較合適的處理方式。日常只使用瀏覽器時，沒有必要僅為了「全域」字樣增加虛擬網卡與路由層。

啟用前檢查版本、節點與連接埠

排查順序應從節點可用性開始，而不是直接反覆切換 TUN。先在一般系統代理模式下選擇一個節點，開啟可存取的測試頁面，並確認 v2rayN 核心記錄中沒有驗證失敗、TLS 交握失敗或連線逾時。節點本身不可用時，TUN 只會擴大故障範圍。

以下數值可作為 v2rayN 7.15.x 桌面環境的檢查基準。不同小版本可能調整選單名稱或自動產生的網段，但連接埠占用、預設路由與 DNS 接管的判斷方法一致。

1. 在伺服器清單中雙擊已驗證可用的 VMess 或 VLESS 節點，使其成為作用中伺服器。
2. 進入「設定」→「參數設定」，確認本機監聽連接埠沒有與其他代理程式重複。若記錄出現 address already in use，應先結束占用連接埠的處理程序，或將本機連接埠改為尚未使用的值。
3. 校正系統日期、時間與時區。TLS 與 Reality 連線依賴合理的系統時間，明顯偏差會導致交握階段失敗。
4. 記錄目前的網路狀態，包括正在使用的網卡、預設閘道與 DNS 位址。如此在異常結束後，可以判斷殘留的是路由、DNS 還是虛擬網卡。
5. 暫時退出其他會建立虛擬網卡或修改預設路由的網路工具，避免兩套接管規則爭奪優先順序。

v2rayN TUN 設定中的關鍵參數

在 v2rayN 7.x 中，可從「設定」→「參數設定」進入 TUN 相關設定，儲存後回到主介面啟用「TUN 模式」。部分版本會將開關放在主視窗上方或系統匣選單中，但操作結果相同：啟動具備 TUN 入站能力的核心、建立虛擬網卡並寫入路由。

參數不宜一次變更過多。第一次測試建議保留自動路由與自動偵測介面，只調整確實存在衝突的項目。成功建立基礎鏈路後，再處理 MTU、嚴格路由與 DNS 策略，能更快定位是哪一項導致連線異常。

啟用後的確認步驟

1. 儲存參數並返回主介面，保持一個可用節點處於選取狀態。
2. 啟用 TUN 模式，接受系統權限要求，等待狀態列顯示核心運作正常。
3. 檢查核心記錄，應能看到 TUN 介面建立與路由寫入資訊，不應連續出現 permission denied 或 route add failed。
4. 關閉瀏覽器中的手動代理設定，再存取測試目標，確認請求仍可依規則連通。
5. 測試一個明確設定為直連的網域和一個設定為代理的網域，驗證 TUN 接管與路由分流同時生效。

Windows、macOS 與 Linux 的權限差異

TUN 需要操作網路介面與系統路由，一般使用者權限通常不足。三個桌面平台的目標一致，但授權方式不同。權限不足時，典型現象是開關自動恢復、虛擬網卡未出現，或記錄在建立介面階段直接報錯。

Windows 的建議操作順序

1. 完全退出舊版 v2rayN 程序，再啟動目前版本，避免兩個核心同時監聽 10808。
2. 先連線節點並測試系統代理，再啟用 TUN，出現權限確認時完成授權。
3. 若虛擬介面存在但沒有流量，開啟系統路由資訊，檢查是否存在指向實體閘道且優先順序更高的預設路由。
4. 退出 TUN 後確認虛擬介面與暫時路由已清除，再決定是否重新安裝或重設相關驅動程式。

macOS 與 Linux 的額外檢查

• macOS 使用多個網路服務時，應確認目前實際對外連線的是無線網路還是有線網路，自動介面偵測結果必須與實際出口一致。
• Linux 桌面環境可能由 NetworkManager 或 systemd-resolved 管理 DNS；TUN 已接管路由但網域解析失敗時，應個別檢查解析鏈路。
• 休眠、切換網路或從有線網路切換至無線網路後，原本的預設介面可能失效。此時關閉再啟用 TUN，讓客戶端重新偵測出口。
• 容器與虛擬機網路通常使用獨立私有網段，若與 TUN 位址重疊，應先修改 TUN 網段，而不是新增更多預設路由。

啟用 TUN 後路由表發生了什麼

直接用一條新的預設路由覆蓋原本的閘道，可能讓代理核心本身也被送回 TUN，形成迴圈。實際實作通常會保留實體出口，並將 IPv4 預設空間拆成兩條更具體的路由，例如 0.0.0.0/1 與 128.0.0.0/1。由於前綴較長，這兩條路由會優先於原本的 0.0.0.0/0，一般應用程式流量進入 TUN，而核心連往遠端伺服器的連線則透過排除規則走實際閘道。

以下是用於理解結構的簡化輸出，不代表每台裝置都會使用相同的介面名稱與閘道。重點是辨識「原本的預設閘道仍在」以及「更具體的接管路由指向 TUN」這兩項特徵。

目標網路          閘道或介面
0.0.0.0/0         192.168.1.1
0.0.0.0/1         tun0
128.0.0.0/1       tun0
192.168.1.0/24    本地實體網卡
127.0.0.0/8       本機迴路

DNS 也需要配合路由方向。若網域先由本地網路解析，但連線隨後透過代理出站，可能取得不適合該出口的位址；反過來，所有 DNS 都經由代理，又可能無法解析區域網路主機名稱。較穩妥的做法是讓代理網域使用遠端解析，讓區域網路與明確直連的網域使用本地解析，並確保 DNS 查詢本身不會繞過既定出站。

TUN 與 Xray 路由分流如何配合

TUN 解決的是「流量如何進入客戶端」，Xray 路由解決的是「進入後從哪個出站離開」。將 TUN 視為全代理開關，會忽略分流規則的作用。日常設定至少需要區分代理、直連與阻斷三類結果，並將高優先順序的特殊規則放在通用規則之前。

例如，區域網路位址與裝置管理頁面應優先直連；需要代理的網域集合再指向代理出站；廣告或明確不需要存取的網域可進入阻斷出站；其餘流量最後由預設策略兜底。規則會依順序比對，前面已命中的連線不會繼續執行後面的規則。

建議的規則優先順序

1. 客戶端本身與節點位址：必須透過實際實體出口連線，避免核心連線再次進入 TUN。
2. 迴路與區域網路：127.0.0.0/8、常用私有位址範圍及本地裝置網域通常設定為直連。
3. 阻斷規則：對明確需要拒絕的網域或協定使用 block 出站，減少無效連線。
4. 代理規則：依網域集合、目標位址、連接埠或協定進行比對，並傳送至目前的代理出站。
5. 預設規則：最後決定未命中項目使用 direct 還是 proxy，避免出現沒有出站結果的連線。

修改規則後，應分別測試網域請求與直接 IP 請求。只有網域失敗時，優先檢查 DNS 與網域規則；網域和 IP 都失敗時，優先檢查節點、路由表與權限；只有某個區域網路裝置無法存取時，則檢查私有位址範圍是否被誤送至代理出站。

常見故障與逐項復原方法

TUN 故障應依「權限與介面、路由、DNS、MTU、分流規則」的順序處理。一次只修改一項，並在每次調整後重新建立連線。若同時更換節點、修改 DNS、降低 MTU 及重新排列規則，即使網路恢復，也無法確定真正原因。

最小化排錯清單

• 系統代理模式下的節點是否已驗證可用。
• TUN 虛擬介面是否成功建立，記錄中是否出現權限錯誤。
• 原本的實體預設閘道是否保留，接管路由是否指向正確介面。
• 直接存取 IP 與透過網域存取的結果是否不同。
• 區域網路、迴路位址與節點伺服器位址是否已正確排除。
• 將 MTU 調整至 1500 後，大型檔案傳輸與登入請求是否恢復。
• 關閉 TUN 並退出客戶端後，暫時路由與 DNS 設定是否已撤銷。

確認基礎鏈路穩定後，再逐步啟用嚴格路由、細化 DNS 規則或增加分流條件。對於只需要瀏覽器代理的環境，系統代理通常更便於維護；對於多個不讀取代理設定的桌面程式，TUN 搭配清晰的 direct、proxy 與 block 規則，才能實現可控的全域流量接管。