V2Ray 設定檔 JSON 結構解析：逐段看懂 inbounds、outbounds 與 routing

先分清用戶端設定與核心設定

v2rayN 是桌面用戶端，負責管理訂閱、伺服器項目、路由預設值及核心程序；V2Ray 或 Xray 才是讀取核心設定並處理連線的程式。用戶端儲存的介面偏好與訂閱群組資料，不等於交由核心載入的執行階段 JSON。排查時應找到這次啟動實際載入的檔案，不要只因副檔名是 .json 就直接修改。

Android 上的 v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心。本文說明的是 V2Ray 常見的設定結構，不能因此推論兩種核心的所有欄位都通用。例如 REALITY 是 Xray 相關功能，對應設定不能直接交給 V2Fly 使用。即使欄位名稱同樣是 streamSettings，傳輸方式名稱與可用選項仍應以目前使用的核心為準。

這是閱讀設定的主流程；需要解析網域名稱時，DNS 會在相應環節參與，日誌則會記錄整個過程。系統代理只影響遵循該設定的應用程式；設定中有 SOCKS 入站，不代表所有應用程式的流量都已進入核心。入口尚未連通時，繼續修改路由通常也不會改變結果。

• 確認核心：查看啟動日誌，確認目前執行的是 V2Ray 還是 Xray，而不只是看用戶端名稱。
• 確認檔案：查看啟動日誌或程序啟動參數中的設定檔路徑；路徑與檔名可能因用戶端版本而異。
• 保留原始檔：先複製執行中的設定檔再閱讀；更新訂閱、切換節點或重新啟動核心，都可能重新產生檔案。

完整 JSON 範例：一個入口、兩個出站、兩條規則

以下是用於說明結構的設定，不包含遠端代理伺服器。它會在 127.0.0.1:10808 提供 SOCKS 服務，阻斷前往 example.org 的精確網域請求，以及 TCP 25 連接埠的請求；其餘連線預設直連。請勿用它取代現有訂閱設定，否則原有的代理出站會遺失。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-local",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "socks-local"
        ],
        "domain": [
          "full:example.org"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp",
        "port": "25",
        "outboundTag": "block"
      }
    ]
  }
}

頂層物件的鍵值排列順序通常不會決定處理順序；本文只是依閱讀需要排列。但陣列中的項目順序可能直接影響行為，尤其是 outbounds 的第一項與 routing.rules 的先後順序。不要為了「整理格式」而任意重排這兩個陣列。

log：透過日誌區分啟動錯誤與連線錯誤

log 用來控制日誌輸出，不負責選擇節點。範例只設定 loglevel，未指定日誌檔案；實際輸出位置取決於核心的啟動方式，用戶端也可能將輸出收集到自己的日誌面板。排查時先看啟動後出現的第一則錯誤，再查看觸發存取時新增的紀錄。

如果核心一啟動就結束，先修正設定或連接埠衝突，不要先更換 DNS。如果核心運作正常，只有特定請求失敗，再檢查對應目標、路由結果與連線錯誤。日誌可能包含存取的網域、伺服器位址及本機路徑，請勿將完整的執行設定與日誌直接公開。

dns：解析伺服器與路由策略是不同設定

dns.servers 用來指定核心內建 DNS 使用的解析伺服器。範例中的 1.1.1.1 是一般 DNS 伺服器位址，通常透過 UDP 53 連接埠查詢；這裡沒有設定加密 DNS，也不代表查詢會自動經由代理。解析伺服器是否可連線，仍須在實際網路環境中測試。

最容易混淆的是兩個同名欄位：routing.domainStrategy 決定路由比對階段如何處理網域名稱；freedom 出站中的 settings.domainStrategy，則決定建立直連時如何解析目標。兩者位於不同物件中，列舉值與作用也不相同。

IPIfNonMatch 會在網域未命中規則時嘗試解析，再比對 IP 規則；IPOnDemand 則會在比對過程需要 IP 時觸發解析。兩者都不是「強制所有流量走代理」的設定。如果設定中沒有 IP 規則，先維持簡單策略，避免只為了解釋一條網域規則，就引入額外的解析行為。

• 瀏覽器自行完成的網域解析，不會因為核心設定中有 dns 物件，就自動全部交由核心處理。
• 如果應用程式只向 SOCKS 入口傳送 IP，核心可能無法取得原始網域，因此網域規則可能不會命中。
• 內建 DNS 設定不等於修改作業系統的 DNS，兩者應分開檢查。

inbounds：確認應用程式連到哪個入口

inbounds 是一個陣列，每個項目都描述一個接收連線的入口。本例的 listen 限定為本機迴路位址，port 是數字 10808，protocol 則是 socks。這三個欄位共同決定應用程式要連到哪裡，以及使用哪種協定連線。

1. 確認監聽位址：127.0.0.1 僅供本機存取。改成 0.0.0.0 會擴大監聽範圍，排查問題時不應直接暴露未設定驗證的入口。
2. 確認協定：SOCKS 連接埠不等於 HTTP 代理連接埠。讓只支援 HTTP 代理的程式連到本例的 10808，不能據此判斷節點是否可用。
3. 確認實際連接埠：10808 是本文指定的數值，不是所有用戶端共用的固定值。v2rayN 可在「設定」→「參數設定」中確認本機監聽相關選項，最後仍應以執行設定與日誌為準。
4. 確認 UDP：udp: true 允許這個 SOCKS 入站處理 UDP，但應用程式仍須使用 SOCKS UDP 機制，後續出站與網路也必須支援相應流量。

tag: socks-local 是入口的內部名稱，不是網域，也不是訂閱中的節點名稱。它不會改變監聽協定，而是讓其他設定可以引用這個入口。本例第一條規則的 inboundTag 使用陣列格式，因為一條規則可以接受多個入口標籤。

"inboundTag": [
  "socks-local"
]

變更入口標籤後，也要同步更新引用它的規則。如果只把入站的 socks-local 改成 local-socks，卻保留原本的規則，該規則就無法比對這個入口的流量。

outbounds：標籤、協定與預設出站

outbounds 定義連線接下來如何送出。本例中的 freedom 代表直連，blackhole 代表阻斷；兩者都不是遠端代理協定。實際訂閱產生的設定可能還會有 VMess 或 VLESS 出站，並包含伺服器位址、連接埠、使用者識別資料及傳輸參數。

在本例這種未設定其他預設分派機制的情況下，未命中路由規則的連線會使用 outbounds 的第一項，因此預設為直連。將 block 移至第一項會改變預設處理方式；更改標籤名稱則不會自動改變陣列順序。

如果實際設定使用 proxy 作為代理出站標籤，路由中的 outboundTag: proxy 就必須能找到對應的出站項目。在本例新增一條指向 proxy 的規則，不會憑空建立代理連線；應先保留並確認用戶端產生的有效代理出站設定。

routing：規則由上而下比對，分清條件的「且」與「或」

routing.rules 通常由上而下依序檢查；命中一條規則後，就會使用該規則指定的出站，不再繼續比對後面的普通規則。因此，條件較明確的規則應排在涵蓋範圍較廣的規則之前。設定中有某條規則，不代表它一定有機會執行。

同一條規則中的不同條件欄位通常是「且」的關係；同一欄位陣列中的多個候選值，通常則是「或」的關係。本例第一條規則同時要求入口為 socks-local，目標網域為 example.org；兩者都符合時，才會交由 block 處理。

• full:example.org：只精確比對這個網域，不包含 www.example.org。
• domain:example.org：比對這個網域及其子網域，適合需要涵蓋整組網域的情境。
• network: tcp 與 port: "25"：本例第二條規則同時比對 TCP 網路與目標 25 連接埠；這裡指的不是本機監聽連接埠。
• outboundTag: block：結果會送往阻斷出站，不會接著嘗試下一條規則。

以上推演的前提是應用程式確實將網域名稱傳給 SOCKS 入站。如果應用程式已先解析網域，只傳送 IP，第一條網域規則可能無法使用。嗅探可在部分協定中辨識網域資訊，但不保證能還原原始網域；本例未啟用嗅探，建議先用明確指定網域的請求測試規則。

設定檢查步驟與常見問題

閱讀設定時一次只修改一個變數，並記錄修改前後的日誌。先確認核心能啟動，再確認入口可連線，最後檢查規則與出站；如果同時修改連接埠、DNS、標籤與傳輸參數，就很難判斷成功或失敗的原因。

1. 檢查語法與類型：連接埠 10808 是數字，udp 是布林值 true，inbounds 與 outbounds 則是陣列。
2. 核對所有引用：逐一搜尋 inboundTag 與 outboundTag，確認對應的入口或出站中確實有同名的 tag。
3. 確認應用程式使用正確入口：測試本例時，請明確指定 SOCKS 位址，避免瀏覽器的系統代理設定影響判斷。
4. 推演路由：從第一條規則開始，依序檢查目標網域、目標連接埠、網路類型與入口標籤。
5. 恢復由用戶端管理：確認原理後，將長期修改套用至用戶端支援的路由或設定選項，再重新產生執行設定並驗證。

如果裝置已安裝支援 SOCKS 的 curl，且核心已載入本例設定、連接埠也未被占用，就可以執行以下命令。socks5h 會要求 SOCKS 服務處理目標網域；本例會因精確網域規則而阻斷請求，這是預期的測試結果，不代表遠端代理故障。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 https://example.org/

想了解更多設定概念，可參閱路由分流技術參考；若要透過用戶端介面確認解析設定，請依照教學中的 DNS 設定步驟操作。看懂核心結構後，再逐項對照用戶端介面，能減少把訂閱、入口和路由誤當成同一項設定的情況。