V2Ray 設定檔完整參考

V2Ray 與 Xray 的主設定可理解為描述流量處理管線的 JSON 物件：入站接收連線，路由判斷去向，出站執行連線，DNS 與策略物件則為這條管線補充解析與資源限制。

頂層物件不是執行步驟清單

設定檔最外層由一個 JSON 物件構成，常見鍵包括 log、dns、inbounds、outbounds、routing、policy 與 stats。這些鍵在文字中的先後位置通常不決定執行順序，因為 JSON 物件以鍵名表達結構，而不是以書寫位置表達流程。真正具有順序語意的地方主要是陣列，例如 routing.rules 會由前往後匹配，先命中的規則先決定出站；多個入站與出站也透過各自的 tag 被其他物件引用。

閱讀設定時，較穩妥的方法是先記錄所有標籤，再沿著引用關係檢查。一個入站標籤可能被路由規則的 inboundTag 使用，一個出站標籤會由 outboundTag 指向，DNS 伺服器也可能透過 tag 與路由規則連接。標籤本身只是設定內部的識別碼，不會自動產生分流效果。若規則寫入不存在的標籤，設定可能在啟動階段報錯，也可能在執行到相關路徑時表現為流量沒有可用去向，具體取決於核心與欄位位置。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": ["1.1.1.1", "localhost"]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

陣列、物件與值的型別

inbounds、outbounds 與 routing.rules 都是陣列，因此使用方括號；單一入站、出站或規則則是物件，使用大括號。連接埠是數字，不應寫成帶單位的字串；布林值只能寫成 true 或 false；省略欄位與值為 null 並不等價。省略表示讓核心採用預設行為，而明確的空值只有在欄位定義允許時才有意義。許多啟動失敗都不是協定問題，而是括號未正確閉合、物件之間缺少逗號、字串誤用中文引號，或把原本應為陣列的欄位寫成單一字串。

標準 JSON 不允許註解，也不允許在最後一個成員後保留尾隨逗號。網路範例為了說明常會寫入 // 註解，但複製到用戶端核心設定前必須刪除。v2rayN、v2rayNG 與 v2flyNG 可能在圖形介面之外維護自己的設定層，介面中的節點、訂閱與路由設定經過轉換後才交給核心。因此，手動編輯前應先確認目前修改的是用戶端管理檔案、產生後的執行設定，還是獨立核心讀取的設定；三者不能因檔名相似就視為同一個物件。

從最小設定逐步增加複雜度

排查設定時，應先保留一個本機入站、一個明確可用的出站與最少量的路由，再逐步加入 DNS、嗅探、多種傳輸與統計策略。一次加入多個模組會讓錯誤來源彼此掩蓋。例如連線失敗可能來自遠端參數，也可能是網域先被錯誤的 DNS 路徑解析，或前置規則把連線送到了 blocked。最小化不是刪除必要的安全欄位，而是縮短變數鏈：維持伺服器要求的位址、連接埠、使用者識別碼、傳輸與安全參數不變，只暫時移除不影響連通性的附加規則。

儲存前還應確認文字編碼為 UTF-8、檔案內容只有一個根物件，且鍵名大小寫與欄位定義一致。outboundTag 與 outboundtag 是不同名稱，協定名稱也不應根據介面譯名自行推測。完成結構檢查後，再進入入站、出站與路由三部分逐段驗證，這比直接在大型設定中反覆修改連接埠，更容易得到可解釋的結果。

出站負責將經由路由選擇的連線傳送至目標位置。它可以連線到遠端協定伺服器，也可以直接存取目標、拒絕連線，或將流量交給另一個出站繼續處理。

協定欄位必須整體核對

遠端出站通常由 protocol、settings 與 streamSettings 共同定義。以 VLESS 為例，伺服器位址與連接埠位於 vnext 項目，使用者識別碼位於 users；傳輸方式、安全層與伺服器名稱則在 streamSettings 中。只核對位址、連接埠與使用者識別碼，不足以證明設定一致；用戶端與伺服器端的網路傳輸、TLS 類安全設定、路徑、主機名稱及相關擴充參數，也必須彼此對應。

設定介面常將這些欄位分散在「位址」「使用者」「傳輸」「安全」等頁面中，而 JSON 則把它們放在相鄰物件裡。訂閱匯入異常時，先在用戶端詳細資訊頁逐項查看，不要只根據節點顯示名稱判斷。節點名稱通常只是本機備註，不參與協定握手；真正影響連線的是結構化欄位。手動移轉參數時，應避免把 URI 中經過編碼的文字直接當作 JSON 原值，也不要把介面中表示「預設」的空白項目擅自改成字串 "default"。

{
  "outbounds": [
    {
      "tag": "remote-vless",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        },
        "wsSettings": {
          "path": "/example-path",
          "headers": {
            "Host": "server.example.com"
          }
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ]
}

direct 與 blocked 是明確的處理路徑

freedom 出站通常用於直接連線到目標，常標記為 direct；blackhole 用於終止被規則選中的連線，常標記為 blocked。這些標籤只是約定俗成的名稱，可以更改，但路由引用必須同步。將 freedom 放入出站陣列，不會自動讓本機位址直連，仍需由路由規則將相應流量指向它。同樣地，定義 blackhole 也不會自動攔截任何網域名稱，只有在匹配規則引用後才會生效。

沒有規則命中時，核心通常會選擇預設出站，具體行為取決於設定結構與核心實作。為避免讀者依賴隱含順序，大型設定宜為關鍵流量寫出明確規則，並讓出站標籤具有可讀意義。遠端出站、直連出站與阻斷出站的名稱應呈現用途，而不是使用容易混淆的連續數字。名稱清楚後，日誌中的出站識別也更容易對應到設定。

出站鏈、代理設定與循環

部分核心允許透過 proxySettings 或其他機制，讓一個出站經由另一個出站建立連線。這適用於明確設計的鏈式出口，但也增加了 DNS、握手與故障定位的層次。鏈條中的每一段都要有唯一標籤，且不能形成 A 指向 B、B 又指向 A 的循環。遠端伺服器網域名稱如何解析也需要單獨考慮：若用於建立第一段連線的 DNS 查詢反過來依賴尚未建立的出站，就可能形成啟動後持續逾時的閉環。

排查鏈式設定時，應先讓最後負責實體連線的單一出站獨立可用，再逐段向前加入。日誌若只有「連線已關閉」，需要結合出站標籤判斷失敗發生在哪一層。遠端拒絕、網域名稱解析失敗、TLS 伺服器名稱不符與本機路由提前選錯出站，都可能在表面上表現為應用程式無法開啟頁面。逐層驗證比同時替換所有協定參數更能保留證據。

桌面端優先使用 v2rayN 管理節點與核心設定，Android 可依核心需求選擇 v2rayNG 或 v2flyNG。若需要比較 Xray 與 V2Fly 的定位，可繼續閱讀Xray 與 V2Fly 核心差異整理；核心分支支援的欄位範圍可能不同，移轉複雜設定前應確認目標用戶端實際啟用的核心。

DNS 設定決定核心需要解析網域名稱時要向哪些伺服器查詢，以及特定網域名稱應優先進入哪組解析路徑。它與作業系統 DNS、應用程式自行解析及路由階段解析並非同一層。

先區分查詢由誰發起

應用程式可能先在系統層完成解析，然後只將目標 IP 交給代理；也可能把網域名稱原樣交給 SOCKS 或 HTTP 入站；部分應用程式還會使用自己的加密 DNS 機制。只有進入核心並由核心執行的查詢，才會直接受頂層 dns 物件控制。因此，修改設定後若觀察不到預期變化，應先確認入站收到的是網域名稱還是 IP，並檢查嗅探是否還原了網域名稱。僅更換 dns.servers，不能強制所有系統程式放棄自己的解析路徑。

servers 可以包含簡單位址，也可以包含帶有 address、domains、expectIPs、skipFallback 等屬性的物件。簡單陣列適合單一路徑；物件形式適合依網域名稱選擇伺服器。伺服器清單並不總是按照「第一個失敗才使用第二個」的傳統備援概念運作，網域篩選、回退設定與核心實作會共同決定查詢對象。設計複雜 DNS 前，先用兩個職責清楚的伺服器驗證，再加入網域範圍與回退限制。

{
  "dns": {
    "hosts": {
      "router.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "full:router.example",
          "domain:internal.example"
        ],
        "skipFallback": true
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:public.example"
        ]
      },
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts、domains 與預期結果

hosts 用於為明確名稱提供靜態對應，適合少量穩定的本機服務名稱，不適合作為大型動態網域表。靜態對應的優先順序較高，位址變更後若忘記更新，會造成「只有某個名稱持續指向舊位址」的現象。排查時應同時檢查作業系統 hosts 檔案、用戶端介面中的主機覆寫項目，以及核心設定中的 dns.hosts，避免多層覆寫互相衝突。

伺服器物件中的 domains 用於篩選交由該伺服器處理的網域名稱，語法與路由網域條件相近，但用途不同：前者選擇解析器，後者選擇連線出站。expectIPs 可限制預期回傳位址的範圍，用於判斷結果是否符合預設；它不是把任意回應改寫成目標範圍。限制過窄時，正常回應也可能被排除並進入回退。skipFallback 則會影響該伺服器參與回退的方式，組合使用前應先畫出「網域選擇—伺服器查詢—結果檢查—連線路由」四步關係。

DNS 查詢如何選擇出站

DNS 伺服器位址本身也需要建立連線。若伺服器寫成網域名稱，首先還有解析解析器網域名稱的問題；若寫成 IP，則省去這一層，但仍須由路由選擇網路出站。較複雜的設定會為 DNS 流量分配標籤，再在路由中依標籤或協定送往特定出站。此時必須避免閉環：遠端出站依賴網域名稱解析，而該網域名稱解析又被要求透過尚未建立的遠端出站完成。

建立可解釋路徑的方法，是先讓遠端伺服器位址具備穩定的基礎解析路徑，再決定一般目標網域名稱如何分流。若設定中同時使用 domainStrategy 與 DNS 規則，路由為判斷 IP 條件而觸發的解析也會進入 DNS 模組。因此，表面上的路由問題，實際上可能由 DNS 伺服器篩選或回退結果造成。排查日誌時應依時間順序觀察查詢、取得位址、選擇出站與連線目標，而不是只截取最後一筆逾時訊息。

快取、IPv4 與 IPv6 選擇

queryStrategy 用於限制或偏向查詢回傳的位址族群，支援範圍依核心而異。強制只使用一種位址族群，可能繞過本地網路不完整的問題，但也可能排除原本可達的目標。應先確認作業系統是否具備相應的網路連通性，再決定是否限制查詢。用戶端、核心與系統解析器都可能快取結果，修改 DNS 後立即重試不一定會觸發新查詢；可以重新啟動相關用戶端程序並建立新連線，但不應把清除快取當作長期設定方案。

針對「網域名稱無法存取、直接使用 IP 卻可以」的情況，先核對查詢是否回傳位址，再檢查回傳位址是否被路由規則送往預期出站。針對「部分網域偶爾失敗」，則需要比較失敗與成功時選用的 DNS 伺服器、位址族群與出站標籤。更換伺服器只能驗證解析器路徑，不能取代對規則條件的檢查。關於常見用戶端連線主線與驗證方法，可回到入門指南逐步確認。

遠端協定定義身分與請求格式，streamSettings 則定義這些資料如何承載於網路連線上。兩端協定參數正確但傳輸層不一致，連線仍無法完成。

network 決定後續設定物件

streamSettings.network 指定傳輸類型，常見設定可能涉及 TCP、WebSocket、gRPC 或 mKCP。選擇某種網路後，應使用與之對應的設定物件，例如 WebSocket 使用 wsSettings，gRPC 使用對應的服務名稱設定。保留另一種傳輸的欄位，通常不會自動將兩者組合，反而會造成閱讀誤判。移轉節點時，應先確認介面顯示的傳輸類型，再展開其專屬欄位逐項核對。

傳輸類型不是可由用戶端單方面最佳化的選項。伺服器端監聽什麼傳輸、使用什麼路徑或服務名稱，用戶端就必須依相同結構連線。遇到錯誤時頻繁在 TCP、WebSocket 與 gRPC 之間切換，通常只會增加變數。較穩妥的做法是依來源設定固定傳輸類型，檢查位址是否可解析、連接埠是否可達，然後再檢查路徑、主機欄位與安全層。

{
  "streamSettings": {
    "network": "grpc",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com",
      "allowInsecure": false,
      "alpn": ["h2"]
    },
    "grpcSettings": {
      "serviceName": "example-service",
      "multiMode": false
    },
    "sockopt": {
      "tcpKeepAliveIdle": 100
    }
  }
}

WebSocket 路徑、Host 與 TLS 名稱

WebSocket 設定中的 path 是 HTTP 握手路徑，是否帶有前導斜線、是否包含查詢部分，都應與伺服器端入口一致。headers.Host 屬於 WebSocket 握手標頭，而 tlsSettings.serverName 用於 TLS 伺服器名稱驗證，兩者可能相同，也可能因部署結構而不同。將它們視為同一欄位同步替換，可能導致其中一層成功、另一層失敗。

伺服器位址 address 決定最初連線至哪台主機，TLS 名稱決定憑證與握手所針對的名稱，WebSocket Host 則由 HTTP 層處理。排查時應依連線建立順序理解三者。若位址可以建立 TCP 連線但 TLS 失敗，重點檢查系統時間、伺服器名稱與安全參數；若 TLS 成功後 WebSocket 被拒絕，則繼續檢查路徑與 Host。單純將憑證驗證選項改為寬鬆值會降低錯誤可見性，不應作為常規修復方式。

gRPC、mKCP 與傳輸專屬欄位

gRPC 設定通常需要準確的 serviceName，並依賴 HTTP/2 相關協商。服務名稱是設定值，不是節點備註，也不應自行加入 URL 形式的斜線。若中間層不支援所需連線方式，可能表現為握手後立即關閉。mKCP 屬於基於 UDP 的傳輸，除了雙方參數外，也取決於目前網路是否能穩定承載 UDP；TCP 可達不能證明 UDP 路徑同樣可達。

傳輸專屬參數數量較多時，應優先使用用戶端依節點資訊產生的結構，再針對明確需求修改。網路上跨核心、跨時期的範例，可能包含已經調整過的欄位名稱。v2rayN 通常搭配桌面端核心管理，v2rayNG 使用 Xray 核心路徑，v2flyNG 則面向 V2Fly 核心；同名傳輸的基礎概念相近，但擴充欄位未必完全一致。無法確認支援範圍時，先刪除非必要擴充，保留伺服器端要求的核心欄位。

security、TLS 與 Reality 的層級

security 決定啟用的安全層，對應設定物件必須與其一致。TLS 參數放在 tlsSettings，Reality 參數則使用核心規定的獨立設定物件。兩類設定不能只替換 security 字串，卻沿用全部舊欄位。伺服器名稱、公鑰類參數、短識別碼與指紋類選擇，都屬於特定安全方式的握手條件，必須來自同一份有效設定。

安全層錯誤與使用者識別碼錯誤在介面上都可能表現為連線測試失敗，因此需要依日誌判斷 DNS、TCP、TLS 或協定驗證發生在哪一步。若連伺服器連接埠都無法建立連線，繼續修改伺服器名稱沒有意義；若 TCP 已建立但安全握手失敗，則不要先修改路由規則。先將故障定位到具體層級，再修改參數，可避免某項改動暫時改變錯誤形式，卻沒有解決根本原因。