v2rayN TUN 模式設定教學：虛擬網卡接管全域流量

一、TUN 虛擬網卡和系統代理有什麼不同？

系統代理會提供代理入口給應用程式使用。瀏覽器等遵循系統設定的軟體，會將請求傳送至本機代理連接埠；自行建立連線或忽略系統設定的軟體，則可能繼續直接連線。因此，「瀏覽器能連線，命令列工具卻不行」不一定是節點故障，也可能是兩者使用了不同的網路路徑。

TUN 會在系統網路層建立虛擬介面，並透過路由將符合條件的 IP 封包交由處理核心處理。應用程式通常不必另外填寫代理位址。這裡所說的「全域接管」指的是流量涵蓋範圍，不代表所有連線都必須經過遠端節點：進入 TUN 的連線仍可依規則直連、代理或封鎖。

v2rayN 負責介面、產生設定和管理程序，實際流量轉送則由核心處理。常見桌面版本透過 sing-box 實作 TUN，實際搭配會依版本與設定而異；不能將「TUN 已啟用」理解為 Xray 的所有功能都會自動生效。VMess、VLESS 是節點協定，REALITY 是安全傳輸方案；它們都不是虛擬網卡驅動程式，也不必因為切換至 TUN 而重新產生訂閱。

二、啟用前先確認節點、權限與本機代理入口

先關閉 TUN，透過系統代理確認節點能正常開啟 HTTPS 網頁。節點本身無法使用時，新增虛擬網卡只會讓排查多出變數。匯入訂閱請參考訂閱設定教學；若連線失敗，請先依照故障排除中的方法檢查記錄。

1. 記下目前設定：記錄目前使用的節點、路由模式、本機監聽連接埠及自訂 DNS。若設定中包含訂閱網址或節點憑證，請只保存在本機，勿公開分享。
2. 關閉其他網路接管工具：暫時中斷其他 VPN 連線，並關閉會修改預設路由的工具。若企業遠端存取有使用規範，請先確認是否允許調整網路設定。
3. 確認執行權限：在 Windows 完全結束 v2rayN，按右鍵點選程式，選擇「以系統管理員身分執行」，再確認授權提示。關閉視窗可能只是將程式縮至系統匣，請從系統匣選單結束程式。
4. 確認程式檔案：若記錄顯示缺少 TUN 相關核心或驅動程式檔案，請使用符合系統架構的完整發行套件，勿從不明來源單獨下載動態連結程式庫。

這三個數字分別用來辨識本機代理入口、網域名稱解析和網站連線，並非需要全部開放的防火牆連接埠。尤其不要為了排查問題，將本機監聽位址從 127.0.0.1 改成 0.0.0.0；TUN 接管本機應用程式流量，不需要將代理入口公開給區域網路。

三、v2rayN 啟用 TUN 的操作步驟

不同桌面版本的設定位置可能不同。常見介面可在「設定」→「參數設定」中尋找「TUN 模式設定」，主視窗也可能直接提供「啟用 TUN」開關。請依照功能名稱操作；若介面中沒有相應選項，先確認目前版本與平台，勿照著其他版本的截圖修改不熟悉的欄位。

1. 選取已確認可用的節點。確認目前使用的節點正確，且透過系統代理測試網頁已成功。
2. 先確保只有一條流量路徑。先將系統代理切換為「清除系統代理」，並讓用戶端核心繼續執行。此時暫時無法連線至代理目標是預期情況，下一步再交由 TUN 接管。
3. 保留 TUN 預設參數。首次啟用時，不要同時修改協定堆疊、MTU、介面名稱和 DNS 策略。先使用目前版本的預設設定，建立可重複測試的基準。
4. 啟用「TUN 模式」。查看記錄是否出現建立介面、啟動核心或初始化路由的訊息。開關顯示已啟用只代表介面狀態，仍須實際測試連線。
5. 確認虛擬介面已建立。在 Windows 開啟「設定」→「網路和網際網路」→「進階網路設定」查看網路介面卡；也可執行下方的唯讀命令檢查。
6. 確認正常後再調整。確認網頁與目標應用程式都能連線後，再逐項恢復自訂路由。每次變更後都測試一次，避免一次修改多個變數。

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 20 DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

請在 PowerShell 中執行以上命令；這些命令只會讀取網路介面卡與路由資訊。不同核心建立的介面名稱可能不同，路由接管也可能使用多個更明確的前綴，不能只靠是否出現一條 0.0.0.0/0 判斷是否成功。請一併檢查介面狀態、啟動記錄及實際連線記錄。

四、路由分流與 DNS 必須一併設定

啟用 TUN 接管後，仍應保留合理的分流設定。區域網路裝置、公司內網和節點伺服器本身的連線都需要正確的出口；若一律將所有位址送回代理入口，可能造成路由迴圈。常見版本會處理代理出口的介面選擇或繞行，但自訂設定、多張虛擬網卡和複雜的策略路由仍可能破壞這項設定。

DNS 常見的陷阱是循環依賴：連線至節點前，必須先解析節點網域名稱；但該解析請求又被設定為必須經過該節點。解決方式是為節點網域名稱提供可用的初始解析路徑，而不是反覆更換公用 DNS 位址。使用加密 DNS 時，也要考慮如何在初始階段解析 DNS 伺服器本身的網域名稱。

• 區域網路範例：若印表機位址是 192.168.1.50，請確認所在網段 192.168.1.0/24 使用本機網路直連；不能只新增印表機名稱，卻忽略名稱解析結果。
• 應用程式內建 DNS：瀏覽器的安全 DNS 可能透過獨立的 HTTPS 請求連線，不能假設接管 53 連接埠的 DNS 流量就已涵蓋這類請求。排查時請記下瀏覽器設定，必要時暫時改用系統 DNS 解析。
• IPv6 範例：若網域名稱回傳 AAAA 記錄，但網路沒有可用的 IPv6 出口，可能會發生等待一段時間後才切換的情況。請先確認網路是否支援 IPv6，再調整用戶端的 IPv6 策略，勿只修改系統網路介面卡設定。

五、確認 TUN 確實生效，不只看開關

測試時必須確認「成功接管」和「正確分流」兩件事。先確認系統代理已清除，目標應用程式也沒有手動設定代理，再連線至已知可用的網站。否則瀏覽器成功連線，可能只是沿用原有的代理入口，無法證明 TUN 已成功接管流量。

1. 測試 HTTPS：開啟可連線的 HTTPS 網站，查看用戶端記錄是否出現相應連線。網頁快取可能掩蓋斷線問題，必要時請重新整理從未開啟過的頁面。
2. 測試目標程式：開啟原本不會讀取系統代理設定的應用程式，確認連線結果並查看連線記錄。若應用程式在虛擬機器或容器中執行，不能假設主機的 TUN 也會接管其獨立網路。
3. 測試分流：分別連線至應直連的內網位址和應使用代理的網域名稱，比對記錄中的規則與出口。查詢公網 IP 只能反映該次查詢請求的路徑，不能代表所有應用程式的流量。
4. 測試 UDP：只有在確實需要時，才檢查目標應用程式的 UDP 功能。TCP 網頁正常不代表 UDP 一定可用，伺服器端策略或節點傳輸能力仍可能有所限制。

curl.exe --noproxy "*" -I --connect-timeout 10 https://example.com/

不要只根據一次延遲測試就判斷連線速度。節點清單中的延遲通常只反映特定的探測方式，不等於影片傳輸速度或遊戲往返延遲。進行對照測試時，請保持節點、網路與目標一致，只切換系統代理和 TUN，才能判斷差異來自哪一層。

六、啟用 TUN 後無法連線的常見問題

七、適用情境與安全退出步驟

如果只有瀏覽器需要代理，通常使用系統代理就足夠，也不必設定太多項目。若多個桌面應用程式不讀取系統設定、需要統一分流，或應用程式確實需要 UDP，再考慮使用 TUN。TUN 擴大的是網路接管範圍，不會提高節點頻寬，也不會自動解決伺服器無法連線、訂閱過期或協定參數錯誤等問題。

• 正常退出：先關閉 TUN，等待核心撤除相關路由，再從系統匣結束 v2rayN。若要繼續使用系統代理，請重新啟用相應模式。
• 程式異常結束後：重新啟動用戶端，開啟再關閉一次 TUN，讓程式完成清理；同時檢查 Windows「設定」→「網路和網際網路」→「Proxy」中是否還留有手動代理設定。
• 仍無法恢復連線：保留記錄並重新啟動系統，再檢查實體網路。勿直接照抄網路上的批次刪除路由命令，以免移除公司內網或其他必要連線。
• 設定完成後：記錄可用節點、路由模式、DNS 策略和測試結果。日後更新或更換網路時若發生問題，即可依照這份基準逐項檢查。

判斷標準很明確：清除系統代理後，目標應用程式仍能依預期連線；應直連的目標維持直連；退出後系統網路恢復正常。確認這三點後再逐步新增自訂規則，比一開始採用複雜設定更容易維護。