V2Ray 設定檔參考

本頁與教學頁的分工

本頁是 V2Ray 設定檔的系統查閱手冊，按欄位解說一份 config.json 從頂層結構到各功能段該怎麼寫。站內另有快速上手教學，那條主線只做一件事：把訂閱匯入用戶端、選好模式、連上、確認可用。兩者分工明確——教學頁回答「下一步點哪裡」，本頁回答「這個欄位是什麼意思、寫成什麼值合法、寫錯會怎樣」。已經能正常連線、只想日常使用的使用者，不需要讀完本頁。

設定檔在整體鏈路中的位置

三款用戶端都是圖形外殼，真正建立連線的是它們內建的核心。v2rayN 桌面版內建 Xray 核心，v2rayNG 使用 Xray，v2flyNG 使用 V2Fly 核心。圖形介面上勾選的每一項——傳輸方式、TLS、多工、分流開關——最後都會被轉譯成一份 JSON 設定，核心啟動時讀取這份 JSON，依裡面的 inbounds 監聽本機連接埠，依 outbounds 把流量送出去。理解這層轉譯關係之後，排查問題時就能先判斷：是介面上的選項沒選對，還是產生的設定本身有問題。

三款用戶端對手動改設定的支援

v2rayN 在節點編輯視窗裡提供完整的 JSON 編輯入口，訂閱匯入的節點會先被解析成內部結構，再由用戶端依目前設定重新產生設定；v2rayNG 支援自訂設定與訂閱匯入，但在行動裝置上編輯長 JSON 不方便，更常見的做法是在桌面端整理好再匯入；v2flyNG 與 v2rayNG 的設定格式同源，差別在核心家族。三款用戶端的下載入口都在取得用戶端頁面，橫向差別見橫向評測。

建議的閱讀順序

第一次接觸設定檔的使用者，先讀第二章的結構總覽，建立「頂層有哪些段、哪兩段必需」的整體印象；之後再按需要跳到特定章節。日常使用中出現頻率最高的三段是 outbounds、routing 和 dns：出站決定流量怎麼出去，路由決定哪些流量走哪個出站，DNS 決定網域在哪裡解析。policy 屬於調校項，預設值對多數情境夠用，只在需要控制記憶體占用或連線回收時間時才細看。

欄位與核心版本的關係

設定格式在不同核心版本之間有小幅演進，新的傳輸方式與新的安全類型通常先在 Xray 側落地，V2Fly 側再跟進。本頁範例以通用欄位為主，不綁定特定版本號。判斷某個欄位在目前用戶端裡是否可用，可靠的做法是看執行日誌：核心不認得的欄位會在啟動日誌裡報錯或給出忽略提示，而不是默默生效。

關於範例值

本頁所有設定片段裡的網域、UUID、公鑰都使用明顯可替換的範例寫法，不要直接照抄進實際設定。節點參數以服務供應商提供的資訊為準。頁面頂端的章節列可以跳到任何一章，每章內部按小節展開：表格用於欄位速查，程式碼區塊用於完整片段，帶底色的提示區塊用於容易踩的坑。

頂層有哪些段

一份完整的設定檔是一個 JSON 物件。頂層常見的段落有九個：log 負責日誌，inbounds 定義本機監聽入口，outbounds 定義流量出口，routing 定義分流規則，dns 定義解析策略，policy 定義連線與緩衝策略，stats 與 api 供圖形用戶端讀取執行狀態，reverse 用於反向代理情境。其中 inbounds 與 outbounds 是必需的兩段：沒有入站，應用程式流量進不來；沒有出站，流量送不出去。

下面這份最小設定只保留了必需項和一個日誌段，可以用來理解結構，但它只做直連，不具備代理能力：

欄位命名與語法紀律

JSON 對語法很嚴格，設定檔裡最常見的啟動失敗都來自下面這幾條。欄位名稱大小寫敏感，outbounds 寫成 outBounds、streamSettings 寫成 streamsettings 都會解析失敗；標準 JSON 不允許註解，從網頁或筆記複製設定時，行內的雙斜線註解和區塊註解必須刪掉；不允許尾隨逗號，陣列或物件的最後一項後面多一個逗號就會報錯；字串一律用雙引號，不能用單引號；連接埠、逾時這類數值直接寫數字，不要加引號；布林值只有小寫 true 和 false。

tag 的作用

每個入站、出站都可以帶一個 tag 欄位。tag 是自訂字串，routing 規則透過 tag 引用具體的入站或出站——例如「來自 socks-in 的流量走 proxy 出站」。tag 建議用看得懂的名字，如 socks-in、http-in、proxy、direct、block，方便幾個月後回頭看設定時還能對得上。同一份設定裡 tag 不要重複，重名會讓規則指向不明確。

載入與生效方式

核心在啟動時一次性讀取設定。改動設定後需要重新啟動核心或觸發重新載入，圖形用戶端一般在儲存節點後自動完成這一步。設定錯誤有兩種表現：一種是解析失敗，核心直接結束，日誌裡會給出出錯位置；另一種是欄位合法但語意衝突，核心能啟動，但連線行為與預期不符，例如路由規則順序寫反導致分流不生效。前者好定位，後者要靠對照日誌逐段排除。

與訂閱的關係

訂閱裡的每個節點最後都會被展開成一份這樣的設定。用戶端為每個節點產生獨立的 outbounds 項目，再補上入站、路由和 DNS 段，拼成核心能讀的完整檔案。所以訂閱更新時，用戶端是按整份設定重新產生的，手動改過的欄位會被覆蓋，這一點在後面的用戶端章節會展開說明。

不同用戶端存放設定檔的位置不同，桌面端通常在程式目錄或使用者設定目錄下，Android 端由應用程式內部管理。日常使用不需要關心具體路徑，只有在匯出設定做備份或移轉時才需要找到它。

入站做什麼

入站描述核心在本機監聽什麼，是應用程式流量進入核心的入口。圖形用戶端通常自動產生兩項：socks 入站給瀏覽器和系統代理使用，http 入站給只支援 HTTP 代理的程式使用。兩者監聽不同連接埠，可以同時存在。下面是一份雙入站設定，包含嗅探設定：

欄位逐一說明

為什麼需要 sniffing

當應用程式透過 socks 把目標位址傳過來時，傳的有可能是 IP 而不是網域。一旦目標以 IP 形式出現，routing 裡所有基於網域的規則都會失效，分流自然不準。開啟 sniffing 後，核心會從 TLS 握手的 SNI、HTTP 請求標頭的 Host 裡把真實網域提取出來，再拿這個網域去比對路由規則。destOverride 列出允許被覆寫的協定類型，常見寫法是 http 與 tls；routeOnly 設為 true 時，提取出的網域只用於路由判斷，不改寫實際請求的目標位址，適合需要保持原始請求形態的情境。桌面端與行動端用戶端預設都會開啟嗅探。

dokodemo-door 說明

dokodemo-door 是另一類入站，作用是把某個本機連接埠收到的流量原樣轉送到指定目標，常用於把區域網路裝置或某個固定連接埠的請求接入核心。它在圖形用戶端裡沒有對應的開關，屬於手寫設定的範疇，需要自己指定 address 與 port。

監聽位址的安全邊界

listen 寫 127.0.0.1 時只有本機能存取這個連接埠，這是預設做法。改成 0.0.0.0 後，同一網路下的其他裝置可以直接把代理指向這台機器，適合明確需要共用代理的情境，但要求網路環境可信。圖形用戶端裡對應的選項一般寫作「允許來自區域網路的連線」，打開前先確認這一點。代理連接埠本身不做身分驗證時，任何能存取到該連接埠的裝置都可以直接使用。

outbounds 出站

出站做什麼

出站決定流量離開核心之後怎麼走。outbounds 是一個陣列，裡面可以有多個項目，每個帶自己的 tag。陣列的第一項是預設出站，沒有命中任何路由規則的流量走它。下面是一份 VLESS 出站範例，傳輸層使用 TCP 搭配 REALITY：

伺服器參數

vnext 陣列描述遠端伺服器，每項包含 address、port 和 users。address 可以寫網域也可以寫 IP；port 是伺服器端監聽連接埠。users 裡的 id 是身分識別，VMess 與 VLESS 都用 UUID 形式。VLESS 的 encryption 欄位固定寫 none，加密交給傳輸層處理；VMess 的 alterId 在新版裡預設 0，舊節點如果還要求非零值，填錯會直接連線失敗。flow 是 VLESS 的流量控制選項，與傳輸層安全類型搭配使用，tcp 傳輸搭配 TLS 或 REALITY 時常見寫法是 xtls-rprx-vision。

傳輸層參數

下面這段是 WebSocket 搭配 TLS 的傳輸層寫法，與上面的 REALITY 範例屬於同一層級，替換 streamSettings 整段即可：

VMess 出站的差別

VMess 出站的結構與 VLESS 相同，差別在 users 裡的欄位：VMess 用 alterId 與 security 兩個欄位描述加密方式，前者在新版裡預設 0，後者常見寫法是 auto。傳輸層參數與 VLESS 完全通用，同一個伺服器端如果同時提供兩種協定，切換時只需要改 protocol 和 users 這兩處。VMess 與 VLESS 在身分驗證與傳輸依賴上的差別，在協議科普裡有四點對照。

mux 多工

mux 是多工開關。開啟後，核心把多條連線合併到一條底層連線上，減少重複握手，在網路狀況穩定的鏈路上能降低延遲；代價是單條連線的品質會互相影響，大檔案下載這類持續高吞吐的情境反而可能變慢。用戶端預設關閉，視需要開啟即可。

freedom 與 blackhole

freedom 是直連出站，收到什麼就原樣送出去，常搭配路由規則處理中國大陸網域和私有位址。它有一個 sendThrough 欄位，可以指定從本機哪個位址發出。blackhole 是丟棄出站，用來攔截特定流量，可以設定回應內容。兩者都不需要伺服器參數，寫一個 tag 就能用。

routing 路由規則

規則怎麼生效

routing 決定哪些流量走哪個出站。結構由 domainStrategy 和 rules 兩部分組成。規則由上而下依序比對，第一條命中的規則生效，後面的規則不再判斷——所以規則的順序比條數更重要。rules 陣列裡每一項都是一個物件，type 固定寫 field，其餘欄位描述比對條件與命中後的動作。

domainStrategy 的三個取值

規則條件欄位

網域比對的四種前綴

下面是一份可直接使用的分流片段：私有位址與中國大陸網域直連，UDP 443 連接埠攔截，其餘流量走預設出站。

順序寫反的典型後果

舉一個順序寫反的例子：第一條規則寫「所有流量走 proxy」，第二條寫「中國大陸網域直連」。因為第一條已經命中了全部流量，第二條永遠不會被判斷，分流效果等於沒有。正確寫法是把具體條件放在前面、寬泛條件放在後面，最後再加一條涵蓋其餘流量的規則。判斷順序問題時，把日誌等級臨時調到 debug，核心會印出每條連線的比對結果，能直接看到命中的是哪一條。

geosite 與 geoip 資料

geosite:cn、geoip:private 這類寫法依賴用戶端內建或下載的規則資料檔。資料有更新週期，新出現的網域可能還沒被收錄，表現為個別網站的分流結果不符合預期。圖形用戶端一般在路由設定裡提供資料更新入口，定期更新一次即可。私有位址段的資料很少變動，不需要頻繁更新。

balancer 簡述

balancer 用於在多個出站之間分送流量，規則裡用 balancerTag 引用。它需要先定義 balancer 段，用 selector 依 tag 前綴挑選出站，再指定分送策略。一般使用者很少需要，只有維護多個等價節點時才用得上。

dns 設定

寫與不寫 dns 段的差別

dns 段決定核心如何解析網域。不寫這段時，核心把解析交給系統；寫了之後，核心依設定裡的伺服器清單和策略自己發出查詢。寫這段有三點價值：避免解析結果被中間環節干擾、讓基於網域的分流更準確、減少一次多餘的解析往返。下面是常用欄位的完整寫法：

hosts 的用途

hosts 是靜態對應，把網域直接指向固定 IP，解析這一步就省掉了。它適合兩種情境：節點網域已知且穩定，想跳過解析；測試環境裡需要把某個網域固定到指定位址。寫法上支援 domain:、full:、keyword: 前綴，與路由規則的網域寫法完全一致，不需要額外記憶。

queryStrategy 怎麼選

queryStrategy 控制優先解析出的位址族。UseIP 表示不限制，依伺服器回傳的順序；UseIPv4 和 UseIPv6 分別只保留對應位址族。在只有 IPv4 出口的環境裡寫 UseIPv4，可以避免解析出 IPv6 位址後又因為無法連線而重試，少一次失敗往返。反過來，如果本機網路已經以 IPv6 為主，寫 UseIPv6 能減少不必要的雙棧查詢。

與路由的搭配

DNS 查詢由核心自己發出，不經過 outbounds 裡的代理鏈路，因此不需要為解析單獨寫路由規則。需要留意的是解析結果會影響路由：如果開啟了 IPIfNonMatch，網域會先被解析成 IP 再比對 IP 規則，解析結果不準，IP 規則就會跟著不準。這也是把 dns 段和 routing 段放在一起看的原因。

不同模式下誰在解析

桌面端使用系統代理時，網域解析仍由作業系統完成，核心的 dns 段只在核心需要自己解析時才起作用；開啟 TUN 模式後，核心接管全部流量，包括 DNS 請求。Android 上的 v2rayNG 透過 VpnService 運作，同樣會接管 DNS 查詢。所以同一份 dns 設定在不同用戶端、不同模式下的實際影響範圍並不相同，判斷效果時要先確認目前處在哪種模式。

policy 策略

什麼時候需要寫 policy

policy 控制連線的生命週期與緩衝區大小，屬於調校項。預設值對一般使用足夠，寫它的典型情境有三個：降低記憶體占用、加快閒置連線的回收、給不同入站設定不同限制。下面是一份常見寫法：

levels 的用法

levels 的鍵是等級編號，0 是預設等級。入站的 settings 或使用者設定裡可以指定 level 欄位，把某個入站或某個使用者歸到特定等級，達到依入口分別限流的效果。日常使用只改 0 這一檔就夠了，給不同入口分配不同等級屬於多使用者情境下的做法。

system 段

system 段控制統計開關。statsInboundUplink 與 statsInboundDownlink 打開後，核心會統計入站方向的上下行流量，圖形用戶端的速率顯示依賴這些資料；statsOutboundUplink 與 statsOutboundDownlink 對應出站方向。關閉統計可以省下一點開銷，代價是介面上的流量數字不再更新。

調校的取捨

降低 connIdle 會讓閒置連線更快被回收，記憶體占用也隨之下降，代價是再次使用時需要重新建立連線，表現上會多一次握手延遲。bufferSize 調大對高頻寬情境有幫助，調小則省記憶體。handshake、uplinkOnly、downlinkOnly 一般不需要調整，只有在網路品質較差、握手經常逾時的環境裡才考慮放寬 handshake。

行動端的特殊情況

行動端上背景連線被系統回收，通常與 policy 無關，而是省電策略在起作用。相關處理方式在v2rayNG 使用要點裡說明。調校的前提是先有穩定的基準，建議保留一份預設設定，改動後逐項對比，確認效益真實存在再保留。網路上流傳的參數組合大多針對特定硬體和特定情境，直接照搬未必帶來改善。

用戶端裡的設定產生與手動修改

訂閱是怎麼展開成設定的

訂閱網址回傳的是一段經過編碼的文字，用戶端下載後逐行解析，每一行描述一個節點的完整參數，再把參數轉譯成 outbounds 裡的一個項目。訂閱裡的節點數量對應 outbounds 陣列的長度，訂閱更新時整份設定重新產生。理解這條鏈路之後，就能明白為什麼在介面裡改過的節點會在更新後回到原樣。

分享連結參數與設定欄位的對應

v2rayN 裡的編輯入口

v2rayN 的節點清單右鍵選單裡有編輯入口，視窗依基礎欄位和傳輸欄位分組。需要改用戶端介面沒有暴露的欄位時，可以在參數設定裡找到完整設定編輯入口。要注意訂閱更新是按訂閱整體替換節點清單的，手動改過的節點在下次更新後會被覆蓋；需要長期保留的調整，建議另存為獨立節點或先匯出備份。

v2rayNG 的設定來源

v2rayNG 的節點來源有三種：掃描 QR Code、從剪貼簿匯入分享連結、訂閱匯入。行動端編輯長 JSON 不方便，常見做法是在桌面端整理好再匯入。分應用程式代理在設定裡依應用程式勾選，只決定哪些應用程式的流量進入 VpnService，與 JSON 設定本身無關——也就是說，分應用程式代理的規則不會出現在 config.json 裡。

v2flyNG 的定位

v2flyNG 與 v2rayNG 的設定格式同源，差別在核心家族。同一個節點的參數在兩邊都能用，當某個核心版本對特定傳輸方式的支援有差異時，備選用戶端可以作為對照。三款用戶端的平台與版本入口見取得用戶端頁。

什麼情況值得手動改設定

三種情境值得手動改：用戶端介面沒有暴露某個欄位，例如自訂路由規則、bufferSize；需要依應用程式或依連接埠單獨分流；排查問題時想用最小設定重現。前兩種建議在桌面端完成，改完匯出再同步到行動端。第三種情境下手寫的設定越短越好，只保留重現問題必需的段落。

訂閱格式的更多細節

訂閱有三種常見形態：base64 編碼的連結清單、原生 JSON 設定、以及單條分享連結。三者的差別與轉換時容易漏掉欄位的地方，在訂閱格式科普裡有逐項對照。匯入失敗時，先確認訂閱回傳的是哪一種形態，再決定用哪個入口匯入。