V2Ray JSON 設定檔參考

01 / JSON 結構與連線路徑

設定檔描述的是核心行為

圖形化用戶端負責管理伺服器、更新訂閱、設定系統代理及啟動核心。核心設定則負責監聽連線、執行路由、解析網域與建立出站連線。兩者彼此相關，但不是同一份資料。用戶端主視窗儲存的伺服器資料，通常必須轉換後才能成為核心可讀取的設定；修改介面上的名稱，也不代表核心中的所有標籤都會同步更名。

先將連線路徑分成四個步驟：應用程式連線至入站，入站接收目標位址，路由選擇出站，出站建立後續連線。DNS 可能在比對路由或建立連線時參與。記錄檔會記下部分階段事件，策略則會影響連線逾時與統計行為。排查設定時應沿著這條路徑逐步檢查，不要一看到瀏覽器錯誤就直接更換所有 DNS 設定。

物件、陣列與欄位型別

JSON 物件使用大括號，陣列使用中括號。鍵名與字串必須使用半形雙引號，連接埠通常是數字，開關則使用不加引號的布林值。多餘的結尾逗號、全形引號或未閉合的括號，都會導致嚴格 JSON 解析失敗。部分核心或載入方式支援註解等擴充語法，但本頁範例採用嚴格 JSON，方便使用不同工具檢查。

頂層通常是一個物件。inbounds 與 outbounds 是陣列，因為可以同時宣告多個監聽入口與多個出口；routing、dns、policy 則是物件，分別包含規則或子設定。重複撰寫同名頂層鍵並不代表追加內容，不同解析器可能會覆蓋前一個值或拒絕讀取，因此應合併為唯一欄位。

以完整的直連設定建立參照

以下是用於檢查本機監聽的完整設定。它只會在迴路位址提供 SOCKS 入站，所有連線都透過直連出站傳送，不包含遠端代理伺服器。這裡的連接埠僅為範例，啟動前請確認沒有被其他程式占用。這份設定適合用來驗證「應用程式能否連上本機核心」，無法證明任何遠端節點可用，也不會自動變更系統代理。

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

閱讀範例時，先查看監聽位址與連接埠，再看入站協定，最後確認預設出站。沒有路由規則時，常見的處理方式是使用出站陣列的第一個項目。可見陣列順序不只是排版問題；用戶端重新產生設定後，也應再次確認預設出口，不能只檢查某個代理協定物件是否仍存在。

設定中的 tag 是供其他欄位參照的識別標籤，不是連線憑證。建議使用簡短、唯一且意義明確的名稱。檔名也不會決定檔案的作用：名為 config.json 的檔案，只有在目前核心程序實際載入時才會生效。查閱後續章節時，請保留一份可正常啟動的參照設定，每次只修改一個相關片段。

02 / inbounds：監聽位址與入站協定

先確認誰會連上這個入口

入站設定核心要在哪個位址與連接埠，接收哪一種連線。桌面應用程式最常使用 SOCKS 或 HTTP 代理，兩者不能只看連接埠就互換。應用程式選用 HTTP 代理，卻連到只接受 SOCKS 握手的監聽連接埠時，即使連接埠正在監聽，也可能立刻收到協定錯誤。排查時必須一併確認位址、連接埠與代理類型。

listen 用來決定監聽範圍。繫結至 127.0.0.1 時，入口主要供本機使用；改為監聽所有介面會擴大可存取範圍，也會受到系統防火牆與網路環境影響。遠端代理協定的加密，不會自動保護開放在區域網路中的本機 SOCKS 入口。除非確實需要共用且已設定存取控制，否則保留迴路監聽較容易限制存取範圍。

分別宣告 SOCKS 與 HTTP

以下片段並列宣告兩個入口。SOCKS 使用範例連接埠 10808，HTTP 使用範例連接埠 10809。連接埠不是軟體的識別標記，修改後必須同步調整應用程式設定。兩個監聽項目不能在同一個位址上共用同一個 TCP 連接埠；若其他用戶端仍在背景執行，請先確認是哪個程序占用，再決定關閉舊程序或改用其他連接埠。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

settings.auth 設為 noauth 時，SOCKS 入口不要求使用者名稱與密碼。這適用於受控的本機監聽，不代表可以任意對外分享。若需要驗證，請依照目前核心的 SOCKS 入站定義設定帳戶，並確認呼叫端支援相同的驗證方式。HTTP 入站使用不同的設定結構，不能直接套用 SOCKS 的驗證欄位。

udp 允許 SOCKS 入站處理相應的 UDP 請求，但不代表所有應用程式都能使用 UDP 代理。應用程式必須支援 SOCKS 的 UDP 轉送方式，出站協定與遠端服務也必須具備相應能力。僅設定作業系統的 HTTP 代理，通常不會讓任意 UDP 程式自動經由該 SOCKS 入口；兩者的差異在於流量進入的路徑不同。

嗅探資訊與原始目標

sniffing 會嘗試從支援的協定交握中取得網域等資訊。若應用程式只提交目標 IP，嗅探可能補上路由所需的網域。範例中的 destOverride 用來指定可覆寫目標的協定類別，但能否擷取資訊仍取決於實際流量。它無法解密所有應用程式內容，也不能保證每個連線都能還原最初造訪的網域。

啟用嗅探可能改變連線用於路由或出站處理的目標資訊。部分核心另有僅供路由使用的相關選項，欄位支援與細節需要另外確認。若啟用後某個應用程式發生異常，請先比較啟用前後的記錄檔與目標，再確認出站是否接受網域目標；不要直接將問題歸因於入站連接埠。

路由中的 inboundTag 也可以參照入站標籤，讓不同本機應用程式入口使用不同出口。此時應確保標籤唯一，並為應用程式明確指定入口。常見錯誤是修改入站名稱後，忘了更新路由規則中的參照，導致連線套用後續規則或預設出站，看起來就像入站設定沒有儲存。

修改完成後，請重新啟動或重新載入目前的核心，再確認監聽是否成功。系統代理開關屬於用戶端或作業系統層級，不會因新增入站物件而自動啟用。請參照快速入門流程，確認應用程式確實使用這個入口，再繼續排查出站與路由，能減少跨層反覆修改。

03 / outbounds：出口、標籤與協定參數

出站順序與路由參照

出站定義核心如何繼續連線至目標。它可以直接連線、封鎖連線，也可以透過某種代理協定連上遠端伺服器。tag 讓路由規則選擇特定出口；protocol 則決定 settings 的結構。名為 proxy 的出站不一定真的是代理，必須查看協定內容；反過來說，代理出站也可以使用其他唯一標籤。

在常見設定中，沒有符合規則的連線會交由陣列中的第一個項目處理。若要將代理設為預設路徑，應明確控制第一個項目，並保留必要的直連規則。除錯時不要為了方便閱讀而任意調整出站陣列順序。用戶端產生器可能會依目前伺服器與路由模式重新排列出站；最終應以正在執行的設定為準，而不是介面清單的顯示順序。

直連與封鎖的最小片段

freedom 表示透過本機網路直接建立連線，blackhole 則表示封鎖相應連線。以下片段可作為直連測試設定的出站部分，也能合併至包含代理出口的設定中。單純宣告封鎖出站不會自動封鎖任何目標；必須由路由規則選中它，或將它設為預設出站，才會產生相應效果。

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

直連不代表略過網域解析。目標為網域時，仍需要相應元件將它轉換成可連線的位址；實際使用內建 DNS 或系統解析，以及選擇哪種位址族，取決於目前核心與出站設定。路由中寫著「直連」，只表示選擇的出口，不能據此判斷解析請求經由哪條路徑。

不同遠端協定的欄位不能混用

代理出口需要有效的伺服器位址、連接埠與驗證參數。VMess、VLESS、Trojan、Shadowsocks 的憑證結構各不相同，傳輸層與安全層也各有要求。本頁不提供使用虛構帳戶的代理設定成品；實際使用時，請根據可信的連線資訊產生出站，再確認欄位與伺服器端一致。不能只替換協定名稱，卻保留另一種協定的使用者物件。

傳輸設定通常位於 streamSettings 等相應結構中。傳輸類型必須與伺服器實際部署一致，協定支援也受核心限制。不能把 REALITY 等功能視為所有核心通用且都能接受的欄位。選擇核心前，可先閱讀Xray 與 V2Fly 核心差異，再確認用戶端產生的設定是否適用。

伺服器位址、TLS 服務名稱與傳輸層主機欄位可能剛好相同，但代表的意義不同。伺服器位址決定連線目的地，服務名稱參與交握與身分驗證，部分傳輸標頭則供伺服器分流請求。遇到交握錯誤時，應逐項比對來源資訊，而不是把所有涉及網域的欄位都替換成伺服器 IP。

不要把略過憑證驗證當成一般修復方式。這無法解決協定不符、遠端連接埠錯誤或系統時間偏差，反而會改變身分驗證的安全界線。若出現憑證相關錯誤，請先檢查系統時間、服務名稱與憑證涵蓋範圍；若伺服器採用特殊部署方式，請先取得明確的設定說明，再調整安全選項。

最後檢查相依關係：路由所參照的每個出站標籤都必須存在，名稱大小寫也要一致。刪除舊伺服器產生的出站後，還要清除指向它的規則。若需要多個出口，先用兩個明確的出口完成驗證，再加入負載平衡、鏈式連線等額外機制；基本路徑尚未確認前加入巢狀設定，只會讓故障位置更難判斷。

04 / routing：比對條件與規則順序

由上而下選取規則

路由會依連線資訊選擇出口。常見欄位規則使用 type 為 field 的物件，並設定網域、IP、連接埠或入站標籤等條件。通常會依陣列順序逐一檢查，符合條件後就使用相應出口。範圍較小、優先度較高的例外應放在前面，較廣泛的規則放在後面，避免後續規則永遠沒有機會生效。

同一條規則中的不同條件欄位通常必須同時符合；同一個網域清單或 IP 清單中的多個項目，通常代表可擇一比對。若要達成「符合某個網域，或來自某個入站」，應拆成兩條規則，而不是把兩個欄位並列在同一個物件中。撰寫規則前，先用白話釐清條件之間是「且」還是「或」，再轉換成設定結構。

使用可控的目標驗證規則順序

以下片段會將範例網域交由封鎖出口處理，並將私人位址交由直連出口處理。它依賴上一章的 direct 與 block 出站，也要求目前核心能讀取相應的地理資料。範例網域僅用於驗證規則，不代表建議用於正式環境的清單。其他連線仍會交由預設出站處理，不會因為新增這兩條規則就自動變成全域代理。

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

網域比對應區分完整網域、包含子網域的網域範圍與正規表示式。例如 full:example.com 只會比對指定網域，domain:example.com 則用於該網域及其子網域。一般字串的比對方式與這些前綴不同，容易涵蓋比預期更廣的範圍。規則清單應使用能明確表達意圖的形式。

路由解析策略不等於出站解析策略

AsIs 通常不會為了比對 IP 規則而主動解析傳入的網域；若原始目標本來就是 IP，仍可比對 IP 條件。IPIfNonMatch 會在網域階段沒有符合項目時，嘗試解析並比對 IP。IPOnDemand 則可能在規則檢查需要 IP 資訊時提早發起解析。這三種設定控制的是路由判斷階段，不是完整的 DNS 流量方案。

以範例來說，傳入目標若是完整網域 example.com，就能符合第一條規則，不需要依賴後面的私人位址規則。若目標沒有符合網域規則，解析結果可能會用於 IP 規則比對。如果上方已有涵蓋範圍很廣的網域直連規則，後面的 IP 封鎖規則就可能不會執行；只修改解析策略無法修正規則順序本身的問題。

缺少規則資料時，核心可能在載入階段就回報錯誤；資料過舊或分類不符合預期時，則可能出現啟動成功但分流錯誤的情況。請先區分這兩種狀況，再決定要檢查檔案位置或規則內容。用戶端更新規則資料與更新伺服器訂閱是不同操作，訂閱更新成功並不能證明地理規則已更新。

若要將特定入口分配給某個出口，可以使用 inboundTag；若要依目標連接埠比對，則可使用目前核心支援的連接埠表示方式。建議先用單一條件驗證，再逐步增加組合條件。查看記錄檔時，應同時觀察目標與實際出口；只有目標位址符合預期但出口不符時，才將重點放在路由比對，而不是直接修改遠端協定參數。

所謂全域、規則或直連模式，通常是用戶端為產生設定所提供的一組預設選項，不是通用的獨立 JSON 欄位。切換模式後，應重新確認預設出站與規則陣列。若對分流結果有疑問，記錄具體目標、入口、符合條件與最終出口，比起只說「部分網站無法連線」更容易重現，也更適合比較後續修改結果。

05 / dns：解析來源、位址族與路由相依關係

先區分三種解析路徑

應用程式可能在連線至代理前自行解析網域，也可能直接將網域交給代理。核心也可能為了路由或出站連線使用自己的解析器，遠端服務則可能負責最後的解析。這些路徑可能同時存在。設定中有 dns 物件，不代表所有應用程式的查詢都由它處理，更不代表系統 DNS 已經被取代。

例如，應用程式先取得 IP，再將 IP 作為 SOCKS 目標時，核心收到的初始目標可能不含網域。此時網域規則能否使用，取決於嗅探等機制是否補上資訊。若應用程式將網域交給代理，路由與出站就能保留較完整的目標資訊。因此，比較不同應用程式的連線結果前，應先確認它們提交給本機代理的是網域還是已解析的位址。

基本的內建 DNS 片段

以下範例設定兩台一般 DNS 伺服器，並要求內建解析優先採用只查詢 IPv4 位址的策略。這些位址僅用於說明結構，不代表適用於所有網路的最佳選擇，也不會變更作業系統的 DNS 設定。DNS 服務的可連線性、適用網路與隱私需求應分別評估；填入一個位址不會自動建立通往該服務的可用路徑。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

servers 可使用簡單的伺服器項目，部分情況也支援包含網域範圍、預期位址等條件的物件。物件欄位的意義不等於「永遠只連線至這一台伺服器」，實際候選伺服器與回退流程仍受目前核心演算法影響。不要一次加入多個複雜選項；先確認基本查詢能正常連線，再逐項限制適用網域與回退行為。

位址族應符合實際網路環境

queryStrategy 用來控制內建解析的位址族策略。僅查詢 IPv4 可用來排查特定位址族問題，但不是解決所有連線失敗的通用方法。支援 IPv6 的網路也可能需要保留相應查詢。反過來說，系統取得 IPv6 位址，不代表連往遠端服務的 IPv6 路徑、代理伺服器與出站策略都具備相同能力。

網域最後選用的位址族，也會受到應用程式自行解析、出站解析方式與遠端處理影響。只修改頂層 DNS 查詢策略，無法保證所有連線都只使用特定位址族。排查時應比較解析結果與實際連線目標；若兩者不一致，先確認是否由其他解析器或遠端服務處理，不要繼續加入彼此衝突的 DNS 選項。

避免解析與代理形成循環相依

如果代理伺服器位址本身是網域，而解析器又必須透過尚未建立的代理存取，就可能形成啟動階段的循環相依。使用加密 DNS 且解析端點也是網域時，也要考量端點的初始解析。規劃時應明確決定哪個步驟負責引導解析、哪條路徑不依賴代理啟動，以及這些路徑在目前網路中是否確實可連線。

不同核心對 DNS 查詢的路由、標籤與本機解析模式可能有不同處理方式。不能只把加密解析位址複製到字串中，就認為查詢一定會經由指定代理出口。若需要遠端解析，應一併確認端點格式、支援方式與出站路徑；若使用系統解析，也要考量作業系統的快取與網路設定所帶來的影響。

測試 DNS 修改時，應用程式快取、系統快取與既有連線都可能掩蓋變更。先關閉測試頁面的舊連線，依平台提供的正常方式處理快取，再用同一個網域重新測試。不要用大量隨機網域取代有計畫的驗證。保留修改前後的解析目標與記錄檔，才能分辨是「解析結果改變」還是「出口改變」，兩者完全不同。

DNS 不是獨立於路由之外的效能調整開關。路由可能依賴解析結果，解析連線也可能受到出站路徑影響。先釐清相依關係，再調整網域規則或位址族；若基本連線尚未建立，應回到簡單的解析設定，而不是先加入複雜的網域分類、回退限制與多層轉送。

06 / policy：逾時、使用者層級與統計

策略依層級套用，不依顯示名稱套用

policy 用來設定連線處理策略與部分統計開關。levels 底下的鍵是使用者層級編號的字串表示；實際連線如何對應至該層級，取決於協定的使用者欄位或相關入站設定。用戶端群組名稱、伺服器備註與訂閱名稱都不是策略層級；修改這些介面文字不會自動切換另一組逾時參數。

未明確設定使用者層級的常見情況通常會使用第零級，但仍應確認目前協定與核心的行為。若需要分級，先找出對應使用者物件中負責層級的欄位，再將相同編號填入策略表。只宣告一個沒有任何連線使用的層級，不會對現有連線產生預期效果，也無法用來判斷策略是否正常支援。

逾時值代表不同階段的界線

以下數值皆為教學範例，不代表核心預設值。handshake 限制交握階段，connIdle 用於處理閒置連線，uplinkOnly 與 downlinkOnly 則涉及單向結束後的等待行為。常見欄位以秒為單位，實際意義應以所用核心的文件為準，尤其不要把它們當成測速或頻寬參數。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 8,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false
      }
    },
    "system": {
      "statsInboundUplink": false,
      "statsInboundDownlink": false
    }
  }
}

交握時間設得太短，可能在網路不穩或伺服器回應稍慢時提早中止；設得很長，也無法讓錯誤密碼或不相符的傳輸突然成功。遇到交握失敗，先確認記錄檔顯示的是逾時、驗證錯誤還是協定不符。只有確實在等待階段因時間限制而中止，且該路徑原本能完成連線時，才需要評估逾時界線。

閒置連線與持續傳輸連線並不相同。瀏覽器連線池、訊息長連線與終端機工作階段，可能有一段時間沒有應用程式資料；閒置限制設得太短，可能讓這些連線必須重新建立。若遇到「閒置一段時間後首次存取失敗」，應一併考慮應用程式重連、網路設備的連線維持與遠端行為，不能只憑時間間隔就判定問題出在本機策略。

單向結束不代表整個工作階段已結束

有些協定允許一端停止傳送後，另一端繼續接收剩餘資料。單向等待參數用來處理這類連線狀態，不是延長下載時間的開關。等待時間設得太短，可能截斷仍有用的收尾過程；設得太長，則可能讓無效連線保留更久。若沒有明確問題，保留核心預設策略通常比照抄一組「最佳化參數」更容易維護。

策略無法修復底層網路封包遺失、遠端拒絕連線或憑證服務名稱錯誤。若問題發生在 TCP 建立連線之前，調整協定交握後的閒置時間就無法解決。閱讀錯誤訊息時，應先辨認所屬階段：本機監聽、網域解析、遠端撥號、協定交握或穩定傳輸，各自對應不同參數，不應跨階段猜測。

統計開關與資料顯示管道分開設定

範例將相關統計開關明確設為關閉，僅用來展示欄位位置。啟用使用者統計通常還需要可識別的使用者資訊與相應統計功能；若要讓外部程式讀取資料，可能還需要統計物件、API 服務與受控的存取入口。只將某個布林值改成 true，不會讓用戶端介面自動顯示可用的統計面板。

統計欄位也不能等同服務供應商的計費資料。核心可能依特定層級統計連線流量，遠端服務則可能採用不同的計算方式。重新啟動、切換核心與清除狀態也可能改變本機累計範圍。若需要記錄，應先確認統計對象、時間範圍與重設條件，不要把本機觀測結果直接解讀為帳戶餘額或最終帳單。

穩妥調整策略的方式，是先保留預設值，只針對已重現的問題修改一項設定。記錄原值、預期改善的現象與重新測試結果；若沒有改善就還原。也要確認連線確實重新建立，避免仍使用舊連線的應用程式掩蓋效果。策略用於管理連線生命週期，應在確認基本協定與路由後再處理。

07 / 用戶端產生的設定、訂閱與 TUN

編輯的是來源資料還是執行中的設定

v2rayN 適合在桌面端管理伺服器與啟動核心；Android 主要使用 v2rayNG，v2flyNG 則可作為 V2Fly 核心方向的替代選擇。三者的介面設定與資料保存方式不完全相同，但都必須區分伺服器資料、用戶端偏好設定與最終核心設定。不能把一種用戶端的設定目錄結構直接套用到另一種用戶端。

用戶端自動產生的執行檔案，可能在切換伺服器、切換路由或重新啟動時遭到覆寫。直接編輯暫存檔，短時間內或許看得到變更，但不一定能長期保留。修改前應先確認入口屬於「自訂設定」、路由設定還是一般伺服器參數；若需要完整控制 JSON，請使用用戶端明確支援的自訂設定機制，並閱讀其適用範圍。

訂閱是伺服器來源，不是通用頂層欄位

訂閱連結通常用來取得伺服器項目或用戶端支援的設定內容，並由用戶端層負責解析。subscription 不是可以任意寫入 V2Ray 頂層物件的通用欄位。更新訂閱不代表核心已切換至新伺服器：用戶端可能已更新清單，但目前選取項目、作用中的連線與執行程序仍維持原狀，必須分別確認。

更新失敗時，先檢查連結是否完整、是否仍有存取權限，以及回傳內容是否符合用戶端接受的格式。若回傳登入頁面、錯誤訊息或空白文字，都可能造成解析失敗。不要將訂閱網址貼到公開頁面，也不要把包含存取憑證的查詢參數放進記錄檔截圖。完整排查流程請見訂閱更新失敗自我檢查清單。

TUN 涉及流量接管入口與配套路由

TUN 透過虛擬網卡將流量導入處理鏈。用戶端可能因此呼叫另一套支援此入口的核心或輔助元件，設定模型不一定是本頁介紹的 V2Ray 風格 JSON。不能只因介面上有 TUN 開關，就在設定頂層新增同名物件。請先確認目前 TUN 實際使用的元件、權限需求與設定格式，再查閱對應欄位。

系統代理主要影響遵循代理設定的應用程式；TUN 的涵蓋範圍則取決於系統路由、排除項目、位址族與接管方式。啟用後仍可能有流量未被接管，也可能因路由設定錯誤而導致網路異常。不要把「全域」理解為所有程式、所有協定都必定經過同一個出口；仍須配合分流規則與應用程式行為驗證。

TUN 情境尤其要避免將代理連線再次送回虛擬網卡。用戶端通常會負責設定必要的繞行路徑與排除項目，手動新增路由可能破壞這些設定。啟用後若核心本身無法連上伺服器，請先檢查是否發生循環接管，再檢查權限、網卡與 DNS。操作流程可參考v2rayN TUN 模式設定說明。

移轉設定時，先記下用戶端與實際使用的核心名稱，再記錄使用的協定與擴充功能。Xray 支援的某種出站或安全選項，不一定能直接由 V2Fly 讀取；同屬 Project V 生態系，也不代表欄位永遠相容。更換核心後，應重新驗證設定載入、交握與路由，而不是只確認視窗仍能開啟。

備份應包含復原時所需的來源資料，而不只是暫時產生的檔案。至少保留自訂規則、修改說明與必要的用戶端匯出內容，並妥善保護其中的伺服器憑證。分享排錯資料時，請用教學用假資料取代地址以外的敏感驗證資訊；替換後再檢查巢狀物件、備註與訂閱查詢參數，避免只遮住介面第一行。

需要重新安裝時，請從用戶端與平台下載入口選擇相應的系統與架構，不要只憑相似檔名判斷是否相容。安裝完成後，先還原最小設定，再逐項還原訂閱、路由與接管設定。若一次匯入所有舊設定後才開始測試，就無法判斷問題是來自用戶端環境變更，還是舊設定本身不相容。

08 / 設定驗證、記錄檔與回復順序

依失敗階段縮小排查範圍

排錯的第一步，是確認目前問題發生在哪個層級。視窗能開啟，只能證明用戶端介面正在執行；核心程序成功啟動，才表示設定至少通過相關載入流程；本機連接埠可以連線，也不能證明遠端驗證成功。分開驗證這些條件，可以避免 JSON 語法錯誤時反覆更換節點，或在應用程式未使用代理時不斷修改路由。

儲存前先進行靜態檢查：括號是否成對、字串是否有結尾、陣列項目之間是否漏逗號、欄位值型別是否正確。接著檢查結構語意：出站參照是否存在、規則資料是否可讀取、協定欄位是否受目前核心支援。嚴格 JSON 解析成功只能證明語法正確，不代表核心認得所有欄位，也不代表設定符合實際伺服器要求。

記錄等級先足以定位問題，再恢復日常設定

warning 適合減少一般執行資訊，但可能不足以觀察出站選擇。排查時可以暫時改為 info，必要時短時間使用目前核心支援的更詳細等級。不同等級顯示的事件有所不同；沒有看到某條記錄，不代表相應行為沒有發生。詳細記錄也可能包含目標位址，請在可控的時間內收集，並限制分享範圍。

{
  "log": {
    "loglevel": "info"
  }
}

這段只是替換記錄檔物件的片段，不是可單獨啟動的完整設定。若另外設定輸出檔案路徑，必須確認核心程序有寫入權限，而且該路徑位於目前的執行環境中。可攜式目錄、受保護的安裝目錄與行動裝置儲存權限可能有所不同。記錄檔為空時，先檢查輸出位置與權限，再判斷核心是否沒有產生任何事件。

常見現象的檢查順序

本機連線遭拒時，不必先檢查遠端 DNS。請確認目前用戶端未結束、核心沒有啟動後立即當機，且應用程式使用的是實際監聽連接埠。若有多個用戶端同時執行，請確認測試的是哪個程序。連接埠衝突常發生在背景程序仍存在時；只關閉可見視窗，不一定會停止相應服務。

遠端撥號逾時與驗證失敗應分開處理。前者優先檢查目標位址是否可連線、網域是否解析至預期位址，以及出站是否繞回自身；後者則應比對協定、密碼或使用者識別資訊，以及傳輸安全參數。連續更換多個無關欄位，會讓原本明確的錯誤變成多種問題疊加，也讓記錄檔失去比較價值。

只有特定目標異常時，請固定使用同一個應用程式與目標進行測試。檢查該應用程式是否略過代理、是否使用獨立 DNS、是否保留舊連線，再觀察符合的路由與最終出口。測速成功不能取代實際應用程式驗證，因為測試可能採用不同的目標、連線方式與路由條件。相關概念請參閱名詞解釋。

透過單一變因重新測試並留下回復紀錄

每次只修改一組具有直接因果關係的欄位。例如修改本機連接埠時，可以同步修改應用程式的連線連接埠；但不要同時調整 DNS、出站協定與路由模式。儲存後，依用戶端要求重新載入或啟動核心，再建立新的測試連線。既有長連線可能仍沿用舊路徑，重新整理頁面也不一定會建立全新的連線。

重新測試的紀錄應包含修改目的、原設定片段、修改後的片段、測試目標與記錄檔現象。不必記錄未經驗證的效能結論，也不需要長期保留所有記錄檔。能穩定重現的「某條規則選到了錯誤出口」，比缺乏背景的「網路變慢」更有參考價值。若結果沒有改善，請還原原值，再確認基準狀態仍可正常使用。

恢復日常使用時，盡量讓用戶端處理能穩定設定的一般選項，僅在明確需要特定行為時使用自訂 JSON。若不清楚操作入口，請參閱v2rayN 主介面說明；首次設定順序仍以入門指南為主。本手冊說明欄位及其適用界線，實際生效情況仍應以目前核心、執行中的設定與重新測試結果為準。