V2Ray 設定檔完整參考

01 / CONFIG ROOT

JSON 結構總覽與資料流

設定檔不只是節點資訊的簡單集合

V2Ray 設定檔的根節點是一個 JSON 物件。常見的頂層欄位包括 log、dns、inbounds、outbounds、routing、policy 與 stats。其中，入站負責接收本機應用程式送出的連線，出站決定連線最終從哪裡離開，路由負責將每條連線對應到某個出站，DNS 為網域比對與目標解析提供結果，策略與統計則控制連線層級的行為。理解這條流程比背誦欄位更重要：應用程式連入入站連接埠，核心辨識目標網域或 IP，路由規則由上而下比對，命中後選擇出站標籤，必要時由 DNS 模組參與解析，最後透過對應的出站建立連線。

用戶端產生的設定可能比手寫範例複雜，因為圖形用戶端還會加入本機管理介面、統計入口、多個 DNS 伺服器或相容欄位。排錯時不要看到陌生欄位就整段刪除。先確認它屬於哪個頂層模組，再觀察是否被其他模組透過標籤引用。例如路由規則中的 outboundTag 必須對應某個出站的 tag；策略中的等級編號需要與使用者或入站採用的等級相符；DNS 的 tag 也可能被路由規則當作獨立流量入口處理。

JSON 語法與型別限制

JSON 對標點符號與資料型別的要求很嚴格。物件使用大括號，陣列使用方括號，字串必須放在雙引號中；物件成員之間需要逗號，但最後一個成員後不能保留尾逗號。布林值寫作 true 或 false，不能寫成字串。連接埠通常是數字，寫成 "10808" 可能通過 JSON 語法檢查，卻不一定通過核心欄位驗證。註解也不是標準 JSON 的一部分，複製含有 // 或區塊註解的範例後，常會出現「invalid character」這類解析錯誤。

欄位名稱區分大小寫。outboundTag 與 outboundtag 並不是同一個欄位，domainStrategy 也不能任意改寫。另一個常見問題是層級放錯：協定專用參數通常位於該物件的 settings 內，傳輸參數位於 streamSettings 內，不能把伺服器位址直接放在出站根層。遇到「unknown field」時，應先檢查欄位所屬層級，而不是先懷疑網路。

從最小設定開始擴充

手動維護設定時，應從能啟動的最小集合開始：一個本機入站、一個可用出站、一個直連出站，以及少量路由規則。確認核心能讀取檔案後，再加入 DNS、複雜規則與策略項目。如此可以分開處理「語法錯誤」、「協定參數錯誤」與「路由邏輯錯誤」。一次貼上數百行設定雖然省事，但任何括號錯位都會讓定位成本快速上升。

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

圖形用戶端儲存設定後可能重新產生設定檔，因此手動修改暫存檔不一定會永久保留。需要長期使用的規則，應優先寫入用戶端提供的自訂設定、路由規則或 DNS 設定入口。若只是分析啟動失敗，可將目前設定匯出或複製到獨立位置，再逐段縮減測試，避免下次訂閱更新覆蓋排錯現場。

02 / INBOUNDS

inbounds 入站：監聽、驗證與流量辨識

入站決定本機應用程式如何接入

inbounds 是陣列，一份設定可以同時提供多個本機入口。桌面用戶端常見 SOCKS 與 HTTP 兩類入站：瀏覽器或支援代理設定的軟體可以連接 HTTP 入口，支援 SOCKS5 的程式則連接 SOCKS 入口。透明代理、通道介面或區域網路共用屬於更複雜的接入形式，應在基礎本機代理驗證正常後再啟用。每個入站最好設定清楚且唯一的 tag，例如 socks-in、http-in，方便路由規則依入口區分。

listen 決定監聽位址。寫成 127.0.0.1 時，通常只有目前裝置可以連線，適合個人桌面環境；改為區域網路可存取的位址後，會擴大可連線範圍，此時需要一併考量系統防火牆、入站驗證與網路邊界。不要為了排查「應用程式連不上本機連接埠」就直接擴大監聽範圍，先確認用戶端是否啟動、連接埠是否被占用，以及應用程式代理類型是否與入站協定一致。

port 是本機監聽連接埠，必須與系統代理或應用程式內的代理設定一致。連接埠數字本身沒有固定要求，但同一位址上的兩個程式不能同時占用相同連接埠。若日誌出現 address already in use，應關閉衝突程序、修改監聽連接埠，或檢查用戶端是否重複啟動。修改連接埠後也要更新瀏覽器、終端機環境變數及其他應用程式中的代理位址，否則核心雖已正常啟動，應用程式流量仍不會進入。

SOCKS 與 HTTP 入站參數

SOCKS 入站的 settings 通常包含 auth 與 udp。本機迴路位址上的個人使用情境常用 noauth；若擴大監聽範圍，應依用戶端能力設定存取控制。udp 決定該入站是否接收 UDP 請求，但不會自動保證遠端協定、出站鏈路與目標服務都支援 UDP。HTTP 入站主要處理 HTTP 代理請求與 CONNECT 通道，應用程式必須明確支援 HTTP 代理模式。將 SOCKS 連接埠填入 HTTP 代理欄位，常見表現是連線立即關閉或交握格式錯誤。

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

sniffing 的作用與限制

sniffing 用於從連線初期資料中辨識目標網域，讓原本只取得目標 IP 的流量仍有機會依網域規則分流。destOverride 中常見 http 與 tls，分別對應可辨識的 HTTP 主機資訊與 TLS 交握中的伺服器名稱。它不是解密網頁內容，也不能保證所有連線都能還原網域；加密用戶端問候的變化、非標準協定或直接存取 IP 時，路由仍可能只能看到 IP。

啟用流量辨識後，如果發現某些應用程式的目標被改寫或連線行為異常，可以先只保留必要的覆寫類型，再對照日誌判斷。路由設計不應完全依賴辨識結果：重要的本機網段、保留位址與已知 IP 範圍仍應設定 IP 規則。相反地，關閉辨識後，大量網域規則可能無法命中，尤其是系統先完成解析再提交目標 IP 的應用程式。是否啟用應配合入站方式與應用程式行為決定，而不是機械套用同一套設定。

多個入站的分工

多個入站不只是為了相容不同代理類型，也可以承載不同路由策略。例如一個 SOCKS 入站使用一般分流，另一個入站固定走指定出站。做法是在路由規則中使用 inboundTag 比對入口，再設定目標 outboundTag。入口專用規則應放在通用網域規則之前，否則連線可能先被較寬泛的規則攔截。

排查入站時可以分三步確認：先看核心日誌是否顯示監聽成功，再檢查本機是否存在對應監聽連接埠，最後確認應用程式請求是否真正進入。若核心沒有收到連線，問題通常位於應用程式代理設定、系統代理狀態或連接埠衝突；若已收到連線但無法抵達目標，再轉向路由、出站與 DNS。不要在第一步尚未成立時反覆修改伺服器協定參數。

03 / OUTBOUNDS

outbounds 出站：協定、伺服器與傳輸層

出站陣列與標籤設計

outbounds 描述連線離開核心的方式。常見設定至少包含一個代理出站、一個 freedom 直連出站，以及一個 blackhole 阻擋出站。代理出站連接遠端伺服器；直連出站使用本機網路存取目標；阻擋出站則用於明確拒絕某類連線。路由模組只透過標籤選擇出口，因此標籤應穩定、簡短並表達用途，例如 proxy、direct、block。更換節點時可以修改 proxy 內部的伺服器參數，不必重寫全部路由規則。

陣列順序可能影響沒有明確路由結果時使用的預設出口。為避免依賴隱含行為，重要流量應透過規則明確指向標籤，同時讓主要代理出站保持在容易辨識的位置。圖形用戶端可能依目前節點動態調整第一項，手動合併設定時不要只根據陣列位置判斷出口用途，還應同時檢查 tag、protocol 與協定設定。

協定參數與傳輸參數分層

一個代理出站通常分成兩部分：settings 儲存協定本身所需的伺服器、連接埠與使用者資訊；streamSettings 儲存底層網路、TLS、REALITY 或 WebSocket 等傳輸設定。兩部分必須與伺服器端一致。協定正確但傳輸層不一致時，常見表現是 TCP 已建立後交握失敗；傳輸層正確但使用者識別錯誤時，則可能被遠端立即拒絕。

以下範例展示 VLESS 出站的結構位置，網域、識別碼與公鑰都是用來說明結構的範例值，使用時必須替換為實際設定。security 位於使用者物件內，描述 VLESS 使用者層設定；security 也會出現在 streamSettings 中，後者表示傳輸安全方式。兩個同名欄位位於不同層級，不能互相替代。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "fingerprint": "chrome",
          "publicKey": "replace-with-server-public-key",
          "shortId": "0123456789abcdef"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

address、serverName 與目標網域不是同一回事

address 是用戶端實際連接的伺服器位址，可以是網域或 IP。TLS 或 REALITY 相關的 serverName 則用於交握中的伺服器名稱，兩者有時相同，有時由伺服器端設定決定。路由中的目標網域則是應用程式原本要存取的網站。排錯時必須區分這三者：伺服器位址解析失敗屬於連線入口問題；伺服器名稱不相符通常表現為交握失敗；應用程式目標網域走錯出口則屬於路由問題。

若伺服器位址使用網域，核心在建立代理連線前也需要解析它。DNS 規則寫得過於積極時，可能讓伺服器網域本身的解析被送入尚未建立的代理路徑，形成循環依賴。穩妥的做法是為伺服器網域安排可用的初始解析路徑，或依用戶端提供的伺服器位址處理方式進行設定。修改 DNS 後若所有節點同時失效，應優先檢查這一層，而不是逐一重新填寫節點。

多代理出站與選擇關係

一份設定可以包含多個代理出站，例如 proxy-main 與 proxy-alt。但 V2Ray 核心設定中的多個出站，不會自動等同於圖形用戶端中的延遲選擇或故障轉移。具體選擇由路由規則、負載策略或用戶端產生邏輯決定。不要只是把多個節點物件追加到陣列，就期待它們自動切換。v2rayN、v2rayNG 與 v2flyNG 的節點選擇介面會產生相應設定，手動設定時則要明確每個標籤由誰引用。

排查出站失敗應由外而內進行：確認伺服器位址可解析，確認目標連接埠可連線，再核對協定使用者欄位，最後檢查傳輸安全與網路類型。日誌中的 timeout 多半指向位址、連接埠或路徑無法抵達；handshake failed 更接近傳輸層參數；invalid user 或驗證相關提示則應回頭檢查使用者識別碼。詳細的 TLS 錯誤分類可繼續閱讀TLS 憑證錯誤排查清單。

04 / ROUTING

routing 路由規則：比對順序與分流寫法

規則由上而下命中

routing.rules 是有順序的規則陣列。核心會逐條檢查連線屬性，通常在命中適用規則後選擇對應出站，因此規則順序會直接決定結果。範圍更具體、優先級更高的規則應放在前面，兜底規則則放在後面。例如先阻擋本機不需要的協定、處理內網位址、指定某些網域直連，再安排代理或預設出口。若先寫入範圍很大的網域規則，後面的精確規則即使語法正確，也可能沒有機會生效。

規則中的多個比對維度通常用來共同限制一條連線。例如同一規則同時包含 inboundTag 與 domain，表示連線既要來自指定入站，也要符合網域條件。同一維度內的多個項目，通常表示該維度中任一項命中。設計複雜規則時，建議先用自然語言寫出目標：「來自 socks-special 入站且目標屬於 example.com 的連線走 proxy-alt」，再對應到欄位，避免把「且」與「或」的關係寫反。

domainStrategy 與網域比對

domainStrategy 決定路由過程中何時為了 IP 規則解析網域。常見思路包括盡量依網域比對，只有必要時才解析為 IP，或在網域規則未命中後再嘗試 IP 規則。不同核心版本與設定情境支援的取值，需以用戶端目前的核心行為為準，但原則一致：解析動作會引入 DNS 依賴，策略越積極，就越要確認 DNS 路徑穩定。

網域項目的常見寫法包括完整比對、子網域範圍、關鍵字與規則資料集。full:example.com 只比對完整網域；domain:example.com 可涵蓋該網域及其子網域；keyword:example 範圍更廣，誤比對風險也更高；geosite: 項目則引用核心可用的網域資料分類。規則資料必須與目前核心的資源相符，分類不存在或資源未載入時，不能把它當作網路故障處理。

IP、連接埠與協定規則

IP 規則可以寫單一位址、CIDR 網段或 geoip: 資料分類。內網位址通常應明確直連，例如迴路、私有網路與鏈路本地範圍。連接埠可以寫單一連接埠或範圍，用來限制特定服務流量，但連接埠無法可靠代表應用程式類型，同一連接埠可能承載不同業務。協定辨識依賴核心能夠辨識的連線特徵，只適合處理明確目標，不應取代網域與 IP 規則。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:intranet.example.com",
          "domain:local.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks-special"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

預設出口與規則末尾

並非所有設定都需要寫一條涵蓋全部目標的末尾規則。未命中規則時使用哪個出站，與核心預設行為及出站排列有關。為讓設定更容易稽核，可以保持主要出口位置穩定，並明確列出需要例外處理的流量。如果團隊或多台裝置共用規則，建議在文件中寫清楚「預設走向」，不要依賴維護者記憶。用戶端匯入新節點後，檢查出站排序是否改變也是必要步驟。

分流失效時，先觀察目標在路由階段以網域還是 IP 出現。若規則寫的是網域，但日誌只有 IP，請檢查入站辨識與 DNS 處理；若看得到目標網域卻未命中，請檢查比對前綴與規則順序；若日誌顯示已命中正確標籤但連線仍失敗，應轉向對應出站。區分「未命中」與「命中後出站失敗」，可以避免在規則表中不斷新增重複項目。

用戶端自訂規則的套用位置

v2rayN 的路由設定、v2rayNG 與 v2flyNG 的分流設定，最終都會轉換為核心可讀取的規則。不同用戶端對規則集合、預設模式與自訂項目的合併順序可能不同。修改前先匯出目前設定或查看執行中的設定，確認自訂規則位於預設規則之前還是之後。若用戶端提供「略過區域網路」、「全域」、「規則」等模式，這些模式控制的是產生邏輯，不只是介面上的開關。

中國大陸直連與境外代理這類常見方案，涉及網域分類、IP 資料與規則順序的共同作用，不能只複製一行規則。完整寫法與排錯流程可參考V2Ray 路由規則設定實戰。搬移規則時也要確認目標用戶端採用的核心版本與資源檔案是否支援相同分類名稱。

05 / DNS

DNS 設定：伺服器選擇、網域規則與出口關係

V2Ray DNS 解決什麼問題

DNS 模組為核心需要解析的網域提供結果，也可以依網域類別選擇不同伺服器。它與系統 DNS 並不是完全的替代關係：應用程式可能先在系統層解析，只把 IP 交給代理；也可能將網域原樣交給 SOCKS 或 HTTP 入站；伺服器位址本身也可能需要由系統或核心完成初始解析。因此，判斷 DNS 問題前，必須先確認查詢由誰發起、目標網域在哪一層解析，以及解析結果是否參與路由。

最簡單的 servers 陣列可以包含 localhost 或 DNS 伺服器位址。更細緻的物件寫法可以指定伺服器位址、適用網域與查詢預期。伺服器順序不能簡單理解為「第一個失敗就永遠使用第二個」，實際行為還會受到網域比對、查詢類型與核心實作影響。設定多個伺服器時，應明確定義每個伺服器負責哪些網域，而不是堆疊大量位址，期待自動得到更好的結果。

依網域選擇 DNS 伺服器

為伺服器物件設定 domains 後，符合條件的網域可以優先使用該伺服器。網域表示方式與路由規則相似，可以使用完整網域、網域範圍與可用的資料分類。這裡的規則負責「向誰查詢」，路由規則負責「查詢流量或最終連線從哪個出口離開」，兩者屬於不同層次。只寫 DNS 網域條件而沒有處理對應出口，不代表查詢一定會依預期路徑進行。

{
  "dns": {
    "hosts": {
      "router.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "full:router.example",
          "domain:local.example"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts 可以為特定名稱提供靜態對映，適合固定的本機服務名稱或測試環境。不應使用它維護大規模且頻繁變動的位址表。靜態對映會繞過一般查詢，一旦位址變更，舊值可能持續造成連線異常。排查某個網域的解析結果與系統不同時，別忘了檢查 hosts，包括用戶端介面產生的自訂主機記錄。

查詢策略與位址族

queryStrategy 控制查詢位址類型的傾向。實際可用值與細節取決於所使用的核心，但通常涉及同時使用 IPv4 與 IPv6、只查詢其中一種，或依環境選擇。不要因為某次 IPv6 路徑無法使用，就永久刪除所有相關能力；更合理的做法是先確認本機網路、遠端出站與目標網站是否形成完整鏈路。如果系統具備位址卻沒有可用路由，解析成功後仍會連線逾時，這屬於網路路徑問題，而不是 DNS 沒有回傳結果。

網域規則使用 IP 分類時，核心可能需要先解析目標，再將結果與 IP 規則比較。此時查詢策略會間接改變路由結果：同一網域回傳不同位址族，可能命中不同網段規則。設計設定時應避免讓路由結論過度依賴偶然的一次解析結果。對於必須穩定直連的內網名稱，同時使用清楚的網域規則與內網網段規則進行雙重限制，更容易維護。

DNS 查詢如何選擇出站

DNS 伺服器位址本身也是網路目標，可以透過專用標籤或路由規則控制出口。若使用一般 IP 位址作為 DNS 伺服器，可依目標 IP 與連接埠辨識；若使用網域形式的加密 DNS，還要先解決該伺服器網域的初始解析。常見循環是：解析代理伺服器需要 DNS，DNS 被路由到代理出站，而代理出站又必須先解析伺服器位址。處理方式是為啟動鏈路保留一個不依賴代理的可用解析入口，或使用用戶端支援的明確引導設定。

出現 DNS 查詢成功但網頁無法開啟時，應繼續查看最終連線，而不是停留在解析結果。可能的情況包括路由將解析後的 IP 送往錯誤出站、遠端不支援相應位址族、目標連接埠遭阻擋，或應用程式沒有使用核心 DNS。反過來，網頁能開啟也不代表所有 DNS 都依設定執行，應用程式自身的解析機制可能繞過本機代理。需要嚴格觀察時，應結合日誌中的目標形式、入站協定與應用程式代理方式。

快取、FakeDNS 與排錯界線

部分用戶端與核心情境會使用快取或 FakeDNS，讓透明接入時保留網域對映。FakeDNS 回傳的是內部對映位址，核心收到連線後再還原真實網域；如果該位址被其他應用程式、系統元件或不相符的入站處理，就可能出現看似異常的目標 IP。啟用前應確認目前接入方式確實需要，並確保相關位址範圍不與本地網路衝突。

排查 DNS 最有效的方法是逐層替換：先用一個明確可用的一般伺服器驗證基礎解析，再恢復網域分組，接著加入查詢策略與專用路由。每次只修改一個變數，並記錄目標網域、回傳位址與最終出站標籤。更完整的設定入口說明，可搭配站內V2Ray 使用流程的用戶端章節查看。

06 / POLICY

policy 策略：連線逾時、使用者等級與統計開關

策略物件的兩層結構

policy 用於集中設定連線生命週期與統計行為，常見結構包含 levels 與 system。levels 以使用者等級為鍵，每個等級下定義交握、連線閒置，以及上下行關閉後的等待時間等參數；system 則控制是否啟用入站與出站統計。多數個人用戶端不需要複雜的等級，但理解此結構有助於解釋為何某些連線閒置一段時間後會被釋放，或為何統計模組沒有產生資料。

等級編號不是速度優先級，也不會自動讓某個使用者取得更高頻寬。它只是把使用者或協定物件引用的 level 對應到一組策略。若設定中只有等級 0，所有使用預設等級的連線就會採用這組值。新增等級但沒有任何使用者引用，不會產生實際效果。將伺服器端風格的設定移轉到用戶端時，常見問題是保留複雜的等級表，卻刪除了原本引用它的使用者物件，留下難以理解的冗餘。

連線生命週期參數

handshake 通常控制連線建立階段允許等待的時間；connIdle 控制沒有資料活動的連線可維持多久；uplinkOnly 與 downlinkOnly 用於一側資料結束後繼續等待另一側的時間。具體單位與支援範圍應以目前核心的欄位定義為準。閒置時間過短可能讓長連線、訊息推播或下載控制連線頻繁重建；過長則會讓已失效的連線佔用資源更久。

逾時不是越長就越穩定。伺服器位址無法抵達時，過長的交握等待會讓故障回饋變慢；網路頻繁切換時，長時間保留舊連線也不會自動恢復。調整策略前先從日誌確認中斷原因：如果是遠端主動關閉，延長本地閒置時間沒有意義；如果應用程式本身定期重新連線，也不應把每次重連都歸因於核心策略。

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

統計開關不等於統計結果

策略中的統計欄位只是允許核心收集相應維度的資料，還需要 stats 頂層物件，以及可讀取統計資料的介面或用戶端功能配合。單獨將所有開關改為 true，介面不一定會自動顯示資料。反過來，用戶端為了顯示流量資訊而產生統計設定時，也可能附帶 API 入站或內部路由，不能只保留 policy 而刪除配套物件。

統計會增加一定的狀態維護工作，個人環境只應啟用真正需要的維度。例如只關心出站總量，就不必同時啟用每個使用者的上下行統計。設定稽核時應問清楚三個問題：需要觀察什麼維度、由哪個介面讀取、資料由哪個用戶端頁面顯示。如果無法回答，優先維持簡單設定，避免為了「欄位齊全」而加入沒有實際用途的模組。

用戶端產生策略的處理方式

v2rayN、v2rayNG 與 v2flyNG 可能依據流量統計、連線測試或本機管理功能寫入策略欄位。手動覆寫設定時，應先關閉相關用戶端功能或使用其支援的自訂入口，否則下次啟動可能重新產生。特別是桌面端同時執行系統代理、連線測試與統計顯示時，執行中的設定通常不等於訂閱中的單一節點連結。

策略排錯應避免與網路排錯混在一起。核心啟動失敗且明確指向 policy 欄位時，檢查型別、等級鍵與目前核心是否支援該欄位；連線能建立但過早中斷時，再比較閒置時間與應用程式行為；統計為空時，則檢查完整的資料採集鏈。分開處理這三類情況，才能判斷是設定結構問題、連線生命週期問題，還是用戶端顯示問題。

何時應維持預設值

一般瀏覽、命令列代理與日常訂閱使用，通常不需要手動調整 policy。預設值已考量通用情境，除非日誌與重現步驟能證明某個連線確實受到策略時間影響，否則不建議為了追求「更快」而修改。策略參數控制的是等待與狀態，不會提升遠端線路品質或伺服器吞吐量。

如果確實需要調整，應先記錄目前值與重現條件，每次只改變一個參數，並在相同應用程式、相同網路路徑下觀察結果。調整後連線問題沒有變化，就恢復預設值，繼續檢查出站與系統網路。設定大全的目的不是讓每個欄位都被修改，而是讓必要的修改都有明確依據。

07 / LOG & STATS

日誌、統計與執行設定：建立可觀察的排錯現場

log 欄位與日誌等級

log 決定核心輸出哪些執行資訊。常見等級會從詳細除錯資訊逐步收斂到警告與錯誤。日常使用可選擇 warning 類型的較簡潔等級，重現複雜問題時暫時提高詳細程度，確認問題後再恢復。長期維持最詳細的日誌會產生大量重複資訊，反而更難定位重要錯誤，也可能佔用額外磁碟空間。

日誌通常分為存取記錄與錯誤記錄。存取記錄回答「哪條連線進入、目標是什麼、選擇了哪個出口」，錯誤記錄回答「在哪個階段失敗以及失敗原因」。只看最後一行很容易誤判，因為最外層錯誤可能只是「連線結束」，真正原因藏在前幾行的 DNS、路由或交握資訊中。排錯時應保留從核心啟動到故障出現的完整時間段，並記錄觸發操作。

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "stats": {}
}

空路徑的具體處理方式與核心及用戶端啟動參數有關，圖形用戶端通常會接管日誌輸出並在介面中顯示。不要假設手動填入某個檔案路徑後，用戶端就一定會讀取該檔案。Windows、macOS、Android 與 Linux 的應用程式資料目錄及權限模型不同，應優先使用用戶端內建的日誌視窗或匯出功能。需要重新安裝用戶端時，可從安裝套件頁面依平台選擇對應版本。

讀取日誌的階段順序

啟動日誌先檢查設定解析。如果出現 JSON 字元位置、未知欄位或型別錯誤，核心尚未進入網路連線階段，此時修改節點位址沒有意義。設定載入成功後檢查入站監聽，確認連接埠與位址；接著觀察 DNS 與路由，確認目標已被辨識並命中預期出站；最後才查看遠端連線、TLS 或協定交握。沿著資料流閱讀日誌，可以將大量資訊歸入明確階段。

常見錯誤文字不應脫離上下文解讀。timeout 可能發生在 DNS、TCP 連線或交握階段；connection refused 可能來自本機連接埠、遠端連接埠或中間轉送；failed to find an available destination 可能與出站選擇、解析結果或策略有關。判斷依據應是錯誤前後的模組名稱、目標位址與標籤，而不是只搜尋一個英文短語。

執行設定與儲存設定

用戶端介面儲存的是節點、訂閱、路由模式與應用程式設定，真正交給核心的執行設定可能在啟動時動態合成。排錯時應查看執行設定，而不是只看訂閱連結中的節點欄位。用戶端可能新增本機入站、API、統計、DNS、直連與阻擋出站；系統代理設定也位於核心設定之外。執行設定正確但應用程式沒有流量進入時，就應檢查系統代理或應用程式代理，而不是繼續修改 JSON。

複製執行設定用於測試時，要注意其中的暫時連接埠、用戶端內部標籤與路徑。獨立啟動核心前，應將環境依賴替換為目前機器可用的設定。反過來，將手寫設定匯回用戶端也可能被用戶端重新整理。長期維護應選定一個主要來源：要麼以用戶端設定為主，透過受支援的自訂規則擴充；要麼以完整手寫設定為主，避免兩個來源輪流覆寫。

stats 與用戶端流量顯示

stats 頂層物件用於啟用統計模組，但實際指標還取決於 policy 中的開關。部分用戶端會透過內部 API 讀取入站、出站或使用者維度資料，並在介面中顯示。若刪除 API 物件或內部路由，統計可能停止，但代理連線仍然正常。這種「核心可用、介面資料為空」的情況，應與節點失效分開處理。

統計值適合觀察流量方向及連線是否經過某個入口，不適合當作線路品質評分。吞吐量受目標伺服器、網路路徑、並行連線與應用程式行為共同影響。設定頁不應為了看到更多數字就啟用所有統計維度。先確定排錯目標，例如驗證某個入站是否收到上行流量，再啟用對應維度，完成後恢復精簡設定。

建立最小重現案例

可靠的排錯記錄至少應包含：使用的用戶端名稱、作業系統平台、核心家族、觸發步驟、錯誤發生階段、相關標籤，以及經過刪減的設定結構。節點憑證與訂閱內容不應公開複製。可以保留協定類型、欄位層級與範例化位址，讓他人仍能判斷結構問題。

如果核心讀取設定後立即退出，進一步的日誌定位方法可查看透過日誌定位 config.json 設定錯誤。如果錯誤集中在 certificate invalid、serverName 或交握階段，則前往TLS 憑證錯誤排查清單，依系統時間、伺服器名稱與憑證鏈順序檢查。

08 / VALIDATION

完整設定組裝、驗證順序與故障分支

組裝一份易讀的基礎設定

完整設定應先確保標籤關係清楚，再追求規則數量。以下基礎結構包含本機 SOCKS 入站、代理出站、直連與阻擋出口、簡單 DNS 及路由。代理伺服器資訊仍是範例，不能直接用於連線；範例重點是展示各模組如何形成完整引用鏈。實際使用時，圖形用戶端通常會依訂閱自動填入代理出站，手動規則則較適合透過用戶端支援的設定入口合併。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "localhost"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300
      }
    }
  }
}

第一層：語法與結構驗證

設定無法啟動時，先檢查 JSON 是否完整。重點查看括號是否成對、陣列成員之間是否有逗號、字串是否使用雙引號，以及數字和布林值是否為正確型別。編輯器顯示的錯誤行有時只是解析器最終無法繼續的位置，真正缺少的逗號可能位於上一行。修正後再次讀取設定，直到不再出現 JSON 解析錯誤。

語法通過後進入欄位結構驗證。檢查欄位名稱、所屬層級與核心支援情況。若設定來自另一條核心版本線、舊教學或不同用戶端，某些欄位可能無法使用。Xray 與 V2Fly 具有共同基礎，也存在協定與功能差異，不能假設設定永遠可以原樣互換。需要了解兩條核心版本線與用戶端搭配方式，可閱讀Xray 與 V2Fly 核心關係及選擇建議。

第二層：標籤與監聽驗證

列出所有入站與出站標籤，再逐一檢查引用。每個 outboundTag 都應找到同名出站，每個 inboundTag 都應對應實際入口。標籤大小寫必須一致，重複標籤則會讓設定含義不清。接著確認每個入站都監聽成功、連接埠沒有衝突，且應用程式代理位址與協定類型完全一致。

如果應用程式無法存取，但核心完全沒有對應的連線日誌，應將注意力放在系統代理與應用程式設定。桌面環境中，系統代理可能只影響遵循系統設定的程式；終端工具、遊戲或獨立瀏覽器可能有自己的代理入口。Android 用戶端通常透過系統網路介面接管流量，排錯重點則是應用程式權限、目前設定與連線狀態。不同平台的入口可在安裝套件頁面查看。

第三層：DNS、路由與出站驗證

確認連線進入後，記錄日誌中的目標形式。如果是網域，檢查網域規則；如果已經是 IP，檢查 IP 規則與入站辨識。然後確認實際命中的出站標籤。命中錯誤表示需要調整規則順序、比對範圍或 DNS 解析結果；命中正確但連線失敗，則檢查該出站的伺服器解析、連接埠、協定與傳輸層。

可以暫時減少路由規則來判斷問題界線。先保留內網直連與一個明確的代理出口，確認基礎鏈路；再逐組恢復網域分類、阻擋規則與專用入站規則。DNS 也採用相同方法，從單一可用伺服器開始，再恢復網域分組與專用出口。一次恢復一組，才能準確找出引入故障的變更。

常見故障分支

修改後的回歸檢查

設定恢復可用後，不要只驗證一個網頁。至少檢查網域目標、直接 IP 目標、本地網路位址、需要直連的網站與需要代理的網站，確認規則邊界符合預期；若啟用 UDP，再用實際需要 UDP 的應用程式驗證。接著重新啟動用戶端，確認設定能穩定重新產生並載入，避免只有暫時的執行檔案有效。

訂閱更新後還應檢查自訂規則是否保留、目前節點是否仍對應到預期的代理標籤，以及用戶端是否切換了核心。v2rayN 適合 Windows、macOS 與 Linux 桌面環境，v2rayNG 使用 Xray 核心，v2flyNG 則是採用 V2Fly 核心的 Android 備選方案。三者介面不同，但排錯主線一致：逐層確認入口、辨識、路由、解析、出口與交握。

最後保留一份文字化的變更記錄，寫明修改原因、涉及模組與驗證結果。設定檔可以複製，但網路環境與用戶端產生邏輯會變化；只有知道某條規則解決什麼問題，後續才能判斷它是否仍有必要。快速操作請繼續查看使用文件，欄位名稱與協定概念請查閱術語表，涉及具體錯誤時再進入對應的部落格文章，避免將所有知識堆進一份難以維護的設定。