V2Ray 設定檔結構與參數說明

01 / JSON STRUCTURE

設定檔結構總覽

先依流量方向理解頂層物件

V2Ray 與 Xray 的設定檔通常是一個 JSON 物件。首先要記住的不是欄位數量，而是流量方向：應用程式先連線到本機的入站監聽，核心讀取路由規則、選擇一個出站，再透過目標出站建立連線。DNS 負責將網域解析為位址，policy 負責工作階段逾時、統計等執行策略，log 則決定記錄位置與紀錄等級。

inbounds 和 outbounds 都是陣列，因為同一個執行個體可以同時監聽多個本機連接埠，也可以準備多個出口。陣列中的每個物件通常使用 tag 命名，路由規則再透過標籤引用。標籤只是執行個體內部的識別名稱，不會傳送給遠端；名稱可自行決定，但應保持簡短、穩定且能看出用途，例如 socks-in、proxy、direct 和 block。

一個便於閱讀的設定順序是：先寫入日誌，再寫 DNS，接著是入站、出站、路由與策略。JSON 本身不要求這個順序，但固定排列能縮短排查時間。遇到啟動失敗時，可以從檔案開頭往下檢查；比較兩份設定時，也更容易找出變更。圖形用戶端產生的順序可能不同，只要層級與欄位有效，執行結果不會因物件鍵的排列順序而改變。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {},
  "inbounds": [],
  "outbounds": [],
  "routing": {},
  "policy": {}
}

JSON 語法與設定語意是兩層檢查

設定能被 JSON 解析，只代表括號、引號、逗號與資料型別符合語法，不表示目前核心會接受所有欄位。例如連接埠寫成字串，可能是合法 JSON，卻不符合該欄位需要整數的要求；出站標籤拼寫不一致，也可能直到套用路由時才暴露問題。排查時要分兩步：先確認 JSON 可以解析，再查看核心日誌中關於未知欄位、型別錯誤、標籤缺失或協定設定不完整的提示。

標準 JSON 不允許註解，也不允許在物件或陣列最後一項後保留多餘逗號。複製範例時尤其要注意這一點。文件為了說明經常展示片段，但片段本身只有放入正確的父層物件才有效。例如單獨複製 routing 物件時，必須將它作為頂層的 "routing" 值，而不是直接貼到檔案末尾。字串必須使用雙引號，布林值使用 true 或 false，不能加上引號。

修改前建立可回復的基準

開始調整前，先讓目前設定在不修改的情況下成功啟動一次，並記下正在使用的本機連接埠、系統代理模式與核心名稱。接著複製設定檔，為副本加上用途明確的檔名。每次只修改一個邏輯單元，例如先增加直連出站，驗證後再加入路由規則。一次改動多個區域雖然較快，但啟動失敗時很難判斷是語法、標籤還是協定參數造成的。

圖形用戶端可能在更新訂閱、切換節點或重新啟動核心時重新產生執行設定。此時直接編輯暫存檔，變更可能無法長期保留。v2rayN 中應優先使用用戶端提供的自訂設定、路由設定或進階選項；Android 用戶端則先確認目前設定來自訂閱節點還是手動設定。想了解某個術語的界線，可同時查看術語表，避免將「入站」、「系統代理」與「路由模式」理解成同一項功能。

03 / OUTBOUNDS

outbounds 出站設定

代理、直連與阻擋組成基礎出口

出站定義核心要將流量送往何處。完整設定通常至少包含代理出口與直連出口，需要明確拒絕某類連線時再增加阻擋出口。代理出口保存伺服器位址、連接埠、使用者識別碼、加密或傳輸設定；直連出口讓核心直接存取目標；阻擋出口則主動終止符合規則的連線。routing 不負責建立連線，只負責將目前請求交給某個出站標籤。

出站陣列的順序值得留意。當某條連線沒有命中任何路由規則時，常見實作會使用第一個出站作為預設出口。因此，將代理放在第一項，還是將直連放在第一項，會直接影響未命中流量的去向。不要只依賴預設順序表達重要策略，關鍵流量應明確寫出規則；同時仍要讓第一項符合整體預期，避免新增網域或遺漏條件時產生意外結果。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-4333-8444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

協定身分參數與傳輸參數要分開檢視

排查代理出站時，先將欄位分成兩組。第一組是協定身分參數，例如伺服器位址、連接埠、使用者 ID 與協定要求的附加設定；第二組是 streamSettings 中的傳輸參數，例如 TCP、WebSocket、gRPC、TLS 或 REALITY。兩組參數各自正確但組合關係不一致，連線仍然無法建立。例如遠端使用 WebSocket，而本機設定成 TCP；伺服器憑證對應的名稱與 serverName 不同；使用者識別碼正確，但連接埠指向另一項服務。

訂閱匯入的價值之一，就是將服務提供者給出的協定、傳輸、安全層與主機參數一併寫入用戶端。手動遷移時不要只複製位址與連接埠。看到「節點能測試但網頁打不開」時，也不要立即認定出站身分參數全部正確：用戶端測試方法可能只涵蓋部分鏈路，實際應用還會涉及 DNS、UDP、路由與系統代理。應結合執行日誌判斷失敗發生在解析、連線至遠端、握手還是存取目標階段。

直連出口同樣會受到 DNS 與網路環境影響

freedom 表示由目前裝置直接建立目標連線。它不是繞過整個設定流程，而是仍經過入站與 routing 後，由核心執行直連。直連失敗時要檢查本機網路、系統 DNS、目標位址以及出站的網域策略。若規則依網域選擇 direct，但目標在建立連線前需要解析，解析結果與位址族會影響後續行為。某些環境中 IPv6 記錄存在但實際連線條件不完整，也可能表現為等待較久後逾時。

可以為 freedom 出站設定適當的網域解析策略，但不同核心支援的值與行為可能有差異。沒有明確需求時，先保留用戶端產生的預設值。除錯過程中若想判斷問題是否來自分流，可以暫時建立一條範圍很小、目標明確的規則送往 direct，而不是刪除全部規則。驗證完成後再復原，避免臨時測試改變其他應用程式的流量路徑。

代理鏈與多出口應從簡單結構開始

一個設定可以包含多個代理出站，並透過路由標籤選擇，也可以讓一個出口經由另一個出口建立底層連線。這種結構適合有明確鏈路需求的環境，但標籤依賴會迅速增加。開始設定前先畫出「入站 → 路由 → 第一出口 → 底層出口」的順序，確保不存在互相引用。若 proxy-a 依賴 proxy-b，而 proxy-b 又回到 proxy-a，核心便無法得到有效鏈路。

多節點選擇通常由 v2rayN、v2rayNG 或 v2flyNG 的設定管理功能完成。用戶端切換節點時，會調整目前使用的出站或重新產生執行設定。直接在產生檔案中塞入大量伺服器物件，不一定能配合用戶端的切換邏輯。桌面環境優先讓 v2rayN 管理節點，只將穩定的自訂路由與 DNS 需求放到用戶端支援的擴充位置，這比長期手動維護整份節點清單更容易復原。

05 / DNS

dns 解析設定

先分清系統解析與核心解析

DNS 設定容易出錯，是因為一台裝置上可能同時存在多條解析路徑。應用程式可以先呼叫系統 DNS 取得 IP，再將 IP 交給代理；核心也可以為了路由判斷主動解析網域；TUN 情境還可能由用戶端接管系統查詢。設定檔中的 dns 主要定義核心自身如何解析，並不會自動確保所有應用程式查詢都經過這裡。判斷問題前，先確認日誌中進入核心的是網域還是已解析好的 IP。

如果應用程式將網域直接交給 SOCKS 或 HTTP 代理，核心有機會依自己的 DNS 設定處理。若應用程式先在本地解析，routing 看到的可能只有位址，此時 DNS 設定對該次原始查詢不一定生效。sniffing 可以從部分連線中還原網域，但不能取代完整的查詢接管。因此，「已經寫了 dns 物件」與「所有程式都使用該 DNS」並不是同一回事。

{
  "dns": {
    "hosts": {
      "router.home.arpa": "192.168.1.1"
    },
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

servers 陣列既有順序，也可以附帶條件

servers 可以包含簡單位址，也可以使用物件為某個伺服器附加網域條件、預期位址範圍或回退行為。簡單設定從一至兩個穩定的解析來源開始即可。伺服器越多，不代表解析越可靠；如果各伺服器的使用條件不清楚，失敗時很難判斷查詢實際送往何處。物件中的 domains 用來讓指定網域優先交給該伺服器，適合內部網域或有明確解析來源的服務。

skipFallback 的用途，是控制符合目前伺服器條件的查詢是否還參與後續回退。啟用前要確認該伺服器確實能解析所列網域，否則查詢失敗後可能不會再嘗試其他來源。對於區域網路主機名稱，直接使用本地解析伺服器或 hosts 靜態對映通常更清楚。將內部名稱交給公共解析來源，不僅得不到結果，還可能讓排查方向偏離本地網路。

hosts 適合穩定對映，不適合維護動態位址

hosts 可以將網域對映至固定位址，也可以用於少量別名關係。它在測試新服務、覆寫區域網路主機名稱或暫時繞過錯誤解析時很方便。由於對映優先於一般查詢，寫錯後會持續將連線送往錯誤目標。使用 hosts 排錯時，要記錄新增項目，並在驗證後決定是否保留，避免數週後位址已經變更，設定卻仍固定在舊值。

對映值的資料型態要符合核心要求，網域鍵也應寫成預期的完整名稱。如果目標同時有 IPv4 與 IPv6，單一固定對映會改變正常的位址選擇。對於由服務提供者動態調度的網域，不建議使用 hosts 長期固定某個結果；看似縮短了一次查詢，實際上可能失去故障切換與位址更新能力。遇到偶發連線問題，應先比較解析結果與連線日誌，而不是立即將目前 IP 寫死。

queryStrategy 影響位址族選擇

queryStrategy 用來控制查詢 IPv4、IPv6 或兩類位址的傾向。不同核心支援的具體值可能有所差異，應以目前用戶端所使用核心的有效設定為準。裝置所在網路只有穩定 IPv4 時，強制只回傳 IPv6 會導致目標無法連線；網路具備 IPv6 並不表示每條遠端鏈路都適合優先使用它。選擇策略時要結合本地網路、代理伺服器位址與目標出站的能力。

典型現象是網域解析很快，但連線在某個位址族上持續等待，之後回退或逾時。此時可以分別查看解析得到的 A 與 AAAA 記錄，再觀察核心實際嘗試的目標位址。不要將所有 timeout 都歸咎於節點故障。若切換查詢策略後恢復，應繼續確認是本地 IPv6 路由、遠端伺服器監聽還是目標網路路徑的問題，而不是永久依賴一個偶然有效的設定。

DNS 與 routing 需要閉環檢查

當 domainStrategy 需要解析網域以比對 IP 規則時，routing 會呼叫 DNS；解析查詢本身又可能透過某個出站傳送。設計不當會出現循環依賴：為了決定網域應走哪個出口而先發起查詢，但查詢出口又依賴尚未完成的網域分類。簡單環境應避免為 DNS 設計過度複雜的路由鏈。先確保基本查詢可用，再為明確的解析伺服器位址新增直連或代理規則。

檢查閉環可以分四步進行：第一，看應用程式交給入站的是網域還是 IP；第二，看路由策略是否需要解析；第三，看查詢由哪個伺服器處理；第四，看查詢連線本身透過哪個出站。任何一步與預期不同，最終都會表現為網頁無法開啟或分流錯誤。v2rayN 的日誌可以協助定位查詢與連線階段，閱讀方法可參考V2Ray 執行日誌怎麼看。

07 / ASSEMBLY

組合完整設定與啟動前檢查

先建立最小閉環，再逐層增加功能

組合設定時，最可靠的順序是先建立最小閉環：一個只監聽本機的 SOCKS 入站、一個有效的代理出站、一個直連出站，以及少量方向明確的路由規則。最小設定能夠啟動並完成連線後，再增加 HTTP 入站、DNS 條件、阻擋規則與 policy。這樣每次新增的範圍有限，出現問題時可以直接回復到上一份可用設定。

完整檔案中的每個標籤都要形成引用閉環。routing 使用的 outboundTag 必須能在 outbounds 中找到；inboundTag 必須與 inbounds 的標籤一致；使用者 level 若關聯 policy，也要存在對應策略。標籤區分大小寫時，Proxy 與 proxy 會被視為不同名稱。建議只使用小寫字母、數字與短橫線，減少輸入錯誤。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIP"
  },
  "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": "11111111-2222-4333-8444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  },
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300
      }
    }
  }
}

範例完整不代表節點參數可以直接使用

上面的 JSON 層級完整，可用於理解各部分如何組合，但其中的伺服器網域與使用者 ID 是文件範例。實際設定必須替換為自己的訂閱或服務資訊中的完整參數，並讓 streamSettings 與遠端一致。如果實際節點使用的不是範例中的協定或傳輸方式，應替換整個代理出站物件，而不是只修改協定名稱。協定物件內部結構不同，僅修改一個字串會留下不相容欄位。

使用 v2rayN、v2rayNG 或 v2flyNG 時，優先匯入節點後觀察用戶端產生的出站結構，再將需要的路由思路套用到用戶端支援的位置。不要為了使用本文範例而放棄用戶端已正確產生的節點參數。設定參考的用途是解釋結構與協助排錯，不是讓每位使用者都從空白檔案手動寫出全部連線資訊。

執行語法檢查與核心設定檢查

第一層檢查可以使用支援 JSON 的編輯器確認括號、引號與逗號。第二層需要讓實際核心讀取設定。獨立執行 Xray 時，常見測試方式是執行 xray run -test -config config.json；獨立執行 V2Ray 時，可依目前可執行檔支援的命令使用 v2ray test -c config.json。命令名稱與參數應以本機核心的說明輸出為準，因為用戶端封裝方式與可執行檔位置可能不同。

圖形用戶端使用者通常不需要手動開啟終端機測試暫存設定。重新啟動核心後查看用戶端日誌即可。若用戶端在啟動前會重新產生檔案，應在它提供的編輯入口中儲存變更。測試結果回報未知欄位時，先確認目前使用的是 V2Fly 還是 Xray 核心，再檢查該欄位屬於頂層、入站設定、協定設定還是 streamSettings。將正確欄位放錯層級，同樣會被判定為無效。

依資料流進行啟動後的四段驗證

設定通過讀取後，還要驗證執行鏈路。第一段檢查入站：確認連接埠正在監聽，應用程式的代理類型與連接埠相符。第二段檢查路由：存取一個目標，查看日誌選擇的是 proxy 還是 direct。第三段檢查出站：觀察遠端連線與握手是否完成。第四段檢查目標回應：確認應用程式取得實際內容，而不只是建立了本機代理連線。

如果第一段失敗，重點查看連接埠占用與監聽位址；第二段錯誤，檢查規則順序、目標形式與標籤；第三段失敗，檢查節點、網路與傳輸參數；前三段正常但第四段異常，再查看 DNS、目標服務與應用程式自身行為。這種分段方法比不停更換節點更有效，也能避免將本機連接埠問題誤判為遠端故障。

用戶端覆寫設定時如何保留變更

v2rayN 在切換伺服器、更新訂閱或變更代理模式後，可能重新組織核心執行設定。需要長期保留的內容，應放進用戶端支援的自訂路由、DNS 或自訂設定功能，而不是只編輯執行目錄中的暫存 JSON。修改前先匯出或記錄目前設定，更新後再確認自訂規則仍被合併。首次安裝與設定檔位置相關的注意事項，可查看v2rayN 首次安裝與初始設定完整流程。

Android 用戶端也可能將單節點設定、訂閱項目與執行設定分開儲存。編輯某個節點只會改變該節點的協定參數，不一定會改變全域路由。先確認目前頁面修改的是節點、路由還是應用程式設定，再進行測試。v2rayNG 首推使用 Xray 核心路徑，v2flyNG 則作為 v2fly 核心的備選；兩者擴充欄位存在差異時，不應直接互相複製完整 JSON。