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

一、V2Ray 設定結構：先分清客戶端與核心

先說結論：inbounds 決定從哪裡接收請求，outbounds 決定如何建立後續連線，routing 則決定將請求交給哪個出站。這三者不是各自獨立的開關，而是同一條處理鏈上的三個環節。

v2rayN 是桌面客戶端，負責儲存節點、管理訂閱、產生執行設定並啟動所選核心。Android 版 v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心。客戶端名稱相近，不代表接受的設定欄位完全相同。排查前，先從日誌或「關於」頁面確認實際執行的核心及版本。

本文採用常見的傳統 JSON 設定結構。V2Ray 與 Xray 在這套結構上有共通之處，但功能支援仍須以各自版本為準。例如 REALITY、xtls-rprx-vision 等設定，不代表可以直接套用到 V2Fly；即使它們出現在某份 Xray 範例中也一樣。分享連結與訂閱內容也不一定是完整的執行設定，不能只把網址貼進 JSON 檔就交由核心執行。

二、inbounds 入站：位址、連接埠與協定各自負責什麼

入站是核心接收流量的入口，不是遠端伺服器。瀏覽器連上本機 SOCKS 連接埠時，請求會先進入入站，再由核心選擇出站。以下將 SOCKS 監聽連接埠設為 10808，HTTP 監聽連接埠設為 10809；這只是本文範例值，並非所有客戶端的預設值。

listen 是監聽位址。127.0.0.1 只接受本機連線；改成 0.0.0.0 則會監聽所有 IPv4 網路介面，可能讓同一個區域網路中的其他裝置連上代理入口。若只供本機使用，請勿為了排錯而直接擴大監聽範圍。

• 連接埠遭占用：出現 address already in use 或繫結失敗時，先檢查是否有其他核心程序占用相同的位址與連接埠。
• 協定不符：將 HTTP 代理請求送到 SOCKS 入口時，即使連接埠可連線，也可能在交握階段失敗。
• 標籤用途：tag 是設定中的引用名稱。它不是密碼，但後續路由引用時必須完全一致。
• UDP 適用範圍：SOCKS 設定允許 UDP，不代表系統中所有應用程式的 UDP 流量都會自動進入該入站。

三、outbounds 出站：節點參數與預設出口

出站描述核心如何向外連線。遠端代理通常需要伺服器位址、連接埠、使用者憑證及傳輸安全參數；直連出站則直接連線到目標服務。在本文採用的傳統設定結構中，沒有規則符合時，預設使用 outbounds 陣列的第一個項目。因此，陣列順序也會影響實際流量方向。

VMess、VLESS、Trojan 和 Shadowsocks 不能共用同一套 settings。同樣稱為「連接埠」的欄位，也要分清本機監聽連接埠與遠端伺服器連接埠。前者決定應用程式如何連入本機，後者決定核心如何連線至伺服器；修改其中一個，不會自動解決另一個的問題。

以 VMess 為例，使用者資訊位於協定指定的使用者陣列中；TLS 則屬於傳輸安全設定。WebSocket 路徑、TLS 伺服器名稱與遠端位址也不一定相同。匯入訂閱後若無法連線，請逐項比對服務提供者給的參數，不要把所有欄位都改成伺服器位址。

四、routing 路由：規則順序與網域解析時機

路由不會自動挑選「看起來最精確」的規則，而是依設定順序逐一檢查，由第一條符合的規則決定出口。範圍較廣的規則若排在前面，後續的細分規則可能永遠不會生效。同一條規則若同時設定入站、網域與連接埠等條件，通常必須全部符合。

{
  "domainStrategy": "AsIs",
  "rules": [
    {
      "type": "field",
      "domain": ["full:example.invalid"],
      "outboundTag": "block"
    },
    {
      "type": "field",
      "inboundTag": ["socks-in", "http-in"],
      "outboundTag": "direct"
    }
  ]
}

這段規則先將 example.invalid 的完整網域比對交給 block，再將來自兩個本機入口的其他請求交給 direct。這個網域僅用來示範比對語法，並非可用的遠端服務位址。full: 代表完整網域比對；domain: 則可比對指定網域及其子網域，兩者不可混為一談。

• AsIs：路由階段保留原本的目標形式，不會為了 IP 規則而特別解析網域。直連出站在後續建立連線時，仍可能解析網域。
• IPIfNonMatch：網域未符合規則時，嘗試解析網域，並繼續比對 IP 規則。
• IPOnDemand：比對過程需要檢查 IP 條件時，可觸發網域解析。

網域規則也取決於入站取得的資訊。如果應用程式已先將目標解析為 IP，再把 IP 交給代理，核心不一定知道原始網域。嗅探可從部分協定流量中擷取網域線索，但並非所有請求都能靠它補救，也不等於已設定 DNS 分流。

五、完整 JSON 範例：兩個入站、直連與封鎖

以下是完整的傳統格式範例，只示範結構，不提供遠端代理功能。範例會監聽本機的兩個連接埠，預設直連，並封鎖一個示範網域。若已有客戶端使用這些連接埠，請先停止相關程序，或改用未占用的連接埠，以免將連接埠衝突誤判為設定語法錯誤。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.invalid"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "inboundTag": ["socks-in", "http-in"],
        "outboundTag": "direct"
      }
    ]
  }
}

閱讀時可以從任一引用反向查找：看到 outboundTag: "block"，就到出站陣列尋找 tag: "block"；看到 inboundTag，就回到入站陣列確認名稱。把標籤想成設定中的連線，比逐字背欄位更容易找到問題。

1. 使用支援純文字的編輯器，將檔案儲存為 config.json，並確認沒有另存成豐富文字格式。
2. 物件鍵名與字串必須使用英文雙引號；數字連接埠不可寫成帶有單位的文字。
3. 陣列或物件的最後一個項目後不可加逗號。範例採用標準 JSON 格式，不含註解。
4. 先測試核心設定，再啟動監聽。語法檢查通過只代表核心接受這份設定，不代表遠端服務一定可連線。

六、日誌與客戶端介面：從現象找出設定問題

log 用來控制日誌輸出。常見的 loglevel 包括 debug、info、warning、error 和 none。平時可保留 warning，排錯時短暫調高至 info 或 debug；完成後請恢復設定，避免持續累積連線細節。

不同客戶端版本的選單名稱可能有所調整；表格用來對照概念，不代表所有版本的選單層級都相同。Android 端還要分清 VPN 接管與本機代理監聽：v2rayNG、v2flyNG 可透過系統 VPN 機制接收流量，不能直接套用桌面端系統代理的判斷方式。

桌面端啟用系統代理，只是通知遵循系統代理設定的應用程式使用指定入口，不保證所有應用程式都會經過核心。若日誌完全沒有該應用程式的連線紀錄，請先確認流量是否進入入站，不要直接修改遠端節點。接管方式可參閱使用說明；連線異常則可對照連線問題說明。

啟動後立即退出

優先檢查 JSON 解析錯誤、不支援的欄位、連接埠繫結失敗，以及資料資源缺漏。

本機連接埠可連線，但無法存取

接著檢查路由選擇、遠端連線、驗證、TLS 交握與 DNS 解析；「連接埠已開啟」不代表「代理可正常使用」。

只有部分網站異常

記下特定網域與時間，檢查是否符合封鎖或直連規則，再比較使用同一節點時的結果。

七、設定驗證順序：一次只改一個變數

命令列測試適合確認核心是否接受設定。以下兩條指令分別是 V2Ray 5.x 與 Xray 常見的命令格式，請只執行符合實際核心的一條；並自行確認執行檔路徑與目前工作目錄。若版本不同，請先查看該程式的說明輸出。

v2ray test -c config.json

xray run -test -config config.json

這類測試無法取代實際請求，也無法證明帳號、伺服器及網路路徑正常。測試通過後，再依序啟動核心、確認監聽、送出請求並檢查出口。測試時固定同一個目標與接入方式，才能清楚判斷是哪次修改產生效果。

1. 確認實際使用的檔案：檢查啟動參數指向哪個設定檔，避免修改了備份檔，實際執行的卻是另一份。
2. 確認語法與欄位：使用目前的核心測試設定。若失敗，先處理第一則明確錯誤；後續訊息可能只是連帶結果。
3. 確認入口：核對應用程式的代理類型與連接埠，確保請求確實進入預期的入站。
4. 確認規則：檢查標籤引用及規則順序；必要時暫時簡化為單一出口進行比對。
5. 確認遠端設定：恢復實際的代理設定後，再檢查伺服器位址、驗證方式與傳輸安全參數。
6. 恢復日常設定：取消暫時放寬的監聽範圍、恢復日誌層級，並保留能重現結果的修改紀錄。