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

先釐清：用戶端設定、訂閱與核心設定

v2rayN 是桌面用戶端，負責管理節點、訂閱、路由與核心執行；實際接收流量並建立連線的是核心。用戶端儲存的介面偏好、訂閱網址與群組記錄，不等於核心啟動時讀取的 JSON。直接修改用戶端產生的暫存設定，可能在切換節點、更新訂閱或重新啟動核心後遭到覆寫。

本文採用 V2Ray 常見的傳統 JSON 設定結構。V2Ray 的不同設定格式，以及 Xray 的擴充欄位，不能只憑副檔名混用。尤其是 VLESS、傳輸層與安全層相關參數，應以目前執行的核心及其版本文件為準；同樣是 JSON，不代表欄位完全相容。

在 v2rayN 中，可先前往「設定」→「參數設定」確認本機監聽相關設定，再到「設定」→「路由設定」查看分流規則；不同版本的選單名稱可能有所調整，請以實際介面為準。核心名稱、啟動參數與設定檔位置，優先從啟動記錄確認；不要把訂閱檔當成完整的執行設定。

流量路徑：inbounds 接收、routing 選擇、outbounds 執行

inbounds 是入口陣列，用來描述核心在哪裡、透過什麼協定接收請求。例如，應用程式連線至本機 127.0.0.1:10808 的 SOCKS 服務後，流量才會進入這個入口。只啟動核心，不會讓所有程式自動使用它；系統代理、應用程式個別代理與 TUN 是不同的連線方式。

outbounds 是出口陣列，可包含遠端代理、直連與阻斷等出口。routing 則依據網域、IP、連接埠或入口標籤等條件選擇出口。標籤 tag 是設定內部的識別名稱，不是協定名稱，也不會自動建立同名出口。

• inboundTag：篩選流量來自哪個入口，參照入口的 tag。
• outboundTag：指定規則命中後使用的出口，必須與某個出口的 tag 完全相同。
• 規則依序檢查，最先命中的規則生效；若沒有規則命中，通常會使用 outbounds 陣列中的第一個出口。
• 同一條規則中，網域清單內的多個項目通常採「符合任一項即可」；網域、連接埠等不同條件欄位同時出現時，則必須全部符合。

完整範例：本機 SOCKS、直連與網域阻斷

以下是用來理解結構的完整傳統 JSON 範例：只在本機監聽 SOCKS，阻斷精確網域 example.com，其他透過此入口送入的請求則直接連線。範例不含 VMess 或 VLESS 伺服器參數，因此即使成功瀏覽網頁，也只能證明本機入口與直連路徑可用。

{
  "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": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:example.com"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

JSON 物件使用大括號，陣列使用方括號，字串則使用英文雙引號。為減少解析差異，範例不使用註解或尾隨逗號。語法正確只是第一步，欄位名稱、欄位型別與協定參數仍須由核心驗證。

入口與出口：監聽位址不等於伺服器位址

入口的 listen 是本機繫結位址；遠端代理伺服器的位址則屬於相應出口的協定設定。把伺服器網域填入本機監聽位址，無法建立代理連線，反而可能導致入口無法繫結。127.0.0.1 僅允許本機存取；改成 0.0.0.0 則會開放至所有 IPv4 網路介面，需一併評估驗證機制、防火牆與區域網路的存取範圍。

udp: true 表示 SOCKS 入口允許 UDP 轉送，不代表所有應用程式的 UDP 流量都會經由此入口。應用程式須支援 SOCKS5 UDP 關聯，後續出口與網路路徑也須支援 UDP。只在系統中設定 HTTP 代理，不會自動將 UDP 請求送入這個 SOCKS 入口。

實際新增 VMess 或 VLESS 出口時，還需要伺服器位址、連接埠、使用者識別碼與相符的傳輸設定。VMess 常見設定使用 settings.vnext；VLESS 也有對應的使用者與伺服器結構，但兩者的驗證方式不同，不能只修改 protocol 字串。啟用 TLS 時也須確認伺服器名稱；伺服器連接埠為 443，不代表設定必然已啟用 TLS。

• 遠端節點資訊應由服務提供者或有效訂閱取得，不要根據連線失敗的現象猜測使用者識別碼。
• 核心支援某種協定，不代表支援該協定所有較新的傳輸與安全性擴充。
• v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；轉移節點後仍須檢查具體參數的相容性。

路由規則：順序、網域比對與預設出口

範例中的 full:example.com 只會精確比對這個網域，不會自動涵蓋 www.example.com。若要涵蓋網域及其子網域，傳統路由規則可使用 domain:example.com。請勿將這種網域比對誤認為 URL 比對：路由通常無法依網頁路徑 /account 區分同一網站的不同頁面。

domainStrategy: "AsIs" 表示路由階段不會為了 IP 規則主動解析網域。這不代表整個連線過程都不會進行 DNS 查詢：出口實際連線至目標時，仍可能需要解析。使用 IPIfNonMatch 時，網域規則未命中後可解析 IP，再嘗試比對；使用 IPOnDemand 時，遇到需要 IP 的規則就可能觸發解析。

規則排序應由具體到廣泛。若第一條規則已將某個入口的所有流量導向直連，後續針對同一入口的網域阻斷規則就不會執行。使用 geoip:、geosite: 規則時，也須確認相應資料檔可用；資料缺失與網路無法連線是兩種不同錯誤。

DNS 與記錄：定義解析器不代表接管所有查詢

dns.servers 用來為核心內建 DNS 指定上游解析器，範例使用 1.1.1.1。一般 IP 位址的寫法通常代表傳統 DNS 查詢，而非加密 DNS。能否連線以及查詢如何送出，也會受到網路與相關設定影響；不能只憑這個欄位判斷解析路徑。

應用程式也可能先透過作業系統 DNS 取得 IP，再將 IP 傳給 SOCKS。此時核心收到的目標不是原始網域，前述網域規則就可能無法命中。嗅探可在適用的協定中協助辨識網域，但無法保證還原所有請求的原始網域，也不會因為設定內建 DNS 就自動具備這項能力。

1. 先確認輸入內容。請求記錄顯示的是網域還是 IP？使用 SOCKS 的應用程式是否啟用了由代理端解析網域？
2. 再確認失敗階段。網域解析失敗、連線逾時與 TLS 交握失敗發生在不同階段，不能一概歸因於 DNS。
3. 短暫提高記錄層級。將 loglevel 從 warning 改為 info 或 debug，重現一次問題後再恢復，避免持續記錄大量連線細節。
4. 視需要設定記錄檔。access 與 error 可指定存取記錄與錯誤記錄的路徑；目標資料夾必須存在，執行帳戶也須具備寫入權限。

驗證步驟：先檢查語法，再確認實際流量

建議將範例另存為 config.json，先在獨立測試環境驗證，不要覆蓋用戶端目前使用的設定。支援相應命令的 V2Ray 可使用以下方式測試設定；不同發行版本的命令列入口可能不同，若出現未知命令，請先執行 v2ray help 查看本機支援的參數。

v2ray test -c config.json

設定測試通過，不代表連接埠一定能成功繫結、遠端一定可連線，或路由符合預期。啟動核心後，再使用明確指定代理協定的請求進行驗證。以下命令適用於已安裝 curl 的環境；Windows 終端機可使用 curl.exe，避免命令別名造成差異。

curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 https://example.com/

--socks5-hostname 會將目標網域交給 SOCKS 代理處理，適合驗證本例的網域規則。預期結果是此請求無法正常取得網頁，同時記錄中應能看到請求進入核心。實際錯誤訊息取決於核心與 curl 版本，不能只看一則錯誤就判斷是哪條規則生效。

1. 驗證阻斷。保留完整設定中的 full:example.com 規則，執行上述命令並查看記錄。
2. 驗證直連。將測試副本的 rules 改為空陣列 []，重新啟動核心後再執行相同請求；若網路本身可連線至目標，應由第一個直連出口建立連線。
3. 確認入口。若記錄中完全沒有請求，請檢查監聽位址、連接埠與應用程式設定，不要繼續修改路由。
4. 還原環境。關閉獨立測試核心，還原原始設定，再啟動用戶端，避免多個程序爭用同一個連接埠。

常見問題：啟動成功，但分流沒有變化

閱讀設定時，可固定檢查三個問題：應用程式是否進入預期入口、請求是否命中預期規則，以及選定的出口是否具備正確參數。將解析、路由與連線分開驗證，通常比同時調整多個選項更容易找出原因。