V2Ray 設定檔參考

一、JSON 結構與設定載入界線

從一筆請求看懂頂層物件

設定檔描述核心如何接收連線、選擇轉送方式及處理輔助功能，不是另一種訂閱網址格式。應用程式先將請求送入某個入站，路由模組讀取目標與來源資訊，再將連線交給選定的出站。DNS、記錄檔與策略則在不同階段參與處理。掌握這條流程後，修改設定時就能先判斷問題所在層級，不必同時調整幾個看似相關的選項。

常見的頂層物件包括 log、inbounds、outbounds、routing、dns 與 policy。入站和出站通常是陣列，因為可以同時設定多個監聽入口與多種出口；路由則以規則陣列表達比對順序。陣列中項目的位置可能影響行為；物件欄位的排列順序通常不影響語意。整理格式能提升可讀性，但不應為了排版好看而任意調換出站或路由規則。

先建立可運作的本機基準設定

以下完整範例會在本機回送位址監聽 SOCKS 連接埠，並使用直連出站。用途僅在確認核心能讀取檔案、繫結連接埠並處理本機請求，不會建立遠端代理通道。啟動前請確認該連接埠未被其他用戶端占用，測試時則讓應用程式明確使用此 SOCKS 入口。範例未啟用 UDP，方便先將初次驗證範圍限縮在 TCP 請求；其他功能會在後續章節分別說明。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

JSON 字串必須使用英文雙引號；布林值寫成 true 或 false，數字則不需加引號。陣列和物件的最後一個項目後不要留逗號，也不要直接在程式碼中加入中文說明。有些工具允許使用含註解的擴充格式，但編輯器能開啟，不代表核心也能接受。要在不同工具間傳遞設定時，使用標準 JSON 較容易找出語法問題；檔案以 UTF-8 文字格式儲存即可。

欄位存在，不代表目前的核心支援

V2Fly 與 Xray 的設定格式源自相近的演進脈絡，但協定支援、傳輸選項與欄位發展並不完全相同。閱讀範例前，先確認執行中的程序使用哪個核心，再核對該核心的欄位定義。用戶端介面出現某個選項，只能表示用戶端提供對應的設定入口，不能據此推論所有核心都接受相同的 JSON。sing-box 採用另一套結構，本頁範例不能直接載入作為它的設定檔。

還要分清楚「編輯的檔案」與「程序載入的檔案」。圖形介面用戶端可能在啟動時產生暫存執行設定，自訂設定也可能透過獨立項目載入。若儲存目錄中的 JSON 後沒有變化，請先查看啟動記錄或設定詳情，確認實際載入路徑與目前使用的項目。不要假定程式目錄裡名稱相似的檔案就是生效檔案，更不要同時修改用戶端資料庫與產生檔案來碰運氣。

設定檔容易維護，關鍵在於界線清楚。建議先保留一份可正常運作的基準設定，每次修改只動一個物件；確認有效後，再記錄修改原因與預期結果。合併片段時特別留意頂層同名欄位，只能保留一個對應物件或陣列，不可將兩份完整設定直接前後拼接。即使解析器接受重複鍵，也可能只保留其中一個值，導致實際設定與閱讀時的理解不一致。

本頁依序介紹入口、出口、路由、解析與策略，最後說明用戶端管理及驗證流程。實際使用時可依目錄跳讀；但遇到轉送異常，仍應沿著請求路徑逐項檢查。先確認流量確實進入目標程序，再判斷規則是否命中；若入口根本沒有流量，調整路由只會增加排錯變因，無法證明任何規則是否正確。

二、inbounds 入站監聽與流量入口

監聽位址、連接埠與協定各有用途

inbounds 中的每個物件都定義一個入口。listen 決定要繫結哪個本機位址，port 決定監聽的連接埠，protocol 則決定入口接受哪種協定。應用程式必須使用與入口相符的代理方式，不能把 HTTP 代理位址填入只接受 SOCKS 的連接埠。連接埠號碼只是本機設定，並不代表固定功能；複製設定時，應以目前檔案及用戶端顯示的實際值為準。

僅供本機使用時，請將監聽位址明確設為 127.0.0.1。這是 IPv4 回送位址，其他裝置無法直接存取此監聽入口。若改為 0.0.0.0，表示繫結所有 IPv4 網路介面，並不是可填入其他裝置的目標位址。開放區域網路存取還涉及主機位址、防火牆與驗證，應視為獨立變更處理；不要只為了解決本機連線問題，就直接擴大監聽範圍。

SOCKS 與 HTTP 雙入口

以下片段會在第一章的 SOCKS 入口之外新增 HTTP 入口，適合需要分別設定這兩種代理的應用程式。請以此片段完整取代原有的 inbounds 陣列，不要在頂層再新增第二個同名欄位。兩個入口使用不同連接埠，但可共用同一個出站物件。這裡的標籤只供設定內部參照，不會讓系統自動識別或啟用代理。

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

SOCKS 入站的 udp 表示允許處理 SOCKS UDP 轉送請求，不代表所有使用系統代理的程式都支援 UDP。應用程式本身必須具備對應能力，出站協定、伺服器與網路路徑也都要支援相關流量。HTTP 入站主要供遵循 HTTP 代理設定的應用程式使用。若瀏覽器正常、其他程式卻異常，請先檢查它們使用的入口機制，而不是只比較目標網域。

tag 應簡短、唯一且容易辨識。路由可透過 inboundTag 比對特定入口，讓不同本機連接埠使用不同出口。標籤不會自動修正錯誤；更名後必須同步修改所有參照，否則規則可能不再命中，卻沒有明顯的語法錯誤。建議在設定說明中註明各入口對應的應用程式類型，以免長期維護後只剩連接埠號碼，無法確認用途。

流量嗅探可補充目標資訊，但不能取代解析

有些應用程式會先將網域解析為 IP，再送出代理請求，因此路由收到的目標不再是原始網域。sniffing 可嘗試從支援的應用層交握中辨識網域，供後續處理使用。常見的 destOverride 值包括 http 和 tls。不過，流量嗅探並非對所有流量都有效，也不能解密任意應用程式資料；是否會改變連線目標，仍須確認所用核心的實際行為。

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

這段設定應放在某個入站物件內，不是獨立的頂層模組。啟用前請先釐清目的：是要補足網域路由資訊，還是要處理目標位址還原？若應用程式使用的協定不在支援範圍內，或交握過程沒有提供可辨識的資訊，仍須依賴原始目標與 IP 規則。不要把流量嗅探當成所有網域分流問題的通用解法；修改嗅探設定後，應重新檢查受影響應用程式的連線結果。

排查連接埠繫結失敗時，先關閉可能重複執行的用戶端，再檢查是否有其他程序占用相同的位址與連接埠。不要連續更換幾個連接埠，卻忘了同步更新應用程式設定。若監聽已成功，但應用程式沒有請求記錄，請檢查它是否使用自己的代理設定、是否略過本機位址，以及系統代理是否仍指向舊連接埠。確認入口後再檢查出站，可避免把「沒有連線進來」誤判成「遠端無法使用」。

三、outbounds 出站協定與傳輸參數

出站物件定義實際的轉送方式

outbounds 可包含直連、封鎖及遠端代理等不同物件。protocol 指定出站協定，settings 儲存該協定所需參數，tag 則供路由參照。出站標籤不是伺服器位址，也不是用戶端顯示的別名；中文別名變更後，產生設定中的標籤是否跟著變動，取決於用戶端。查閱執行設定時，應以物件中實際存在的標籤為準，不能只憑介面名稱推測參照關係。

若沒有路由規則命中，常見設定會使用出站陣列中的第一個物件。因此，陣列順序不只是排版問題。將直連物件從第二項移至第一項，可能改變所有未命中流量的去向。為了讓行為更容易理解，可以在路由末尾設定明確的預設規則；但仍應確認第一個出站的用途，尤其是在用戶端產生設定與自行維護設定之間轉換時。

直連與封鎖的基本物件

以下定義兩個出站：freedom 會讓本機網路直接連線至目標，blackhole 則會丟棄符合條件的流量。兩者都不需要遠端伺服器資訊。此陣列可搭配第一章的入站使用；不過，若沒有新增路由，封鎖物件不會因為存在於陣列中就自動生效。設定物件負責提供功能，路由則負責選擇功能，兩者應分開理解。

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

遠端代理出站通常還需要伺服器位址、連接埠、識別資訊與傳輸設定。這些內容必須依實際服務設定決定，不能從用戶端名稱推測。VMess、VLESS 與 Trojan 的驗證欄位各不相同，TLS、WebSocket 等傳輸參數也不能放錯層級。建議先匯入服務提供者的有效訂閱或連結，再檢查用戶端產生的結果；這比從零手動拼接多層設定更容易保持一致。

分別核對協定、傳輸與安全層

streamSettings 描述底層傳輸與安全相關設定，和 settings 中的協定識別資訊用途不同。伺服器使用哪種傳輸，客戶端就必須採用相應結構；路徑、主機名稱與安全參數也必須成套相符。更改傳輸名稱不會自動轉換伺服器設定。若交握失敗，先核對伺服器要求的組合，再檢查本機選項，不要逐一嘗試所有下拉選項。

連線位址與 TLS 驗證使用的伺服器名稱是不同概念。前者決定連線目的地，後者用於驗證憑證身分；在某些部署中兩者可以不同，但必須有明確的服務設定依據。遇到憑證錯誤時，應檢查系統時間、伺服器名稱與憑證鏈，不要直接略過驗證。略過驗證會改變連線的安全條件，不能當作長期解決方式，也無法證明其他參數正確。

REALITY 等專用功能需要搭配相容的核心與伺服器參數。不要因為 JSON 中也出現安全相關欄位，就將範例直接移植到另一種核心。v2rayN 可管理不同核心的項目，但不代表所有項目都能任意切換執行程式。Android 端的 v2rayNG 與 v2flyNG 也應依各自核心能力選用；三款用戶端的分工請參閱用戶端比較。

排查出站問題時，應從單一物件開始。暫時設定明確的預設規則，讓測試請求只經過目標出站；確認基本連線正常後，再恢復複雜分流。若只有特定類型的網站無法連線，檢查目標解析與規則；若所有目標都無法建立連線，再核對遠端位址、驗證資訊與傳輸設定。不要同時啟用多種連線最佳化功能來掩蓋基本錯誤，新增的層次會讓記錄中的失敗位置更難對應到原始請求。

更新訂閱後，服務提供者可能會調整連線參數，用戶端也可能重新產生內部標籤。手動維護的自訂路由若參照舊標籤，就需要再次檢查。建議將遠端參數交由訂閱項目管理，把長期穩定的分流需求放在路由設定中。若確實需要完全自訂出站，請記錄參數來源與核心需求；分享排錯資料前，移除識別資訊與私人訂閱網址。

四、routing 路由規則與比對順序

先符合的規則決定出口

routing.rules 是有順序的規則陣列。對常見欄位規則而言，同一陣列欄位中的多個候選條件通常採「符合任一項」；不同條件欄位則必須同時符合。例如規則同時設定入站標籤與網域時，只會處理從指定入口進入、且目標網域也符合條件的連線。規則越前面越先比對；特殊條件應排在廣泛規則之前，預設規則則放在最後。

以下範例先封鎖文件示例網域，再將私人位址導向直連，最後也把其他 TCP 與 UDP 流量導向直連。此範例用於說明規則順序與標籤參照，不是遠端代理分流方案。使用前須備有標籤為 direct 和 block 的出站，並安裝目前核心可讀取的 GeoIP 資料檔；若沒有資料庫，請先移除相關規則完成基準驗證。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:example.org"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

網域寫法應清楚表達比對意圖

full:example.org 表示精確比對此網域；domain:example.org 則用於比對該網域及其子網域。正規表示式的表達能力較強，但也更容易造成過度比對；一般需求建議優先使用明確的完整網域或網域後綴規則。不要將完整網頁網址直接填入網域清單；路徑、查詢參數與片段都不屬於網域條件。帶有路徑的網址常會讓規則看似存在，卻始終無法命中。

IP 條件可使用單一位址、網段或資料庫參照。網域規則與 IP 規則處理的是不同資訊，不能假設某個網域符合某分類後，其所有解析位址也屬於相同分類。內容傳遞網路可能讓多個網站共用位址，同一網站也可能解析出不同地區的位址。若需要精確控制，請先說明比對依據，再選擇使用網域或位址，避免用大型網段取代少數明確網域。

domainStrategy 控制路由中的解析時機

AsIs 會依連線目前已有的目標資訊進行路由，不會為了比對 IP 規則而主動額外解析。IPIfNonMatch 會在既有條件未命中時嘗試解析網域，再進行相應比對；IPOnDemand 則會在比對過程需要 IP 資訊時觸發解析。選用後兩者，代表路由結果可能取決於 DNS 回傳值；解析失敗或位址變動都會影響判斷，請搭配第五章一起閱讀。

此處的路由解析策略，不等於所有出站的位址處理策略，也不等於作業系統的 DNS 設定。名稱相似的欄位可能屬於不同模組，作用時間與範圍也不一樣。修改前先確認物件路徑，再清楚描述預期結果；例如「網域未命中時，以解析出的位址參與規則比對」，就比「開啟智慧解析」更明確。若應用程式已提交 IP 目標，相關網域解析策略也無法憑空還原原始網域。

GeoIP 與 GeoSite 資料需要一併管理。更新檔案後，請確認實際執行的核心已讀取新檔案，並依用戶端要求重新啟動或載入；只替換其他目錄中的副本不會改變結果。若出現找不到分類或無法讀取資料等錯誤，先確認檔案來源與路徑，再檢查規則寫法。更新方式請參閱GeoIP 與 GeoSite 資料庫更新指南。

用戶端中的「繞過中國大陸」等預設設定，是一組規則，並非單一開關的另一種說法。切換預設可能同時改變網域、IP 與預設出口；排錯時應檢視產生的完整規則。若要新增單一例外，請將它放在會先命中的廣泛規則之前，並確認儲存後已重新載入。至少測試一個應該命中的目標，以及一個不應命中的目標，才能判斷條件是否過於寬鬆。

多入口情境也可透過 inboundTag 區分應用程式，例如讓特定本機連接埠使用固定出口。對可手動指定代理的程式來說，這比反覆調整系統代理更合適；前提是應用程式確實連上對應入口。若路由無效，請依序核對入口標籤、原始目標、規則順序與出站標籤；不要一發現連線結果不符，就先更換資料庫或修改遠端協定。

五、dns 解析設定與查詢路徑

先釐清是哪一層發起解析

一次連線可能涉及應用程式自行解析、作業系統解析、核心內建 DNS，以及遠端服務解析。頂層 dns 設定只管理核心內建解析器參與的部分，不會自動接管所有程式的網域查詢。瀏覽器若啟用自己的加密 DNS，查詢路徑也可能不同。排查時先記錄目標以網域還是 IP 進入核心，再判斷問題是否確實與此物件有關。

內建 DNS 可供路由的網域解析策略、特定出站行為等功能呼叫。只新增伺服器陣列，不會讓所有代理請求都先在本機解析；遠端協定也可能將網域交由另一端處理。反過來說，若應用程式在送出請求前已先解析並提交 IP，核心可能沒有機會使用此處的伺服器。系統解析結果正常，只能證明系統這條路徑可用，不能證明核心解析也正常。

基本伺服器與靜態對應範例

以下片段使用一般 DNS 伺服器，並為文件示例網域新增靜態對應。對應位址僅供文件示範，不提供真實網站服務；驗證時只觀察解析結果，不要用來判斷網頁是否連得上。靜態對應用於說明設定結構，不建議長期將大量網站位址寫死在設定中；服務位址變更後，固定記錄很容易成為不易察覺的故障來源。

{
  "dns": {
    "hosts": {
      "example.org": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1"
    ]
  }
}

hosts 提供內建解析器的靜態解析結果，servers 則定義上游伺服器。伺服器位址能否連線取決於目前網路，範例位址不保證在任何環境都能使用。一般 DNS 與加密 DNS 在傳輸、憑證及引導解析方面有所不同；切換前先確認所選服務可連線，再檢查該核心支援的設定格式，不要直接把網頁網址當成解析介面。

依網域分流解析與結果限制

伺服器也可設定為物件，透過 domains 指定優先比對的網域範圍。以下範例為示例網域指定專用伺服器，其餘查詢則交由預設候選伺服器處理。比對到的伺服器失敗後是否回退，以及回退時包含哪些候選項目，也會受到所用核心設定影響。不要只憑陣列位置就認定「排在前面便永遠優先」；應分別了解網域比對、候選伺服器選擇與失敗回退的階段。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:example.org"
        ]
      },
      "8.8.8.8"
    ]
  }
}

部分設定還會透過 expectIPs 限制可接受的解析結果。這是結果篩選條件，不會自動把錯誤答案修正為正確答案。限制過嚴時，伺服器雖然已回傳位址，核心仍可能拒絕結果，呈現出解析失敗的狀況。若使用資料庫參照來限制結果，還會增加資料檔依賴；排錯時應先移除結果限制，確認解析正常後再逐項恢復條件。

路由的 domainStrategy 與 DNS 設定搭配使用時，特別容易造成誤解。若採用按需解析，首次連線可能要等網域解析完成，才能決定出口；若上游解析又依賴尚未建立的代理路徑，則應檢查是否形成循環依賴。遠端伺服器本身使用網域時，也需要可用的引導解析方式。請將伺服器位址解析與一般業務網域解析分開驗證，不要只測試一個網站。

IPv4 與 IPv6 的解析結果也應分開觀察。網路取得 IPv6 位址，不代表對應出口具備完整的 IPv6 連線能力；應用程式可能優先嘗試某一類位址，再回退到另一類，造成偶發等待。不要一遇到連線緩慢就永久停用某個位址族。先以相同目標分別驗證解析結果與連線路徑，再依核心支援的查詢策略調整，避免把連線問題誤判為網域分類問題。

TUN 情境還涉及系統 DNS 如何進入虛擬網卡，以及是否存在攔截或重新導向等額外流程。只靠本頁的頂層 DNS 物件無法說明這些行為，還須一併檢查用戶端產生的 TUN 設定。相關原理請見v2rayN TUN 模式說明。任何 DNS 相關變更後，建議重新建立應用程式連線並留意快取影響，避免用舊解析結果判斷新設定。

六、policy 等級策略、逾時與統計

策略等級不是路由優先順序

policy 用於定義連線行為與統計相關策略，其中 levels 依使用者等級組織設定。這裡的等級不是訂閱群組編號，也不是路由規則的執行優先順序。某些協定的使用者設定中，level 會連結至相應策略；若未另外指定，通常會使用預設等級。修改沒有任何使用者引用的等級，可能不會影響目前連線，因此應先確認策略套用對象。

以下片段為等級零設定連線階段與閒置處理參數。數值以秒為單位，用於呈現欄位之間的關係，不是適用所有網路的建議範本。請將它合併至頂層 policy 物件中。若已有其他等級或系統統計設定，應保留原有欄位再行調整；不要整份以範例覆蓋後，又把功能消失誤認為核心行為改變。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

連線生命週期中的四個時間欄位

handshake 限制入站連線完成交握階段的等待時間，不是所有遠端連線流程共用的逾時設定。調大此值無法修正驗證欄位錯誤或傳輸方式不相符的問題。若連線建立後才停頓，應檢查閒置策略、遠端狀態與應用程式行為。記錄中同樣出現「逾時」，不代表都由這個欄位控制，必須依出錯階段判斷。

connIdle 用來設定連線沒有傳輸資料時可閒置多久。時間過短可能影響長時間維持、但傳輸頻率較低的工作階段；時間過長則可能延遲釋放已無實際用途的連線。即時通訊、遠端終端機與一般網頁的連線特性不同，不能只用載入一次網頁來判斷設定是否合理。調整後應觀察原先發生問題的應用程式，並涵蓋它實際可能經歷的等待時間。

uplinkOnly 與 downlinkOnly 分別控制連線只剩單向傳輸時的等待行為。它們不是上傳或下載速度限制，也不是路由選擇條件。有些應用程式送出資料後，仍會等待較長時間才收到回應，因此單向傳輸階段的處理方式會影響連線結束時機。若回應提早中斷，先確認連線狀態與記錄，再考慮這些欄位，避免把伺服器主動關閉連線誤認為用戶端策略。

統計開關不等於完整的統計介面

若需要使用核心統計，常見設定會同時包含頂層 stats 物件，以及 policy.system 底下的統計開關。以下僅示範如何啟用入站與出站總流量統計。這不會自行建立圖形化面板，也不代表用戶端一定會讀取這些計數；讀取方式還取決於用戶端實作或相關介面。若沒有查詢途徑，新增統計欄位也不會讓介面憑空出現新項目。

{
  "stats": {},
  "policy": {
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  }
}

若還需要前述等級策略，應將 levels 和 system 合併至同一個 policy 物件，不要複製出兩個同名物件。使用者層級統計還涉及協定與使用者識別等關聯條件，不能把系統統計開關誤當成使用者統計設定。比較計數時，也要考慮程序重新啟動、工作階段結束與用戶端彙整方式；否則兩次介面讀數的差異，可能只是統計週期不同。

緩衝與資源相關選項屬於進階調校範圍。沒有資源瓶頸的證據時，建議保留核心預設值，不要照抄所謂的通用最佳化參數。增加緩衝可能提高記憶體用量，縮小緩衝則可能影響特定流量；實際效果也取決於並行連線數及應用程式的讀寫模式。先確認協定、路由與 DNS 設定正確，再針對單一瓶頸進行對照測試，比一次加入大量策略更容易釐清結果。

排查策略問題時，應保留穩定的觀察時段。先記錄發生問題的應用程式、閒置時間與連線階段，再一次只修改一個欄位，重新建立受影響的連線後再測試。若策略變更沒有差異，請檢查實際載入的檔案、使用者等級與目前執行的核心。不要不斷拉長逾時來延後失敗；若根本原因是遠端拒絕連線或位址無法到達，增加等待時間只會讓錯誤更晚出現，無法恢復連線。

七、v2rayN 產生設定與自訂設定

分開維護持久設定與執行檔案

v2rayN 會將節點、訂閱群組、路由與參數設定儲存為用戶端可管理的資料，再依選定核心產生執行設定。產生的檔案較接近執行產物，不一定是長期維護設定的入口。直接修改產生檔後，切換伺服器、重新載入或重新啟動都可能覆蓋變更。需要長期保留的設定，應優先從對應介面修改；若需完全掌控 JSON，再評估自訂設定項目的管理方式。

使用前先確認目前的工作模式：一般節點項目通常由用戶端負責組合入站、出站與共用設定；自訂設定項目則可能保留較多檔案內容。兩種模式中的選單操作，不一定會作用於相同層級。不要假設切換介面上的路由預設值，就會重寫任意自訂 JSON。要確認某項設定是否生效，應檢查重新載入後的實際執行設定，而不只是確認介面按鈕已選取。

共用參數、節點參數與訂閱來源

本機監聽連接埠、核心選擇等共用參數，可在參數設定相關頁面中查找；實際名稱會隨用戶端介面調整。遠端位址、驗證資訊與傳輸設定屬於節點參數；訂閱網址與更新間隔則屬於訂閱群組。將問題交由正確入口處理很重要：更新間隔不會改變交握協定，系統代理設定不會修改遠端伺服器，切換路由預設值也不等於重新下載訂閱內容。

訂閱更新可能會覆蓋來源項目的連線資訊，因此若長期手動修改訂閱節點，應考慮下次更新的影響。若只是暫時測試，請先複製為可獨立管理的項目，並清楚標示用途；若是服務提供者變更參數，應更新來源，而不是反覆修補舊欄位。若無法取得訂閱，請先處理網址、網路與時間問題；詳細步驟請見訂閱更新失敗排查。

切換核心不能只換程式名稱

v2rayN 可透過用戶端提供的入口管理不同核心，但某個項目能否切換，取決於它使用的協定與傳輸功能。不要將 Xray 專用設定交給 V2Fly，並只憑 JSON 語法正確就認定可用。sing-box 的設定物件結構不同，更不能直接沿用本頁片段。切換前請確認用戶端會重新產生相符格式，或為自訂設定準備獨立的對應檔案。

Windows 的 WPF 介面與跨平台桌面介面，在選單配置、系統匣及系統整合方面可能不同，但入站、出站與路由等概念仍然相通。macOS 與 Linux 也須留意系統代理與權限機制差異，尤其是 TUN 相關操作。安裝檔選擇請見桌面版與 WPF 版差異，不要為了尋找相同選單而安裝不適用於目前平台的套件。

Android 端的 v2rayNG 與 v2flyNG 應依各自的核心與介面管理設定，不能照搬桌面端的選單路徑。匯入連結或訂閱時，請確認用戶端支援相關協定與參數；匯入完整 JSON 時，也要確認這是用戶端明確支援的匯入類型。訂閱連結、單一節點分享連結與完整設定檔是三種不同資料，即使都以文字儲存，也不能互相取代。

建議為自訂設定建立簡單的變更記錄，註明修改的物件、預期行為與回復方式。記錄保存在本機即可，不必將私人設定上傳至公開位置。分享排錯資料時，可保留物件結構、標籤與錯誤訊息，但須移除識別資訊、私人伺服器位址與訂閱網址。只遮蔽一段驗證內容未必足夠；其他欄位也可能洩露服務資訊或個人使用習慣。

維護時應以單一來源為準：由介面管理的內容就在介面修改，由自訂檔案管理的內容就在檔案修改。不要讓兩套設定長期互相覆蓋。每次變更後先檢查產生結果，再查看程序記錄，最後測試應用程式；若介面顯示與實際行為不同，應優先確認設定載入流程。若只想完成連線，請回到快速入門流程，不必先掌握所有頂層物件。

八、設定驗證、記錄檢視與回復

依序檢查語法、載入、入口與出口

排查設定問題的第一步，是判斷故障發生在哪個階段。JSON 語法錯誤會使檔案無法正確解析；欄位不受支援或參照不存在，可能在載入階段報錯；連接埠被占用會影響監聽；遠端交握問題則通常發生在請求進入之後。各階段的修正方式不同。先讀取第一則有實際意義的錯誤，不要只看最後一行「啟動失敗」，因為後續訊息往往只是前面錯誤造成的結果。

編輯前請保留目前可正常運作的檔案或用戶端設定備份，並記下這次只打算修改哪個物件。完成編輯後，先檢查括號、逗號、值的型別與重複鍵，再透過用戶端重新載入，確認核心是否成功啟動。若用戶端提供設定檢視或記錄入口，請確認其中顯示的是剛修改的項目。發生錯誤後不要繼續疊加新規則；先回復到最近可運作的狀態，才能判斷是哪項變更造成差異。

以明確的本機請求驗證入口

以下兩個指令使用支援相應選項的 curl，分別測試本機 SOCKS 與 HTTP 入口。它們使用第二章的連接埠，僅適用於該設定目前正在執行的情況。SOCKS 指令中的 socks5-hostname 會將目標網域交由代理端解析；若改成本機解析，測試的 DNS 路徑就會不同。測試網站是否連得上仍取決於目前網路與出口，指令不保證測試成功。

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

若出現無法連線至本機連接埠的訊息，先檢查程序、監聽位址與連接埠，不必立刻修改遠端設定。若本機連線已建立後才失敗，再檢查目標解析、路由選擇與出站交握。測試時盡量維持相同目標與入口，每次只改變一項條件；混用瀏覽器快取、系統代理與命令列直連會引入不同路徑，使表面上相同的連線無法直接比較。

暫時提高記錄詳細程度，不要長期保留詳細記錄

預設警告層級適合日常使用；排查路由或連線問題時，可暫時提高至 info。以下片段僅調整錯誤記錄的詳細程度，不指定檔案路徑，方便先透過用戶端記錄介面檢視。若要寫入檔案，請確認目錄可寫入、路徑符合目前作業系統格式，並留意檔案大小持續增加。記錄中可能包含目標網域與連線資訊，分享前請檢查並清除敏感內容。

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

檢視記錄時，應以新建立的一筆請求為主，依時間順序觀察入口接收、目標辨識、出站選擇與失敗位置。規則未命中時檢查條件與順序；標籤不存在時檢查參照；憑證錯誤時檢查時間與伺服器身分；資料庫讀取失敗時檢查檔案路徑與分類。不同核心的訊息用語可能不同，不要把網路上常見的錯誤描述當成唯一判斷標準，應配合這次請求的上下文分析。

複雜設定最有效的回復方式，是逐層還原。先驗證第一章的本機直連基準設定，再加入目標出站，接著恢復少量路由，最後才還原 DNS 與策略調整。若使用圖形介面用戶端，可透過獨立測試項目保留正式使用的項目，不必手動替換整份執行檔案。每個還原步驟都要建立新連線並記錄結果，避免舊工作階段繼續使用先前的出口，影響判斷。

單次連線成功，不代表設定整體都正確。至少測試一個預期直連的目標、一個預期使用其他出口的目標，以及需要長時間維持的應用程式；若啟用了 UDP 或 TUN，也應分別驗證對應流量。驗證範圍應符合這次變更內容，不要因為 TCP 網頁正常，就推論所有流量都正常。若只有特定應用程式失敗，可繼續查閱疑難排解，依入口機制逐步縮小範圍。

排查結束後，請恢復適當的記錄層級、移除暫存網域對應與測試規則，並確認用戶端重新啟動後仍能載入相同設定。將最後確認有效的修改更新至長期維護的來源，不要只留在產生檔案中。若要了解核心的歸屬，可參閱Project V、V2Fly 與 Xray 生態關係；維護設定的目標，是讓每項行為都能說明、重測與回復，而非不斷增加欄位。