V2Ray 從零到進階設定手冊

核心概念：用戶端、核心、協定與路由

先分清圖形用戶端與代理核心

v2rayN、v2rayNG 與 v2flyNG 首先是圖形用戶端，負責儲存訂閱、顯示節點、產生設定、啟動核心，並將系統代理或虛擬網卡切換至正確狀態。真正執行協定握手、加密傳輸、DNS 查詢與路由比對的是用戶端呼叫的核心。v2rayN 可在桌面平台使用 Xray 或 V2Fly 相關核心；v2rayNG 主要採用 Xray 核心路線；v2flyNG 則面向 V2Fly 核心設定。遇到「用戶端已開啟但網頁無法存取」時，不能只看視窗是否存在，還應確認核心是否啟動、監聽連接埠是否建立，以及系統流量是否進入該連接埠。

用戶端設定與節點設定也不在同一個層級。節點設定描述遠端位址、連接埠、使用者識別碼、協定、傳輸方式與安全參數；用戶端設定還包含本機監聽、系統代理、DNS、路由與記錄。訂閱通常只提供節點與分組資訊，不會替使用者決定所有本機網路策略。匯入訂閱後仍需選擇代理模式，必要時設定略過區域網路、中國大陸網域直連、遠端 DNS 或 TUN。分開理解這兩個層級，就能解釋為何同一份訂閱在不同裝置上都能連線，但分流效果不完全一致。

協定、傳輸與安全參數需要成組匹配

VMess、VLESS 與 Trojan 屬於節點協定層；TCP、WebSocket、gRPC 等屬於傳輸層；TLS 與 REALITY 則屬於連線安全及身分驗證相關設定。用戶端建立連線時，這些參數必須與伺服器端逐項一致。以 VLESS 設定為例，位址與連接埠正確並不代表連線一定成功；使用者識別碼、流控、傳輸類型、服務名稱、伺服器名稱、公鑰與短識別碼只要有一項不匹配，都可能表現為握手失敗、連線後立即中斷或測試延遲逾時。

REALITY 節點常見欄位包括伺服器名稱、指紋、公鑰、短識別碼與流控。伺服器名稱不是隨意填寫的備註，而是握手的一部分；公鑰必須由節點提供方提供；短識別碼依提供內容填寫；使用 Vision 流控時，協定、傳輸與安全設定也必須保持一致。匯入標準分享連結或訂閱時，用戶端通常會自動解析這些欄位。手動輸入只適合確認欄位來源時使用，不要把其他節點的參數拼接到目前節點。

入站、出站與路由構成資料路徑

入站表示用戶端在本機接收流量的位置，例如本機 SOCKS 連接埠、HTTP 連接埠或 TUN 虛擬介面；出站表示流量離開用戶端後的處理方式，常見標籤為代理、直連與阻擋；路由規則則決定每個請求交給哪個出站。瀏覽器使用系統代理時，請求會先進入本機 HTTP 或 SOCKS 入站，再由路由判斷直連或代理。開啟 TUN 後，更多應用程式流量會從虛擬網卡進入核心，但後續的路由與出站邏輯仍然存在。

路由通常依網域、IP、連接埠、網路類型或程序資訊進行比對。規則具有順序，先符合的規則會先執行，因此「規則內容正確」還不夠，也要確認它位於適當位置。區域網路位址與保留位址通常優先直連，明確需要阻擋的目標應放在直連規則之前，地區網域與 IP 規則則放在代理兜底之前。最後保留一個可預期的預設出站，避免未符合規則的流量落入不明確狀態。

用可觀察結果判斷目前層級

連線測試顯示成功，只能表示用戶端在特定測試條件下可以存取目標，並不代表所有應用程式都正常。瀏覽器可用但命令列不可用，通常應檢查程式是否讀取系統代理；網域無法開啟但直接連線已知 IP 有回應，優先檢查 DNS；區域網路裝置突然無法存取，優先檢查路由與 TUN 略過項目；所有節點同時失敗，應先查看本機網路、系統時間、核心啟動狀態與訂閱參數，不要逐一刪除節點。

記錄是確認問題層級的主要依據。啟動記錄用於確認設定是否被接受、連接埠是否被佔用、虛擬網卡是否建立；連線記錄用於觀察網域、目標位址、符合的規則與出站標籤；錯誤記錄用於定位解析失敗、握手失敗、逾時與權限問題。日常可將記錄等級設為 warning，排錯時暫時切換為 info；完成後恢復原設定，避免長期累積大量檔案。記錄中可能包含存取網域與節點位址，複製前請先刪除與問題無關的連線資訊。

選擇用戶端並完成安裝

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

Windows、macOS 與 Linux 桌面環境優先選擇 v2rayN。它將訂閱、節點、系統代理、路由、DNS、TUN 與記錄集中在同一套介面中，適合從基礎連線逐步進入分流與虛擬網卡設定。Windows 使用者可在桌面版與經典 WPF 版之間選擇：桌面版採用跨平台介面，適合希望在不同桌面系統維持相近操作流程的使用者；經典 WPF 版保留傳統 Windows 操作結構，適合已熟悉原有選單與系統匣行為的使用者。

Android 裝置優先使用 v2rayNG，節點欄位與 Xray 路線的相容性較完整；需要 V2Fly 核心設定時則選擇 v2flyNG。兩者都能匯入訂閱、選擇節點、建立本機 VPN 接管並查看記錄，但部分設定名稱與入口位置不同。遷移時不要只複製截圖中的開關狀態，應先匯出標準節點連結或重新新增訂閱，再逐項重建路由、DNS 與依應用程式設定的策略。

安裝前先確認架構與舊設定

下載前請在用戶端頁面選擇對應平台。macOS 需要區分 Apple Silicon 與 Intel；Android 近年的主流裝置通常選擇 arm64，無法確認時可使用通用版；Linux 則需同時確認發行版套件格式與處理器架構。檔名中的 x64、arm64、deb、rpm 都是選擇依據，不能只看應用程式名稱。系統架構不相容時，常見情況包括安裝程式拒絕執行、系統提示不支援該格式，或啟動後立即退出。

已有舊版用戶端時，請先記錄目前的訂閱位址、訂閱分組、路由規則、DNS 設定與本機連接埠。若用戶端提供設定備份功能，請將其儲存至個人文件目錄；若採用可攜式設定目錄，則在完全退出用戶端後複製整個設定目錄。升級時不要同時更換用戶端分支、核心類型與主要設定，否則出現問題後很難判斷變更來源。較穩妥的順序是先保留設定並完成用戶端更新，確認基礎連線後，再更新核心或調整路由。

完成桌面平台首次啟動

Windows 安裝後啟動 v2rayN，先檢查視窗底部或設定頁面中的核心狀態。若程式只顯示在通知區域，請從系統匣圖示開啟主介面。出現系統安全提示時，只授予實際需要的網路範圍存取權限。連接埠衝突通常發生在舊的執行個體尚未退出，或其他代理程式佔用相同監聽連接埠；此時先退出重複程式，再到 v2rayN 的本機監聽設定中確認 SOCKS 與 HTTP 連接埠未被其他程序使用。

macOS 首次啟動可能要求確認應用程式執行、網路存取或系統代理變更。完成授權後，先使用一般系統代理模式驗證，不要立即開啟 TUN。Linux 安裝後若主視窗可以開啟但系統匣沒有顯示，先確認桌面環境是否支援狀態圖示；即使系統匣暫時不可見，也可從主視窗完成訂閱與連線。Linux 上還應確認目前使用者對設定目錄具有讀寫權限，避免每次退出後設定無法儲存。

完成行動裝置基礎權限設定

Android 安裝 v2rayNG 或 v2flyNG 後，首次連線會要求建立 VPN 連線，這是系統將應用程式流量交給用戶端處理所需的權限，只要在系統彈出視窗中確認即可。若系統啟用了嚴格的背景限制，應將用戶端設定為允許背景執行，否則鎖定螢幕後核心可能被系統停止。雙 SIM 卡、熱點分享與工作設定檔環境會改變網路介面；切換網路後若連線中斷，可先停止再重新啟動連線。

首次安裝階段只做三項驗證：用戶端能正常開啟、訂閱或單一節點能夠儲存，以及連線後記錄沒有持續重複的啟動錯誤。此時不要匯入大量自訂規則，也不要修改所有 DNS 選項。先使用預設路由建立可重現的基礎連線，後續章節再逐步加入系統代理、分流與 TUN。若只想盡快完成第一次連線，可前往快速入門主線依精簡步驟操作。

匯入訂閱並管理節點

訂閱連結與單一節點連結的差異

訂閱連結用於持續取得一組節點及其更新內容，單一節點連結則只代表一個特定連線設定。長期使用時，應優先建立訂閱分組，而不是將訂閱內容逐條轉成手動節點。分組可以儲存更新入口、備註、篩選條件與獨立更新策略；節點位址、連接埠或安全參數變更後，只需更新訂閱即可。手動節點適合臨時測試或驗證欄位，不適合作為大量節點的主要維護方式。

在 v2rayN 中開啟「訂閱分組」，新增分組名稱與訂閱位址，儲存後執行「更新所有訂閱」或更新目前分組。分組名稱應表達來源或用途，不要依賴節點原始備註來區分。v2rayNG 與 v2flyNG 的入口通常位於訂閱設定或側邊選單，新增後先執行更新，再回到節點清單選擇目標。複製訂閱位址時請注意不要包含前後空格、換行或聊天軟體自動產生的說明文字。

更新失敗時依請求鏈路檢查

訂閱更新失敗與節點連線失敗是兩類不同問題。更新訂閱時，用戶端需要先存取訂閱位址並解析回傳內容；節點連線則使用解析後的伺服器參數。若訂閱更新失敗但舊節點仍可連線，表示現有設定仍可使用，應檢查訂閱位址是否完整、系統時間是否準確、目前網路能否存取訂閱入口，以及訂閱分組是否設定了錯誤的前置代理。不要先刪除舊分組，否則會失去可用設定與比對樣本。

如果訂閱更新必須經過目前代理，應先連線至一個已儲存且可用的節點，再為訂閱分組啟用前置代理；若訂閱入口可從本地網路直接存取，則維持直連更新會更容易排查。回傳內容無法解析時，請查看記錄確認是 HTTP 請求失敗、內容格式不支援，還是某個節點欄位異常。單一節點解析失敗不一定代表整份訂閱不可用，可保留成功項目並向訂閱提供方確認異常欄位。

用分組、備註與篩選控制清單規模

同時存在多個訂閱時，為每個分組設定穩定的簡短名稱，並讓節點備註保留可搜尋的結構，例如「地區｜線路｜協定」。篩選只會影響顯示或更新結果，不應修改節點協定欄位。v2rayN 可依關鍵字包含或排除節點，適合隱藏重複項目或只保留特定協定。規則應盡量簡單，使用一至兩個穩定關鍵字即可；過度依賴節點名稱中的臨時文字，會導致訂閱改名後清單突然變空。

自動更新間隔不必設定得太短。訂閱內容通常不會按分鐘變更，頻繁請求只會增加失敗提示與清單重新整理。日常可設定為啟動時更新，或依實際變更頻率設定週期。更新後先確認目前選取的節點是否仍存在；節點被移除時，再手動選擇新的項目。需要更完整的分組策略，可繼續閱讀v2rayN 多訂閱分組管理。

選擇節點不要只依賴單次測試

延遲測試用於快速判斷用戶端能否完成指定探測，但不等同於實際應用品質。不同測試方式可能測量 TCP 建立連線、HTTP 回應或完整連線流程，結果不能直接互相比較。選擇節點時先確認協定欄位完整，再執行用戶端提供的連通性測試，最後以實際需要存取的網頁或應用程式驗證。單次逾時可能來自本機網路抖動、DNS、遠端限流或測試目標暫時無法存取，應重新測試並比對記錄。

所有節點都逾時時，先選擇一個設定明確的節點作為樣本。檢查伺服器位址是否能解析、連接埠是否遭本地網路封鎖、系統時間是否偏差過大，以及核心是否支援節點使用的參數。若單一節點失敗而同一分組的其他節點正常，重點比較協定、傳輸、安全與備註以外的實際欄位；若所有訂閱同時失敗，則應重點檢查本機網路、核心啟動與代理迴路，不要逐一修改使用者識別碼。

{
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-1111-4111-8111-111111111111",
            "encryption": "none",
            "flow": "xtls-rprx-vision"
          }
        ]
      }
    ]
  }
}

上方片段用於說明 VLESS 出站欄位層級，網域與使用者識別碼都是範例值。實際使用訂閱時，應由用戶端依訂閱內容產生完整設定，不要將範例欄位覆蓋到現有節點。查看產生設定的主要目的，是確認介面中的位址、連接埠、使用者識別碼與流控是否進入正確層級，而不是將整份產生檔案改成長期手動維護。

選擇系統代理與代理模式

系統代理負責接入支援代理的程式

v2rayN 啟動核心後會在本機監聽 SOCKS 與 HTTP 連接埠，但僅有監聽連接埠並不會自動接管所有程式。啟用「自動設定系統代理」後，讀取作業系統代理設定的瀏覽器與桌面應用程式會將請求傳送至 v2rayN。關閉系統代理時，核心仍可繼續執行，手動指定本機代理連接埠的程式仍可使用。這項差異適合用來排查「用戶端顯示執行中，但只有部分應用程式可以連線」的情況。

系統代理模式適合瀏覽器、辦公軟體與多數遵循系統設定的應用程式，影響範圍清楚，退出用戶端後也容易復原。對不讀取系統代理的命令列工具，可在工具本身設定 HTTP 或 SOCKS 代理，而不是立即切換至 TUN。設定本機代理時，位址通常使用迴路位址，連接埠則必須與用戶端目前的監聽設定一致。不要將遠端節點連接埠誤填成本機代理連接埠。

全域、規則與直連模式對應不同路由策略

「全域」通常表示進入用戶端的流量統一使用目前的代理出站，適合判斷路由規則是否造成存取異常，也適合短時間驗證節點本身。它不是日常使用的必要選項，因為區域網路、印表機、本機開發服務或中國大陸資源也可能被交給代理。「規則」模式會依網域、IP 與其他條件選擇直連或代理，是長期使用時更常見的設定。「直連」則讓進入用戶端的請求直接存取目標，可用來確認問題是否由代理路徑引起。

排錯時可以採用固定順序：先切換至全域模式測試目標；全域可用但規則模式不可用，檢查路由比對；全域也不可用，檢查節點、DNS 與核心。直連模式可用並不能證明節點正常，只表示本機網路至目標的直接路徑可達。測試完成後應恢復原本模式，並在記錄中確認目標網域最終使用預期的出站標籤。

PAC 與系統代理例外項目需要明確界線

部分桌面環境允許使用 PAC 指令碼決定哪些請求進入本機代理。PAC 會在請求抵達核心前進行一次選擇，而用戶端路由則在請求進入核心後再次決定出站；兩者疊加會增加理解成本。需要精細路由時，通常讓系統代理統一指向用戶端，再由核心路由處理直連與代理會更清楚。只有在必須讓某些程式或網域完全不進入用戶端時，才考慮使用系統代理例外或 PAC。

區域網路位址應加入略過範圍，常見範圍包括迴路位址、私有位址與本地域名。如此存取路由器管理頁面、區域網路檔案服務或開發環境時，就不會繞行代理。請注意，區域網路服務的網域形式仍可能先經過 DNS；若解析結果不正確，僅加入 IP 略過規則並不能解決問題。此時應在 DNS hosts、系統 hosts 或本地域名解析服務中維持一致的記錄。

確認流量是否真的進入用戶端

不要只根據網頁能否開啟來判斷系統代理狀態。開啟用戶端連線記錄，存取一個先前未快取的網域，觀察是否出現新的連線記錄及對應出站。如果瀏覽器存取正常但記錄沒有變化，可能使用了瀏覽器內建的獨立代理、其他網路延伸功能或快取連線。若記錄出現請求但出站為 direct，應檢查路由；若記錄顯示 proxy 但隨後握手失敗，則應回到節點參數與遠端連線層檢查。

命令列環境可分別驗證直接解析、系統代理讀取情況與明確指定代理。不同工具對系統代理變數的支援並不一致，因此測試指令必須先確認自己使用的是哪條路徑。驗證完成後清除暫時環境變數，避免後續終端工作階段仍將軟體更新或套件管理請求傳送至已關閉的本機連接埠。日常設定的目標不是讓所有程式採用同一種入口，而是讓每類應用程式的入口清楚、可查看且可復原。

設定路由分流與 DNS

從最小路由規則集開始

常用路由目標是讓區域網路與私有位址直連、明確的中國大陸網域與 IP 直連，其餘流量使用代理。v2rayN 中可先選擇「繞過中國大陸」等預設規則，再依實際應用程式補充自訂網域。預設規則依賴 GeoSite 與 GeoIP 資料，前者依網域集合比對，後者依目標 IP 所屬位址範圍比對。網域規則能在解析前決定策略，IP 規則通常需要先取得解析結果，兩者應互相配合而非彼此取代。

最小規則集應先處理私有位址，避免區域網路請求進入遠端出站；再處理明確的阻擋項目；接著處理需要直連的網域與 IP；最後設定代理兜底。規則越多不一定越精準。大量重複網域、過期規則與彼此覆蓋的運算式會讓記錄難以解讀。新增規則時先寫入一個精確網域進行驗證，確認符合後再擴充為後綴或分類標籤。

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

domainStrategy 決定網域規則未符合時，是否繼續解析並嘗試 IP 規則。IPIfNonMatch 表示網域規則沒有結果時才解析 IP，適合同時使用 GeoSite 與 GeoIP 的常見情境。若設定為僅依現有 IP 處理，部分網域流量可能不會進入預期的 IP 規則；若對所有網域都預先解析，則會提高 DNS 的參與程度。修改策略後，應同時觀察解析記錄與路由記錄。

理解網域規則的比對範圍

精確網域只會比對指定主機；網域後綴可涵蓋其子網域；關鍵字比對範圍較廣，容易將名稱相似但用途不同的網域一併納入。優先使用精確網域或明確的分類標籤，只有在目標網域結構穩定且確實需要涵蓋多個子網域時，才使用後綴。對於內容傳遞網路，同一項服務可能呼叫多個網域，不能只根據網址列中的主網域建立規則，應從連線記錄確認實際請求集合。

路由判斷依賴用戶端看見的網域。若應用程式直接連線至 IP，網域規則就不會符合，只能使用 IP、連接埠或程序規則。啟用某些 DNS 映射機制後，核心可以恢復網域與連線之間的對應關係，但前提是 DNS 請求也由用戶端管理。出現「同一個網站有時直連、有時代理」時，請檢查是否存在不同子網域、IPv4 與 IPv6 結果差異、快取解析結果或應用程式自有的解析通道。

將 DNS 與路由視為同一條鏈路設定

DNS 的工作不只是將網域轉換為 IP，也會影響後續路由是否符合，以及請求是否受到本機快取或解析路徑影響。常見設定是讓中國大陸網域使用本地或中國大陸解析服務，其他網域使用遠端解析，並讓遠端 DNS 請求經由代理出站。這能減少網域解析結果與實際存取路徑不一致的情況。具體規則應依目前核心支援的 DNS 結構設定，不要同時在系統、瀏覽器、用戶端與多個網路工具中設定彼此衝突的解析策略。

排查 DNS 時先清除變數：關閉瀏覽器中的獨立安全 DNS 設定，保留用戶端 DNS；或暫時關閉用戶端自訂 DNS，只測試系統解析。一次只保留一條主要解析路徑。網域無法存取時，先確認記錄中是否出現查詢、回傳了哪個位址，以及該位址隨後符合哪條路由。解析成功但連線失敗，問題已進入傳輸層；沒有查詢記錄，則應用程式可能繞過了用戶端 DNS。

處理 DNS 洩漏、快取與 IPv6 分支

使用系統代理時，部分應用程式可能仍直接呼叫系統 DNS，這取決於應用程式的網域解析方式。若需要讓解析請求統一由用戶端處理，可使用用戶端的遠端 DNS、DNS 出站或 TUN DNS 接管。驗證方式包括瀏覽器檢測、系統指令查詢與用戶端記錄比對，具體步驟可查看v2rayN DNS 洩漏檢測與修復。判斷時應關注解析伺服器與請求路徑，不要只看最終回傳的 IP。

快取會讓修改看起來沒有生效。用戶端、作業系統、瀏覽器與應用程式都可能儲存 DNS 結果。修改規則後，先重新啟動相關應用程式或清除對應快取，再使用新網域建立連線。IPv6 可用時，網域可能同時回傳 A 與 AAAA 記錄；若本機 IPv6 路徑不穩定，應用程式可能優先選擇失敗的位址。應先確認系統是否具備正常的 IPv6 連通性，再決定保留、限制或為 IPv6 個別建立路由，不能只靠刪除一筆 DNS 記錄來長期掩蓋網路問題。

維護 GeoIP 與 GeoSite 資料

GeoIP 與 GeoSite 資料會隨位址分配與網域變化而更新。規則本身沒有修改，但分流結果逐漸偏離預期時，應檢查資料檔案是否能被目前核心讀取、更新程序是否完成，以及自訂檔案是否覆蓋了用戶端管理的版本。資料檔案與核心應保持相容；更新後先重新啟動核心，再從記錄確認分類標籤能夠載入。

手動替換資料檔案前，先退出用戶端並備份原始檔案，避免檔案仍被佔用。替換後若啟動記錄回報標籤不存在或檔案格式錯誤，應立即還原備份，不要繼續新增補償規則。完整的檢查位置、更新入口與還原方法請參閱GeoIP 與 GeoSite 資料更新指南。路由資料庫只是分類依據，最終仍需透過存取記錄確認目標是否符合預期出站。

啟用並校準 TUN 模式

明確判斷何時需要 TUN

TUN 模式透過虛擬網路介面接收作業系統中的 IP 流量，適合不讀取系統代理的應用程式、部分命令列程式，以及需要統一接管的情境。它的涵蓋範圍通常大於系統代理，因此也會將區域網路、軟體更新、背景服務及其他原本不經過代理的流量帶入路由判斷。只使用瀏覽器與一般桌面應用程式時，系統代理通常已經足夠；確認存在無法個別設定代理的應用程式後，再開啟 TUN 會更容易維護。

TUN 並不是提升節點連線能力的開關。節點本身握手失敗、訂閱欄位錯誤或遠端無法連線時，開啟 TUN 不會修復連線，反而會增加路由表、DNS 與權限等變數。正確順序是先在系統代理模式驗證目前節點，再開啟 TUN，並維持相同節點與基礎路由。開啟後若所有存取都失敗，可以直接比較開關前後的記錄與系統路由，不必重新懷疑訂閱內容。

開啟前檢查權限、介面與位址範圍

建立虛擬網卡與修改路由通常需要系統權限。v2rayN 顯示權限不足時，請依用戶端與作業系統提供的方式完成授權，不要反覆點擊啟動。系統中若已有其他虛擬網路工具，可能出現介面路由競爭、DNS 重複接管或預設路由來回切換。排錯階段先退出其他會修改系統網路的程式，只保留 v2rayN，再重新建立 TUN 介面。

TUN 使用的虛擬位址範圍不能與目前區域網路、企業網路或其他虛擬介面重疊。重疊時可能表現為部分位址無法存取、區域網路裝置失聯或請求迴圈。可先查看本機現有路由，再選擇用戶端預設且不衝突的位址範圍。Windows 可使用系統網路介面查看介面卡與路由；macOS 與 Linux 可透過系統網路工具查看介面。重點是確認預設路由、區域網路網段與 TUN 網段各自指向正確介面。

ip route
ip route get 1.1.1.1
resolvectl status

這些 Linux 指令分別用於查看路由表、確認指定目標經過的介面，以及查看目前 DNS 狀態。其他桌面系統應使用對應的系統網路查看工具。指令結果主要用來比較開啟 TUN 前後的變化：預設流量是否進入虛擬介面、區域網路網段是否仍由實體介面直連，以及 DNS 伺服器是否切換至預期入口。

設定自動路由、嚴格路由與略過項目

自動路由會讓用戶端建立將流量導向 TUN 的系統路由，通常應先使用預設值。嚴格路由會加強對旁路流量的限制，適合在確認基礎 TUN 正常後再測試。開啟嚴格策略後，本機服務、虛擬機器、容器或區域網路探索可能受到影響，因此應先建立私有位址與本機介面的略過規則。不要將所有私有位址交給代理出站，否則路由器、印表機與本機開發服務會無法存取。

依程序略過或納入可以縮小 TUN 的作用範圍，但程序名稱、子程序與系統服務之間的關係需要實際驗證。某個應用程式可能由啟動器啟動獨立程序，也可能將網路請求交給系統元件。只加入主程式名稱不一定涵蓋完整請求鏈。開始時使用一般路由規則驗證，確實需要依應用程式控制時，再配合記錄逐一加入程序，並保留預設出站作為兜底。

處理 TUN 下的 DNS 與 MTU

在 TUN 情境中，DNS 最好由用戶端統一處理，使網域、映射位址與實際連線保持關聯。常見做法是讓系統 DNS 指向用戶端提供的本機入口，再由核心依網域規則選擇本地或遠端解析。若系統仍同時使用其他 DNS，可能出現解析結果未進入核心、網域規則無法關聯或檢測結果不一致。切換 TUN 後，先查看 DNS 狀態，再進行網頁測試。

部分網路環境可能出現網頁開始載入，但大型檔案或特定請求停住的情況，這可能與 MTU 有關。TUN 封裝會增加額外負擔，而路徑中的部分裝置可能無法正確處理分片。排查時可在用戶端支援範圍內逐步降低 MTU，每次只調整一個數值，並使用相同目標重新測試。不要直接設定過低的值，過小的 MTU 會增加分片與處理負擔。若只有單一網路環境異常，也應與其他 Wi-Fi 或有線網路比較。

建立可復原的關閉流程

正常退出用戶端前，先關閉 TUN，讓用戶端撤銷虛擬介面、路由與 DNS 修改。系統異常關機或用戶端當機後，若網路仍無法使用，先重新啟動用戶端並正常開關一次 TUN，讓清理流程執行；仍未恢復時，再檢查系統代理、預設路由與 DNS。不要在不了解殘留狀態時連續安裝多個網路工具，這會讓路由來源更難判斷。

穩定的 TUN 設定應符合四項條件：開啟後基礎存取正常、區域網路仍可連線、DNS 請求進入預期路徑，以及關閉後系統網路完整恢復。完成這四項後，再新增嚴格路由、程序規則或複雜 DNS。TUN 使用中的常見問題也可回到快速入門頁查看基礎連線檢查順序，再結合本章定位系統接管層。

日常維護、備份與故障排除

分開更新用戶端、核心、訂閱與規則

v2rayN 圖形用戶端、代理核心、訂閱內容以及 GeoIP、GeoSite 資料，屬於四個獨立的更新項目。一次只更新一個項目，完成後驗證基礎連線與分流，再繼續下一項。如此遇到設定不相容時就能快速回復。用戶端更新主要改變介面與設定產生方式；核心更新可能改變協定實作或參數支援；訂閱更新會改變節點；路由資料庫更新則會改變分類結果，這些問題的表現各不相同。

更新前記錄目前可用的節點、核心類型、系統代理模式、TUN 狀態與自訂路由。備份重要設定，並保留最近一次確認可用的設定副本。更新後先使用原節點與原模式測試，不要立即清理舊設定。確認啟動記錄沒有解析錯誤、連線記錄正常後，再刪除過期備份。自動更新適合訂閱與一般資料；涉及用戶端分支切換或大範圍規則變更時，應手動安排。

依照「入口—解析—路由—傳輸」排錯

第一步檢查入口：程式是否讀取系統代理，或流量是否進入 TUN；第二步檢查解析：網域是否取得位址，DNS 請求是否經過預期路徑；第三步檢查路由：目標符合的是 direct、proxy 還是 block；第四步檢查傳輸：節點協定、連接埠、安全參數與遠端回應。固定順序可避免在 DNS 問題上反覆更換節點，也能避免節點握手失敗時盲目修改路由。

瀏覽器可用但其他應用程式無法使用，優先檢查應用程式入口；所有網域都失敗但已知 IP 可以連線，優先檢查 DNS；規則模式失敗但全域模式正常，優先檢查路由；所有節點突然失敗，先檢查本機網路、系統時間、核心程序與訂閱變更；單一節點失敗，則比較該節點欄位與同一分組中正常節點的差異。排錯時保留一個已知可用的樣本，比同時測試大量節點更有價值。

正確使用記錄等級與時間線

日常將記錄等級維持在 warning，可突顯啟動失敗、解析異常與連線錯誤。需要確認路由符合時，暫時切換至 info，重現一次目標存取後立即儲存相關時間段。記錄過多時，先停止連線、清空目前畫面，再重新啟動並只執行一個測試動作。如此可按時間串起啟動、DNS、路由與連線記錄，避免在大量背景請求中尋找目標。

錯誤訊息需要結合上下文解讀。timeout 表示在規定時間內未取得預期回應，可能發生於 DNS、TCP 建立連線或協定握手；connection refused 表示目標明確拒絕目前連接埠；name resolution failed 指向解析層；設定解析錯誤通常會提供欄位路徑或類型。複製記錄討論問題時，只保留錯誤前後必要的幾行，並移除訂閱位址、節點憑證與與問題無關的存取記錄。

維護系統時間、連接埠與背景狀態

TLS 與 REALITY 等連線依賴合理的系統時間。裝置時間明顯偏差時，憑證有效期判斷與握手都可能失敗，因此應讓系統自動同步時間。連接埠方面，本機 SOCKS、HTTP 與 API 監聽不能與其他程式衝突；更改連接埠後，應用程式內的手動代理也要同步修改。用戶端重複啟動時可能產生兩個介面執行個體，但只有一個能成功佔用連接埠，應透過程序清單與記錄確認。

行動裝置需要注意背景限制，桌面系統則需要注意睡眠喚醒、網路切換與系統匣退出。網路從有線切換至 Wi-Fi、從家庭網路切換至行動熱點後，舊連線與 DNS 快取可能仍然存在。遇到異常時先停止目前連線，等待舊工作階段釋放後再重新連線。長期使用 TUN 時，每次作業系統大版本更新後，都應重新驗證虛擬介面權限與關閉後的復原流程。

建立簡單且可復原的備份結構

備份至少應包含訂閱分組、手動節點、自訂路由、DNS 設定與用戶端偏好設定。檔名可使用日期與用途，例如「桌面基礎規則」、「TUN 穩定設定」，但不要將訂閱位址或節點識別碼寫入檔名。備份後應實際驗證能夠匯入或復原；只複製一個不完整的資料庫檔案，並不能保證有效。跨平台遷移時，優先遷移標準訂閱與規則思路，不要假設所有介面設定檔都能直接通用。

遇到複雜故障時，還原至最小設定通常比繼續疊加修補規則更快：關閉 TUN，使用系統代理；暫時使用預設 DNS；選擇單一已知設定；啟用全域模式；確認連線後，再依序恢復規則、DNS 與 TUN。每恢復一步，都重新測試同一個目標。DNS 專項問題可參考中國大陸與其他地區的分流解析設定，Linux 安裝與自動啟動問題可參考v2rayN Linux 安裝教學。

從可用設定走向易維護設定

先固定一份最小基準

進階設定的起點不是增加更多規則，而是保存一份能穩定重現的最小基準。基準應包含一個可用的訂閱分組、一個經驗證的節點、系統代理入口、簡單的私有位址直連規則、明確的預設出站與可觀察的記錄。它不必涵蓋所有應用程式，但必須能回答請求從哪裡進入、如何解析、符合哪條路由，以及使用哪個出站。

在基準上增加功能時，採用小步驟變更：先加入 GeoSite 與 GeoIP 分流，驗證後加入遠端 DNS，再驗證 TUN，最後才考慮程序規則、嚴格路由或複雜網域覆蓋。每一步都保留設定快照與測試目標。測試目標應涵蓋一般網頁、區域網路服務、需要代理的網域、直連網域，以及一個不讀取系統代理的應用程式，確保變更不是只解決單一情境。

理解產生的設定，再決定是否自訂

v2rayN 等用戶端會將介面設定轉換成核心設定。進階使用者應學會查看產生結果中的 inbounds、outbounds、routing、dns 與 log，但不要繞過用戶端，長期直接修改暫時產生的檔案，因為用戶端重新啟動或切換節點時可能會重新產生。正確做法是在用戶端提供的自訂設定、路由規則或預設入口中修改，再透過產生結果確認修改已寫入預期欄位。

查看設定時先追蹤標籤關係：路由規則中的 outboundTag 必須對應實際出站標籤；DNS 伺服器若指定出站，也必須存在對應標籤；入站標籤可用來限制規則適用範圍。欄位名稱正確但標籤拼寫不一致時，核心可能拒絕啟動或採用非預期路徑。陣列順序也很重要，尤其是路由規則、DNS 伺服器選擇與網域比對清單。

{
  "dns": {
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://resolver.example/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

這段片段展示依網域集合選擇 DNS 伺服器的結構，範例網域僅用於說明欄位。實際設定時，請確認目前核心支援對應寫法，並為解析服務安排正確的出站。skipFallback 會影響符合的伺服器失敗後的回退行為，不應在不了解結果時批次啟用。DNS 設定完成後，仍需結合路由檢查解析請求與目標連線是否採用一致路徑。

為不同網路環境建立設定界線

家庭網路、辦公網路、公共網路與行動熱點的 DNS、IPv6、區域網路網段及連接埠可達性可能不同。不要用一組強假設規則覆蓋所有環境。經常切換網路時，可準備「系統代理基礎」、「TUN 接管」、「保留區域網路」幾套設定，名稱應表達接管範圍而非地點。切換後先檢查目前預設路由與 DNS，再啟動用戶端，有助於減少舊介面殘留造成的問題。

辦公網路可能使用內部網域與私有 DNS，這些請求應留在本地解析路徑，內部位址則應直連。家庭網路中的儲存裝置、印表機與媒體裝置同樣需要略過私有網段。公共網路可能存在登入驗證頁面，連線至網路後應先完成本地驗證，再啟動代理或 TUN。驗證頁面無法開啟時，暫時關閉系統代理與 TUN，完成驗證後再恢復原設定。

用測試矩陣取代主觀判斷

可維護的設定需要固定測試矩陣。每次變更後依序測試：用戶端能否啟動；訂閱能否更新；已知節點能否連線；直連網域是否使用 direct；代理網域是否使用 proxy；區域網路位址是否可達；DNS 是否使用預期伺服器；關閉 TUN 後網路是否恢復。將測試結果記錄為「通過、失敗、未測試」，不要只寫「網路正常」。

出現回歸時，依首次失敗的項目回到對應層級。用戶端無法啟動就不要測試網頁；DNS 尚未確認時不要評估路由；區域網路失敗時檢查私有位址規則與介面；關閉 TUN 後未恢復時先處理系統網路。固定測試順序後，更新用戶端、核心或資料檔案都可以使用同一套流程複核，避免依賴記憶。

建立長期學習路線

完成本手冊後，下一步應先讀懂連線記錄與產生的設定，再深入網域策略、DNS 出站、TUN 路由與協定參數。協定學習應以欄位關係為主：VLESS 的使用者識別碼與流控、REALITY 的伺服器名稱與公鑰、傳輸層的服務名稱與路徑，都要結合實際節點設定理解。不要從蒐集大量設定片段開始，脫離用戶端版本、核心能力與伺服器端條件的片段很難直接重複使用。

日常維護重點在於可解釋性：知道目前節點來自哪個分組，知道系統代理或 TUN 是否開啟，知道主要 DNS 路徑，知道路由預設出站，也知道如何恢復基準。設定越複雜，就越需要減少隱含狀態。遇到具體問題時，先回到對應章節，再查看站內文章與快速入門頁的常見問題說明，依層級收集記錄與重現步驟。