V2Ray 進階設定指南

訂閱分組與伺服器篩選

區分訂閱網址、伺服器項目與目前使用的設定

訂閱分組用來儲存設定來源與更新選項，伺服器項目記錄實際連線參數，而目前使用的設定則是啟動核心時採用的項目。三者並非同一個物件。在清單中切換分組通常只會變更顯示範圍，不一定會切換目前使用的伺服器；選取某個項目也不代表它已設為目前使用的伺服器。修改後，先確認用戶端顯示的目前伺服器，再停止並重新連線，避免以舊連線的結果判斷新設定。

首次整理時，建議依來源建立分組，例如「主要訂閱」、「備用訂閱」、「手動設定」。在 v2rayN 的訂閱分組設定或 v2rayNG 的訂閱設定中填寫備註與訂閱網址，再執行該分組的更新。分享連結只包含一個或多個特定連線參數，不會自動提供持續更新功能。匯入方式的差異可參閱分享連結與訂閱網址說明，請勿將單一節點連結誤填至訂閱網址欄位。

使用備註篩選，不修改協定欄位

伺服器篩選只會影響清單顯示，不等於網路路由。搜尋「備用」只會縮小顯示的項目範圍，不會自動讓特定網站改走備用伺服器。先用一般關鍵字確認符合範圍；只有介面明確支援正規表示式時，才使用正規表示式。例如 ^(辦公|備用)- 表示備註以指定前綴開頭，但不能假設所有搜尋欄位都接受這種格式。包含與排除篩選條件如何組合，也應透過實際清單確認，以免隱藏所有可用項目。

篩選時最好使用穩定的備註前綴，而非暫時的延遲數值或容易變動的排序位置。訂閱更新可能改變備註、順序與項目數量；名稱相同的項目也可能使用不同的位址、連接埠或傳輸設定。判斷項目是否重複時，應比對伺服器位址、協定、連接埠與傳輸參數，而不只看名稱。使用者名稱、識別碼與金鑰都屬於敏感連線資訊，分享截圖或記錄檔前請先遮蔽；訂閱網址中的存取權杖也要一併處理。

更新失敗時，先保留現有項目

更新訂閱前，先確認該操作會不會先刪除舊項目，再匯入新項目。不同用戶端與更新方式的保留策略並不相同，不要依賴未經確認的行為。重要的手動項目應另外匯出備份，不要直接放在可能被重建的分組中。如果更新後清單變空，先確認回應內容是否為用戶端支援的訂閱格式，再檢查網址是否過期、是否回傳登入頁面，以及取得訂閱時使用的網路是否可用。

若遇到「目前代理無法使用，因此無法透過目前代理更新訂閱」的循環問題，請分別檢查取得訂閱的連線路徑與連線伺服器的路徑。只有在來源允許且本機網路可連線時，才改用不經代理的方式更新；不要反覆切換全域設定，導致原始狀態遺失。記錄失敗發生在網域解析、建立連線或解析內容哪個階段，還原舊設定後再逐項重試。更新成功只代表取得設定，不代表每個項目都能連線。

最後，建立一套可重複執行的檢查流程：確認分組名稱、清除篩選條件、比對更新前後的位址與重要參數，再手動選取目前使用的伺服器。先實際開啟一個網頁測試，再決定是否批次測試。測試會產生連線與流量，過於密集的批次操作可能觸發伺服器端限制。保留少數已驗證的備用設定，比依賴清單排序更容易在故障時還原。

路由規則實作：先比對，再選擇出站

確認規則順序與預設出站

Xray 路由規則通常會由上而下檢查，符合條件後便交由指定的出站處理。規則順序比清單是否整齊更重要：精確網域、指定應用程式入口或特殊目標應排在較廣泛的地區規則之前。編輯前先列出現有的出站標籤，確認 direct、proxy、block 確實存在。標籤是區分大小寫的參照名稱，不是固定保留字；使用不存在的標籤不會自動建立對應連線。

同一條規則中的不同條件欄位通常必須同時符合；同一欄位中的多個值則通常代表符合其中任一項即可。例如同時設定 domain 與 port，表示網域條件與連接埠條件都必須符合，而非網域或連接埠任一命中即可。若要讓「某個網域走代理，另外一批連接埠也走代理」，拆成兩條規則會更清楚。規則越複雜，越應先用一句話說清楚判斷條件，再寫入設定。

從一條精確網域規則開始

以下是 Xray 的 routing 局部設定，假設設定中已存在 proxy 與 direct 出站。範例先將文件測試網域交由代理處理，再處理中國大陸網域與私有位址。full: 只比對完整網域，domain: 則比對該網域及其子網域。範例網域僅用於說明語法；正式設定時應填入實際目標，不要用它測試服務是否可用。

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

geosite 與 geoip 是規則資料參照，不是即時線上查詢。對應檔案缺失、分類名稱不受支援或資料過舊，都可能造成載入失敗或比對結果不如預期。更新用戶端與更新規則資料是兩件不同的事。發生錯誤時，先用一條 full: 規則驗證路由架構，再恢復集合參照；不要同時更換核心、資料檔案和所有規則。

了解 domainStrategy 的解析時機

AsIs 不會為了路由判斷額外解析目標網域，適合以網域規則為主的情境。IPIfNonMatch 會在網域形式無法符合規則時嘗試解析，並使用取得的位址重新判斷。IPOnDemand 則可能在比對過程遇到需要 IP 的規則時進行解析。這些選項控制路由階段的行為，不會直接決定使用哪台 DNS 伺服器，也不等同於出站連線階段的位址選擇策略。

如果應用程式直接將 IP 位址交給用戶端，網域規則可能沒有可供比對的輸入。流量嗅探可以從部分 HTTP 或 TLS 請求中辨識網域線索，但無法還原所有協定的原始網域。加密交握、應用程式快取及純 IP 請求都會影響結果。排錯時先確認入口收到的是網域還是 IP，再決定使用網域規則、位址規則或依入口分流；不要只因規則名稱正確，就認定它一定會命中。

驗證時先清除應用程式的舊連線，指定一個明確目標重新發出請求，再查看存取記錄中的目標與出站標籤。瀏覽器重複使用連線，可能讓規則變更看起來沒有生效；重新啟動核心也不一定會清除瀏覽器本身的快取。若啟用記錄後產生大量項目，請縮小測試範圍並及時關閉詳細記錄。每次只驗證一條新增規則，確認命中後再擴大到網域集合，才能找出問題究竟來自順序、解析或標籤參照。

DNS 設定調整：分開檢查解析與連線路徑

辨識不同層級的解析請求

一個請求可能涉及系統 DNS、應用程式內建解析器、核心內建 DNS 與代理伺服器端解析。設定核心的 dns.servers，不代表所有應用程式都會使用它。系統代理主要影響遵循代理設定的請求；瀏覽器若啟用了自訂加密 DNS，也可能透過另一條路徑解析。先確認網域在哪個環節轉換成 IP，再討論應使用哪台解析器，否則很容易只修改到未參與目前請求的層級。

也要區分目標網站的網域與代理伺服器的網域。代理連線建立前，通常必須先取得伺服器網域可用的位址，這一步不能依賴尚未建立的同一條連線。如果伺服器位址使用網域，請先確保啟動解析路徑可用，再設定目標網域的分流解析。若強制所有 DNS 請求都經由代理，有時會形成啟動依賴循環，出現核心啟動正常、第一條連線卻始終無法建立的情況。

使用限定網域的解析器設定

以下 Xray 局部設定會優先將對應 geosite:cn 的網域交給中國大陸解析器，並保留一台通用解析器。expectIPs 用來檢查回傳位址是否符合預期範圍，不能驗證網站身分，也無法保證位址對應的線路最佳。此設定依賴相應的規則資料；只有確認本機網路可連線至這些 DNS 位址時，範例才有測試意義。解析請求實際使用哪條出站路徑，仍須一併檢查目前核心與路由設定。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "1.1.1.1"
    ]
  }
}

網域優先比對、預期位址篩選與後備查詢會共同影響結果，不能將伺服器陣列簡單理解成「第一台失敗後才用第二台」。新增解析器前，先確認目前核心支援哪些後備策略欄位，並透過記錄檔確認實際查詢行為。如果一台解析器已穩定回應，增加更多解析器可能只會增加等待時間與不確定性。對於明確要求單一路徑的網域，應個別設定比對範圍與後備行為，不要只憑陣列位置推測。

選擇一般 DNS、DoH 與位址家族策略

傳統 DNS 通常使用 UDP 或 TCP 的指定連接埠；DoH 則透過 HTTPS 傳送解析請求，可保護到解析器這一段的傳輸，但不能取代代理，也不會自動修正錯誤路由。若 DoH 位址使用網域，也要考慮其自身的啟動解析。只有在目前核心支援對應位址格式、網路可連線至端點且憑證驗證正常時，才啟用 DoH。不要為了消除錯誤訊息而關閉憑證驗證，這會改變連線的安全界線。

UseIP 允許依設定取得兩種位址家族；UseIPv4 與 UseIPv6 則會限制查詢方向。限制為 IPv4 可用來判斷故障是否與 IPv6 路徑有關，但不適用於所有網路，也不是永久解法。如果系統提供 IPv6 位址，但 TUN 只接管 IPv4，應用程式可能優先使用未被接管的路徑。應一併檢查 DNS 回應、系統路由與出站能力，而非只更換解析器位址。

排查「可以連線，但部分網域無法開啟」時，先分別記錄同一網域的系統解析結果與核心記錄，再確認是否命中預期的網域規則。系統查詢工具只能反映該工具使用的解析路徑，不代表代理請求內部的結果。接著重新啟動測試應用程式、清除其 DNS 快取或等待快取到期，再發起新連線。只重新整理用戶端清單不會清除所有層級的快取，舊位址可能還會繼續使用一段時間。

先保留一份只使用單一可連線解析器的基準設定。新增網域分流後，依序測試一般網域、指定集合，以及重新啟動後的首次連線。如果只有冷啟動時失敗，優先檢查啟動解析依賴；若長時間執行後才失敗，則檢查快取、網路切換與解析器連線狀況。分層測試比一次啟用 DoH、FakeDNS 和複雜後備規則更容易找出明確原因。

TUN 模式：檢查接管範圍與系統路由

區分系統代理、虛擬網卡與 Android VPN

系統代理會提供代理位址給應用程式，只有遵循該設定的程式才會使用。TUN 則透過虛擬網路介面接收系統交付的 IP 流量，再由相關元件轉換成代理請求。兩者的運作層級不同；啟用 TUN 不等於更換伺服器協定，也不保證所有程式都會被接管。桌面版建議優先使用 v2rayN 介面提供的 TUN 選項；實際處理元件與設定格式應以目前用戶端產生的結果為準。

Android 版 v2rayNG 通常透過系統 VPN 服務接收應用程式流量，其權限提示與桌面虛擬網卡的安裝流程不同。不要將桌面 TUN 設定檔直接匯入 Android 用戶端。v2flyNG 採用不同的核心架構，不能根據 v2rayNG 的選單推斷其功能。選定用戶端後，先確認一般連線可用，再單獨啟用系統接管，才能分辨故障來自伺服器參數還是本機流量入口。

啟用前先排除路由衝突

啟用前請先關閉其他正在接管預設路由的網路工具，並記錄現有的 VPN、虛擬機網卡與企業網路設定。多個元件同時修改預設路由、DNS 或防火牆時，問題可能會隨啟動順序而變化。若桌面系統要求提升權限，請依用戶端提示操作，不要反覆啟動多個執行個體來規避錯誤。虛擬介面建立失敗時，應先查看權限與驅動程式記錄，而非修改訂閱或更換協定。

特別確認代理伺服器本身的連線不會再次被送回虛擬介面。TUN 接管大部分流量時，必須為底層代理連線建立正確的繞行路徑，通常由用戶端自動處理。若手動新增系統路由或修改網卡綁定，可能破壞這項排除設定，造成流量迴圈。常見現象是啟用接管後全部中斷，關閉後立即恢復。此時請先還原自動介面與預設路由設定，再逐項恢復自訂項目。

分別測試 TCP、UDP 與區域網路

網頁能開啟只代表部分連線路徑正常，不能證明 UDP、即時音訊與視訊或區域網路存取也正常。TUN 能接收 UDP，後續仍須由出站協定、伺服器端與目標網路共同支援。測試失敗時，先確認請求是否進入用戶端，再檢查出站是否支援相應的網路類型。不要直接丟棄所有 UDP 來掩蓋問題；這可能讓應用程式改用其他傳輸方式，也可能導致部分功能完全無法使用。

存取區域網路裝置還涉及私有位址路由、防火牆與名稱解析。啟用略過區域網路規則通常只會處理連線流向，不會自動解決印表機探索或多點傳播。先使用裝置的實際私有位址驗證基本連線，再判斷探索協定是否受到接管影響。允許區域網路連線到本機代理，是另一項開放本機代理監聽的設定，與本機存取區域網路裝置不同；不要為了解決後者而任意開啟前者。

在 Android 上設定個別應用程式代理時，請明確選擇「只代理選取的應用程式」或「略過選取的應用程式」。即使清單相同，模式相反，結果也會完全不同。應用程式更新、重新安裝或工作資料環境都可能改變可選應用程式的範圍；修改清單後，請重新建立 VPN 連線再測試。部分系統會額外限制背景程序，若螢幕鎖定後連線中斷，先檢查系統電池與背景執行設定，不要直接歸咎於路由規則。

穩定性驗證應涵蓋啟用、停用、切換網路與休眠後恢復。每次都要觀察系統 DNS 與預設路由是否隨用戶端正確還原，避免留下無法連線的解析器位址。如果關閉用戶端後系統仍無法連網，先還原系統代理與自動 DNS，再檢查是否有殘留的虛擬介面設定。完整記錄接管前後的變化，有助於區分本機網路狀態問題與遠端連線問題，也方便切回已驗證的一般代理模式。

FakeDNS：管理網域對應，而非連線至虛擬位址

了解虛擬位址的用途

FakeDNS 會為查詢的網域指派一個虛擬 IP，並在核心中保存網域與位址的對應關係。應用程式之後連線至這個位址時，代理元件會依據對應關係找回網域，再進行路由與出站處理。虛擬位址不是目標伺服器的真實位址，也不能從任意網路直接連線。它的用途是讓後續只帶有 IP 的連線仍有機會還原網域資訊，前提是解析與連線都經過彼此配合的處理路徑。

因此，只在 DNS 設定中填入 fakedns 並不是完整方案。用戶端還必須將相關查詢交給 FakeDNS，確保虛擬位址範圍的連線受到接管，並讓入口能還原對應關係。在系統代理情境中，如果應用程式自行解析後繞過代理連線，可能會取得無法經由外部網路路由的位址。請先確認接管範圍，再啟用 FakeDNS；不要用它取代尚未正確設定的系統路由。

先確認位址池與嗅探功能

以下是 Xray 的 DNS 與位址池局部範例，僅展示欄位關係，不包含 TUN 接管設定。198.18.0.0/15 是用於基準測試的特殊位址範圍，常作為虛擬位址池，並非真實目標網站的網段。企業網路或其他接管工具也可能使用此範圍，若發生衝突，不能只擴大位址池，而應統一規劃。入口片段必須合併至真正接收相應流量的入站設定中，不能另建一個未被使用的入站來取代。

{
  "dns": {
    "servers": ["fakedns"]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

對於實際承接流量的 Xray 入站，嗅探設定可採用以下形式。destOverride 中的 fakedns 用於還原相關網域，routeOnly 則限制嗅探結果的路由用途。用戶端是否會自動產生這些選項，必須查看目前核心與產生的設定檔。若用戶端的 TUN 路徑由其他元件處理，就不能把這段 Xray 入站設定當成通用 TUN 設定語法。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "fakedns"],
    "routeOnly": true
  }
}

處理快取與對應關係的生命週期

對應關係的生命週期是排錯重點。應用程式可能會快取虛擬位址，但核心重新啟動後不再保留原有對應，因此舊連線只剩虛擬 IP，無法還原真實網域。可能出現剛啟用時正常，重新啟動用戶端後部分應用程式失敗的情況。先結束應用程式的舊連線並清除相關 DNS 快取，再重新查詢與連線。不要將虛擬位址保存成長期使用的伺服器位址，也不要複製到其他裝置上測試。

位址池容量用來控制可維護的對應規模，不代表並行連線數，也不是效能評分。長時間瀏覽大量不同網域時，對應項目替換與應用程式快取可能共同造成問題；盲目增加容量無法修復未受接管的連線。先在小範圍內確認查詢確實進入 FakeDNS，且連線確實回到同一條處理路徑，再觀察運作穩定性。確認基本流程正常後，再依核心說明與裝置資源評估是否需要調整容量。

有些應用程式會檢查解析結果、使用寫死的位址，或自行發起加密 DNS 查詢，這些行為可能繞過預期的對應流程。遇到單一不相容的應用程式時，先嘗試恢復真實 DNS 並保留其他路由設定，再比較結果。如果只要停用 FakeDNS 就恢復正常，應檢查對應流程，而非立刻更換訂閱。若部分網域需要使用真實解析，也要確保後續路由能處理真實位址，避免兩套判斷互相衝突。

驗收至少涵蓋首次查詢、重新啟動應用程式、重新啟動核心與切換網路四種情境。若記錄中持續出現虛擬目標位址，卻沒有還原網域，先檢查對應關係是否存在，以及入站設定是否正確；不要為虛擬位址新增直連規則。虛擬位址直接送往外部網路通常無法連上目標；正確的修復方向是恢復網域對應與接管的完整流程，而非擴大直連範圍。

多訂閱管理：區隔來源與更新策略

建立來源清單，不要全部混在同一份清單中

多訂閱管理的主要難題不在匯入數量，而在於設定來源、更新結果與目前使用的伺服器之間的關係。建議每個來源各自使用獨立分組，並記錄用途、取得方式及是否允許自動更新。備註應說明實際用途，不要依賴容易變動的節點名稱。手動維護的特殊設定應另放一組，避免在更新訂閱時遭到取代。需要比較兩個來源時，先在各自分組中測試，再決定哪一個作為主要來源。

訂閱可能會提供位址、連接埠、協定與傳輸參數，但不要假設它能控制用戶端的所有路由、DNS 或接管設定。不同訂閱格式的涵蓋範圍不同，有些只提供伺服器清單。匯入後請檢查實際變更，尤其是核心選擇與傳輸欄位。將來源設定轉換成其他格式時，也可能遺失原格式的部分功能；若解析成功卻無法連線，應回頭確認原始參數是否完整保留。

避免同名、去重與更新覆寫造成混淆

兩個來源都叫「備用線路」，不代表連到同一台伺服器；名稱不同也可能指向相同位址。去重前先確認判斷依據，至少比對協定、位址、連接埠、身分欄位與傳輸設定。若只根據位址與連接埠刪除項目，可能誤刪使用不同身分或安全參數的有效設定。如果不清楚去重功能採用的演算法，請先匯出備份，再對副本操作，不要直接清理唯一可用的清單。

手動修改訂閱項目時，應保留可追蹤的界線。暫時調整伺服器備註通常影響較小，但修改 SNI、傳輸路徑或公鑰後，下次更新可能會還原來源設定。需要長期保留的修改，應複製成獨立的手動項目，並註明原始來源與修改目的。不要以停用訂閱更新來掩蓋設定衝突，否則位址或服務參數變更後仍會使用過期內容，增加後續排錯難度。

分開處理更新、選用與故障切換

更新訂閱、測試延遲、選擇目前使用的伺服器是三種不同操作。訂閱更新成功不代表已完成切換；清單排序也不代表會自動選出最佳節點。即使是用戶端提供的自動選擇功能，也要確認觸發條件、測試位址與切換範圍。測試目標可連線，不代表所有服務都可連線；TCP 建立連線成功，也不代表完整請求成功。不同測試的意義請參閱延遲測試與下載速度測試的差異。

安排自動更新時，請避開需要穩定長連線的時段，並先確認更新是否會觸發核心重新載入。行動裝置切換網路或進入省電狀態時，排程工作可能延後執行，因此不要把自動更新視為準時保證。重要使用前，請主動檢查設定與連線狀態。若多個訂閱都透過同一條失效連線取得，備用來源也可能同時無法更新，請保留已驗證的離線設定備份。

訂閱網址通常具有存取權限，不應視為一般公開網頁連結。瀏覽器歷史紀錄、截圖、剪貼簿同步與匯出檔案都可能包含完整網址。分享設定時，只提供排錯所需欄位，不要公開訂閱網址與連線身分資訊。若懷疑網址外洩，請透過來源提供的管理方式更換存取憑證，再更新用戶端；只修改本機分組名稱不會讓舊網址失效，也無法阻止其他裝置繼續存取。

故障切換可依照固定流程處理：先確認目前的分組與伺服器，再檢查訂閱是否剛有變動，接著切換至已驗證的備用項目。切換成功後，保留故障設定的副本，以單獨測試還原原因，不要立即刪除整個來源。如果兩個獨立來源同時失敗，優先檢查本機 DNS、系統時間、網路權限與接管狀態。多個來源能降低部分故障的影響，但無法排除同一裝置上的共通網路問題。

自訂出站：管理標籤、預設流向與回復

先確認設定由哪個元件產生

出站描述核心如何與目標建立連線；路由則決定每個請求使用哪個出站。用戶端圖形介面通常會依目前使用的伺服器、路由模式與參數設定產生執行設定。直接編輯暫存的產生檔案，可能在下次啟動時被覆寫。進行長期自訂前，先確認用戶端是否提供自訂設定或對應的範本入口，並匯出目前結果作為比對。桌面版建議優先使用 v2rayN 圖形介面完成一般設定；只有介面無法呈現時，才改為維護完整設定。

Xray、V2Fly 與其他網路元件的設定格式不能只因欄位相似就互換。本節範例採用 Xray 風格的 JSON，並非所有用戶端都能直接匯入。自訂完整設定也可能略過用戶端的伺服器清單產生流程，因此切換清單項目後，連線目標未必會改變。儲存後請檢查實際啟動檔案、核心類型與記錄中的設定載入結果，先排除「修改的檔案並未被使用」這類問題。

從直連與阻斷出站驗證設定架構

以下是局部出站陣列；freedom 表示直連，blackhole 表示丟棄符合條件的流量。若沒有其他規則接手，第一個項目通常會成為預設出站，因此此範例預設為直連，並非完整的代理方案。若要加入實際代理出站，請沿用已由用戶端驗證過的正確連線參數，再讓路由參照對應標籤；不要自行拼湊伺服器身分資訊。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

標籤應簡短且穩定，並在同一份設定中保持唯一。將出站標籤從 proxy 改為 proxy-main 後，所有參照舊標籤的路由與其他相關設定也都必須同步修改。不要以顯示備註取代標籤，也不要讓兩個不同出站使用同一個名稱。維護時可先整理「入站標籤、規則條件、目標出站」對照表，再檢查每個參照是否都有定義；這比只看 JSON 縮排可靠。

區分串接、分流與自動回退

設定多個出站只代表有多種連線方式，不會自動進行故障切換。依目標將路由分配至不同出站，稱為分流；透過一個出站建立另一條連線，稱為串接；依據觀測結果選擇出站，則需要額外的選擇機制。三者不可混為一談。若沒有明確設定健康檢查與選擇邏輯，第一個代理出站失敗時，不會因為陣列中還有第二個就自動改用它；重複新增出站也不會提高可用性。

串接會增加依賴關係：前一段連線的 DNS、傳輸能力與穩定性都會影響後一段。若鏈路中的某一段不支援所需的網路類型，最終請求仍會失敗。先分別驗證每條出站都能單獨使用，再考慮串接，並確認目前核心支援相關欄位。不要同時加入多層串接、複雜路由與不同解析策略；一旦出錯，將難以判斷問題發生在哪一段，也難以取得有用的記錄。

以可還原的變更驗證最終設定

自訂設定應先驗證語法與載入結果，再進行實際使用測試。JSON 格式正確，不代表目前核心支援其中的欄位；欄位能載入，也不代表路由參照正確。遇到啟動錯誤時，依記錄指出的項目定位問題，不要直接刪除整段路由。先還原最近一次成功的版本，再一次只加入一個出站或一條規則。如果用戶端提供設定測試功能，請優先使用；若沒有，也要在重新啟動前保留原始檔案，以及可用來還原的圖形介面設定。

實際使用測試至少應選擇一個預期直連的目標、一個預期走代理的目標，以及一個明確阻斷的測試目標，分別觀察記錄與應用程式結果。阻斷規則應限於明確的網域或測試範圍，避免影響更新與解析請求。連線失敗時，從入口是否收到請求開始，依序檢查符合的規則、目標標籤、位址解析與遠端交握，不要只憑最後的逾時訊息就推斷伺服器故障。若要查看桌面版的記錄入口，請參閱v2rayN 主介面功能說明。

完成後，請一併保存有效設定、修改目的與驗證條件。記錄採用的接管方式、DNS 路徑與出站標籤，比只記下「可以上網」更有助於重現結果。匯出前移除不必要的敏感資訊，對外交流時另製作已去識別的副本。日後更換核心或用戶端時，先以原有基準設定驗證，再移轉自訂欄位。日常連線仍請依入門指南的連線與驗證流程操作，只保留確實需要且能說明用途的複雜設定。