V2Ray 設定檔參考

JSON 結構總覽：先了解資料流

V2Ray 設定不是一組互不相關的開關。應用程式先連上入站，核心再依目標資訊選擇路由，並交由特定出站處理；DNS 為需要解析的環節提供結果，策略與日誌則負責管理連線及觀察問題。先沿著這條資料流讀一遍，比逐一背誦欄位更實用。同樣是連線失敗，可能是應用程式沒有進入入站，也可能是出站無法完成交握，兩者不該用同一種方式處理。

頂層物件與欄位用途

頂層必須是單一 JSON 物件。inbounds 和 outbounds 是陣列，可分別定義多個入口與出口；routing、dns、policy、log 通常是物件。不要把入站的 listen 放進出站，也不要將路由規則直接放在頂層。編輯器能識別括號，只能證明檔案可能可以解析，不能證明欄位位置正確。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

上方的結構片段呈現欄位關係，但沒有本機監聽入口，無法直接讓瀏覽器連線。空陣列本身是合法 JSON，但其執行意義仍須視核心的預設行為而定。閱讀他人提供的片段時，先確認它要替換哪個欄位，再決定要覆寫整個陣列，還是只新增其中一個物件。把兩份完整物件直接接在一起，會變成無法解析的文件。

語法正確不代表設定有效

為方便在不同工具間複製，本頁統一使用嚴格 JSON：鍵名與字串使用英文雙引號，陣列最後一個項目後不加逗號，說明文字不放進程式碼區塊。某些讀取器允許註解，不代表訂閱處理器和其他核心也能接受。布林值請寫成 true 或 false，不要加引號當成字串；數字和字串也不要只憑外觀互換，欄位要求仍須以對應核心為準。

同一個物件內不要重複使用鍵名。例如寫了兩次 routing，不同處理器可能會覆蓋前一項，也可能直接拒絕讀取；表面上看似有兩組規則，實際可能只有一組生效。合併設定時，應將規則放在同一個 rules 陣列中。陣列順序也有實際影響：出站的第一項可能決定預設出口，較前面的路由規則可能先攔截連線，不宜使用自動排序工具任意整理。

標籤是不同設定區段之間的連結點。出站定義了 direct，路由才能用 outboundTag 指向它；標籤的大小寫與拼法必須一致。建議為每個入站、出站設定穩定且唯一的標籤，後續日誌與分流都會依標籤識別。標籤只是名稱，不會因為叫作 proxy 就自動具備代理功能，實際行為仍由該物件的通訊協定與設定決定。

保留設定來源，再開始編輯

在圖形化用戶端中，訂閱記錄、介面設定與執行設定通常不是同一個檔案。請先保留可供還原的用戶端備份，再查看這次啟動實際產生的內容。不要在核心執行時修改暫存檔，就以為下次啟動還會保留。能透過介面完成的修改，請優先在對應設定頁面儲存；必須使用自訂設定時，再透過用戶端提供的入口載入。

每次修改前，先寫下預期結果，例如「這個網域使用直連出口」，而不是「改善網路」。接著只修改與目標相關的設定區段，重新載入後以相同的連線操作驗證。如此一來，就能分別找出語法錯誤、欄位不相容或規則未命中的原因。若尚未建立首次連線，請先回到教學主線完成基本驗證，不必同時加入複雜規則。

用戶端與核心：先確認設定格式

V2Ray 常被用來泛指整個生態系，但用戶端介面與實際負責執行連線的核心並不是同一回事。v2rayN 負責桌面上的訂閱管理、設定選擇與執行控制，核心則負責解析設定、建立連線及執行路由。介面上有相似選單，不代表底層支援完全相同。查閱欄位前，先確認目前執行的是哪個核心，再確認用戶端是否會將介面選項轉換成其他格式。

V2Fly 與 Xray 的共通結構與差異

Project V 生態系中的 V2Fly 與 Xray 有共同的歷史背景，也保留不少相似的 JSON 結構。不過，通訊協定實作、傳輸參數、額外功能及欄位演進並不同步。本頁範例以常見的傳統 JSON 結構說明基本概念，不保證所有擴充欄位都能跨核心複製。特別是設定涉及 VLESS、XTLS、REALITY 等項目時，必須逐一確認所用核心與對應通訊協定組合是否支援。

Android 上的 v2rayNG 主要使用 Xray 核心，v2flyNG 則是採用 V2Fly 核心的替代用戶端。桌面環境可優先從 v2rayN 開始，實際使用哪個核心仍應符合你的設定需求。不要因為某個用戶端能成功匯入連結，就推定它能完整執行連結中的所有參數；匯入解析、產生設定與核心啟動，是三個都必須分別通過的環節。

圖形化設定不等於原始 JSON 的鏡像

用戶端可能透過一個下拉選項組合多個欄位，也可能隱藏由程式管理的標籤與連接埠。例如介面中的路由模式，可能對應整組規則，而不是某個名為「模式」的頂層鍵。修改產生的檔案後再切換模式，原先的變更可能會被覆寫。閱讀設定時，應分辨哪些值來自目前節點、哪些來自全域設定，以及哪些由用戶端在啟動時自動補上。

自訂設定也不一定支援用戶端的所有代管功能。有些匯入方式會以完整設定執行，另一些則只把它當成單一連線項目。系統代理所指向的本機連接埠、用戶端用來檢查狀態的入口，以及統計功能所需的標籤，都可能另有約定。若介面顯示已啟動，但應用程式無法連線，請先核對實際監聽的連接埠，不要立刻認定遠端伺服器故障。

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

這段出站設定代表直接連線，適合用來說明通用欄位，但不代表完整的遠端連線設定。它也說明判斷設定相容性的方法：先看通訊協定名稱，再看該協定的 settings，最後檢查傳輸相關參數。只替換通訊協定名稱、卻保留原協定的設定物件，通常無法得到正確結果；不同協定使用的伺服器、驗證與傳輸欄位應一起核對。

遷移設定時逐項確認功能

切換核心前，先列出目前實際使用的通訊協定、傳輸方式、路由資料庫、DNS 策略與入站功能。確認新核心支援這些功能後，再用單一設定進行小範圍測試。不要一次替換整份設定，然後只憑介面是否顯示啟動來判斷遷移成功。核心雖然可能順利啟動，少見的路由、特定 UDP 使用情境或額外傳輸行為仍可能與原先不同。

路由資料庫同樣是相容性的一環。設定中寫了 geosite:cn，仍須確認目前核心能找到對應資源，且檔案中包含這個分類。用戶端更新規則資源的目錄，不一定就是另一個核心尋找資源的目錄。手動遷移時不能只帶走 JSON，也要確認資源載入位置；不要任意將不同格式的資料檔改名混用。

排錯時先記下「用戶端名稱、實際核心、設定來源、錯誤欄位」這四項資訊，通常比一張首頁截圖更有幫助。需要選擇安裝檔，請前往用戶端頁面；想進一步了解兩種核心的取捨，可閱讀Xray 與 V2Fly 核心差異。不要把更換用戶端當成通用解法，先確認它是否能解決具體的相容性問題。

inbounds 入站：定義應用程式連線入口

入站決定應用程式如何將連線交給核心。常見的本機入口是 SOCKS 與 HTTP 代理，應用程式必須使用正確的通訊協定和連接埠連線。入站連接埠不是遠端伺服器連接埠，在本機監聽也不代表遠端連線已經成功。排錯第一步是確認應用程式確實連到這個入口；如果要求根本沒有進入核心，繼續調整出站驗證參數也不會改變結果。

本機位址、連接埠與通訊協定須一併確認

{
  "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 的應用程式連接 10808，使用 HTTP 代理的應用程式連接 10809，這兩個連接埠不能任意互換。這裡的數值只是範例，不代表你的用戶端一定使用相同連接埠。若介面顯示其他值，請以實際執行設定為準，並同步修改應用程式的代理位址。

當 listen 設為 127.0.0.1 時，其他裝置無法透過區域網路位址存取這個入口。若改成通用監聽位址，接入範圍就不再限於本機，必須一併考慮驗證、防火牆與可信任網路範圍。上方的 SOCKS 範例使用免驗證模式，只適用於明確限制在本機的情境，不應原樣改成對外開放的共用代理。

啟用 UDP 不代表整條連線都支援 UDP

SOCKS 設定中的 udp 允許入站處理相應的 UDP 要求，但最後能否完成通訊，還取決於應用程式是否確實使用 SOCKS 的 UDP 功能、出站通訊協定是否支援，以及遠端網路是否允許。HTTP 代理入口通常用於 HTTP 要求與通道連線，不等同於通用的 UDP 入口。若瀏覽器正常、某個即時應用程式卻無法連線，應先分辨兩者使用的傳輸類型。

同樣地，系統代理只是將代理入口提供給遵循系統設定的應用程式，不會自動接管所有流量。有些程式會讀取自己的代理設定，有些則直接連線。TUN 是另一種接管方式，涉及虛擬網路介面、權限、路由與 DNS 配合，不能只靠新增 SOCKS 入站來取代。要判斷哪些流量受到影響，應從特定應用程式的流量入口查起，而不是只看系統匣狀態。

嗅探可提供網域線索，但無法辨識所有連線

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    }
  ]
}

嗅探會嘗試從已接收的流量中擷取通訊協定或網域資訊，協助核心處理只帶有目標 IP 的連線。它不是解密工具，也不能保證所有連線都能還原網域。某些交握方式、加密中繼資料，或非 HTTP、TLS 流量，都會限制辨識能力。啟用後還須確認目前核心如何處理目標覆寫；不能把「可供路由使用的網域線索」和「實際連線目標」視為同一回事。

為入站設定穩定的標籤，也有助於依入口進行分流。例如，獨立的測試入口可以搭配路由的 inboundTag，只影響從該入口進入的連線。不過規則仍會依序執行；如果前面已有範圍更廣的比對，入口專用規則可能沒有機會命中。新增入口時就應決定標籤，避免日後改名卻漏改引用它的路由。

驗證入站時，先使用明確支援手動代理的應用程式，設定本機位址和對應連接埠，再觀察日誌是否出現要求。沒有紀錄時，檢查應用程式設定、監聽位址與防火牆；有紀錄但接著出錯，再檢查出站與解析。若只有區域網路裝置無法連線，則另外確認綁定位址與存取範圍。把這三類問題分開，通常能減少不必要的設定修改。

outbounds 出站：區分連線方式與標籤

出站負責處理連線後，決定如何存取下一個目標。它可以直接連線、依遠端通訊協定建立連線，或明確阻擋要求。入站處理「應用程式如何進入」，出站處理「核心如何連出去」，兩者不必使用相同通訊協定。應用程式透過 SOCKS 入站進入核心後，可以被路由至不同類型的出站；因此，看到本機 SOCKS 連接埠，不代表遠端也使用 SOCKS。

先建立直連與阻擋兩種基本出口

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

freedom 表示由核心直接連線至目標，blackhole 則用來丟棄分配至該出口的流量。direct 和 block 都只是本例的標籤，你可以更改名稱，但必須同步修改路由引用。阻擋出口適合用來表達明確的拒絕策略，不應作為連線失敗時的自動備援；若規則誤將常用要求送到這裡，應用程式可能只會出現逾時或連線中斷。

在傳統設定行為中，未被規則選中的流量通常會交由出站陣列中的第一個出口處理。上方範例的第一項是直連，因此預設結果也是直連。把遠端出站加到陣列末尾，不會自動讓所有要求改走遠端。調整預設出口前，先確認用戶端是否另外產生了備援規則，或使用負載平衡等額外機制；不能只根據陣列順序推斷所有情況。

遠端參數必須完整成組保留

VMess、VLESS、Trojan 等通訊協定使用的驗證與傳輸欄位並不相同。遠端位址、連接埠、使用者資訊、傳輸類型及 TLS 相關參數，都必須符合伺服器的實際設定。不要把某個連結中的驗證資訊搬到另一種通訊協定物件，也不要只為了讓設定通過解析就刪除不認識的欄位。成功解析只能代表格式被接受，無法證明雙方的交握設定一致。

遠端使用 TLS 時，連線位址、交握所用的伺服器名稱，以及應用層要求中的主機欄位，可能各有不同用途。它們有時相同，但不能只因為看起來都是網域就混為一談。傳輸路徑也可能由伺服器明確指定。請以取得的完整設定為準逐項比對；任意替換名稱或路徑，往往只會把原本明確的錯誤變成多處不相符。

錯誤發生在哪個層級

連線分配至某個出站後，還可能依序經過網域解析、建立底層連線、TLS 交握、通訊協定驗證與資料傳輸。某個步驟失敗，不應直接歸咎於「節點無法使用」。例如本機解析失敗時，連目標位址都還沒取得；底層連接埠可連，也不代表通訊協定驗證一定成功。查看日誌時，應找出最早出現的具體錯誤，而不是只複製最後一行摘要。

測試直連與遠端出站時，應使用不同且明確的目標。先讓同一個本機入站連上一個已知可直連的頁面，確認應用程式到核心這一段正常；再選擇已設定的遠端出站，觀察路由與交握結果。若兩種測試都失敗，優先檢查共用的入站或用戶端執行狀況。只有遠端路徑失敗時，再檢查遠端欄位、網路條件與通訊協定相容性。

不要把略過憑證驗證當成預設的排錯步驟。憑證名稱、系統時間、信任鏈與伺服器設定都可能影響 TLS；直接停用驗證會掩蓋真正的不相符。請先確認連線資訊來源與裝置時間，再依日誌處理具體原因。也不要將含有驗證資訊的完整 JSON 發布到公開討論區；說明問題通常只需要通訊協定類型、欄位名稱與已去除敏感資訊的錯誤訊息。

在用戶端中，更新訂閱可能會重新寫入遠端出站，因此要長期保留的本機路由，應盡量透過用戶端支援的方式管理。需要安裝用戶端時，請前往下載頁面；匯入後的驗證順序請參閱v2rayN 首次連線檢查清單。先讓出站維持精簡，單一路徑驗證通過後再加入複雜組合。

routing 路由：依序判斷連線

路由優先順序不是由規則數量決定，而是依設定順序判斷。通常會由上往下搜尋，遇到符合條件的項目就選擇其出口，後續規則不再參與這次判斷。因此，具體例外應放在範圍較廣的分類之前。某個網域明明設定為直連，卻仍走遠端時，先檢查前面是否已有涵蓋範圍更廣的規則，比反覆重新啟動用戶端更有效。

規則順序與標籤引用

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "block"
      }
    ]
  }
}

本例依賴已存在的 direct、block 出站，以及可載入的 GeoIP、GeoSite 資料。最後一項會將其餘 TCP、UDP 連線送往阻擋出口，代表一種明確限制流量的策略，並非建議所有使用者採用的預設方案。若希望其他連線走既有遠端出口，請引用該出站實際使用的標籤，並確認它確實存在；不要自行新增一個名為「代理」的標籤。

同一條規則中的不同條件欄位通常必須同時符合；同一清單中的多個候選項目，通常則用來比對其中任一項。例如規則同時設定 inboundTag 和 domain，代表連線必須從指定入口進入，且符合指定網域，而不是兩者擇一即可。把多個不相關條件塞進同一條規則，可能導致永遠無法命中。要表達兩條獨立路徑時，應拆成兩個規則物件。

選擇正確的網域比對方式

domain:example.com 用來比對該網域及其子網域，full:example.com 則用於精確比對完整網域名稱。一般字串與正規表示式的比對方式不同，不能只因某次成功比對，就認定範圍正確。一般網域分流優先使用明確的網域比對格式，避免過短的關鍵字誤中其他網域；需要使用正規表示式時，再另外驗證範圍與跳脫字元。

JSON 字串本身會處理跳脫字元，正規表示式也會處理跳脫字元，因此從其他工具複製規則時要特別小心。先確認正規表示式在 JSON 中實際形成的字串，再確認核心如何解讀它。若只想比對某個網域及其子網域，就不必為了簡短而使用複雜的表示式。規則越容易閱讀，日後找出誤比對的原因就越不必猜測。

domainStrategy 決定何時使用 IP 資訊

AsIs 不會為路由而主動將網域解析成 IP，但已知 IP 的連線仍可參與 IP 規則比對。IPIfNonMatch 會在網域階段沒有比對結果時，再嘗試解析並依 IP 條件判斷；IPOnDemand 則會在比對過程需要 IP 資訊時觸發解析。這些選項改變的是路由階段的解析時機，不等於全域切換裝置 DNS，也不等於指定遠端出口。

尤其要留意兜底規則的影響。如果網域階段已被一條範圍廣泛的規則接住，IPIfNonMatch 可能就沒有機會進行解析後的比對。於是你以為私有 IP 規則會處理某個網域，實際上它可能先被最後一條網路兜底規則選走。設計規則時要明確區分哪些目標依網域分類處理，哪些必須在解析後檢查位址，不能只看欄位名稱推測執行順序。

維護規則時，將「本機位址、明確例外、用途分類、最後兜底」依易讀順序排列，每次只新增或修改一種類型。規則資源更新後，也應重新測試少量代表性目標，因為分類內容可能改變。若資源缺失或找不到分類，先處理啟動日誌，不要刪除所有分流規則來掩蓋問題。資源維護方式可接著參閱GeoIP 與 GeoSite 資料庫更新說明。

最後透過日誌核對目標網域、入口標籤與所選出站。瀏覽器成功開啟頁面，還不足以證明規則選中了預期出口，因為直連與遠端連線可能都能成功。若路由結果不符，先檢查實際載入設定中的規則順序，再確認應用程式是否提交網域，最後檢查資料庫。依這個順序排查，可避免把缺少網域資訊誤判為分類錯誤。

dns 設定：分辨由誰解析網域

一次連線可能涉及多個解析者：應用程式自行解析、作業系統解析、核心內建 DNS 解析，或由遠端連線端解析。設定中有 dns，不代表裝置上的所有查詢都會經過它。先確認應用程式交給入站的是網域還是 IP，再判斷這段設定是否參與目前的要求。否則，修改核心 DNS 卻觀察系統解析結果，很容易得出錯誤結論。

servers 與 queryStrategy 的基本用途

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIPv4"
  }
}

這裡設定一個明確位址的解析器和本機系統解析入口，並將核心支援的查詢位址類型限制為 IPv4。localhost 在這裡代表使用本機系統解析機制，不是遠端主機名稱。伺服器清單也不能簡單理解成「第一項失敗才試第二項」的固定主備關係；實際的選擇、並行與回退行為，須視伺服器物件、比對網域與目前核心的實作而定。

UseIPv4 不是效能最佳化口訣，而是選擇位址類型。如果目標只有可用的 IPv6 位址，限制使用 IPv4 可能會讓它完全無法連線；如果裝置的 IPv6 路徑有問題，允許雙堆疊也可能引發另一類連線失敗。應先確認本機網路與遠端路徑支援哪些功能，再設定查詢策略。這個欄位也不會自動停用系統的 IPv6，不能用來取代裝置網路管理。

依網域選擇解析器

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": ["domain:example.com"]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

伺服器物件可用來設定特定網域的解析方式。範例將 example.com 及其子網域設為指定伺服器的比對範圍；其他查詢仍須配合完整的回退邏輯判斷。domains 不是路由中的 domain 欄位，不能因內容相似就互換名稱。較複雜的伺服器物件還可能涉及預期位址與回退設定，新增前請確認對應核心支援其確切語意。

也要確認解析器的網路可達性。明文 DNS、加密 DNS 與本機解析入口，可能經過不同的連線路徑；有些形式會受到一般路由影響，另一些則具有本機處理語意。不能一概而論地說「放進 servers 就一定走代理」。如果解析器位址本身需要網域解析，也要考慮啟動階段如何取得它的位址，避免解析依賴自身而形成無法完成的循環。

快取、嗅探與 FakeDNS 的範圍

修改解析策略後，應用程式、系統與核心可能仍保留舊快取，既有連線也可能繼續沿用。驗證時應建立新連線，必要時依各程式的方式清除快取，不要只重新整理同一個頁面一次。若瀏覽器使用獨立的加密解析，看到的結果可能與系統不同。先確認測試工具使用哪條解析路徑，再比較結果，才能判斷修改是否確實作用於要求。

FakeDNS 透過虛擬位址保存網域對應關係，目的是協助後續流量還原網域資訊，而不是向公網分配真實目標位址。它必須搭配流量接管方式、對應回收與嗅探設定，不能只開啟一個欄位就期待所有應用程式都能正常運作。若某個程式繞過預期入口，取得虛擬位址後直接連線，就可能失敗。一般系統代理已可正常使用時，不必為了增加欄位而啟用它。

DNS 排錯可分三步：先確認是否取得解析結果，再確認結果是否適用於目前網路，最後確認連線使用了哪個結果。日誌出現解析逾時時，先檢查解析器是否可連線；取得位址但連線失敗時，再檢查位址類型、出站與遠端路徑。相關原理可參閱FakeDNS 運作原理與適用情境。不要把所有連線失敗都歸咎於 DNS。

設定穩定後，保留一小組能代表不同解析路徑的目標作為回歸測試。每次更換伺服器、查詢策略或流量接管模式，都用相同目標重新驗證。解析結果會隨伺服器調度而變動，不必要求位址永遠相同；真正要確認的是解析能順利完成、回傳位址可用，而且連線符合預期的路由範圍。

policy 與日誌：管理連線並保留紀錄

policy 負責連線管理與統計相關策略，不負責決定某個網域要走哪個出口。路由異常應先檢查 routing，驗證異常則先檢查出站；不要因為策略中有「逾時」欄位，就把所有連線失敗都歸因於等待時間不足。大多數一般使用情境可以先保留預設策略，待日誌明確顯示連線生命週期不符合需求時，再進行針對性調整。

等級策略如何套用至連線

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

這裡的等級鍵 "0" 是物件鍵，因此必須加上雙引號。連線使用哪個等級，須視對應通訊協定支援的使用者等級設定而定；有些入站透過 userLevel 關聯，有些協定則將等級放在使用者物件中。只新增等級物件，不會自動將所有連線切換到該等級。本例數值僅用於說明欄位，並非適用所有網路環境的統一建議值。

handshake 與建立連線時的交握等待時間有關，connIdle 控制連線閒置時間，uplinkOnly 和 downlinkOnly 則涉及單向傳輸狀態下的保留時間。這些時間通常以秒為單位，實際作用仍取決於通訊協定與連線階段。把所有數值都調得很大，可能只會讓無效連線占用資源更久，無法修復錯誤的伺服器位址或驗證參數。

統計開關不等於完整的統計服務

策略中的統計布林值只負責允許記錄某類資料；若要完整讀取，可能還需要統計模組、使用者識別、介面設定及用戶端的呼叫方式。開啟幾個開關，不代表介面就會立即顯示所有統計資料。使用圖形化用戶端時，優先保留由它管理的統計設定，避免手動修改標籤或刪除介面，導致介面無法再與核心通訊。

也不要為了查看統計資料而任意開放管理介面。是否監聽、綁定哪個位址、哪些人可以存取，都必須個別評估；管理介面不是一般應用程式代理入口。若用戶端已提供流量資訊，通常不需要另外建立可供外部存取的介面。本頁的基準範例不包含管理介面，目的是讓連線路徑保持清楚，而不是提供完整的監控部署方案。

日常使用 warning，需要時短暫提高詳細程度

{
  "log": {
    "loglevel": "warning"
  }
}

日常使用 warning 可減少一般輸出。排錯時若需要觀察要求的去向，可暫時切換至更詳細的日誌等級，再重現一次問題。不要長時間保留過多的除錯日誌，因為其中可能記錄目標位址與連線細節，也會增加儲存空間負擔。找出問題後，請恢復一般等級，並依用戶端提供的方式處理不再需要的日誌。

{
  "log": {
    "access": "access.log",
    "error": "error.log",
    "loglevel": "info"
  }
}

這段設定會將存取與錯誤輸出寫入相對路徑的檔案。相對路徑通常取決於程序的工作目錄，不一定位於你開啟 JSON 的資料夾；用戶端也可能另行管理輸出。使用前請確認目錄可寫入、檔案位置可找到，並留意日誌會持續增加。若日誌路徑無效導致啟動失敗，請先恢復用戶端預設的輸出方式，不要在沒有證據時反覆修改連線參數。

閱讀日誌時，依時間順序還原一次連線過程：核心是否啟動、入口是否收到連線、路由選擇了哪個出口、解析是否成功，以及交握在哪個步驟失敗。若第一個明確錯誤是無法識別設定欄位，後續連線狀態就沒有分析價值；若核心正常啟動但沒有連線紀錄，應回頭檢查應用程式入口。先找出最早發生的明確異常，再決定要修改哪個區段。

行動裝置還要區分程序生命週期與連線策略。應用程式遭系統回收、背景權限受限或網路切換，都不能只靠延長 connIdle 解決。若螢幕關閉後連線中斷，可參考v2rayNG 背景執行與電池設定檢查系統層級的條件。只有在核心仍持續執行、連線確實由它管理時，策略參數才有討論意義。

驗證與還原：用最小設定找出問題

驗證設定時，先將「核心能否啟動」與「目標能否連線」分開處理。前者主要檢查 JSON、欄位相容性、資源與監聽條件；後者還涉及應用程式接入、解析、路由及後續連線。以下提供一份本機直連基準設定，只用來確認應用程式能否透過核心連上原本就可直連的目標，不含遠端代理功能，也不需要 GeoIP、GeoSite 資源。

完整的本機直連基準設定

{
  "log": {
    "loglevel": "info"
  },
  "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": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

先備份目前的用戶端設定，再透過用戶端明確支援的完整自訂設定入口載入這份基準設定。不要將它貼到只接受單一節點欄位的輸入框中。若用戶端會管理連接埠或另有設定產生規則，請依實際設定方式操作，避免同時執行兩個核心而爭用連接埠。載入後，選擇支援手動代理的應用程式，將它指向對應的本機入口，再連線至已知可直連的目標。

逐層驗證，不要同時改動多個變數

若基準設定無法啟動，先查看最早出現的錯誤。語法錯誤請檢查括號、逗號與雙引號；連接埠占用則檢查其他程序；欄位無法識別時，確認核心類型與設定格式。此時不要新增 DNS、嗅探或更多出站，否則只會增加錯誤來源。最小設定的價值，在於將原本交錯的問題拆解成幾個可以分別確認的環節。

若核心啟動成功，但應用程式無法連線，先查看日誌中是否有這次要求。沒有要求紀錄時，檢查應用程式的代理通訊協定、位址與連接埠；有要求但解析失敗時，檢查系統解析與目標網域；取得位址卻無法連線時，再檢查本機網路與目標服務。此階段尚未設定遠端出站，因此不必檢查遠端驗證或傳輸參數。先確認基準設定正常，後續比較才有意義。

基準設定可用後，還原既有的遠端出站，並新增一條明確指向它的路由。先驗證單一遠端連線，再逐步加入網域分類、DNS 物件及其他策略。每新增一組設定，都執行相同的連線操作並記錄結果。若新增某個區段後開始失敗，只要還原該區段即可縮小問題範圍，不必重新設定已驗證正常的入站。

重新載入設定與既有連線

修改設定後，須依用戶端支援的方式重新載入設定或重新啟動核心。已建立的長連線、瀏覽器連線集區與應用程式快取，可能仍保留舊狀態，不能只憑仍在播放的頁面判斷新規則無效。驗證時請建立新連線，必要時關閉對應應用程式後再試，但不必每修改一個欄位就重新啟動整台裝置。先用小範圍操作確認設定已切換，效率更高。

系統代理與 TUN 也應分開驗證。先用一種明確的接入方式完成測試，再切換至另一種，避免兩套接管機制疊加後無法判斷流量從哪裡進入。桌面與 Android 的系統整合方式不同，但檢查順序相同：入口、解析、路由、出口。若只有某個應用程式不受影響，應優先確認它的代理適用範圍，而不是直接判定整個核心失效。

還原時，請恢復整組相關欄位

有效備份不只是一個 JSON 檔案，還應包括設定來源、目前核心、所需資源與用戶端相關設定。還原路由時，須恢復完整規則順序；還原出站時，須恢復通訊協定與配套傳輸欄位；還原 DNS 時，也要檢查應用程式是否使用獨立解析。不要只撤銷最後一個看得見的值，卻留下指向已刪除標籤的規則；相關欄位不完整會帶來新的錯誤。

最後保留一份簡短的變更紀錄：修改目標、涉及欄位、驗證方式與結果。紀錄不必包含帳號資訊，也不用保存每次的完整日誌。下次遇到相似狀況時，先沿用已驗證的基準，再比較新增部分。首次使用請回到教學，常見連線問題請參閱連線故障問答；本頁則是查閱欄位與執行關係的入口，依實際問題返回對應章節即可。