V2Ray 設定檔完整指南

JSON 結構總覽與設定範圍

先確認設定來源，再修改欄位

V2Ray 設定不是一張節點資料表，而是描述流量如何進入、比對規則並離開程序的執行說明。頂層物件通常包含 log、inbounds、outbounds、routing、dns 與 policy。並非每個欄位都必須出現，省略後的行為由核心預設值決定。查閱欄位前，先確認目前執行的是 Xray 還是 V2Fly，以及用戶端是否會在啟動時重新產生設定；否則修改的檔案可能根本不是實際載入的那一份。

桌面用戶通常從 v2rayN 開始：匯入訂閱後，在介面選擇伺服器、系統代理與路由模式，再由用戶端轉換成核心設定。此時，訂閱保存的是連線資料，介面保存的是使用者偏好，執行目錄中的 JSON 則可能只是產生結果。三者用途不同。排查問題時可以查看產生的設定，但若要長期修改，應回到介面支援的選項或自訂設定入口。別把一次性的暫時編輯當成已保存的用戶端設定，也不要在不清楚覆寫機制時反覆修改同一個檔案。

可啟動的本機直連基礎設定

以下是一份完整的基礎設定：在本機回送位址提供 SOCKS 入站，將收到的連線交給 freedom 出站，並以警告層級記錄日誌。此設定不連線至任何遠端代理，適合用來確認核心能否啟動、本機連接埠是否可用，以及測試程式是否確實使用該入站。連接埠僅供範例使用；若已被其他用戶端占用，請先停止衝突程序或改用其他可用連接埠。直連基礎設定可用，只能證明本機連線路徑正常，不能據此判斷遠端設定正確。

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

標準 JSON 要求屬性名稱與字串使用雙引號，物件與陣列的最後一個成員後不能加逗號，布林值寫成 true 或 false，數字連接埠不必加引號。部分核心工具能讀取含註解的擴充格式，但編輯器、用戶端匯入器或其他處理環節未必支援。為方便複製與定位問題，本文一律使用標準 JSON，不在程式碼中插入註解。說明文字放在程式碼外，既能減少解析差異，也方便逐段替換。

物件、陣列與標籤如何搭配

inbounds 和 outbounds 都是陣列，因為一個程序可以監聽多個入口，也能管理多種出口；每個陣列成員則是一個物件。tag 是設定內部的參照名稱，不是協定名稱，也不會自動建立對應功能。將出站命名為 proxy，不代表它已設定遠端位址。路由中的 outboundTag 必須對應到實際存在的出站，名稱的大小寫與拼法都要一致，建議使用簡短、固定且意思明確的標籤。

維護設定時，請將修改拆成可驗證的小步驟：先保存可啟動的基礎設定，再新增一個出站，接著加入一條路由，最後才調整 DNS 或策略。每次修改都記錄影響的欄位、預期結果與復原方式。陣列成員的順序可能影響預設出口與路由比對，不要為了排版任意排序。若目前只想正常使用用戶端，優先沿用介面產生的設定；只有確實需要特殊行為時，才進入手動維護流程，避免同時處理介面狀態與核心檔案兩套設定的複雜性。

inbounds：本機監聽與流量入口

listen、port 與 protocol 各自決定什麼

入站負責接收應用程式交給核心的連線。listen 決定繫結的本機位址，port 決定監聽連接埠，protocol 則決定該連接埠使用哪種要求格式。三者缺一不可：即使應用程式連到正確連接埠，若使用錯誤協定，一樣無法建立有效要求。SOCKS 入口不能當成一般 HTTP 代理位址填入，反之亦然。排查時應逐一比對用戶端顯示的監聽協定與應用程式的代理類型，而不只是檢查連接埠數字是否一致。

只供本機應用程式使用時，通常監聽 127.0.0.1。這個位址只接受本機回送連線，不等同於區域網路位址，也不會自動涵蓋 IPv6 回送位址。監聽 0.0.0.0 通常表示繫結所有 IPv4 網路介面；其他裝置能否連線，還會受到防火牆與網路隔離影響。擴大監聽範圍前，應先確認哪些裝置需要使用、採用何種驗證方式，以及退出用戶端後是否仍有其他監聽程序。開放區域網路存取會改變存取範圍，不只是單純的連線最佳化。

SOCKS 與 HTTP 雙入口設定片段

以下片段展示兩個獨立入口，各自使用不同連接埠，再透過標籤供後續路由參照。SOCKS 中的 udp 表示允許該入站處理 SOCKS UDP 要求，但應用程式仍須實際使用相應機制，出站與網路路徑也必須支援 UDP。HTTP 入站主要供使用 HTTP 代理機制的應用程式使用；設定兩個入口，不代表所有程式或傳輸都會自動被接管。若要將本片段用於第一章的基礎設定，應替換整個 inbounds 陣列，而不是再新增一個同名的頂層欄位。

{
  "inbounds": [
    {
      "tag": "socks-local",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-local",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

同一位址與連接埠通常不能同時由兩個一般監聽實例占用。若繫結失敗，先確認是否重複啟動用戶端、測試用核心是否仍在執行，以及舊程序是否已正常結束。不要只改應用程式的連接埠，卻忘了修改入站；也不要只改入站，卻繼續使用系統中舊的代理連接埠。對桌面版 v2rayN 而言，介面上的本機監聽連接埠可能與其他入口設定相關，實際狀況應以執行設定與日誌為準，不能把範例連接埠當成所有安裝環境的固定標準。

嗅探與原始目標的關係

入站也可以包含 sniffing，用來從部分協定的初始資料辨識網域等資訊，協助判斷網域路由。它不是解密工具，也無法保證辨識所有連線，更不能取代正確的 DNS 設定。有些連線只帶有 IP，有些協定的目標資訊無法讀取，因此規則可取得的輸入也會不同。若要讓辨識結果只用於路由、不改寫實際目標，應確認目前核心支援相關選項及其語意，不要照搬不同核心的進階嗅探欄位。

若要確認入站是否正常，可先在明確支援手動代理的應用程式中設定位址與協定，發出一次獨立要求，再查看日誌是否出現對應的入口標籤。若完全沒有記錄，請檢查應用程式是否略過代理、是否使用另一套網路設定，或日誌層級是否足以顯示連線資訊。系統代理只是將設定提供給應用程式的方式，不等於強制轉送。接管範圍的基本操作請參閱使用指南；若遇到無法連線的狀況，可依疑難排解逐項確認。

outbounds：協定出口與遠端參數

先建立出口，再讓規則參照

出站描述核心如何將已接收的流量傳送至目標。freedom 表示直接連線至目標，blackhole 用來丟棄或拒絕流量；遠端代理協定則需要額外的伺服器與帳號參數。出站存在於陣列中，不代表一定會被使用；是否選用取決於路由結果與預設行為。在常見執行方式中，未符合任何規則的連線會使用第一個出站，因此調整陣列順序可能改變整體流向。維護時應明確記錄預設出口，不要只憑標籤名稱推測行為。

以下片段只有直連與封鎖兩個出口，適合與基礎入站合併，用來練習路由參照。此設定沒有遠端伺服器，不能視為遠端連線方案。settings 是協定專用物件，不同協定接受的欄位各不相同；頂層共用欄位相似，不代表內部參數也能互換。將遠端協定物件改成 freedom 時，應一併清除原協定參數，避免殘留欄位造成閱讀與排錯困難，也避免誤以為核心仍會使用那些帳號資料。

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

連線資料、傳輸與安全層不可混為一談

遠端出站通常包含三類資訊：伺服器位址與連接埠、協定身分參數，以及傳輸與安全設定。VMess、VLESS 與 Trojan 的身分參數結構各不相同；TCP、WebSocket 等傳輸設定也不能只改一個名稱就完成切換。TLS 則屬於另一個層次，涉及伺服器名稱與憑證驗證。匯入連結時，用戶端會處理其中一部分轉換；手動設定時，則必須核對完整組合。單看某個欄位似乎合理，不代表它能與遠端部署的其他設定搭配使用。

伺服器位址可以是網域，也可以是 IP，但連線位址與 TLS 憑證驗證所用的伺服器名稱未必相同。使用網域時也會涉及網域如何解析，因此遠端連線失敗有時是 DNS 問題，而非帳號錯誤。遇到憑證或交握錯誤時，應核對系統時間、伺服器名稱、憑證鏈與傳輸設定，不要先關閉憑證驗證。略過驗證會改變安全範圍，也可能掩蓋位址填錯的問題；保留驗證並修正設定，才容易分辨真正的服務故障與本機設定錯誤。

核心支援範圍決定設定能否移轉

Xray 與 V2Fly 共用部分設定慣例，但不是所有協定功能、傳輸欄位與可選值都能互通。尤其是使用特定安全機制或擴充功能的連線資料，匯入或自訂前應先確認執行中的核心支援。用戶端名稱也不代表每次啟動時使用的核心：v2rayN 實際選用的核心應在介面與日誌中確認；v2rayNG 主要面向 Xray，v2flyNG 則是 V2Fly 方向的 Android 替代選擇。跨核心移轉時，先驗證一個出口，不要同時移轉整套路由與進階功能。

訂閱管理也會帶來設定生命週期問題。更新訂閱可能會替換伺服器參數，卻未必保留手動修改的底層物件；用戶端也可能依目前選取的項目重新產生出站標籤。若要長期參照固定標籤，應採用用戶端明確支援的自訂設定方式，並在每次更新後檢查實際產生的結果。選擇安裝入口請前往下載中心；比較三款用戶端的適用情境，可閱讀用戶端比較。本頁不提供遠端服務，能否建立連線仍取決於實際服務參數與網路連通性。

routing：比對順序與分流規則

規則依序比對，不會自動按條件精細程度排序

路由負責為連線選擇出口。常見欄位規則放在 routing.rules 陣列中，核心會依序檢查，符合後便採用對應的處理結果，不會收集所有規則後再挑選「最精確」的一條。因此，明確的例外通常應放在較寬泛的規則之前。若前面的規則已符合所有 TCP 與 UDP 流量，後面的網域規則即使寫得完全正確，也沒有機會再決定出口。排查分流時，先檢查順序，再檢查條件，最後才考慮資料檔是否缺少項目。

同一欄位中的多個候選條件通常表示符合任一項即可，例如 domain 陣列中任一網域條件成立便符合；同一條規則中不同類型的限制則通常要一併符合。例如同時設定入站標籤、網域與連接埠，表示連線必須滿足這些條件，而不是符合其中任一項就生效。將三個彼此獨立的需求塞進一條規則，往往會意外縮小比對範圍。要表達多個互不相關的例外，拆成數條規則會更容易驗證，也更容易看出是哪條規則生效。

不依賴地理資料的練習片段

以下規則可搭配前兩章的直連與封鎖出口使用。它會先封鎖保留作範例的網域及其子網域，再讓來自 SOCKS 入口的連線直接連線；其他流量仍依預設出口處理。此處以 domain: 表示網域及子網域比對，並以 inboundTag 限定入口。範例用來展示參照方式與規則順序，不是實際分流清單的建議。驗證時應使用明確的測試目標，並在日誌中確認路由結果；不能只憑網頁是否開啟來判斷命中了哪條規則。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:example.org"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks-local"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

full: 通常用於完整網域比對，domain: 用於指定網域及其子網域；只有確實需要處理複雜條件時才使用正規表示式。一般文字的比對範圍可能比直覺更廣，維護時應優先選用語意明確的寫法。IP 規則可以使用位址或 CIDR 網段，但私有網段、回送位址與鏈路本地位址代表不同用途，不能一概視為同一種「本機位址」。規則中的目標 IP 也不一定是最初解析得到的唯一位址；網域連線的解析階段會影響可用於比對的資訊。

domainStrategy 與地理資料的適用範圍

AsIs 會盡量依照現有目標形式判斷，不會為了路由主動將網域解析成 IP；IPIfNonMatch 會在網域比對未命中時嘗試解析，再進行後續判斷；IPOnDemand 則會在路由判斷需要 IP 資訊時嘗試解析。這些選項控制的是路由階段的解析策略，不是全域 DNS 開關，也不會決定每個出站最終採用哪種位址類型。選擇前先確認目前規則依賴網域還是 IP，以及是否願意為了取得 IP 比對結果而額外進行解析。

geosite 與 geoip 是依賴資料檔的規則參照，不是核心自動產生的分類。若相應檔案缺失、目錄錯誤或分類名稱不存在，可能會載入失敗或產生非預期行為。資料內容也會變動，不能將分類視為永久準確的業務界線。對於重要目標，應使用容易說明的明確規則，並清楚安排在分類規則之前或之後。涉及本機服務時，也要考慮系統路由與防火牆，不要只靠核心網域規則解決所有網路存取問題。

建議以「一個目標、一個預期出口、一段日誌」驗證路由。先暫時移除無關規則，確認目標帶有的是網域還是 IP，再逐步恢復資料分類與複雜條件。若要參考完整分流情境，可接著閱讀V2Ray 路由規則實作。匯入現成規則前，應檢查其標籤參照、規則順序與資料依賴是否適合目前設定；直接複製整份清單，往往只是將原本容易定位的問題藏在更多條件中。

dns：解析路徑與網域資訊

先釐清由哪一層發起解析

DNS 問題常被籠統描述為「網域打不開」，但一次連線可能涉及應用程式自行解析、作業系統解析、核心內建 DNS，以及遠端伺服器端解析。這些環節不一定讀取相同設定。若應用程式先將網域轉成 IP，再把 IP 傳給 SOCKS 入站，核心看到的起點便不同於直接收到網域。在頂層加入 dns，不會自動讓系統和所有應用程式改用該解析器，也不會自動接管所有送往外部 DNS 服務的要求。

內建 DNS 可為需要解析的核心功能提供結果，例如部分路由判斷與直連出站的位址解析；實際是否呼叫它，仍取決於相關模組的策略與目前核心的實作。定位問題時，應記錄網域最初在哪一層解析、要求從哪個出口離開，以及解析結果最後交給誰。只替換一個解析伺服器而不釐清呼叫流程，可能讓網頁偶爾恢復，卻無法解釋為何另一個應用程式仍然失敗，也無法確保後續修改不會再次引發同類問題。

基礎伺服器、靜態對應與位址類型

以下是標準 JSON 片段：為保留作範例的網域設定靜態對應，並列出解析伺服器，查詢策略採用 IPv4。這段內容展示欄位結構，並非適用所有網路的推薦清單。實際網路可能限制某種解析傳輸方式，也不保證目前路徑能連到特定伺服器。靜態對應只應用於明確知道目標位址的情境；若服務位址經常變動，長期固定對應反而可能連到舊位址、造成憑證錯誤或讓區域調度失效。

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

queryStrategy 決定查詢結果所涉及的位址類型，常見值包括 UseIP、UseIPv4 與 UseIPv6；實際支援情況應以執行中的核心為準。選用 IPv4 有助於排查部分 IPv6 路徑問題，但不能視為所有逾時問題的通用解法。若服務只有某一種位址記錄，限制位址類型便可能無法取得可用結果。反過來說，能取得 IPv6 位址也不代表本機具備可用的 IPv6 路由或相應出站能力；解析成功與連線成功是不同階段。

指定網域解析與循環依賴

servers 陣列可包含伺服器物件，並透過網域條件與預期的 IP 範圍描述更細緻的查詢需求。這裡的網域條件用於選擇解析伺服器，並不等同於 routing.rules 的出口選擇；解析器收到要求後，網路連線如何送出，也與使用的傳輸方式及核心實作有關。部分本機模式與一般模式的路由行為不同；設定加密解析服務前，應先確認目前欄位的實際語意，不要假設所有 DNS 要求都會自動跟隨代理出口。

尤其要避免解析引導造成循環依賴：遠端伺服器位址必須先解析，但解析服務本身卻只能透過尚未建立的遠端連線存取。使用網域形式的加密解析位址時，也可能遇到類似問題。處理時應先確保引導階段能獨立完成，明確確認遠端伺服器網域如何取得位址，再逐步加入複雜的解析路徑。不要透過關閉安全檢查或任意固定服務位址來掩蓋循環問題；應拆解依賴鏈，並檢查系統 DNS、核心 DNS 與出站連線各自負責的部分。

FakeDNS 透過虛擬位址與網域對應，協助後續階段還原網域，通常需要入口接管、解析流程與核心功能彼此配合。只新增一個名稱或照抄片段，並不能讓一般系統代理自動具備完整接管能力；結束相關模式時，也要留意應用程式與系統快取中殘留的虛擬位址。進一步了解適用範圍，請參閱FakeDNS 原理與適用情境。一般排查時應優先採用簡單的解析路徑，確認穩定後再考慮是否需要這類機制。

policy、log 與 stats：執行策略

policy 控制連線行為，不負責選擇出口

policy 常用於設定連線交握、閒置逾時、半關閉處理，以及流量統計開關。它無法取代路由，也不會因為增加幾個數值就自動改善連線品質。levels 中的鍵代表使用者層級，對應協定使用者物件上的層級資訊；未明確指定時，常見情境會使用預設層級。不同協定能提供的使用者資訊各異，不能假設每個入口都能以相同方式統計。設定前應先確認目前連線對應哪個層級，否則修改的可能是根本沒有使用的策略。

以下片段為預設層級明確設定常見的逾時參數。handshake 是交握階段允許的時間，connIdle 用於連線閒置階段，uplinkOnly 與 downlinkOnly 則控制其中一個方向結束後，另一個方向仍保持開啟的時間。這些值的單位是秒。範例用來說明結構，不表示必須取代用戶端現有的預設值；若目前使用正常，保留經用戶端調整的預設策略，通常比盲目縮短逾時更容易維護。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    },
    "system": {
      "statsInboundUplink": false,
      "statsInboundDownlink": false
    }
  },
  "log": {
    "loglevel": "warning"
  }
}

交握時間設得太短時，網路不穩或多層傳輸尚未建立完成，連線就可能提前中斷。閒置逾時過短可能影響長連線、等待推送或間歇性傳輸；設得太長則會讓已無實際用途的連線保留更久。有些應用程式具備心跳與重試機制，實際表現也會受到應用層行為影響。因此，調整策略應以可重現的問題為依據，記錄修改前後的日誌與連線階段；不要把一次偶然成功當作參數調整有效的證據，也不要將逾時值視為服務回應速度的測量結果。

日誌層級與輸出位置

loglevel 常見層級包括 debug、info、warning、error 與 none。debug 層級會記錄更多資訊，但日誌檔案體積與隱私暴露風險也會增加；日常使用不必長期保留最詳細的記錄。若未設定檔案路徑，輸出可能由主控台或用戶端接收；設定存取日誌與錯誤日誌路徑時，應確認執行中的使用者具有寫入權限，並了解相對路徑是以哪個工作目錄為基準。檔案沒有新增內容，不一定表示沒有連線，也可能是查看了舊路徑或另一份日誌。

存取記錄與錯誤記錄的用途不同：前者用來查看要求目標與出口，後者用來判斷解析、連線或交握在哪個階段失敗。閱讀日誌時，應先對齊同一次測試的時間範圍，再查看入口標籤、目標位址與錯誤鏈。最後顯示逾時，可能是前面的解析失敗所致，不能只截取最後一行。日誌也可能包含網域、位址、使用者識別資訊或本機路徑，分享前應先處理敏感內容，保留足以判斷流程的資訊即可，避免直接公開整份執行記錄。

統計開關與管理介面的關係

頂層 stats 與策略中的統計開關負責不同環節：前者啟用統計相關模組，後者決定要收集哪些資料。即使加入空的 stats 物件，也不會自動產生可存取的圖形化面板；若要讀取統計資料，通常還需要管理介面、服務宣告與入口隔離。本文不建議為了單次排錯就公開管理介面，也不把統計數值當成網路效能結論。若用戶端已有流量顯示功能，應優先沿用既有整合方式，不要另外建立一套無法確認存取範圍的介面設定。

若遇到「連線可以建立，但過一段時間就中斷」，先區分是應用程式主動關閉、遠端關閉、閒置策略觸發，還是網路切換，再考慮調整 policy。若每次都在交握階段失敗，修改閒置參數無法解決根本原因。更完整的日誌閱讀方式請見V2Ray 執行日誌怎麼看。定位問題後，應恢復適合日常使用的日誌層級，清除不再需要的除錯檔案，並將必要的策略修改記錄在設定備份說明中。

用戶端設定與核心 JSON 的範圍

v2rayN：介面狀態不等於檔案狀態

桌面環境優先推薦 v2rayN，但使用圖形化用戶端不代表所有設定都在同一個 JSON 檔案中。伺服器清單、訂閱網址、視窗偏好、路由範本與核心執行設定可能分別保存。按下啟動後，用戶端會將目前的選擇組合成核心可讀取的設定；停止後重新啟動、切換伺服器或更新訂閱，都可能重新產生設定結果。查看檔案時，應先判斷它是長期設定來源還是暫時產物。來源不明的檔案不適合作為唯一備份，也不宜在核心執行時邊修改邊猜測是否已生效。

系統代理是作業系統與應用程式之間的設定約定；核心 JSON 則描述程序本身的監聽與轉送方式。兩者搭配才能完成常見的桌面使用流程。清除系統代理不一定會停止核心，停止核心也不一定會立即清除系統中殘留的代理設定；若應用程式繼續連到已關閉的本機連接埠，就會表現為無法存取網路。退出前後應分別確認系統代理狀態與程序狀態，不要將所有連線拒絕都歸咎於遠端服務，也不要試圖透過同時啟動多個用戶端來修復殘留設定。

跨平台與不同核心的設定差異

Windows、macOS 與 Linux 都能使用 v2rayN，但權限、執行目錄、系統代理整合方式與網路接管機制並不完全相同。檔案路徑格式、設定目錄的寫入權限與服務執行身分，都可能影響實際載入結果。Android 用戶通常選擇 v2rayNG；若要使用 V2Fly 方向的設定，可考慮 v2flyNG。系統提供的網路接管授權與桌面系統代理不是同一種機制。移轉時請保留連線資料，再依目標平台重新確認接管設定；不要直接複製整個工作目錄，並預期所有路徑與權限都能正常沿用。

即使同為 JSON，也可能屬於完全不同的設定模型。v2rayN 可使用不同核心，而本文的 inbounds、outbounds 與 routing 範例是以 V2Fly / Xray 常見結構為主，不能直接套用到 sing-box 的設定結構。不要只憑副檔名判斷相容性。遇到不支援的欄位時，先確認目前啟動的核心，再檢查設定入口要求的是完整設定、伺服器物件，還是用戶端專用匯入格式，避免在錯誤格式上不斷補修欄位。

TUN 與系統代理不能用一個布林值畫上等號

TUN 通常需要虛擬網路介面、路由設定與相應權限，有時也會使用獨立的接管元件或另一個核心。用戶端中的「啟用 TUN」不代表只要在本文的基礎 JSON 頂層加入同名欄位，就能取得相同效果。系統代理的接管範圍較明確，但仰賴應用程式主動使用；TUN 的接管範圍更廣，卻也需要處理本機網路、DNS 與出口迴圈等問題。切換模式時，一次只啟用一條明確的接管路徑，並確認遠端連線本身不會再次被送回入口。

自訂完整設定與一般訂閱也應分開管理。前者通常需要自行維護入口、出口、規則與資料依賴；後者則由用戶端依據訂閱與介面設定產生。匯入成功只代表格式獲得接受，不代表每個欄位都已生效。若用戶端提供設定預覽或執行日誌，應依實際載入結果判斷；若沒有明確的合併說明，不要假設自訂片段會自動覆寫到正確位置。保留一份可供復原的一般設定，比維護多個互相覆寫的暫存檔案更可靠。

選擇桌面介面時，可閱讀v2rayN 桌面版與 WPF 版差異，依作業系統與介面使用習慣選擇，而不要把介面框架差異視為協定能力差異。安裝檔請前往下載中心依平台選擇；初次設定仍依照使用指南的流程進行。只有確認介面無法滿足實際需求後，再使用自訂核心檔案；並在訂閱更新、模式切換與重新啟動後檢查設定是否保留，確保下次執行時仍採用預期設定。

設定驗證、日誌定位與復原流程

分開驗證語法正確與執行正常

排查設定時，從成本最低的檢查開始。第一步確認檔案是標準 JSON，括號、逗號與字串跳脫皆正確；第二步確認欄位受目前核心支援；第三步檢查標籤參照、資料檔、監聽連接埠與路徑權限；最後才進行實際連線測試。語法檢查通過，只代表檔案可供解析，不代表遠端連線可達或路由符合預期。沒有遠端出口的直連設定也可能完全合法，因此「核心能啟動」與「指定目標透過指定出口連線」必須分成兩個獨立的驗證目標。

手動執行核心時，可使用其設定測試模式，不必先讓它長時間監聽。下方命令分別適用於本機已有的 Xray 與 V2Ray 執行檔；檔名 config.json 應指向實際要檢查的設定。請在適當的工作目錄執行命令，或改用正確的執行檔路徑。不同發行版本的命令參數可能有所差異；遇到未知參數時，先查看程式內建的說明。圖形化用戶端使用者可優先透過日誌與設定檢查功能，不必為了閱讀本文另外部署背景程序。

xray run -test -config config.json

v2ray test -c config.json

設定測試通過後，先停用衝突的監聽實例，再啟動目標設定。選擇一個明確支援代理設定的應用程式，只設定本次驗證所需的入口，發出一次要求並記錄時間。使用第一章的直連基礎設定時，預期是驗證本機入口，而非遠端代理。接著再加入已確認參數的遠端出口，最後才恢復路由與 DNS。如此每個階段只會增加一個主要變數，即使失敗，也能縮小到剛加入的部分，不必同時猜測入口、解析與遠端連線三個方向。

依照問題現象回到相應層級

若核心無法啟動，優先檢查解析錯誤、未知欄位、連接埠占用與資料檔載入；若程式提示本機連線遭拒，優先檢查監聽位址、連接埠與程序狀態；若核心已收到要求，卻提示網域解析失敗，就回頭檢查 DNS 呼叫流程；若遠端交握失敗，再核對位址、系統時間、協定身分與傳輸安全設定。遇到逾時時，不要立刻認定故障層級，應沿著日誌向前找出最後一個成功階段，以及第一個明確失敗的位置。

測試時應避免應用程式快取造成干擾。既有連線可能繼續沿用舊通道，網域快取可能保留先前結果，系統代理設定變更也未必會立即被正在執行的應用程式讀取。必要時先關閉相關連線或重新啟動測試應用程式，再送出相同要求；但不要一次清除所有設定，讓原始故障失去比較基準。網路切換也會改變連通性與解析路徑，應記錄測試時使用的網路環境。只有在相同條件下重複出現的結果，才適合用來判斷某項設定修改是否真正有效。

保留復原點，不要不斷累積修補

每確認一個階段可用，就保存相應設定與簡短說明，記錄執行核心、入口連接埠、預設出口及依賴檔案。備份若包含訂閱網址或帳號資料，應視為敏感資訊妥善管理，不要放在公開頁面或共用記錄中。出現新問題時，先復原至最近的復原點，再逐項重做修改；不要在失敗的設定上持續增加例外規則與逾時參數。恢復正常後，應刪除已證實無效的修補，避免後續維護者誤以為暫時嘗試是必要設定。

最後還要檢查設定是否持續生效：停止並重新啟動用戶端，確認訂閱更新或模式切換沒有覆寫必要設定，再以相同目標重新驗證一次。除錯結束後，恢復合適的日誌層級，撤除暫時擴大的監聽範圍，並清除不再使用的系統代理設定。若仍無法定位，可將已去除敏感資訊的錯誤片段與最小重現步驟，帶到疑難排解查閱；若只是要重新完成基本流程，請回到使用指南，不要把設定參考手冊中的所有選用項目都當成必要步驟。