V2Ray 設定檔參考

JSON 結構總覽

設定物件與連線路徑

V2Ray 設定檔的頂層是 JSON 物件。入站負責接收應用程式連線，出站負責傳送連線，路由負責在兩者之間選擇目的地，DNS 負責設定範圍內的網域解析，策略則控制部分連線限制與統計功能。這些模組不是依檔案位置逐一執行的指令碼，而是由核心讀取後建立的執行結構。理解設定時，應追蹤一項請求經過哪個入站、符合哪條規則，最後交由哪個出站處理，而不只是確認某個欄位是否存在。

圖形用戶端與核心也應分開理解。v2rayN、v2rayNG 與 v2flyNG 提供節點編輯、訂閱管理及代理開關；實際建立連線的是背後的核心。用戶端介面中的單一選項可能會產生多個 JSON 欄位，也可能只修改作業系統設定。系統代理開關通常屬於後者，不能因為設定檔中有 HTTP 入站，就認為瀏覽器已經使用它。以下先以本機 SOCKS 入站與直連出站建立完整的基準設定，方便確認基本連線路徑。

{
  "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": []
  }
}

型別、陣列與標籤參照

JSON 對欄位型別有明確要求。此範例中的連接埠是數字，開關使用布林值，標籤與位址使用字串，多個入站與出站則放在陣列中。字串必須使用雙引號，最後一個元素後不能多加逗號，標準 JSON 也不接受註解。編輯器能開啟檔案，不代表核心就能解析；語法錯誤與欄位含義錯誤是不同層次的問題。先確認括號、引號與型別，再檢查協定是否支援對應設定，可避免把簡單的語法問題誤判為網路故障。

標籤是模組之間的連結依據。路由中的出站標籤必須與出站物件的標籤完全一致，大小寫不同也可能導致參照失敗。標籤最好使用簡短、明確且唯一的名稱，例如直連、阻斷與遠端代理各自採用不同標識。不要只憑陣列中的顯示順序判斷標籤含義；通常未符合路由規則的連線會使用第一個出站，因此調整出站順序本身就可能改變預設行為。複製片段時，應一併核對參照與目標。

合併片段並儲存變更

合併設定時，每個頂層欄位只保留一份。已有出站陣列時，應新增或修改其中的物件，而不是再寫一個同名陣列；不同解析器對重複鍵的處理方式可能不同，容易造成介面看似已儲存，實際上卻只讀取後面那份內容。物件內的欄位也應放在所屬層級，例如傳輸設定屬於相應的出站，不應放在頂層路由物件中。遇到選用欄位時，先保留核心預設值，只針對確實需要的行為新增設定，不必把文件中的所有參數都填進檔案。

桌面端建議優先使用 v2rayN 管理一般節點，但不要直接覆寫執行時產生的暫存設定檔。下次選擇節點、更新訂閱或重新啟動服務時，用戶端可能會重新產生檔案。應先確認自己是在編輯自訂設定檔，還是修改用戶端持久保存的設定。測試前先保留一份可正常運作的設定，記錄變更欄位與預期結果；測試後檢查日誌中的實際監聽連接埠及所選出站。設定結構穩定後再加入路由與 DNS，問題範圍會更容易縮小。

inbounds 入站設定

監聽位址、連接埠與應用程式接入

入站定義核心在哪裡接收連線，以及使用什麼協定解析連線。一般桌面使用情境中，SOCKS 與 HTTP 是常見的本機入口。應用程式必須主動將請求送至此入口，或透過系統代理、虛擬網卡等機制轉送。監聽位址設為本機迴圈位址時，只接受本機連線；設為所有網卡位址則可能讓區域網路裝置也能存取。後者還涉及防火牆、驗證與網路邊界，不能只為了故障排除就擴大監聽範圍，尤其是在公用網路或多人共用的裝置上。

連接埠必須與應用程式設定的代理連接埠一致，且不能已被其他程式占用。連接埠占用通常會在啟動日誌中顯示為繫結失敗，此時更換節點無法解決問題。可以先關閉另一個代理用戶端，或在圖形設定中調整本機連接埠，再讓應用程式同步使用新連接埠。SOCKS 連接埠與 HTTP 連接埠不能任意互換：將 HTTP 請求送到只接受 SOCKS 握手的入口，會在連線初期失敗，瀏覽器可能只顯示代理伺服器異常。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

驗證、UDP 與網域資訊

本機單一使用者情境通常會使用不需驗證的 SOCKS 入站，但這不代表任何監聽位址都適合關閉驗證。若要分享給其他裝置，應一併評估哪些裝置能存取連接埠、用戶端協定是否支援所需驗證，以及系統防火牆是否限制來源。驗證只是其中一個環節，不能取代合理的監聽邊界。HTTP 入站的設定結構與 SOCKS 入站不同，不能直接複製同一組驗證欄位；應依目前協定及核心支援的格式設定，並分別確認應用程式能否完成交握。

SOCKS 入站中的 UDP 開關，只代表此入口允許處理相應的 UDP 請求，不保證整條路徑都能傳送 UDP。應用程式是否使用 SOCKS 的 UDP 關聯、遠端協定與服務是否支援、出站是否允許，以及防火牆是否放行，都會影響結果。以一般瀏覽器的系統代理進行測試，也無法涵蓋所有 UDP 行為。若網頁能開啟，但某類應用程式失敗，應先區分失敗的是 TCP 連線還是 UDP 流量，再判斷是否需要變更接入方式，避免把所有現象都歸咎於節點品質。

由誰解析網域也與入站方式有關。應用程式可以將網域交給 SOCKS 入口，也可以先自行解析成 IP 再建立連線；HTTP 代理通常能從目標資訊取得網域。若路由依賴網域規則，而入站收到的只有 IP，結果可能與預期不同。協定嗅探可以從部分可辨識的流量中還原目標網域線索，但不是所有流量都包含這類資訊。啟用嗅探也可能影響目標選擇，應先確認需求再使用，不要把它當成保證網域規則命中的萬用選項。

v2rayN TUN 模式與系統代理

v2rayN TUN 模式與一般本機入站處理的是不同層面的問題。系統代理主要為遵循系統設定的應用程式提供代理入口；TUN 模式則透過虛擬網路介面接收符合其路由範圍的流量，適用於部分不讀取系統代理設定的應用程式。這涉及虛擬網卡、路由與權限，不能簡單視為在入站陣列中新增一個欄位。用戶端使用的接入方式與設定檔產生方式可能因平台而異，手動核心設定與用戶端 TUN 設定應分開查閱。

切換 TUN 前，先確認一般代理路徑可正常運作，再檢查所需權限及其他網路軟體是否有衝突。主要接管方式一次保留一套，避免多個虛擬網卡或代理程序同時修改路由，導致流量迴圈或解析路徑不明。關閉 TUN 後若存取仍異常，請檢查系統代理是否還留有設定、虛擬介面是否已還原，以及應用程式是否快取代理設定。瀏覽器與終端機的不同接入方式，可參閱系統代理未生效的分流排查；不要只憑單一應用程式的結果，就判定整個入站失效。

outbounds 出站設定

預設出站與連線目標

出站描述連線離開核心的方式。直連出站由本機直接連線至目標，阻斷出站會終止符合條件的請求，代理出站則先連線至遠端服務，再由遠端處理目標連線。出站陣列可以同時包含這些物件，實際使用哪一個由路由決定。常見設定會將代理物件放在第一位，讓未符合特殊規則的連線走代理；本頁第一章的基準設定則刻意將直連放在第一位，只用於驗證本機接入。複製範例前，先確認預設出站，避免把測試結構的設定誤當成遠端代理設定。

遠端位址、遠端連接埠、使用者識別碼與傳輸方式應整體核對。位址正確但連接埠錯誤，通常無法連上服務；網路交握成功但使用者參數不一致，可能在協定階段遭拒；使用者參數正確但傳輸層設定不同，也無法建立預期連線。用戶端顯示的節點名稱只是別名，無法證明這些欄位一致。應透過節點編輯介面核對服務提供的完整參數，尤其留意匯入後是否遺失傳輸路徑、服務名稱或安全設定。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none",
                "level": 0
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

VLESS 協定與傳輸、安全層

在 VLESS 協定的使用者設定中，常見的加密欄位會使用範例中的值，但這不代表整條連線沒有安全層。協定、傳輸與傳輸安全是三個不同面向：協定決定代理請求如何表示，傳輸決定這些內容透過哪種連線承載，安全層則決定該連線如何受到保護。以上範例採用 TCP 與 TLS，只用於展示欄位關係，並非實際服務。若服務採用其他傳輸或安全方案，必須依服務參數修改，不能把所有方案的欄位都堆在同一個物件中。

V2Ray 協定選擇首先受伺服器端設定與目前核心支援範圍限制，而不是在用戶端選單中自由更換名稱。VMess、VLESS、Trojan 與 Shadowsocks 的驗證及參數結構各不相同，不能只改協定欄位就互相轉換。VMess 還需留意裝置時間等條件；不同協定的安全設計也無法用單一設定項概括。若要比較基本差異，可閱讀VMess 與 VLESS 的差異，再依實際節點參數決定用戶端中的選項。

TLS 的服務名稱必須與憑證及伺服器端設定相符。遠端連線位址可以是網域或 IP，但連線位址與用於憑證驗證的名稱並非總是同一概念。瀏覽器能開啟某個位址，也不能證明該位址提供對應的代理協定。遇到憑證錯誤時，請檢查系統時間、名稱與憑證鏈，並確認參數來源；不要先關閉憑證驗證來消除錯誤提示，這會掩蓋真正的設定問題，也會削弱原有的連線驗證機制。

核心相容性與參數保留

Xray 與 V2Fly 共用部分設定概念，但不能因此推斷所有欄位、傳輸方式與擴充功能都通用。v2rayN 可選擇核心，v2rayNG 與 v2flyNG 則面向不同核心體系；切換前應核對節點所需功能。若出現未知欄位、協定不支援或啟動失敗，應先確認目前核心的支援範圍，而不是反覆修改遠端位址。生態系的對應關係可參閱Project V、V2Fly 與 Xray 的關係。

匯入既有節點後，優先保留用戶端能辨識的原始參數，逐項確認後再進行自訂。部分介面會依傳輸類型隱藏不相關的輸入欄位，但欄位隱藏不代表先前填入的內容一定會套用到最終設定。可以查看產生的設定檔中的出站物件，確認參數位於正確層級。每次測試只變更一項設定，並保留失敗日誌與時間點；若同時更換協定、傳輸與核心，即使最後恢復連線，也很難判斷是哪項調整發揮作用。

routing 路由規則

規則順序與比對條件

路由會將連線特徵與出站標籤連結起來。常見特徵包括目標網域、目標 IP、目標連接埠、網路類型與入站標籤。規則通常依序檢查，最先符合的規則決定連線去向，因此明確的例外規則應放在範圍較廣的規則之前。若沒有符合任何規則，連線通常會交給第一個出站。理解預設出站與規則順序，比記住更多欄位更重要：排在前面的廣泛規則可能讓後面的精細規則永遠無法處理相應請求。

同一條規則中的不同類別條件通常需要同時符合，而同一類別陣列中的多個值則代表可選的比對條件。例如同時設定入站標籤與目標網域，表示只處理由該入站收到的相應網域請求，而不是符合其中任一條件就生效。不同用途不應硬塞在同一個物件中；需要表達兩種獨立情境時，應拆成兩條規則。拆開後也更容易記錄每條規則的目的，並透過日誌找出哪項設定改變了出站。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:blocked.example.com"
        ],
        "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.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

網域規則與位址規則的界線

範例中的完整網域比對只針對指定名稱，而網域比對則適用於相應網域及其子網域。第一條規則先阻斷特定子網域，再允許同一主網域下其他符合條件的請求直連，示範精確規則優先的效果。不要以一般字串的直覺取代各前綴的語意，尤其是正規表示式：範圍過寬的表示式可能意外符合不相關網域，也會增加維護成本。先使用明確的完整網域或網域後綴，確實需要表達複雜規律時再使用正規表示式，並準備正反兩類測試目標。

私有位址規則只會比對實際進入路由判斷的目標 IP。若請求攜帶的是網域，而路由策略未進行解析，只靠私有 IP 網段規則未必能辨識該網域最終指向的內部服務。可以為明確的內部網域新增網域規則，或依需求選擇會參與 IP 判斷的網域策略。另一方面，網域可能回傳多個位址，IPv4 與 IPv6 的結果也可能不同，因此單次測試符合規則，不代表所有位址類型及解析結果都會有相同去向。

路由的網域策略與直連出站的網域策略作用位置不同。路由策略主要控制比對規則時是否需要解析網域；直連出站策略則主要影響實際直連時的位址選擇。將兩者混為一談，容易誤以為「已設定解析策略，但路由仍未符合」。採用按需解析時，也應了解觸發條件與目前核心的實作方式，避免無意間增加 DNS 查詢。能以網域準確描述的規則，不必為了符合 IP 而強制解析所有請求。

規則資源與可驗證的調整

部分路由設定會引用地理位置的 IP 或網域分類資源。這些引用仰賴用戶端提供資源檔、資源名稱與更新方式，並非寫入 JSON 就會自動存在。資源缺失可能造成啟動錯誤，分類內容不同也會改變比對範圍。本頁使用明確的網域與網段，方便獨立理解；若要匯入外部規則，應先查看所需資源及其是否適用於目前核心，再檢查產生的設定檔中實際引用內容，不要只憑規則標題判斷相容性。

修改路由後，建議分別選擇一個預期直連、一個預期代理及一個預期阻斷的目標進行驗證，並檢查連線日誌記錄的出站標籤。瀏覽器快取、既有長連線及應用程式自行解析，都可能讓結果看起來沒有變化；必要時請關閉舊連線或重新開啟應用程式。若發生全面斷線，先移除最後加入的廣泛規則，再核對標籤拼寫與預設出站。規則數量不是品質指標，少量、用途明確且可測試的規則更適合長期維護，也更容易移轉至其他用戶端。

dns 網域解析設定

先確認解析發生的位置

DNS 問題應先依解析位置分類。應用程式可能使用系統解析器，也可能內建自己的解析方式；本機代理可能在核心收到網域後進行解析；遠端服務也可能依網域連線至目標。這些路徑可能同時存在。頂層 DNS 物件只控制使用核心 DNS 功能的相關請求，不會自動接管裝置上所有程式的網域查詢。因此「修改 DNS 後瀏覽器結果沒變」並不能直接證明設定失效，應先確認瀏覽器的請求是否經過該解析路徑。

連線目標的解析與代理伺服器位址的解析也應分開看待。出站必須先找到遠端服務；若遠端位址本身是網域，啟動或建立連線時就可能需要解析。之後存取的網站網域，則可能在其他位置解析。若要求所有查詢都經過尚未建立的代理連線，可能形成啟動相依迴圈。規劃解析路徑時，應明確了解遠端服務位址如何解析、解析伺服器如何連線，以及代理失效時是否仍有必要的解析路徑可用，而不是只選擇一個看起來熟悉的伺服器名稱。

{
  "dns": {
    "hosts": {
      "service.example.com": "192.0.2.10"
    },
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

靜態對應、伺服器與位址類型

這個片段以本機系統解析器建立基準，並示範靜態網域對應的結構。範例位址是文件專用位址，不能作為真實服務目標；測試真實網站時，應移除此教學對應。靜態對應適合已知目標位址且需要固定解析結果的情境，不適合長期取代變動頻繁的服務解析。網域對應的位址可能因地區、負載與服務遷移而改變；固定使用舊位址可能導致連線失敗，也可能讓請求避開正常的位址選擇機制。

解析伺服器可以使用系統解析，也可以採用核心支援的其他形式。不同形式可能使用不同協定、連接埠與路徑，不能只看伺服器位址就判斷是否經過代理。設定以 HTTPS 為基礎的解析服務時，也要考慮該服務網域本身的解析與連線路徑。部分核心會區分本機直連查詢與可交由路由處理的查詢方式，實際行為應以所用核心為準。先用簡單且確認可連線的解析方式驗證，再新增網域分流規則，可降低多項相依條件同時失敗的風險。

位址類型策略會決定查詢或接受哪些 IP 類型，但無法讓原本不支援 IPv6 連線的網路突然具備相應能力。只選用某種位址類型後，若目標沒有相應記錄，也可能失去可用位址。若部分網站連線緩慢、解析成功卻逾時，應檢查取得的位址類型是否符合本機、遠端服務及最終出站的連線能力。調整前先記錄解析結果，調整後以相同網域重複觀察；不要只憑一次成功存取，就斷定某種位址類型在所有情境下都更適合。

網域分流、快取與路由協作

較複雜的 DNS 設定可以為部分網域指定解析伺服器，並控制回退行為。指定伺服器回應失敗、傳回空結果或遭到過濾後，是否繼續查詢其他伺服器，會影響最終結果與存取速度。這裡應同時確認核心支援的伺服器物件欄位與回退邏輯，不能把「優先使用」解讀成「只允許使用」。若設定了位址範圍限制，也應確認目標的正常結果是否可能超出範圍，否則有效回應可能會被視為不符合條件。

DNS 與路由之間應保持語意一致。若希望某個內部網域直連，解析路徑就應能取得內部位址，路由也要能辨識相應名稱或位址；若希望某類連線經由遠端服務，也要確認解析位置不會破壞服務預期。不要把 DNS 伺服器選擇、路由出站選擇與瀏覽器的安全解析設定視為同一個開關。三者作用層面各不相同；排除問題時，可以先固定其中兩項，只調整另一項，再依日誌與應用程式行為確認變化。

快取可能讓變更後的結果暫時看不出來。快取可能位於瀏覽器、作業系統、核心或遠端解析器，重新啟動一個程序不一定能清除所有層級。驗證時先確認設定已重新載入，再關閉舊連線，必要時重新啟動目標應用程式；同時區分解析失敗、連線逾時與憑證錯誤。若只有一個應用程式異常，先檢查它是否啟用了獨立解析方式。使用虛擬網卡時，也要確認 DNS 是否由用戶端另外接管，避免反覆修改未參與實際請求的頂層物件。

policy 策略與統計

使用者等級與連線時間限制

策略模組用來定義部分連線行為與統計開關，不負責決定請求要經過哪個節點。常見的層級方式是依使用者等級設定策略，並為整個系統設定統計選項。使用者等級是設定檔中的參照，不是帳號權限、付費級別或節點品質評分；只有在協定對應的使用者物件支援並使用此等級時，相關策略才會生效。若設定檔中寫了某個等級，卻沒有任何相關使用者參照，就不能因此期待所有連線自動套用該組參數。

建立連線、閒置保持與半關閉等待是不同階段。交握時間限制用來限制建立連線時的等待時間，閒置時間限制則針對沒有活動的連線，單向關閉後的等待時間則用來處理另一方向尚未傳完的資料。縮短這些數值可能加快資源回收，也可能讓慢速網路、長輪詢或長時間閒置的應用程式頻繁斷線。調整參數應以具體症狀為依據，不要把所有逾時值一起調低，再把因此產生的斷線誤判為遠端服務不穩。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": true,
        "statsUserDownlink": true
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "stats": {}
}

統計開關、身分與讀取方式

範例中的時間欄位依常見核心語意使用秒，數值僅用於說明結構，並非適用於所有網路的建議組合。等級物件的鍵是字串，使用者物件中的等級通常是數字，兩者在設定檔中的型別不同。先保留用戶端預設策略，確實遇到可重現的逾時問題後再調整。某些緩衝區或連線管理欄位的支援範圍、單位與預設值會因核心而異，不能把網路上的整套參數直接當成通用最佳化方案。

啟用統計模組與能讀取統計結果是兩回事。空的統計物件用來啟用模組，策略中的開關則決定要收集哪些方向或物件的資料，但不會自動在介面上產生圖表。讀取結果還需要用戶端具備對應支援，或設定核心支援的統計介面。用戶端本身顯示的速度或流量，也可能採用另一套擷取方式。因此介面沒有顯示使用者統計，不一定代表整個統計模組失效；應先確認預計讀取哪類資料，以及對應介面是否實際存在。

使用者層級統計通常還需要使用者物件中可識別的身分欄位及協定支援，只有等級開關可能不足以產生預期項目。本機一般 SOCKS 入口不會因為設定了等級零，就自動取得遠端使用者身分。入站、出站與使用者統計的觀察位置也各不相同，不能不加區分地相加並視為實際網路用量。封裝額外負擔、不同傳輸層與多條連線都會影響比較結果；統計較適合觀察趨勢與追查流量來源，而非直接對應伺服器端帳單。

統計介面與資源界線

若需要手動設定管理介面，必須閱讀目前核心的介面模型與服務清單，並將監聽範圍限制在必要界線內。介面入口、對應路由與服務名稱通常需要協同設定，單獨新增一段策略並不會建立可存取的管理通道。不要為了讓統計工具連線，就將介面開放至所有網卡；這類通道不應與一般代理入口混淆。若圖形用戶端已管理相關介面，優先使用現有的資訊顯示，避免另建入口而與既有連接埠衝突。

策略變更也應以可重複的實際操作驗證。針對閒置斷線，記錄應用程式建立連線後的靜止時間與斷線時間；針對交握失敗，記錄是否已連上遠端連接埠、是否進入安全層或協定階段。只有證據顯示問題出在相應階段，才值得修改相關策略。若實際問題是 DNS 失敗、路由指向阻斷或節點參數錯誤，增加逾時只會讓使用者等更久，無法修復連線。若資源使用量異常，也應先檢查連線數量的來源及流量迴圈。

測試完成後，應關閉不再需要的診斷開關。詳細日誌與大量統計項目會增加持續觀察的成本，保存的資料也可能包含瀏覽習慣。設定手冊中出現的模組不必全部長期啟用；穩定運作時，只保留用途明確的選項即可。對於行動裝置，也應區分策略造成的連線回收與系統背景限制：應用程式切換至背景後若遭系統暫停，單靠延長核心閒置時間無法解決，還需檢查應用程式權限與電池管理設定。

訂閱與用戶端設定檔產生

訂閱內容不等於完整設定檔

訂閱主要用來向用戶端提供節點資訊；完整的執行設定通常由用戶端依據目前節點、本機入口、路由、DNS 與其他設定產生。不同訂閱格式能承載的資訊範圍不同，有些只描述節點，有些則包含更多設定結構；用戶端是否接受並保留這些內容，也取決於匯入方式。不要把訂閱網址、分享連結與完整 JSON 檔案視為同一類資源。匯入前應先確認取得的是哪種內容，再選擇相應的訂閱更新、剪貼簿匯入或自訂設定檔入口。

v2rayNG 訂閱匯入的常見流程是建立訂閱群組、填寫別名與網址、儲存後執行更新，再確認群組中是否出現節點。v2rayN 的訂閱群組設定也採用相近的管理方式。別名方便區分來源，網址則用來取得實際內容，兩者不能互相取代。更新成功後仍需選擇節點並啟動連線；下載訂閱內容不代表遠端服務可用，也不代表系統代理或行動裝置 VPN 接入已啟用，這些步驟都應分別確認。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth"
      }
    }
  ],
  "outbounds": [
    {
      "tag": "selected-node",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "local-socks"
        ],
        "outboundTag": "selected-node"
      }
    ]
  }
}

上方物件以直連協定模擬已選取的出站位置，只用來說明產生後的結構，並非訂閱內容格式。實際用戶端會將選取的節點轉換成相應的代理出站，再與本機設定組合。節點名稱可能改變，而用戶端內部出站標籤可能維持固定；也可能依設定模式產生不同標籤。因此手寫規則不能只依賴清單中的顯示名稱，應檢查最終產生的標籤。若用戶端提供統一的代理出站參照，應優先依照它的規則編輯方式設定。

更新範圍與自訂設定檔

訂閱更新可能替換節點參數、新增或刪除節點，也可能變更別名，實際合併方式由用戶端決定。直接手動修改訂閱節點後，下次更新可能會覆寫這些變更。需要長期保留的特殊節點，可依用戶端支援方式放入獨立群組或設定檔，並記錄來源與修改目的。本機路由與 DNS 是否會隨更新改變，也取決於匯入模式：只更新節點與匯入完整設定的行為不能混為一談；更新前後檢查實際執行物件更可靠。

自訂完整設定檔適合需要明確控制結構的使用者，但可能略過用戶端部分自動產生功能。某些介面中的節點選擇、路由預設或本機連接埠調整，未必會影響這份設定檔。進入自訂模式前，應確認由誰負責入站、由誰管理介面、用戶端是否仍會自動加入欄位，以及啟動時載入的檔案位置。不要一邊使用完整自訂設定檔，一邊期待所有一般介面選項都會同步寫入；先釐清設定檔的管理權責，再新增自訂內容。

移轉、隱私與用戶端選擇

移轉至其他用戶端時，先移轉節點，再重新設定本機接入與路由，不要假設所有介面預設選項都有同名對應項。桌面端建議優先使用 v2rayN；Android 可依核心需求選擇 v2rayNG 或 v2flyNG。同一組節點資訊在不同核心中可能受支援功能範圍影響。請前往用戶端下載頁選擇對應系統的下載項目；搜尋 v2rayNG 下載時，也應先確認裝置架構。架構會影響程式能否安裝執行，但不會直接決定節點協定或路由行為。

訂閱網址往往包含存取憑證，不適合將完整連結放入公開截圖、聊天紀錄或故障報告。回報問題時，保留錯誤類型、回應狀態與更新時間，並隱藏查詢參數及使用者識別碼。更新失敗應先區分網址無法存取、回傳內容為空、內容格式不支援及節點解析失敗；這些階段與代理節點能否連線並非一一對應。若訂閱中只有部分節點消失，應優先檢查缺少的節點所用協定與傳輸是否受支援，而不是立刻重新安裝整個用戶端。

自動更新間隔也應設定得當。更新過於頻繁會增加不必要的請求，也可能在故障排除期間不斷改變測試對象；間隔過長則可能保留已失效的參數。依服務實際變更頻率與使用需求設定即可，不應把較短的間隔視為連線品質更好。開始排查時，可以暫時固定節點與設定，完成驗證後再恢復一般更新。首次完整操作請依照入門指南中的訂閱步驟進行；本章主要說明更新後哪些模組發生了變化。

設定驗證與故障排除

從讀取設定到應用程式存取

驗證應沿著連線路徑依序進行：先確認設定檔語法可供讀取，再確認核心已啟動且本機正在監聽，接著確認應用程式確實使用入口，之後檢查路由選擇、DNS 結果、遠端連線與協定交握，最後測試實際應用程式。依此順序可將故障範圍縮小到特定階段。網頁無法開啟並不是具體原因，重新安裝用戶端也不能取代問題定位；只有確認最後成功的階段與最先失敗的階段，才能判斷下一步應檢查連接埠、權限、參數還是網路路徑。

修改後先確認載入的是新設定。用戶端可能仍在執行舊程序，或於啟動時重新產生另一份檔案；編輯器中的內容不一定等於目前的執行狀態。儲存設定後，依用戶端方式重新啟動服務，再檢查啟動日誌中的監聽位址、連接埠與使用的核心。若日誌顯示未知欄位，先查相容性；若顯示位址繫結失敗，先查連接埠；若連啟動日誌都沒有，則檢查程式是否正常啟動，並參考用戶端閃退與權限問題排查。

{
  "log": {
    "loglevel": "info"
  }
}

日誌資訊與問題分類

暫時使用資訊級日誌，有助於觀察接入與出站過程，但日誌內容與詳細程度取決於核心及用戶端。不要預期每條規則都會提供格式一致的命中紀錄，也不要脫離上下文解讀單一提示文字。閱讀時應保留時間順序：應用程式發起連線後，是否有入站紀錄、是否選擇出站，以及失敗發生在解析、建立連線還是交握階段。診斷結束後，請恢復適合日常使用的層級；分享日誌前，隱藏目標位址、訂閱參數及使用者識別碼等敏感資訊。

同一錯誤可能有多種原因，因此表格用於安排檢查順序，而不是為現象下唯一結論。遠端逾時可能是網路無法連線，也可能是連接埠錯誤；交握錯誤可能來自服務名稱不符、驗證不一致或缺少傳輸參數。使用已知可正常運作的設定進行對照，比反覆新增陌生參數更有效。對照時應盡量使用相同裝置、相同網路與相同測試目標，避免把網路環境改變誤當成設定修復效果。

V2Ray 節點測速與實際可用性

V2Ray 節點測速包含不同測試方式。連接埠連通測試只表示能否與目標連接埠建立連線，不一定完成代理協定；透過代理存取測試網址較接近實際應用情境，但仍會受到測試網站、DNS 與路由影響；下載測試可觀察持續傳輸表現，但也會消耗流量。介面中的單一時間數值無法代表整體存取體驗。比較節點時，應維持測試方式與目標一致，並搭配實際使用的應用程式驗證，不能只依一次排序結果決定長期設定。

測試成功但瀏覽器失敗時，應優先檢查兩者是否使用相同入口與路由。瀏覽器擴充功能、略過清單、內建解析及舊連線都可能改變請求路徑；終端機工具也可能使用自己的代理設定或環境變數。反過來說，瀏覽器成功也不能證明所有應用程式都遵循系統代理。請逐一確認行為不同的應用程式採用哪種接入方式，並記錄核心日誌是否看得到請求。若需要擴大流量接入範圍，再回到本頁的 TUN 章節評估權限與路由影響。

復原、紀錄與穩定運作

每輪測試只修改一組相關欄位，並記錄預期現象。例如為某個網域新增直連規則後，預期是出站標籤改變，而不是所有存取速度都提升；調整解析策略後，預期是位址類型或解析路徑改變，而不是驗證錯誤消失。若結果不符，先還原上一份可正常運作的設定，再核對規則的前置條件。保留簡短的變更紀錄，包括欄位、測試目標與觀察結果，可避免多次測試後忘記目前設定存在的原因。

穩定的設定應保留明確的預設出站、範圍有限且用途清楚的規則、符合實際接入方式的 DNS，以及必要的本機監聽邊界。清除暫時使用的教學對應、診斷介面與測試參數，再恢復訂閱更新。若仍需回報問題，請說明用戶端名稱、作業系統、核心類型、失敗階段與已去識別化的日誌，不必公開完整設定檔。後續查閱可從本頁目錄進入各模組，日常連線則依入門指南操作；如此既能保留易於維護的結構，也能避免每次異常都從頭重建所有設定。