v2rayN 完整使用指南

一、核心概念：用戶端、核心與連線路徑

先釐清介面與執行層的差別

v2rayN 是圖形化用戶端，負責儲存伺服器參數、管理訂閱群組、設定代理入口並啟動核心。真正建立連線、解讀路由規則、處理協定與傳輸的是核心。介面正常開啟，不代表核心已啟動；核心正在執行，也不表示瀏覽器已將請求送進核心。了解這兩個層次，才能把「無法連線」拆解成可逐一檢查的環節，而不是反覆重裝整個用戶端。

Project V 是相關代理技術的生態背景，V2Fly 與 Xray 是彼此相關、但各自獨立發展的核心專案。不同核心支援的欄位、傳輸組合與擴充能力不盡相同。用戶端顯示某個協定選項，只代表提供了設定入口；能否正常運作，仍取決於所選核心、伺服器參數與目前使用的版本。遇到不相容時，應先核對這些條件，而非只比較協定名稱。

沿著請求的路徑理解各項設定

典型的桌面連線會依序經過應用程式、系統代理或應用程式內建代理、本機監聽入口、路由規則、出站連線與遠端服務。入口通常稱為入站，決定核心如何接收流量；出站則決定連線如何離開核心。常見出站包括代理伺服器、直接連線與封鎖。訂閱主要提供伺服器資料，路由規則則決定哪些請求使用哪些出站，兩者解決的是不同問題。

節點不是可以任意替換欄位的通訊錄項目。伺服器位址、連接埠、使用者識別碼、協定、傳輸方式與 TLS 參數共同構成連線條件。網域名稱可用來尋找伺服器，也可用於 TLS 服務名稱驗證，兩者不一定相同。傳輸中的路徑、主機名稱與服務名稱，也可能是伺服器比對條件的一部分。只有伺服器位址，通常不足以補齊其他參數。

區分協定、傳輸與加密各自的用途

VMess、VLESS、Trojan 的驗證方式與協定行為各不相同；TCP、WebSocket、gRPC 等則屬於另一層的傳輸選擇。TLS 為相關連線提供加密與身分驗證，REALITY 則有獨立的參數要求。即使協定名稱相同，只要傳輸方式或安全參數不同，連線仍可能失敗。檢視訂閱項目時，應依這些層次逐一核對，不能把某種協定直接等同於固定的加密或傳輸組合。

DNS 負責將名稱解析為位址，但解析發生的位置會影響路由結果。應用程式若先解析再連線，核心可能只看得到目標位址；若應用程式提交的是網域名稱，核心便有機會依網域規則處理。系統代理通常仰賴應用程式主動遵循設定，TUN 則透過虛擬網路介面接收符合條件的流量。兩種入口的涵蓋範圍不同，但仍可能共用相同的路由與出站，因此不能只憑入口判斷最終連線路徑。

進入下一章前，應能區分三種結果：用戶端已儲存設定、核心已接受設定，以及應用程式請求確實經過設定。第一項可在介面確認，第二項可從啟動輸出確認，第三項則須交叉比對執行日誌與應用程式測試。不熟悉術語時可查閱術語指南，但首次連線前不必掌握所有協定細節；先了解完整路徑，比記住所有欄位更重要。

二、選擇用戶端：平台、核心與使用情境

桌面平台優先選用 v2rayN

Windows、macOS 與 Linux 桌面平台，建議先從 v2rayN 開始。使用同一種用戶端有助於統一訂閱群組與故障排除習慣，但不代表三種系統的選單、權限與網路接管方式完全相同。操作時請以目前介面顯示的名稱為準；找不到某個開關，應先確認平台與使用中的介面，而不是直接照搬其他系統的設定目錄或權限操作。

Windows 下載區提供桌面版與經典 WPF 版。桌面版採用跨平台介面，適合希望在不同桌面系統上維持相近操作方式的使用者；經典 WPF 版保留傳統視窗配置，適合已有使用習慣的情境。兩者不是必須同時安裝的元件。初次設定時擇一使用，完成連線測試後再考慮是否遷移，避免兩個執行個體搶用監聽連接埠，或反覆覆寫系統代理設定。

Android 依需求選擇核心方案

Android 優先選用 v2rayNG，其常見核心方案為 Xray；v2flyNG 則是採用 V2Fly 核心的替代選擇。選擇時應考量現有伺服器參數與實際所需功能，而非名稱相似程度。若設定依賴特定核心功能，應先確認另一款用戶端是否支援。成功匯入只代表項目已解析並儲存，不代表執行層完整採用了其中所有擴充欄位。

安裝套件架構必須與裝置相符。多數較新的 Android 裝置採用 arm64，但仍須一併考量處理器與實際系統環境；不確定時，可查看系統資訊，或選擇下載頁提供的通用版。桌面平台也要區分 x64 與 arm64，macOS 則依 Apple Silicon 或 Intel 選擇。架構選錯通常會導致安裝失敗或程式無法啟動，不應誤判為訂閱或網路線路問題。

選擇時也要考量遷移成本

不同用戶端的訂閱網址或許能共用，但本機設定通常無法直接互通。系統代理、應用程式分流、路由範本、DNS 與 TUN 參數，都可能採用各用戶端專屬的設定格式。遷移時先匯入伺服器資料，再逐項重建行為設定。直接複製整個資料目錄，容易一併帶入不相容欄位、舊路徑或本機連接埠，反而讓新環境的問題更難查明。

也要考量裝置是否受組織管理、是否允許安裝虛擬網路介面，以及是否已在執行其他網路工具。若系統權限受限，可先使用應用程式內建代理或一般系統代理，不必把 TUN 列為安裝完成的必要條件。如果裝置已有正常運作的網路設定，請記錄原本的代理與 DNS 狀態。選擇用戶端無法繞過系統政策，也不應疊加多個工具來猜測是哪一層生效。

本章完成時，應選定一款用戶端、一個安裝入口與一種初始連線方式。桌面平台先以一般代理驗證；Android 則依系統提示授予所需的網路連線權限。前往用戶端下載頁依平台選擇安裝套件，避免在不同架構間反覆嘗試。記下選擇理由，日後遇到功能差異時，便能判斷是平台限制、介面差異或核心能力所致。

三、安裝與啟動：建立可復原的基礎環境

安裝前記錄網路基準狀態

安裝前先確認裝置在未啟用用戶端時的網路狀態。記下系統代理是否已有位址、是否設定自動設定指令碼、DNS 是否由網路自動指派，以及是否存在其他虛擬網路連線。測試一個原本可正常連線的網站，作為後續復原檢查的基準。若基礎網路本身異常，應先處理連線、驗證或系統時間問題，否則用戶端測試會混入與代理無關的故障。

依下載頁說明安裝對應平台的軟體。Windows 請擇一使用兩種介面版本；macOS 依晶片選擇安裝項目，再按系統提示完成安裝；Linux 則依發行版的套件管理方式選擇 deb 或 rpm，並確認處理器架構。若系統明確提示缺少執行環境，應依錯誤訊息處理，不要用不斷切換伺服器來掩蓋程式尚未正常啟動的事實，也不要關閉所有系統防護來反覆試錯。

首次啟動先確認核心狀態

程式開啟後，先找到執行日誌或啟動輸出區域，確認核心能否啟動，並留意是否出現找不到檔案、設定解析失敗或位址遭占用等訊息。不同版本的元件配置與執行條件可能不同，不能只因主視窗出現，就認定所有相依元件都已備妥。若核心立即結束，請保留最早出現的錯誤行；後續重試與連線失敗往往只是連鎖結果，應優先處理第一個明確錯誤。

本機監聽位址與連接埠應以目前設定為準。不要把教學中的常見數字當成固定預設值，更不要在其他程式中預先填入未確認的連接埠。若兩個用戶端同時使用相同的位址與連接埠，後啟動的程式可能無法監聽。先關閉多餘的執行個體，再檢查啟動輸出；確實需要調整時，請同時修改用戶端與使用該入口的應用程式，並記下新的對應關係。

目錄、權限與背景執行

用戶端的設定目錄可能因平台、安裝方式與版本而異，請透過程式提供的設定入口或開啟目錄功能尋找。不要把某台裝置上的路徑當成所有裝置通用的位置。儲存設定後重新啟動程式仍能讀取，才表示目前帳戶具備所需的寫入權限。若設定總在結束程式後遺失，應檢查是否不小心開啟另一份程式，或使用了不同帳戶與資料目錄。

一般系統代理與 TUN 所需的權限不同。初次安裝只需建立最基本的運作環境，不要立刻開啟開機啟動、自動更新訂閱與所有網路接管選項。Android 須依系統對話框授予網路連線權限；桌面版 TUN 則可能需要額外權限或元件。權限提示應與剛才執行的操作相符；若不清楚提示來源，先取消，再回到用戶端確認操作與日誌。

最後確認正常結束程式的流程。先停止網路接管，再退出用戶端，檢查系統代理是否恢復至預期狀態，並重新測試安裝前的基準網站。若退出後應用程式仍指向已停止的本機連接埠，需在系統網路設定中清除這次留下的設定，但應保留安裝前原有的組織設定。能啟動、能儲存、退出後能復原，才算完成基礎環境；後續的訂閱問題便可從這個基準獨立排查。

若啟動階段仍有疑問，可接著閱讀核心啟動失敗與連接埠占用排除指南。此時不必匯入大量伺服器，也不要同時更換多種安裝方式。保留清楚的錯誤紀錄與目前的安裝位置，比在同一裝置上堆疊多份程式更有助於找出問題。

四、匯入訂閱與管理群組：區分網址、項目與更新

分開處理訂閱網址與節點連結

訂閱網址是取得伺服器資料的入口，單一節點連結則描述一個具體連線項目。兩者雖然都能複製成文字，但匯入入口可能不同。在 v2rayN 中，先找到訂閱群組設定，新增一個容易辨識的群組，填入服務來源提供的訂閱網址並儲存，再更新該群組。選單名稱可能隨介面調整；重點是先建立群組，再讓用戶端取得並解析其中內容。

v2rayNG 與 v2flyNG 通常透過訂閱設定或新增設定入口管理來源。先確認要匯入的是訂閱還是單一設定，再選擇對應操作。剪貼簿內容若混入說明文字、換行、全形標點或通訊軟體附加內容，可能導致網址解析失敗。網址尾端的查詢參數也可能用於驗證，不可為了縮短文字而自行刪除；教學網址僅使用 https://example.com/sub?token=xxxx 這類明確標示的範例。

建立群組，避免覆寫自行修改的設定

群組名稱建議說明來源與用途，不要填寫存取憑證，也別使用容易變動的線路宣傳名稱。可將工作測試、日常使用與手動新增的項目分開管理。更新訂閱可能會重建群組內的項目；手動修改的別名或參數能否保留，則取決於用戶端的實作方式。需要長期保留的自訂項目應放在獨立群組，並記錄哪些欄位由來源維護、哪些由本機維護。

更新既有群組與重複新增群組是不同操作。前者會刷新該來源的內容；後者容易產生重複項目，讓之後的選擇與測試失去明確對象。更新後先確認是否出現解析錯誤、項目是否位於預期群組，以及原先選取的伺服器是否仍存在。來源刪除或更名後，可能需要重新確認目前選取項目；清單仍顯示舊名稱，不代表遠端仍提供相同服務。

依失敗階段找出更新問題

更新失敗時，先區分網址無法取得與內容無法解析。連線逾時、網域名稱解析失敗，通常發生在取得階段；若收到登入頁面、錯誤提示或不相容內容，則可能是在解析階段出問題。複製錯誤訊息時，請保留錯誤類型，但不要公開完整訂閱網址。一般瀏覽器能開啟某個頁面，不代表用戶端取得了可用訂閱；應確認回應內容的用途與所選匯入方式相符。

部分環境需要透過已可用的代理更新訂閱。若用戶端提供直接更新與透過代理更新兩種方式，請依目前連線狀態選擇。尚未建立可用代理時，依賴代理的更新可能形成循環：沒有伺服器就無法更新，沒有更新又拿不到伺服器。此時應採用來源提供的合適匯入方式，或檢查基礎網路，而不是盲目切換所有 DNS 與 TUN 設定。

訂閱轉換會增加一個可接觸原始資料的處理環節，也可能遺失目標用戶端不支援的擴充欄位。只有在來源格式確實無法直接匯入，且了解處理方與輸出格式時，才考慮轉換。不要把轉換當成排除連線故障的預設步驟。首次完成後，記下群組名稱、更新方式與測試項目；日後更新出問題時，便能比較是來源、取得路徑還是本機設定有所變動。

跨裝置遷移時，優先重新建立訂閱群組，不要透過公開截圖傳送網址。如需協助排除匯入問題，可在常見問題查看安裝與設定分類，並提供用戶端名稱、匯入方式與失敗階段。移除私人資料後再分享日誌，通常仍保留足夠的診斷資訊。

五、代理模式：系統代理、應用程式代理與全域路由

先決定應用程式如何連入代理

桌面平台首次連線時，建議先選定一台伺服器，再啟用系統代理。v2rayN 常見的設定項目是「自動設定系統代理」，用途是將系統支援的代理設定指向用戶端的本機入口。這並不會強制所有網路連線都進入通道。應用程式是否使用這項設定，仍取決於應用程式本身的行為、網路函式庫，以及是否另有擴充功能或獨立代理選項；設定成功與涵蓋所有流量，必須分開判斷。

瀏覽器通常適合用來進行首次測試，但擴充功能、獨立代理設定與自動設定指令碼都可能改變連線路徑。先減少這些變因，只保留一種明確的接入方式。測試時發出新的請求，觀察用戶端日誌是否出現對應連線。頁面仍顯示舊內容可能只是快取；瀏覽器能開啟網頁也不足以單獨證明請求經過代理，應一併檢查介面結果與執行日誌。

全域代理並非單一固定層級

使用者所說的「全域」，可能是指系統代理開關、路由中的全域代理模式，或透過 TUN 擴大接管範圍，三者不可混為一談。系統代理決定部分應用程式如何接入；路由全域模式決定已進入核心的流量如何選擇出站；TUN 則決定如何擷取更多連線。即使路由設為全部代理，不遵循系統代理的程式仍可能完全沒有進入核心，繼續使用原本的網路路徑。

若應用程式本身支援 HTTP 或 SOCKS 代理，可直接填入用戶端目前的監聽位址與連接埠。代理類型必須符合監聽入口，不能只因數字相同就認定協定一致。若僅供本機使用，監聽範圍應符合本機需求，不要任意開放區域網路存取。允許其他裝置連線會擴大曝露範圍，必須同時了解防火牆、存取控制與裝置所在的網路環境。

個別驗證終端機與背景程式

終端機程式不一定會讀取桌面系統代理；有些只辨識程序環境變數，有些則需要自行指定參數。不要看到瀏覽器測試成功，就認定終端機也已設定完成。反過來說，某個終端機程序成功，也不代表整個系統都已接管。環境變數通常會由程序繼承，修改後仍在執行的程式可能繼續使用舊值；請在新程序中驗證，並在測試結束後清除本次臨時設定。

若出現「瀏覽器可用、其他程式無效」，先檢查該程式使用的代理來源、略過清單與請求協定，再考慮是否需要 TUN。若用戶端完全沒有相關日誌，應先懷疑請求未進入入口；若已有連線紀錄但仍失敗，再檢查伺服器、路由與 DNS。更多排查步驟請見系統代理無效：瀏覽器與終端機排查，不要略過入口層直接修改遠端參數。

本章結束時，應保留一套最精簡的可用模式：一台伺服器、一個測試應用程式、一種入口，以及明確的路由選擇。切換模式前先關閉互相衝突的舊設定，切換後重新發出請求並核對日誌。也要測試關閉用戶端後能否復原，尤其要避免應用程式持續連線到已停止的本機連接埠。這個可重複使用的基礎狀態，是下一章加入複雜分流規則時的對照組。

六、路由分流：規則順序、網域比對與 DNS

流量進入入口後，才開始選擇出站

路由分流會處理已進入核心的連線，並依據網域、位址、連接埠等條件選擇出站。先使用用戶端現成的路由範本，例如「繞過中國大陸」，建立容易理解的基礎行為，再新增自訂規則。範本名稱只是摘要，實際結果取決於規則內容、資源資料與排列順序。若特定目標走錯出站，應檢查實際符合的條件，不能只憑範本名稱推斷所有連線都應如何處理。

規則通常依由上而下的順序檢查，第一條符合的規則會決定處理方式，因此越具體的例外通常越應排在前面。網域與位址條件不能完全互換：網域適合描述服務歸屬，位址則適合描述網路範圍。網域最後可能解析為多個位址，共用位址也可能承載多項服務。若為了修復單一網站，就把大範圍位址都加入代理，可能連帶影響原本無關的連線。

閱讀一段 V2Ray 路由設定片段

以下範例是用於合併至相容 V2Ray 設定的路由片段，並非完整的啟動設定。它會將私人位址交由直連出站處理，把相應的廣告分類交由封鎖出站處理，並宣告這兩個出站標籤。使用前須備妥相應的資源資料，並與原設定中同名的出站合併，不可重複貼上頂層欄位。圖形化用戶端可能會重新產生設定，建議優先透過內建的路由編輯入口設定相同規則。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

outboundTag 必須指向實際存在的出站標籤；標籤只是名稱，不會自動建立任何連線能力。geoip:private 用於比對相應的私人位址分類，geosite:category-ads-all 則會參照網域分類資料。若資源缺失或分類不存在，可能會導致載入失敗。規則中的標籤、欄位與資源檔案應一併檢查，不能只確認 JSON 語法正確。

網域策略與解析位置

IPIfNonMatch 表示網域規則未符合時，可解析目標網域，繼續比對位址規則；它不是指定 DNS 伺服器的欄位，也不等於強制所有應用程式使用核心 DNS。若應用程式提交的已是目標位址，路由取得的資訊可能與預期不同。排查網域規則未生效時，應確認入口實際取得的是網域還是位址，以及用戶端是否啟用了會影響目標辨識的相關功能。

設定 V2Ray DNS 時，必須一併考量解析伺服器是否可連線、查詢本身使用哪個出站，以及解析結果會用於哪些比對。更換 DNS 位址不會自動排除所有連線問題，也不保證現有快取會立即更新。先記錄原設定，再針對單一測試目標比對解析與連線日誌。使用加密 DNS 時，還可能需要先解析 DNS 伺服器的名稱；應避免讓這項前置解析又依賴尚未建立的代理路徑。

自訂網域常用 full: 表示完全符合，domain: 表示符合網域及其子網域。關鍵字與正規表示式的比對範圍較廣，應額外檢查是否誤中。先新增一條具體規則並驗證，再擴大範圍；詳情請見自訂路由語法與優先順序。本章的完成標準不是規則越多越好，而是能說明某個目標為何符合特定規則，也能刪除該規則並還原原本行為。

七、TUN 全域接管：權限、路由與衝突處理

先確認一般代理可用，再啟用 TUN

TUN 透過虛擬網路介面接收系統路由導入的流量，適合一般系統代理無法涵蓋的應用情境。它改變的是流量進入用戶端的方式，不會修復失效的伺服器，也不代表每條連線都必須走代理出站。啟用前應先完成一般入口測試，並保留可用設定；否則伺服器、介面與 DNS 問題同時出現時，很難判斷新增故障發生在哪一層。

用戶端中的 TUN 開關可能仰賴特定元件、執行權限與系統功能，不同平台的實作方式不可直接類比。v2rayN 的桌面接管方式，與 Android 系統提供的網路連線授權機制有所不同。請依目前用戶端的提示完成授權，接著檢查日誌是否確實建立介面與路由。開關顯示已啟用只代表介面狀態；若介面建立或路由寫入失敗，請求仍可能未進入預期路徑。

比較啟用前後的狀態

測試前先關閉其他可能爭用網路接管功能的工具，並記錄系統代理是否仍啟用。某些組合可以並存，但初次驗證時應減少入口數量。先選一個不遵循系統代理的測試應用程式，啟用 TUN 後發出新連線，再查看核心日誌。若該應用原本就透過明確指定的代理連線，測試成功並不能證明 TUN 已接管它；應改用能辨別入口變化的測試條件。

本機網路也應個別測試，包括路由器管理頁面、區域網路裝置與需要直連的內部服務。TUN 改變路由後，這些目標可能被意外送往遠端出站。應使用用戶端支援的排除或分流方式處理，不要不斷切換伺服器。私人位址直連規則通常有幫助，但不能取代對系統路由與裝置實際位址範圍的檢查；特殊網路環境也可能另有內部網段。

DNS、迴圈路由與既有虛擬介面

TUN 與 DNS 密切相關，因為應用程式可能仍向原本的系統解析器查詢，而虛擬介面又改變了查詢流量的路徑。是否需要接管 DNS，以及如何處理查詢，應依使用中的實作與用戶端設定確認。不要把其他核心的 DNS 欄位直接貼進目前設定，也不要同時啟用多個互相覆寫的解析方案。每新增一項解析設定，都應重新檢查網域解析與目標連線這兩個步驟。

另一項風險是代理本身的連線再次遭到擷取，形成路由迴圈。成熟的接管實作通常會處理自身流量，但手動修改路由、介面或出站綁定可能破壞這項前提。若啟用後用戶端突然無法連線伺服器，請先關閉 TUN，確認一般代理是否恢復。若一般模式可用、TUN 卻失敗，通常應優先檢查本機接管路徑，而不是立即重新匯入整份訂閱。

行動裝置還須留意背景限制、休眠與網路切換。若前景連線正常、鎖定螢幕後中斷，可能與系統省電或背景執行政策有關；從無線網路切換至行動網路後失效，則應比對切換前後的日誌與授權狀態。調整背景執行設定前，先確認系統提供哪些選項；不要把持續保持前景執行當成長期解法，也不要以反覆安裝取代對執行生命週期的觀察。

本章完成後，應能分別驗證一般入口、TUN 入口與退出後復原這三種狀態。記錄所需權限、保留的排除規則，以及是否同時使用系統代理。暫時不需要接管流量的裝置，維持一般代理也是完整設定，不必為了多開幾個開關而增加複雜度。TUN 的用途是解決明確的流量接入問題，不應成為判斷用戶端設定是否正確的唯一標準。

八、日常維護：更新、日誌與設定備份

分開處理不同項目的更新

用戶端程式、執行核心、訂閱資料與路由資源是不同的維護項目。程式更新會影響介面與設定產生方式；核心更新會影響協定與欄位的解讀；訂閱更新會變更伺服器項目；資源更新則會影響分類比對。若同時全部更新，出問題後就難以快速找出原因。日常維護應一次處理一種項目，完成基本測試後再進行下一項，並記錄更新前可用的狀態。

更新前，使用用戶端支援的匯出或備份功能儲存設定，並確認備份包含哪些內容。有些匯出功能只保存伺服器資料，不包含 DNS、路由與系統行為；有些備份則會包含訂閱憑證與使用者識別碼，應以敏感資料方式保管。備份的目的在於能夠復原，而不只是留下檔案。至少記錄復原入口、用戶端類型、設定儲存位置，以及哪些設定需要手動重建。

利用日誌判斷故障所在層

遇到故障時，先記下發生時間、測試應用程式、目標與最近一次變更，再查看核心啟動輸出與執行錯誤。啟動後立即結束，優先檢查設定與本機檔案；請求沒有紀錄，優先檢查入口；已有請求但連線逾時，再檢查遠端連線與出站；網域解析錯誤則回頭檢查 DNS 路徑。日誌是定位問題的證據，不應把所有含有「錯誤」字樣的紀錄都視為同一個根因。

存取日誌用於查看請求與路徑，錯誤日誌則記錄異常與執行問題，但用戶端可能會將兩者合併顯示。暫時提高日誌詳細程度有助於重現問題；測試結束後應恢復適合日常使用的等級，避免長期累積過多紀錄。分享日誌前，請刪除訂閱查詢參數、使用者識別碼與私人目標資訊，同時保留時間順序、錯誤類型及相關欄位名稱，兼顧問題診斷與資料保護。

單一變因重現與復原

先用一台伺服器與一個應用程式重現問題，每次只調整一個選項。變更後建立新連線，不要依賴既有長連線仍能運作的結果。記錄修改前後的差異，確認成功後再逐步加回其他應用程式與規則。若某項變更沒有改善，先還原再進行下一項；否則多次嘗試會留下難以解釋的設定組合，最後即使恢復連線，也無從得知哪些選項才是真正必要的。

訂閱中的延遲或連線測試，只能反映特定測試方式，不代表目標服務的整體使用體驗。某項測試失敗時，先確認它測的是連通性、交握過程還是特定請求。實際應用仍可能受 DNS、路由、UDP 或伺服器端政策影響。維護紀錄應寫明「哪個應用程式在什麼路徑下成功」，而不是只記一個測試數字，更不應據此推論整體網路效能。

更新後出現異常，先確認舊設定是否已遷移、目前執行的是哪一份程式，以及系統代理是否指向新的監聽入口。需要復原時，使用已儲存的設定與合適的安裝項目，避免新舊程式同時執行。若無法立即定位，先還原最精簡的可用模式，再依章節逐步加入路由與 TUN。如此既能恢復使用，也能保留穩定的比較基準。

不熟悉日誌欄位時，可查閱執行日誌訊息對照。本章的完成標準是備妥可復原的備份、一條可重現的測試路徑，以及一份已移除敏感資料的故障紀錄。維護不是不斷更換參數，而是確保每次變更都能解釋、驗證與撤銷，避免把偶然恢復誤認為已找出真正原因。

九、進階方向：協定界線與設定驗證

先確認設定由誰管理

開始進階設定前，先確認哪些內容由用戶端產生，哪些內容允許使用者長期維護。圖形化用戶端通常會依介面設定產生核心執行設定；直接編輯產生的檔案，可能在切換伺服器或重新啟動時被覆寫。優先使用自訂路由、範本或用戶端明確提供的設定入口。確實需要完整自訂設定時，應先了解它與訂閱、伺服器選擇及介面開關的關係，避免兩套設定來源同時控制相同欄位。

保留一套一般使用的工作設定，另外建立實驗設定，逐項測試想研究的功能。每次實驗都記下預期結果、觀察方式與復原步驟。例如研究網域規則時，固定伺服器、DNS 與入口，只修改比對條件；研究 TUN 時，固定已可運作的路由與出站。實驗目的不是累積更多選項，而是建立因果關係，讓日後發生故障時能依據證據縮小範圍。

分層學習協定參數

學習協定時，應分別了解驗證、傳輸與安全層。VMess 與 VLESS 的驗證與加密職責不同，不能只替換協定名稱就完成轉換；Trojan 也有自己的連線條件。WebSocket 的路徑與主機欄位、gRPC 的服務名稱、TLS 的服務名稱，以及 REALITY 所需參數，都應逐項與伺服器設定核對。來源未提供的欄位不要憑經驗猜測；能夠匯入，不代表所有組合都能在執行時正常運作。

協定相容性也會受到用戶端使用的核心與設定產生方式影響。網路上的設定片段可能採用另一種核心的欄位；即使 JSON 語法正確，在目前環境中仍可能出現未知欄位錯誤或產生不同語意。研究新功能時，先確認它屬於哪一種核心，再查看目前用戶端是否提供相應設定。可先閱讀VMess 與 VLESS 的差異作為基礎，再依實際設定逐層核對。

從規則驗證進一步建立易維護的設定

複雜規則應隨明確需求逐步增加，例如指定服務使用固定出站、讓區域網路維持直連，或封鎖特定分類。每條規則都應記下用途與預期符合範圍，並定期清理已失效的例外。大量重疊規則會讓順序難以推理；更新資源後，也可能改變比對結果。遇到無法解釋的行為時，將規則精簡為少數可驗證的項目，通常比繼續加入更寬泛的規則有效。

進階 DNS 測試也需要明確指定觀察對象。應用程式提出的名稱、核心執行的查詢，以及路由使用的目標位址，可能分屬不同階段的資料。應分別記錄解析失敗、解析結果不符預期，以及連線位址無法到達等狀況。修改解析策略後，舊快取與長連線可能仍沿用原有行為，因此應使用新連線重新測試；只重新整理一次頁面，不足以證明整條解析路徑已切換。

最後建立一組固定的回歸檢查：一般瀏覽器請求、原本不遵循系統代理的應用程式、區域網路存取、訂閱更新，以及結束程式後的網路復原。每次變更只測試新功能並不足夠；新增規則可能破壞舊路徑，新的 DNS 設定也可能影響訂閱取得。回歸檢查不必複雜，但條件應保持穩定，測試對象與成功標準也必須明確，才能比較調整前後是否真的改善。

完整掌握本指南的標準，是能說明連線從哪裡進入、依據哪些規則選擇出站、在哪裡解析名稱，以及失敗時如何復原。日後查閱時，可從常見問題依現象尋找解答，或回到快速入門教學重新建立最精簡的設定。保留一套可正常運作的基準，再逐項將實驗結果併入日常設定，比長期使用一份來源不明、難以解釋的複雜設定更容易維護。