JSON 設定參考

JSON 結構總覽

先確認目前查看的是哪一種設定，再著手理解欄位。v2rayN 儲存的介面設定、訂閱內容與核心執行設定並非同一個檔案。訂閱提供伺服器連線參數；用戶端則依據目前選取的伺服器、路由範本與監聽設定，產生交由核心執行的設定。修改產生的檔案可能只對當次執行有效；下次切換伺服器或重新啟動核心時，變更就會被覆寫。需要長期保留的設定，應優先回到用戶端對應的設定入口修改。

物件、陣列與欄位型別

JSON 頂層是以大括號包住的物件。物件中的欄位由雙引號括住的名稱、冒號和值組成，多個欄位之間以逗號分隔。陣列使用方括號，適合描述多個入站、多個出站或有順序的規則。字串、數字與布林值不能互換：監聽連接埠要填數字，開關要寫成 true 或 false，通訊協定名稱則是字串。最後一個項目後方不加逗號，嚴格的 JSON 中也不能加入註解。

以下範例是常見 V2Ray 與 Xray 核心都能理解的本機直連基本設定。它只在迴路位址提供 SOCKS 入口，不包含遠端代理伺服器。應用程式主動連上這個入口後，會由本機直接連線至目標。此範例用來區分本機監聽問題與遠端連線問題，不代表匯入後就已建立遠端代理連線。

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

頂層設定區段的職責

這些區段透過參照彼此協作，不會依照文字出現的位置順序執行。路由中的 outboundTag 會指向出站的 tag；策略等級則對應通訊協定使用者的 level。物件欄位的書寫順序通常不會改變意義，但陣列順序可能影響行為，尤其是路由規則與預設出站。閱讀設定時，應先找出參照關係，再檢視個別值。

完整檔案與局部片段

本頁後續範例多為頂層片段，用來取代或合併同名設定區段。不要直接串接兩個都含有 routing 的物件，也不要保留兩個同名的頂層鍵。部分剖析器會接受重複鍵，並採用其中一個值，但不應依賴這種結果。合併時請保留單一頂層物件，將目標區段放到正確層級，再檢查括號、陣列與逗號是否正確。

不同核心雖有共同概念，但不保證所有擴充欄位都一致。傳輸實作、DNS 選項與使用者等級的支援情況，應以目前實際執行的核心為準。先建立只含必要欄位、能正常執行的設定，再逐一加入功能，比一次匯入大量來源各異的片段更容易判斷差異。用戶端升級後也應重新檢查產生的設定，不要只憑舊截圖認定欄位沒有變動。

記錄設定時，建議一併記下核心名稱、用戶端設定入口與修改目的。請勿將敏感的伺服器憑證放進公開截圖或文件。遇到錯誤時，先區分 JSON 語法無法剖析、欄位不受支援，以及執行時連線失敗這三個階段；後文會依相同順序說明。如此可避免把連接埠遭占用誤判為通訊協定問題，或把規則未命中誤判為 JSON 寫錯。

inbounds：本機入站監聽

入站設定應用程式如何將連線交給核心。桌面環境常見的做法是讓應用程式使用本機 SOCKS 或 HTTP 代理，再由用戶端啟動對應的監聽服務。應用程式設定的位址、連接埠與通訊協定必須和入站設定一致。看得到用戶端視窗，不代表核心已成功開始監聽；要確認入口是否存在，應查看啟動記錄與實際連接埠占用情況，而非只看系統匣圖示。

監聽位址與通訊協定選擇

listen 是本機的繫結位址，不是遠端伺服器位址。使用 127.0.0.1 時，入口只接受本機迴路連線。改成 0.0.0.0 會讓入口延伸至 IPv4 網路介面，區域網路裝置可能因此連上該連接埠；此時還需要透過驗證、防火牆與網路邊界共同限制存取。只開啟用戶端的區域網路開關，不代表其他裝置一定連得上。

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

此範例依照 Xray 設定語意使用 routeOnly：嗅探取得的資訊僅供路由使用，不會直接取代原始目標。切換至其他核心之前，請先確認該欄位是否受支援。若只想確認本機入口是否正常，可先移除整個 sniffing 區段，保留基本監聽設定；入口穩定後，再測試嗅探與網域規則，避免同時引入兩種變因。

SOCKS 與 HTTP 是不同的入口通訊協定。應用程式只支援 HTTP 代理時，應填入 HTTP 入站連接埠，不能因為兩個連接埠都在本機就任意互換。SOCKS 入站啟用 udp，只代表允許相應的 UDP 轉送功能；應用程式還必須透過支援的方式傳送 UDP 流量，遠端連線也要具備對應能力。一般 HTTP 代理入口不等同於接管所有 UDP 流量。

網域資訊如何進入規則

應用程式可能將網域名稱交給代理，也可能先在本機解析，再將目標 IP 交給代理。前一種情況可以直接套用網域規則；後一種則需要依據已有的目標資訊或嗅探結果判斷。嗅探讀取的是可辨識的通訊協定特徵，並非通用的內容解密工具。如果連線沒有可用的網域特徵、交握受到其他機制保護，或使用的通訊協定不在支援範圍內，就不能期待嗅探補出正確網域。

destOverride 中的 http 與 tls 是嗅探目標的通訊協定類別，不是用來選擇出站傳輸方式。啟用嗅探不會自動啟用 TLS，也無法修正伺服器憑證問題。檢查網域分流時，應一併確認應用程式是否傳遞網域、目前入口是否啟用嗅探，以及規則實際取得的是網域還是 IP；不能只檢查單一開關。

連接埠衝突與區域網路存取

兩個程序不能任意使用相同的監聽位址與連接埠。用戶端啟動時若出現位址已被使用的錯誤，請先關閉重複執行的執行個體，再確認是否有其他程式監聽相同連接埠。變更入站連接埠後，必須同步修改應用程式代理與系統代理設定；否則即使新核心正常執行，應用程式仍會連到舊連接埠。儲存設定前可先記下舊值，測試失敗時再依原設定還原。

若要讓區域網路裝置使用此入口，請先確認裝置位於可互相連線的網路，再檢查繫結位址、系統防火牆與存取驗證。不要直接將 noauth 的本機範例開放至不受信任的網路。通常只允許特定裝置存取，比開放整個介面更安全可靠。其他裝置的連線進入後也會經過路由規則，因此入口連通性與目標可達性仍須分開驗證。

入站標籤宜保持穩定、明確且唯一。例如，為瀏覽器與測試程式設定不同標籤，再透過路由的 inboundTag 觀察不同入口的行為。標籤不負責身分驗證，也沒有預設的特殊意義；它只是設定中的參照名稱。拼字變動會影響相關規則，排查時應逐字核對，不要只因名稱看起來相似就認定兩者已連結。

outbounds：出站與通訊協定參數

出站決定核心如何建立下一段連線。直連出站、阻斷出站與遠端代理出站都屬於這一層，但各自負責不同工作。出站存在不代表一定會被使用；還要確認路由是否選中它，以及規則未命中時預設會使用哪個出站。一般應將預期的預設出站放在陣列第一個，並為需要由規則參照的出站設定唯一標籤，避免依賴難以辨識的位置關係。

通訊協定與傳輸分層

protocol 說明出站使用的代理通訊協定或處理方式。遠端位址、連接埠與使用者參數通常設定在 settings 中；傳輸與連線安全設定則通常位於 streamSettings。通訊協定、傳輸與安全層是彼此配合的三個面向，不應將某個通訊協定名稱視為完整的連線方案。即使兩端使用相同通訊協定，只要傳輸路徑、服務名稱或安全參數不一致，交握仍可能失敗。

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

這段範例不包含遠端伺服器，可用來理解出站參照關係。freedom 會由本機建立目標連線；是否解析網域及如何選擇位址，也會受到相關設定影響。blackhole 用來丟棄符合條件的流量，適合阻斷明確指定的範圍。依預設行為，應用程式可能出現連線失敗或逾時，不應因此認定是目標網站故障。診斷時應先確認連線是否被規則送往阻斷出站。

VLESS 欄位對應關係

VLESS 遠端連線參數須由伺服器設定或可信的分享資訊提供。vnext 描述伺服器清單，其中的 address 與 port 指定連線目標；users 中的 id 則用來識別使用者。不要依照範例自行產生實際連線憑證，也不要將訂閱群組名稱填入伺服器位址。位址、使用者參數與傳輸安全設定必須來自同一套伺服器設定。

使用 VLESS 時，encryption 常見的值 none 是通訊協定使用者設定，不代表整條連線沒有傳輸安全層。TLS 與 REALITY 等連線安全方式，須在對應核心支援的傳輸設定中處理，兩者的參數不能混用。伺服器名稱、憑證驗證、公鑰與識別參數各有不同語意；不清楚欄位用途時，應回頭查閱原始分享資訊，而不是關閉驗證來避開錯誤。

VMess、VLESS 與 Trojan 的驗證結構也不相同。不要將一種通訊協定的使用者物件原樣複製到另一種通訊協定下。最穩妥的做法是先讓用戶端匯入有效的分享連結，再查看產生的設定，了解各項連線參數位於哪個層級。如需比較通訊協定概念，可參閱術語手冊；本頁著重欄位位置與參照關係，不為不同使用情境下的通訊協定排名。

預設出站與連線驗證

如果已設定代理出站，但沒有任何規則指向它，而且它也不是預設出站，流量就不會自動使用該伺服器。反之，將代理出站放在第一個位置，未命中其他規則的連線就會經由該代理。調整陣列順序會改變預設處理方式，因此每次修改前，先用一句話說明預期結果：哪些連線明確直連、哪些明確阻斷，其餘連線交由哪個出站處理。這些描述應能對應到實際陣列與規則。

驗證遠端連線時，先確認本機能否連到伺服器位址與連接埠，再檢查傳輸交握，最後才查看目標請求。伺服器連接埠可連通，只代表網路層有回應，不代表驗證成功。憑證名稱錯誤、傳輸參數不一致或使用者識別碼無效，都可能讓後續階段失敗。用戶端顯示的延遲結果也不能取代完整的應用程式請求，應搭配記錄檔中的錯誤階段判斷。

切換核心後，先確認目前核心是否同時支援所需的通訊協定與傳輸方式，再檢查產生的設定是否保留必要選項。不能只因介面仍顯示相同的伺服器名稱，就認定底層參數完全一致。使用自訂出站時，保留原始匯入資訊與可正常運作的設定副本，有助於區分匯入轉換問題、核心差異與伺服器設定變更。

routing：路由比對與分流

路由的作用是選擇出站，不是修改遠端伺服器設定。規則會依陣列順序逐一檢查，通常由第一條符合的規則決定流量去向；若沒有符合的規則，就使用預設出站。設計規則時，應先放範圍較窄、意圖明確的例外，再放涵蓋範圍較大的規則。如果前面的規則已符合所有目標，後面的規則即使語法正確也不會生效。排查時不能只確認某條規則是否存在。

網域規則與 IP 規則

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

此片段要求設定中存在 block 與 direct 兩個出站。full:example.com 只會比對該完整網域，不會自動涵蓋所有子網域；若要涵蓋網域及其子網域，應使用對應的 domain: 格式。在常見實作中，沒有前綴的字串可能會以關鍵字方式處理，因此撰寫規則時應明確指定比對方式，避免誤將名稱相似的項目納入。

geosite:cn 與 geoip:private 參照的是規則資料類別，不是執行時從名稱推測的集合。它們依賴核心能讀取對應資料檔，且檔案中確實包含相關項目。資料缺漏可能導致啟動失敗，資料更新也可能改變實際涵蓋範圍。若某個網域的分流結果不如預期，應先用明確的網域規則驗證，再判斷差異是來自資料分類還是規則順序。

domainStrategy 的作用範圍

AsIs 表示路由階段主要依據現有目標資訊進行比對，不會為了 IP 規則主動解析網域。IPIfNonMatch 會在網域未符合規則時嘗試解析，再利用結果檢查相關規則。IPOnDemand 則會在比對過程遇到需要 IP 資訊的條件時觸發解析。三者影響的是路由比對階段，不是系統 DNS 的總開關，也不保證其他應用程式的解析請求會進入核心。

同一條規則中，不同類別的條件通常必須同時符合；同一類別中的多個候選值則通常任一符合即可。例如，同一條規則同時設定網域與連接埠，代表該網域在指定連接埠上的連線，而不是網域或連接埠任一符合即可。若要表達兩種彼此獨立的情況，應拆成兩條規則。規則越精簡，就越容易透過記錄檔與測試結果判斷實際命中的條件。

預設規則與復原方式

路由範本常見問題包括預設規則放得太早、標籤拼錯，或把目標連接埠誤認為入口連接埠。先用單一測試網域建立最精簡的規則，確認流量能送往指定出站，再逐步擴大至資料類別與多個條件。每次只修改一組規則，測試後記下命中的出站標籤。若一次合併多個來源的規則，規則互相遮蔽時，很難判斷是哪次修改改變了行為。

私有位址直連也須依網路用途判斷。區域網路服務可能使用內部網域，應用程式也可能先將網域解析為私有位址；只設定公開網域規則，不一定能涵蓋這類連線。反過來說，擴大私有網段的比對範圍前，也應確認不會將原本需要特殊路徑的內部網路流量送錯。規則描述的是實際網路邊界，不能因為看到「私有」就忽略所有存取控制。

用戶端中的全域、略過或規則模式，可能透過不同範本產生路由；名稱相似不代表設定完全相同。切換模式後，應重新查看產生的設定，而不是繼續分析切換前的檔案。路由與 DNS 的關係也要一併檢查：路由可能需要解析結果，而解析伺服器本身也需要透過出站連線；兩者形成依賴時，必須確保基礎網路路徑明確可用。

dns：解析路徑與位址選擇

核心 DNS 會為使用它的內部流程提供解析結果；頂層設定中出現 dns，不代表系統解析器會自動被取代。若應用程式先透過系統 DNS 取得位址，再將 IP 交給代理，核心看到的可能只有位址；若應用程式將網域交給代理，路由或出站則可能呼叫內建 DNS。分析解析問題時，必須先確認由誰發出查詢，再確認查詢交給哪台伺服器。

靜態對應與伺服器範圍

{
  "dns": {
    "hosts": {
      "local.test": "127.0.0.1"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIPv4"
  }
}

此片段示範核心內部的靜態對應、網域優先伺服器與查詢位址族，不會將記錄寫入系統 hosts 檔案。local.test 僅用來說明對應層級，應用程式能否使用它，仍取決於是否透過核心解析。domains 用來指定相應伺服器優先處理的網域範圍，但不等同於阻止其他解析路徑的網路防火牆規則。

多台 DNS 伺服器的選擇也會受到核心實作與回退選項影響，不能簡單理解為「第一台失敗後才依序嘗試下一台」。若要嚴格限制特定網域的解析路徑，應進一步檢查所用核心的回退與比對行為，並以實際查詢結果驗證。範例中的公共解析位址僅用來展示欄位格式；實際部署時，請選擇目前網路可連線且符合需求的解析服務。

DNS 與路由的雙向依賴

路由使用 IPIfNonMatch 時，網域連線可能先套用網域規則；若未命中，就會發出解析請求，再依位址繼續比對。解析失敗會使後續決策缺少資訊，但表面上可能只像一般連線逾時。另一方面，DNS 查詢本身也需要網路路徑；不同解析方式可能經過核心路由，也可能採用本機路徑。不要以為設定了解析位址，就已指定解析流量要使用哪個出站。

使用加密解析服務時，也要考慮解析伺服器名稱所需的初始解析。如果連線至解析服務之前必須先解析其網域，而這個解析步驟又仰賴尚未建立的代理連線，就可能形成循環依賴。先提供可用的基礎解析或伺服器位址連線路徑，再逐步加入分流。排查時可暫時使用明確可連線的位址，確認故障發生在名稱解析、傳輸建立，還是目標伺服器回應階段。

hosts 適合處理少量明確的內部對應或測試覆寫，不適合長期手動維護大量且經常變動的公共服務位址。服務位址可能隨地區、負載與網路狀況調整，長期使用固定對應可能連到不合適的目標。新增對應前先記下用途，測試結束後及時清除；否則日後即使修改伺服器設定，也可能持續被舊對應優先覆寫。

IPv4、IPv6 與目標連線

queryStrategy 控制內建解析器查詢或選用的位址類型。範例中的 UseIPv4 適合用來隔離 IPv6 路徑問題，但不一定適合所有網路長期使用。解析出 IPv6 位址，不代表目前出站具備可用的 IPv6 連線能力；只取得 IPv4 位址，也不代表應用程式沒有透過其他解析路徑取得 IPv6 位址。查詢結果與連線結果應分開驗證。

路由的 domainStrategy、DNS 的 queryStrategy 與直連出站中的位址策略屬於不同層級。名稱相似，但作用對象不同。若調整策略後看不出變化，先確認欄位所在的設定區段，以及對應的程式路徑是否實際執行。若應用程式傳入的已經是 IP，繼續修改未參與處理的 DNS 伺服器項目，通常不會改變這條連線。

常見的逐步排查順序是：確認伺服器位址能解析、確認解析服務可連線、確認目標取得預期位址，再確認路由選中正確出站。不要同時切換多個解析服務、修改位址族並重排所有路由。每次只保留一項變更並記錄失敗階段，才能區分解析器故障、位址無法連線與出站交握問題。

policy、記錄檔與連線策略

策略用來管理連線生命週期與統計行為，不負責選擇代理伺服器，也不會自動改善網路品質。調整前應先確認問題發生在建立連線、閒置維持，還是上下行結束階段。一次把所有逾時值都調大，可能只是讓失敗更晚發生；全部調小，則可能讓網路狀況不佳時的正常請求提早結束。策略參數應用來處理可描述的應用程式行為，而不是當成通用的加速開關。

使用者等級與連線時間

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

這裡的時間單位是秒，數值僅用來展示常見欄位組合，並非適用於所有應用程式的建議值。handshake 限制通訊協定交握的可用時間；connIdle 表示連線閒置的容許時間；上行或下行單向階段的維持時間，則由 uplinkOnly 與 downlinkOnly 等欄位共同控制。實際生效情況也與通訊協定實作及連線狀態有關，不能將這些設定視為作業系統所有通訊端的統一逾時值。

levels 的鍵使用字串格式的等級編號，且應與支援使用者等級的通訊協定物件中的 level 對應。新增等級定義，不會自動將所有連線切換到該等級。若修改後行為沒有變化，應先檢查目前通訊協定是否使用該策略、使用者等級是否相符，再考慮數值大小。不同入口與通訊協定的支援範圍，須依所用核心確認。

統計開關與資料顯示流程

策略中的統計布林值只決定是否記錄相應類別的資料，不代表已具備可查詢的統計服務。完整的統計流程還可能涉及 stats、API 服務、標籤與用戶端的讀取邏輯。只啟用其中一個環節時，介面沒有顯示資料並不能證明流量沒有經過核心。桌面用戶端可能會自行產生統計所需的設定區段，自訂設定不應未經確認就覆寫這些內容。

面向使用者顯示的流量資訊，不適合直接作為計費或完整網路稽核依據。連線經過哪些入口、是否包含直連流量，以及何時重設統計，都取決於實際實作。排查時可將統計當作輔助訊號：規則命中後，對應出站是否有活動；切換伺服器後，資料是否流入新的出站。不要以單一累計數值取代對實際請求與記錄檔的驗證。

記錄檔層級與敏感資訊

{
  "log": {
    "loglevel": "warning",
    "dnsLog": false
  }
}

日常使用時可先保留警告層級；重現問題的短時間內，再提高記錄詳細程度。記錄越詳細，越可能包含目標網域、連線位址與內部網路資訊。提交問題前，應移除伺服器憑證、完整訂閱網址與不必要的個人瀏覽記錄，同時保留錯誤類型、發生順序與相關標籤。刪掉所有背景資訊，只留下「連線失敗」，通常無法判斷錯誤發生在哪個階段。

未設定檔案路徑時，記錄可能會輸出至程序輸出，再由用戶端收集。若明確設定檔案輸出，請確認目錄存在且執行帳戶具有寫入權限。用戶端能寫入自己的設定目錄，不代表核心對任何路徑都有權限。記錄檔路徑錯誤、磁碟空間不足或目錄受到其他程式限制，都可能讓預期的記錄檔未能產生；不能因此直接認定核心沒有執行。

遇到長連線中斷，先比較四個可能來源：應用程式本身的逾時、伺服器端閒置限制、網路設備的連線維持設定，以及核心策略。只有證據指向核心閒置處理時，才調整 connIdle 等值。有些應用程式會主動傳送保活請求，有些則不會；兩者對相同策略的反應可能不同，因此不宜將單次測試結果套用到所有程式。

遇到啟動失敗時，策略不是優先檢查項目。先檢查 JSON 語法、欄位相容性與監聽連接埠，再確認資源路徑與權限。若核心啟動後只有特定請求失敗，才進一步檢查出站交握、DNS 與連線逾時。依故障階段安排檢查順序，能減少沒有根據的參數調整，也有助於保留一份容易說明且可復原的設定。

用戶端設定與核心設定的界線

用戶端負責整理伺服器、訂閱、路由範本與執行方式；核心則負責處理連線。桌面版首選 v2rayN；Android 可依需求選擇 v2rayNG，或以 V2Fly 為核心的 v2flyNG。三款用戶端的設定入口與產生流程不盡相同，不能把桌面畫面中的每個開關直接轉換成通用 JSON 欄位。查閱設定時，請先確認它屬於用戶端、系統還是目前使用的核心。

訂閱管理與產生的檔案

訂閱是分發伺服器資訊的方式，不是 V2Ray 頂層設定中的 subscription 區段。v2rayN 中的訂閱群組、自動更新間隔與更新請求方式由用戶端儲存；核心通常接收的是剖析後產生的出站參數。修改訂閱更新間隔不會改變現有連線的逾時策略；修改出站使用者參數，也不會自動修復失效的訂閱網址。

更新訂閱前，請保留目前可用的設定。更新後檢查群組、伺服器數量變化與目前選取的項目，特別留意原先選取的伺服器是否遭到刪除或更名。手動修改由訂閱管理的項目，可能會在下次更新時被覆寫。需要長期保留的自訂參數，應使用用戶端支援的持久設定或獨立自訂設定，不要將執行檔案當成訂閱資料庫。

遇到更新失敗時，先區分請求網址無法連線、伺服器回應錯誤，以及內容格式無法辨識。瀏覽器能開啟某個頁面，不代表該頁面就是用戶端可剖析的訂閱內容。完整網址可能包含存取憑證，請勿公開貼上。匯入方式與分享連結格式可參閱訂閱連結匯入方式；初次操作仍建議依照入門教學流程進行。

TUN 模式與流量接管

TUN 透過虛擬網路介面接收網路層流量，涉及系統路由、權限、DNS 接管與排除規則，並非在一般 V2Ray 頂層物件中加入 tun 欄位即可。用戶端可能透過另一種核心設定來實作此功能，其欄位結構與本頁介紹的一般 V2Ray、Xray 設定不同。請從 v2rayN 的 TUN 模式入口查看實際產生的內容與相關記錄檔。

啟用前，先確認一般代理入口正常運作，再確認權限、虛擬介面與系統路由是否已成功建立。如果一般代理可用但 TUN 不可用，應優先檢查流量接管流程，不要立刻重寫遠端通訊協定參數。也要確認伺服器連線沒有被錯誤地送回虛擬介面而形成迴圈，以及是否需要排除區域網路服務。若同時執行其他虛擬網路程式，路由優先順序也可能影響結果。

切換多種核心

選擇核心不只是切換名稱，也會影響通訊協定支援、傳輸欄位、規則資料與用戶端產生器採用的設定格式。v2rayNG 常使用 Xray，v2flyNG 則使用 V2Fly；v2rayN 實際可選的項目取決於已安裝的元件。切換後應重新驗證伺服器參數、路由與 DNS，不要將某一核心的擴充設定直接複製到另一個核心。生態關係的背景說明請參閱關於本站。

系統代理與應用程式行為

系統代理由用戶端寫入作業系統或桌面環境的代理設定，不屬於核心通用的頂層欄位，而且只對遵循這些設定的應用程式有效。若某個應用程式仍直接連線，先確認它是否使用自己的代理設定，再檢查流量類型。關閉核心後，如果系統代理仍指向原本的本機連接埠，應用程式可能持續顯示連線失敗。此時應清除系統代理設定，而不是只刪除設定檔。

升級或重設用戶端前，請分別備份訂閱群組、路由範本與自訂設定。還原時也應分階段進行：先還原可用的伺服器，再還原規則，最後還原流量接管方式。若一次匯入所有舊設定後又出現故障，就難以判斷問題是舊欄位不相容、產生流程改變，還是系統代理與虛擬網路狀態未恢復至預期。

設定驗證與分層排查

驗證設定時，應從「能夠剖析」逐步確認到「結果符合預期」。語法正確只代表檔案結構可讀，不代表欄位受到支援；欄位受支援，也不代表遠端伺服器可連線；連線成功更不代表所有規則都能依預期分流。每個階段都應有各自的測試目標。上一階段尚未通過前，不要靠修改下一階段的參數碰運氣。

建立可復原的測試基準

先儲存目前可用的設定與對應的用戶端設定，並記下正在使用的核心。測試副本每次只修改一個設定區段，並明確定義成功條件，例如本機連接埠能接收請求、特定網域使用指定出站，或區域網路位址維持直連。測試期間不要同時更新訂閱、切換核心與調整規則順序。變動因素越少，越容易釐清錯誤結果。

若用戶端提供設定檢查或產生設定檢視功能，請優先使用。先確認執行設定確實包含剛才的修改，再檢查錯誤輸出。有些用戶端會在啟動核心前產生暫存檔案，手動編輯舊檔案不會影響下次啟動。若儲存後內容消失，應回頭檢查設定來源，不要一再修改同一個會被覆寫的檔案。

依故障階段縮小範圍

遇到語法錯誤時，先檢查錯誤訊息附近的欄位，也要確認上一行是否漏了逗號或多加逗號。欄位型別錯誤可能藏在看似合理的值中，例如將數字連接埠寫成欄位不接受的文字。啟動錯誤應優先處理最早出現的實質錯誤；後續的「程序已退出」通常只是結果。保留完整的錯誤順序，比只截取最後一句更有幫助。

若核心已在執行，先讓一個明確支援代理的應用程式直接使用本機入口，不要依賴系統自動判斷代理。如果測試成功但其他應用程式失敗，應優先檢查應用程式入口與系統代理；如果所有應用程式都無法連線，再檢查監聽狀態與核心程序。若本機入口已連通但目標連線失敗，接著檢查遠端交握與路由，不要將兩個階段混為同一種「無法連線網路」問題。

以小範圍規則驗證實際路徑

排查路由時，選擇一個能穩定重現問題的目標，暫時加入靠前且明確的網域規則，並指向已知可用的出站。確認行為有所改變後，再逐項還原原有的分類規則與附加條件。如果明確規則也沒有生效，請檢查應用程式是否傳入網域、是否經過預期入口，以及目前查看的是否為實際執行設定。此時一味擴充規則庫通常無法解決根本問題。

排查 DNS 時，應同時記錄查詢路徑與連線目標位址。網域已取得位址但仍無法連線時，檢查位址族與出站連線狀態；只有解析失敗時，才優先檢查解析服務與基礎網路路徑。不要只根據瀏覽器錯誤頁面判斷問題位置，相同的逾時提示可能來自入口連接埠、解析請求、遠端驗證或目標服務。記錄檔的時間順序是串連各階段的重要線索。

復原與可重現的問題記錄

測試失敗後，請還原最近一份可用設定並重新啟動相關核心，確認監聽與系統代理狀態一致。關閉 TUN 時，也要確認虛擬介面與系統路由已依用戶端流程還原。若用戶端本身無法啟動，可參閱啟動時閃退的處理方式，先區分執行環境問題與核心設定問題；視窗無法開啟不一定是 JSON 所致。

最後保留的設定應能回答三個問題：應用程式從哪個入口進入、規則為何選擇這個出站，以及網域在哪裡解析。無法說明用途的欄位，先不要保留為長期設定。完成驗證後，請回到日常使用教學管理連線與模式；需要更換安裝平台時，再前往用戶端下載頁面。將日常操作與設定實驗分開，日後更新與故障復原會更清楚。