V2Ray 從零到精通完整手冊

CHAPTER 01

核心概念：先區分核心、客戶端與設定

V2Ray、V2Fly 與 Xray 分別位於哪一層

開始設定前，最重要的不是記住選單位置，而是將幾個經常同時出現的名稱放在正確層級。V2Ray 通常用來指稱由 Project V 形成的代理技術生態與設定體系；V2Fly 延續並維護其中一條核心路線；Xray 則是同一技術家族中的另一套核心實作。核心負責解析設定、建立入站與出站、完成協定交握、執行 DNS 策略，並依路由規則轉送流量。它通常在背景執行，不直接負責訂閱清單、系統匣選單與系統代理開關等圖形操作。

v2rayN、v2rayNG 與 v2flyNG 屬於客戶端層。客戶端將訂閱管理、伺服器選擇、日誌檢視與代理模式整合為可操作介面，再呼叫對應核心處理連線。桌面環境首選 v2rayN，支援 Windows、macOS 與 Linux；Android 優先使用採用 Xray 核心的 v2rayNG，需要 v2fly 核心路線時再選擇 v2flyNG。理解這層關係後，遇到問題時就能判斷屬於介面設定、訂閱內容、核心啟動或網路環境，而不是反覆重灌整個客戶端。

一條連線由哪些部分組成

一份能建立連線的設定至少包含入站、出站與路由三個邏輯部分。入站描述本機程式如何將流量交給核心，例如本機 SOCKS 連接埠、HTTP 代理連接埠，或由 TUN 虛擬網卡接收的資料；出站描述核心如何處理流量，常見標籤包括代理出站、直接連線與封鎖；路由位於兩者之間，依網域、IP、連接埠、網路類型或入站標籤決定採用哪個出站。圖形客戶端會產生其中一部分設定，因此日常使用不必手寫完整檔案，但理解結構有助於閱讀日誌與檢查規則。

伺服器項目提供遠端連線所需的位址、連接埠、身分資訊、協定與傳輸參數。協定決定雙方如何交換資料，傳輸層決定資料承載於 TCP、WebSocket、gRPC 等哪種通道，TLS 或 REALITY 這類安全參數則進一步限制交握方式。任何關鍵欄位不一致都會導致連線失敗。客戶端能匯入連結不代表設定一定有效；匯入只表示語法已被辨識，真正可用仍須經過 DNS 解析、網路連通性、系統時間與遠端狀態等多層檢查。

訂閱不是協定，節點也不是客戶端

訂閱位址是一個設定分發入口。客戶端請求該位址後，伺服器返回一組伺服器項目或結構化設定，客戶端再將結果轉換成清單。訂閱本身不負責轉送流量，也不代表某一種協定。常見誤解是把「訂閱更新成功」理解為「代理已啟用」：前者只表示客戶端取得並解析清單，後者還需要選擇伺服器、啟動核心，並讓應用程式流量進入本機代理或 TUN 入站。

「節點」是介面中對伺服器設定項目的慣用稱呼。一個項目可能包含 VMess、VLESS、Trojan 等協定參數，也可能引用同一遠端入口的不同傳輸組合。判斷項目是否適合目前環境時，應先確認協定與傳輸是否受客戶端核心支援，再確認位址能否解析、連接埠能否連通，最後才檢查路由模式。不要只憑名稱判斷用途，因為顯示名稱通常只是訂閱提供者設定的備註，不會參與實際交握。

從應用程式請求到遠端出站的完整路徑

以瀏覽器存取網站為例：瀏覽器先解析網域，再依作業系統代理設定將請求交給 v2rayN 的本機監聽連接埠；核心取得目標網域與目標 IP 後，由上到下比對路由規則；命中 direct 時由本機網路直接存取，命中 proxy 時透過目前伺服器出站，命中 block 時停止轉送。若應用程式不讀取系統代理，請求便不會進入這條路徑，此時需要在應用程式內另行設定代理，或使用 TUN 接管其網路流量。

這個流程說明了為什麼「客戶端顯示執行中」仍可能沒有實際代理效果。執行中只表示核心程序存在；系統代理可能尚未啟用，應用程式可能繞過系統設定，規則也可能將目標分配為直連。反過來，某個網站能開啟也不能證明所有規則都正確，因為它可能剛好走了直連。驗證設定時應同時觀察客戶端日誌、系統代理狀態與目標請求的路由結果，而不是只看單一網頁是否載入。

CHAPTER 02

客戶端選擇與安裝：依平台建立穩定起點

三款客戶端的職責範圍

桌面平台優先選擇 v2rayN。它將訂閱分組、伺服器清單、系統代理、路由規則、TUN 與日誌集中在同一個工作台，適合從基礎連線逐步擴充至複雜分流。Windows 可依介面實作選擇桌面版或經典 WPF 版；前者採用跨平台桌面介面，後者延續經典 Windows 操作方式。兩者的核心任務相同，不需要同時執行。macOS 與 Linux 使用對應平台的 v2rayN 安裝套件，下載時依處理器架構與發行版套件格式選擇。

Android 平台優先使用 v2rayNG，它採用 Xray 核心，設定概念與桌面端接近，但代理接管方式由系統 VPN 介面完成，介面路徑也更精簡。v2flyNG 是採用 v2fly 核心的備選客戶端，適合明確需要該核心路線的設定。兩款 Android 客戶端可以分別安裝，但日常連線時只應啟用一個系統 VPN 工作階段，避免兩個客戶端爭用接管權限。完整安裝套件入口與平台說明集中於下載頁。

安裝前先確認架構與權限

處理器架構決定安裝套件能否啟動。Windows 與 Linux 常見桌上型電腦通常使用 x64；採用 ARM 處理器的裝置則需要 arm64。macOS 可從系統資訊中的晶片或處理器欄位判斷：顯示 Apple 晶片時選擇 Apple Silicon 對應套件，顯示 Intel 時選擇 x64。Android 可在裝置資訊或硬體檢測頁面查看 ABI；近年的主流裝置通常支援 arm64，無法確認時可使用通用套件，但通用套件通常體積較大。

安裝權限會影響系統代理、虛擬網卡與服務註冊。一般系統代理通常只需修改目前使用者設定；TUN 模式需要建立虛擬網路介面並調整路由表，因此可能觸發管理員授權。授權應在使用者主動開啟相應功能時進行。若客戶端可以開啟但 TUN 無法啟動，應優先檢查權限與驅動程式狀態，而不是先修改伺服器協定。企業裝置也可能由政策統一管理代理或網路延伸功能，這類限制需要在系統管理範圍內處理。

首次啟動後的最小檢查

第一次開啟客戶端時，不要立即啟用所有選項。先確認客戶端能正常顯示主介面、設定區能找到核心路徑、日誌視窗可以開啟，然後再匯入訂閱。v2rayN 的主介面通常包含訂閱分組、伺服器清單、系統代理與路由設定；v2rayNG 的主介面則以設定清單、目前選取項目與連線按鈕為中心。此時先保持系統代理關閉，可以將安裝問題與設定問題分開。

接著檢查系統時間、時區與網路基礎狀態。TLS 與 REALITY 等交握對時間偏差相當敏感，系統時間錯誤可能表現為憑證或交握失敗。先使用不經代理的網路確認一般網站與 DNS 可以正常運作，再啟動客戶端。如果目前網路本身需要網頁登入認證，應先完成認證，因為認證頁面通常在代理啟動前處理較穩定。網路環境切換後，也應等待系統取得新的位址與 DNS，再重新連線。

Windows PowerShell
Get-Date
Get-NetIPConfiguration
Test-NetConnection example.com -Port 443

macOS / Linux
date
curl -I https://example.com

這些指令只用於確認本機時間、網卡設定與基礎 HTTPS 連通性，不會判斷代理伺服器是否有效。若基礎連線已經失敗，應先恢復本地網路；若基礎連線正常而客戶端核心無法啟動，再查看設定解析與連接埠占用。如此可避免在網路中斷時反覆更換訂閱項目。

升級、並行安裝與設定目錄

升級客戶端前應先退出正在執行的核心，並記錄目前的訂閱分組、路由模式與自訂規則。客戶端設定通常儲存在使用者目錄或應用程式資料目錄中，具體位置取決於平台與安裝形式。覆蓋安裝前，先使用客戶端提供的備份或匯出功能保存必要設定，不要把快取、日誌與伺服器清單當成唯一備份。訂閱位址可以重新更新，但手動新增的伺服器、路由規則與 DNS 設定可能無法從訂閱復原。

同一台電腦可以保留不同介面實作來進行遷移測試，但不要讓兩個客戶端同時監聽相同本機連接埠，也不要同時修改系統代理。連接埠衝突通常會在日誌中顯示「位址已被使用」或監聽失敗。切換客戶端時，先清除舊客戶端設定的系統代理並完全退出，再啟動新客戶端。若異常退出後系統仍保留代理位址，可在作業系統網路設定中關閉代理，然後回到客戶端重新啟用。

CHAPTER 03

訂閱匯入：從位址取得設定並建立分組

訂閱位址的結構與保存方式

訂閱位址通常是一個 HTTPS URL，路徑或查詢參數中包含用於識別帳戶的權杖。它的作用是讓客戶端定期取得伺服器清單，因此應依帳戶憑證管理，不要發布在公開頁面、截圖或日誌中。複製位址時要確保從通訊協定開頭到最後一個字元都完整保留，避免聊天工具自動截斷查詢參數。客戶端中儲存的是位址，不是網頁正文；若在瀏覽器中開啟後看到編碼文字或下載回應，不代表位址錯誤。

https://example.com/sub?token=xxxx

上方位址只展示常見結構。實際訂閱可能使用不同路徑與參數名稱。匯入時不要手動刪除看似多餘的等號、斜線或百分比編碼，因為這些字元可能屬於權杖或簽章。若複製後結尾帶有空格與換行，應先清除不可見字元。訂閱位址輪換時，建議編輯原有分組，而不是不斷建立重複分組，避免舊伺服器與新伺服器混在同一清單中。

在 v2rayN 中匯入與更新

桌面端應先建立訂閱分組，再將位址放入分組設定。開啟「訂閱分組」相關選單，新增分組名稱與訂閱位址，儲存後執行更新。分組名稱只用於本機識別，可以依用途或設定來源命名，不會影響遠端回應。更新成功後，伺服器清單會依訂閱內容產生；若啟用刪除舊項目的更新策略，客戶端會用本次結果取代該分組先前的項目，因此手動新增的伺服器最好放在獨立分組中。

更新完成後先檢查項目數量是否合理、協定是否已辨識、位址與連接埠欄位是否存在，再選取一個項目設為作用中伺服器。不要在更新過程中連續點擊多次，因為並行請求可能觸發訂閱端的頻率限制，也會讓日誌難以閱讀。多個訂閱並存時，請為每個來源建立獨立分組，按需設定更新間隔；需要進一步整理伺服器時，可參考多訂閱分組與關鍵字篩選，將分組、篩選與路由用途分開管理。

在 v2rayNG 與 v2flyNG 中匯入

Android 客戶端通常從訂閱設定中新增位址，再返回主介面執行更新。更新時系統需要允許客戶端存取網路；省電限制、背景資料限制或私人 DNS 異常都可能導致請求失敗。更新完成後，設定項目會出現在主清單中，需要手動選取其中一項作為目前設定。選取狀態只是指定下次連線使用的設定，不代表系統 VPN 工作階段已建立，還要執行連線並確認狀態列出現 VPN 標誌。

v2rayNG 與 v2flyNG 的訂閱資料應分別維護。雖然部分通用分享連結都能被辨識，但兩套核心對新協定欄位與擴充選項的支援進度可能不同。某項設定在其中一款客戶端無法解析時，先查看它是否包含目前核心不支援的欄位，不要直接認定整個訂閱失效。若訂閱同時提供適用不同核心的入口，應使用與客戶端相符的入口。

更新成功、解析成功與連線成功的差別

訂閱更新包含三個可獨立判斷的階段。第一階段是 HTTP 請求成功，表示客戶端能存取訂閱位址並取得回應；第二階段是內容解析成功，表示返回格式能轉換為伺服器項目；第三階段才是選取項目並建立代理連線。回應狀態正常但清單為空，通常屬於內容格式、帳戶狀態或篩選條件問題；清單存在但全部無法連線，則要檢查伺服器參數、時間、DNS 與目前網路。

日誌中的錯誤訊息應依階段閱讀。網域解析失敗表示訂閱網域未取得 IP；連線逾時表示請求未在期限內完成；未授權或禁止存取通常與位址權杖、帳戶狀態或請求策略有關；解析失敗則表示回應內容不是客戶端預期的格式。若客戶端設定為「透過代理更新訂閱」，而目前代理本身已失效，更新會形成依賴閉環。排錯時可暫時改為直連更新，成功後再恢復原有策略。

分組、篩選與去重策略

分組的價值不只在於視覺整理，也限定更新與刪除操作的範圍。工作、日常瀏覽與測試設定可以分開儲存，更新其中一個來源時不會覆蓋其他分組。伺服器名稱包含地區或用途關鍵字時，可使用客戶端篩選功能縮小清單，但篩選只改變顯示或選取範圍，不會改變遠端設定。建立篩選規則前先觀察命名規律，避免使用過於寬泛的關鍵字把不相關項目一併選入。

重複項目常由多次匯入同一訂閱、訂閱端重複返回，或遷移時保留舊分組造成。處理時先確認項目所屬分組，再刪除舊來源；不要只按顯示名稱批次刪除，因為不同設定可能使用相同備註。若訂閱更新後舊項目仍存在，請檢查該分組的更新方式是否採用追加策略。長期維護應讓自動更新負責訂閱項目，手動設定留在獨立分組，兩類資料的生命週期不同，混合儲存會增加誤刪機率。

訂閱更新失敗時的最短診斷路徑

先關閉透過代理更新訂閱的選項，使用目前的基礎網路請求一次；接著檢查位址是否完整、系統時間是否正確、訂閱網域能否解析。若只有某個位址失敗而其他位址正常，問題較可能出在該訂閱的權限或回應；若所有位址都失敗，應檢查 DNS、殘留的系統代理與安全軟體的網路策略。更新後沒有伺服器時，再查看客戶端是否啟用了名稱篩選，或返回內容是否被辨識為網頁錯誤訊息。

不要透過頻繁刪除重灌來處理單一訂閱錯誤，因為重新安裝客戶端不會改變遠端回應，也不會修復錯誤位址。保留一次失敗日誌，找出請求階段與狀態資訊，再決定是修改位址、切換更新網路或調整解析方式。更多集中問題可在常見問題中依「安裝設定」與「故障排查」分類尋找。

CHAPTER 04

代理模式：決定哪些應用程式將請求交給客戶端

系統代理與核心路由解決不同問題

系統代理負責將支援作業系統代理設定的應用程式請求送至客戶端本機連接埠；核心路由則在請求已進入客戶端後，決定最終走代理、直連或封鎖。前者控制「是否進入」，後者控制「進入後往哪裡走」。許多設定混亂都源於將兩者視為同一個開關：即使路由選擇全域代理，未讀取系統代理的應用程式仍不會自動進入；即使系統代理已開啟，路由也可能將特定目標分配為直連。

v2rayN 的「自動設定系統代理」適合瀏覽器與遵循系統設定的桌面應用程式。啟用後，客戶端會將作業系統的代理位址指向本機監聽連接埠；清除系統代理會撤銷這項設定；不改變系統代理則適用於只啟動核心、由其他應用程式手動連接本機連接埠的情境；PAC 模式則透過規則檔案向應用程式返回不同的代理決策。日常使用先選擇自動設定系統代理，再搭配核心路由進行分流，路徑最容易理解。

如何理解全域、規則與繞過中國大陸模式

客戶端介面中的「全域」通常表示進入核心的流量預設使用代理出站，適合短時間排查規則問題，但不會強制接管所有應用程式。規則模式依路由表逐條比對，常見做法是讓區域網路、私有位址與特定網域集合直連，其餘請求使用代理。繞過中國大陸模式是一組預設規則，通常將中國大陸網域與 IP 分配為直連，再讓其他目標使用代理。預設規則方便開始使用，但仍需依實際應用檢查誤判情況。

選擇模式時應從使用目的出發。日常瀏覽優先使用規則或繞過中國大陸模式，減少不必要的代理路徑；除錯特定目標是否被規則錯誤分流時，可暫時切換全域模式進行對照；只需要代理單一開發工具時，可以維持「不改變系統代理」，在工具中手動填寫本機 SOCKS 或 HTTP 位址。模式比較與典型情境可繼續閱讀系統代理、全域與繞過中國大陸模式的差異。

本機 SOCKS 與 HTTP 連接埠

核心通常會同時提供 SOCKS 與 HTTP 兩種本機入站。SOCKS 能轉送 TCP，也可依客戶端實作處理 UDP；HTTP 代理更適合原生支援 HTTP CONNECT 的應用程式。連接埠由客戶端設定產生，不應任意套用其他教學中的固定數字。需要在獨立應用程式中設定代理時，應從目前客戶端設定頁面讀取本機監聽位址與實際連接埠，主機通常使用回環位址 127.0.0.1，避免將本機代理暴露給區域網路。

應用程式設定中還要區分「代理 DNS」與「本機解析」。某些 SOCKS 客戶端會先在本機解析網域，再將 IP 交給代理；另一些則會將網域交由遠端鏈路解析。前者可能繞過核心依網域執行的路由規則，後者更有利於保留網域資訊。應用程式提供 socks5h 類型模式時，其中的主機名稱解析通常會隨 SOCKS 請求交給代理。具體選擇應與核心 DNS 及路由策略一致。

HTTP_PROXY=http://127.0.0.1:本機HTTP連接埠
HTTPS_PROXY=http://127.0.0.1:本機HTTP連接埠
ALL_PROXY=socks5h://127.0.0.1:本機SOCKS連接埠

以上寫法用於說明環境變數結構，實際使用時應將文字連接埠替換為客戶端顯示的數字。命令列工具只有在讀取這些環境變數時才會使用代理；關閉終端機或清除變數後，行為可能恢復為直連。不要同時設定多個互相衝突的代理來源，例如系統代理、環境變數與應用程式內代理都指向不同客戶端，這會讓請求路徑難以判斷。

如何確認系統代理真正生效

首先在 v2rayN 狀態列確認系統代理顯示為自動設定，然後開啟一個遵循系統代理的瀏覽器請求頁面，同時觀察客戶端存取日誌。日誌中出現新連線，表示請求已進入核心；沒有日誌則應檢查瀏覽器是否使用獨立代理、是否啟用了直連策略，或是否從舊程序繼承了環境變數。完全退出瀏覽器後再重新開啟，可排除部分連線池與代理設定快取。

若日誌存在但目標存取失敗，繼續查看路由標籤與出站錯誤。命中 direct 表示規則選擇直連，命中代理出站後逾時則屬於遠端鏈路或網路問題。若關閉系統代理後仍無法正常直連，作業系統可能殘留舊位址。此時在系統網路設定中檢查手動代理欄位，清除不再使用的回環位址與連接埠，再由客戶端重新自動設定。

行動端的接管方式

v2rayNG 與 v2flyNG 透過系統 VPN 介面接收應用程式流量，因此不需要個別修改每個瀏覽器的系統代理。點擊連線後，系統會要求建立 VPN 工作階段；允許後，客戶端依路由與依應用程式設定決定流量走向。連線圖示出現只表示介面已建立，仍要透過日誌確認目前設定已成功連線至遠端。切換網路、進入省電模式或長時間在背景執行後，系統可能回收程序，需要檢查電池最佳化與背景執行權限。

依應用程式代理可以限制哪些應用程式進入客戶端，適合將工作應用程式與其他流量分開。設定時應明確選擇「僅代理選取的應用程式」還是「繞過選取的應用程式」，兩者意義相反。修改清單後重新建立連線，確保系統重新載入路由。若某個應用程式內部還設定了自己的代理，應避免與系統 VPN 形成二次轉送，先還原應用程式的預設網路設定再測試。

CHAPTER 05

路由分流：依網域、IP 與入站選擇出站

規則由上到下比對

路由規則的核心不在規則數量，而在比對順序。核心通常會依清單由上到下檢查，請求命中一條規則後便使用對應出站，不再繼續比對後面的普通規則。因此，範圍小且意圖明確的規則應放在前面，範圍大的兜底規則放在後面。例如廣告網域封鎖應位於一般網域代理之前，區域網路與私有位址直連應位於預設代理之前。順序顛倒時，即使規則語法完全正確也會產生錯誤結果。

網域規則只有在核心能取得目標網域時才會生效。如果應用程式先在本機解析，只提交 IP，geosite 規則可能無法比對，後續只能依靠 geoip 或其他 IP 規則。反過來，IP 規則需要解析結果；解析策略與 DNS 回應都會影響它。穩定分流需要讓應用程式入站、DNS 與路由採用一致設計，而不是只複製一段規則清單。

geosite、geoip 與 domainStrategy

geosite 是依網域集合比對的規則資料，例如 geosite:cn 表示相應網域集合，geosite:category-ads-all 常用於廣告網域分類。geoip 依 IP 集合比對，例如 geoip:private 用於私有位址，geoip:cn 用於對應地區的 IP。規則資料會隨客戶端或核心資源更新，若日誌提示集合不存在，應檢查資源檔案是否完整，以及標籤是否受目前資料集支援。

domainStrategy 決定路由在什麼條件下為網域解析 IP。AsIs 傾向依原始網域比對，不主動為了 IP 規則進行解析；IPIfNonMatch 表示網域規則未命中時再解析 IP 並繼續比對；IPOnDemand 會在規則需要 IP 時更積極地解析。日常網域與 IP 混合分流常使用 IPIfNonMatch，它在保留網域比對的同時允許後續 IP 規則運作，但具體選擇仍要考慮 DNS 設定與效能。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

這段 JSON 展示可放入 Xray 設定中的路由物件，前提是完整設定已定義名為 block 與 direct 的出站。預設代理通常由客戶端在未命中規則時選擇，或透過最後一條範圍較廣的規則明確指定。複製片段前要核對客戶端產生的出站標籤，不同客戶端可能使用不同標籤名稱；標籤不一致會導致核心啟動時報錯，找不到出站。

建立最小且可解釋的規則集

首次自訂時，建議只保留四類意圖：封鎖明確不需要的網域集合、私有網路直連、確定需要直連的網域與 IP，其餘交給預設代理。每增加一條規則，都應能回答「比對對象是什麼、為什麼放在這個位置、命中後走哪個出站」。如果無法說明，就先不要加入。數量龐大但來源不明的規則集會增加更新依賴，也會讓誤判難以定位。

私有位址直連尤其重要。區域網路印表機、路由器管理頁面、檔案分享與本機開發服務通常位於私有網段，不應被送往遠端代理。除了 geoip:private 外，也可以依目標連接埠、入站標籤或明確網段補充規則。需要透過 TUN 存取區域網路時，還要確認虛擬網卡路由沒有覆蓋本機鏈路；直連只是核心決策，作業系統路由表也必須能到達目標。

依網域、連接埠與程序細分

自訂網域可使用完整網域、子網域後綴、關鍵字或正規表示式形式。優先使用完整網域與後綴比對，較容易預測；關鍵字可能誤中不相關網站，正規表示式則應控制複雜度並記錄用途。連接埠規則適合限定特定服務，但連接埠本身不能判斷網站歸屬，同一連接埠可能承載大量不同服務。在同一條 field 規則中放入網域與連接埠時，通常表示條件共同限制，設定前要確認核心對欄位組合的比對語意。

程序分流依賴平台能力與客戶端實作。即使介面提供程序名稱規則，也可能受權限、程序衍生方式與容器環境影響。程序規則適合作為桌面應用程式的補充控制，不應取代網域與 IP 規則。應用程式更新後，可執行檔名稱或路徑可能變更，也可能使舊規則失效。維護時應在日誌中確認實際程序辨識結果，而不是只看規則是否仍存在。

DNS 洩漏與分流錯位

如果目標網域由本機 DNS 直接解析，而連線本身走代理，解析請求與業務連線便處於不同路徑。這可能造成地區結果不一致、網域規則資訊遺失或解析失敗。解決方向不是簡單更換 DNS 位址，而是明確哪些網域由哪組 DNS 伺服器解析，以及這些 DNS 請求透過哪個出站傳送。核心 DNS、系統 DNS、瀏覽器安全 DNS 與 TUN DNS 劫持可能同時存在，應盡量減少重複層級。

排查時先關閉瀏覽器獨立 DNS 功能，使用系統與客戶端的統一路徑測試；接著觀察日誌中是否保留目標網域、DNS 查詢經由哪個出站、返回位址是否進入預期的 IP 規則。需要進一步檢查時，可閱讀V2Ray DNS 洩漏檢測與設定實作。修改 DNS 後應清除系統與應用程式快取，再重新建立連線，否則舊結果可能持續影響判斷。

規則變更後的驗證清單

儲存路由後應重新載入核心，確認日誌沒有欄位、標籤或資源錯誤；分別存取一個預期直連目標、一個預期代理目標與一個區域網路位址；檢查每個請求的目標網域、目標 IP 與出站標籤；最後切換網路再測試一次，排除 DNS 快取與舊連線池的影響。若只有某個應用程式不符合規則，檢查它是否讀取系統代理、是否使用獨立 DNS、是否重用舊連線或啟用了 QUIC。

規則維護應保留簡短說明與修改原因。客戶端支援備註時直接記錄；只能編輯 JSON 時，可在外部文件保存規則意圖，不要向嚴格 JSON 檔案加入註解。刪除規則前先確認它是否被其他入站依賴。長期穩定的規則集通常比不斷疊加規則更精簡，因為明確的預設行為與少量例外更容易驗證。

CHAPTER 06

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

TUN 與系統代理的根本差異

系統代理依賴應用程式主動讀取作業系統設定，TUN 則建立虛擬網路介面，讓作業系統將符合路由表的 IP 流量交給客戶端。對不支援代理設定的應用程式、部分命令列程式與需要 UDP 的情境，TUN 的涵蓋範圍更完整。代價是設定層級增加：除了核心入站與路由規則，還要處理虛擬網卡權限、系統路由、DNS 劫持、MTU 與區域網路繞過。

TUN 不是「更快的系統代理」，也不應作為所有問題的第一解法。如果瀏覽器透過系統代理已穩定運作，應先完成訂閱、伺服器與路由驗證，再開啟 TUN。如此一旦出現異常，可以確定基礎代理鏈路沒有問題，診斷範圍會集中在虛擬網卡與系統網路層。直接從 TUN 開始，連線失敗時很難區分原因是伺服器、DNS、權限還是路由表。

啟用前的權限與衝突檢查

建立虛擬網卡通常需要管理員權限。v2rayN 開啟 TUN 時可能要求授權或安裝相關元件，完成後應在系統網路介面清單中看到新的虛擬介面。若日誌顯示建立介面失敗、存取遭拒或寫入路由失敗，先以系統允許的方式授予權限，並檢查終端機安全策略是否阻止虛擬網卡。不要反覆點擊開關試圖繞過錯誤，重複建立可能留下多條暫存路由。

其他 VPN、虛擬機網路、容器網路與安全軟體也可能調整路由表或 DNS。啟用 TUN 前先退出不需要的同類工具，記錄基礎網路的預設閘道與 DNS，再啟動客戶端。若兩個工具都宣告預設路由，最終流量可能進入錯誤介面或形成回環。確實需要並行時，應透過更具體的網段與路由優先順序劃分邊界，而不是讓兩邊都接管所有流量。

路由表、嚴格路由與自動路由

自動路由會為 TUN 介面寫入系統路由，使目標流量進入虛擬網卡。嚴格路由通常會進一步限制可能繞過 TUN 的路徑，有助於讓 DNS 與業務流量保持一致，但也可能影響虛擬機、區域網路探索或特殊網卡。初次啟用可使用客戶端推薦的自動路由設定，確認基本存取後，再依需求決定是否啟用更嚴格的策略。

區域網路存取異常時，先確認私有網段是否保留直連的系統路由，再檢查核心中的 geoip:private 是否指向 direct。這兩個條件缺一不可：作業系統必須能將區域網路目標交給正確閘道，核心也必須選擇直接出站。若公司網路使用不常見的內部網段，應新增明確網段規則，而不是假設所有內部位址都落在常見私有範圍內。

Windows PowerShell
Get-NetRoute | Sort-Object RouteMetric
Get-DnsClientServerAddress

macOS
netstat -rn
scutil --dns

Linux
ip route
ip address

這些指令用於觀察 TUN 開啟前後介面、預設路由與 DNS 的變化。檢查重點是預設路由是否由預期介面接管、區域網路網段是否仍有更具體的路由、關閉 TUN 後暫存路由是否撤銷。不同系統的輸出形式不同，不要直接套用他人的介面名稱或閘道位址。

DNS 劫持與 FakeDNS

TUN 接收到的是 IP 封包，而路由規則經常依賴網域。DNS 劫持用於將系統 DNS 請求交給核心，使核心保留網域與解析結果之間的關係。FakeDNS 則可以為網域配置一段暫時映射位址，應用程式連線至該位址時，核心再還原原始網域並執行路由。這類機制能改善網域分流，但要求位址池不與區域網路、虛擬機或其他 VPN 網段衝突。

出現「能解析但無法連線」時，應檢查 FakeDNS 位址是否被其他路由搶走；出現「關閉客戶端後網路仍異常」時，應確認系統 DNS 與路由是否恢復。某些應用程式使用內建 DNS 或加密 DNS，可能繞過系統的一般 DNS 請求，此時需要在應用程式內關閉獨立解析，或透過 TUN 路由確保其解析連線也進入客戶端。DNS 設定應一次只啟用一套主要邏輯，避免系統 DNS、客戶端 DNS 與瀏覽器 DNS 互相覆蓋。

MTU、UDP 與連線異常

MTU 決定單一網路封包的最大尺寸。TUN 疊加代理傳輸後會增加額外負荷，如果路徑不允許分片或丟棄必要的控制訊息，過大的 MTU 可能造成小頁面可以開啟、大型檔案或特定網站卻長時間卡住。遇到這類症狀時，可在客戶端允許的範圍內逐步降低 TUN MTU，每次調整後重新建立連線並測試相同目標。不要一開始就使用極小值，因為過小會增加封包數量與處理負荷。

UDP 需要伺服器協定、出站能力與客戶端設定共同支援。語音、遊戲、DNS 與基於 QUIC 的連線可能使用 UDP；若 UDP 不通但 TCP 正常，先檢查目前設定是否允許 UDP，再查看 TUN 入站是否接收 UDP、路由規則是否將它送往正確出站。為快速判斷，可暫時讓瀏覽器關閉 QUIC，觀察網頁是否恢復；這只是定位手段，最終仍應修正 UDP 或路由設定。

何時適合長期使用 TUN

需要統一接管多個不支援系統代理的應用程式、依賴 UDP，或希望透過一套路由覆蓋桌面程式時，TUN 更合適。只使用瀏覽器與一般辦公工具時，系統代理通常更簡單，也更容易與區域網路服務共存。長期使用 TUN 應定期檢查系統更新後虛擬網卡權限是否變更、網路切換後預設路由是否重建，以及睡眠恢復後 DNS 是否仍指向有效介面。

從系統代理遷移至 TUN 時，先清除系統代理，避免同一請求先進入本機代理再被 TUN 捕捉。啟用後透過日誌確認入站標籤來自 TUN，並分別測試 TCP、UDP、區域網路與 DNS。完整的啟用步驟與平台差異可參閱v2rayN TUN 模式原理與啟用步驟。

CHAPTER 07

日常維護：更新、備份、日誌與故障定位

將維護對象分成四層

穩定使用依賴四類對象：客戶端程式、核心與規則資源、訂閱資料、本機自訂設定。它們的更新來源與風險不同。客戶端更新可能改變介面與設定遷移邏輯；核心更新會影響協定與設定欄位；規則資源更新會影響 geosite 與 geoip 比對；訂閱更新則會替換伺服器項目。一次同時更新所有內容，出現問題後很難判斷是哪一層變更造成。

更穩妥的方法是分批執行。先匯出本機設定與自訂規則，再更新客戶端並確認可以啟動；接著檢查核心與資源是否載入；最後逐一更新訂閱並測試作用中伺服器。若只需要重新整理伺服器，不必同時修改路由與 DNS。每次維護後記錄變更內容與測試路徑，出現回歸時就能快速恢復上一套可用設定。

備份哪些內容才有復原價值

訂閱伺服器清單可以重新取得，但訂閱位址、分組結構、手動伺服器、路由規則、DNS、連接埠與 TUN 參數屬於本機管理資訊，應納入備份。使用客戶端匯出功能時，確認匯出範圍是否包含訂閱位址與敏感欄位；備份檔案應放在受控位置。截圖適合記錄介面狀態，不適合作為完整備份，因為長位址、隱藏欄位與規則順序無法可靠復原。

遷移至另一台裝置時，不應直接複製所有快取與執行狀態。先安裝符合平台的客戶端，匯入訂閱與必要規則，再依新裝置的處理器架構、權限與網路環境調整。監聽連接埠、介面名稱與系統代理狀態不一定適合原樣遷移。復原後從最小系統代理測試開始，確認正常後再啟用 TUN 與進階 DNS。

日誌應從第一條錯誤開始閱讀

核心日誌往往會在一個根因後產生多條連鎖錯誤。例如 DNS 解析失敗會導致連線目標為空，隨後出現出站失敗與請求關閉；連接埠占用會導致入站建立失敗，之後所有應用程式都無法連線。排查時找出本次啟動後第一條明確錯誤，比只看最後一條逾時更有效。重新測試前清空日誌或記住時間點，避免將舊錯誤當成目前狀態。

常見資訊可依階段分類：設定解析錯誤表示欄位、JSON 結構或標籤存在問題；監聽失敗通常與連接埠占用或權限有關；網域解析失敗屬於 DNS；連線遭拒表示目標可達但連接埠未接受連線；逾時可能發生在本地網路、遠端鏈路或交握階段；驗證與交握錯誤通常需要核對伺服器項目的協定參數與系統時間。日誌包含伺服器位址或訂閱資訊時，分享前應刪除敏感內容。

建立可重複的故障定位流程

第一步檢查基礎網路：關閉客戶端後確認一般網路、DNS 與系統時間正常。第二步檢查客戶端程序：使用一個已知可用的設定啟動核心，確認沒有解析或監聽錯誤。第三步啟用系統代理，使用遵循系統設定的瀏覽器測試並觀察日誌。第四步比較全域與規則模式，判斷是否為分流問題。第五步才開啟 TUN，檢查虛擬介面與 DNS。每一步都建立在上一步成功的基礎上。

如果問題發生在網路切換後，先重新連線目前的作用中伺服器，因為舊 TCP 連線與舊 DNS 結果可能已失效。睡眠恢復後出現異常，則檢查核心程序、虛擬介面與系統代理三者是否仍一致。客戶端退出但系統代理未清除時，應用程式會繼續嘗試連線不存在的本機連接埠，表現為所有網頁立即失敗。此時清除系統代理比更換伺服器更直接。

訂閱與規則的更新頻率

訂閱不需要每次開啟客戶端時連續更新。依來源的變更頻率設定合理間隔，並保留手動更新入口。更新過於頻繁會增加請求失敗與清單頻繁重排的機率；長期不更新則可能保留已失效項目。多個分組可以錯開更新時間，避免同時發出請求。更新前正在使用的伺服器若被刪除，客戶端可能切換到其他項目，應在更新後確認目前選取項目。

規則資源更新後，集合內容可能發生變化。重要業務網域不應只依賴寬泛集合，可以加入更明確的高優先級規則。更新資源後抽查常用直連、代理與封鎖目標，尤其檢查內部網域與區域網路服務。若新資源導致異常，先使用自訂規則修正具體目標，再分析集合變化，不要直接堆疊多個互相覆蓋的規則套件。

安全處理設定與診斷資訊

訂閱位址、伺服器身分欄位與匯出的完整設定都可能包含帳戶資訊。保存備份時應限制存取範圍，傳送日誌時只保留錯誤上下文，並替換位址、權杖與身分欄位。不要把完整設定直接貼到公開討論區。需要展示問題時，通常保留協定類型、傳輸方式、錯誤階段與已匿名化的路由結構，就足以進行診斷。

遠端協助前先建立臨時備份，記錄系統代理與 TUN 目前狀態。完成後檢查訂閱分組、自訂規則與作業系統網路設定是否被修改。客戶端行為突然改變時，也應先比對本機設定，而不是只關注伺服器。更多具體症狀與復原步驟可查閱常見問題的故障排查分類。

CHAPTER 08

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

第一階段：固定一條最小工作鏈路

進階的起點不是增加參數，而是建立一條能穩定重現的最小鏈路。選擇一個客戶端、一台作用中伺服器、自動設定系統代理與一套簡單路由，記錄本機入站、預設出站與 DNS 行為。確認瀏覽器請求能進入日誌，直連與代理目標分別命中預期出站。之後每次修改都與這條基線比較，才能知道變更產生了什麼結果。

在基線階段不要同時使用多個客戶端、多個系統代理來源與多個 DNS 接管層。由 v2rayN 負責桌面連線時，讓它成為唯一修改系統代理的工具；Android 上只保留一個作用中的 VPN 工作階段。伺服器清單可以很多，但測試時只固定一個項目。若項目切換與設定修改同時發生，便無法判斷連線結果變化的原因。

第二階段：掌握設定物件與標籤

能夠閱讀完整設定後，重點理解 inbounds、outbounds、routing、dns 與 log。入站標籤可用於區分系統代理、TUN 或特定應用程式來源；出站標籤讓路由指向代理、直連、封鎖或其他鏈路；DNS 伺服器也可指定出站路徑。標籤名稱本身可以自訂，但引用必須一致。許多「規則未生效」問題實際上是標籤拼寫或作用域不一致。

閱讀客戶端產生的設定時，應將自動產生部分與使用者自訂部分分開。客戶端可能在啟動時重寫設定檔，直接編輯暫存檔案會在下次啟動時遺失。優先使用客戶端提供的自訂設定、路由規則或進階設定入口；確實需要外部維護時，先了解合併順序。若自訂物件與客戶端產生物件使用相同鍵名，後寫入的一方可能覆蓋前者。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

這段範例可作為設定結構練習，但未包含遠端代理出站，因此無法單獨完成代理連線。它展示了本機 SOCKS 入站、直接出站與封鎖出站的關係。實際客戶端通常會自動分配連接埠並產生遠端協定欄位，手動合併時要避免與現有入站發生連接埠衝突。監聽位址保持回環位址，可以限制區域網路裝置存取本機代理。

第三階段：讓 DNS 與路由採用相同意圖

成熟的設定會明確回答三個問題：某類網域由哪台 DNS 解析、DNS 請求透過哪個出站傳送、解析結果由哪條路由處理。只設定一個公共 DNS 位址並不能自動解決分流問題。可以依網域集合選擇 DNS 伺服器，讓直連網域透過直連 DNS 解析，讓需要代理的網域透過代理路徑解析，同時保留區域網路網域的系統解析能力。

調整 DNS 時先保留一條可用的備援路徑，並記錄瀏覽器是否使用獨立 DNS。測試應涵蓋網域首次解析、快取命中與網路切換。同一網域時好時壞時，檢查是否同時取得不同位址族、是否存在多個 DNS 回應，以及路由是否對 IPv4 與 IPv6 使用不同結果。停用某個位址族可作為定位手段，但長期方案應依目前網路與遠端能力決定。

第四階段：依入站與情境拆分策略

當系統代理、TUN 與應用程式專用連接埠並存時，可以透過入站標籤採用不同規則。例如系統代理維持日常分流，專用 SOCKS 入站預設走代理，TUN 則優先直連區域網路並處理 UDP。這比在一套超長網域清單中猜測應用程式來源更清晰。拆分時應為每個入站指定明確連接埠、用途與呼叫端，未使用的入站要及時關閉。

情境切換可以透過路由設定組實現，而不是反覆編輯單條規則。日常、除錯與全域代理可分別儲存為清晰預設，切換後在狀態列顯示目前模式。除錯結束應回到日常規則，避免長期保留全域狀態。多個設定組共用自訂規則時，要確認更新順序，防止某個預設仍引用舊資源。

第五階段：觀察連線而不是猜測連線

進階排錯應建立可觀測性。將日誌層級暫時提高到能看到路由與連線階段資訊，重現一次請求後立即恢復日常層級，避免日誌快速增長。記錄目標網域、解析結果、入站標籤、命中規則、出站標籤與最終錯誤，這六項通常能定位問題所在層。只記錄「打不開」無法區分應用程式未進入代理、DNS 失敗、規則直連或遠端交握失敗。

系統工具可以補充客戶端日誌。查看監聽連接埠確認核心是否接受連線，查看路由表確認 TUN 是否接管，查看 DNS 設定確認解析入口，使用連線測試確認目標連接埠是否可達。工具結果應與客戶端狀態一併解讀：目標連接埠可達不代表協定交握正確，日誌顯示核心執行也不代表應用程式已連線至本機連接埠。

第六階段：建立變更與回退紀律

每次只修改一個主要變數，是設定長期可維護的關鍵。修改路由時不要同時更換 DNS，調整 TUN 時不要同時更新客戶端，切換伺服器時不要同時改變傳輸參數。變更前匯出目前設定，變更後使用固定測試目標驗證；失敗時直接回退，而不是繼續疊加臨時修復。臨時修復一旦驗證有效，也應整理成明確規則並刪除重複項目。

設定文件應記錄目的，而不只是參數。例如「私有網段直連用於存取區域網路裝置」比單獨記錄 geoip:private 更有維護價值。未來規則資源或網路環境變更時，可以依目的重新實作，而不是機械式保留舊寫法。訂閱、路由、DNS 與 TUN 都應各自具備復原方法，避免其中一項損壞時重設全部設定。

推薦的持續學習順序

先熟練使用系統代理與最小路由，再學習訂閱分組與規則順序；接著理解 DNS、網域策略與出站標籤；基礎鏈路穩定後啟用 TUN，觀察虛擬網卡與路由表；最後再處理依應用程式分流、多入站與複雜 DNS。每個階段都應保留一套簡單設定作為對照。遇到新協定或新欄位時，先判斷它位於協定、傳輸、安全或路由層，再查閱對應文件。

需要快速完成一次連線時，回到快速上手主線；需要選擇平台安裝套件時前往下載頁；需要比較 v2rayN、v2rayNG 與 v2flyNG 的適用環境時查看客戶端比較。本手冊適合作為設定過程中的索引：先依現象定位章節，再沿資料路徑逐層檢查，不需要每次從頭重做所有設定。