V2Ray Windows版新手到進階指南

核心概念：用戶端、核心與代理設定

先釐清三個層次，再開始操作

v2rayN、v2rayNG 與 v2flyNG 都是圖形化用戶端。用戶端負責儲存伺服器資料、管理訂閱、產生核心設定，並提供系統代理、路由、日誌等操作入口。Xray 或 V2Fly 則屬於代理核心，負責依照設定建立連線、處理協定與傳輸，以及執行網域名稱和 IP 路由。兩者不能混為一談：點擊用戶端中的「啟動」，並不代表圖形介面親自處理所有網路流量，而是用戶端整理設定後呼叫核心。排錯時，應先判斷問題發生在介面管理、核心啟動、遠端設定，還是應用程式根本沒有接入本機代理。

第三層是代理設定，描述伺服器位址、連接埠、使用者識別碼、協定、傳輸、TLS、路由與 DNS 等參數。用戶端只是這些資料的管理工具，設定能否使用取決於各欄位是否彼此匹配。訂閱是批次分發設定的一種方式，不等同於用戶端，也不等同於核心。訂閱更新成功，只代表用戶端取得並解析了內容；這並不能直接證明其中每個設定都能建立連線。反過來，訂閱更新失敗也不代表本機核心損壞，可能只是訂閱網址、網路入口或回應格式有問題。

一次請求會經過哪些環節

以瀏覽器瀏覽網頁為例，完整路徑通常是：瀏覽器讀取系統代理設定，將請求交給 v2rayN 的本機 HTTP 或 SOCKS 監聽連接埠；核心依照路由規則選擇直連或代理出口；若選擇代理出口，再依據伺服器設定建立遠端連線。任一環節中斷，表面上都可能只是「網頁無法開啟」。因此不應一開始就反覆更換設定。先確認本機監聽是否存在，再確認應用程式是否將流量送至該監聽連接埠，接著查看核心日誌是否收到請求，最後才檢查遠端參數與網路條件。

系統代理與路由分流也屬於不同層次。系統代理回答「哪些遵循系統設定的應用程式會將請求交給用戶端」，路由規則回答「核心收到請求後使用哪個出口」。如果終端機程式沒有讀取系統代理，修改十次路由規則也不會改變結果，因為請求從未進入核心。同樣地，開啟 TUN 只是擴大接入範圍，不會自動修正錯誤的伺服器位址、TLS 參數或使用者識別碼。釐清這條界線，是後續設定互不干擾的基礎。

建立可回復的學習環境

首次設定時只保留一個來源可靠的伺服器設定，暫時使用預設路由，不立即啟用 TUN，也不要同時修改 DNS。先讓瀏覽器透過系統代理完成一次可重複的驗證，再逐項增加功能。每完成一個階段，記錄用戶端中的關鍵選項、本機連接埠與目前的設定名稱。如此即使後續分流規則有誤，也能退回「單一設定、預設路由、系統代理」的基線，而不必重新安裝用戶端。重新安裝通常只會清理介面或檔案，不能自動修正訂閱內容、遠端參數與應用程式本身的代理設定。

選擇用戶端：依平台與核心需求判斷

桌面平台優先使用 v2rayN

Windows、macOS 與 Linux 的主要選擇是 v2rayN。它提供桌面圖形介面，統一管理訂閱、設定、系統代理、路由、DNS、TUN 與日誌。Windows 下載頁同時提供桌面版與經典 WPF 版：桌面版採用跨平台介面，適合希望在不同桌面系統維持相近操作邏輯的使用者；經典 WPF 版採用 Windows 原生桌面技術，適合已熟悉傳統 v2rayN 操作位置的使用者。兩者都是用戶端選擇，不應與協定或核心類型混為一談。

選擇桌面套件時，還要核對處理器架構與套件格式。常見的 Windows 桌面裝置選擇 x64；macOS 需要先確認裝置使用 Apple Silicon 還是 Intel 晶片；Linux 除了 x64 與 arm64 外，也應依發行版選擇 deb 或 rpm。架構不相容通常會表現為安裝程式無法啟動、系統提示不支援該格式，或程式啟動後立即退出。這類問題發生在用戶端執行層，與訂閱網址和伺服器設定無關，應先返回用戶端下載頁重新確認平台入口。

在 v2rayNG 與 v2flyNG 之間選擇 Android 用戶端

Android 首選 v2rayNG。它以 Xray 核心作為主要執行元件，適合需要常見協定、路由與分應用程式代理設定的情境。v2flyNG 使用 V2Fly 核心，可作為明確需要 V2Fly 行為或已有對應設定流程時的備選。兩款應用程式的介面與設定位置並不完全相同，同一份訂閱能否匯入也要看設定欄位與核心能力，不應只因名稱相近，就假設所有選項都能一一對應。

Android 下載套件通常分為 arm64 與通用版。較新的主流手機通常使用 arm64，無法確認架構時再選擇通用版。安裝完成後，系統在首次啟動 VPN 接入時會顯示授權提示；該授權用於建立本機虛擬網路介面，是應用程式接管流量所需的系統機制。若裝置中已有其他 VPN 類連線處於啟用狀態，應先結束衝突連線，因為系統通常只允許一個此類介面同時生效。背景執行還會受到省電策略影響，這部分應在連線基線正常後再處理。

不要以功能數量取代實際需求

選擇用戶端應從三個問題開始：裝置平台是什麼、現有設定需要哪類核心能力，以及應用程式準備透過哪種方式接入。若主要需求是 Windows 瀏覽器與一般桌面程式，v2rayN 搭配系統代理通常已經足夠；若 Android 需要分應用程式代理，可在 v2rayNG 中設定納入或排除範圍；只有遇到不讀取系統代理的程式，才進一步評估應用程式本身的代理參數或 TUN。先用最小方案滿足需求，維護成本會明顯低於一開始同時啟用所有進階功能。

從舊用戶端遷移時，優先重新匯入訂閱或標準分享設定，不要直接搬移整個程式目錄。舊目錄可能包含過期的路由檔案、連接埠設定、日誌與介面狀態，複製後容易把歷史問題一併帶入。遷移完成後，先選擇單一設定並確認本機監聽，再逐項恢復分流規則。伺服器設定屬於敏感連線資料，應只儲存於受控裝置與可靠的備份位置；截圖或排錯記錄中應遮蓋訂閱網址、使用者識別碼與驗證資訊。

如果仍無法確定，可先閱讀用戶端比較。確定平台與用戶端後再進入安裝階段，避免將錯誤架構、錯誤套件格式造成的啟動失敗誤判為訂閱或網路故障。

安裝與首次啟動：先確認核心與監聽連接埠

Windows 的安裝與目錄界線

在 Windows 上取得與系統架構相符的 v2rayN 套件後，依下載頁標示的套件類型完成安裝或解壓縮。若使用需要解壓縮的形式，應放在目前帳戶具備讀寫權限的固定目錄，不要長期從壓縮檔預覽視窗或暫存下載目錄執行。用戶端需要儲存設定、更新元件並寫入日誌，目錄權限不足時可能出現介面能開啟但設定無法持久保存、核心無法釋放，或更新後檔案遺失等現象。

首次啟動後先不要匯入大量訂閱。開啟用戶端的設定或日誌區域，確認核心程序可以被呼叫，並記錄本機 HTTP 與 SOCKS 監聽位址。常見監聽位址使用迴路介面 127.0.0.1，表示只允許本機程式存取；連接埠由用戶端設定決定，不應將教學中的範例連接埠視為目前裝置的固定值。若系統防護工具跳出網路存取提示，應依本機使用範圍判斷，不需要為了本機迴路代理而將監聽暴露至公用網路。

macOS、Linux 與 Android 的首次授權

macOS 首次執行下載的應用程式時，系統可能要求確認應用程式來源或授予網路設定相關權限。完成授權後，應檢查選單列或用戶端介面中的系統代理操作是否能寫入目前的網路服務。切換 Wi-Fi、有線網路或其他網路服務後，可能需要重新確認系統代理狀態，因為不同網路服務可以各自儲存設定。Linux 的桌面環境對系統代理的支援並不完全一致；部分應用程式會讀取桌面代理設定，部分命令列程式只讀取自身參數或環境變數，因此「用戶端已執行」與「所有程式都已接入」仍是兩回事。

Android 首次連線時需要確認系統 VPN 授權。授權後，狀態列出現系統提供的 VPN 標誌，只代表虛擬介面已建立，不代表遠端設定一定可用。應先選取一個設定，觀察用戶端是否出現明確錯誤，再用瀏覽器進行基本存取測試。若應用程式切換至背景後很快斷線，應檢查電池最佳化、背景活動權限與系統任務清理策略；若只有部分應用程式無法連線，則繼續檢查分應用程式代理範圍，而不是反覆重新安裝。

1. 確認用戶端本身可以穩定啟動 關閉重複開啟的同名程序，再啟動一個執行個體。若介面立即消失，先檢查系統架構、執行權限與用戶端日誌，不要處理訂閱。
2. 確認核心已正常呼叫 在日誌中尋找設定解析、監聽失敗或權限相關資訊。此階段只判斷本機執行鏈，不要以網頁存取結果取代核心檢查。
3. 確認本機連接埠處於監聽狀態 記錄 HTTP、SOCKS 或混合監聽的實際連接埠。後續瀏覽器、終端機與系統代理都必須指向相同的連接埠類型。
4. 儲存一份初始設定記錄 記錄用戶端類型、核心選擇、監聽位址、連接埠，以及是否啟用系統代理，作為後續排錯的基線。

Windows 查看指定連接埠是否處於監聽狀態，範例連接埠為 10809：

netstat -ano | findstr :10809

如果命令沒有結果，表示該連接埠目前沒有監聽，或實際連接埠並非範例值；應回到用戶端查看本機監聽設定。如果結果顯示連接埠已被其他程序佔用，可根據最後一欄的 PID 在工作管理員中定位程序。重複啟動 v2rayN、其他本機代理程式或開發工具都可能產生衝突。詳細處理步驟可參考v2rayN 本機連接埠被佔用的排查方法。

首次連線只驗證最短路徑

完成本機檢查後，匯入一個設定並選取它作為使用中的項目。先使用用戶端預設路由與預設 DNS，不要啟用複雜規則。開啟系統代理後，使用明確讀取系統代理的瀏覽器瀏覽一般 HTTPS 頁面，同時觀察日誌是否出現對應的網域請求。如果瀏覽器有請求但連線失敗，問題進入遠端設定或網路層；如果日誌完全沒有請求，重點檢查瀏覽器是否使用獨立代理、系統代理是否成功寫入，以及連接埠是否一致。

驗證結束後主動測試「清除系統代理」。關閉用戶端前先恢復系統代理，避免作業系統仍指向已停止的本機連接埠。若用戶端異常退出後所有網頁都無法存取，第一步也應檢查並清除殘留的系統代理，而不是立即修改 DNS。安裝階段的目標不是開啟全部功能，而是建立一個可啟動、可監聽、可接入、可退出的本機基線。

訂閱與設定管理：區分取得、解析與連線

訂閱更新包含三個獨立結果

訂閱更新至少經過位址存取、內容解析與設定寫入三個階段。用戶端首先存取訂閱網址；取得回應後，再判斷內容格式並解析設定；最後將有效項目寫入對應分組。只有三個階段都完成，清單才會更新。若提示網路請求失敗，應檢查訂閱網址能否從目前網路存取、系統時間是否正確，以及用戶端更新訂閱時是否使用合適的網路路徑。若提示解析失敗，則應關注回傳內容是否為用戶端支援的格式，而不是繼續更換本機連接埠。

訂閱網址本身通常具有存取權限，應視為敏感資料。不要將完整網址放進公開截圖、日誌附件或瀏覽器同步筆記。新增訂閱時，為它設定清楚的分組名稱，例如依用途或來源命名，而不要只寫「訂閱一」、「訂閱二」。分組名稱不會改變連線行為，但能協助後續判斷哪次更新覆蓋了哪些設定。多個來源混在同一組時，一旦出現同名項目或欄位差異，很難確認問題來自哪一側。

匯入後的檢查不只是「清單中出現了」

設定進入清單後，至少要核對協定類型、伺服器位址、連接埠、傳輸方式、TLS 狀態與伺服器名稱等關鍵欄位。使用者識別碼等驗證資料可以不在日常介面完整顯示，但其存在與格式必須正確。VLESS、VMess 等協定名稱只描述設定的一部分；WebSocket、gRPC、TCP 等傳輸方式，以及 TLS、SNI、路徑或服務名稱仍需相互匹配。只將協定欄位改成相同名稱，無法修正其他欄位不一致的問題。

批次測試的結果只能作為篩選線索。測試失敗可能來自目前網路、遠端狀態、測試目標或 DNS；測試成功也不代表所有應用程式都已正確接入。更可靠的方法是選取一個設定，維持預設路由，用瀏覽器發起實際請求，並結合核心日誌判斷。針對同一問題同時輪換多個設定，會讓日誌與系統代理狀態頻繁變化，不利於確認因果。

1. 新增訂閱並命名分組 從用戶端的訂閱管理入口新增網址，確認開頭與結尾沒有空格或換行。儲存後只更新剛加入的分組，方便辨識回傳結果。
2. 查看更新提示與分組變化 區分請求失敗、解析失敗，以及寫入後沒有有效項目。不同階段需要檢查的對象不同，不要一律歸因於核心。
3. 選擇單一設定核對欄位 確認協定、位址、連接埠、傳輸與 TLS 相關欄位完整，再設為使用中的設定並啟動核心。
4. 保留最近可用的回復項目 更新前匯出或備份目前的設定資料庫。若來源內容發生變化，可快速判斷是更新引入的問題，還是本機環境變更。

更新失敗時按階段檢查

若用戶端顯示無法連線至訂閱網址，先確認網址是否完整，並檢查系統代理目前是否指向未執行的本機連接埠。在某些情況下，瀏覽器能夠存取並不代表用戶端的訂閱請求走相同路徑，因為兩者可能使用不同的代理設定。若回傳的是登入頁面、錯誤頁面或一般文字，用戶端通常會回報格式異常。此時應核對訂閱來源，而不是手動將網頁內容當作分享設定匯入。

若更新成功但清單為空，請檢查是否啟用了會過濾特定項目的分組設定，以及回傳內容是否包含目前用戶端可識別的設定。若清單更新後原有項目消失，先不要連續多次重新整理；查看該訂閱是否採用覆蓋更新，並從備份還原需要保留的手動項目。更完整的分類步驟可在訂閱更新常見問題中查閱，首次匯入的精簡流程則見快速入門的訂閱步驟。

手動設定適合精確核對

當只有單一設定或需要確認具體欄位時，可以使用用戶端的手動新增功能。填寫時從上到下逐項核對，不要根據相似名稱猜測。伺服器名稱用於 TLS 交握時，應與設定要求一致；傳輸路徑、Host、服務名稱等欄位也各有作用。出現憑證或 TLS 交握錯誤時，優先檢查系統時間、憑證有效期、網域匹配與 SNI，相關原理可參考TLS 交握與憑證錯誤排查。不應將關閉憑證驗證當作日常處理方式。

完成訂閱階段後，應能回答四個問題：設定來自哪個分組、目前使用中的項目是哪一個、核心使用哪類設定，以及本機監聽連接埠是什麼。只有這些資訊明確，下一階段的系統代理與應用程式接入測試才有可靠基礎。

代理模式與應用程式接入範圍

系統代理只涵蓋讀取系統設定的應用程式

v2rayN 中的「自動設定系統代理」通常會將作業系統代理位址指向用戶端的本機監聽連接埠。瀏覽器與部分桌面應用程式會讀取這項設定，因此無需另行設定即可接入。另一些程式擁有獨立的代理設定，或完全忽略系統代理，例如部分終端機命令、開發工具、遊戲平台與自帶網路堆疊的應用程式。系統代理已開啟但某個程式仍直接連線，並不代表 v2rayN 或核心失效，應先查明該程式的接入能力。

「清除系統代理」用於移除用戶端寫入的系統設定。當用戶端停止、本機連接埠變更，或準備切換到其他網路工具時，應先清除舊代理。若系統仍指向 127.0.0.1 的某個連接埠，但該連接埠沒有程序監聽，遵循系統代理的應用程式就會全部出現連線失敗。這類故障常發生在程式異常退出後，表面上像是整個網路無法使用，實際上只需恢復系統代理。

HTTP 與 SOCKS 連接埠不能任意互換

本機 HTTP 代理適合明確支援 HTTP 代理的應用程式，SOCKS 代理則透過 SOCKS 協定轉送連線。用戶端可能提供獨立連接埠，也可能提供相容多種接入方式的混合連接埠。應用程式填寫時必須與監聽類型一致：將 SOCKS 連接埠填入只接受 HTTP 代理的欄位，通常會得到協定交握錯誤或連線被重設。位址一般使用 127.0.0.1，表示連線至本機用戶端；除非明確設定了區域網路監聽與存取控制，否則不應將迴路位址替換為任意網卡位址。

瀏覽器可以先使用系統代理進行基線測試。如果瀏覽器安裝了代理擴充功能，應確認擴充功能處於「跟隨系統」還是自訂模式。擴充功能中的固定連接埠可能覆蓋系統設定，造成用戶端切換連接埠後瀏覽器仍存取舊的監聽連接埠。隱私視窗與不同瀏覽器設定檔也可能使用獨立規則。瀏覽器可用但終端機不可用時，應分開排查兩者，具體步驟見瀏覽器與終端機的代理範圍檢查。

終端機程式通常需要明確設定

許多命令列工具會讀取 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 等環境變數，但具體支援範圍由工具決定。環境變數還分為目前程序、目前終端機工作階段與系統永久設定。排錯時建議只在目前終端機暫時設定，驗證結束後關閉視窗即可恢復，避免將過期的連接埠長期寫入全域環境。以下範例假設 v2rayN 的 HTTP 監聽連接埠確實為 10809；使用前應替換為用戶端介面顯示的實際連接埠。

Windows 命令提示字元目前工作階段：

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
curl https://example.com

PowerShell 目前工作階段：

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
curl.exe https://example.com

若命令執行後，核心日誌仍看不到請求，應檢查該工具是否讀取這些變數、變數名稱是否正確，以及位址與連接埠是否對應 HTTP 監聽。若日誌已出現請求但連線失敗，再進入路由、DNS 或遠端設定檢查。不要只根據終端機輸出中的「逾時」判斷具體層次，因為本機連接埠未監聽、遠端無法連線與網域名稱解析失敗，都可能產生類似表象。

驗證代理範圍，而不只是查看出口結果

可靠的驗證應同時觀察三個訊號：應用程式確實使用目標代理設定；用戶端日誌收到該應用程式產生的網域或連線；路由結果符合預期。只查看一個出口頁面，不能說明所有應用程式都採用相同路徑，也不能說明 DNS 查詢經過了預期處理。測試時分別開啟瀏覽器、終端機與一個目標應用程式，每次只產生少量可辨識請求，再從日誌判斷是否進入核心。

完成本階段後，應能明確知道哪些應用程式跟隨系統代理、哪些使用自身設定，以及哪些仍無法接入。只有第三類應用程式確實存在且無法逐一設定時，才有理由考慮 TUN。對於已能透過系統代理穩定工作的環境，直接進入路由分流通常更簡單。

路由分流：在請求進入核心後選擇出口

路由處理的是出口選擇

路由規則只處理已經進入核心的流量。它根據網域、IP、連接埠、網路類型、入站標籤等條件，將請求交給代理、直連或阻斷等出口。最常見的目標是讓區域網路與明確的內部位址直連，其餘請求使用代理；也可以依網域清單進一步細分。無論採用哪種策略，都應先定義預設行為，再加入範圍清楚的例外規則。如果規則只寫了若干例外，卻沒有理解最終的兜底出口，未命中的請求可能走向與預期不同的路徑。

規則通常依序匹配，前面的寬泛條件可能遮蔽後面的精確條件。例如先寫一條涵蓋所有 TCP 與 UDP 的代理規則，後面的私有位址直連規則就沒有機會命中。設計順序時，一般先放必須直連或必須單獨處理的精確規則，再放範圍較大的分類規則，最後使用兜底規則。修改後要用明確網域逐條驗證，而不是一次匯入很長的規則集後只測試一個網頁。

網域規則、IP 規則與解析策略

當核心仍掌握原始目標網域時，網域規則最直觀，可以匹配完整網域、網域後綴或預先定義的分類。IP 規則依賴目標 IP；當請求最初以網域形式出現時，路由執行是否需要額外解析，會受到 domainStrategy 等設定影響。解析策略設定得過於積極，可能增加 DNS 查詢並改變匹配路徑；完全不解析，又可能讓只寫 IP 條件的規則無法處理網域請求。應依規則實際使用的條件選擇，而不是將某個策略名稱視為普遍最佳值。

私有位址直連通常用於本機、區域網路裝置與內部服務，但仍需結合實際網路環境。企業網路、虛擬機器、容器與開發環境可能使用不同的私有網段；同時存在多個虛擬網卡時，系統路由也會影響連線去向。網域最終解析到私有位址時，還要留意 DNS 結果是否來自目前網路。遇到「網域存取失敗但直接輸入內網 IP 可用」時，應比較網域解析結果與路由命中情況，而不是只調整代理出口。

用於說明規則結構的 Xray 路由片段，出口標籤需與完整設定中的 outbound 標籤一致：

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:intranet.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

這段設定表示：指定的內部網域直連，私有 IP 直連，其餘 TCP 與 UDP 交給名為 proxy 的出口。它是完整設定中的路由部分，不能單獨作為用戶端的完整設定執行。若用戶端透過圖形介面管理路由，應在對應的規則編輯器中表達相同邏輯，不要直接覆蓋用戶端產生的其他欄位。出口標籤不存在時，核心會回報設定錯誤；規則資料檔案遺失或名稱不受支援時，也會在啟動或匹配階段出現提示。

從最小規則集逐步擴充

建立路由時，先保留一條私有位址直連規則與一個明確的兜底出口，確認瀏覽器、終端機與區域網路服務都符合預期。然後一次增加一組網域規則，每組都寫清楚目標與維護來源。規則命名應反映用途，例如「區域網路直連」、「開發服務直連」，不要只寫「規則一」。當某條規則導致異常時，可以暫時停用該組並回到上一個穩定狀態。

DNS 與路由應分別記錄。路由決定出口，DNS 決定如何取得位址，兩者會互相影響但不是同一項設定。若只有網域失敗，先比較解析結果；若 IP 連線也失敗，再檢查出口與遠端連線；若請求根本沒有進入日誌，則返回應用程式接入層。將這三種現象分開，可以避免在路由頁面裡不斷修改 DNS，同時又在系統中設定另一套解析服務。

分流完成後的驗收

至少選擇三類目標分別測試：一個區域網路位址、一個明確要求直連的網域，以及一個使用代理出口的一般網域。對每個目標記錄應用程式接入方式、解析結果、命中規則與最終出口。如果區域網路存取在開啟代理後中斷，先檢查私有位址是否被更寬泛的代理規則提前匹配；如果某個網域偶爾走不同路徑，檢查它是否解析到多個位址，以及規則是依網域還是依 IP 生效。

路由穩定後再考慮 TUN。此時即使擴大流量接入範圍，仍能依靠已驗證的規則判斷出口。若系統代理階段尚未釐清路由，直接啟用 TUN 會將更多程式與系統流量帶入同一套未驗證規則，故障範圍反而更大。

TUN 模式：處理不讀取系統代理的流量

TUN 改變的是流量入口

TUN 透過虛擬網路介面接收系統流量，讓不支援 HTTP 或 SOCKS 代理設定的應用程式也有機會進入核心。它解決的是應用程式接入範圍，不是更換協定，也不會讓錯誤的遠端設定自動恢復。啟用後，系統路由、虛擬網卡、DNS 與核心入站共同參與處理，因此比系統代理多出若干故障點。只有在基礎設定已透過系統代理驗證，且確實存在無法單獨設定代理的應用程式時，才建議進入這一階段。

在桌面系統中，建立虛擬介面或修改路由可能需要額外權限。權限不足時，用戶端介面可能顯示開關已操作，但日誌會出現介面建立、路由寫入或驅動程式存取失敗。Android 的 VPN 接入本身採用系統提供的虛擬網路機制，仍需注意授權、其他 VPN 衝突、分應用程式範圍與背景限制。不同平台的實作細節不同，不應照搬另一平台的驅動程式或權限處理步驟。

啟用前先固定基線

• 目前使用中的設定已透過系統代理完成瀏覽器測試。
• 本機監聽連接埠與核心日誌正常，沒有持續出現設定錯誤。
• 路由規則至少完成私有位址直連與預設出口驗證。
• 系統中沒有同時執行另一套 VPN 或虛擬網路接管工具。
• 已記錄啟用前的 DNS、系統代理與用戶端設定。

符合這些條件後，先清理重複的網路接管方式。若準備由 TUN 處理主要流量，可以依用戶端說明調整系統代理，避免同一請求經過不必要的重複入口。啟用後先測試基本網頁，再測試原本無法讀取系統代理的目標應用程式，最後測試區域網路服務。每一步都查看日誌是否出現請求，以及路由選擇是否正確。不要在第一次啟用時同時匯入新的 DNS、複雜規則與多套繞過清單。

1. 關閉可能衝突的虛擬網路連線 結束其他 VPN 工作階段與同類接管程式，保留正常的實體網路。虛擬機器與容器網路不必盲目刪除，但要記錄其網段與路由。
2. 以所需權限啟用 TUN 根據用戶端日誌確認虛擬介面建立成功，且路由已寫入。只看開關顏色不足以判斷系統層是否完成。
3. 驗證 DNS 與一般 TCP 請求 先測試網域名稱解析，再測試瀏覽器連線。如果 IP 可用但網域失敗，重點檢查 TUN 使用的 DNS 路徑。
4. 測試目標應用程式與區域網路 確認原本未接入的程式已進入日誌，同時確認印表機、路由器管理頁面與內部服務仍能依規則直連。

常見衝突如何分層判斷

啟用後完全無法連線，首先查看虛擬介面與預設路由是否建立，再檢查核心是否仍在執行。若關閉 TUN 後立即恢復，問題集中在 TUN 入口、路由或 DNS，不必重新安裝用戶端。若只有網域失敗而直接輸入 IP 可用，優先檢查 DNS 伺服器的可達性、查詢是否進入預期出口，以及解析結果。若只有區域網路失敗，檢查私有位址規則與系統路由優先順序，尤其是虛擬網卡與實際區域網路使用重疊網段時。

某個應用程式仍未進入代理時，檢查它是否被分應用程式規則排除、是否使用獨立網路介面，或目標流量是否屬於目前 TUN 實作未接管的範圍。Android 上還要確認應用程式是在「僅代理選定的應用程式」還是「繞過選定的應用程式」邏輯下設定，兩種模式的含義相反。相關背景與分應用程式問題可參考Android 權限、省電設定與分應用程式代理。

DNS 是 TUN 排錯的重點

TUN 接管範圍擴大後，系統服務與更多應用程式的 DNS 請求也可能進入處理鏈。需要明確由誰接收查詢、使用哪個伺服器、查詢結果是否用於路由，以及回傳位址是否能從目前出口存取。如果同時設定系統 DNS、用戶端 DNS 與應用程式內建的加密 DNS，實際路徑可能與預期不同。應暫時減少層數，先使用一套明確的用戶端 DNS 方案完成驗證，再依需求恢復應用程式自身的設定。

若日誌中出現網域解析成功但後續連線失敗，應繼續查看解析到的位址與路由出口；若沒有查詢記錄，可能是應用程式使用快取或自身的解析機制。清除快取可用於驗證，但不應把反覆清除快取當作長期方案。最終目標是讓同一網域在相同網路條件下得到可解釋、可重複的解析與路由結果。

退出 TUN 時恢復系統狀態

關閉 TUN 後確認虛擬介面與暫時路由已清理，並檢查系統代理是否仍指向正在執行的用戶端。如果用戶端異常退出導致路由殘留，可先重新啟動用戶端並正常關閉 TUN，再使用系統網路工具檢查路由。恢復過程中不要同時重設所有網路設定，否則會遺失原有的靜態位址、企業網路或虛擬機器設定。保留啟用前的記錄，可以逐項對照變化。

TUN 階段完成的標準不是「開關保持開啟」，而是目標應用程式確實進入核心、區域網路仍可存取、DNS 路徑明確，且關閉後系統能夠恢復。若系統代理已涵蓋全部需求，繼續使用較簡單的接入方式同樣合理。

日常維護與疑難排解：從最近的變更開始

維護重點是設定、狀態與變更記錄

日常維護不需要頻繁重新安裝。更重要的是保留訂閱分組、手動設定、路由規則、DNS 設定與本機連接埠的記錄，並在更新用戶端或調整規則前建立備份。備份中可能包含訂閱網址與連線驗證資料，應存放在受控位置，不應以一般文字公開傳送。還原時先匯入最小設定並進行驗證，再恢復大規模規則，避免無法判斷問題來自備份本身還是新環境。

更新用戶端後，先確認介面設定是否保留、核心能否啟動、本機連接埠是否變更，再測試系統代理。不要將更新、訂閱重新整理、路由替換與 TUN 調整安排在同一次操作中。每次只改變一類變數，出現異常時才能回復。若必須遷移裝置，記錄原用戶端類型、架構、核心選擇、訂閱分組、監聽連接埠、路由策略與特殊應用程式代理設定，比複製整個舊目錄更容易控制風險。

建立統一的故障分類

排錯時先記錄發生時間、最近變更與受影響範圍。若所有遵循系統代理的應用程式同時失敗，檢查用戶端程序、本機監聽與系統代理；若只有單一應用程式失敗，優先查看它的獨立設定；若相同設定在不同網路中表現不同，關注 DNS、網路路徑與系統時間。範圍判斷比錯誤文字本身更有價值，因為許多「連線逾時」不會指出究竟是哪一層逾時。

日誌要從第一個有效錯誤開始讀

用戶端與核心日誌可能在一次失敗後產生大量連鎖提示。應從本次啟動或操作的時間點開始，尋找最早出現的設定解析、監聽、DNS、TLS 或連線錯誤。後續重試產生的行列通常只是結果。分享日誌前，應刪除訂閱網址、使用者識別碼、伺服器位址與其他敏感欄位，只保留錯誤類型、時間順序與必要的上下文。

若核心提示位址已被使用，先定位佔用連接埠的程序。若提示設定欄位無效，回到最近一次編輯或訂閱更新，確認是否匯入了目前核心無法識別的欄位。若出現 TLS 憑證相關錯誤，先同步系統時間，再核對伺服器名稱與憑證網域。若 DNS 查詢逾時，確認 DNS 請求的去向與伺服器可達性，不要直接歸因於伺服器設定。

連接埠、系統代理與異常退出

本機連接埠被佔用時，先判斷是否重複啟動了同一個用戶端，再檢查其他程式。直接修改連接埠可以避開衝突，但會影響所有手動接入端。修改後應同步更新瀏覽器擴充功能、終端機變數、開發工具與區域網路裝置設定。若佔用來自不再需要的舊程序，正常結束該程序通常比長期更換連接埠更容易維護。

用戶端異常退出後，系統代理可能殘留。此時瀏覽器會繼續將請求送往不存在的本機連接埠。可以重新開啟 v2rayN，使用「清除系統代理」，或在作業系統網路設定中恢復。不要因為所有網頁都失敗就立即刪除網路介面卡。若使用 TUN，還要額外確認虛擬介面與路由是否清理；系統代理殘留與 TUN 路由殘留是兩類問題，需要分別檢查。

訂閱、時間與憑證的週期檢查

訂閱不必在每次啟動時無條件連續重新整理。依實際更新需求設定週期，並保留最近可用的設定。重新整理後若大量項目同時變化，先驗證一個項目，不要立即清空舊記錄。系統時間應保持自動同步，因為 TLS 憑證驗證依賴準確時間；時間偏差可能表現為憑證尚未生效或已經過期。伺服器名稱、SNI 與憑證網域也需要匹配，不能靠重複連線消除欄位錯誤。

長期使用中還應留意磁碟空間與日誌增長。日誌用於排錯，但無限保留會增加查找難度。依用戶端提供的清理方式處理舊日誌，不要直接刪除不熟悉的設定資料庫。更新前閱讀介面中的變更提示，更新後驗證最短路徑。更多常見現象可從常見問題依「安裝設定」與「疑難排解」分類查找。

建立可重複使用的排錯記錄

一次有效的記錄應包含平台、用戶端、核心、接入方式、使用中的設定類型、監聽連接埠、是否啟用路由與 TUN、錯誤發生時間、第一筆有效日誌，以及已完成驗證的步驟。不要只寫「不能用」。這些資訊能快速將問題定位到用戶端、核心、設定或應用程式範圍，並避免下次從頭嘗試。解決後補充真正起作用的修改，同時撤銷排錯過程中無效的臨時設定，避免它們成為下一次故障來源。

進階設定路線：從可用走向可解釋

進階不是開啟更多開關

完成基礎階段後，進階目標應是讓設定可解釋、可測試、可回復，而不是同時啟用更多功能。成熟的環境應能明確回答：哪些應用程式透過系統代理，哪些透過自身設定或 TUN；DNS 查詢由誰處理；每類網域與 IP 命中哪條路由；目前使用中的設定採用什麼協定、傳輸與 TLS 參數；用戶端更新或連接埠變更後需要同步哪些位置。能回答這些問題，比介面中啟用了多少選項更重要。

建議將學習路線分為觀察、規則、協定與自動化四個層次。先學會查看用戶端與核心日誌，建立請求從應用程式到出口的路徑；再維護小規模路由與 DNS 規則；接著理解協定、傳輸與 TLS 欄位之間的組合關係；最後才考慮設定備份、遷移與重複驗證流程。每一層都以前一層的穩定基線為前提。

分開理解協定、傳輸與 TLS

VLESS、VMess 等屬於代理協定；TCP、WebSocket、gRPC 等描述傳輸承載；TLS 用於建立加密連線並驗證對端身分。一個設定能否連線，取決於這些層的欄位共同匹配。看到「協定相同」，不能推斷傳輸路徑、服務名稱、伺服器名稱或安全參數也相同。學習新設定時，應按協定層、傳輸層與 TLS 層分別列出關鍵欄位，再對照核心日誌判斷失敗發生在哪個步驟。

TLS 交握發生在建立受保護連線的階段。系統時間錯誤、憑證有效期不符、伺服器名稱與憑證網域不匹配，都可能導致交握失敗。SNI 用於在連線時表示目標伺服器名稱，不應隨意填入與設定無關的網域。傳輸層中的路徑或服務名稱則由遠端服務設定決定，同樣不能憑經驗猜測。進階排錯的核心是逐層核對，而不是嘗試隨機組合。

為路由與 DNS 建立測試清單

加入路由規則後，應維護一組固定測試目標：區域網路位址、內部網域、一般直連目標、代理目標，以及需要 UDP 的應用程式。每次修改規則後按相同順序測試，並記錄命中的出口。DNS 測試還要記錄解析伺服器、回傳位址，以及查詢是否經過預期入口。固定樣本能協助判斷變化來自規則本身，還是目標網站、快取或目前網路。

規則檔案與分類資料更新時，也應先在少量目標上驗證。分類名稱可能存在涵蓋範圍變化，寬泛規則的位置尤其需要重新檢查。自訂規則應寫清楚建立原因與日期，但不需要記錄虛構的效能數字。若某條規則長期沒有明確用途，應考慮移除，以減少未來衝突。簡單且能解釋的規則集，通常比大量來源不明的規則更可靠。

將不同裝置視為獨立環境

桌面系統與 Android 可以使用同一訂閱來源，但系統代理、VPN 介面、背景策略與分應用程式能力不同。不要假設在 Windows 上驗證過的接入方式可以原樣複製到 Android，也不要將 Android 的 VPN 授權問題歸因於訂閱。跨裝置排錯時，應先確認兩端是否選用了同一設定、系統時間是否正確、網路條件是否相近，再比較核心與欄位支援。

若多部桌面裝置都使用 v2rayN，可以統一訂閱分組命名與路由目標，但監聽連接埠、安裝路徑與系統代理仍應依裝置記錄。macOS 與 Linux 對系統代理的實作不同，命令列工具也可能採用各自的環境變數。共享的是設定邏輯，而不是作業系統狀態。遷移文件應描述「要達成的行為」，同時為各平台保留具體的檢查方法。

設計三個穩定設定檔位

可以將日常設定分為三個檔位。基礎檔只包含單一使用中設定、預設路由與系統代理，用於驗證核心與瀏覽器；分流檔加入經過測試的直連規則與明確的 DNS 路徑，用於日常桌面使用；擴充檔則在分流檔基礎上啟用 TUN，涵蓋不讀取系統代理的應用程式。三個檔位都應能獨立回復，出現問題時先降回基礎檔，而不是刪除所有設定。

各檔位之間的差異需要以文字記錄，包括系統代理狀態、TUN 狀態、DNS 設定、路由規則組與應用程式獨立代理。切換後使用同一組測試目標驗收。如此可以快速判斷故障是由遠端設定變更引起，還是由本機進階功能導致。若基礎檔也失敗，就不必繼續調整 TUN；若基礎檔正常而擴充檔失敗，問題範圍已縮小至虛擬介面、路由或 DNS。

持續學習的資料順序

先使用概念速查補足協定、核心、訂閱、系統代理與路由術語，再透過用戶端比較理解平台差異。遇到具體故障時，從常見問題定位類別，再閱讀對應文章。若要理解 Project V、V2Fly、Xray 與三款用戶端的關係，可參考開源生態與用戶端選擇說明。資料之間應形成「概念—操作—驗證—排錯」的順序，而不是只收集零散參數。

到了這個階段，設定工作的重點已從「讓一次連線成功」轉為「讓行為長期可預測」。保留最小基線、限制同時變更的變數、記錄應用程式接入範圍、驗證每條路由的命中證據，並妥善備份訂閱與敏感設定。這套方法適用於 v2rayN、v2rayNG 與 v2flyNG，也能協助區分用戶端介面差異、核心行為與作業系統網路機制。