V2Ray JSON 設定手冊

一、JSON 結構與設定範圍

先分清用戶端與核心

v2rayN、v2rayNG 和 v2flyNG 是圖形化用戶端，負責管理訂閱、節點、系統代理與啟動流程；實際依設定收發連線的是核心。Project V 提供相關技術生態的基礎，V2Fly 延續 V2Ray 的社群發展，Xray 則是另一個獨立演進的核心分支。它們有不少共通概念，但支援的欄位並不完全相同。遇到一份可用的 JSON 設定，應先確認它適用哪個核心，再查看目前用戶端實際啟動了哪個程式。

本頁以傳統 JSON 設定結構為主，遠端協定範例主要採用 Xray 常見寫法。v2rayNG 通常搭配 Xray 使用，v2flyNG 則是採用 V2Fly 核心的 Android 替代選擇；v2rayN 可管理不同核心，實際功能取決於所選核心與用戶端設定。不能因為選單都有「自訂設定」，就把某個分支的新欄位直接套用到另一個分支。遇到未知欄位或不支援的協定，請先確認核心，而不是反覆更換訂閱。

頂層物件如何串起請求

設定最外層是物件。inbounds 描述請求從哪裡進入，outbounds 描述請求從哪裡送出，routing 則決定兩者之間的選擇方式。dns 設定內建解析器，policy 管理部分連線與統計策略，log 則用來觀察執行狀況。這些欄位並非依照撰寫順序執行的指令碼；欄位寫在檔案前面，不代表它會先於後面的模組處理流量。

以下是刻意精簡的本機測試設定：只監聽本機 SOCKS 連接埠，收到請求後直接連線至目標。適合用來驗證 JSON、連接埠與應用程式代理設定，但不會建立遠端代理連線。如果連接埠已被其他程式使用，請同步修改設定與測試應用程式。起步設定越簡單，之後加入遠端出站、路由與 DNS 時，就越容易判斷問題出在哪個環節。

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

語法正確不代表設定正確

JSON 的物件鍵與字串要使用英文雙引號，陣列使用方括號，布林值寫成 true 或 false，不能加上引號。物件最後一個項目後面不能加逗號。即使某些載入器容許註解，仍建議儲存為嚴格 JSON，方便在不同用戶端間檢查。不要在同一個物件中重複使用相同的鍵；有些解析器會以後值覆蓋前值，有些則會拒絕載入，讓實際設定難以判斷。

語法檢查通過後，還要確認欄位所在層級。例如 port 屬於入站物件，遠端伺服器的連接埠則位於對應協定的伺服器設定中；streamSettings 通常與出站的 settings 同層，不應放進伺服器位址物件。結構錯誤不一定會造成檔案無法讀取，也可能讓特定設定遭到忽略。閱讀範例時，先確認外層括號再複製欄位，通常比只比對單一關鍵字可靠。

建議保留一份可正常執行的基準副本，並記錄每次調整的目的，例如「只新增內網直連規則」。節點憑證、訂閱網址與日誌中的存取目標都可能含有私人資訊，分享設定前請先替換。本文含遠端位址的範例使用說明用途的網域與識別資料，只用來展示結構，並非可連線的服務；只有上方的本機直連設定可在連接埠未被占用時直接測試。

二、inbounds：本機請求入口

監聽位址、連接埠與協定

入站設定要先回答三個問題：在哪個位址等待連線、使用哪個連接埠、接受哪種協定。listen 設為 127.0.0.1 時，只有本機可以連線至這個 IPv4 監聽位址；設為 0.0.0.0 則會監聽所有 IPv4 網路介面，區域網路中的裝置也可能連得上。後者不是通用的「相容性較佳」開關，還必須考量防火牆、網路環境與存取控制。只供本機瀏覽器使用時，保留迴圈位址監聽會比較容易管理。

port 是本機服務連接埠，不是遠端節點的連接埠。兩者填入相同數字並沒有特殊效果。SOCKS 與 HTTP 是不同的入站協定，應用程式端也要選擇正確類型；只有正確的位址與連接埠還不夠。系統代理、瀏覽器擴充功能與終端機環境變數可能各自指向不同入口，因此某個瀏覽器能開啟網頁，不代表所有應用程式都使用同一個入站。

新增 HTTP 入口

以下示範兩個入站的組合，可取代第一章設定中的 inbounds 陣列。SOCKS 適用於支援此協定的應用程式；HTTP 則適用於一般 HTTP 代理，以及支援 CONNECT 的用戶端。兩個連接埠都必須未被占用。HTTP 入站不是通用的 UDP 入口；SOCKS 支援 UDP，也不代表所有應用程式都會傳送 SOCKS 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": {}
  }
]

tag 是設定內部使用的名稱，後續路由可透過 inboundTag 明確引用。建議使用能表達用途的簡短名稱，並確保不重複。標籤不會自動建立系統代理，也不會因為名稱叫「全域」就接管所有流量。若要讓不同入口使用不同出口，可以分別命名，再於路由規則中明確設定對應關係，避免猜測用戶端顯示名稱的意思。

嗅探用來補充目標資訊

部分應用程式只會把目標 IP 傳給核心，因此網域規則缺少比對依據。嗅探可嘗試從支援的初始協定資料中辨識 HTTP 主機名稱或 TLS 伺服器名稱資訊。常見設定放在入站物件的 sniffing 中；啟用 enabled 後，由 destOverride 指定要嘗試辨識的類型。嗅探不是解密工具，也無法保證每條連線都能取得網域；遇到加密握手資訊或非目標協定時，可能無法補上。

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

這是 Xray 常見的入站附加設定。routeOnly 表示將嗅探取得的資訊用於路由判斷，而不直接據此改寫實際連線目標；實際支援情況仍應確認核心版本。排查時要分清楚「辨識出網域」、「規則比對成功」與「目標連線成功」這三件事。嗅探有結果只代表第一步成功，不能證明 DNS、遠端傳輸或目標服務都正常。

Android VPN 接管與一般代理不同

在 v2rayNG 中，系統 VPN 授權與流量接管由用戶端配合完成。不能只複製一個 SOCKS 入站，就期待能接管整部裝置的流量。依應用程式設定代理、排除特定應用程式與背景執行限制，也都不屬於 JSON 設定。匯入自訂設定後，請確認用戶端如何使用該設定，以及用戶端保留了哪些本機連接埠，避免與自動產生的監聽入口衝突。

桌面端也要分清楚系統代理與 TUN。系統代理只會影響遵循相關設定的程式；TUN 還涉及虛擬介面、權限與路由處理，並非單一入站欄位就能完整描述。遇到「只有部分應用程式能用」時，先確認應用程式是否有連上核心，再檢查出站。若要了解瀏覽器與終端機的差異，可接著閱讀系統代理排查紀錄：瀏覽器與終端機分開檢查，不要一開始就修改遠端協定參數。

三、outbounds：連線出口與協定參數

預設出口與標籤引用

出站設定決定核心如何連線至目標。一份設定可以同時包含遠端代理、直接連線與阻斷出口，但這些出口不會因此自動分工。沒有符合的路由規則時，傳統設定通常會使用出站清單的第一項作為預設出口。因此調整陣列順序可能改變未符合規則的請求如何處理。先決定預設策略再新增例外，比起隨意排列標籤後觀察結果更容易理解。

路由透過 outboundTag 引用出站的 tag，兩者必須完全一致。介面上顯示的節點備註不一定等於執行設定中的標籤。常見問題之一是複製規則後仍指向舊名稱，導致核心找不到目標出口。另一種情況是把直連設為預設出口，卻以為未符合規則的流量都會經過代理。閱讀設定時，應從出站陣列的第一項開始確認，再逐條追蹤路由引用。

直連與阻斷的基本寫法

freedom 用於直接連線至請求目標，blackhole 則用於中止流量。以下是兩個可個別引用的出口物件，可加入現有的出站陣列。直連仍使用裝置本身的網路，不代表目標一定可連線；阻斷也不是能完成連線的備用節點。排查時可暫時將測試網域指向直連，比較代理路徑與本機網路的差異；請記錄修改內容，並在測試完成後還原。

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

VLESS 範例中的欄位歸屬

以下示範 Xray 的 VLESS 出站結構。範例網域與使用者識別碼僅供閱讀，必須替換成伺服器實際提供的參數才能連線。address 是建立遠端連線使用的位址，port 是伺服器監聽的連接埠，users 是此協定的使用者參數集合。id 是使用者識別碼，encryption 的寫法由協定定義；此處的 none 不代表傳輸層沒有安全保護。

{
  "tag": "proxy",
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "edge.example.org",
        "port": 443,
        "users": [
          {
            "id": "00000000-0000-4000-8000-000000000001",
            "encryption": "none",
            "level": 0
          }
        ]
      }
    ]
  },
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.org"
    },
    "wsSettings": {
      "path": "/tunnel"
    }
  }
}

這段設定中的協定參數與傳輸參數屬於不同層級。VLESS 使用者識別碼正確，但 WebSocket 路徑錯誤，連線仍會失敗；TLS 握手成功，也不代表使用者驗證通過。伺服器要求的流量控制選項、傳輸類型與其他參數都必須逐一相符，不能只因協定名稱相同就認為節點相同。範例未包含所有選用欄位，未列出的參數也不應自行猜測補上。

不同協定不可混用設定結構

VMess 也常見 vnext 結構，但使用者參數的意義與 VLESS 不同；Trojan 通常使用 servers 陣列與密碼欄位。不要把 Trojan 密碼放進 VLESS 的 id，也不要將某個協定的使用者物件直接套用到另一個協定。匯入節點分享連結後，先在用戶端介面確認協定與重要參數，比手動拼接長篇設定檔更不容易遺漏。

出站還可能包含網域解析、介面綁定與鏈式轉送等進階選項。這些功能在不同核心間差異較大，只有確定需要時再加入。所謂「備用出口」也不代表會自動故障切換；只多寫一個出站，核心不會因此自動測速並挑選較快的出口。自動選擇通常還需要相應的選擇機制、監測邏輯或用戶端功能支援，請依目前使用的核心文件分別設定。

如果匯入後只有某個出站失敗，請保留其他可運作的設定，只替換該出站的位址、驗證資訊或傳輸參數進行比較。避免同時修改出口順序與路由；否則即使連線恢復，也難以判斷是節點修復了，還是流量改走另一個出口。

四、傳輸與安全層：分開檢查參數

協定、承載方式與加密並不相同

閱讀節點設定時，可拆成三個層次：代理協定負責身分識別與轉送方式，傳輸方式負責如何承載連線，安全層則負責相應的握手與保護。例如 VLESS、WebSocket、TLS 分別屬於不同層次。協定名稱正確只是第一步；如果伺服器預期使用 WebSocket，客戶端卻使用一般串流連線，就算連接埠相同也無法成功連線。

streamSettings.network 用來選擇傳輸方式，streamSettings.security 用來選擇該層的安全機制，具體設定則分別放在對應物件中。不同核心對傳輸名稱及新舊欄位的支援情況會變動，因此不能把某份針對新版核心的範例當成所有版本通用的範本。請先保留匯入時的原始參數，再針對明確的錯誤訊息修改；尤其不要批次替換所有看似相近的網路名稱。

WebSocket 與 TLS 參數對照

以下是傳輸設定片段，應放在對應的出站物件中，不能單獨當成完整設定執行。路徑必須與伺服器或前置反向代理相符，並包含開頭的斜線；如果實際路徑帶有查詢參數，也要保留其作用。serverName 用於 TLS 伺服器名稱相關處理，WebSocket 的 Host 則屬於 HTTP 請求層。兩者通常相同，但不能因此視為同一個欄位。

"streamSettings": {
  "network": "ws",
  "security": "tls",
  "tlsSettings": {
    "serverName": "edge.example.org",
    "allowInsecure": false
  },
  "wsSettings": {
    "path": "/tunnel",
    "headers": {
      "Host": "edge.example.org"
    }
  }
}

實際連線位址可以是網域，也可以是服務提供者指定的位址；憑證名稱、TLS 伺服器名稱與 HTTP 主機名稱分別參與不同階段。若位址可連線，但憑證名稱不符，應檢查服務端提供的網域與本機時間，不要直接將 allowInsecure 改成 true。略過驗證會掩蓋憑證或目標錯誤，不應作為日常修復方式。

REALITY 與其他傳輸方式的差異

REALITY 用戶端參數與一般 TLS 設定不同，不能只改一下 security 的名稱就完成轉換。伺服器名稱、金鑰相關參數與短識別碼都必須與伺服器相符，而且欄位支援情況取決於核心版本。透過分享連結匯入時，也應確認用戶端是否完整辨識所有參數。若介面缺少對應設定，請先確認是否支援，不要自行把參數塞進名稱相近的物件。

同樣地，gRPC 服務名稱不是 WebSocket 路徑，HTTP 傳輸相關的要求標頭也不能跨類型任意沿用。更換傳輸方式通常需要同步調整伺服器，單方面切換用戶端不會讓伺服器自動相容。比較兩個節點時，應先確認它們是否使用同一組服務參數，再討論表現差異；否則測得的是不同連線路徑的結果，而不只是傳輸方式的效能差異。

依失敗階段判讀日誌

連線逾時通常先檢查位址、連接埠與路徑的可達性；出現憑證錯誤時，優先確認名稱、憑證鏈與系統時間；若收到 HTTP 狀態碼但升級失敗，常見檢查項目是路徑、主機名稱與前置服務設定。驗證失敗則要回到代理協定層檢查使用者識別碼或密碼。日誌錯誤屬於哪個層級，就優先檢查該層，避免把所有連線問題都歸咎於 DNS。

排查時先使用單一節點、單一應用程式與固定測試目標，並關閉會改寫請求的代理擴充功能，維持可比較的環境。不要同時切換傳輸方式、憑證設定與路由模式。每次只修改一個變數，並記錄失敗階段是否提前或延後；從「無法建立連線」變成「驗證失敗」雖然還沒成功，仍表示前面的網路與握手環節已有進展。

五、routing：規則順序與目標比對

由上而下檢查，符合即選擇出口

路由不會先合併所有比對結果再評分。常見的欄位規則會依陣列順序檢查，符合第一條有效規則後，就會選擇該規則指定的出口，因此精確例外應放在寬泛規則之前。過早出現的「所有流量走代理」規則，會擋住後面的內網直連規則。檢查設定時，不只要搜尋是否存在某條規則，還要確認前面是否已有能攔截該請求的規則。

規則中的不同條件欄位通常必須同時符合；同一欄位的陣列則通常代表多個候選值。例如在同一條規則中同時設定 inboundTag 與 domain，意思是請求必須來自指定入口，且目標網域也要符合，而不是符合任一條件即可。若要表達「網域屬於某個集合，或目標 IP 屬於某個網段」，拆成兩條規則會更清楚，也方便從日誌確認實際觸發的條件。

易於閱讀的規則片段

以下範例先阻擋一個僅供說明的精確網域，再讓私有位址直連，之後將指定網域及其子網域交給代理。設定依賴已存在的 block、direct 與 proxy 出站標籤。geoip:private 需要可用的 GeoIP 資料檔；若環境尚未準備好資料，應先以明確網段測試，不要假設該集合名稱必定涵蓋所有位址。

"routing": {
  "domainStrategy": "AsIs",
  "rules": [
    {
      "type": "field",
      "domain": ["full:blocked.example.org"],
      "outboundTag": "block"
    },
    {
      "type": "field",
      "ip": ["geoip:private"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "domain": ["domain:example.org"],
      "outboundTag": "proxy"
    }
  ]
}

full: 用於比對完整網域，domain: 用於比對網域及其子網域，regexp: 表示正規表示式，geosite: 則用來引用網域集合。未加前綴的一般文字可能採用較寬泛的比對方式，不適合用來取代精確網域。若只要比對單一主機，請優先使用明確前綴，避免把名稱中剛好含有相同文字的其他網域也納入規則。

網域解析策略會改變比對流程

AsIs 會盡量使用請求原有的目標資訊進行路由，不會為了比對 IP 規則就主動解析每個網域。因此，在上述範例中，以網域發起的請求，不一定會因為實際解析到私有位址而符合私有 IP 規則。IPIfNonMatch 會在網域未符合規則時嘗試解析，再進行相關比對；IPOnDemand 則會在比對過程需要 IP 資訊時嘗試解析。這兩種策略都會增加解析依賴。

這些選項主要影響路由判斷，不能簡單視為「所有流量都強制在本機解析」或「DNS 一定經過代理」。網域最後由本機解析還是交給遠端處理，也會受到所選出站與協定行為影響。若修改策略後網頁首次開啟變慢，請先觀察是否增加了解析等待時間。只有在確實需要比對 IP 集合時才啟用相應策略，不要以為越早解析，規則就一定越準確。

集合檔案與介面規則的關係

geosite.dat 與 geoip.dat 分別提供網域與 IP 集合資料，並非核心設定中的一般註解。集合名稱必須存在於目前使用的資料檔中；檔案載入失敗或名稱拼錯，都可能導致啟動失敗。更新後的分類內容也可能改變，排查時應記錄資料來源與變更內容。詳細更新路徑與規則順序請參考GeoIP 與 GeoSite 使用說明。

v2rayN 的路由預設設定與 v2rayNG 的自訂規則，可能會在產生執行設定時與介面選項組合。如果編輯檔案後結果仍像舊規則，請先確認目前實際選取的設定與模式，再查看用戶端是否重新產生了檔案。驗證時分別測試一個精確網域與一個已知私有位址，並觀察出口標籤；只憑某個網頁能開啟，無法證明所有分流規則都如預期運作。

六、dns：解析來源與連線路徑

內建 DNS 不等於系統 DNS

設定中的 dns 定義核心內建解析器的運作方式，但不會自動改寫裝置上所有應用程式的 DNS 設定。瀏覽器可能啟用自己的加密 DNS，應用程式可能呼叫系統解析器，Android VPN 接管功能也可能由用戶端安排 DNS 流量。排查前先釐清：失敗的是誰的解析請求、請求從哪裡送出、由哪個解析器回覆。修改核心 DNS 後若仍測試瀏覽器自己的解析路徑，通常看不到預期變化。

路由模組、直連出站與其他功能是否會呼叫內建解析器，取決於具體選項。應用程式若已傳入 IP，核心可能完全不需要再解析原始網域；若應用程式將網域交給代理，才有機會保留網域資訊供規則或遠端處理。因此「日誌沒有 DNS 查詢」不一定表示 DNS 模組故障，也可能是請求進入時已帶有位址，或目前流程不需要本機解析。

先建立簡單的解析基準

以下片段指定兩個一般 DNS 伺服器，並在核心需要解析時優先只取得 IPv4 結果。這是用來了解伺服器清單與查詢策略的基本範例，不代表這些位址在所有網路中都能連線，也不代表查詢一定會經過代理。實際使用時，應選擇自己能連線且願意使用的解析服務，再依核心的具體行為安排查詢路徑。

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

UseIPv4 會限制內建解析器查詢結果的位址類型，不會停用作業系統的 IPv6，也不會改寫應用程式直接發起的 IPv6 連線。這項設定可用來隔離某些位址類型相關問題，但不應當成所有連線失敗的萬用解法。如果裝置與節點都穩定支援 IPv6，應依實際目標測試後再決定策略，避免為了暫時繞過問題而長期放棄原本可用的連線路徑。

靜態對應與指定網域解析

hosts 可為特定名稱提供內建解析器使用的靜態對應。例如以下設定會將一個僅供說明的測試網域對應到迴圈位址，適合測試本機服務的解析流程。這不等於修改系統 hosts 檔案，也不保證所有包含該網域的出站都會自動改寫；只有使用這套解析流程的操作才會套用對應。測試後請移除設定，避免之後原本應連往遠端的請求被導回本機。

"dns": {
  "hosts": {
    "lab.example.org": "127.0.0.1"
  },
  "servers": [
    "1.1.1.1"
  ],
  "queryStrategy": "UseIPv4"
}

較複雜的 DNS 設定可以為特定網域指定解析伺服器，或設定預期 IP 範圍與回退行為。但這些選項的組合會因核心而異，不能只複製一個伺服器物件，就認為已完成完整的分流解析。尤其要明確設定「指定伺服器沒有回傳可接受的結果時該如何處理」，包括是否允許回退，以及會改用哪些伺服器。先釐清各個分支再加入欄位，比堆疊多組解析器更容易維護。

避免解析依賴形成循環

使用加密 DNS 時，解析伺服器本身的網域也可能需要先解析；若這項解析又依賴尚未連線的代理，就會形成啟動依賴。同樣地，代理伺服器位址若是網域，而該網域的解析又設定成必須經過該代理，也可能導致連線無法開始。排查時先保留一條明確可用的基礎解析路徑，再逐步加入加密解析與路由要求，不要一開始就把所有查詢綁定到同一個尚未驗證的出口。

DNS 查詢的傳送方式也會受到伺服器位址格式影響；一般 UDP 查詢、加密查詢與部分本機處理方式的路由行為並不完全相同。不要只替 DNS 加上標籤，就認為每種查詢都會依該標籤進入路由。請確認目前核心對相應伺服器格式的說明，再透過日誌與實際網路狀況驗證。網域解析成功只代表取得了位址，仍需確認能否透過最終出口連線至該位址。

遇到「節點顯示已連線，但網頁無法開啟」時，可先比較同一目標的解析結果與連線錯誤，再檢查系統時間、位址類型與個別應用程式代理，接著判斷是否需要調整 DNS。完整檢查順序請參閱已連線卻無法上網的逐項檢查清單。每次只更換一個解析器並重新連線；也要考慮應用程式快取可能讓舊結果繼續生效。

七、policy：連線策略與統計開關

策略等級不是系統權限等級

policy 將部分連線行為集中在策略物件中。levels 裡的鍵是使用者等級識別碼，例如字串鍵 "0" 代表零級；協定使用者物件可以透過對應的 level 欄位引用此等級。這個等級不代表管理員權限，也不是節點品質評分。若沒有明確的分級需求，先了解預設策略，通常比替所有使用者新增多個等級更容易維護。

並非所有入站與出站都會以相同方式使用使用者等級。欄位可以寫進 JSON，不代表目前使用的協定一定有對應的使用者資訊。判斷某項策略是否生效，必須同時確認協定支援、等級引用與連線類型。尤其不要只在 levels 新增一個物件，就認為所有流量會自動套用；必須在支援此機制的位置建立關聯。

依階段理解逾時參數

handshake 限制適用連線的握手等待時間，connIdle 用來處理沒有有效資料傳輸的閒置階段，uplinkOnly 與 downlinkOnly 則對應連線只剩單一方向仍在運作的階段。這些設定不是四種可以互相取代的「連線逾時」，也不是數值越小就越靈敏。行動網路切換、長連線通知與緩慢握手對等待時間的需求可能不同，應依實際問題調整。

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

上述範例中的時間欄位以秒為單位，用來展示完整的層級關係，不是適用所有裝置的最佳化建議。如果握手尚未完成就中止，應先檢查連線路徑與伺服器回應，再評估等待時間是否真的太短。如果閒置一段時間後連線重建，應一併檢查應用程式的重新連線機制、系統背景限制與網路變化；不要只因為看到「已中斷」就調高所有逾時設定。

統計需要模組與開關配合

policy.system 中的統計開關會控制相應方向的資料統計。核心端通常還需要啟用頂層 stats 模組；如果用戶端要讀取這些資料，還需要相應的查詢介面或內建整合方式。只開啟統計開關不會自動顯示面板。不同統計項目也不能混為一談：入站統計記錄入口，出站統計記錄出口，使用者統計則依賴可辨識的使用者與相關設定。

"stats": {},
"policy": {
  "system": {
    "statsInboundUplink": true,
    "statsInboundDownlink": true,
    "statsOutboundUplink": true,
    "statsOutboundDownlink": true
  }
}

這是頂層設定片段，合併時應整合至現有的 policy 物件，不要在同一層再寫第二個同名鍵。統計通常反映核心處理的資料量，不等於電信業者計費的流量；連線標頭、重傳與系統的其他流量可能不計入相同範圍。用戶端顯示的累計量也可能在重新啟動後歸零；查看前應先確認統計範圍與計算期間，不要直接相減不同介面的數字。

效能問題別先堆疊策略參數

網路速度變慢，常見原因包括目標服務、遠端節點負載、網路路由與本機流量接管方式。策略中的等待時間主要管理連線生命週期，不會憑空增加可用頻寬。部分核心允許調整連線緩衝設定，但緩衝區大小不等於傳輸量，設得過大也可能增加記憶體負擔。應先取得可重複的測試結果，再判斷特定參數是否與觀察到的問題有關。

Android 裝置還要留意電池限制與背景執行狀況；桌面端則應檢查系統代理、TUN 與其他網路工具是否互相影響。這些因素並非都屬於 policy。如果應用程式切到背景後才失去連線，應先確認用戶端是否仍在執行，而不是把閒置時間調到極大。若只有特定時段速度變慢，請先比較不同節點與直連結果；詳細方法請參閱網速慢的分層診斷。

八、合併設定、驗證日誌與復原

將片段合併為有效設定檔

本頁中的多個範例都是局部片段，不能直接首尾相接。合併時保留一個頂層物件，將所有入站物件放進同一個 inbounds 陣列，將出口物件放進同一個 outbounds 陣列；路由規則則加入現有的 rules，並重新確認順序。頂層的 dns、policy 與 log 各自只保留一個明確物件，避免重複鍵覆蓋先前設定。

完成語法檢查後，再沿著一個請求逐步追蹤：應用程式是否連上正確的入站、入口標籤為何、請求保留的是網域還是只有 IP、第一條符合的規則是哪一條、指定的出站標籤是否存在，以及遠端傳輸參數是否完整。這種手動追蹤方式能找出不少「設定檔可以啟動，但連線方式不對」的問題。尤其要確認預設出口，避免測試成功其實是因為意外直連。

先在用戶端確認載入結果

在 v2rayN 中，先確認目前選取的設定、核心類型與路由模式，再查看日誌視窗；在 v2rayNG 中則確認目前的設定項目、VPN 授權與服務狀態。選單名稱可能會隨用戶端版本調整，請以目前介面為準。自訂設定與一般節點編輯的管理方式可能不同；修改後要重新啟動相應服務，並確認日誌顯示載入的是剛才修改的內容，而不是其他設定項目。

暫時將日誌等級調高至 info，通常更容易查看連線目標與出口。排查完成後可恢復為 warning，減少長期記錄的內容。如果設定檔尚未通過解析，檔案中的日誌設定可能還來不及生效，此時應查看用戶端顯示的啟動輸出。不要因為沒有產生日誌檔，就判定核心沒有嘗試啟動。

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

使用固定目標驗證本機入口

桌面端若有可用的命令列請求工具，可以明確指定本機代理，排除系統代理是否生效的影響。以下兩個命令分別測試 SOCKS 與 HTTP 入口，對應第二章所用的連接埠。SOCKS 命令會透過代理端流程處理網域；HTTP 命令則使用本機 HTTP 代理存取同一個僅供說明的網站。這些命令用來驗證請求能否經由指定入口完成，不是測速工具。

curl --proxy socks5h://127.0.0.1:10808 https://example.org/
curl --proxy http://127.0.0.1:10809 https://example.org/

如果命令顯示本機連線遭拒，優先檢查監聽連接埠與服務狀態；若請求已進入核心但遠端逾時，再檢查出口與網路；若命令成功但瀏覽器失敗，則重點檢查瀏覽器擴充功能、個別代理設定或 DNS 行為。Android 端可使用固定瀏覽器與固定目標重複測試，同時查看 v2rayNG 日誌與個別應用程式設定，不必為了照搬桌面命令額外安裝工具。

依錯誤類型縮小排查範圍

日誌最後一行有時只是前面錯誤造成的結果，例如連線關閉可能源自更早的解析或驗證錯誤。請保留同一次嘗試的前後文，從第一個明確錯誤開始往下讀，比只截取最後一行更有幫助。分享日誌前請替換使用者識別碼、密碼、訂閱網址與存取目標，只保留欄位名稱、錯誤類型及必要結構。更詳細的啟動錯誤分析請參閱v2rayNG 核心日誌判讀。

為每次變更保留還原點

較穩妥的順序是：先確認基準設定能成功啟動，再加入遠端出站、驗證單一連線，接著才新增路由、DNS 與策略。每一步都儲存一份副本，並記下修改目的。發生故障時，先還原至最近可用的設定，確認裝置與網路仍正常，再單獨重做失敗的修改。這樣能區分環境變化與設定問題，也能避免繼續在已經混亂的檔案上層層補丁。

最後，盡量將需要日常維護的設定放回用戶端可管理的位置，並確認訂閱更新後哪些內容會保留、哪些會重新產生。本手冊用來理解底層設定的關聯，不代表每次使用都要手動撰寫完整 JSON。需要重新整理匯入與連線步驟時，請返回快速入門教學；需要下載適用於作業系統的程式時，再前往用戶端下載頁面選擇相應版本。