V2Ray 設定檔
結構與規則參考

JSON 結構與設定範圍

設定檔描述的是核心如何接收連線、選擇路徑並建立出站連線，不是用戶端所有設定的集合。視窗位置、訂閱群組、更新週期、系統代理開關通常由圖形用戶端保存；監聽連接埠、協定參數和路由規則才會寫入執行設定。先釐清這兩個層次，才能判斷應修改介面選項、自訂範本，還是獨立的 JSON 檔案。

頂層物件與資料型別

JSON 最外層是物件，欄位名稱和字串須使用英文雙引號。物件以大括號表示，陣列以中括號表示；連接埠通常寫成數字，布林值則寫成小寫的 true 或 false。最後一個成員後面不加逗號。請勿在檔案中使用中文引號、註解或複製頁面時帶入的隱藏字元。有些工具容許的寫法，不代表所有核心入口都能讀取。

inbounds 和 outbounds 都是陣列，因為一個程序可以同時提供多個入口，也能定義多個出口。routing、dns、policy 則是物件，分別管理規則、解析和連線策略。欄位名稱會區分大小寫，標籤也必須完全相符；若將 outboundTag 改成其他大小寫，程式不會自動修正。

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

先看懂最小設定

上方是一份以本機 SOCKS 入站連接直連出站的完整基本範例。應用程式將請求送至本機指定連接埠後，核心會透過 freedom 使用目前的網路建立連線。這份設定不包含遠端代理伺服器，也不會自動設定瀏覽器或作業系統代理。用途是確認設定可載入、連接埠可監聽、應用程式可連入核心，而非示範如何連線至遠端節點。

這個範例沒有設定路由，未被規則選中的連線會使用第一個出站。因此，出站陣列的順序會實際影響連線，不能只當成顯示順序。後續加入遠端出站時，應明確規劃預設路徑；否則看似只新增一個節點，實際上可能改變所有未符合規則的請求。建議先決定預設流量要走哪裡，再安排陣列順序和備援規則。

完整檔案、片段與用戶端範本

設定片段只呈現特定欄位附近的結構，例如一個 routing 物件或一項出站設定。合併時，應放回同名的頂層欄位，而不是將兩個完整物件直接前後串接。頂層欄位也不應重複出現；不同解析器對重複鍵的處理方式可能不同，看似能啟動，不代表兩份規則都會生效。較穩妥的做法是整理成單一且明確的陣列或物件。

圖形用戶端通常會根據目前的伺服器、路由預設和本機連接埠產生執行檔。直接編輯這個檔案後，下次切換伺服器或重新啟動核心時，修改內容可能遭到覆寫。請先查看用戶端是否提供自訂設定、路由編輯或匯入功能。只有確認檔案由使用者獨立管理後，才將它作為長期設定來源；不要讓介面設定和手動編輯同時修改相同欄位。

未指定的欄位會採用核心預設值，但預設值不應妨礙理解設定。安全界線、預設出站和路由解析策略建議明確設定；尚未使用的複雜功能則可先省略。查閱範例時，也要確認核心家族。V2Fly 與 Xray 的基本結構相近，不代表所有擴充欄位都通用。若出現未知欄位或啟動錯誤，請先確認支援範圍，再檢查網路因素。

儲存時請保留一份可正常運作的基準設定，並將修改目的記在檔案旁的純文字筆記中，不要在嚴格的 JSON 內加入說明文字。每次只修改一組相關欄位，成功載入後再測試對應行為。如此可分開處理「語法錯誤」、「結構層級放錯」和「連線參數不符」，避免一次貼上大段設定後無法還原。

inbounds 入站與本機監聽

入站是應用程式將連線交給核心的入口。設定時應先確認的不是遠端伺服器，而是應用程式實際連線的本機位址、連接埠和代理協定。即使遠端節點參數完全正確，只要瀏覽器仍指向舊連接埠，流量就不會進入這份設定。排錯時應一併比對應用程式的代理設定與入站監聽狀態，而非只看用戶端是否顯示正在執行。

監聽位址與開放範圍

listen 決定要綁定的本機位址，port 則決定監聽連接埠。僅供本機使用時，建議優先綁定 127.0.0.1，也就是 IPv4 迴環位址。應用程式使用 localhost 時，系統也可能將它解析為 IPv6 迴環位址；如果核心只監聽 IPv4，而應用程式只嘗試 IPv6，就可能連線失敗。排查時可先明確指定相同的迴環位址。

監聽所有網路介面和允許區域網路裝置存取，是兩件不同的事。擴大綁定範圍後，還須考慮防火牆、裝置所在網路及入站驗證。未經驗證的代理入口不應直接暴露於不受信任的網路。若要共用，請先確認使用者和網路界線，再設定驗證及防火牆來源限制；遠端伺服器的驗證資訊不能取代本機入站的存取控制。

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

SOCKS 與 HTTP 入口的差異

上方是入站欄位片段，兩個連接埠分別提供 SOCKS 和 HTTP 代理。應用程式選擇 SOCKS5 時應連線至前者；選擇 HTTP 代理時則連線至後者。HTTP 代理可透過 CONNECT 承載通往 HTTPS 目標的連線，因此不能只因目標網址以 HTTPS 開頭，就誤以為代理入口本身也必須使用 TLS。代理入口協定與目標網站協定屬於不同層次。

SOCKS 入站的 udp 表示允許處理 SOCKS UDP 轉送，但不保證整條連線路徑都支援 UDP。應用程式必須支援相應方式，遠端出站和伺服器也須承載 UDP，網路路徑則須允許相關封包。HTTP 入站不能直接取代通用 UDP 入口。若網頁正常、特定即時應用卻異常，請單獨檢查該應用的傳輸方式，不要反覆更換網頁代理連接埠。

入站標籤與嗅探範圍

tag 為入口指定一個可供路由引用的名稱。例如，瀏覽器和測試工具使用不同入站時，就能透過 inboundTag 區分兩類流量。標籤本身不會建立監聽，也不會限制應用程式；真正決定應用程式能否連入的是位址、連接埠和協定。標籤建議簡短且固定；變更名稱時，請同步修改引用它的路由，否則規則將失去比對目標。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"]
  }
}

這段 sniffing 物件放在個別入站內，與 settings 同層。它會嘗試從支援的協定交握中辨識網域，以協助網域路由。它無法解讀所有加密內容，也不保證每個連線都能取得網域。對於直接提供 IP 的請求，辨識結果可能影響目標處理方式；是否只用於路由等擴充選項，請依實際核心支援情況確認。

連接埠衝突與系統代理

監聽失敗時，通常應先查看記錄中的位址和連接埠。可能是另一個用戶端執行個體已占用，也可能有系統服務或其他本機代理正在監聽。不要只改一個數字就結束：修改入站後，還要同步更新手動設定的瀏覽器、終端機工具和其他應用程式。用戶端管理的系統代理通常會隨設定更新，但仍應前往系統代理頁面確認實際值。

系統代理只是指示遵循該設定的應用程式連線至某個入口，不代表接管裝置的所有連線。部分應用程式有自己的代理設定，另有部分完全忽略系統代理；這與入站能否啟動是兩個不同問題。若用戶端提供 TUN 模式，其流量接管、路由和權限還涉及系統層機制，無法只靠新增 SOCKS 入站達成。驗證時，請先使用明確支援代理的應用程式縮小範圍。

有效的入站測試應同時確認核心成功啟動、目標連接埠正在監聽，以及應用程式請求出現在對應記錄中。只確認程序存在還不夠，設定載入失敗後，用戶端介面可能仍會顯示原有狀態。完成這三項檢查後再排查出站，可避免將本機入口問題誤判為遠端線路故障，也能為後續依入口分流建立穩定基準。

outbounds 出站與標籤關係

出站決定核心接收連線後，透過哪種方式抵達目標。它可以直接連線、轉交遠端代理伺服器，或依規則丟棄連線。查看 outbounds 中的各個物件時，應先確認協定，再查看該協定對應的 settings。不同協定的設定結構並不通用，不能只修改 protocol 名稱，就把現有設定轉換成另一種協定。

直連、代理與封鎖

freedom 表示使用目前裝置所在的網路直接建立連線；blackhole 則用於丟棄符合條件的流量。direct、proxy 和 block 只是常見標籤，並非內建協定。名為 direct 的標籤若實際指向遠端協定，流量仍會經由遠端出口。因此閱讀設定時，須同時確認標籤與協定，不能只憑英文標籤推斷行為。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

這段片段可作為基本測試設定的出站部分。若規則沒有選中其他出站，第一個出口通常會作為預設路徑。用戶端產生設定時，可能會自行安排預設出站和備援規則，因此手動查閱時應查看最終執行檔，而非只看介面顯示的目前伺服器名稱。新增出站不會自動將流量導向該出口，必須透過預設順序或路由引用建立關聯。

遠端出站的參數層級

遠端代理設定通常包含伺服器位址、連接埠、使用者驗證及傳輸安全設定。位址表示實際連線的伺服器，連接埠表示該服務的監聽位置，使用者欄位則必須符合所選協定。傳輸路徑、服務名稱或 TLS 伺服器名稱屬於其他層級。若將這些值全部填入同一個位址欄位，或直接把連結中的編碼內容塞進驗證欄位，都會破壞原本的結構。

訂閱和分享連結是交換伺服器參數的載體，不等於完整的執行設定。用戶端匯入後，還會結合本機連接埠、DNS 和路由產生設定檔。分享連結可被辨識，只代表格式大致可讀取，不代表驗證有效、憑證相符或傳輸端點存在。遠端參數應取自獲得使用授權的服務設定，不應從其他範例拼湊驗證值和路徑。

多個出站與切換範圍

一份設定可包含多個遠端出站，並由不同規則分別引用。每個標籤都應有獨特且明確的意義，避免重複命名後無法判斷實際引用對象。手動修改標籤時，除了路由，也要檢查其他可能引用出口的功能。只調整出站清單順序，不代表建立了健康檢查或自動切換；若未設定相關機制，核心不會因某條路徑較慢就自行改走其他路徑。

某些協定還包含網域解析策略、連線多工或底層通訊端選項，應在基本連線成功後再調整。例如，解析策略會影響直連出口如何處理網域，但不能取代路由物件中的網域策略；連線多工會改變連線的組織方式，卻無法修正錯誤的伺服器驗證。將效能調整與連線可用性分開處理，排錯記錄才不會混在一起。

遠端出站位址若使用網域，還須考慮啟動時如何解析該網域。解析伺服器網域所需的路徑，必須在代理建立前也能運作，否則可能陷入「要連上代理，卻得先透過同一個代理」的循環。可透過本機解析、明確的引導解析方案或服務提供者提供的有效位址打破循環，不要只反覆切換用戶端的系統代理開關。

設定與用戶端的分工

v2rayN 適合在桌面端管理伺服器和路由範本；Android 上的 v2rayNG 採用 Xray 生態系，v2flyNG 則是 V2Fly 路線的替代選項。相同的基本出站概念可以沿用，但專屬協定擴充、傳輸欄位和匯入行為仍須分別確認。選擇用戶端時，請先考量裝置平台與設定需求；安裝檔統一可在下載頁取得，不要把用戶端名稱填入核心欄位。

儲存遠端參數前，建議逐項核對來源：連線位址、連接埠、驗證、傳輸和安全設定必須屬於同一份服務設定。連線建立後，再確認請求是否確實經由預期出口；連線測試成功不代表所有目標都符合這條路由。若本機直連測試正常，但遠端出站失敗，請將檢查範圍縮小至伺服器解析、交握和驗證，並暫時維持入站設定不變。

routing 比對順序與分流規則

路由會連結入站與出站：檢查目標網域、位址、連接埠或入口標籤，再選擇已定義的出口。規則通常依序由上而下比對，第一條符合的規則決定流量去向。將精確例外放在前面、適用範圍廣的規則放在後面，比記住某一套預設更可靠。未符合任何規則的連線則回到預設出站行為，不會自動依網域所屬地區判斷。

先設定目標，再設定條件

outboundTag 必須與某項出站的 tag 完全相符。引用不存在的名稱不會自動建立出口，可能造成設定檢查失敗或轉送失敗。規則中的 type 設為 field 時，條件欄位用來描述比對範圍。建議先確認可用的出口，再逐條加入規則；否則很難判斷是條件未符合，還是符合後找不到目標出口。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

這段路由片段可搭配前文的直連和封鎖出口使用。blocked.example 是保留的示範網域，用於展示精確比對語法；實際測試時可換成自己有權管理的測試網域。geosite 和 geoip 會引用外部規則資料，執行環境必須提供相應資料檔。若未安裝比對資料集，不應將載入錯誤歸咎於網路線路。

相同欄位與跨欄位的邏輯

同一個網域陣列中的多個項目，通常代表符合其中任一項即可；同一條規則若同時指定網域、連接埠和網路類型，則必須同時符合這些條件。例如，要讓「某個網域或某個 IP」走同一出口，通常應拆成兩條規則，而不是把網域和 IP 放在同一條規則並期待採用「或」的邏輯。先畫出條件關係，再轉成 JSON，較能避免規則看似完整、實際卻永遠不會符合。

full: 用於完整網域比對，domain: 用於比對指定網域及其子網域，regexp: 則用於正規表示式。未加前綴的字串可能比預期涵蓋更廣，不適合用於需要嚴格限制的例外。規則比對的目標是主機名稱，不是完整網址；通常不要將 https://、路徑和查詢參數寫入網域條件，因為路由不會比對網址列中的完整內容。

網域策略與 IP 規則

AsIs 不會只為了路由中的 IP 條件而主動解析網域，因此，應用程式交給核心的是網域時，只有 IP 規則不一定能得到預期結果。IPIfNonMatch 會在網域階段未符合時嘗試解析，再繼續比對；IPOnDemand 則會在比對需要 IP 的規則時觸發解析。兩者都會增加解析介入的機會，也會改變規則順序帶來的實際效果。

解析結果可能包含多個位址，目標服務的位址也可能變動。IP 規則符合，不代表該位址永遠對應某個網域；共用基礎設施也可能讓多個服務使用相同的位址範圍。若能用穩定網域表達需求，請優先使用網域條件；只有確實需要控制本機網段或固定服務位址時，才使用 IP 條件。資料集分類也不是判定憑證或服務歸屬的絕對依據。

{
  "type": "field",
  "inboundTag": ["local-socks"],
  "network": "tcp",
  "port": "443",
  "outboundTag": "direct"
}

這條獨立規則表示：來自指定 SOCKS 入口、目標連接埠為 443 且使用 TCP 的連線會直連。三項條件必須全部符合才會命中，並非全域開放該連接埠。這裡的連接埠是目標連接埠，不是本機監聽連接埠。將規則放在陣列前段時，也要留意它是否會先行攔截後方的網域封鎖規則。規則涵蓋範圍越廣，越需要謹慎安排順序。

預設出口與驗證方式

若需要明確設定備援規則，可在規則末尾加入涵蓋 TCP 與 UDP 的規則，並指向已定義的預設出口。此規則之後的同類規則通常不會生效，因此務必將備援規則放在最後。若預設行為是使用第一個出站，也應在設定筆記中註明，避免日後重新排序出口而意外改變行為。不要將用戶端的「全域代理」模式與系統是否接管所有應用程式混為一談；前者主要描述選路策略。

遇到規則沒有生效時，請依序檢查應用程式傳入的是網域還是 IP、是否已被前面的規則攔截、標籤是否一致，以及資料檔能否載入。修改後須讓核心重新載入相應設定；舊的長連線可能仍沿用原本路徑。測試時先關閉舊連線，再重新發出請求，才能避免將連線重用造成的延續行為誤判為規則未更新。

DNS 解析與路由的配合方式

DNS 會將網域轉換為位址，但在代理連線中，發起解析的角色不只一個。應用程式可能在將請求交給代理前自行解析；核心可能為路由或直連出站進行解析；遠端伺服器也可能解析最終目標。設定 dns 物件，只代表已設定核心解析器，不能據此認定裝置上的所有網域查詢都會經過它。請先確認解析發生在哪個層次，再選擇調整位置。

核心 DNS 的基本結構

servers 指定核心可使用的解析伺服器，hosts 則可為特定網域設定靜態對應。下方以迴環網域對應和示範解析器位址展示結構。此設定不包含攔截系統 DNS 的入站，也不會修改應用程式本身的解析設定。更換解析器時，請確認目前網路允許存取，且符合所在環境的管理規範，不要只因位址看起來常見就直接使用。

{
  "dns": {
    "hosts": {
      "loopback.example": "127.0.0.1"
    },
    "servers": [
      "1.1.1.1"
    ]
  }
}

此處的靜態對應適合用來驗證核心解析流程，不會修改系統 hosts 檔案。只有使用核心 DNS 的請求會受到影響；瀏覽器若透過其他方式取得位址，核心不會回頭替換該位址。正式設定中的靜態對應也需要維護，服務遷移後舊位址可能失效。除非服務提供者明確建議如此連線，否則不要長期以固定 IP 取代動態服務網域。

分域解析與回退

在支援相應欄位的核心中，伺服器物件可透過 domains 指定優先比對的網域範圍，再透過 expectIPs 判斷回應位址範圍。兩者用途不同：前者篩選查詢，後者檢查答案。它們也不等於 routing 規則；DNS 選定解析器後，實際業務連線仍須依出站與路由決定路徑。不要將解析器分組誤認為連線已完成分流。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "1.1.1.1"
    ]
  }
}

此範例需要可用的規則資料集，展示優先比對與一般解析器並存的設定方式。實際回退行為也會受到核心支援的回退選項影響；不要將陣列順序簡單理解為永遠依序執行的主備佇列。若要禁止某類查詢改用其他伺服器，請先確認相應版本的回退開關，不要只刪除或修改某個位址。設定完成後，應分別測試符合條件和未符合條件的網域。

解析流量本身的路徑

一般 UDP 解析、透過 HTTPS 的解析，以及使用本機網路堆疊的解析方式，實際出站路徑可能不同。部分位址格式由核心內部轉送，部分本機模式則會略過一般路由處理。解析器 URL 的寫法應依照實際核心文件，不能只在一般位址前加上前綴，就假設流量會經過代理。尤其要確認建立加密解析連線時，解析器主機名稱如何先取得位址。

遠端出站網域和遠端解析器網域互相依賴，是常見的啟動循環。可能出現首次連線失敗、切換網路後長時間等待，或有快取時正常、重新啟動後卻異常等情況。解決方式是建立代理連線前即可使用的引導解析路徑，並明確指定它只負責哪些基礎網域。不要為了排除一次逾時，就將所有解析器和出站綁定到同一條尚未建立的連線。

IPv4、IPv6 與快取差異

解析出 IPv6 位址，不代表裝置到目標的 IPv6 路徑可用；同樣地，停用 IPv6 也不是所有逾時問題的通用解法。請先檢查本機網路、遠端服務和出站支援的位址類型，再決定是否限制解析結果。不同核心家族支援的查詢策略欄位可能不同，設定時應依實際支援範圍調整，避免使用核心無法辨識的欄位來設定網路策略。

應用程式快取、系統快取、核心快取和遞迴解析器快取可能同時存在。修改 DNS 後重新整理網頁仍看到舊行為，不能立即證明設定未生效。請先重新建立應用程式連線，再視需要清除對應層級的快取，並觀察一次新的查詢。測試時使用可控制的網域或明確記錄查詢時間；不要只依據大型網站的位址是否變更，判斷解析器是否切換成功。

若網頁速度緩慢，但記錄中沒有明確的解析錯誤，請分別比較首次造訪和連續造訪。首次載入緩慢可能與解析或交握有關；持續下載速度慢則較可能與線路、負載或本機處理有關。進一步排查可參考網速慢的分層排查方法，不要同時更換 DNS、節點和路由，否則無法判斷真正起作用的是哪項變更。

policy 策略、記錄與統計

policy 管理的是連線行為和統計開關，不是另一份網域分流表。它可以依使用者等級設定交握等待時間、閒置逾時等參數，也能控制系統層級的流量統計。路由決定流量走哪裡，策略決定如何管理連線；混淆兩者，容易在路徑問題上反覆調整逾時，卻始終沒找到實際故障原因。

等級與逾時的對應關係

levels 的鍵是等級編號字串；使用者等級須由支援此機制的協定設定關聯。如果入站未明確指定使用者，或協定不採用相應等級，就不能假定任意等級設定都會產生作用。建議先確認預設等級，再觀察連線行為。等級編號不代表優先順序或頻寬級別，也不會自動將某組流量分配至較快的出口。

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

此處的時間欄位以秒為單位，呈現的是設定結構，並非適用所有網路的最佳化方案。handshake 限制交握等待時間，connIdle 限制沒有資料交換時的閒置時間；另外兩個欄位則與單一方向結束後等待另一方向的時間有關。連線長時間沒有業務資料時，逾時可能是預期行為。無限制調高數值只會延後回收，無法修復已失效的網路路徑。

需要長時間維持的業務連線，應先確認應用程式是否有心跳機制、伺服器是否允許持續連線，以及網路設備是否會回收閒置連線。只調整核心閒置時間，無法改變中間設備的限制。反過來說，將時間設得過短，可能讓原本正常的低頻請求頻繁重新連線。請先記錄中斷間隔和相關記錄，再判斷是哪一層主動結束連線，不要將所有中斷都歸因於用戶端耗電或背景執行問題。

統計開關不等於統計介面

範例同時包含統計物件和系統統計開關，但這不會自動產生可存取的圖表或管理頁面。讀取統計還需要相應的介面和用戶端支援；部分計數也取決於入站、出站標籤或使用者識別碼。介面數值沒有更新時，請先確認用戶端是否真的讀取該核心的統計資料，而不是繼續增加路由欄位。統計反映處理量，也無法直接說明遠端業務失敗的原因。

若要自行設定管理介面，請將監聽範圍限制在可信任的本機環境，並了解介面路由與權限界線。不要只為了方便某個工具讀取，就將管理入口綁定到所有網路介面。一般桌面使用者建議優先使用用戶端內建的統計功能；獨立設定只保留確實需要的項目，可減少不必要的監聽和後續維護成本。

記錄層級與問題排查

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

這是用來暫時觀察連線的記錄片段。日常使用可採較精簡的層級，排查時短暫提高詳細程度，重現問題後再恢復。存取記錄、錯誤記錄和記錄詳細程度是不同設定；若未指定檔案路徑，還須確認用戶端如何擷取核心輸出。若要寫入檔案，請選擇可寫入的目錄並管理檔案大小，不要假定各平台上的應用程式安裝目錄都有寫入權限。

記錄應依時間順序串接：設定是否載入、入站是否監聽、請求是否進入、選用哪個出站，以及在哪個階段結束。單獨摘錄一行逾時訊息通常不足以定位問題，前面的解析失敗或交握錯誤才可能是根本原因。分享記錄前，請移除伺服器驗證資訊、訂閱網址和個人存取目標；保留錯誤類型、發生階段及必要的匿名化標籤即可。

策略調整的驗證範圍

連線多工、快取和既有連線，都可能讓策略變更的效果延後出現。修改逾時後，應用程式已建立的連線不一定會立即採用新行為，請重新啟動相關連線再測試。測試時維持相同目標和操作方式，記錄閒置時間與重新連線情況，避免將伺服器負載變化誤認為策略帶來的改善。只有能重複觀察到的差異，才值得保留為長期設定。

Android 的背景常駐和電池最佳化也受系統排程影響，不是調高 connIdle 就能解決。v2rayNG 遭系統停止後，核心設定本身無法繼續運作，應先檢查應用程式的電池權限和執行模式。相關取捨可參考v2rayNG 耗電與背景執行排查。分別驗證系統層和核心層，才能避免只增加耗電，卻沒有實際改善連線。

傳輸參數與 TLS 安全層

同一種代理協定可以透過不同傳輸方式運作，同一種傳輸也可能承載不同協定。理解設定時，可由內而外分成代理協定、傳輸方式和安全層：協定負責使用者驗證與請求語意，傳輸負責將資料送達伺服器，安全層負責相關連線的加密和身分驗證。某一層設定正確，不代表其他層也會自動設定完成。

streamSettings 的位置

streamSettings 通常位於個別出站物件內，與 protocol、settings 同層。它不應放進協定使用者物件，也不能任意寫在頂層。下方只展示 WebSocket 與 TLS 的傳輸片段，必須搭配實際服務提供的出站參數使用。網域採用保留的示範名稱，路徑僅用來展示語法，無法連線至遠端服務。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "gateway.example",
      "allowInsecure": false
    },
    "wsSettings": {
      "path": "/transport",
      "headers": {
        "Host": "gateway.example"
      }
    }
  }
}

這個片段未包含伺服器連線位址，位址由出站協定的伺服器設定提供。serverName 用於 TLS 伺服器名稱及憑證驗證相關處理；WebSocket 的 Host 則用於應用層主機選擇。有些部署環境會使用相同的值，另一些則有明確分工。不能只因兩者看起來都是網域，就在沒有伺服器說明的情況下任意互換。

路徑、主機與憑證

WebSocket 路徑必須與伺服器接收端點一致；開頭斜線、大小寫和附加內容都可能影響比對。路徑錯誤時，伺服器仍可能回傳正常網頁或其他 HTTP 回應，但代理交握並未成功。能開啟伺服器首頁，不代表傳輸端點設定正確。排查時應查看升級交握和核心錯誤，而非只測試網域能否在瀏覽器中開啟。

憑證驗證失敗時，請先檢查裝置時間、憑證涵蓋的網域、信任鏈，以及實際連線的服務。停用 allowInsecure 驗證會改變安全界線，不應作為長期修復憑證錯誤的方法。使用 IP 連線，但服務憑證是簽發給網域時，仍須依正確的服務設定填入伺服器名稱。憑證問題和代理使用者驗證是兩套機制，修改使用者識別碼無法修復網域不相符。

傳輸欄位不可跨類型套用

切換傳輸方式不能只修改 network 一個欄位。WebSocket 路徑、gRPC 服務名稱和其他傳輸的參數分屬不同設定物件，必須與伺服器端的設定一致。保留無關欄位有時會遭忽略，有時則會造成載入或交握異常。建議只保留實際使用的傳輸物件，並逐項對應伺服器提供的參數，避免混用多個分享連結的內容。

基本 TCP、WebSocket 和 gRPC 等方式在資源使用、連線管理和部署條件上各有不同，但不存在不考慮伺服器條件的通用最快選項。用戶端選擇某種方式，而伺服器沒有相應端點，就無法建立連線。調校時應先維持目前可用的傳輸方式，再比較相同網路下的實際表現；不要將某種傳輸名稱直接視為速度保證。

核心家族與擴充功能

V2Fly 與 Xray 屬於相關的代理核心生態系，但設定功能各自演進。REALITY 等專屬安全功能應使用實際支援它的核心，並依該核心的欄位規範設定，不可直接將名稱替換到本節的 TLS 範例中。JSON 外觀相似，不代表參數相容；匯入分享連結後，也應確認用戶端選用的核心符合節點需求。

連線多工也須考量協定和伺服器條件。啟用後可能減少部分新建連線的成本，也可能在特定連線路徑或業務上造成不同表現。若只有單一長連線異常，可先回到未額外啟用多工的基準設定，在其他參數不變的情況下進行比較。不要一次同時修改多工、傳輸、TLS 和 DNS；變因太多，偶然成功的結果便難以重現。

若本機入口正常、伺服器連接埠也可連線，但記錄停在 TLS 或傳輸交握階段，請暫停調整路由與 policy。先核對系統時間、伺服器名稱、路徑、服務名稱及驗證資訊是否來自同一份設定，再檢查中間反向代理的端點對應。逐層排查通常比反覆匯入訂閱更能保留有效線索，也不會連同可用規則一起覆寫。

設定合併、測試與故障復原

設定維護的重點不是一次收集更多欄位，而是讓每次變更都有明確原因、能夠驗證並可復原。開始前請確認目前使用的用戶端、實際核心、設定來源和預設出口，並儲存一份可正常運作的基準設定。基準內容還應包括 JSON、用戶端目前模式和系統代理狀態；若只保留檔案而忘記外部開關，還原後仍可能得到不同結果。

依照相依關係合併片段

先建立可啟動的入站與直連出口，再新增遠端出站，接著加入只涵蓋單一目標的路由，最後才調整 DNS 和策略。這個順序並非功能限制，而是排錯所需：入口不通就無法驗證出口；出口不存在就無法驗證規則；基本連線失敗時，調整逾時也沒有意義。每個步驟成功後先記錄，再進入下一層；發生問題時就能明確回復。

合併陣列時新增成員，合併物件時逐一核對鍵值，不要把片段直接貼在檔案末尾。特別留意重複的 routing、dns 和 log 欄位，以及多處定義的同名標籤。若範本工具會自動產生部分欄位，也要確認它是取代整個物件，還是只在陣列中新增項目；了解合併方式，比只看到「內容都還在」更重要。

啟動前與啟動後的檢查

先使用本機編輯器檢查 JSON 語法，再讓實際執行的核心檢查設定結構。語法正確不代表欄位受支援，核心成功載入也不代表能連線到遠端伺服器。應分層解讀錯誤訊息：解析錯誤先檢查引號和逗號；未知欄位先確認核心功能；監聽失敗先檢查本機連接埠；交握失敗再檢查遠端參數。不要讓網路測試掩蓋尚未成功載入的檔案。

測試工具應明確指定代理，避免系統代理狀態造成混淆。下方請求用於驗證本機 SOCKS 入口能否處理 HTTPS 目標；socks5h 表示將網域交由 SOCKS 端處理。結果仍受所選出口和網路狀況影響，不能用來評估延遲，也無法證明所有應用程式都已接入。在 Windows 上明確使用程式名稱，可避免終端機環境中同名別名造成差異。

curl.exe --proxy socks5h://127.0.0.1:10808 --head https://example.com
curl --proxy http://127.0.0.1:10809 --head https://example.com

用戶端重建與訂閱更新

在 v2rayN 中，切換伺服器、切換路由預設或重新啟動核心，都可能重新產生執行設定。若手動修改很快就消失，請尋找可保存設定的入口，不要繼續編輯暫存輸出。首次安裝位置、寫入權限和啟動設定，可參考v2rayN 初次安裝設定檢查清單；基本連線步驟則可回到入門教學確認。

訂閱更新也可能變更伺服器項目、節點名稱和可選參數。若自訂規則依賴經常變動的項目名稱，請確認用戶端如何將它對應至執行標籤，不要假設顯示名稱永遠等於出站標籤。多來源管理方式可參考訂閱群組與篩選方法。更新前後保留結構差異，比只記下「更新後失效」更有助於定位問題。

常見問題與復原順序

最終的驗證記錄應能回答四個問題：請求從哪個入口進入、目標以網域還是 IP 表示、符合哪條規則，以及由哪個出口建立連線。只寫「可以用」不足以證明分流正確，只寫「逾時」也無法判斷故障層級。分別記錄一次成功與一次失敗的連線流程，通常就能將問題縮小至少數欄位，不必重寫整份設定。

維護完成後，請恢復適當的記錄層級，移除不再需要的測試入口和臨時靜態對應，並將長期設定儲存至用戶端認可的位置。保留精簡且容易理解的規則，比疊加多套預設更便於長期維護。之後若只需完成連線操作，請查閱教學；若要了解欄位含義、相依關係或合併方式，再依本頁目錄返回相應章節。