V2Ray 設定檔完整參考

JSON 結構總覽與處理流程

先了解資料如何通過設定

V2Ray 設定不是一組互相獨立的開關，而是一條有順序的處理鏈。應用程式流量先進入 inbounds，核心從入站連線取得目標位址、連接埠、網路類型與入站標籤；接著由 routing 按規則順序判斷應交給哪個出站；網域名稱在匹配或建立連線時，可能進入 dns 解析流程；最後由 outbounds 中選定的代理、直連或攔截出口處理。policy、log 與統計設定不會直接改變目的地，卻會影響連線生命週期、可觀測資訊與排錯效率。理解這條流程，比孤立記憶欄位更可靠。

頂層物件通常包含 log、dns、inbounds、outbounds、routing 與 policy。陣列中的每個入站與出站都應設定清楚的 tag，因為路由規則會透過標籤引用它們。標籤只是設定內部識別，不會自動建立網路連線，也不能與訂閱中的節點備註混為一談。常見錯誤是規則寫了 outboundTag: proxy，實際出站卻叫作 proxy-main；設定可能通過 JSON 語法檢查，但執行時無法依預期選路。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "security": "auto"
              }
            ]
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

物件、陣列與欄位類型

JSON 對格式要求非常嚴格：物件使用大括號，陣列使用方括號，鍵名與字串使用雙引號，布林值只能寫成 true 或 false，數字不能加引號。最後一個欄位後不能保留逗號，設定中也不應混入說明性註解。許多「核心啟動失敗」並非協定問題，而是複製片段後出現全形標點、彎引號、重複鍵或括號層級錯位。編輯時應維持 UTF-8 文字，先完成純 JSON 語法檢查，再確認欄位是否受目前核心支援。

支援的欄位範圍取決於核心家族。v2rayNG 通常搭配 Xray 核心，v2flyNG 對應 V2Fly 核心，v2rayN 則能管理不同類型的核心與設定。VMess、VLESS、傳輸層安全與路由欄位有許多共通之處，但 REALITY 等功能仍須依實際核心支援情況選擇。直接貼上另一核心專用的欄位，最常見的結果是「未知欄位」、出站初始化失敗，或用戶端儲存時捨棄該欄位。遷移設定時應先確認協定能力，再逐段移轉，不宜一次替換整份檔案。

圖形化用戶端與核心設定的界線

v2rayN、v2rayNG 與 v2flyNG 都會將介面設定、訂閱節點與路由選項轉換為核心設定。介面中的「系統代理」、「VPN 服務」、「略過區域網路」等選項，不一定對應同名 JSON 欄位；有些屬於作業系統接管層，有些才會寫入 routing.rules。因此排錯時要先判斷問題屬於哪一層：用戶端是否接管流量、產生的設定是否正確、核心是否成功啟動，以及目標連線是否命中預期出站。只查看訂閱節點狀態，往往會漏掉系統代理與路由層。

手動維護設定時，建議採用穩定的標籤命名，例如 socks-in、http-in、proxy、direct、block。名稱簡短且含義唯一，能降低後續規則拼寫錯誤。複雜設定還應記錄每個出站的職責，而不是把節點備註當作永久識別。用戶端更新訂閱後，節點名稱可能改變；職責型標籤則應保持穩定，讓路由規則只依賴「代理、直連、攔截」這些邏輯出口。

inbounds 入站：流量從哪裡進入

監聽位址、連接埠與公開範圍

inbounds 定義本機應用程式如何將流量交給核心。桌面用戶端常見 SOCKS 與 HTTP 入站，行動裝置用戶端還會透過系統網路介面接管應用程式流量。手動設定時首先要確認 listen 與 port：監聽 127.0.0.1 代表只接受本機連線，適合瀏覽器、終端機或系統代理使用；監聽所有網路介面會擴大可存取範圍，必須同時評估區域網路環境、驗證方式與系統防火牆。除非明確需要讓其他裝置連線，通常維持本機監聽更容易控管。

連接埠必須未被其他程式佔用，而且不同入站不能重複監聽相同的位址與連接埠組合。v2rayN 介面中的本機連接埠通常由用戶端管理；手動修改設定後，若介面仍保存舊連接埠，系統代理可能繼續指向舊值，呈現「核心正在執行但網頁無法連線」。此時應同時核對核心日誌中的監聽資訊、用戶端顯示的本機連接埠與作業系統代理設定，三者必須一致。

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

SOCKS、HTTP 與透明接管

SOCKS 入站適合支援 SOCKS5 的應用程式，也可透過 udp: true 接收 UDP 請求。HTTP 入站主要處理 HTTP 代理與 CONNECT 通道，能相容大量桌面軟體。兩者都要求應用程式或系統代理明確指向對應連接埠。透明接管則不同：流量可能由作業系統路由、虛擬網路介面或轉送規則送入核心，目標位址的還原方式更複雜。圖形化用戶端通常會管理這些平台差異，不建議在不了解系統轉送流程時，直接將桌面 SOCKS 範例改成透明入站。

settings 的內容取決於入站協定。SOCKS 的 auth、udp 與 HTTP 入站的帳戶欄位不能互相套用。若監聽範圍只限本機，noauth 是常見設定；若要提供給區域網路裝置使用，應先在用戶端啟用對應的共享功能，並設定存取控制。不要只靠放寬監聽位址來完成共享，因為系統防火牆、網路類型與驗證仍會影響實際公開範圍。

流量嗅探與 routeOnly

sniffing 用於從 HTTP 請求或 TLS 握手中辨識網域名稱，讓網域規則在原始目標只有 IP 位址時仍有機會匹配。destOverride 指定可辨識的協定類型，routeOnly 表示嗅探結果主要用於路由判斷，而不是直接改寫最終連線目標。啟用嗅探不代表所有連線都能取得網域名稱：加密的用戶端問候、非標準協定、已建立的連線，以及不含主機資訊的流量，仍可能只能看到 IP。

啟用嗅探後若部分網站連線異常，可沿兩條路徑排查。第一，暫時關閉嗅探，確認問題是否來自網域辨識或目標改寫；第二，保留嗅探但使用 routeOnly，讓網域只參與規則匹配。若規則主要依據 IP，嗅探效益有限；若設定大量使用 domain、geosite 或尾碼規則，嗅探通常更有價值。最終選擇應由規則設計決定，而不是把它視為固定的效能開關。

outbounds 出站：代理、直連與攔截

出站職責與選擇順序

outbounds 定義核心可使用的出口。常見設定至少包含代理出站、freedom 直連出站與 blackhole 攔截出站。路由規則透過 outboundTag 選擇其中一個；未命中規則時，核心通常會使用出站陣列中的第一個可用項目，因此陣列順序也具有實際意義。若希望預設使用代理，應將代理出口放在前面；若希望預設直連，則應明確調整順序並補上需要代理的規則，不能只修改標籤名稱。

一個出站由協定層、伺服器帳戶、傳輸方式與安全層共同組成。以 VMess 或 VLESS 為例，settings 描述伺服器位址、連接埠與使用者資訊，streamSettings 描述 TCP、WebSocket、gRPC 等傳輸，以及 TLS 或 REALITY 等安全方式。四個部分必須逐項對應伺服器端參數。位址正確但傳輸方式不同，或連接埠正確但安全層名稱不同，都會導致握手失敗。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "edge.example.com",
            "port": 443,
            "users": [
              {
                "id": "22222222-2222-4222-8222-222222222222",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "edge.example.com",
          "allowInsecure": false
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

伺服器位址、使用者與傳輸層

address 可以是網域名稱或 IP，port 必須是數字。使用網域名稱時，核心需要先完成解析，因此 DNS 設定會間接影響代理出站建立。使用者識別、加密設定與 flow 等欄位依協定而異，不應將 VMess 使用者物件直接改名後當作 VLESS 設定。分享連結或訂閱已包含這些參數時，優先讓用戶端解析；手動輸入適合核對欄位，但要避免漏掉路徑、主機名稱、服務名稱或伺服器名稱。

streamSettings.network 表示底層傳輸。選擇 WebSocket 時通常還需要路徑與請求標頭中的主機名稱；選擇 gRPC 時需要服務名稱；選擇 TCP 時也可能設定特定標頭或安全層。傳輸名稱相同不代表其他參數可以省略。排錯時應將「協定帳戶」與「傳輸握手」分開：帳戶錯誤常在協定驗證階段失敗，傳輸參數錯誤則較早表現為連線關閉、TLS 名稱不匹配或服務路徑無法存取。

TLS、REALITY 與核心差異

TLS 設定中的 serverName 用於伺服器名稱驗證與握手，應依節點提供的資訊填寫，不能簡單視為連線位址。allowInsecure 控制憑證驗證，常規設定應維持 false。若節點依賴 REALITY，需確認用戶端目前使用的是支援該功能的 Xray 核心，並完整填入節點提供的伺服器名稱、公鑰、短識別碼與指紋等欄位。v2flyNG 使用 V2Fly 核心，選擇用戶端時應先依節點協定確認相容範圍，而不是只比較介面。

v2rayN 可管理桌面端節點與不同核心設定，適用於 Windows、macOS 與 Linux。v2rayNG 面向 Android，主要依 Xray 協定能力作為選擇依據；v2flyNG 則是 V2Fly 核心路線的替代選擇。三者都屬於設定管理層，節點能否連線仍取決於協定參數、核心支援與網路路徑。需要安裝對應用戶端時，可在用戶端下載頁依平台選擇。

直連、攔截與鏈式出口

freedom 表示由本機網路直接建立目標連線，適合區域網路、裝置位址或明確需要本地出口的網域。blackhole 用於終止命中規則的連線。攔截規則應放在足夠前面的位置，並盡量縮小匹配範圍，避免一併攔截更新服務、登入介面或區域網路裝置。若日誌只顯示連線已關閉，應先檢查目標是否誤命中 block，不要立即更換代理節點。

複雜設定可能透過 proxySettings 或其他機制，將一個出站轉交給另一個出站，形成前置代理或鏈式出口。鏈路越長，排錯成本越高：任何一層的 DNS、傳輸或驗證失敗，都會導致最終連線中斷。建立鏈式設定前，應先分別驗證每個單獨出口都能運作，再逐層串接；同時確保中間出站標籤唯一，避免規則直接選到只供鏈路內部使用的出口。

routing 路由：規則順序與匹配範圍

由上到下，命中即停止

routing.rules 是分流設定的核心。規則依陣列順序由上到下檢查，連線命中後通常不會繼續評估後續規則。因此，具體規則應放在通用規則之前：區域網路直連可早於大範圍代理規則，明確的攔截項應早於寬泛的網域尾碼，兜底策略則由最後一條規則或預設出站負責。許多分流故障不是匹配條件寫錯，而是前面已有更寬泛的規則提前攔截流量。

規則可以依網域、IP、連接埠、網路類型、入站標籤、協定辨識結果或使用者識別進行匹配。一條規則同時出現多種類型的條件時，通常需要這些條件共同成立；同一欄位陣列中的多個值，通常表示命中任一值即可。設計規則前，應先釐清自然語言需求，例如「從 SOCKS 入站進入、目標連接埠為 53 的 UDP 流量走 DNS 出站」，其中包含入站標籤、連接埠與網路三類條件，缺少任一項都可能擴大範圍。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.internal",
          "full:router.example.internal"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

網域規則的四種常見寫法

full: 用於完整網域匹配，只命中完全相同的主機名稱；domain: 通常涵蓋指定網域及其子網域；regexp: 使用正規表示式，彈性高但更容易擴大範圍；geosite: 引用核心可用的分類資料。不加前綴的寫法在不同設定情境中可能有特定含義，為便於維護，建議明確寫出匹配類型。排查網域規則時，應記錄實際存取的主機名稱，而不是只看網頁標題或產品名稱。

正規表示式規則需要同時考慮跳脫層。正規表示式本身使用反斜線，放入 JSON 字串後還需要進行 JSON 跳脫，肉眼檢查很容易遺漏。能用 full: 與 domain: 表達的需求，不必優先使用正規表示式。分類資料也不是即時網路狀態，而是一組隨資料檔更新的網域或位址集合；命中結果取決於目前核心載入的資料內容。

IP、連接埠、網路與入站標籤

IP 規則可以寫單一位址、CIDR 網段或 geoip: 分類。geoip:private 常用於讓區域網路與保留位址直連，但仍需依實際網路環境檢查。若公司或家庭網路使用特殊位址範圍，應明確補上對應網段。連接埠可以寫單一值或範圍，網路類型則常見 tcp、udp 或兩者組合。限制條件越明確，規則對其他流量的副作用越小。

inboundTag 能讓相同目標在不同入口採用不同策略。例如瀏覽器透過 socks-in 進入時走代理，某個本機服務透過另一個入站進入時維持直連。這比複製兩套核心實例更容易維護。前提是入站標籤確實存在且拼寫一致。標籤比較通常區分字元，額外空格、大小寫變化與用戶端重新產生設定，都可能使規則失效。

domainStrategy 如何觸發解析

AsIs 優先使用連線中已有的網域名稱進行路由，不會為了 IP 規則主動解析網域；IPIfNonMatch 表示網域規則未命中時，再解析為 IP 嘗試匹配 IP 規則；IPOnDemand 則會在需要 IP 條件時更積極觸發解析。策略越積極，IP 分流能力越強，但對 DNS 的依賴也越深。若 DNS 伺服器無法連線或回傳結果不符預期，路由階段可能出現延遲與誤判。

選擇策略要與規則集配套。以網域規則為主、IP 規則只處理直接提供的位址時，AsIs 更直觀；需要讓網域最終匹配地區 IP 分類時，可考慮 IPIfNonMatch。修改後應分別測試網域目標與直接 IP 目標，並在日誌中確認實際選用的出站。關於連線成功後仍無法存取的系統化排查，也可參考DNS、路由規則與系統代理逐項排查清單。

DNS 設定：解析路徑與分流一致性

內建 DNS 與系統 DNS 的職責

dns 模組為核心內部的網域解析提供規則與伺服器選擇，主要服務於路由判斷、代理伺服器網域解析，以及由核心接管的請求。它不一定會取代作業系統的全部 DNS 行為：若應用程式自行發起加密 DNS、瀏覽器繞過系統設定，或流量未進入核心，對應查詢可能不會經過此處。排錯時應先確認「是誰發起解析」，再檢查 V2Ray 的 DNS 設定，不能將所有網域問題都歸咎於同一個模組。

servers 可以包含一般位址、localhost，或帶有匹配網域的伺服器物件。簡單清單會依設定策略選擇解析器；伺服器物件則能讓特定網域交由指定的解析服務處理。若解析伺服器本身使用網域名稱，核心還需要先解析該伺服器位址，容易形成額外依賴。基礎解析伺服器最好使用明確可達的位址，並確認其連線應走直連還是代理。

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableCache": false,
    "disableFallback": false,
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      {
        "address": "8.8.8.8",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "hosts": {
      "router.example.internal": "192.168.1.1"
    }
  }
}

hosts、快取與查詢策略

hosts 提供靜態網域對映，適合固定的區域網路服務或測試環境。它的優先順序通常高於外部查詢，因此舊對映會長期覆蓋真實解析結果。修改伺服器位址後若仍連線到舊 IP，應先檢查 hosts，再檢查 DNS 快取。靜態對映只應放入確實穩定的目標，並在網路調整後同步更新。

disableCache 控制核心 DNS 快取。保留快取可減少重複查詢與連線等待；排查解析變化時可以暫時關閉，但長期關閉會增加查詢量。queryStrategy 決定優先請求哪些位址族，常見選項包括使用 IP、僅使用 IPv4 或僅使用 IPv6，具體名稱與支援範圍應以目前核心為準。若本地網路沒有穩定的 IPv6 路徑，卻取得 IPv6 位址並優先連線，可能出現網域能解析但連線逾時的情況。

依網域指定解析器

伺服器物件中的 domains 用於限定該解析器負責的網域。匹配語法與路由網域規則相近，可以使用完整網域、尾碼或分類資料。skipFallback 表示匹配到該伺服器的網域不再進入一般回退流程，適合必須使用特定解析器的內部網域；設定過寬則會讓目標在該伺服器失敗後失去其他解析路徑。

disableFallback 會整體改變回退行為，不適合在尚未理解伺服器匹配順序時直接啟用。較穩妥的做法是先保留回退，透過日誌觀察特定網域選中了哪台伺服器，再針對少量確定目標加入 skipFallback。DNS 分流與路由分流應保持一致：若某類網域的解析請求走代理，但解析得到的目標連線卻被規則送往直連，可能出現出口視角不一致。反過來也一樣，解析與連線路徑分裂會增加定位難度。

代理伺服器網域的啟動依賴

代理出站的 address 若填寫網域名稱，核心必須在建立代理連線前解析它。此時尚未有可用的代理通道，若解析器本身必須透過代理才能存取，就可能形成啟動閉環。處理方式不是盲目更換節點，而是確保至少有一條基礎 DNS 路徑能在代理建立前運作，並讓代理伺服器網域的解析經由這條路徑。設定複雜 DNS 出站時尤其要注意這一點。

要判斷 DNS 是否為根因，可以分四步縮小範圍：先用固定 IP 目標驗證出站鏈路；再檢查節點伺服器網域能否解析；接著檢查目標網域的 A 與 AAAA 結果；最後觀察路由是否因解析結果改變了出站。若固定 IP 同樣失敗，問題通常不只在 DNS。若節點能連線但部分網域失敗，則繼續檢查網域匹配、快取與位址族選擇。

policy 策略：連線生命週期與統計開關

系統策略與使用者等級

policy 用於控制連線逾時、握手時間、上下行閒置判斷與統計開關。它不決定流量要走哪個節點，也不會取代路由規則。設定通常分為 levels 與 system：levels 依使用者等級套用連線策略，協定使用者物件中的 level 會對應這裡的鍵；system 則控制全域統計維度。若使用者沒有明確設定等級，通常會套用預設等級策略。

等級鍵在 JSON 中以字串形式出現，例如 "0"。不同協定引用使用者等級的方式可能不同，用戶端自動產生設定時也可能省略未使用的策略。手動新增等級前，應先確認對應的入站或使用者物件確實引用了它。只建立 "1" 策略，卻沒有任何使用者設定 level: 1，不會自動提升所有連線。

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

handshake 與 connIdle

handshake 限制建立連線階段可等待的時間，單位通常為秒。數值過小會讓高延遲網路、首次 DNS 查詢或複雜握手在完成前被中止；數值過大則會讓明顯失敗的連線佔用更久。調整時應先區分「建立連線很慢」與「建立後傳輸很慢」，前者才直接與握手等待有關。若日誌顯示出站已建立，繼續增加握手時間通常沒有幫助。

connIdle 控制連線在沒有資料活動時可維持多久。即時通訊、長輪詢、遠端終端機與背景同步可能長時間沒有明顯流量，閒置時間過短會造成週期性斷線；一般網頁連線通常能接受較短的閒置回收。修改此值前，先觀察問題是否總是在固定閒置時間後發生。若連線在持續傳輸時也中斷，應繼續檢查網路路徑、伺服器限制與傳輸層，而不只是調整策略。

uplinkOnly、downlinkOnly 與緩衝

uplinkOnly 與 downlinkOnly 用於半關閉狀態下的連線回收。當一側資料方向結束後，核心仍可等待另一方向完成剩餘傳輸。等待過短可能截斷回應尾端，過長則會讓已結束的連線保留更久。這類參數通常維持合理的預設值即可，只有當日誌與擷取現象明確指向半關閉階段時才需要調整。

bufferSize 會影響每條連線的緩衝策略，含義與單位可能隨核心實作而異。更大的緩衝不等於更快的速度，在大量並行連線下還會增加記憶體使用量。效能調校應先確認瓶頸來自 CPU、網路、協定握手還是應用程式讀取速度，再決定是否調整緩衝。沒有測量依據時，維持用戶端或核心的預設設定更穩定。

如何啟用統計資料

system 下的統計開關決定是否記錄入站與出站的上下行資料，通常也需要頂層存在 stats 物件。使用者層級統計還要在對應等級中啟用 statsUserUplink 與 statsUserDownlink。只寫 stats: {} 不會自動產生所有維度；只開啟策略開關但沒有讀取統計資料的介面，也不會在用戶端介面憑空出現圖表。

統計會增加一定的狀態維護成本，是否啟用應由實際觀測需求決定。排查分流時，出站統計有助於判斷流量是否進入代理、直連或攔截出口；排查個別使用者時，使用者層級統計才有意義。個人桌面設定通常只需要出站維度，不必同時開啟所有使用者統計。若圖形化用戶端已提供流量顯示，應以其產生設定與讀取機制為準，避免重複設定多個統計入口。

調整策略後的驗證應涵蓋三類連線：快速短連線、持續傳輸連線，以及長時間閒置後恢復的連線。只開啟一個網頁無法判斷閒置回收是否合理，也無法驗證半關閉等待。若用戶端每次儲存節點都會重新產生設定，手動策略可能被覆蓋；應將可用選項寫入用戶端的自訂設定功能，或在每次更新訂閱後重新核對產生結果。

日誌、統計與執行狀態

日誌層級與檔案輸出

log 是設定排錯的第一個入口。常見層級由詳細到簡略包括 debug、info、warning、error 與 none，具體名稱以目前核心支援為準。日常執行使用 warning 通常能保留關鍵異常，同時減少重複資訊；定位規則或握手問題時，可暫時提高至 info 或 debug。問題重現完成後應恢復常用層級，避免大量日誌佔用磁碟並干擾後續搜尋。

access 與 error 可指定存取日誌與錯誤日誌路徑。使用相對路徑時，其基準目錄取決於核心啟動位置，圖形化用戶端、終端機與系統服務可能各不相同。若設定顯示已寫入檔案但實際找不到，應先檢查程序工作目錄與檔案權限。路徑所在目錄必須已存在，且目前使用者要有寫入權限；不要將日誌路徑指向安裝套件內部或臨時解壓縮目錄。

{
  "log": {
    "access": "./logs/access.log",
    "error": "./logs/error.log",
    "loglevel": "warning",
    "dnsLog": false
  },
  "stats": {}
}

如何閱讀一筆連線紀錄

閱讀日誌時，應依時間將同一條連線的幾個階段串起來：入站接受連線、辨識目標、路由命中、選擇出站、解析伺服器位址、建立傳輸、協定握手與關閉原因。單獨看到「connection closed」並不能判斷是節點失效、目標主動關閉，還是路由攔截。需要結合同一時間附近的目標位址、入站標籤與出站標籤，確認關閉發生在哪一層。

若日誌只有入站紀錄而沒有出站選擇，應優先檢查路由規則與設定載入；有出站選擇但伺服器位址解析失敗，則轉向 DNS；遠端 TCP 已建立但協定握手失敗，核對使用者、傳輸與安全參數；握手成功後特定目標失敗，則繼續檢查目標路由、位址族與應用程式行為。依階段定位能避免在多個模組之間反覆試錯。

存取日誌與錯誤日誌的分工

存取日誌更適合回答「哪個目標透過哪個入口被處理」，錯誤日誌則更適合回答「處理為何中斷」。驗證路由時，可以選擇一個容易辨識的測試網域，清除舊日誌後只發起一次請求，再查看新紀錄。並行開啟大量網頁會產生背景請求、更新檢查與媒體連線，目標混在一起後，很難判斷某條規則是否準確命中。

日誌中的網域與 IP 可能來自不同階段。嗅探辨識出的網域用於規則匹配，DNS 回傳的 IP 用於建立連線，最終存取日誌顯示哪一種，取決於核心與日誌位置。看到 IP 不代表網域規則一定沒有執行，看到網域也不代表連線沒有經過解析。需要結合 domainStrategy、嗅探設定與路由日誌共同判斷。

統計、API 與用戶端介面

統計模組負責記錄計數，API 或用戶端介面負責讀取與顯示。若使用核心 API，通常還需要專用入站、服務標籤與路由規則，將 API 流量送往對應出站。這種結構具有較明顯的核心差異與用戶端管理界線，手動新增前應先確認用戶端是否已建立同名標籤。API 入站連接埠重複會導致啟動失敗，路由標籤重複則可能讓狀態查詢進入一般代理出口。

v2rayN 等圖形化用戶端通常已提供執行日誌、核心日誌與連線狀態入口。排錯時優先使用用戶端顯示的實際啟動設定與錯誤資訊，因為介面設定可能會在啟動前轉換欄位。手動編輯一份獨立 JSON，但用戶端實際載入的是另一份臨時設定，是常見的資訊錯位。確認設定來源的方法，是查看啟動日誌中的設定路徑、監聽連接埠與出站標籤，再與正在編輯的檔案逐項比對。

日誌中的隱私與保存

存取日誌可能包含網域、目標位址、本機帳戶識別與連線時間。啟用詳細層級前，應確認日誌保存位置與使用範圍；排錯完成後及時降低層級，並清理不再需要的除錯檔案。分享錯誤片段時，只保留與故障直接相關的階段，並替換節點位址、使用者識別、路徑與帳戶欄位。只刪除一行伺服器位址並不足夠，因為相鄰的握手資訊也可能暴露設定細節。

日誌分析的目標是建立可重複的因果鏈，而不是收集越多內容越好。一次只重現一個問題，記錄修改前後的差異，保留明確的時間點與測試目標。若同時更換節點、修改 DNS、調整路由與切換系統代理，即使問題消失，也無法確定哪項改動有效。穩定的排錯紀錄應包含目前用戶端、使用的核心家族、入站方式、命中的出站與最終錯誤階段。

設定驗證、遷移與故障排查

先通過三層檢查

設定驗證應分為三層。第一層是 JSON 語法：括號、逗號、引號與欄位類型必須正確。第二層是設定語義：協定欄位是否被目前核心辨識、標籤引用是否存在、連接埠是否衝突。第三層是執行流程：入站是否收到流量、路由是否命中、出站是否建立、目標是否回應。三層不能互相取代；JSON 能被解析，只代表文字結構成立，不能證明節點參數與路由結果正確。

部分核心提供設定測試模式，可在不長期執行服務的情況下讀取設定並回傳錯誤。命令形式會隨核心與封裝方式改變，應以用戶端隨附核心的說明資訊為準。桌面用戶端較穩妥的做法，是先使用介面中的檢查、重新啟動核心或查看啟動日誌功能。測試時確認命令呼叫的是用戶端實際使用的核心檔案，系統路徑中的另一份核心可能支援不同欄位。

v2ray run -test -config ./config.json
xray run -test -config ./config.json

若命令提示不支援該參數形式，先執行對應程式的說明命令查看本機語法，不要據此判斷設定內容錯誤。驗證成功後再啟動核心，並檢查日誌中是否出現預期的監聽連接埠。若連接埠沒有出現，表示執行設定、權限或連接埠佔用仍有問題；若連接埠出現但應用程式沒有流量進入，則應回到系統代理或應用程式代理設定。

依模組進行二分排查

面對複雜設定，最快的方法不是逐字閱讀全部欄位，而是縮減至最小可執行鏈路。保留一個本機 SOCKS 入站、一個參數完整且已知可用的代理出站、一個直連出站，以及空的路由規則。先確認代理出口可以連線，再加入私有位址直連，接著加入網域分類、DNS 分流與攔截規則。每增加一層都保留可回退的設定副本；某一步出現故障時，範圍就會限定在剛加入的模組。

若節點顯示連線成功但網頁無法開啟，依「應用程式接管、入站監聽、節點連線、DNS、路由、系統代理」的順序檢查。用戶端狀態只代表某個程序已啟動或某次測試已完成，不代表目前瀏覽器流量確實進入該入站。最直接的判斷方式，是查看存取日誌中是否出現測試目標；沒有紀錄就先處理流量入口，有紀錄再分析出站。

訂閱更新後的設定變化

訂閱更新會重新整理節點清單與部分節點參數，用戶端也可能依目前路由模式重新產生執行設定。手動修改暫存檔通常無法長期保留。需要持久化的路由規則，應寫入用戶端提供的自訂規則、預設設定或支援的範本位置。更新後應重點核對節點協定、傳輸方式、伺服器名稱、出站標籤與規則順序，尤其是從不同核心來源匯入節點時。

單一 vmess:// 或 vless:// 分享連結通常代表一個節點，訂閱網址則會回傳可更新的節點清單。兩者在用戶端中的匯入入口與更新行為不同。相關差異可閱讀分享連結與訂閱網址的使用說明；若更新後沒有節點或回傳錯誤，可繼續參考訂閱更新失敗排查與自動更新設定。

跨核心遷移檢查表

從 V2Fly 設定遷移至 Xray，或反向遷移時，應先保留兩者都支援的基礎結構：SOCKS 入站、一般直連出口、簡單的網域與 IP 路由。接著依協定逐項確認使用者欄位、傳輸層、安全層與流控設定。遇到未知欄位時，不應直接刪除整段安全設定後繼續連線，因為該欄位可能是節點正常運作的必要條件。正確做法是確認目標核心能否表達相同的協定能力；若無法表達，就選擇與該節點匹配的用戶端與核心。

REALITY 節點通常應使用支援對應功能的 Xray 核心路線，Android 可優先考慮 v2rayNG；使用 V2Fly 設定與節點時，可依需求選擇 v2flyNG。桌面端首選 v2rayN，並在核心設定中確認實際啟用的核心。更完整的生態與核心關係可查看Project V、V2Fly、Xray 與用戶端關係整理以及Xray 與 V2Fly 核心選擇參考。

建立可維護的設定基線

一份可長期維護的設定，應包含明確標籤、有限的規則層級、可解釋的 DNS 路徑與適量日誌。每次修改都記錄目的，而不只是欄位值；例如「讓區域網路網段直連」比「新增 geoip 項目」更容易在日後判斷是否仍有需要。規則應依攔截、特殊直連、特殊代理與兜底的邏輯分組，組內則由具體到寬泛排列。

完成修改後，至少驗證本機位址、一般網域、直接 IP、TCP 請求，以及需要 UDP 的應用情境。接著重新啟動用戶端一次，確認設定不是只在目前程序中暫時生效。若依賴訂閱，還應執行一次更新並檢查自訂規則是否保留。快速使用流程可回到v2rayN 與 v2rayNG 設定教學；需要重新選擇安裝套件時，請前往V2Ray 用戶端下載頁。