V2Ray JSON 設定教學

一、JSON 結構與設定生效範圍

先分清用戶端與核心

v2rayN、v2rayNG 和 v2flyNG 是管理設定的圖形用戶端；實際接收連線、比對規則並轉送資料的是核心。用戶端介面中的訂閱、設定清單、系統代理與路由預設，不一定能在檔案中找到一一對應的物件。閱讀 JSON 前，請先從用戶端執行資訊或啟動記錄確認核心名稱，再判斷目前項目使用的是自動產生的設定，還是自訂設定檔。

傳統設定的頂層通常是一個物件，內部依職責分為 log、inbounds、outbounds、routing、dns 與 policy。入站與出站採用陣列，因為單一程序可以提供多個本機入口，也可以選擇多個轉送出口。請勿將陣列的方括號改成大括號，即使陣列目前只有一個項目也一樣。

以最小設定建立基準

以下是本機 SOCKS 入站轉為直連出站的基準設定。這份設定可用來確認核心能否啟動、本機是否成功監聽，以及應用程式能否接入，但不會建立遠端代理連線。測試時，請指定應用程式使用本機 SOCKS 連接埠，並選擇允許直接連線的目標。確認基準設定正常後，再加入遠端出站、路由與 DNS，才能判斷新增欄位造成的變化。

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

JSON 的字串與鍵名都要使用雙引號；布林值寫成 true 或 false，連接埠數字不要附上單位文字。標準 JSON 不支援註解，也不允許在最後一個項目後保留逗號。部分核心的讀取器可能接受擴充語法，但設定經過用戶端匯入、訂閱轉換或其他工具處理時，仍可能依嚴格 JSON 解析，因此手動編輯的檔案最好維持標準格式。

頂層物件出現重複的同名鍵，是另一種不易察覺的問題。部分解析器會保留最後一個值，部分工具則會拒絕讀取；無論是哪種情況，都不適合用來疊加設定。例如，寫入兩個 routing 物件，不代表兩組規則會自動合併。要新增規則，請修改同一個 rules 陣列，並明確安排新規則的位置。

選對編輯入口，修改才不會被覆蓋

自動產生的設定通常由用戶端依據目前節點、路由預設與選項重新組合。直接修改執行目錄中的暫存檔，可能只在目前的啟動期間生效；切換節點、更新訂閱或重新啟動服務後，檔案便可能遭到覆蓋。需要長期保留的調整，請寫入用戶端支援的自訂入口，或另存為獨立設定，再透過對應的自訂設定功能載入。

自訂設定也有其限制。用戶端介面顯示的本機連接埠、路由模式或 DNS 選項，不一定能覆蓋自訂檔案中的欄位；反過來說，部分介面功能仍可能產生外層執行參數。判斷依據不是設定頁是否勾選，而是核心實際載入的設定與記錄內容。首次切換設定模式時，請先暫停原有連線並記下設定來源，再重新啟動確認。

不同核心共用部分欄位名稱，不代表完整設定可以直接互換。擴充協定、傳輸方式、DNS 選項與策略預設值都可能不同。遷移時，請先保留入站、直連與封鎖等基本設定，再逐項加入目標核心確認支援的功能。解析錯誤應優先依欄位路徑排查；核心尚未成功啟動前，請勿同時更換伺服器或訂閱。

二、inbounds：本機監聽與應用程式接入

先確認監聽位址與連接埠，再檢查協定

入站設定說明核心從哪裡接收連線。單機使用時，應先確認 listen 與 port：前者決定要繫結的本機位址，後者決定應用程式需要連線的連接埠。設定正確不代表一定能成功繫結；若另一個用戶端、舊核心程序或其他服務占用相同位址與連接埠，啟動仍會失敗，記錄通常會指出監聽錯誤。

127.0.0.1 僅供本機存取，適合作為預設值。若將監聽位址改為 0.0.0.0，監聽範圍會擴大至所有 IPv4 網路介面；但其他裝置能否連線，仍取決於防火牆與網路環境。擴大監聽範圍並不是解決本機連線問題的常見方法。若確實需要區域網路接入，請一併考量驗證機制、允許的來源，以及裝置所在網路是否可信。

SOCKS 與 HTTP 是不同的入口協定

SOCKS 入站適合可明確設定 SOCKS 代理的應用程式；HTTP 入站則供採用 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": {}
    }
  ]
}

範例提供兩個互相獨立的入口；其中的連接埠只是本文採用的設定，並非所有用戶端都固定使用這些連接埠。實際操作時，請先查看目前用戶端的本機監聽設定，再填入應用程式代理。瀏覽器擴充功能、系統代理頁面與終端機環境變數也可能各自指向不同連接埠。排查時，請記下正在測試的應用程式讀取哪一處設定，避免只修改到未使用的入口。

SOCKS 的 udp 表示允許相應的 UDP 接入能力，不代表所有應用程式的 UDP 流量都會自動進入核心。應用程式本身必須支援並實際使用 SOCKS UDP，後續出站與網路路徑也必須能承載這類流量。只開啟這個欄位，通常無法解決需要系統層級流量接管的情境。Android 的 VPN 接入與桌面應用程式手動設定本機代理，使用的入口機制並不相同。

tag 與 sniffing 的作用範圍

tag 是入站的邏輯名稱，可供路由中的 inboundTag 參照。它不是監聽連接埠，也不會因為改名就改變連線方式。建議使用能反映用途的名稱，並確保名稱不重複。若將 local-socks 改成其他字串，所有依此名稱篩選連線的規則也要一併修改，否則相關規則會失去比對對象而不易察覺。

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

上方物件屬於單一入站的內部設定。嗅探功能會嘗試從支援的初始流量中取得目標網域名稱，例如 HTTP 主機資訊或 TLS 交握中的伺服器名稱，供後續分流使用。這不等於解密 HTTPS，也無法保證取得每條連線的網域名稱。若資料不具備相應特徵、應用程式採用不同的交握形式，或連線尚未提供足夠資訊，就可能無法得到預期結果。

不同核心對嗅探選項的支援有所差異，部分選項還會影響目標位址是否遭到替換。請勿為了讓網域規則生效，就一次開啟所有欄位。先確認應用程式是否已將網域名稱提交給代理，再判斷是否需要嗅探；如果原本就有提交網域名稱，問題更可能出在規則順序或出口選擇。若嗅探僅用於路由，請確認目前核心支援對應設定。

驗證入站時，先使用單一測試應用程式與單一入口，並暫時停用該應用程式的其他代理外掛。如果記錄中沒有連線，就先別調整遠端出站；流量尚未進入核心，即使伺服器參數完全正確也無法改善結果。瀏覽器與終端機的分別檢查方式，請參閱系統代理未生效的排查清單。

三、outbounds：出口標籤與遠端協定

出站代表處理動作，不是規則

出站定義連線離開核心時採用的方式。常見類型包括直接連線目標的 freedom、拒絕連線的 blackhole，以及使用遠端伺服器的協定出站。路由負責選擇出站，出站負責執行轉送，兩者不能互相取代。新增名為 proxy 的出站，不代表所有連線都會自動選用它；最終仍由預設出口與路由規則決定。

在常見的傳統設定中，未符合路由規則的連線會使用出站陣列的第一個項目，因此陣列順序會影響實際行為，不只是顯示順序。整理設定時，若把 direct 移到第一個位置，原本依賴第一項代理的預設行為就會改變。建議在編輯記錄中註明預設出口，並在每次新增規則後，以未被規則涵蓋的測試目標確認預設路徑。

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

這段片段只有直連與封鎖，適合用來理解出口選擇，不包含遠端服務。封鎖出站可用來明確拒絕特定連線，但請勿將所有「連線失敗」都視為遠端網路問題。若路由錯把目標送往 block，更換伺服器也無法解決。排查時，請先查看連線實際選用的標籤，再檢查該出口的撥號或交握資訊。

遠端欄位應成組核對

遠端出站的協定、位址、連接埠、身分欄位、傳輸方式與安全層彼此相關，應一併核對。分享連結雖可攜帶多數資訊，匯入過程仍可能受到格式差異影響。匯入後若無法連線，請逐項比對用戶端編輯頁與原始提供的資訊，特別檢查傳輸路徑、伺服器名稱或流控選項是否遺漏，而不只是確認位址與連接埠。

以下是傳統 VLESS 出站的結構教學範例。網域 example.com 與全零識別碼僅用來說明欄位位置，不對應可連線的服務。實際遠端設定應由可信任的服務設定匯入；請勿將範例身分欄位或伺服器名稱用於日常連線，也不要把其他協定的使用者欄位直接搬到這個物件中。

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

encryption 的值必須依協定解讀。範例中的 none 是此 VLESS 結構使用的欄位，不代表關閉外層 TLS 後仍能獲得相同的傳輸保護。VMess、Trojan 與 VLESS 的驗證方式及欄位層級各不相同，不能只替換 protocol 就完成轉換。選用協定時，首要條件是與遠端服務一致，其次才是本機核心是否支援。

標籤參照與用戶端更新的影響

出站標籤必須與路由中的 outboundTag 完全相符，大小寫也不能不同。將設定清單中的顯示名稱改成「代理」，不一定會改變核心的出站標籤；用戶端可能仍固定產生既定標籤。手動編寫路由時，應以最終執行設定為準。參照不存在的標籤可能造成設定錯誤或轉送失敗，請勿仰賴核心自行猜測出口。

更新訂閱會刷新節點參數，手動修改的遠端位址、使用者識別碼或傳輸欄位可能遭到覆蓋。若要長期保留獨立項目，請先了解用戶端複製設定及訂閱歸屬的處理方式，再另存副本。分享連結與訂閱網址的更新機制不同，可參考單節點分享連結與訂閱網址的差異，判斷應在哪個層級修改。

若基本連線已建立，但特定目標仍無法連線，請先保持目前的遠端參數不變，改為比較直連與代理的路由選擇。只有記錄顯示撥號、驗證或安全交握失敗時，才優先檢查出站欄位。分開記錄「所有連線都失敗」與「只有單一目標失敗」，可避免遇到局部路由問題時反覆重建整組節點設定。

四、streamSettings：傳輸與安全層

分開理解協定、傳輸與安全層

閱讀節點設定時，請分清三個層次：代理協定定義雙方如何驗證並表示目標；傳輸層決定資料以何種連線形式承載；安全層則處理交握與加密。protocol、streamSettings.network 與 streamSettings.security 分別屬於不同層次。三者必須相容，但不能只因遠端連接埠是四百四十三，就推斷傳輸必定採用 WebSocket，或安全方式必定是 TLS。

傳輸參數必須與遠端入口相符。原本採用 TCP 的服務，不會因為只在用戶端把 network 改成 ws，就具備 WebSocket 能力。反向代理是否轉送相應請求、路徑是否吻合，以及上游服務是否正在監聽，都是服務端的必要條件。用戶端只能使用既有的接入方式，無法透過本機欄位替遠端服務建立新的傳輸入口。

TLS 網域名稱與伺服器位址

address 是撥號目標，serverName 是 TLS 交握時使用的伺服器名稱；在某些部署方式中，兩者可能不同。憑證驗證通常必須符合有效的伺服器名稱。若位址可以連線，但 TLS 交握失敗，請檢查系統時間、伺服器名稱與憑證狀態，不要先取消驗證。略過驗證會改變信任範圍，也可能掩蓋原本應修正的設定錯誤。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com"
    },
    "wsSettings": {
      "path": "/tunnel",
      "headers": {
        "Host": "example.com"
      }
    }
  }
}

這是傳輸物件的教學片段，其中的路徑與網域不代表實際服務。path 必須與伺服器端路由完全相符，也要確認開頭斜線與大小寫。HTTP 的 Host 與 TLS 伺服器名稱分屬不同階段：前者用於 HTTP 請求路由，後者用於安全交握。有些部署要求兩者相同，但修改其中一個欄位不會自動同步另一個欄位。

路徑也可能包含查詢參數。以文字複製設定時，請完整保留原始內容；分享連結若將部分內容進行 URL 編碼，用戶端編輯頁顯示的可能是解碼後的形式。排查時應比對語意與最終執行欄位，不要混淆編碼後的百分比序列與解碼後的字元，也不要重複編碼，導致遠端服務收到不同路徑。

REALITY 與流控不可混為一談

REALITY 是 Xray 生態系中的安全交握方案，不是可任意替換的代理協定名稱。常見組合仍以 VLESS 作為協定，並在傳輸安全層設定相應欄位。伺服器名稱、公開參數與短識別碼都必須符合伺服器端允許的值；欄位名稱也可能隨核心版本演進而變動，遷移設定時請採用目前核心文件所列的寫法。

XTLS Vision 的流控選項與 REALITY 並非同一欄位，也不是所有傳輸方式都能任意搭配。是否填入 flow，必須依服務端協定組合與用戶端實際使用的核心判斷。若出現驗證或流控相關錯誤，請先還原服務提供的完整參數，再確認組合是否相容，避免把文章中的零散欄位加到另一種傳輸設定上。

想了解兩者的分工，請閱讀REALITY 與 XTLS Vision 原理說明。實際排除問題時，仍應以記錄中的失敗階段為主：撥號失敗先檢查位址；交握失敗再檢查安全參數；接入路徑不符時則檢查傳輸設定。依階段逐步定位，比同時修改傳輸、連接埠與伺服器名稱更容易找出原因。

五、routing：比對順序與分流範圍

先確認預設出口，再新增例外

路由規則通常會依陣列順序由前往後檢查，第一條符合條件的規則就會決定連線去向。系統不會自動尋找文字上「最精確」的規則，也不會綜合計算多條規則的結果。因此，針對單一網域的例外通常應放在範圍較廣的分類規則之前。撰寫分流規則前，先用一句話寫出預設策略，再依優先順序列出例外，可減少反覆調整規則位置。

同一條規則中的不同條件欄位通常必須同時符合；同一個網域或 IP 清單中的多個項目，則用來比對其中任一項。例如同時設定 inboundTag 與 domain，表示連線必須來自指定入口，且目標網域也要相符，而不是兩個條件擇一。這很容易造成「分開測試都符合，合在一起卻沒有命中」的情況。

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

範例僅展示路由片段，假設完整設定已定義 direct 與 block，並安裝可供讀取的網域與 IP 分類資料。若希望未命中的連線交由代理處理，還需將實際遠端代理設為預設出站；這段片段本身並未建立代理。第一條規則會將文件範例網域送往封鎖出口，用來示範精確例外如何優先於後續的一般策略。

網域格式與分類資料

full: 用於精確比對完整網域；domain: 用於比對網域及其子網域；regexp: 則用於正規表示式。裸字串可能採用關鍵字比對，不宜憑直覺將它視為完整網域。若要比對特定網站，建議使用語意明確的前綴，再透過實際連線記錄確認；正規表示式應保持簡單，避免使用難以維護且範圍過廣的寫法。

geosite 與 geoip 參照的是不同類型的資料：前者提供網域分類，後者提供 IP 範圍。它們並不是由核心即時判斷目標所屬地區的功能。資料檔案缺漏、分類名稱不存在、路徑錯誤或資源過舊，都可能影響載入與比對。用戶端更新節點訂閱，不一定也會同步更新這兩類資源，請分別檢查相應的資源管理入口。

domainStrategy 決定何時補做解析

AsIs 通常依連線目前的目標形式進行比對，不會為了路由額外將網域解析成 IP。IPIfNonMatch 會在網域未符合適用規則時嘗試解析，再比對 IP 規則；IPOnDemand 則會在比對過程需要 IP 條件時觸發解析。各核心的具體實作細節請以對應文件為準，但這三種策略共同影響的是路由階段，而不是系統中的所有網域查詢。

啟用解析後，部分連線會多一次查詢流程，也會受到解析結果影響。若將範圍廣泛的 IP 規則放在前面，可能改變原本預期依網域分類的行為。排查時先確認核心收到的是網域還是 IP，再檢查規則順序，最後查看解析策略。只修改 domainStrategy 卻不檢查入口資訊，往往無法解釋為什麼同一網站在不同應用程式中會走向不同出口。

既有連線可能仍沿用調整前的路徑，瀏覽器也可能重複使用連線。修改規則後，請重新建立測試連線，必要時重新啟動受測應用程式，不要只重新整理頁面。如果記錄結果與預期不符，先用單一精確網域規則驗證入口與出口，再逐步恢復分類規則。完整分流寫法請見geosite 與 geoip 路由規則實作。

六、dns：解析來源與連線路徑

先確認由誰發起網域查詢

設定核心 DNS，不代表作業系統、瀏覽器與所有應用程式都會改用這項設定。應用程式可能先在本機解析，再將 IP 傳給代理；也可能直接把網域提交給 SOCKS 或 HTTP 入口，交由後續環節處理。瀏覽器的安全 DNS、系統解析快取與應用程式內的解析程式庫，都可能形成不同路徑。排查的第一步，是確認目標以網域還是 IP 的形式進入核心。

頂層 dns 會為核心需要網域解析的功能提供服務，例如路由補做 IP 判斷，以及部分出站策略的目標解析。這不是宣告要在本機 DNS 連接埠自動監聽。如果應用程式始終繞過核心自行查詢，單獨新增這個物件不會改變應用程式行為；必須透過用戶端支援的流量接管方式或應用程式設定處理，不能混淆兩者的職責。

基礎伺服器與查詢策略

以下片段採用一般 DNS 伺服器位址，並將查詢策略限制為 IPv4。這個位址只是明確的範例選擇，不代表適用於所有網路環境。測試時應選擇目前網路可連線且符合需求的解析服務；若伺服器本身無法連線，調整網域路由也不會讓查詢自動成功。缺乏依據時，也不應不斷堆疊更多伺服器。

{
  "dns": {
    "hosts": {
      "manual.example": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

hosts 範例使用保留作文件用途的位址，僅用來說明靜態對應，不可當成真實服務存取。靜態對應適合受控測試，但會略過正常的位址更新；若目標遷移後忘了刪除舊對應，就可能長期指向失效位址。檢查解析異常時，請分別查看核心中的對應與系統 hosts 檔案，兩者屬於不同的設定來源。

UseIPv4、UseIPv6 與 UseIP 用於控制核心查詢時的位址家族偏好或範圍。限制為 IPv4 有助於確認是否存在 IPv6 路徑問題，但不代表這是所有環境的長期最佳設定。若目標只有 IPv6，強制使用 IPv4 自然無法取得可用位址；若網路完整支援雙協定堆疊，則應依實際連線能力與需求決定，不要固定照抄範例。

設計分域解析時，也要考慮回退方式

傳統設定可以透過伺服器物件，為特定網域選擇解析服務。請注意，網域優先選擇、未命中時的預設查詢，以及查詢失敗後的回退方式，往往會受多個欄位共同影響。只設定一份 domains 清單，不一定代表其他伺服器永遠不會參與。若對解析路徑有明確要求，應閱讀目前核心的回退選項，並驗證查詢失敗時的情況，而不只測試成功查詢。

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

範例表示網域選擇關係，不保證查詢一定透過代理。DNS 請求是否進入路由、採用直連或由特定出口控制，取決於伺服器位址格式、核心實作及相關設定。一般 UDP 查詢、透過 HTTPS 的查詢，以及具有本機處理語意的位址寫法，可能採用不同路徑。設定時應分別確認「選擇哪一台解析伺服器」與「如何連線至該伺服器」。

使用網域格式的加密 DNS 服務時，也要考量啟動解析。核心必須先知道解析服務的位址，才能連線至該服務；若這個步驟又依賴同一條尚未建立的解析路徑，就可能形成循環。若伺服器出站本身也是網域，循環會更難察覺。請為啟動階段保留清楚可查的解析路徑，並透過記錄確認服務位址已先行解析成功。

修改後也要考量快取。應用程式、系統與核心可能各自保留解析結果，只重新啟動其中一個環節，不一定會立即改變行為。測試時請記錄查詢對象、位址家族與回傳結果，並重新建立連線；同時區分「沒有取得位址」與「已取得位址但連線失敗」。後者應繼續檢查路由與出口，不能只因問題涉及網域就一概歸咎於 DNS。

七、policy 與 log：連線策略與可觀測性

策略級別不等於連線優先級

policy 用於設定連線處理策略及部分統計開關。常見的傳統結構會以 levels 依使用者級別組織參數。這裡的級別不是速度等級，也不代表會替某條連線分配較高頻寬；只有當協定與使用者設定實際引用相應級別時，相關策略才會套用到該連線。即使未使用的級別寫得完整，也不代表執行時會自動啟用。

不要把策略當成「通用加速參數」大量套用。交握時限、閒置逾時、單向資料等待與緩衝設定，處理的是不同問題。縮短等待時間可能更快清除失效連線，也可能誤傷交握較慢或長時間沒有資料傳輸的應用程式。調大數值或許會保留更多連線狀態，但無法修復遠端驗證失敗、DNS 解析失敗或本機入口協定錯誤。

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

範例使用級別零來展示結構，鍵名仍是字串，內部各時間值則依相應欄位的規定使用秒數。這只是參數集合範例，不代表適用於所有網路的建議組合。如果目前核心的預設策略已符合需求，可以省略這一段。對於缺乏測量依據的環境，減少自訂欄位會比複製來歷不明的大量策略更容易維護。

逾時欄位需依連線狀態判斷

handshake 限制相應連線的交握等待時間；connIdle 用來設定連線處於閒置狀態的時間；uplinkOnly 與 downlinkOnly 則分別對應一側結束後，另一個方向繼續處理的等待時間。適用的協定與狀態轉換請查閱目前核心文件。這些欄位不能簡化理解為「網頁最多等幾秒」，更不能取代應用程式本身的請求逾時設定。

例如，長連線在沒有業務資料時，可能需要依靠應用程式的心跳保持連線。如果閒置時限過短，可能會看到連線週期性重新建立；此時應一併檢查應用程式心跳、伺服器端逾時與中間網路設備，而不是一味調大用戶端數值。修改前記下原始值，修改後分別測試閒置與持續傳輸的情況，才能判斷影響出現在哪種狀態。

記錄等級與統計是兩條不同的設定線

記錄用來說明發生了什麼事，統計則用來彙整特定連線或使用者的計數，兩者並非相同功能。部分統計功能除了需要策略開關，也需要頂層統計物件、受支援的協定識別資訊與相應的讀取介面。只開啟 statsUserUplink 欄位，不代表圖形用戶端一定會顯示相應介面；用戶端可能採用另一套資料擷取方式，也可能根本不讀取這項統計資料。

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

日常使用時可保留適當的記錄等級，排錯時再依核心支援範圍暫時提高詳細程度。warning 適合查看警告與錯誤，但不一定會包含每條連線的完整去向；若要定位路由，可能還需查看存取記錄或用戶端提供的連線資訊。記錄中缺少成功連線資訊，不代表流量沒有經過核心，請先確認目前記錄範圍。

若指定記錄檔路徑，請確認目錄存在、執行身分具有寫入權限，且用戶端允許使用該位置。桌面系統與 Android 應用程式的可寫入目錄不同，不能直接複製其他平台的絕對路徑。排錯時不需要提高服務權限；請優先使用用戶端現有的記錄視窗，匯出確實需要的片段，再決定是否設定獨立檔案。

記錄內容也可能包含目標網域、遠端位址與驗證相關資訊。分享前請逐項隱藏敏感資料，同時保留錯誤類型、發生階段及必要的欄位路徑。測試結束後，請恢復一般記錄範圍，避免持續累積大量檔案。若要進一步比對症狀，可從FAQ 故障排除分類尋找相應項目，不要只根據單行警告就重建整份設定。

八、整體驗證、遷移與故障排除

逐層驗證，不要只靠單次測速

完整驗證應涵蓋檔案能否讀取、核心能否啟動、應用程式能否連入入站、連線選用哪個出口、遠端交握是否完成，以及目標是否確實回傳資料。用戶端的測試功能通常只涵蓋其中一部分。某次測試成功，不代表瀏覽器代理已設定完成；測試失敗，也不一定表示節點完全不可用，可能只是測試目標或方式與實際用途不同。

第一步只檢查結構與啟動。儲存檔案後，透過用戶端的設定檢查功能或啟動記錄確認解析結果，特別留意物件層級、欄位類型及不支援的欄位。發生錯誤時，請從最早出現的有效錯誤開始處理；後續錯誤可能只是前一項失敗所引發的連鎖反應。核心尚未成功啟動前，不必更換 DNS 或路由分類，因為這些功能還沒有進入執行階段。

第二步驗證入站。確認監聽連接埠與應用程式設定相符，讓單一應用程式發出新的請求，並確認是否產生相應記錄。若完全沒有連線，請檢查系統代理、應用程式內的代理設定及外掛是否覆寫設定。桌面終端機通常不會自動沿用瀏覽器設定，Android 應用程式也可能受到按應用程式指定代理的範圍影響。此時應先修正接入路徑，不要繼續調整遠端身分欄位。

以最小連線流程恢復可用狀態

第三步驗證出口。先保留一個明確的遠端項目與簡單路由，確認出口標籤正確，再觀察撥號、傳輸交握與驗證階段。每次只修改一組相關參數，並重新建立連線。若原本可用的設定在加入分流後失敗，請優先還原新增規則；若更換核心後才開始失敗，則先確認擴充欄位與協定是否受支援，不要同時懷疑所有網路條件。

第四步驗證 DNS 與規則涵蓋情況。分別選擇一個精確網域規則、一個需要依 IP 判斷的目標，以及一個不符合任何規則的目標，確認三者各自的去向。測試目標應符合實際使用需求，並記錄預期出口；不要只看網頁能否開啟。連線成功但出口不符設計，同樣表示規則需要調整，否則後續流量可能經由不同路徑而產生風險。

跨用戶端遷移時，請驗證最終設定

遷移並非將檔案複製到另一台裝置後就算完成。請先確認目標用戶端實際執行的核心，再核對自訂設定入口、資源資料路徑、記錄路徑與本機監聽位址。桌面端可先使用 v2rayN；Android 則可依需求選擇 v2rayNG 或 v2flyNG。安裝入口請見用戶端頁面，用戶端職責差異請參考選用指南。

將分享連結或訂閱轉換為原生 JSON 時，匯入成功只表示用戶端接受了輸入，不代表所有擴充欄位都已保留。請開啟項目編輯頁，檢查協定、傳輸、安全層與流控，再查看最終執行設定。轉換過程尤其要留意路徑編碼、遺漏的預設值及欄位名稱變更；格式差異請參考訂閱格式與原生 JSON 對照。

在同一台裝置上同時執行多個用戶端，也可能干擾驗證。它們可能爭用連接埠、反覆設定系統代理，或留下仍在執行的核心程序。切換測試對象前，請先正常停止原有連線，再確認新用戶端已接管預期入口。不要只因關閉視窗就認定服務已退出，也不要尚未記錄現況就大量結束不明程序。

測試記錄建議包含設定來源、目前核心、修改欄位、發生時間、測試應用程式及錯誤階段，不必記錄完整憑證。若無法判斷問題出在哪一層，請回到第一章的直連基準，再逐項恢復遠端出站、傳輸、路由與 DNS。每恢復一層就保留一份可用副本；後續出問題時，便能回到最近一次確認正常的狀態，而不必從頭拼接設定。