V2Ray 設定檔參考

JSON 結構與設定範圍

先確認正在編輯哪一層

V2Ray 生態系中的「設定檔」不一定只是一個檔案。v2rayN 會儲存伺服器資料、訂閱群組、路由規則與參數設定，再依選用的核心產生執行設定。v2rayNG 和 v2flyNG 也分為應用程式本身的資料，以及核心執行設定兩個層次。在介面中修改連接埠，不代表訂閱原始內容也會跟著變更；編輯暫時產生的 JSON，也不代表下次啟動時會保留。查閱欄位前，請先確認檔案是手動管理、由客戶端匯出，還是啟動時建立的暫存檔，並記下產生檔案的客戶端與核心。

本頁範例以 V2Ray 風格的 JSON 和 Xray 常見欄位為主。V2Fly 與 Xray 共用部分設定基礎，但協定支援、傳輸名稱及擴充選項可能不同。sing-box 使用另一套設定結構；即使 v2rayN 支援切換核心，也不能因此將這裡的 JSON 原封不動交給它。遇到「未知欄位」時，先確認實際啟動的核心，再查閱該核心接受的欄位；不要只憑客戶端名稱推斷。下載客戶端時，可前往平台下載頁選擇合適的版本。

物件、陣列與參照關係

JSON 最外層是物件，欄位名稱與字串都使用英文雙引號。陣列以方括號表示，適合存放多個入站、出站或規則；物件以大括號表示，適合存放一組參數。數字型連接埠通常直接寫成數字，布林值則使用小寫的 true 或 false。標準 JSON 不接受註解、結尾多餘的逗號或單引號。即使某些工具支援含註解的擴充語法，分享或移轉前仍應匯出標準 JSON，避免其他解析器無法讀取。

以下是一份可獨立啟動的本機直連基準設定，用來檢查 JSON 解析、本機監聽與日誌輸出，不包含代理伺服器。設定只監聽迴路位址，不會設定系統代理，也不會建立桌面選單。載入成功後，本機 SOCKS 入口會將請求交給 direct 出站。此時能連上某個位址，只能證明直連路徑可用，不能證明訂閱中的代理伺服器正常。交由客戶端使用前，也要確認客戶端是否支援自訂設定入口，以及是否會改寫本機連接埠。

{
  "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": {}
    }
  ]
}

從結構正確到語意正確

解析成功只代表語法沒有問題。如果 routing 中填入不存在的 outboundTag，或規則參照的入站標籤拼錯，設定仍可能報錯或無法依預期分流。標籤是同一份執行設定內的參照名稱，區分大小寫；它不是介面上顯示的備註，也不是伺服器網域。建議先列出入站與出站的 tag，再核對規則中的參照。陣列順序也有影響：一般路由規則會依序比對，未符合規則的請求通常由第一個出站處理，不宜任意按字母排序。

閱讀後續局部範例時，請將欄位合併到對應的頂層位置，不要把多個完整物件依序貼進同一個檔案。單一頂層物件中不要重複定義 routing 或 dns；重複鍵的處理方式取決於解析器實作，容易造成介面顯示與實際執行結果不一致。每次合併只修改一項功能，保留修改前的副本，並在啟動日誌中確認載入結果。若只需要匯入訂閱及日常連線，建議優先由客戶端產生設定；只有介面無法滿足需求時，才手動管理 JSON。

inbounds 入站與本機監聽

listen、port 與 protocol 的分工

入站是應用程式流量進入核心的入口。listen 用來指定要監聽的本機位址，port 決定連接埠，protocol 則決定要接收哪種協定。桌面本機代理通常監聽 127.0.0.1，只有本機程序能連線；若設為 0.0.0.0，通常會監聽所有 IPv4 介面，可能讓區域網路中的裝置也能連線。這不代表「使用任意伺服器」，也不保證外部一定連得上，實際情況仍受防火牆與網路環境影響。沒有明確的共享需求時，不應擴大監聽範圍。

SOCKS 與 HTTP 是不同的本機代理協定，應用程式的設定必須與入口相符。瀏覽器設定 HTTP 代理時，不能任意指向只接收 SOCKS 的連接埠；命令列工具使用 SOCKS 時，也要確認是否支援透過代理解析網域。v2rayN 介面可能提供本機混合連接埠，由客戶端與選用的核心負責實作。不要因此在任意 V2Ray 風格設定中填入名為 mixed 的協定；是否可用，必須依目前核心的實際設定定義判斷。

並列設定 SOCKS 與 HTTP

以下是由兩個入站物件組成的局部片段，應取代或合併至頂層 inbounds 陣列，不能與已使用相同連接埠的入站並存。兩個入口都綁定迴路位址，SOCKS 開啟 UDP 接收，HTTP 入口則供支援 HTTP 代理的程式使用。開啟 udp 只代表該入站會接收相關請求，不保證後續出站、伺服器及網路路徑都能轉送 UDP。應用程式若沒有送出代理請求，修改核心路由也不會讓流量自動進入這些連接埠。

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

本機連接埠不是伺服器的遠端連接埠。前者供本機應用程式連線，後者設定於 outbounds 的伺服器資料中，兩者通常不必相同。遇到連接埠被占用時，先關閉重複啟動的客戶端，確認背景是否仍有核心程序，再改用未占用的連接埠。修改入站連接埠後，也必須同步更新應用程式的代理設定及客戶端系統代理設定。若只改 JSON 而未更新系統代理，可能出現核心已正常啟動、瀏覽器卻仍連到舊連接埠的情況。

sniffing 的用途與限制

嗅探可嘗試從支援的流量特徵中擷取網域，做為網域路由的判斷依據。它不是解密工具，也不保證每條連線都能辨識出網域。以 Xray 為例，以下物件可放在某個入站物件中；routeOnly 表示嗅探結果只用於路由判斷。欄位是否受支援、可辨識哪些協定，應以使用中的核心為準。如果應用程式本來就會向 SOCKS 入口提交網域，路由已有可用的網域資訊，通常不必為了「完整」而額外開啟所有嗅探選項。

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

Android VPN 模式會透過系統提供的虛擬網路介面接收流量，通常不必逐一為應用程式填入 SOCKS 連接埠。v2rayNG 的「分應用代理」則決定哪些應用程式要使用或略過這條路徑，與入站 JSON 的監聽位址並非同一層設定。桌面端使用其他流量接管方式時，也要區分系統層與核心層：先確認流量是否到達核心，再檢查後續規則；不能看到「VPN 已連線」就認定每個應用程式都使用同一入口。

允許區域網路裝置存取時，也要考量驗證、來源位址與防火牆範圍。未設定驗證的 HTTP 或 SOCKS 入口，不適合直接開放給不受信任的網路。連線裝置必須知道代理位址，主機也應限制可存取的網段；只修改 listen 而忽略網路邊界，會擴大預期之外的存取範圍。排錯時可先在本機完成迴路測試，再開放區域網路存取，最後檢查防火牆。逐層開放，比同時修改多個位址與規則更容易找出問題來源。

outbounds 出站與協定參數

預設出口與明確標籤

出站決定核心如何繼續處理請求。freedom 通常用於直連，blackhole 用於阻擋，VMess 等協定則透過相應伺服器轉送。tag 是路由選擇出口時使用的識別標籤，不會自動成為可用的伺服器。名為 proxy 的標籤可以指向任何協定，因此判斷出口性質時，必須同時檢查 protocol 與 settings。未符合路由規則的請求通常會交給 outbounds 中的第一個出站；若將 direct 放在第一項，預設路徑就是直連。

以下片段定義直連與阻擋兩個出口，適合練習路由參照，但不具備遠端代理功能。blackhole 的空設定會依協定預設方式處理遭阻擋的請求。如需回傳特定回應，請查閱目前核心對應的協定設定，不要把任意 HTTP 文字當成通用回應。設定多個出站時，應使用清楚且唯一的標籤，例如 direct、block 和 proxy，避免只用一串數字；排查路由時，能一眼看懂出口用途，比少打幾個字更重要。

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

透過 VMess 認識伺服器欄位

VMess 出站會將伺服器位址、遠端連接埠及使用者參數放在 settings 的 vnext 陣列中。address 可以是伺服器網域或位址，port 是伺服器實際監聽的連接埠，users 則描述驗證使用者。以下僅示範欄位結構；example.net 是文件專用網域，全零 UUID 也是教學用值，不能用來連線至實際服務。實際使用時，必須從既有伺服器設定或有效訂閱取得相符參數；此處沒有可用節點，也不應隨機產生 UUID 猜測伺服器憑證資料。

{
  "tag": "proxy",
  "protocol": "vmess",
  "settings": {
    "vnext": [
      {
        "address": "example.net",
        "port": 443,
        "users": [
          {
            "id": "00000000-0000-0000-0000-000000000000",
            "alterId": 0,
            "security": "auto",
            "level": 0
          }
        ]
      }
    ]
  }
}

這個物件本身不是完整的連線設定，還缺少與伺服器相符的傳輸及安全層設定。連接埠使用 443 不代表自動啟用 TLS；users 中的 security 也不等同於 streamSettings 中的 security，兩者所屬層級不同。現代 VMess 設定通常使用零值的 alterId，但移轉舊資料時仍應以伺服器端設定為準。系統時間不準可能影響驗證；遇到握手錯誤時，先確認系統時間與時區，再逐項核對使用者參數。

不要跨協定照搬欄位

VMess、VLESS 與其他協定的使用者結構並不完全相同。把某個協定的 users 物件直接貼到另一個協定下，可能在解析階段失敗，也可能產生沒有實際用途的參數組合。同樣地，連線位址、傳輸 Host 與 TLS serverName 可以是不同欄位，分別用於網路連線、應用層請求及憑證驗證。只有伺服器明確要求時才填入相應值，不要為了讓三個名稱看起來一致，就覆蓋訂閱提供的設定。

訂閱更新與手動編輯之間也存在覆寫關係。客戶端通常會依訂閱中的伺服器記錄重新產生出站；直接修改暫存 JSON 不會回寫訂閱，下次切換伺服器時也可能遺失。若需長期自訂，應使用客戶端提供的自訂設定或範本功能，並保留伺服器資料來源。只想修改路由時，不必同時更動驗證欄位；只想調整本機連接埠，也無須重寫整個出站。縮小修改範圍，可降低改壞正常連線參數的風險。

「連線測試通過」不代表「實際傳輸正常」。測試可能只確認連線建立、特定網址或特定請求，而實際應用程式還會使用長連線、不同網域及 UDP。先確認出站能建立協定連線，再查看存取日誌，核實應用程式的請求確實使用這個標籤，最後測試實際服務。單一分享連結與訂閱網址的差異，請參閱分享連結與訂閱匯入說明，避免在錯誤的資料層修改參數。

streamSettings 傳輸與安全層

分開檢視協定、傳輸與 TLS

出站協定負責代理請求的組成與驗證，傳輸負責如何在兩端之間承載資料，TLS 等安全層則負責保護相應連線及驗證身分。三者彼此相關，卻不能互相取代。同一個 VMess 協定可搭配不同傳輸，但伺服器端未必同時開放這些組合。客戶端顯示某個選項，也不代表目前的伺服器支援它。排查時應依序核對「協定一致、傳輸一致、安全層一致」，不要反覆嘗試下拉式選單中的所有組合。

streamSettings 位於對應的入站或出站物件內，不是任意的頂層欄位。此處以客戶端出站為例，透過 WebSocket 搭配 TLS 說明結構。network 為 ws 時，相關參數放在 wsSettings；security 為 tls 時，相關參數放在 tlsSettings。不同核心及其實作對傳輸名稱與可用擴充的支援可能不同。遇到新名稱或棄用提示時，請查閱目前核心的支援範圍，不要只把欄位名稱替換成看似相近的拼法。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.net"
    },
    "wsSettings": {
      "path": "/proxy",
      "headers": {
        "Host": "example.net"
      }
    }
  }
}

位址、serverName 與 Host

範例中的 example.net 與路徑僅用於說明欄位，實際連線必須使用伺服器提供的值。出站 address 決定要先連線到哪裡；tlsSettings.serverName 用於 TLS 服務名稱及憑證驗證；WebSocket 的 Host 則是 HTTP 請求中的主機識別。反向代理環境可能要求這些值彼此不同。手動編輯時，請逐項記錄，不要用伺服器備註覆蓋所有欄位。網域看起來相同只是部分部署方式的結果，並非通用設定規則。

path 也不是可以任意填寫的說明文字。反向代理常依路徑將 WebSocket 請求轉交給後端；路徑不符時，可能回傳一般網頁、重新導向或錯誤狀態。路徑的大小寫、開頭斜線及額外查詢內容都可能影響伺服器行為。若連線建立後立即中斷，先核對伺服器要求的路徑與 Host，再檢查中間代理是否支援連線升級。不要試圖修改本機入站連接埠來解決遠端 WebSocket 路徑錯誤，兩者位於完全不同的位置。

依連線階段定位錯誤

連線逾時首先表示某個階段未能在指定時間內完成，不能直接推斷是驗證密碼錯誤。若伺服器位址無法解析，先檢查網域解析；若位址已解析但無法建立連線，檢查遠端監聽、防火牆及網路路徑；若已進入 TLS 階段，日誌通常會提供憑證或握手線索；只有進入代理協定驗證階段後，才應優先檢查使用者參數。依此順序排查，可避免同時改亂路由規則、DNS 與驗證欄位。

傳輸層還有許多進階選項，例如通訊端行為、連線多工及特定傳輸擴充，通常不是初次設定的必填項目。合併多個來源的「最佳化參數」，可能改變連線生命週期、產生不相容的組合，或讓伺服器無法辨識請求。先建立明確符合伺服器設定的最小組態，再依單一需求驗證新增選項。若沒有明確證據，不要期待堆疊參數就能自然提升速度。

REALITY 等擴充不能視為可任意取代 tlsSettings 的設定值；它們有特定的核心需求及獨立參數限制。v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心，兩者支援的協定與擴充不一定相同。移轉前應核對每台伺服器需要的功能，再選擇客戶端與核心，不要先匯入後才逐一刪除錯誤欄位。使用 v2rayN 桌面版時，也要確認該伺服器實際選用哪個核心執行。

比較修改結果時，請固定使用同一台伺服器、同一條網路與同一個測試目標，每次只調整一個參數，並記錄日誌顯示的階段變化。若一次更換傳輸、伺服器位址及路由模式，即使恢復連線，也無法判斷是哪項修改奏效。若反覆發生握手失敗，可參考執行日誌錯誤排查繼續檢查；速度問題則應在連線設定正確後另外分析，不要把所有連線緩慢都歸因於 TLS。

routing 路由與規則順序

先了解規則何時生效

路由會處理已進入核心的請求，再依條件選擇出站。它不會替應用程式開啟系統代理，也不會自動接收未進入客戶端的連線。一般 field 規則依陣列順序比對，第一條符合條件的規則會決定出口。規則中的多個不同條件通常必須同時符合；同一個 domain 或 ip 陣列中的多個項目，則代表可比對的候選項目。設計規則時，先釐清流量來源、目標及出口，再選擇欄位，不要先堆滿清單才猜測優先順序。

以下是局部路由設定範例：私有位址與 geosite:cn 網域會交由 direct 處理。本例要求 outbounds 中已存在 direct 標籤；geoip 與 geosite 參照也要求目前執行環境提供相容的規則資料。若沒有符合任何規則，一般設定仍會回到第一個出站，不會自動選擇名為 proxy 的標籤。若要讓「其他請求走代理」，請先確認代理出站有效，再安排預設出口；不要只憑規則名稱推斷完整行為。

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

domainStrategy 與比對方式

routing.domainStrategy 控制路由比對時如何處理網域與位址。AsIs 通常只比對請求現有資訊；IPIfNonMatch 會在網域規則未符合時嘗試解析，以便繼續比對位址規則；IPOnDemand 則會在比對需要位址資訊時觸發解析。它不是 DNS 伺服器位址，也不會強制所有出站優先使用某種位址族。選擇策略時，應考量是否設有位址規則、網域能否正確解析，以及額外解析對排錯與請求路徑的影響。

網域規則可使用完整網域、網域及其子網域、關鍵字或正規表示式等不同比對範圍。常見的 full:example.net 只比對指定名稱；domain:example.net 也包含相應子網域；regexp: 則需要理解正規表示式及 JSON 字串跳脫。若只想比對單一網站，優先選擇範圍明確的形式。過於寬泛的關鍵字可能誤中無關網域，複雜的正規表示式也會增加維護負擔。修改後應同時測試預期符合及預期不符合的目標。

{
  "type": "field",
  "domain": [
    "full:example.net",
    "domain:example.org"
  ],
  "network": "tcp",
  "outboundTag": "direct"
}

這條範例規則要求目標網域符合其中一項，且網路類型為 TCP。如果請求只帶有位址，網域規則可能沒有可用依據；若透過嗅探取得網域，則還要檢查嗅探及路由的實際設定。不要把「網站使用某個網域」與「核心收到該網域」混為一談。應用程式自行解析、使用加密解析或直接連線至位址時，核心可見的資訊可能不同。檢查存取日誌中的目標形式，通常比繼續增加網域項目更有效。

從例外規則排到預設路徑

需要優先處理的精確規則，應放在範圍較廣的規則之前，例如先處理明確的內部服務，再設定較大範圍的位址或網域集合。若前面的規則已涵蓋所有 TCP 流量，後面再加入單一網站的 TCP 例外，通常不會生效。維護時應為規則保留用途說明，但應寫在文件或客戶端支援的備註欄位，不能直接把中文註解放進標準 JSON。清理失效項目時，也要保留可還原的副本，避免一次刪除相依設定。

「繞過中國大陸」是客戶端常見的預設規則集名稱，不是 JSON 中能自動完成所有分流的布林開關。實際效果取決於規則資料、規則順序、預設出口及 DNS 行為。不同客戶端、核心與規則資料更新後，特定目標可能有不同結果。需要精確分流時，應檢查執行中的 routing，而非只看選單名稱。系統代理與路由模式的關係，請參閱系統代理與繞過中國大陸模式詳解。

排查單一目標時，先確認請求是否進入核心，再查看命中的出口，最後檢查該出口能否連線。可暫時新增一條完整網域規則做比對；若仍未命中，就檢查請求是否帶有網域、設定是否已重新載入，以及前方是否已有範圍較廣的比對規則。區域網路位址連線異常時，也應檢查系統代理的略過清單，因為請求可能根本沒有進入核心。桌面程序規則取決於平台與流量接管能力，不能把 Android 的分應用代理視為通用 routing 欄位。

dns 解析與路由協作

區分系統解析與內建解析

DNS 負責將網域轉換為位址，但一次連線可能在多個位置進行解析。應用程式可以使用系統解析器，也可能使用自己的解析機制；核心在路由判斷或建立出站連線時，也可能呼叫內建 DNS。頂層 dns 主要設定核心的解析能力，不會只因為存在這個物件，就接管整台裝置的 DNS 請求。若系統仍使用原有解析器，不代表核心的 dns 沒有載入；應先確認觀察到的查詢來自哪個程序、哪個處理階段。

請求透過 SOCKS 帶著網域進入時，後續可能由核心或遠端伺服器處理網域；若應用程式先行解析並提交位址，核心收到的就可能只有位址。這兩種模式會影響路由可見的網域資訊，也會改變錯誤發生的位置。排查「網域無法開啟但位址可連線」時，先找出解析發生在哪一端，再檢查回傳結果。若直接逐一更換所有解析伺服器，可能掩蓋原有問題，卻無法解釋為何某個應用程式與瀏覽器的結果不同。

用於理解欄位的解析範例

以下片段使用本機解析器，保留系統目前的解析路徑，並指定內建查詢優先取得 IPv4 結果。hosts 中的 example.test 指向文件示例位址，只用於說明靜態對應，不會提供實際網站服務。將這段合併到頂層 dns 後，仍須由特定功能呼叫內建解析器才會使用。不同核心對查詢策略與伺服器選項的支援可能不同；若啟動時出現欄位錯誤，請依目前核心的設定定義核對。

{
  "dns": {
    "hosts": {
      "example.test": "192.0.2.10"
    },
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIPv4"
  }
}

hosts 適合少量、明確且穩定的本機對應，不適合長期取代動態網站的解析。許多服務仰賴多個位址、區域調度及故障切換；固定使用過期位址，可能導致間歇性連線失敗。設定靜態對應時，也要注意 TLS 憑證仍會依網域驗證；更改目標位址不會讓任意伺服器取得相符身分。刪除測試對應後，還要考量應用程式與系統快取，否則下次存取仍可能使用舊結果，讓人誤以為設定沒有生效。

解析策略不等於出站策略

dns.queryStrategy 與 routing.domainStrategy 名稱相近，但用途不同。前者主要限制內建 DNS 查詢使用的位址族，後者則控制路由比對時是否需要將網域解析為位址。某些出站或通訊端設定也有自己的網域處理選項，同樣不能混為一談。只將內建 DNS 查詢設為 IPv4，不代表所有應用程式、系統解析及遠端代理都只會使用 IPv4。要定位位址族問題，應分別觀察本機解析、實際連線目標及最終出口。

指定加密解析服務時，也要確保解析服務本身可連線。如果查詢服務使用網域，而連線至該服務又依賴同一條尚未正常運作的解析路徑，就可能形成循環相依。若代理伺服器的網域也需要透過必須先連上代理才能使用的解析路徑，啟動階段同樣可能卡住。應先釐清伺服器網域如何取得初始位址、查詢連線經由哪個出站，以及失敗時是否有可理解的備用路徑。設定複雜不代表更可靠。

排錯可分為三個步驟：先確認網域能否解析，再確認解析結果是否為可用位址，最後檢查連線是否走向預期出口。解析成功但連線逾時，應繼續檢查網路路徑，不要把所有逾時都稱為 DNS 錯誤；解析失敗也不應透過關閉憑證驗證來處理。比較解析結果時，請記錄時間與位址族，因為動態調度可能造成結果不同。只有當變更能穩定重現並對應故障時，才有依據決定是否保留。

路由中的 geosite 資料描述網域集合，geoip 資料描述位址集合；兩者都不是 DNS 快取，也不會自動將網域轉成正確位址。規則集合能否載入、網域能否解析、出口能否連線，是三個不同的檢查點。透明接管、虛擬位址與 DNS 分流會引入更多狀態，建議先建立一般本機代理基準設定，再逐步加入這些功能。若涉及路由器或旁路由，請參閱Xray 閘道部署概覽，不要直接套用桌面監聽設定。

policy 策略、日誌與統計

使用者層級策略如何關聯

policy 用於定義連線行為及統計相關策略，不是另一套路由表，也不是會自動替應用程式配置頻寬的限速器。levels 物件依使用者層級組織參數，JSON 中的鍵名是字串；協定使用者中的 level 則用來對應相應層級。只有在協定與設定路徑支援這項機制時，層級才有意義，不能把任意入站標籤當成層級名稱。若沒有明確需求，請先使用核心預設策略，避免把不了解的參數當成通用最佳化選項。

以下展示層級零的連線時間參數，數值以秒為單位，用於說明結構，並非建議所有網路都採用這組值。handshake 限制相應連線握手階段的時間；connIdle 用於處理連線閒置時間；uplinkOnly 與 downlinkOnly 會影響連線進入單向狀態後的等待行為。各參數適用於哪些協定與階段，應以目前核心的實作為準。它們不能取代伺服器健康檢查，也無法只靠調大數值就恢復無法連線的遠端位址。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

時間參數的影響

閒置逾時設得太短，可能讓暫時沒有資料傳輸的連線過早中斷；設得太長，則可能讓已失效的連線佔用資源更久。長連線應用程式是否受影響，還取決於應用程式本身的心跳、伺服器逾時設定及網路設備狀態。排查中斷時，應記錄最後一次有效資料到連線中斷的時間，確認是否反覆出現相同間隔。只因為看到一次斷線就延長所有逾時，既無法定位問題，也可能延遲釋放真正失敗的連線。

理解握手逾時時，也要考量連線階段。網路壅塞、伺服器回應緩慢及驗證不一致，都可能表現為握手未能及時完成，但處理方式不同。延長握手等待時間只能擴大容許範圍，無法修復錯誤的使用者參數或不相符的傳輸設定。先依執行日誌確認失敗階段，再決定是否小幅調整。若修改後只是從「快速失敗」變成「等待更久才失敗」，應還原原值，繼續檢查位址、協定與安全層。

先選擇合適的日誌層級

log 位於頂層，loglevel 可選擇目前核心支援的層級。日常使用通常查看 warning 或 error；排查問題時可暫時調高至 info，需要更多細節時再短時間使用 debug。較詳細的日誌不會讓連線速度變快，也可能包含存取目標、本機路徑或使用者識別資訊。分享排錯內容前，請移除訂閱網址、驗證資料及可識別個人身分的資訊。保留完整錯誤原文與發生順序，比只截取最後一句「失敗」更有幫助。

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

若明確設定 access 與 error 檔案路徑，也要確認執行帳戶有寫入權限、目錄存在且磁碟空間足夠。桌面客戶端可能已接管日誌輸出，手動設定路徑後不一定會顯示在客戶端的日誌面板中。相對路徑取決於程序的工作目錄，不應依編輯器所在目錄推斷。完成排查後，應將日誌層級調回較低設定，並依保留期限清理包含存取記錄的檔案，避免日常產生過多記錄。

統計開關不等於監控面板

stats、policy 中的統計選項與 api 的統計查詢能力需要相互配合；單獨開啟一個選項，不會讓桌面介面自動出現圖表。入站、出站與使用者統計的適用範圍不同；使用者統計也可能依賴協定中的使用者識別欄位。如果客戶端已提供流量統計，請先使用介面現有功能，不要為了顯示數字而額外開放管理介面。統計值反映特定計數位置，不一定等於電信業者計費流量，也不等於應用程式實際檔案大小。

評估「最佳化」時，應使用相同應用程式、相同伺服器及相同測試目標；先記錄原始設定下的狀況，再一次只修改一項策略。傳輸量會受到節點負載、線路、協定、應用程式並行數及裝置效能共同影響，policy 中幾個時間值無法決定整條連線的速度。如果連線穩定但下載緩慢，請參考速度慢的分層排查方法，區分節點、線路與本機設定，不要反覆縮短逾時或開啟所有統計選項。

設定驗證、移轉與還原

建立可重現的修改記錄

修改設定前，先保存目前可正常使用的狀態，並明確記下要解決的問題，例如「某個應用程式未走代理」、「某個網域走錯出口」或「切換網路後解析失敗」。這些問題分別涉及入口、路由與解析，不應一律透過重新匯入所有訂閱處理。記錄客戶端、實際使用的核心、流量接管方式與修改欄位即可，不必抄錄驗證資料。保存副本時也要注意可能包含私密伺服器資訊，不宜上傳至公開位置。

手動設定 JSON 至少要經過三個層次的驗證：語法解析、核心接受及實際執行行為。語法層檢查括號、引號、逗號與資料型別；核心層檢查欄位支援、標籤參照及資源載入；行為層則確認實際應用程式是否依預期進入入口並使用正確出口。前兩層通過，不代表第三層必定成功。反過來說，偶然開啟某個網頁也不能證明設定正確；它可能直接連線或使用快取，必須觀察實際路徑才能判斷。

依固定順序啟動與測試

先關閉重複執行的客戶端或測試程序，避免本機連接埠衝突。載入設定後先查看啟動日誌，確認沒有語法錯誤、未知欄位、缺少規則資料或監聽失敗，再讓應用程式發出明確請求。若啟動失敗，不要繼續切換路由模式；若啟動正常卻沒有存取記錄，先檢查應用程式入口；若有記錄但使用錯誤標籤，再檢查路由順序。依此順序排查，能清楚區分「沒有收到請求」與「收到後處理錯誤」。

1. 保留原設定，在副本中只修改一組欄位，並記錄預期變化。
2. 載入副本，檢查解析結果、標籤參照、規則資料及連接埠監聽。
3. 使用固定目標發出請求，核對日誌中的目標資訊與出站標籤。
4. 測試一個理應不受影響的目標，確認例外規則沒有擴大適用範圍。
5. 恢復常用應用程式與原本的日誌層級，並確認重新啟動客戶端後修改是否保留。

測試目標應涵蓋實際需求，但不必一次測試所有網站。至少選擇一個預期直連的目標，以及一個預期經由遠端出站的目標；若涉及區域網路，再加入一個內部服務。不要只用網頁能否開啟做為判斷依據，瀏覽器快取、既有連線及應用程式內建代理都可能影響結果。修改路由或 DNS 後，可先關閉相關應用程式再重新開啟，讓新請求確實使用新設定；若需清除快取，也應記錄清除範圍，避免比較條件不明。

區分可還原的錯誤與相容性問題

出現 unknown field 等訊息時，先確認設定格式是否適用於目前核心，再檢查欄位拼寫與層級。出現 address already in use 時，應檢查重複程序與連接埠，而非更換伺服器。出現憑證錯誤時，檢查系統時間、服務名稱及憑證鏈。規則資料讀取失敗時，則確認檔案是否由客戶端正確管理。錯誤訊息會因核心而異，但「先確認失敗階段，再修改對應欄位」的原則不變。

從 v2rayN 移轉至 v2rayNG 時，可優先移轉支援的伺服器資料，再於行動裝置上重新設定分應用代理與路由。桌面系統代理、檔案路徑及視窗偏好設定，不能直接搬移成核心設定。移轉至 v2flyNG 時，還要確認 V2Fly 核心是否支援原伺服器所需的協定與傳輸。訂閱可讀取，只能證明匯入格式可辨識，不代表其中每個項目都能在目標核心中執行。移轉完成後，應依相同檢查流程重新驗證。

若客戶端支援匯出分享連結、完整設定與備份資料，請先確認匯出內容的用途。分享連結通常只包含單一伺服器資訊，不會完整保留路由、DNS 及系統設定；備份可能包含更多應用程式資料，還原後影響範圍也更大。將匯出檔提供給他人協助排查前，應移除伺服器驗證資訊與訂閱內容。若只需說明規則問題，可單獨提供 routing、相關標籤定義及已去識別的日誌，避免整份備份散布於多個位置。

還原設定不只是把舊文字貼回去，也包括恢復系統代理、原本選用的核心、日誌層級與應用程式入口。若曾新增區域網路監聽或管理介面，也應一併撤銷。還原後重新啟動並測試原有目標，確認確實回到基準狀態，再考慮下一次嘗試。日常操作可回到入門指南依主要流程檢查；需要更換裝置平台時，請前往客戶端下載頁。保留一套明確可用的基準設定，比累積大量來源不明的設定片段更容易長期維護。