V2Ray config.json 設定檔解析：inbounds、outbounds 與 routing 路由規則

1. config.json 頂層結構與請求流程

config.json 是核心讀取的設定檔名稱之一，並非固定的儲存位置。v2rayN 等客戶端可能會產生暫存的執行設定檔；手動修改產生的檔案，切換節點後可能就會被覆寫。請先確認目前使用的是 Xray 還是 V2Fly，再查看實際載入的設定檔與啟動記錄。

inbounds 和 outbounds 都是陣列，可分別設定多個入口與出口。routing 是物件，其中的 rules 才是規則陣列。tag 是設定檔內部用來識別項目的名稱，不是伺服器位址；規則透過 outboundTag 指定出站。

以下是僅供本機直連測試的完整基本設定。它會在迴路位址開啟 SOCKS 服務，所有未由規則處理的請求都會使用第一個出站 direct。此設定沒有遠端代理節點，也不會自動變更系統代理設定。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

2. inbounds：監聽位址、連接埠與本機協定

入站決定「應用程式如何將流量交給核心」。範例中的 127.0.0.1:10808 是本機 SOCKS 入口，不是遠端節點的連接埠。瀏覽器、命令列工具或其他支援 SOCKS 的程式，必須明確指定使用此入口，流量才會進入核心。

10808 和 10809 是本文採用的範例值，並非所有版本都固定使用的預設值。若直接將應用程式的 HTTP 代理指向 SOCKS 連接埠，會造成協定不相容。若客戶端提供混合入口，請以該入口實際支援的協定為準，不要只靠連接埠號碼推斷。

• listen: "127.0.0.1" 限制為本機連線，適合個人桌面環境測試。
• listen: "0.0.0.0" 會監聽所有 IPv4 網路介面。若要在區域網路中共用，還須設定驗證與防火牆；不應只改位址就直接對外開放。
• settings.udp: true 允許 SOCKS UDP 轉送，但應用程式必須支援 SOCKS5 UDP，後續出站與伺服器端也必須支援相應流量。
• 系統代理是作業系統層級的入口設定，TUN 則是透過虛擬網卡接管流量；兩者都不等同於一般 SOCKS 入站。

使用以下命令檢查應用程式能否透過範例入口發出 HTTPS 請求。Windows 可使用 curl.exe，macOS 和 Linux 可使用 curl。其中 socks5h 表示將目標網域交由代理端處理；代理端最後如何解析，仍取決於設定。

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

3. outbounds：遠端節點與傳輸參數

出站決定「核心要從哪裡連線至目標」。freedom 代表直連，blackhole 用於阻擋連線，vmess 則需要遠端伺服器配合。入站可以是 SOCKS，出站可以是 VMess；兩者不必同名，因為它們位於連線流程的不同環節。

以下範例用來取代頂層的 outbounds。192.0.2.10 是文件專用的示範位址，UUID 與網域也僅用於說明結構，無法直接連線。實際使用時，位址、連接埠、使用者識別碼、傳輸方式與 TLS 參數都必須依據已獲授權的伺服器設定填寫，不能只替換其中一個欄位。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "192.0.2.10",
            "port": 443,
            "users": [
              {
                "id": "b43b4b90-a710-4ee4-883d-b8c574099d11",
                "alterId": 0,
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "proxy.example.net"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心；v2rayN 可用的核心則依實際安裝與選擇而定。頂層結構相似，不代表擴充欄位完全相容，尤其是 VLESS 的特定安全組合。本文的 TCP 欄位寫法用於說明常見設定；實際欄位名稱與相容性，請依安裝的核心版本確認。

4. routing：規則順序、標籤引用與預設出口

路由並非將幾個網域分組後就會自動生效，而是依序比對規則。通常由第一條符合的規則決定出口；同一條規則中的不同條件必須全部符合，而同一條件陣列中的多個值則代表符合其中任一項即可。outboundTag 必須與現有出站的 tag 完全一致。

以下範例依賴上一節的 proxy、direct、block 三個出站。規則會先阻擋一個示範網域，再讓私有位址直連，最後將其他流量交給代理。兩個網域都只是規則範例，不代表建議實際造訪。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example.org"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

1. full:blocked.example.org 只會比對這個完整網域。雖然它也是 example.org 的子網域，但由於阻擋規則排在前面，因此會優先阻擋。
2. 私有網段規則會處理目標 IP 落在相應範圍內的請求。這並非完整列出所有特殊用途位址，也不會自動涵蓋 IPv6 本機位址。
3. domain:example.org 會比對該網域及其子網域，不等同於比對任意包含該字串的內容。
4. 最後的 network: "tcp,udp" 是本例的預設備援規則，必須放在具體規則之後，否則可能先攔截流量，導致前面的分流規則無法生效。

若沒有任何規則符合，通常會使用 outbounds 陣列中的第一個出站。第一節的第一個出站是 direct，第三節則改為 proxy，因此只調整陣列順序也可能改變預設行為。不能因為陣列中有代理節點，就認定所有請求都會經過代理。

5. dns、記錄與客戶端產生設定檔的界線

routing.domainStrategy 控制路由比對階段如何處理網域，不是 DNS 伺服器位址，也不是完整的 DNS 分流策略。AsIs 會盡量保留原始目標進行比對；IPIfNonMatch 會在網域規則未符合時嘗試解析，再繼續檢查 IP 規則；IPOnDemand 則可能在檢查 IP 規則時觸發解析。

以下範例只會新增內建 DNS 設定，不會自動變更作業系統的 DNS，也不保證每個應用程式的查詢都會進入核心。若應用程式在連線前已於本機完成解析，核心可能只會收到 IP；若透過代理協定傳送網域，最後由哪一端解析也可能取決於出站與伺服器設定。

{
  "dns": {
    "servers": ["localhost"]
  }
}

• 訂閱：是客戶端取得節點資料的入口，不是可直接寫入 outbounds 的通用核心欄位。
• 系統代理：讓遵循系統代理設定的應用程式使用本機入口，不代表所有處理程序都會被接管。
• TUN：由客戶端與其網路元件協同管理，不能將介面上的 TUN 開關直接對應成通用 JSON 欄位。
• 記錄：排除問題時，可暫時將 log.loglevel 改為 info，重新載入後重現一次；完成後再改回 warning。

閱讀客戶端匯出的設定檔時，先找到 inbounds[].port、outbounds[].tag 和 routing.rules，再追查 DNS 與傳輸細節。不要直接刪除不熟悉的管理入口或附加欄位，它們可能供客戶端統計、控制介面或執行階段功能使用。分享記錄前，也應移除使用者識別碼、訂閱網址與伺服器資料。

6. 修改設定後的檢查順序與常見問題

修改前先保留一份可還原的設定，每次只調整一個部分。先驗證 JSON 與核心欄位，再確認連接埠監聽狀態，最後測試遠端連線與規則比對。以下檢查命令適用於提供相應命令列介面的較新版本核心；實際參數請以已安裝程式的說明輸出為準。若設定由客戶端管理，請使用它實際載入的檔案路徑。

xray run -test -config config.json
v2ray test -c config.json

測試命令成功，不代表節點一定可用。它主要用來確認目前的核心能否接受設定，不能取代遠端驗證、TLS 交握與目標連線測試。若核心能啟動，但應用程式仍無法連線，請依序檢查「本機入口、遠端出口、路由結果」，逐步縮小問題範圍。