V2Ray 設定手冊
從核心概念到 TUN

階段一 · 建立概念

核心概念與流量路徑

先分清介面、核心與伺服器

開始設定前，先將用戶端分成兩部分來看：圖形介面負責儲存伺服器、訂閱及規則；代理核心則讀取設定，負責監聽本機連接埠、處理連線並選擇出口。視窗能開啟，只代表介面正常，不表示核心已啟動。要確認連線是否可用，還得查看執行記錄、本機監聽狀態及實際連線結果，不能只看系統匣圖示或開關顏色。

V2Ray 是 Project V 代理生態系中的技術體系，V2Fly 延續相關核心的開發，Xray 則是另一條核心發展路線。v2rayN 是桌面圖形用戶端，可依版本功能呼叫不同核心；v2rayNG 主要採用 Xray 核心，v2flyNG 則使用 V2Fly 核心。用戶端名稱與通訊協定名稱並不相同，同一介面中的設定也不一定能在所有核心上運作。

沿著一次請求了解設定位置

常見的流量路徑如下：應用程式發出請求，系統代理或虛擬網卡將流量交給本機入口，核心依路由規則選擇直連、代理或阻擋，再由相應出口完成連線。遠端伺服器負責代理出口的伺服器端功能。安裝用戶端不會自動提供遠端服務；訂閱網址、伺服器資訊及使用權限須由使用者合法取得，本網站的下載頁面提供的是用戶端下載入口。

「節點」通常是圖形用戶端對一組伺服器連線參數的稱呼，包含位址、連接埠、通訊協定、身分驗證及傳輸安全設定。VMess、VLESS、Trojan、Shadowsocks 是通訊協定名稱；WebSocket、gRPC 等屬於傳輸方式；TLS 與 REALITY 則涉及傳輸安全。各項參數須與伺服器設定相互配合，不能只因兩個節點都標示 VLESS，就任意互換安全欄位。

建立最小化的驗證流程

第一次操作時，只設定一個明確目標：讓一個應用程式透過已選取的伺服器完成一次請求。先關閉其他代理工具，確認裝置時間正確，選好伺服器後再啟用系統代理。暫時不要同時修改 DNS、路由範本及 TUN。先確認最基本的連線路徑正常，之後新增的設定才有可靠的比較基準；否則多項變更交疊，很難判斷問題出在哪一層。

驗證時要分辨三種結果：核心無法啟動，先檢查本機設定、權限或連接埠；核心已啟動但代理連線失敗，接著檢查伺服器參數、訂閱狀態及網路連線；只有部分應用程式失敗，則檢查應用程式是否遵循系統代理，以及路由規則是否命中。介面上的延遲測試只能反映特定測試路徑是否成功，不能取代實際服務連線，更不等於下載速度。

階段二 · 選擇工具

選擇用戶端與安裝套件

桌面系統優先選用 v2rayN

在 Windows、macOS 和 Linux 上，建議優先使用 v2rayN，方便透過相近的訂閱、伺服器及路由管理方式處理日常設定。選擇時先確認作業系統，再確認處理器架構，最後核對套件格式。不要因為檔名較短或檔案較小，就判斷哪個版本比較適合；架構或執行環境不相容，通常會在安裝、啟動或呼叫核心時出現問題。

Windows 下載項目包含 Desktop 桌面版和經典 WPF 版。Desktop 採用跨平台介面，適合希望在不同桌面系統上維持相近操作方式的使用者；WPF 版沿用經典 Windows 桌面介面，適合熟悉原有工作流程的使用者。兩個版本的介面位置及相依元件可能不同，不能將某一版本的畫面截圖當成所有版本都適用的選單說明。

若沒有既有設定需要沿用，可以先選擇 Desktop，再依安裝套件的提示安裝所需執行環境。已在 WPF 版穩定使用的話，不必只為了介面差異立即換版。準備轉換版本時，先匯出必要資訊並記下目前設定；讓兩套程式使用不同資料夾，避免交替寫入同一個設定資料夾，也不要讓兩套核心同時占用相同的監聽連接埠。

Android 依核心與架構選擇

Android 優先選用採用 Xray 核心的 v2rayNG；若需要確認 V2Fly 的行為或使用相應設定，再考慮 v2flyNG。兩款用戶端可作為不同的測試環境，但不要同時啟動連線。系統通常只允許一個應用程式占用目前使用者空間中的 VPN 通道，後啟動的工具可能會取代原有連線，造成「開關還開著，實際流量路徑卻已改變」的誤判。

多數較新的 Android 手機採用 ARM64 架構，確認裝置支援後再選擇 arm64 套件。若不確定架構，可考慮通用版，再透過安裝結果及裝置資訊確認。應用程式安裝成功，不代表訂閱中的所有通訊協定參數都受支援：用戶端、核心與伺服器功能必須相互配合。遇到不支援的欄位時，應先確認功能需求，而非反覆更換通用安裝套件。

分清系統相容性與設定相容性

macOS 上，Apple Silicon 對應 ARM64，Intel 處理器對應 x64；Linux 上，deb 適用於相應的 Debian 系套件管理環境，rpm 則適用於相應的 RPM 套件管理環境。Linux 的 ARM64 套件也需要 ARM64 系統，不能只因發行版名稱相同就安裝 x64 套件。系統程式庫、桌面環境及權限管理的差異仍可能影響啟動，套件格式正確只是第一步。

選好用戶端後，先記下作業系統、架構、介面類型及核心類型，後續排除問題時會用到這些資訊。請從下載中心下載，避免混用不同來源的說明。若不確定訂閱的要求，請向提供者確認通訊協定及傳輸參數；本章的選擇原則是相容性與操作習慣，不是依用戶端名稱判斷伺服器品質。

階段三 · 準備執行環境

安裝、權限與本機監聽

先確保程式與核心穩定啟動

在 Windows 上，先將安裝檔或解壓縮後的程式放在固定資料夾，再啟動用戶端。若下載的是壓縮檔，請完整解壓縮後再執行，不要直接在壓縮檔預覽視窗中雙擊主程式。設定、記錄檔及核心檔案可能依賴相對路徑，暫存解壓位置容易造成設定遺失或找不到檔案。資料夾路徑盡量簡短，並避免放在需要特殊寫入權限的位置。

第一次啟動時若提示缺少執行環境，請依目前所選安裝套件的要求處理，不要直接套用其他介面類型的相依元件說明。安裝所需元件後重新啟動，並查看記錄中是否有核心啟動失敗、設定解析錯誤或監聽失敗。一般系統代理連線通常不需要長期以系統管理員身分執行整個用戶端；只有確實涉及虛擬網卡或安裝服務等需要權限的操作時，才依提示授權。

在 macOS 上安裝時，先將應用程式放入固定的應用程式資料夾，並透過系統提供的安全確認流程處理首次開啟提示。不要為了啟動單一應用程式而全面關閉系統安全機制。Linux 安裝後若介面無法開啟，先從終端機啟動程式或查看桌面啟動記錄，分辨是缺少圖形介面相依元件，還是代理核心發生錯誤；兩者的處理方式不同，重新匯入訂閱無法補上系統程式庫。

確認監聽位址與連接埠

在參數設定中找到本機混合監聽連接埠，並記下目前的數值。本手冊以 10808 為例，實際設定請以用戶端顯示為準。混合入口通常能辨識 HTTP 和 SOCKS 請求，但實際功能仍取決於用戶端及核心設定。初期只允許本機使用，監聽回送位址；若沒有明確的區域網路共用需求，不要啟用允許區域網路連線，也不要改成監聽所有網路介面。

若記錄顯示連接埠已被占用，先查明目前由哪個程序監聽，不要接連嘗試不同權限。以下指令只會查看連線及監聽資訊，不會結束任何程序。Windows 請確認結果中的監聽項目及對應 PID；Linux 請查看本機監聽項目；macOS 則使用系統內建的連接埠查詢工具。若沒有輸出，也要確認指令權限、查詢的連接埠是否與實際設定相符。

# Windows PowerShell
netstat -ano | findstr :10808

# Linux
ss -lntp 'sport = :10808'

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

確認衝突程序屬於舊版用戶端後，先正常結束舊程式；若屬於其他必要服務，則在目前用戶端改用未占用的連接埠。儲存設定並重新啟動核心後，再確認新連接埠已開始監聽。所有手動設定代理的應用程式也要同步更新連接埠。詳細排查方式請參閱本機監聽連接埠被占用的排查步驟，不要只憑程序編號就強制結束系統服務。

完成 Android 首次授權

在 Android 安裝後，第一次建立連線時會要求 VPN 授權。這是系統提供給本機流量接管使用的介面，不代表已連上遠端伺服器。完成授權後仍須查看用戶端記錄及實際連線結果。若安裝失敗，先分辨是架構不相容、系統版本限制、簽章衝突，還是檔案尚未下載完成；不要急著解除安裝舊版，因為解除安裝可能一併移除原有設定及訂閱。

階段四 · 管理連線資訊

匯入、更新訂閱與驗證節點

將訂閱網址加入訂閱群組

訂閱網址是用戶端取得伺服器設定的入口，通常包含存取憑證。複製時請保留完整網址，不要刪除查詢參數，也不要將連結貼到公開討論區。匯入前確認來源及使用權限，並檢查複製內容是否混入空格、換行、引號或通訊軟體附加的說明。訂閱入口需要能讀取設定內容，不是服務介紹網頁或需要互動登入的管理主控台頁面。

在 v2rayN 開啟訂閱群組管理，新增群組，填入容易辨識的備註，再貼上訂閱網址並儲存。返回主介面後，執行該群組的訂閱更新，確認伺服器清單是否增加。不同介面版本的選單名稱可能略有差異，但操作順序相同：先儲存來源，再取得內容，最後選擇伺服器。不要把訂閱網址誤填到手動新增伺服器的「位址」欄位。

v2rayNG 和 v2flyNG 可在訂閱群組設定中新增來源，再返回主介面更新訂閱。透過 QR Code 或剪貼簿匯入時，也可能只新增單一靜態伺服器項目，不一定會建立持續更新的訂閱。匯入後應檢查群組資訊，確認後續維護方式是更新訂閱，還是手動替換。群組備註只供管理之用，不會改變伺服器通訊協定或核心行為。

更新失敗時，先檢查回應內容

訂閱更新通常分為網路請求及內容解析兩個階段。若請求逾時，先確認連結是否仍可存取，以及目前更新是直連還是透過代理；若解析失敗，則優先檢查回應格式是否受支援。伺服器回傳的登入頁面、錯誤頁面或額度說明，即使網路請求成功，也不能匯入為伺服器設定。用戶端顯示更新完成後，仍須檢查項目數量變化及錯誤提示，不能只看操作是否結束。

若尚未建立可用的代理，第一次更新時優先嘗試直連。若目前網路確實無法存取訂閱入口，且已有可用伺服器，再改用代理更新。不要將訂閱來源設定為必須透過尚未匯入的伺服器才能存取，否則會形成啟動相依問題。更新前先保留仍可用的舊項目；若先批次刪除，一旦訂閱來源失效，就會同時失去可用連線及排查依據。

選定伺服器後再測試實際連線

匯入成功後，先選擇與目前核心相容的伺服器，並設為作用中項目。可先進行實際連線延遲測試，篩除明顯無法使用的設定，再透過瀏覽器或命令列驗證實際服務請求。測試結果會受到測試目標、DNS、網路路線及時間影響，不是固定的效能標籤。不要只選清單中數字最小的項目，也不要把單次測試失敗解讀為整份訂閱永久失效。

若同一群組中的大多數項目都失敗，先檢查裝置時間、訂閱有效性及通訊協定是否受支援；若只有單一項目失敗，再比對該項目的位址、連接埠、安全設定及傳輸參數。不要擅自修改訂閱自動產生的關鍵欄位來碰運氣，因為下次更新可能覆蓋變更。若要保留實驗設定，請另存為獨立的手動項目並清楚標記用途，避免與訂閱來源的內容混淆。

更新完成後，再確認作用中的伺服器項目是否仍存在。來源名稱變更或項目遭移除後，原先的選擇可能失效；群組篩選條件也可能讓清單看起來是空的。更多排查方式請參閱訂閱解析失敗與清單空白自查清單。本章完成條件是訂閱來源可正常維護、作用中的伺服器明確，且至少有一個項目通過實際連線驗證。

階段五 · 導入應用程式流量

系統代理、手動代理與全域模式

先用系統代理測試瀏覽器

選定作用中的伺服器後，在 v2rayN 啟用「自動設定系統代理」或相應功能。此功能會修改作業系統提供給應用程式讀取的代理設定，但應用程式仍可自行決定是否遵循。多數一般瀏覽器會使用此設定，但某些終端機工具、下載工具及遊戲採用自己的網路連線方式。若瀏覽器能連線、其他應用程式卻不行，先確認它們使用哪種接入方式，不要立刻更換伺服器。

「清除系統代理」通常會撤銷用戶端寫入的系統入口設定，不代表核心一定已停止；「不變更系統代理」則可能保留作業系統原有設定。各用戶端的選單細節請以實際介面為準。正常結束程式前，先還原不需要的系統代理，尤其是手動結束程序時：若系統仍指向本機連接埠，但監聽程式已停止，遵循代理設定的應用程式就會無法連線。

分清流量接管範圍與出口策略

「全域代理」容易造成誤解。在用戶端的路由設定中，它通常表示將進入核心的流量優先交由代理出口處理，不保證所有應用程式的流量都會進入核心。系統代理處理部分應用程式如何接入；路由模式決定已接入的連線如何出去；TUN 則會改變流量接管範圍。三者屬於不同層級，不能用單一「全域」按鈕概括所有行為。

若單一應用程式支援 HTTP 或 SOCKS 代理，可手動填入回送位址及本機監聽連接埠，明確指定該應用程式的接入方式，不必立刻擴大接管範圍。先確認應用程式要求的通訊協定，再填入位址；混合監聽入口不代表介面中的每個連接埠都能互換。不要將遠端伺服器位址直接填成一般應用程式的本機 HTTP 代理位址。

使用明確指定的代理進行對照測試

以下兩個指令會分別透過 HTTP 和 SOCKS 連線到同一個範例網站。連接埠須與目前的監聽設定一致；在 Windows 上使用 curl.exe，可避免部分終端機環境中同名指令造成差異。socks5h 會將目標網域交由代理端處理，但實際解析路徑仍取決於核心設定。指令成功代表這條請求路徑可用，不表示所有應用程式都已被接管。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

在 macOS 和 Linux 上，可將指令名稱改為 curl。先記錄明確代理測試的結果，再與瀏覽器比較：指令成功而瀏覽器失敗時，檢查瀏覽器擴充功能、個別代理設定或舊連線；兩者都失敗時，再檢查本機監聽及代理出口。不要用瀏覽器快取頁面判斷連線成功；必要時開啟新視窗，瀏覽先前未造訪的頁面。

Android 的 VPN 模式透過系統介面接收流量，應用程式代理設定也會影響實際接管範圍。第一次驗證時先不要排除測試用瀏覽器，連線後再依需求縮小應用程式範圍。本章完成時，應能分辨「應用程式未進入代理」與「已進入代理但出口連線失敗」。快速操作可參閱使用教學；遇到異常狀況，可依照常見問題逐項檢查。

階段六 · 控制流量出口

路由規則、DNS 與分流驗證

先使用內建模式，不要從空白規則開始

系統代理驗證成功後，再選擇用戶端提供的路由模式。初期優先使用內建範本，先弄懂「直連」、「代理」及「阻擋」的意思，再新增例外規則。直連表示由本機網路直接連接目標，不代表流量完全未經核心；阻擋表示主動拒絕符合條件的連線，並非連線故障。全域模式可用來比對診斷，但不必長期取代所有細緻規則。

路由規則通常依序檢查，由最先符合的規則決定流量路徑。若某個網域已符合上方較寬泛的規則，下方更精確的規則可能沒有生效機會。新增規則前，先寫清楚比對對象、預期出口及規則位置，再查看記錄。不要同時新增網域、位址範圍及程序三套彼此重疊的例外，即使連線恢復，也很難確認是哪一條規則發揮作用。

確認設定片段的適用範圍

以下是 V2Ray / Xray 路由片段範例，並非可獨立啟動的完整設定。此範例假設完整設定中已定義名為 direct 的直連出口，以及名為 proxy 的代理出口；此處只示範讓範例網域及私人位址直連。使用其他出口標籤時必須一併修改，也不要直接覆蓋圖形用戶端自動產生的設定，否則儲存時可能會重新產生內容。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

網域規則中的 domain:example.com 用於比對該網域及其子網域，不適合表示任意路徑條件。代理路由通常無法看到加密網頁中的實際頁面路徑，因此不能把完整網址當成網域規則填入。私人位址規則方便保留區域網路服務，但未涵蓋所有特殊用途位址；實際使用時應優先採用用戶端維護的完整範本，再依需求補充例外。

DNS 會影響規則可取得的資訊

DNS 負責將網域名稱轉換成位址，也會影響位址規則的判斷條件。範例中的 AsIs 不會為了比對 IP 規則而主動解析網域，但不代表整個連線過程完全不使用 DNS。若應用程式只將解析後的位址交給核心，網域規則未必能直接命中；反過來，若只有網域資訊而沒有解析結果，部分位址判斷也需要額外策略支援。

網域嗅探可在支援的流量中補充目標資訊，但無法從所有通訊協定還原網域，也不代表會解密應用程式內容。瀏覽器的安全 DNS、應用程式自行解析及系統快取，都可能讓實際路徑與預期不同。排查時先確認失敗是在解析階段還是連線階段，再決定是否調整解析策略；盲目更換公用 DNS，無法修正錯誤的驗證參數或未啟動的核心。

驗證分流時，分別選一個應直連的目標及一個應透過代理的目標，送出新的請求，並查看記錄中的目標及出口標籤。只看網頁最後顯示的位址並不足夠，因為頁面可能會使用多個網域。修改規則後應重新建立連線；既有連線可能仍沿用原來的路徑。每次只調整一項，並記下修改前後的設定摘要，失敗時才能還原。

階段七 · 擴大流量接管範圍

TUN 模式、權限與復原

先確認是否真的需要 TUN

只有應用程式不遵循系統代理，且沒有可用的手動代理設定時，才考慮使用 TUN。它透過虛擬網路介面將更大範圍的流量導入代理處理鏈，可接管許多一般代理設定無法直接處理的應用程式。TUN 改變的是流量入口範圍，無法修復失效的伺服器、錯誤的驗證資訊或不相容的通訊協定。一般系統代理尚未驗證成功前，應先解決基本連線問題，再增加這一層。

v2rayN 的 TUN 功能取決於目前版本、執行元件及作業系統，開關位置與服務需求也可能不同。啟用前記下目前使用的核心、本機連接埠、路由模式及 DNS 設定，並保留關閉 TUN 後的復原方式。不要只因舊教學沒有某個按鈕，就自行拼裝不明核心或替換程式檔案；請先確認目前安裝套件提供的功能及介面提示。

以單一入口進行首次驗證

第一次啟用前，先關閉其他代理軟體及非必要的虛擬網路工具。清除不需要的系統代理後，再依用戶端提示啟用 TUN，並完成必要的權限或服務授權。這樣才能判斷連線實際使用哪個入口。某些環境允許兩種入口並存，但首次驗證時不宜同時啟用；多個入口、虛擬網卡及自動路由一起變動，會大幅增加排查難度。

啟用後先查看記錄，確認是否出現虛擬介面建立失敗、權限不足、路由新增失敗或 DNS 繫結衝突。若介面未能建立，反覆更換伺服器沒有幫助。若介面已建立但所有連線都失敗，應先關閉 TUN，確認原有系統代理仍能正常運作；若關閉後恢復，表示基本出口大致正常，排查重點應放在流量接管路徑，而不是重新匯入所有訂閱。

一併檢查 DNS、UDP 及本機服務

在 TUN 環境中，DNS 請求可能經由系統解析、核心解析或虛擬位址對映等不同路徑，應以實際設定為準。不要直接複製其他核心的 DNS 欄位。若網頁能正常使用，但語音或遊戲等服務異常，應確認 UDP 從入口到代理出口是否都受到支援；啟用虛擬介面不代表遠端伺服器一定具備完整的 UDP 轉送能力。

區域網路印表機、網路儲存裝置及辦公室內網都需要保留正確的直連路徑。啟用後分別測試本機裝置與代理目標，確認兩者不會互相影響。企業網路可能會套用自訂 DNS 及路由，擅自覆寫可能影響內部服務；遇到此類環境，應先了解組織的網路規則。IPv6 也需要明確的處理策略，不能因 IPv4 測試成功，就假設所有網路位址版本都已正確接管。

Android 的 VPN 模式同樣透過系統介面接收流量，但不應照搬桌面虛擬網卡的驅動程式及系統管理員操作。Android 常見問題包括 VPN 授權、應用程式排除清單、背景執行限制及與其他 VPN 工具衝突。本章完成時，應能說明啟用 TUN 的具體原因，並驗證瀏覽器、目標應用程式及區域網路服務；關閉後也能恢復原有網路，不要讓開關長期維持在不明狀態。

階段八 · 維持正常運作

訂閱維護、記錄與分層排查

建立可重複執行的日常檢查

日常使用不需要頻繁修改設定。連線異常時，先記錄發生時間、目前網路、用戶端及核心類型、作用中的伺服器、接入方式與路由模式，再重複相同的連線測試。這些記錄有助分辨偶發網路變化與持續性的設定錯誤。若手機熱點與固定網路的結果不同，也能提供排查線索；但比對時不要同時更換伺服器和 DNS，否則無法判斷差異來源。

依來源建議或實際變化更新訂閱即可，不必每隔很短時間反覆送出請求。更新後檢查作用中的伺服器是否仍有效，以及本機例外規則是否保留。升級用戶端前先備份必要設定，並閱讀介面中的移轉提示；備份可能包含驗證資訊，應存放在安全可控的位置。不要將完整設定當成一般文件同步至公開空間，也不要把訂閱連結寫進排查筆記。

依本機、訂閱、節點、系統四個層級排查

第一層檢查本機：核心是否啟動、監聽連接埠是否存在、裝置時間是否正確、磁碟是否可寫入。第二層檢查訂閱：更新回應是否正常、作用中的項目是否過期或遭移除、通訊協定是否受支援。第三層檢查伺服器：位址與連接埠能否建立連線，驗證資訊及傳輸參數是否相符。第四層檢查系統：應用程式入口、系統代理、防火牆、虛擬網卡及 DNS 設定是否一致。

若記錄明確指出問題，可以提前聚焦處理，但不要略過證據。例如記錄已顯示監聽失敗，就先處理連接埠；顯示驗證失敗，就檢查身分資訊及裝置時間；只有特定應用程式無法連線，則優先檢查應用程式入口。節點連線逾時的處理方式，請參閱依四個層級排查連線逾時。逾時只描述結果，不代表問題一定出在遠端節點。

只保留必要時段的記錄

暫時提高記錄詳細程度，有助確認目標位址及出口路徑；但長期保留大量除錯記錄會占用磁碟空間，也可能記下存取目標。先找出失敗請求發生的時段，儲存必要片段後恢復一般記錄層級。分享記錄前，刪除訂閱、驗證資訊及私人目標資料，並保留完整錯誤前後文；只截取最後一行「失敗」，通常不足以分辨入口錯誤或遠端連線錯誤。

網路切換、系統休眠及背景清理都可能使既有連線失效。桌面系統先確認系統代理仍指向目前的監聽連接埠，再重新啟動核心以建立新連線；Android 則檢查背景執行限制及 VPN 狀態。不要一遇到異常就清除應用程式資料，否則會失去最有價值的設定比較依據。若重新啟動後暫時恢復，仍應記下觸發條件，不要把重新啟動當成已找出根本原因。

階段九 · 延伸與回顧

進階設定與持續學習方向

從容易解釋的規則開始擴充

完成前八個階段後，進階重點不是收集更多參數，而是讓每項設定都能說明理由、驗證結果並在需要時還原。先選定一項具體需求，例如讓特定網域直連、讓單一應用程式使用手動代理，或在切換網路後維持穩定連線。寫下預期的流量路徑，再找出目前設定與預期之間的差異。需求範圍越小，越容易完整測試，也越不容易影響其他正常服務。

學習設定結構時，先了解入站、出站、路由、DNS 與記錄之間的引用關係。標籤只是設定內部使用的名稱，必須與引用位置一致；不同核心中的同名欄位也可能有不同意義。圖形用戶端提供的進階設定，應優先透過介面儲存。只有在了解產生流程及覆寫規則後，再考慮自訂設定，以免下次按下儲存時手動變更遭到覆蓋。

切換核心時保持條件一致進行比較

v2rayN 支援多種核心，適合用來驗證相容性，但不要把切換核心當成碰運氣的修復按鈕。先確認新核心支援目標通訊協定、傳輸方式及安全欄位，再保持網路、伺服器與測試目標不變，只更換核心。記錄啟動結果及實際請求結果。若某項功能不受支援，應改用相容的核心或設定，不要刪除關鍵安全欄位來勉強通過解析。

移轉到另一台裝置時，也應分階段進行。先安裝符合系統及架構的用戶端，再重新建立訂閱並確認作用中的伺服器，最後移轉路由例外及接入設定。不要假設整個程式資料夾可以跨平台直接複製；檔案路徑、權限、介面名稱及系統代理機制都可能不同。移轉後至少測試一個直連目標、一個代理目標及一項本機服務，確認舊規則沒有沿用錯誤假設。

將設定實驗控制在小範圍變更

進階測試時，建議保留簡短的變更記錄，記下目標、修改項目、驗證結果及還原方式，但不要記錄實際驗證資訊。以下清單可直接作為每次調整前後的檢查順序。比起複雜的拓撲圖，這種方式更實用：結果不符預期時，能立即確認是否要還原，以及下一步只需修改哪一層，而不是繼續疊加新參數。

1. 確認這次只處理一個問題，並記下目前可用的基準設定。
2. 確認目標核心支援所需欄位，並保存修改前必要的設定。
3. 完成單項修改，重新建立連線，查看記錄中的實際路徑。
4. 測試代理目標、直連目標及區域網路服務，記錄受影響的範圍。
5. 若失敗就還原並重新測試；成功後再恢復一般記錄層級及日常使用。

遠端 DNS、網域嗅探、IPv6 及 UDP 都可作為下一階段的學習主題，但應分開研究。研究 DNS 時先固定接入模式及伺服器；研究 UDP 時先確認伺服器端支援；研究 IPv6 時同時檢查位址類型、解析及路由。若一次全部啟用，只會得到更難解釋的系統。設定項目越多，就越需要可供觀察的記錄及明確的測試目標。

效能評估也需要建立比較基準。延遲、建立連線所需時間、傳輸量及穩定性分別回答不同問題，不能用單次延遲測試代表整體使用體驗。下載速度慢可能是目標網站、網路壅塞、連線重複使用方式或裝置負載所致；只有固定測試條件並重複觀察，才適合進行比較。首次驗證的操作細節請參閱實際連線測試與代理生效驗證，不要把清單排序當成完整診斷。