V2Ray 設定檔參考.

01 / STRUCTURE

JSON 結構與設定生效範圍

先確認實際載入的檔案

設定檔描述核心如何接收連線、選擇出口及解析網域，但不包含用戶端的所有設定。v2rayN 的訂閱分組、介面偏好與系統代理選項由用戶端管理；核心通常只讀取用戶端產生的執行設定。排查前，請先確認目前選用的核心、執行目錄，以及日誌記錄的設定檔路徑。磁碟上可能有多份名為 config.json 的檔案；修改未載入的副本，不會改變目前的連線行為。

JSON 頂層通常是一個物件，各模組以鍵名區分。inbounds 與 outbounds 是陣列，因為同一個程序可以接收多種本機入口，也可以有多個出口；routing、dns 和 policy 則是物件。請勿只憑介面上選項的排列位置推測巢狀關係。欄位即使拼寫正確，若放錯層級也可能被忽略，或導致核心拒絕載入。

從最小可運作設定理解模組關係

以下是 SOCKS 本機入站連至直連出口的基本設定，不包含遠端代理伺服器。這份設定用來確認本機監聽、接收請求與直連出站能形成完整流程。應用程式必須主動使用這個 SOCKS 入口，流量才會進入核心。範例中的兩個 tag 是設定內部名稱，可自行命名，但所有引用處都要一併修改；標籤不是協定名稱，也不會自動建立對應出口。

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

讀取這份設定時，請先沿著請求方向檢視：應用程式連至本機監聽位址，入站解析 SOCKS 請求，路由決定出口，出站再建立目標連線。若未設定個別路由規則，通常會由第一個出站作為預設出口。新增第二個出站不代表流量會自動分流，必須由規則或其他明確機制指定。先了解這項預設關係，比背下大量參數更有助於判讀實際情況。

嚴格區分語法正確與語意正確

標準 JSON 不允許註解、結尾逗號或單引號字串。數字型連接埠應寫成數值，布林開關應使用 true 或 false，不能以加上引號的同名文字代替。反斜線在字串中有跳脫作用，手動輸入路徑或正規表示式時尤其容易出錯。編輯器能格式化，只能表示文字結構大致正確，不能證明協定支援該欄位，也不能確認遠端參數與本機設定一致。

本文後續程式碼多為頂層模組片段，目的是說明欄位之間的關係，並非每段都能獨立啟動。合併片段時，請取代原有的同名模組，不要在同一物件中新增重複鍵。不同解析器處理重複鍵的方式可能不一致，容易造成「檔案看似已修改，執行結果卻沒有改變」的誤判。陣列內也須保留正確的逗號與括號，避免把一個出口誤放進另一個出口的設定物件。

版本相容性應以目前實際使用的核心為準，而不只是看用戶端名稱。同一用戶端可能切換核心，不同發行套件也可能支援不同功能。查閱欄位時，請一併記下模組、欄位路徑、值的型別及適用核心；遇到不熟悉的欄位，先縮小設定範圍。不要不斷加入網路上找到的開關碰運氣；保留一個能重現問題的請求，逐層確認入口、路由與出口，通常更容易找出真正差異。

02 / INBOUNDS

inbounds：監聽位址與入站協定

監聽範圍決定哪些裝置能使用入口

入站首先定義可連線的本機入口。listen 決定綁定的位址，port 決定連接埠，protocol 則決定收到連線後要用哪種協定解析資料。僅供本機程式使用時，建議綁定 127.0.0.1。若改為監聽所有介面，區域網路中的其他裝置可能也能連到該連接埠；實際是否可連仍取決於防火牆與網路環境，因此不能只改位址而忽略存取控管。

位址與連接埠必須配合使用。應用程式設定的代理位址必須指向目前執行核心的裝置；手機上的迴環位址只代表手機本身，不會指向旁邊的電腦。監聽 IPv4 迴環位址，也不表示已監聽 IPv6 迴環位址。如果應用程式使用 localhost 時連線失敗，改用迴環數值位址卻可連線，請檢查名稱解析結果及監聽的 IP 位址族，避免誤把本機入口問題當成遠端伺服器故障。

SOCKS 與 HTTP 入站各自接收什麼

SOCKS 入站通常供支援 SOCKS 代理的應用程式使用；HTTP 入站接收 HTTP 代理請求，包括應用程式透過 CONNECT 建立的通道。兩者不會把瀏覽器流量強制改寫成某種網頁協定，也不會自動啟用系統代理。請在應用程式中選擇與入口相符的代理類型；不能把 SOCKS 連接埠填入只會傳送 HTTP 代理請求的欄位，再期待核心自行辨識。以下設定將兩種入口分開，方便觀察與排查。

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

這裡啟用 SOCKS 的 UDP 功能，只代表入口允許相關請求，不保證所有 UDP 應用程式都已透過它傳輸。應用程式必須支援 SOCKS UDP 的使用方式，出口與遠端服務也須支援相應轉送。系統代理通常無法涵蓋所有應用程式或任意 UDP 流量，因此「網頁正常，但某個即時應用程式失敗」不能直接歸咎於節點無法使用。請先確認該應用程式如何接入，再檢查後續連線路徑是否支援所需傳輸方式。

嗅探用來補足目標資訊

部分路由規則需要網域，但應用程式送入核心時可能只提供目標 IP。入站的嗅探功能可嘗試從連線開頭辨識 HTTP 主機名稱，或從 TLS 交握中的伺服器名稱取得資訊，提供更多路由判斷依據。嗅探不是通用的內容解密功能，也不能保證每條連線都能擷取網域。不同核心支援的嗅探協定清單與選項可能不同；新增相關欄位前，請先確認目前核心的文件，不要整段照抄其他核心的範例。

嗅探還涉及「僅用於路由判斷」與「是否改寫連線目標」的差異。部分核心提供只影響路由的選項，適合不希望改變原始目標位址的情況，但這類欄位並非所有核心通用。排查時，請先關閉額外嗅探，讓一個明確的網域或 IP 請求成功，再逐項啟用。否則，入站提供的原始目標與嗅探取得的名稱混在一起，會讓日誌中的路由結果更難判讀。

入站啟動失敗最常見的本機原因是連接埠衝突、監聽位址不存在或權限不足。同一裝置上的兩個用戶端若使用相同位址與連接埠，通常無法同時監聽。不要為了避開衝突而任意擴大監聽範圍；請先關閉不再使用的用戶端，或有計畫地調整連接埠，並同步更新應用程式的代理設定。更完整的錯誤排查流程請見日誌排查；系統代理的設定步驟則請見使用指南。

03 / OUTBOUNDS

outbounds：出口協定與傳輸設定

出口標籤與預設順序

出站負責將請求從核心送往目標或遠端代理伺服器。protocol 用來選擇出口協定，settings 儲存該協定的具體參數，streamSettings 則設定底層傳輸與傳輸安全性。標籤只供內部引用；名為 proxy 的出口不會因此自動具備代理功能。出口必須確實存在、參數有效，並且命中路由規則或位於預設出口位置，才能處理請求。

基本設定通常會同時包含代理、直連與阻斷出口。直連的 freedom 會由執行核心的裝置直接連線至目標；阻斷的 blackhole 則會主動終止符合條件的請求。這裡的「直連」不代表略過本機網路堆疊，也不表示一定避開系統層的虛擬網卡。若啟用了 TUN 或其他全域接管機制，須確認核心本身有正確的繞行路徑，否則請求可能再次進入自身，形成迴圈。

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

分別核對節點身分與傳輸安全性

遠端代理出口通常包含伺服器位址、連接埠及協定所需的身分參數。VMess、VLESS、Trojan 和 Shadowsocks 的身分結構各不相同，不能只替換 protocol，就把一份設定改成另一種協定。匯入訂閱的優點之一，是用戶端會依節點類型產生相應欄位。手動修改時，請逐項核對服務提供者給的資訊，不要只憑分享連結的外觀推測加密方式、傳輸路徑或安全設定。

以下片段示範 Trojan 出站常見的欄位層級。proxy.example.com 與範例密碼僅供說明結構，無法連線至真實服務；實際使用時，須替換為服務提供者給的位址、連接埠、密碼與憑證名稱。這與前一段直連範例用途不同，請勿將兩段頂層物件直接疊加。使用前也應確認目前核心支援該協定及所用傳輸欄位。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "trojan",
      "settings": {
        "servers": [
          {
            "address": "proxy.example.com",
            "port": 443,
            "password": "your-password"
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "proxy.example.com",
          "allowInsecure": false
        }
      }
    }
  ]
}

傳輸方式決定連線如何承載資料；TLS 決定如何協商傳輸安全性；代理協定則定義雙方如何交換代理請求。這三層都必須與遠端設定相符。伺服器接受哪種傳輸、路徑是否區分大小寫、是否需要特定主機名稱，都應以伺服器端設定為準。修改用戶端其中一層，不會讓伺服器自動配合；設定組合不一致時，可能立即斷線、交握失敗，也可能持續等待直到逾時。

憑證名稱與伺服器位址不是同一欄位

伺服器位址用來找到遠端主機；TLS 的 serverName 則用於交握時的名稱指示與憑證驗證。在某些部署中，兩者可以不同。將網域改成數值 IP 後，仍可能需要保留憑證對應的伺服器名稱。不要長期以關閉憑證驗證來掩蓋名稱錯誤；請先檢查系統時間、憑證涵蓋範圍與填入的名稱是否一致，再判斷問題是否出在伺服器憑證鏈或網路連線。

連線重用、底層通訊端與進階傳輸參數都屬於後續最佳化，不應成為初次設定的必要條件。節點使用預設參數正常運作後，再觀察特定應用程式是否有重複建立連線、長連線中斷等問題，最後依核心支援情況調整。一次套用多項「最佳化參數」會同時改變多個變因，讓失敗原因難以重現。尤其不要為了測速結果任意修改協定身分欄位，這些欄位不是效能調整開關。

如果出口啟動正常但連線失敗，應分辨是網域解析失敗、無法連上遠端連接埠、TLS 協商失敗，還是協定驗證失敗。前一層尚未成功時，檢查後一層通常沒有意義。憑證相關問題可進一步參閱TLS 交握與 SNI 排查筆記；如果只是要更換或安裝圖形化用戶端，請前往用戶端頁面選擇，不必另外尋找核心下載入口。

04 / ROUTING

routing：規則比對順序與分流設定

規則依序判斷，不會自動按精確度排序

路由模組會逐項比對連線資訊與規則，再將符合條件的請求交給指定出口。常見規則使用 type: "field"，依網域、目標 IP、連接埠、網路類型或入口標籤判斷。規則會由上而下檢查，通常由第一條符合的規則決定結果，因此範圍較窄的例外應排在一般規則之前。若將涵蓋所有連線的規則放在最上方，後續細部規則就不會實際生效，即使規則本身完全正確也一樣。

同一條規則中的不同條件欄位通常須同時符合；同一陣列中的多個候選項通常代表符合其中任一項即可。例如網域陣列可以列出多個網站，若同時設定連接埠條件，請求連接埠也必須符合限制。不要把不同用途的條件全部塞進一條規則，期待它們彼此取代。閱讀規則時，可以先用一句話重述：哪個入口、存取什麼目標、使用哪種網路、交由哪個出口，再確認程式碼表達的意思是否一致。

網域、完整比對與 IP 網段

domain: 適合指定某個網域及其子網域，full: 用於完整網域比對，regexp: 則使用正規表示式。規則不需要加入網頁路徑，因為代理連線層通常看不到完整網頁網址；把含有協定標頭與路徑的 URL 當成網域條件，往往無法命中。已知固定主機時，優先使用簡單比對；確實需要模式比對時才使用正規表示式，較容易維護並檢查跳脫字元。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:telemetry.example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

此片段要求已存在標籤為 block 和 direct 的出站。第一條是第二條涵蓋範圍內的例外，因此必須排在前面。私有網段範例只處理列出的位址，並未涵蓋所有特殊用途網路；實際環境若需要鏈路本地位址等範圍，請依網路用途補充。未符合規則的請求會繼續使用預設出口；最後一條設定直連，不代表所有剩餘連線都會改為直連。

domainStrategy 決定路由何時解析網域

AsIs 盡量依現有目標資訊判斷，不會為了補足 IP 條件而主動解析網域。IPIfNonMatch 在網域階段未命中時，可能解析網域後繼續比對 IP 規則；IPOnDemand 則可能在遇到需要 IP 資訊的規則時觸發解析。這些策略會影響路由判斷流程，不等同於 DNS 伺服器清單，也不能取代建立出站連線時所需的解析。變更策略後，DNS 請求數量與規則結果都可能改變。

如果應用程式只將 IP 交給核心，單純新增網域規則並不會讓原始名稱憑空恢復。此時應檢查應用程式的代理方式、DNS 解析發生的位置，以及是否使用適用的嗅探機制。反過來說，目標已是網域時，也不能假設私有 IP 規則一定會先命中；是否解析以及何時解析，取決於目前的策略。排查時記錄「入站收到的是網域還是 IP」，通常比只看瀏覽器網址列更有用。

geosite 和 geoip 是分類資料的引用，不是即時網路查詢。它們需要核心能找到相應資料檔，分類名稱也必須存在。缺少資料可能導致啟動失敗；分類內容改變，也可能讓同一份設定在更新後產生不同結果。先用單一明確網域或網段驗證規則，再改用分類引用，就能將規則語法問題與分類資料問題分開，不必同時猜測兩個變因。

維護規則時，建議在設定檔外記錄每條規則的用途與修改原因，避免把註解寫進標準 JSON。刪除舊規則前，先確認後續規則是否依賴其順序，尤其留意依入口標籤分流的規則與最終兜底規則。具體比對語法與優先順序範例請見自訂路由規則筆記；若要分辨系統代理與全域模式，可搭配常見問題了解用戶端層的行為。

05 / DNS

dns：解析入口與查詢路徑

先確認是哪一層正在進行解析

一次存取可能涉及應用程式自行解析、作業系統解析、核心內建 DNS，以及遠端代理端解析。設定中的 dns 只描述核心相關解析器的行為，不會自動取代裝置上所有應用程式的 DNS 設定。瀏覽器可能啟用自己的加密 DNS，應用程式也可能先取得 IP，再傳送代理請求。因此要判斷 DNS 是否生效，必須先確認是哪個元件發出查詢，不能只看系統設定頁面上的伺服器位址。

核心 DNS 的使用方式還會受到路由策略、出口設定與用戶端產生設定的邏輯影響。部分請求會保留網域並交由遠端解析，另一些請求則可能為了比對 IP 規則而在本機解析；兩種情況可以同時存在。遇到「網頁能開啟，但日誌沒有相應查詢」時，不一定代表設定無效。請先確認入站目標是網域還是 IP，以及請求最後由哪個出口處理，再判斷預期的解析應在哪裡發生。

servers、hosts 與查詢位址族

servers 用來指定解析伺服器，可以是簡單位址，也可以依核心支援情況使用含網域條件的物件。hosts 用來設定明確的名稱對應，適合受控測試或固定內部名稱。以下範例使用數值型解析伺服器位址，並將保留示例網域對應至文件用途位址；此對應僅供示範，不是可存取的網站。使用數值位址可以減少啟動階段先解析 DNS 伺服器網域的依賴。

{
  "dns": {
    "hosts": {
      "lab.example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

UseIP 表示允許查詢 IPv4 與 IPv6 結果；其他查詢策略的可用值，應依所用核心確認。只回傳 IPv4 有助於縮小某些雙協定堆疊問題的範圍，但不應視為永久通用的最佳化設定；如果網路需要 IPv6，強制限制反而會失去可用路徑。系統有 IPv6 位址，不代表目前網路具備穩定的端對端 IPv6 連線能力；應分別確認位址設定與實際連通性。

DNS 伺服器清單不等於連線出口清單

列出多個伺服器，不代表它們一定會嚴格依序互相備援。網域條件、快取、回退機制與核心實作都可能影響實際查詢。若需要依網域分流解析，請明確指定哪些名稱交給哪個解析器，以及未符合條件的名稱如何處理。物件形式的網域條件與路由中的網域規則看起來相似，但作用位置不同：前者選擇解析器，後者選擇連線出口，不能因為寫法相近就混為一談。

加密 DNS 可以保護裝置至解析服務之間的傳輸，但不會自動確保這段連線經由預期出口。還要了解目前核心如何傳送這種解析模式，以及用戶端是否另有 DNS 路由設定。如果解析服務使用網域位址，又必須先解析該網域才能找到伺服器，就可能形成啟動依賴迴圈。排查時可先使用可明確連線的數值位址建立基本解析，再逐步切換至目標方案。

快取是 DNS 排查中的重要變因。重新載入用戶端可能只會清除核心快取，瀏覽器與作業系統仍可能保留舊記錄；既有連線也不會因解析結果改變而自動重建。驗證設定時，請建立新連線；必要時關閉相關應用程式後重新開啟，並記錄測試時間與查詢名稱。不要在短時間內持續重新整理頁面，讓多層快取的結果混在一起，再據此判斷某個伺服器一直沒有生效。

DNS 逾時也可能是路由迴圈造成的。例如，解析請求被送往某個代理出口，但建立該出口又需要先解析網域；或虛擬網卡把核心自身的流量再次導入。此時一再新增公共解析伺服器通常無法解決問題。請回頭檢查連線依賴關係，分別確認解析服務位址、代理服務位址及核心自身連線的路徑。只有每個環節的前置條件都能獨立成立，複雜的分流解析才有穩定基礎。

在 v2rayN 或 v2rayNG 中調整 DNS 時，請先使用用戶端既有的設定入口，再核對最後產生的設定，避免介面設定與自訂片段互相覆蓋。如果只是初次連線，減少變因通常更合適；若要驗證特定分流需求，則固定一個測試網域，分別觀察解析與連線兩個階段。系統代理的涵蓋範圍及應用程式自行解析等常見疑問，請參閱常見問題。

06 / POLICY

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

策略不是節點優先順序

policy 用來設定連線資源與統計相關策略，常見內容包括交握等待時間、閒置逾時、單向連線保留時間，以及流量統計開關。它不會依節點名稱挑選出口，也不能取代路由規則。遇到連線不穩時，應先確認出口能否成功連線，再判斷是否真的受到逾時策略影響；一味調長所有時間，只會讓某些原本應該儘早出現的錯誤延後發生。

levels 中的數字鍵代表使用者層級，JSON 物件鍵仍須加上引號。層級不是系統權限，也不代表「數字越大，速度越快」。協定使用者設定中的 level 會與對應層級關聯，未明確指定時通常使用預設層級。有些情境主要使用沒有驗證的本機入口，也沒有為使用者設定多種層級；此時大量定義高編號策略通常不會帶來預期效果。

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

依連線階段理解逾時設定

範例中的時間欄位通常以秒為單位，仍應以目前核心的欄位說明為準。handshake 限制交握階段的等待時間；connIdle 關注連線沒有資料活動時保留多久；uplinkOnly 與 downlinkOnly 則與其中一個方向關閉後，另一方向還要保留多久有關。這些欄位描述不同階段，不能用其中一個概括所有「連線中斷」的情況。

交握時間設得太短，可能在高延遲或短暫壅塞時，提前終止尚未完成的連線；設得太長則會延後失敗回報。閒置逾時太短，可能影響長時間等待通知、但很少傳輸資料的應用程式；太長又會占用較多連線資源。調整前應先找到可穩定重現問題的應用程式，記錄中斷前是否真的沒有資料，再小幅調整相關欄位。不要把持續傳輸中的故障直接歸因於閒置逾時。

網路連線中單向關閉並不少見。一側停止傳送資料，不一定代表另一側已完成回應，因此單向保留時間可能影響部分請求的收尾。只有日誌與應用程式行為確實指向半關閉階段時，才值得調整相關參數。如果連線根本未通過驗證，或伺服器端主動終止工作階段，修改用戶端的時間欄位無法解決協定不相容，也不能強迫遠端維持連線。

統計開關需要完整的資料收集流程

啟用使用者上傳或下載統計，不代表用戶端會立即顯示相應數值。統計模組、相關使用者識別資訊、API 服務及用戶端讀取邏輯必須串成完整流程。介面上的流量數字也可能來自虛擬網卡或其他統計來源，因此不能看到數字就斷定某個 policy 欄位已生效。本文範例維持關閉統計，只展示欄位所在層級，避免引入額外介面與資料收集設定。

系統層級統計與使用者層級統計的細緻程度不同。入口統計可能彙總同一入口的多種請求；使用者統計則需要協定中有可辨識的使用者物件。若想依應用程式區分流量，只開啟使用者統計未必足夠；還須考量入口劃分、應用程式接入方式，以及用戶端是否提供相應的顯示功能。不要為了取得一個介面指標，就將控制介面暴露在區域網路；監聽範圍仍應依實際需求限制。

啟用統計或其他進階模組後若無法啟動，請先檢查是否缺少相依模組、目前核心是否支援相關欄位，以及用戶端是否已產生同名設定。不要同時保留兩套互不相關的 API 定義，再試圖用換連接埠解決所有錯誤。先退回只包含連線策略的最小設定，再逐項加入統計功能，就能分開排查連線處理與監控功能，避免資料收集流程影響正常使用。

評估策略變更時，不宜只看一次延遲測試。短請求、長連線與持續傳輸受到影響的階段不同，單一測試無法涵蓋所有行為。請分別確認首次連線能否完成、閒置後能否恢復，以及既有工作是否會異常中斷；測試後再恢復一般日誌等級。如果說不清某個數值具體解決了什麼問題，就沒有必要長期保留。設定越精簡，日後切換核心時越容易確認相容性。

07 / CLIENT INTEGRATION

用戶端產生設定與接管範圍

介面選項如何轉成執行設定

v2rayN、v2rayNG 與 v2flyNG 都將圖形介面與核心連線處理分開。用戶端負責儲存節點、訂閱與使用者選項，再將目前選取的項目轉換成核心執行所需的設定。這能減少手動輸入欄位的負擔，但也表示產生的檔案未必是長期設定來源。切換節點、重新啟動核心、變更路由模式或更新訂閱，都可能觸發重新產生設定；直接編輯執行檔案，可能在下一次操作時被覆蓋。

桌面端建議使用 v2rayN，並依實際核心與系統環境選擇圖形介面功能。Android 裝置可使用採用 Xray 核心的 v2rayNG，或選擇以 V2Fly 核心為替代方案的 v2flyNG。不同用戶端接入自訂設定的方式不盡相同，介面名稱也可能調整，請以目前安裝的版本為準。若找不到某個選項，不要把另一款用戶端的完整操作步驟當成通用方法；請先確認目前使用的應用程式與核心。

分清訂閱、節點與完整設定

訂閱網址通常指向一組可更新的節點資料；節點分享連結描述單一服務的協定與連線參數；完整 JSON 則可能同時包含入口、出口、DNS 與路由。三者不能當成同一種文字匯入。把完整設定貼進只接受節點連結的匯入入口，或把訂閱網址填入出站伺服器位址，都無法正確設定。匯入前先確認內容用途，比匯入失敗後不斷嘗試不同按鈕更有效。

部分用戶端允許匯入完整設定，另一些則支援局部自訂或路由規則管理。使用前請先確認其處理方式是整份取代、合併特定物件，還是只在陣列中新增項目。同一片段在不同合併方式下可能產生不同結果：取代出站陣列會移除原有出口，追加路由規則則可能被前面的規則遮蔽。不要只確認檔案已儲存，也要檢查最後產生的內容是否包含預期標籤與順序。

系統代理與 TUN 是不同的接入方式

系統代理是由作業系統向遵循相關設定的應用程式提供代理資訊，不會自動涵蓋所有程式；TUN 則透過虛擬網路介面及相關路由，將流量交由用戶端處理。兩者可能使用同一個核心，但不是同一個 JSON 開關。TUN 所需的權限、虛擬介面與系統路由通常由用戶端管理；不能只在傳統入站陣列中新增一個陌生的協定名稱，就認為已完成系統流量接管。

同時執行多個網路代理工具時，請留意系統代理位址由誰修改、預設路由由誰接管，以及 DNS 設定最後由誰管理。某個用戶端關閉後，另一個用戶端可能仍占用連接埠或保留系統設定。若出現「關閉軟體後，應用程式反而無法連網」的情況，請先檢查系統代理是否仍指向已停止的本機入口，再檢查虛擬網卡與系統路由，不要立即重裝所有軟體。

用一項小幅變更確認設定來源

要確認是否採用了自訂設定，可以選擇容易觀察、又不會暴露服務資訊的變更，例如修改本機入口連接埠並同步調整測試應用程式，或為既有出口新增明確的內部標籤。重新啟動相關連線後，檢查監聽狀態與日誌。若最後產生的設定沒有改變，問題可能在用戶端設定來源或合併邏輯，不必繼續懷疑遠端網路；若產生的內容正確，再進一步排查連線。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["http-in"],
        "outboundTag": "direct"
      }
    ]
  }
}

上方的局部片段只示範依入口標籤分流，必須同時存在名為 http-in 的入口與 direct 的出口。它不會建立這些物件，也不適合未經檢查就覆蓋既有路由。維護自訂內容時，可另外記錄修改目的、適用核心與相依標籤，但不要將訂閱網址或密碼寫進公開筆記。更換裝置前，請先匯出必要設定，並依用戶端功能確認敏感資料的保存方式。

初次使用仍建議依照使用指南完成匯入、選取節點與連線驗證，再考慮接管完整設定。想了解 v2rayN 的設定入口與日誌區域，可參閱主介面功能導覽。本頁用於說明欄位與適用範圍；用戶端的實際按鈕請以目前介面為準，不必為了與範例完全一致而放棄已穩定運作的預設設定。

08 / DIAGNOSTICS

日誌檢查與設定回復順序

先確認程序是否成功啟動

排查設定問題時，第一個判斷點是核心能否持續執行。若啟動後立即結束，請先查看最早出現的錯誤，不要直接測試網頁。常見原因包括 JSON 結構錯誤、不支援的協定或欄位、監聽連接埠衝突，以及缺少必要資料檔。後續連續出現的「連線被拒絕」可能只是核心退出後造成的連帶現象；修正應用程式端的提示，無法取代修正最初的啟動錯誤。

日誌出現檔案位置時，請確認它屬於目前執行中的實例。多個用戶端或殘留程序可能各自產生日誌，舊視窗中的資訊也未必對應最近一次測試。記下明確的重新啟動時間，只保留目前實例的相關片段，並確認設定檔路徑與實際編輯位置一致。如果用戶端提供啟動錯誤詳情，請優先從該處確認模組名稱，再回到檔案定位，不要先全文取代看似相近的欄位。

暫時提高日誌詳細程度

需要觀察連線流程時，可在確認核心支援的前提下，暫時將日誌等級設為 info；更詳細的偵錯等級只用於縮小問題範圍。日誌可能包含目標網域、連線位址或使用者相關資訊，分享前請移除敏感內容。記錄越多不代表越容易排查，尤其多個應用程式同時連網時，正常連線可能淹沒真正失敗的請求。測試期間只保留一個應用程式與一個明確目標會更有幫助。

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

這段設定只取代頂層日誌模組，不應視為可獨立使用的完整設定。修改後若日誌詳細程度沒有改變，請先確認是否需要重新啟動核心，以及用戶端是否覆蓋了日誌選項。排查結束後請恢復一般等級，避免長期記錄不必要的存取細節。若將日誌寫入檔案，也須確認目錄存在且目前程序有寫入權限；無法建立日誌檔本身也可能造成額外錯誤，不應與連線故障混為一談。

依序檢查入口、解析、路由與出口

核心正常運作後，先確認測試請求是否進入正確的入站。完全沒有記錄時，請檢查應用程式的代理類型、位址、連接埠與系統代理狀態；請求已進入但目標資訊不正確時，檢查應用程式的解析方式與嗅探設定；目標正確卻使用錯誤出口時，檢查規則順序、標籤及網域策略。確認已選取預期出口後，再檢查伺服器解析、連線、TLS 與協定驗證，避免跨層猜測。

「逾時」只表示某個階段未能在等待時間內完成，本身不是根本原因。伺服器網域解析逾時、目標連接埠連線逾時，以及協定協商逾時，應採用不同的檢查方式。如果日誌只保留最後一則提示，可適度提高詳細程度並重現一次，找出更早的階段資訊。不要一看到逾時就同時更換 DNS、傳輸方式與身分參數；否則即使問題偶然排除，也無法確認是哪項變更生效。

驗證修復結果時，應同時觀察新建立的請求與應用程式的實際功能。既有長連線可能仍使用舊出口，瀏覽器快取也可能讓頁面看似正常，實際上卻沒有送出新請求。關閉相關連線後再測試，確認請求經過預期入口與出口，並檢查應用程式所需的其他請求是否也成功。實際連線測速可協助篩選服務連通性，但單次測試通過，不代表所有網域、協定與應用情境都符合路由預期。

以恢復可判讀的狀態為目標進行回復

若多處修改後已無法判斷問題來源，請先回復到最近一次可啟動的設定，只保留一個入口、一個已確認可用的出口，以及最少量的規則。再依序恢復 DNS、分流、策略與進階功能，每次都測試同一個目標。這個順序不是要求永久減少功能，而是將複雜問題拆解為可觀察的步驟。每次新增內容都有明確結果，後續調整才不會不斷累積難以解釋的例外。

若要進一步了解啟動錯誤的分類，請參閱從 Xray 日誌排查設定錯誤；若核心已能啟動，但不確定代理是否生效，可參考首次連線驗證筆記。仍有疑問時，請回到常見問題依現象查閱。設定參考的目的，是讓每個欄位都有明確用途，而不是讓檔案越寫越長。