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

一、先區分用戶端設定與核心設定

v2rayN、v2rayNG、v2flyNG 都是用戶端，不等同於核心本身。用戶端負責管理訂閱、節點與操作介面，再將相關設定轉換為核心可讀的格式。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；v2rayN 的執行設定則須依目前選用的核心判斷。不同核心與版本支援的欄位範圍不盡相同，不能一概而論。

本文採用 V2Ray 傳統 JSON 設定中的常見欄位。查看實際設定時，請先確認它是核心設定，還是用戶端自己的設定檔。介面中儲存的訂閱群組、視窗選項與更新偏好，不一定會出現在核心的 config.json 中；反過來說，執行設定中的本機連接埠也可能由用戶端自動產生。

這條流程描述的是明確使用本機代理的應用程式。只啟動核心，不會自動讓所有程式連上本機連接埠。系統代理、應用程式內代理與 TUN 的接入方式各不相同；本文先以 SOCKS 或 HTTP 入站為例，避免將接入範圍問題誤認為路由錯誤。

二、完整的 config.json 範例

以下是用來解析設定結構的完整範例。它會監聽兩個回環位址連接埠，拒絕目的網域完全符合 example.org 的請求，其餘流量則直接連線。example.org 是文件示例網域，並非可用節點。設定中沒有 VMess 或 VLESS 遠端出站，因此不會將流量轉交給代理伺服器。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1"
    ]
  },
  "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.org"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks-in",
          "http-in"
        ],
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

標準 JSON 的鍵名與字串都必須使用雙引號，陣列和物件的最後一個項目後方不能多加逗號。程式碼區塊不含註解，可作為獨立範例閱讀；至於能否由特定核心載入，仍應使用該核心的設定檢查指令確認。

三、inbounds：監聽位址、連接埠與入口標籤

inbounds 是陣列，因為同一個核心程序可以接收多個入口。每個入口的 protocol 決定接收的協定，而 settings 內的欄位也會依協定而異。本例 SOCKS 入口中的 udp: true 表示允許 SOCKS UDP 轉送，不代表所有應用程式的 UDP 流量都會自動由核心接管。

listen 與 port 共同決定監聽位置。將 127.0.0.1 改為 0.0.0.0 會擴大可接入範圍，其他裝置也可能因此連上代理連接埠。本例使用未設定驗證的 SOCKS，因此不應為了方便連線就任意擴大監聽範圍；若確實需要區域網路存取，請一併規劃驗證機制與防火牆設定。

tag 是設定內部用來引用的識別標籤，不是伺服器位址，也不會自動建立新的連接埠。第三條路由規則中的 inboundTag 引用的正是這裡的兩個字串。變更入口標籤時，也必須同步修改對應規則，並確認大小寫與連字號完全一致。

四、outbounds：出站類型與預設去向

outbounds 定義連線離開核心時的處理方式。freedom 代表由本機直接連線至目標，blackhole 則用來拒絕流量。這裡的 direct 與 block 只是自行命名的標籤；真正決定出站行為的是 protocol，不是標籤看起來像什麼。

在此使用的一般路由機制中，若沒有規則符合，便會使用第一個出站。因此，調整 outbounds 陣列順序不只是整理顯示順序，也可能改變預設流向。本例另外為兩個已知入口加上最後一條直連規則，讓預設行為更容易辨識。

若要連接遠端節點，必須新增參數正確、且協定受目前核心支援的代理出站，再將相關規則指向該出站。VMess 與 VLESS 的使用者欄位、傳輸層及安全性設定並不相同，不能只修改 protocol 字串就當作轉換完成。請以可信任訂閱匯入後產生的設定為參考，逐一核對伺服器、連接埠、使用者識別碼與傳輸參數。

五、routing：規則順序與比對條件

routing.rules 是依序排列的規則陣列。處理每個請求時，核心會由前往後檢查，遇到符合的規則便採用指定出站，不會繼續執行後面的所有規則。若將涵蓋範圍較廣的規則放在前面，後面的細部規則可能永遠不會命中。

1. 先比對精確網域。full:example.org 只會比對完整網域，不包含其子網域。只有在請求附帶網域，或核心取得網域資訊時，這條網域規則才能參與比對。
2. 接著比對指定 IP 網段。本例列出回環位址與三個常見的私有 IPv4 網段，符合時會走 direct。這不是完整的特殊用途位址清單，也未涵蓋 IPv6 私有或鏈路本地範圍。
3. 最後比對兩個本機入口。來自 socks-in 或 http-in，且網路類型為 TCP 或 UDP 的請求，會交由 direct 處理。

在同一條規則中，inboundTag 陣列裡的兩個入口表示「任一入口符合即可」；不同條件欄位通常則必須同時成立。因此，第三條規則的意思不是「來自這兩個入口，或是 TCP」，而是「來自這兩個入口之一，而且網路類型符合」。

domainStrategy: "AsIs" 表示路由比對不會為了符合 IP 規則而主動將網域解析成 IP。若應用程式交給核心的是網域，第二條私有位址規則不會只因該網域最後可能解析為私有位址就命中；若傳入的是 IP，則可直接比對網段。這個選項控制的是路由階段的處理方式，不代表整個連線過程都不會進行 DNS 查詢。

六、dns 與 log：別混淆解析與分流

範例中的 dns.servers 設為 1.1.1.1，這是核心內建 DNS 的伺服器設定，不會自動取代作業系統或瀏覽器自己的解析設定。單是加入這個欄位，也無法保證所有解析請求都會經過代理。哪些模組會使用內建 DNS、解析連線會走哪條路徑，須視具體核心與相關策略而定。

• 路由策略決定網域或 IP 如何參與比對。本文使用的 AsIs 不會為 IP 路由規則額外解析網域。
• 出站連線仍可能需要解析。freedom 最終必須建立連線，使用哪種解析路徑仍會受出站策略與核心實作影響。
• 應用程式可能自行解析。由應用程式內的安全 DNS 或系統解析產生的請求，不會因設定中有 dns 就必然交由核心接管。
• 請依實際網路環境選擇位址。範例解析器僅用於說明設定結構，不代表在所有網路環境中都能連線或適合使用。

log.loglevel 設為 warning，適合先查看警告與錯誤。排查規則時可暫時改為 info；需要更詳細資訊時，再考慮使用 debug。日誌層級不是日誌檔案路徑，也不保證所有版本輸出的格式相同。分享日誌前，請先移除訂閱網址、使用者識別碼、伺服器位址與存取目標等敏感資訊。

七、修改、驗證與還原的操作順序

用戶端可能在切換節點、更新訂閱或重新啟動時重建執行設定。直接修改自動產生的檔案，內容可能在下次操作時遭到覆蓋。請先釐清目的是「查看產生的設定」還是「使用自訂設定」，再決定要從用戶端介面修改，或使用用戶端提供的自訂設定入口。

1. 保留可還原的副本。備份原始設定，並記下目前的核心類型、設定檔位置與監聽連接埠；請勿將訂閱網址記在公開筆記中。
2. 每次只修改一個項目。例如只新增一條網域規則，暫時不要同時更換 DNS、連接埠與遠端節點，以免無法判斷是哪項變更造成影響。
3. 先檢查語法與設定。標準 JSON 檢查可找出逗號或引號錯誤；核心檢查則可進一步偵測不支援的協定、欄位類型及部分引用問題。
4. 接著啟動並確認監聽狀態。若提示位址遭占用，先確認 10808、10809 是否已由用戶端使用，避免同時執行兩份使用相同連接埠的設定。
5. 最後驗證實際連線路徑。先確認應用程式確實連上本機入口，再觀察目標請求是否使用預期的出站；若失敗，請還原上一份可用設定。

常見的核心命令列檢查方式如下，擇一使用即可，請勿將兩種方式連續套用在不同核心上。可執行檔名稱與呼叫方式須依本機系統調整；若目前版本不認得該選項，請以其 help 輸出為準。檢查通過只代表設定可被接受，不表示遠端伺服器可連線或流量分流符合預期。

v2ray test -c config.json

xray run -test -config config.json

桌面系統若已安裝 curl，可使用以下明確指定代理的請求測試本例。第一條讓 SOCKS 代理接收網域，適合檢查 full:example.org 拒絕規則；第二條透過 HTTP 入口存取另一個文件示例網域，應採直連。執行這兩條命令前，核心必須已正常啟動，且連接埠與本例一致。

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

curl --proxy http://127.0.0.1:10809 --connect-timeout 10 https://example.com/

第一條預期會連線失敗，但單看錯誤訊息無法分辨是拒絕規則生效、入口未啟動還是網路故障；第二條能否成功也取決於實際網路。請搭配核心日誌判讀命令結果，不能只因網頁未開啟就認定某條規則已命中。

八、閱讀設定時的常見問題