V2Ray JSON 設定參考

JSON 結構總覽與設定範圍

用戶端設定與核心設定的界線

JSON 設定描述代理核心如何接收連線、選擇出口、解析網域及管理工作階段，不等於用戶端的所有設定。v2rayN 儲存的視窗狀態、訂閱群組、系統代理開關及自動更新間隔，通常屬於用戶端本身的資料；啟動核心時，用戶端再依據這些資料產生執行設定。v2rayNG 與 v2flyNG 也各有自己的設定管理方式。請先確認目前查看的是用戶端儲存檔、匯出的自訂設定，還是這次啟動實際使用的檔案；否則即使修改正確，也可能不會套用到執行流程。

核心設定的頂層通常包含 log、inbounds、outbounds、routing、dns 與 policy。其中入站與出站是陣列，可同時定義多個物件；路由與策略則是物件，內部還會巢狀包含規則或級別。欄位在檔案中的排列順序不代表執行順序；真正影響行為的是陣列順序與引用關係。例如路由規則由上而下比對，未符合任何規則的連線通常會使用出站陣列的第一個項目。

建立易讀的最小結構

以下是完整的本機直連測試設定，可用來確認 JSON 能否載入、回環位址能否監聽，以及本機能否直接連線至目標。這份設定只建立 SOCKS 入站與直連出站，不提供遠端代理功能，也不會設定系統代理。應用程式必須明確使用這個 SOCKS 入口，流量才會進入核心。測試前請先停止占用相同連接埠的其他執行個體，避免把連接埠衝突誤判為欄位設定錯誤。

{
  "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": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

閱讀設定時，可以先整理出一條邏輯流程：應用程式連線進入帶有標籤的入站，路由根據目標位址與入站標籤進行比對，最後將連線交給某個出站。需要解析時會用到 DNS；策略則會限制交握與閒置連線等行為。理解這個模型比逐行背誦欄位更實用，因為同一個故障可能出在不同層。例如應用程式未進入入站，修改出站協定就不會改變結果；出站標籤拼錯，修改 DNS 也無法修正引用。

語法、合併與修改範圍

本手冊統一採用標準 JSON：鍵名與字串使用雙引號，布林值寫成 true 或 false，連接埠使用數字，陣列與物件的最後一個項目後面不加逗號。部分載入器允許註解或擴充語法，但不能假設所有用戶端都支援。尤其應避免重複鍵：不同剖析器可能會覆寫、拒絕，或產生難以察覺的差異。合併兩段設定時，請將內容合併至同一個頂層物件，不要把兩個根物件直接連續貼在一起。

修改前請保留一份可正常運作的基準設定，並記錄修改是透過哪個入口進行。透過圖形介面管理的設定，應優先回到對應頁面調整；手動編輯自動產生的檔案，可能在重新啟動、切換節點或更新訂閱後被重新產生。若要長期保留自訂欄位，請先確認用戶端的自訂設定模式、覆寫規則及路由匯入功能，不要依賴臨時檔案路徑。不同系統的資料目錄各不相同，不宜照抄他人截圖中的絕對路徑。

選擇核心也是閱讀設定前的必要條件。V2Fly 與 Xray 在部分協定、傳輸名稱及擴充欄位上有所不同，不能因為檔案都是 JSON 就假設可以互換。請先在用戶端確認目前使用的核心，再核對該核心支援的欄位。遇到未知欄位或協定錯誤時，先縮小檢查範圍至相關物件，不要一次替換整份設定。術語說明可參閱術語表，操作流程則以教學頁為主。

inbounds 入站與本機監聽

監聽位址、連接埠與協定

inbounds 定義核心接收連線的入口。每個入口至少要指定協定及相關設定；常見的本機入口有 SOCKS 和 HTTP。listen 控制監聽位址，port 控制連接埠，tag 則提供路由引用的名稱。標籤只是設定內部的識別名稱，不會自動建立系統代理，也不會讓瀏覽器主動連線。應用程式是否使用代理，仍取決於應用程式的代理選項、作業系統設定或其他流量導入方式。

只供本機使用時，將監聽位址設為 127.0.0.1，即可明確限制在 IPv4 回環介面。監聽 0.0.0.0 代表接收本機所有 IPv4 介面上的連線；區域網路裝置能否連入，還取決於防火牆與網路環境，但可接觸的範圍已經不同。不要為了排錯就直接擴大監聽範圍。若確實需要在區域網路分享，請一併規劃驗證方式、允許連線的來源及系統防火牆，並確認哪些人可以使用該出口。

連接埠必須與使用它的應用程式設定一致。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": {}
    }
  ]
}

UDP 與目標識別

SOCKS 設定中的 udp 允許此入口處理相應的 UDP 請求，但它不是讓所有程式自動取得 UDP 代理能力的總開關。應用程式必須支援相應的連線方式，出站協定及遠端服務也必須能轉送這類流量。作業系統的一般 HTTP 代理設定不等於接管整台裝置的 UDP 流量。若網頁可以使用，但即時通訊失敗，請分別檢查應用程式的連線方式、入口支援情況及出口能力，而不是反覆切換這個布林值。

sniffing 可從部分連線的初始資料中辨識目標資訊。常見設定會透過 destOverride 指定嘗試辨識 HTTP 主機名稱或 TLS 服務名稱，以便在原始目標只有 IP 時協助網域路由。並非所有連線都能取得識別結果，也無法解密任意加密內容。協定是否提供可辨識資訊，以及用戶端實際啟用哪些選項，都會影響結果。啟用識別不代表所有網域規則都一定能比對成功。

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

上述物件應放在目標入站內部，而不是設定根目錄。是否使用識別結果改寫連線目的地，以及是否只將結果用於路由，在不同核心中可能有額外選項與行為差異。若要保留原始 IP 連線語意，請確認目前核心支援只用於路由的選項。識別功能也不能取代妥善的 DNS 設計：應用程式透過 SOCKS 提交網域時，核心原本就可能直接取得網域，不一定要額外依賴識別才能比對網域規則。

監聽失敗的檢查順序

啟動時若出現位址已被使用，請先確認是否有另一個用戶端或舊核心仍在執行，再檢查本次設定是否重複定義相同的位址與連接埠。更換監聽連接埠後，瀏覽器手動代理、應用程式代理及用戶端設定的系統代理都必須同步更新。只修改 JSON 中的數字，會讓應用程式繼續連到舊連接埠，看起來就像核心沒有回應。詳細排查方式請參閱本機連接埠遭占用與修改監聽連接埠。

若沒有啟動錯誤，卻看不到連線記錄，請確認應用程式確實連到目前的入口，並檢查應用程式本身是否設有代理略過清單。接著分辨 IPv4 回環位址與 IPv6 回環位址，不要假設監聽其中一個就涵蓋另一個。排錯期間可先只保留一個入口和一個測試應用程式，讓每個請求都有明確來源；確認入口正常後，再恢復其他入口與複雜路由。比起同時調整多個網路層，這樣更容易找出故障位置。

outbounds 出站與標籤引用

協定、出口與預設行為

outbounds 描述流量離開核心的方式。直連通常使用 freedom，拒絕連線通常使用 blackhole，遠端代理則由對應協定的出站負責。protocol 決定 settings 的結構，不能只替換協定名稱，卻沿用另一種協定的伺服器欄位。路由會透過 outboundTag 引用出站的 tag，因此標籤應保持唯一、易讀；修改名稱後也要同步更新引用。

未符合路由規則的流量通常會交給第一個出站，因此陣列順序確實會影響行為。將直連移到第一項，就等於改變未符合規則流量的去向；若將拒絕出站移到第一項，可能導致大量連線立即失敗。不要把出站陣列當成會自動依優先順序嘗試的候選清單。一般出站物件的排列不會帶來失敗回退、延遲測試或負載平衡；這些功能需要另外的機制與明確設定。

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

上述片段只定義兩個出口，沒有指定哪些請求應該遭到拒絕；只有路由引用 block 時，相關流量才會進入拒絕出站。這個範例可用來了解路由行為，但不能取代遠端服務設定。遠端代理物件必須符合服務端提供的資料，包括位址、連接埠、使用者驗證、傳輸方式及安全參數。這些資訊應來自有權使用的來源，不要根據其他協定的範例自行猜測，也不要放進公開的故障回報中。

節點資料與核心支援能力

VMess、VLESS、Trojan 與 Shadowsocks 的驗證欄位及安全模型各不相同。匯入訂閱的其中一項好處，是由用戶端將分享格式轉換為支援的內部表示方式，再產生核心設定。轉換成功不代表每個欄位都符合執行條件：部分協定或傳輸方式需要特定核心，其他連結也可能包含用戶端不認識的擴充參數。切換核心前，請先確認目標協定是否受支援，再檢查產生的設定與啟動記錄。

遠端位址用於建立連線，TLS 服務名稱則與身分驗證有關，兩者可能不同，但不能任意替換。連接埠也不會決定協定類型；相同的連接埠號碼可能承載不同服務。連線逾時不一定是驗證錯誤；驗證遭拒也不一定會明確顯示密碼錯誤，有些服務只會關閉連線。排錯時依序檢查位址是否可連通、傳輸是否建立、安全交握是否成功，以及協定驗證是否通過，避免把所有失敗都歸因於節點失效。

直連解析與出站共用

直連也可能需要 DNS。假設路由選擇了 direct，目標仍是網域，後續建立連線時就仍須取得 IP 位址。路由階段的 domainStrategy 與直連出站本身的解析選項作用階段不同，不能因名稱相似就視為同一個開關。若要控制位址類別或解析來源，請分別確認 DNS 模組、路由及直連出站設定，並透過記錄核對實際連線位址，而不是只看最後網頁能否開啟。

連線共用並非適用於所有協定與應用程式的通用加速選項。它會改變多個邏輯連線共用底層連線的方式，也可能影響故障表現。遇到特定網站中斷、長連線異常或傳輸相容性問題時，請先以預設共用設定建立基準，再單獨比較。不要同時修改連線共用、傳輸、安全驗證與路由；否則即使問題解決，也難以判斷是哪一項變更發揮作用。

更換節點後，仍應保留穩定的路由標籤設計。用戶端可能會為目前選取的節點產生統一的出口標籤，讓規則不必隨節點名稱變動；手動設定則需要自行維護引用。匯入外部規則前，請先對照本機現有的出站名稱，避免規則引用不存在的標籤。若要了解延遲、地區及協定上的節點差異，可另行參閱節點挑選與測試指標說明；但無論測試結果如何，設定引用都必須正確。

streamSettings 傳輸與安全參數

分清代理協定與承載方式

代理協定說明如何驗證身分及轉送流量，傳輸層說明連線如何承載，安全層則說明如何保護與驗證連線。三者並非同一個欄位。VLESS 不等於 REALITY，WebSocket 也不是獨立的代理驗證協定；同一種代理協定可能搭配不同傳輸方式，而某種安全方案也只適用於部分核心與組合。解讀設定時先拆分這三層，才能判斷分享連結中的各項參數應放在哪個物件。

streamSettings 通常位於需要相關傳輸設定的入站或出站物件中，network 指定傳輸類型，security 指定連線安全方式，接著由各自的設定物件提供參數。這個欄位不能單獨建立遠端連線，也無法補足缺少的驗證資料。以下是採用傳統 TCP 命名的 TLS 局部範例，只適用於目前核心確實接受該命名，而且伺服器端提供相應承載方式的設定；不可不加確認就貼到不同核心使用。

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.org",
      "allowInsecure": false
    }
  }
}

範例中的 example.org 是文件示範用網域，不是可供代理連線的服務位址。實際使用時，服務名稱必須符合授權服務提供的憑證身分與設定要求。若核心文件使用其他傳輸名稱或不同設定結構，請採用對應格式，不要只把字串換成看起來相似的名稱。相容性應以目前執行核心的設定規格為準，而不是用戶端按鈕的中文翻譯。

TLS 服務名稱與憑證驗證

serverName 用於 TLS 服務身分相關處理，通常與憑證名稱及伺服器端的選擇有關。遠端連線位址可以是 IP，也可以是網域；即使透過 IP 建立連線，也可能需要正確的網域服務名稱才能完成預期的交握。反過來說，隨意填入常見網域也無法讓憑證變成有效。憑證名稱不符、憑證鏈不完整、系統時間錯誤，以及中間設備介入，都可能造成安全交握失敗。

allowInsecure 不應作為預設的修復方式。停用身分驗證或許能讓表面上的憑證錯誤消失，卻也會改變安全界線。排錯時請先確認系統日期、服務名稱、憑證有效期限與信任鏈，再檢查網路中是否有替換憑證的設備。若服務明確採用自建信任架構，請依照管理流程設定受信任憑證，不要把所有異常一律改成略過驗證。訂閱更新的憑證問題與節點交握的憑證問題也應分開記錄。

WebSocket、路徑與中間轉送

使用 WebSocket 時，路徑、請求主機名稱與反向代理轉送規則通常必須相互對應。TLS 服務名稱、HTTP 請求中的主機欄位，以及底層連線位址各有不同用途；即使某個部署中的值恰好相同，也不代表可以互換。路徑大小寫、結尾斜線，或遭中間代理改寫，都可能讓請求抵達一般網頁，而不是預期的服務。這時出現的可能是 HTTP 狀態錯誤，而非傳統代理驗證失敗。

排查傳輸問題時，先確認服務端公布的承載類型，再檢查是否需要 TLS、請求路徑與主機資訊。不要以瀏覽器能否開啟某個網站，來證明代理傳輸已經正常：一般網頁瀏覽與特定升級請求可能會經過不同的服務分支。若節點是透過用戶端匯入，請先檢查介面儲存的參數是否完整，再查看產生的設定，避免在自動產生的檔案與介面之間來回修改，造成設定來源混亂。

傳輸與協定功能也會因核心而異。v2rayNG 與 v2flyNG 分別面向不同的核心生態，不能假設某個用戶端成功辨識的所有連結參數，另一個用戶端也一定支援。桌面版 v2rayN 的核心選擇同樣要符合節點能力。遇到未知傳輸、欄位無法辨識或交握階段立即中斷時，請先確認功能是否相容，再考慮網路問題；不要連續切換多個參數碰運氣。

條件允許時，每次只驗證一種承載組合：固定遠端資料，保留預設的連線共用與策略，先確認基本交握成功，再逐項恢復進階設定。記錄錯誤發生於剖析設定、建立 TCP、進行 TLS，還是交換代理資料的階段。這些記錄能直接指出需要檢查的物件，也有助於在說明中心依錯誤類型尋找解答，而不是重做整個安裝流程。

routing 規則順序與比對範圍

先比對規則，再選擇出站

routing 負責將已進入核心的連線分配至出口。它不會讓尚未使用代理的應用程式進入核心，也不等於作業系統的代理開關。規則通常依陣列順序由上而下檢查，第一條符合的規則會決定流量去向，因此應將範圍明確的例外放前面，範圍較廣的預設規則放後面。若某條規則涵蓋所有 TCP 與 UDP，後續相關規則通常就不會生效。

同一條規則中的不同欄位條件通常會共同限制比對；同一欄位陣列中的多個候選值則通常表示符合其中一個即可。例如同時設定入站標籤與網域，代表只有指定入口連線到指定網域時才符合規則；若希望一組 IP 或一組網域分別使用相同出口，拆成兩條規則通常更清楚。不要把多個條件塞進同一條規則後，誤以為任意一項符合就會命中。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:example.org"
        ],
        "outboundTag": "block"
      },
      {
        "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",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

此片段搭配前文的 direct、block 出站標籤使用：精確網域會遭到拒絕，列出的本機位址範圍則直連，其餘流量仍走預設出站。這只是規則機制的示範，不是完整的存取分類方案。尤其在 AsIs 下，網域目標不會只為了比對 IP 規則而主動解析，因此不能說加入私有位址範圍就涵蓋了所有最終解析至區域網路的網域。

網域格式與解析策略

full: 用於比對完全相符的網域，domain: 通常用於比對指定網域及其子網域，regexp: 則使用正規表示式。一般字串比對的範圍可能比預期更廣，閱讀也較不容易，建議盡量使用明確前綴。在 JSON 字串中使用正規表示式時還需進行 JSON 跳脫，例如正規表示式中的反斜線必須正確跳脫。規則看起來像網域清單，不代表每個項目都使用相同的比對語意。

路由的 domainStrategy 常見值包括 AsIs、IPIfNonMatch 與 IPOnDemand。前者不會為了路由比對而主動解析網域；後兩者則會依各自條件利用解析結果嘗試比對 IP 規則。是否提早解析會影響查詢次數、規則命中與排錯路徑，但不能簡單視為更快或更準確。請依規則是否需要 IP 分類，以及 DNS 是否已有可用的解析路徑來選擇。

規則資源與模式切換

使用 geosite: 或 geoip: 分類時，也要確認對應資源是否存在、內容是否符合預期，以及用戶端如何更新資源。分類名稱並不代表核心能憑空辨識所有網站，而是對資源資料的引用。載入時若顯示找不到資源，請檢查資源與規則是否配套；若能載入但結果異常，則需確認目標實際符合哪個分類。外部規則名稱相同，也不代表不同資源包內的內容完全一致。

用戶端的「全域」、「略過」等模式通常會產生或切換一組路由，而系統代理則決定哪些應用程式請求會送至本機入口。切換模式後，手動新增的規則是否保留、會插入哪個位置，都需要檢查實際設定。關於這兩層設定的完整說明，請參閱系統代理與路由模式的差異。不要只憑系統匣圖示，就判定所有應用程式都已使用相同的連線路徑。

驗證規則時，請選擇一個能明確區分的目標，先只保留相關例外與預設備用規則，再觀察記錄中的入站與出站標籤。若目標符合了非預期的規則，應先檢查前面是否有範圍較廣的規則、應用程式是否已先行解析網域，以及是否使用目標識別功能，而不是先新增更多重複項目。確認最小規則有效後，再逐組恢復分類，藉此找出是哪一組規則擴大了比對範圍。

dns 解析路徑與位址類別選擇

區分應用程式、系統與核心解析

遇到 DNS 問題，首先要確認查詢發生在哪一層。應用程式可以自行解析，作業系統可以代為解析，核心也可能在路由或建立連線時解析網域；這些流程可能同時存在。若應用程式先將網域解析成 IP，再交給 SOCKS，核心看到的原始目標可能就只有 IP；若應用程式直接將網域交給 SOCKS，核心則會保留網域目標。這兩種路徑會影響網域路由是否需要額外識別，也會影響實際參與查詢的是哪項 DNS 設定。

在頂層設定 dns，不代表接管本機所有網域查詢。它主要提供核心本身所需的解析設定；是否也處理應用程式的 DNS 請求，還得看流量導入方式與 DNS 轉送設計。瀏覽器內建的加密解析功能也可能走另一條路徑。排查時請記錄應用程式是否自行解析、使用哪種代理協定，以及是否啟用其他 DNS 機制，不要只根據系統網路設定推測所有查詢的來源。

{
  "dns": {
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

這個局部片段會讓核心使用系統解析路徑，並允許查詢兩種位址。它適合作為了解設定界線的基準，但不代表系統解析在所有網路環境中都能連到目標。此處的 localhost 是核心約定的系統解析方式，不是要求本機必須有 DNS 服務監聽回環位址。若要指定獨立的解析伺服器，請使用目前核心支援的伺服器表示方式，並進一步確認查詢如何送出。

分開處理解析策略與路由策略

queryStrategy 控制核心 DNS 查詢使用的位址類別，常見值為 UseIP、UseIPv4 與 UseIPv6。限制為 IPv4 或許能避開無法使用的 IPv6 路徑，但也會讓只有 IPv6 位址的目標無法取得可用結果。IPv6 是否可用取決於本機介面、預設路由、出口與目標；不能只因系統顯示有 IPv6 位址，就認定整條連線路徑都正常。

路由中的 domainStrategy 決定何時為規則比對進行解析；DNS 的查詢策略決定解析時查詢哪一類位址；直連出站的相關策略則可能決定建立連線時如何使用位址。三者作用於不同階段。修改其中一個欄位後若恢復連線，只能說明連線路徑有所變化，不能因此認定另外兩處設定也正確。請在保留可運作基準的前提下逐一檢查，不要把名稱相近的策略全部改成相同值。

依網域選擇不同解析伺服器時，也要確認伺服器物件中的網域範圍、預期位址篩選條件及回退行為。伺服器有回覆，不代表該回覆一定會被採用：若不符合預期位址條件，核心可能會繼續嘗試其他路徑。設定複雜的 DNS 分流前，請先從一個明確可連線的解析來源開始，再逐步加入分類與回退；否則解析失敗可能源自伺服器無法連線、條件篩選或回退限制等不同原因。

引導解析依賴與循環

若遠端服務位址本身是網域，就必須在建立連線前先取得 IP 位址；加密 DNS 服務若也使用網域，同樣需要先解析。如果 DNS 查詢路徑又依賴尚未建立的代理出口，就可能形成循環依賴。常見現象是啟動後持續逾時，卻看不到真正的遠端交握。規劃時請分別整理遠端位址、解析伺服器位址與各自使用的出口，確保至少有一條不依賴自身解析結果的可連線路徑。

DNS 查詢是否經過路由、是否交由本機解析器，以及加密查詢是否使用代理，都取決於伺服器格式與核心行為，不能只憑頂層物件的位置判斷。某些伺服器格式有特定的本機處理方式，也不能假設一般路由標籤一定會對它生效。請確認目前核心對伺服器類型的說明，再透過記錄與實際請求路徑驗證。把「已填入 DNS 位址」理解成「所有查詢都會走指定出口」，是常見的誤解。

遇到特定網域無法使用時，請先記錄是否取得解析結果、結果屬於哪種位址類別，再檢查連線目標位址是否可連通。能解析不代表能連線，能連到位址也不代表 TLS 服務名稱正確。若問題只出現在單一應用程式，請優先比較該應用程式的解析設定；若所有應用程式都同樣失敗，再檢查共用的解析路徑與出口。更多依現象分類的處理方式，請參閱說明中心；不要用關閉憑證驗證來取代 DNS 排查。

policy 工作階段策略與統計開關

級別策略不等於路由優先順序

policy 管理工作階段層級的資源與逾時行為；levels 依使用者級別組織策略，system 則管理系統層級的統計等選項。級別不代表規則優先順序，也不是連線速度的等級。只有相關協定使用者或連線實際採用某個級別時，該級別策略才會生效。用戶端產生設定時可能使用預設級別；手動新增級別物件，不會自動將所有連線切換到該級別。

JSON 中的級別鍵應寫成字串，例如 "0"；內部欄位則依規格使用數字或布林值。策略不負責建立出站、不會修復憑證，也不能讓未被路由選取的節點自動參與連線。調整參數前，請先確認問題是交握逾時、閒置工作階段回收，還是統計資料缺失。若錯誤發生在 JSON 載入或監聽連接埠階段，策略尚未參與處理，修改這些數值也不會解決問題。

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

上述內容是用來說明欄位關係的明確策略片段，不是適用於所有網路的固定組合。時間欄位以秒為單位，實際生效情境仍取決於核心實作。若目前設定沒有明確問題，保留用戶端產生的預設策略，通常比照抄一組「最佳化參數」更容易維護。每次調整都應有可重現的故障案例與明確的觀察目標，不要只憑某次網頁載入的感覺判斷策略效果。

交握、閒置與單向連線

handshake 限制相關交握階段可使用的時間，但不是所有底層逾時的統一上限。網域解析、傳輸連線建立與應用程式本身的等待方式，可能各有不同機制。交握時間設得太短，回應較慢時容易提早中斷；設得太長，則可能讓無法使用的連線占用資源更久。排錯時請先確認錯誤發生在連線生命週期的哪個階段，再判斷是否確實受此策略欄位控制。

connIdle 用於處理沒有資料交換的閒置連線。持續傳輸中的下載連線，與長時間沒有資料傳送的訊息通道並不相同。有些應用程式會透過心跳維持工作階段，心跳間隔可能與核心的閒置連線回收時間，以及中間設備的工作階段逾時互相影響。無限延長閒置時間，無法阻止路由器或遠端主動回收連線，也無法修復已中斷的網路路徑。

uplinkOnly 與 downlinkOnly 用於處理工作階段只剩單一方向傳輸時的等待行為。半關閉連線在某些協定中屬於正常狀況，不能立刻視為故障。對上傳、串流回應或長輪詢有特殊需求的應用程式，請先用預設策略驗證，再依記錄與連線狀況逐項比較。任意縮短等待時間，可能會在剩餘回應尚未傳送完畢前就結束工作階段。

統計依賴與資源範圍

啟用統計旗標，不代表用戶端介面一定會顯示數字。核心可能還需要啟用統計模組、提供讀取介面，並由用戶端主動查詢。使用者層級的統計通常也需要協定使用者身分等必要資訊；匿名的本機入口不會憑空產生可區分的使用者物件。若只是想確認本機連線是否經過特定出口，存取記錄往往比架設統計介面更直接，不要為了排錯額外開放管理監聽。

連線統計、網卡流量與服務計費可能採用不同計算方式。傳輸封裝、連線共用、其他處理程序的流量及取樣時間，都會影響數值比較；不能要求不同位置的數字始終相同。設定層級的統計用於觀察對應物件的流量變化，不應當作服務商最終計費的依據。涉及節點流量倍率時，請以服務說明為準，不要試圖透過修改策略欄位改變計費結果。

調整策略時也要考量裝置資源。桌面版與 Android 在背景限制、休眠及網路切換方式上各有不同；長連線中斷可能是系統回收所致，不一定與核心閒置策略有關。v2rayNG 或 v2flyNG 在背景中斷線時，請先確認系統的電池管理與網路權限；v2rayN 在電腦喚醒後出現異常，則先比較重新建立連線後的結果。只有確認核心確實依策略回收工作階段後，才有必要繼續調整相關逾時設定。

設定驗證、記錄與逐層排錯

先確認設定載入，再測試連線

驗證應從設定語法開始，依序檢查核心結構、監聽、流量導入、路由、解析、傳輸與應用程式結果。語法正確只代表剖析器能讀取 JSON，不代表協定欄位受支援；核心成功啟動，只代表基本結構與資源符合載入條件，也不代表遠端連線可用。分別記錄每一層的成功證據，能避免「檔案能開啟，所以設定沒問題」或「瀏覽器失敗，所以節點失效」這類跨層推論。

請先在用戶端儲存可正常運作的設定，或匯出副本，再建立獨立的測試設定。優先使用用戶端提供的設定測試與記錄功能，並確認測試所使用的是目前選取的核心。若使用自訂設定執行，請確認用戶端是否仍會追加路由、改寫連接埠或合併其他選項。測試檔案與實際執行檔案不一致時，再完整的語法檢查也無法說明真實行為；每次驗證都應確認載入來源。

以下指令只使用 Python 標準程式庫檢查並格式化 JSON，不會驗證 V2Fly 或 Xray 的欄位語意，也不會啟動連線。指令中的 config.json 指目前資料夾中的本機測試檔案；Windows 若使用 Python 啟動器，可使用第二條指令。若系統未安裝相應工具，直接使用用戶端的測試功能即可，不必為了閱讀本手冊額外變更執行環境。

python3 -m json.tool config.json
py -m json.tool config.json

暫時提高記錄詳細程度

loglevel 控制記錄詳細程度；日常使用可維持較精簡的級別，排錯時再短暫提高。以下片段會輸出資訊層級的錯誤記錄，但未指定檔案位置，輸出會由實際啟動方式接收。存取記錄是否寫入、寫入位置，以及用戶端能否顯示，都必須分別確認；不要假設提高錯誤記錄級別就一定會產生完整的存取記錄。

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

檢查記錄時，先找第一個錯誤，不要只看最後一句「連線失敗」。未知協定通常與核心支援能力或協定名稱有關；位址已被使用通常指向入站監聽；找不到資源則可能是規則資料問題；解析逾時通常與 DNS 路徑有關；憑證名稱錯誤則指向安全層身分設定。重複重試會累積相似記錄，請標記每次測試的開始時間，只送出一個明確請求，並減少其他應用程式流量對判斷的干擾。

記錄可能包含目標網域、位址、部分訂閱連結或其他使用資訊。分享前請刪除驗證資料、完整訂閱網址及無關的存取記錄，只保留錯誤類型與必要欄位。不要將含有使用者資料的完整設定貼到公開問答區。排錯完成後，請恢復一般記錄級別，並檢查本機記錄的儲存位置與輪替方式，避免長期累積無助於後續分析的資料。

最小重現與復原流程

若入口正常但連線失敗，可先使用本頁的直連基準，確認應用程式能否連到本機入口，再恢復一個資料完整且已知可用的遠端出站。接著加入單一規則，最後再恢復 DNS 分類與策略。每一步都使用同一個測試應用程式與目標，並記錄成功或失敗及對應記錄。這樣便能把問題定位到某次變更，而不必在包含大量節點、資源與覆寫規則的設定中，同時搜尋多種可能原因。

訂閱更新失敗時，請將「下載訂閱內容」與「使用訂閱節點連線」分開驗證。前者可能受連結狀態、用戶端更新路徑或憑證問題影響；後者則取決於節點參數與核心。節點仍可連線，不代表訂閱網址依然有效；訂閱更新成功，也不代表所有節點都能連線。相關排查方式請參閱訂閱更新失敗排查；更新發生錯誤時，不要先重寫整個路由物件。

跨平台移轉時，通常可以沿用設定的邏輯設計，但檔案路徑、監聽衝突、系統代理與背景執行限制都需要重新檢查。Windows 與 macOS 的首次啟動問題可參閱首次安裝與初始設定；Linux 還需分清桌面工作階段的代理設定與應用程式本身的環境，Android 則要留意系統網路導入方式及背景管理。移轉成功的標準，是應用程式請求能依預期進入並離開核心，而不是檔案複製時沒有出現錯誤。

最後請儲存可正常運作的設定、恢復一般記錄級別、確認標籤引用與監聽範圍，並驗證重新啟動後修改仍然保留。接著測試瀏覽、下載及需要長連線的實際應用程式，不要只用單一網頁代表所有使用情境。若不清楚欄位含義，請回到相應章節查閱；需要重新建立操作流程時，請使用快速入門教學。本手冊用於說明設定之間的關係，教學則帶領您依序完成操作，兩者不能互相取代。