V2Ray 進階設定指南

01 · 訂閱與項目

訂閱分組與伺服器篩選

訂閱網址是取得伺服器設定的入口，分組則是用戶端在本機整理項目的方式，兩者不能混為一談。一個分組通常對應一個來源，也可能包含手動新增的伺服器。進行進階設定前，請先分別記錄「來源、顯示名稱、用途」：來源用於更新，名稱用於辨識，用途則用於篩選。分組名稱即使是「辦公」，用戶端也不會因此自動讓辦公軟體使用其中的伺服器；實際流量仍取決於目前使用的伺服器、路由規則及流量接管方式。

先建立方便追蹤的分組

在 v2rayN 的訂閱分組設定中新增分組，填入簡短且固定的備註，再貼上完整訂閱網址。若網址含有查詢參數，必須完整保留；複製時若混入換行、空格或網頁標點，都可能改變請求結果。儲存後只更新這個分組，確認更新提示與項目數量變化，再檢查伺服器的協定、位址和連接埠是否完整。不要一次新增多個來源後立刻批次更新，否則清單為空時，很難判斷是網址錯誤、請求失敗，還是來源本身沒有回傳內容。

訂閱連結可能含有帳戶存取憑證，分享截圖、記錄或匯出設定前，都應隱藏完整網址。一般整理不需要將訂閱內容傳送給不熟悉的轉換工具。若來源提供用戶端專用格式，請優先使用與目前用戶端相符的入口；內容能在瀏覽器中顯示，不代表用戶端就能解析。登入頁、到期通知和錯誤頁都可能回傳成功的網路狀態，卻不是有效的伺服器清單；應搭配用戶端更新記錄判斷，而不只是確認頁面能否開啟。

顯示篩選與更新篩選的差異

清單搜尋通常只會暫時隱藏不符合條件的項目，清除搜尋後仍可看到所有伺服器；部分訂閱分組的篩選設定則會影響匯入結果，被排除的伺服器更新後可能根本不會出現在本機清單。操作前先看欄位說明，確認篩選作用於顯示或更新。建議先用一般關鍵字測試，例如依備註中的地區標記搜尋；只有介面明確支援正規表示式時才使用，別把所有輸入欄位都當成相同的比對工具。

以支援正規表示式的備註篩選為例，辦公|備用表示符合其中任一詞，^辦公表示從備註開頭比對。大小寫規則、空白備註的處理方式及排除語法，應以該欄位的實際支援情況為準，不宜照搬其他工具的寫法。儲存複雜篩選條件前，先確認現有清單至少有一筆符合，再單獨更新一次。若結果突然變成空白，請先取消篩選並重新更新；不要立刻刪除整個分組，以免一併遺失本機備註和手動新增的項目。

為更新與切換保留回復方式

訂閱更新可能覆寫伺服器參數、替換識別資訊，或移除來源已刪除的項目。需要長期保留的手動修改，建議複製到獨立的本機分組，並記錄修改原因；不要長期依賴訂閱項目承載自訂參數。更新完成後，重新確認目前使用的伺服器仍在清單中，再實際開啟網頁測試。延遲測試只能反映特定探測路徑的結果，不代表所有服務都能正常使用；選擇節點時也可參考延遲、倍率、地區與協定類型的取捨方式。

02 · 比對與分流

V2Ray 路由規則實作

路由決定的是「已進入核心的連線，應交由哪個出站處理」。它不會讓所有應用程式自動進入用戶端，也不等同於系統代理開關。若應用程式繞過本機代理，核心中的規則就無從比對。排查分流問題時，請先確認請求確實進入用戶端，再檢查目標網域或位址、符合的規則，以及最後採用的出站。將流量接管、規則比對與轉送拆成三個環節，比直接更換整套路由預設值更容易找出問題。

了解規則順序與比對欄位

常見核心會依規則順序尋找符合項目，前面的寬鬆規則可能會先攔截流量，讓後面的精確規則無法生效。因此，應先列出明確的本機服務與特定網域，再安排範圍較大的位址集合，最後才設定預設方向。同一條規則中的不同類型條件通常必須同時成立；同一份網域清單中的多個值則代表可接受的比對選項。不要在同一條規則中放入互不相關的網域條件和位址條件，卻期待它們各自成立。閱讀設定時，應以單條規則的完整條件進行判斷。

網域寫法也有適用範圍：full:example.com只比對指定網域，domain:example.com則比對該網域及其子網域；一般字串可能會以較寬鬆的關鍵字方式比對。若只想處理特定服務，請優先使用精確網域或明確的網域後綴。直接設定 IP 規則時，請留意目標可能有多個位址，也可能因網路不同而回傳不同結果，因此單一位址規則無法可靠地代表整個網站。若規則仰賴地理資料庫，也必須確認對應資料檔存在，且目前的核心能夠讀取。

從最精簡的規則集開始驗證

以下是 Xray 風格的路由片段，並非完整設定檔。範例會將測試網域和內網位址交由直連出站處理，其他連線則維持原有預設行為。假設已有標籤為 direct 的出站；若實際標籤不同，必須一併修改。合併至自訂設定時，請保留原有入站與代理出站，不要直接用片段覆蓋整個檔案。若圖形介面的路由編輯器會自動產生這些欄位，請直接在介面中修改，避免下次啟動時設定又被覆寫。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

網域解析策略不等於路由預設值

AsIs表示路由階段會盡量依據現有目標資訊判斷，不會為了比對 IP 規則而主動解析網域。IPIfNonMatch會在網域未符合規則時嘗試解析，再比對位址；IPOnDemand則可能在遇到位址條件時提早解析。解析策略會改變查詢次數和比對結果，但不會自動將 DNS 請求送往正確的伺服器。使用位址集合前，應先確認 DNS 設定與解析路徑，再決定是否需要讓路由階段主動解析，避免為原本可用網域表示的規則額外增加依賴。

驗證時選定一個目標，只發出一次新請求，再查看存取記錄中的目標與出站標籤。瀏覽器可能繼續重用既有連線；修改規則後，請關閉相關連線或重新開啟應用程式測試。如果網域規則始終沒有命中，請檢查應用程式是否只將 IP 傳給核心，以及嗅探功能能否取得網域資訊；若資訊不足，反覆調整規則順序也無法解決。系統代理模式的基本差異請參閱代理模式說明；連線後仍無法存取網路，請依逐項排查清單檢查。

03 · 查詢與解析路徑

DNS 設定最佳化

DNS 設定不能只理解成「換一個伺服器位址」。一次連線可能涉及應用程式本身的解析器、作業系統解析器、用戶端內建 DNS，以及遠端代理處理目標網域時採用的解析路徑。瀏覽器若啟用加密 DNS，也可能不再使用系統的一般 DNS 請求。最佳化的第一步是確認由誰查詢、查詢送往何處，以及結果由誰使用。只有請求確實由某個模組處理，修改該模組的設定才會生效。

區分引導解析與一般解析

若代理伺服器位址使用網域名稱，就必須在連線至代理之前取得其實際位址，這個步驟稱為引導解析。若強制將所有查詢交給尚未建立的代理，可能陷入「必須先連上代理才能解析代理位址」的循環。解決方式是為伺服器網域保留可直接運作的解析路徑，或使用來源明確提供的伺服器位址；不要自行將網域解析出的某個位址永久寫死，因為來源可能會調度或更換位址。一般網站的解析則應依實際出站需求另行規劃。

在 v2rayN 中調整 DNS 前，先記錄目前的路由預設值、核心類型及 DNS 編輯方式。有些介面會分別提供一般代理與 TUN 的 DNS 範本；有些進階選項則允許直接編輯核心設定。若修改的範本未套用於目前模式，執行結果就不會改變。儲存後重新啟動相關核心，並從記錄確認設定已成功載入。若出現不支援的欄位，請先還原原設定，再核對目前核心支援的語法；不要猜測其他核心中同名的設定是否通用。

了解常用參數的影響

以下展示 Xray 內建 DNS 常見的最精簡欄位組合，僅用於說明結構。公共解析位址並非適用所有網路的最佳選擇，請先確認目前網路是否可連線。UseIPv4用於明確指定僅查詢 IPv4 的測試條件，不應設為所有環境的永久設定；若需要 IPv6，應先確認系統、網路及代理路徑都能正常使用，再恢復相應的查詢策略。這段設定也不會接收系統送出的所有 DNS 請求，更不會自動在 TUN 模式下接管 DNS。

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

依照現象逐層排查

若所有網域都無法解析，但數字位址可連線，請先檢查解析器連線狀態與查詢出站；若只有特定網域失敗，請檢查網域分流規則、快取及上游回傳結果；若解析成功但連線逾時，則應優先確認取得的位址是否真的可連線。加密 DNS 的憑證驗證仰賴正確的系統時間；使用網域名稱作為解析服務位址，也可能增加引導解析需求。測試時一次只更改一個變因，並記錄查詢耗時與錯誤類型；不要同時更換解析器、路由策略和代理節點。

IPv6 問題尤其容易與 DNS 混淆。取得 IPv6 位址，不代表本機網路或代理出站一定能連上該位址；反過來說，全面停用 IPv6 也可能影響原本可正常使用的服務。請先在可控制的測試中限制查詢類型，觀察失敗是否隨位址家族改變，再決定要修復網路或調整策略。切換 Wi-Fi、有線或行動網路後，必要時重新建立連線並清除相關快取；瀏覽器和系統各自都有快取，只重新啟動用戶端未必能清除所有舊結果。

04 · 流量接管

啟用 TUN 模式與還原方式

TUN 會透過虛擬網路介面接收 IP 封包，適合用來接管不遵循系統代理設定的應用程式，但它不是代理協定。進入 TUN 的資料仍須經過路由、DNS 處理及出站連線，實際能力取決於所使用的後端。v2rayN 可透過專用的 TUN 後端接管流量，因此不能將介面上的 TUN 開關直接視為 Xray 核心設定中的某個欄位。請先查閱目前用戶端的說明與執行記錄，確認使用的後端，再檢視網路堆疊、路由和 DNS 參數。

啟用前先完成基本連線驗證

先使用一般系統代理模式，確認節點能存取目標服務，再檢查作業系統是否允許建立虛擬介面及修改路由。Windows 可能需要以適當權限啟動用戶端或啟用相關服務；macOS 與 Linux 則可能需要授權或配套服務支援。權限不足、介面建立失敗和伺服器連線失敗屬於不同問題，應依記錄分別處理。桌面版安裝檔請至下載中心取得，不要透過來源不明的額外元件，處理尚未釐清的錯誤。

啟用前暫時關閉其他會修改預設路由、DNS 或虛擬介面的軟體，並記錄原本的網路狀態。若是遠端連線至其他裝置進行操作，請特別謹慎：切換路由可能會立刻中斷管理連線，應先準備本機復原方式。首次測試不要同時啟用嚴格路由、自訂排除網段和 FakeDNS；保留預設參數，先確認介面已建立、代理伺服器可連線且一般網頁可正常瀏覽，再逐項加入所需功能。

了解網路堆疊、自動路由與排除項目

網路堆疊負責將接收到的封包轉換為可處理的連線；不同實作在系統相容性、UDP 支援和資源使用上可能有所差異。某種網路堆疊能在一個系統上使用，不代表所有裝置都應優先選用。自動路由負責將目標流量導入虛擬介面，排除項目則用來保留本機服務、區域網路或特定連線的原有路徑。應先確認後端已正確排除代理伺服器本身的連線，避免出站流量再次進入 TUN，形成重複接管。

MTU 表示介面可承載的封包大小，並非數值越大速度越快。若小型網頁可以瀏覽，但大型檔案、特定應用程式或部分連線常常停住，除了節點與 DNS，也可以檢查路徑 MTU 和分片問題。調整時請依照後端支援範圍小幅變更，每次都重新建立測試連線，並保留原始數值。只憑一次網頁載入結果，就將 MTU 固定為網路上看到的數值，往往會掩蓋真正的問題；切換網路後尤其容易再次發生。

跨平台差異與驗證順序

Android 上的 v2rayNG 與 v2flyNG 通常透過系統 VPN 介面接管應用程式流量，授權畫面與桌面系統的虛擬介面管理並非同一套機制。依應用程式設定代理、略過區域網路，以及背景執行限制，都可能影響實際接管範圍。啟用其中一個用戶端前，應先停止另一個占用相同介面的連線；若系統省電策略終止背景程序，也可能造成螢幕鎖定後連線中斷。不要將桌面用戶端的服務安裝方式直接套用到 Android。

驗證時依序檢查一般網頁、本機閘道或區域網路服務、需要 UDP 的應用程式，再測試網路切換與裝置喚醒。若啟用後完全無法連線，請先關閉 TUN，確認一般網路已恢復，再查看介面、路由及 DNS 記錄。若關閉後仍有異常，請結束用戶端並檢查系統是否仍保留代理設定，再重新連線網路。只有接管層持續穩定後，才適合進一步調整嚴格路由與排除網段；優先恢復網路，不要繼續堆疊進階參數。

05 · 網域映射

FakeDNS 與 DNS 接管

FakeDNS 會為網域指派合成位址，並在後續連線抵達時，依據映射找回原始網域。合成位址供用戶端內部辨識使用，並非網站的實際伺服器位址。這項功能的用途是：當應用程式先自行解析，接著只使用 IP 建立連線時，代理仍有機會還原網域，進而套用網域路由或將網域名稱交由遠端處理。它不會自動改善節點品質，也無法脫離 DNS 接管與流量接管單獨運作。

先確認映射流程是否完整

完整流程包含四個步驟：應用程式的查詢進入指定解析模組，模組回傳合成位址，應用程式連線至該位址，用戶端收到連線後還原網域。任何一步繞過用戶端，都可能導致失敗。例如，瀏覽器使用自己的加密 DNS，查詢未進入映射模組；或系統取得了合成位址，卻因排除路由而直接透過實體網路連線；也可能是產生映射的模組與接收連線的模組不是同一個實作。遇到這些情況時，單純啟用嗅探未必能解決問題。

因此，請先確認一般 TUN 與實際 DNS 解析都穩定，再決定是否使用 FakeDNS。v2rayN 的 TUN 後端可能提供自己的合成位址機制，不能只因名稱相似，就認定它與 Xray 設定中的 FakeDNS 可以互相取代。欄位名稱、位址池、快取方式和路由需求，都應依照實際後端確認。除非已有明確的相容性設計，否則不要同時啟用兩套機制並共用同一個位址範圍；不同模組保存的映射可能不一致，同一個合成位址也可能代表不同網域。

位址池與映射容量

以下是 Xray 風格的相關片段，展示位址池、DNS 伺服器選擇及入站嗅探之間的關係，並非可直接取代用戶端設定的完整檔案。入站的嗅探欄位應合併至實際接收該流量的入站，不要任意新增至根物件。198.18.0.0/15是常見的合成位址池選擇，啟用前仍須確認本機網路沒有使用此範圍或將其設定特殊路由，並確保相關連線不會直接離開代理接管路徑。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

poolSize控制映射容量，不代表可同時支援的伺服器數量。瀏覽大量不同網域時，容量與淘汰方式會影響舊位址是否仍能還原為原始網域。應用程式可能長時間保留解析結果，但核心重新啟動後，原有映射已遺失；此時應用程式若繼續連線舊的合成位址，就可能失敗。若只有重新啟動用戶端後，部分應用程式才出現異常，請先結束應用程式、清除相關 DNS 快取並重新建立連線，不要立刻更換代理協定。

例外網域與故障現象

區域網路名稱、裝置探索、依賴實際位址的應用程式，以及需要特殊 DNS 記錄的服務，都應分別確認是否適合使用合成位址。部分應用程式會檢查解析結果是否位於預期網路，或將結果交給未受用戶端接管的其他程序，因此必須依後端支援方式設定例外。例外網域應繼續回傳實際位址，並與對應的直連或代理規則搭配；不能一邊回傳合成位址，一邊又將該範圍加入完全繞過用戶端的清單。

排查時先確認系統或應用程式是否取得合成位址，再檢查連線是否抵達接管介面，最後查看記錄是否已還原原始網域。若合成位址出現在實體網路連線中，應優先修正接管與路由，而不是更換 DNS 伺服器。停用 FakeDNS 時也要處理快取：先切換回實際解析，重新啟動受影響的應用程式，必要時清除系統快取，再確認所有連線都不再依賴舊映射。若只關閉開關卻保留舊位址，故障可能在設定還原後繼續發生。

06 · 來源與維護

多訂閱管理與更新策略

多訂閱管理的重點是區隔來源、控制更新影響並保留可復原狀態，而不是將所有伺服器合併成難以辨識的長清單。建議每個來源使用獨立分組，並以固定格式記錄「來源代號與用途」；暫時測試的來源則另行存放。增加來源後，先建立管理規則再批次更新；否則同名項目、不同協定與訂閱變更混在一起，切換時容易選錯伺服器，也難以判斷參數來自哪個來源。

釐清分組、項目與使用中連線的關係

選擇分組通常只會變更目前的清單檢視，不一定會切換使用中的伺服器；部分介面則允許在分組內重新選擇後立即切換。操作時應確認實際的使用中標記，而不只是查看上方顯示的分組名稱。伺服器備註不是穩定的唯一識別資訊，兩個來源可能提供同名項目，同一來源也可能在更新時更改名稱。排查更新影響時，比對協定、目標位址、連接埠和傳輸參數，會比只比對顯示名稱可靠。

自動去重也需要謹慎。兩台伺服器使用相同位址和連接埠，不代表設定等效；識別欄位、TLS 名稱、路徑或流控參數不同，都可能對應不同的連線方式。除非清楚用戶端依哪些欄位判斷重複，否則不要為了縮短清單而批次刪除。若確實需要精簡，請先依分組篩選並保留必要的本機紀錄；操作後再更新一次分組，確認來源不會重新下發相同項目。

為自動更新設定合理限制

更新週期應依來源的實際變動頻率和用戶端使用習慣決定。更新過於頻繁會增加請求與排錯干擾，也無法讓已失效的來源恢復正常。首次新增時請手動更新；確認內容穩定後，再啟用用戶端支援的排程策略。裝置休眠、網路尚未就緒或背景程序暫停時，排程不一定會如預期執行，因此重要使用情境前仍應檢查最近一次更新結果，不要只確認已設定排程。

也要分清楚實際上是否需要「透過代理更新」或「直接更新」。若某個來源只能透過特定路徑存取，應明確選擇更新請求使用的路徑；但不要讓唯一可用的訂閱更新完全依賴即將替換的使用中伺服器。修改更新方式後，請單獨測試一個分組，保留記錄中的網路錯誤類型，同時隱藏完整訂閱網址。多個分組同時失敗時，先檢查共同的網路和代理依賴，通常不必逐一重新建立來源。

備份、移轉與來源停用

移轉用戶端前，請使用介面提供的匯出或備份功能，並確認匯出內容是否包含訂閱網址、手動新增的伺服器、路由和 DNS 設定。不同備份範圍不能混為一談，單一分享連結通常不足以還原整個使用環境。備份檔可能含有身分資訊，應儲存在安全的位置。移轉至其他裝置後，先確認本機連接埠、檔案路徑、服務權限和虛擬介面設定是否適用，不要將舊裝置的所有網路參數都當成通用設定。

來源停用時，先切換至已驗證可用的伺服器，關閉該分組的自動更新，再決定刪除或保留本機紀錄。直接刪除目前使用中的項目可能會中斷連線；某些應用程式也可能繼續重用舊連線，造成「清單已更新，請求卻仍走舊路徑」的錯覺。刪除後應重新建立測試連線，並確認沒有路由或自訂出站仍引用該項目。長期不使用的訂閱也應從自動更新清單中移除，減少無意義的錯誤通知。

管理規模擴大後，可以維護簡短的變更紀錄：修改了哪個分組、更新了哪些參數、驗證了哪些情境，以及如何復原。紀錄不應包含完整訂閱網址或身分欄位。記錄的用途是將故障與最近操作連結起來，而不是另建一套複雜的設定系統。若無法判斷問題來自來源更新或本機設定，可先在獨立分組匯入相同來源，只比較項目與連線結果，不要修改原有的穩定分組。

07 · 標籤與轉送

自訂出站與設定合併

出站設定描述核心如何發起連線，路由則透過標籤將請求交給對應出站。規則中寫入 outboundTag，不代表用戶端已建立該出站；該標籤必須確實存在於最終執行設定中，拼字和大小寫也必須一致。自訂出站適合明確的轉送需求，不宜用來取代所有圖形介面設定。日常使用時，建議優先由 v2rayN 管理標準伺服器設定，只將確有需要的部分交由自訂設定處理，以降低更新和移轉成本。

先確認最終設定由哪個功能管理

圖形化用戶端通常會依據目前伺服器、路由預設值和 DNS 範本產生執行設定。直接修改暫存產生檔，下一次切換伺服器或啟動核心時可能會被覆寫。請先確認目前的設定入口是「編輯伺服器」、「編輯路由」還是「完整自訂設定」，三者的控制範圍不同。使用完整自訂設定時，也要確認用戶端是否仍會加入本機入站、記錄及管理介面；不要假設圖形介面中的每個選項都會繼續生效。

修改前先匯出目前可用的設定，並從記錄確認實際使用的核心。Xray 與 V2Fly 都採用 JSON 風格的設定，但支援的欄位和協定並不完全相同，更不能直接混用其他 TUN 後端的設定結構。將片段合併至現有檔案時，請確認根物件、陣列和逗號格式正確；同一物件若出現重複鍵，解析器可能覆寫設定而不明顯報錯。設定通過語法解析，只能證明格式正確；還要確認核心接受欄位並成功建立連線。

從直連與本機轉送了解標籤

以下 Xray 風格的出站片段展示兩個標籤：direct代表直接連線，local-socks則將請求交給本機迴圈位址上的 SOCKS 服務。只有本機連接埠確實有相應服務監聽時，第二個出站才可使用；範例中的連接埠不代表所有用戶端的預設值。不要將它指向目前設定自己的入站連接埠，否則可能形成循環轉送。若已有出站陣列，請合併需要的物件，不要覆蓋原有的代理出站。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1080
          }
        ]
      }
    }
  ]
}

這類設定中，未符合任何路由的流量通常會使用出站陣列中的第一個出站，因此範例預設採用直連，不能當成完整的日常代理設定。實際合併時，請保留既有的預設出站，並使用精確規則引用新增標籤。先選一個測試網域交由 local-socks 處理，確認本機服務可正常運作後，再擴大比對範圍。不要剛新增出站就用涵蓋所有連線的規則測試，否則錯誤會影響整條存取路徑。

區分鏈式轉送與出口選擇

同時存在多個出站，不代表請求會依序經過它們。一般情況下，一條連線只會選擇一個出站；只有明確設定核心支援的鏈式機制，才會形成前後相依。鏈式連線還需考慮哪一段負責解析伺服器網域、哪一段處理 UDP、前段失效時該如何應對，以及應從哪一側查看記錄。若沒有明確需求，不建議為了形式上的「多一層」而疊加轉送，這會增加連線建立時間和故障排查難度。

驗證自訂出站時，先確認下游服務的監聽位址與連接埠，再確認標籤存在，最後查看規則比對結果和連線錯誤。若記錄顯示連線遭拒，請優先檢查監聽服務；若找不到出站，請檢查標籤和設定合併；若出現循環或大量重複連線，請立即停止相關核心並還原基準設定。復原後再逐項加入修改。關於核心與圖形化用戶端的分工，可參閱Project V 開源生態整理；不要將用戶端名稱直接當成出站協定名稱。

08 · 相容性與驗收

協定、核心與設定驗收

完成進階設定前，必須建立一套相容性判斷流程：用戶端能否設定這些參數、所選核心能否解析相關欄位、伺服器端是否具備對應能力，以及目前網路是否允許建立連線。四項缺一不可。用戶端提供某個選項，不代表任何伺服器都能使用；匯入後看得到備註，也不代表參數已完整套用。桌面環境建議使用 v2rayN 管理設定；Android 則依需求選擇 v2rayNG 或 v2flyNG，實際支援範圍仍以所用核心和匯入結果為準。

分開核對協定、傳輸方式與加密層

VLESS、VMess、Trojan 和 Shadowsocks 的身分驗證與連線機制各不相同，不能只更改協定名稱就彼此轉換。傳輸方式負責承載連線，TLS 或 REALITY 等設定則涉及交握和目標身分參數。排查時應逐層核對：先確認協定與身分欄位，再檢查位址和連接埠，接著確認傳輸路徑與服務名稱等參數，最後核對 TLS 名稱或 REALITY 所需欄位。來源未提供的值，不應拿其他伺服器的設定自行補上。

VLESS 本身不具備與 TLS 相同的傳輸加密能力，應依伺服器要求搭配相應的安全層。REALITY 與 XTLS Vision 也不是可以任意互換的兩種協定標籤，實際使用會涉及安全層、流控與核心支援。常見的交握失敗可能源自伺服器名稱、金鑰相關欄位、短識別碼或系統時間不一致，不一定是路由規則錯誤。原理與設定項目之間的關係可參閱REALITY 與 XTLS Vision 原理說明；測試時仍應以來源提供的完整參數為準。

切換多種核心不是通用的故障解法

Xray 與 V2Fly 是 Project V 相關生態系中的不同核心路線，圖形化用戶端則負責將介面設定轉換成核心執行設定。v2rayNG 主要採用 Xray 核心路線，v2flyNG 則以 V2Fly 為主；不能期待含有特定擴充功能的設定能在兩者之間原樣移轉。v2rayN 選擇核心時，也應考量所用協定和設定範本。切換前先記錄原本的核心與已啟用的進階功能，停止原有連線，再確認新核心是否成功啟動，而不只是查看介面上的執行圖示。

匯入後若有欄位遺失，請先確認分享格式是否能包含這些參數，以及目前用戶端是否支援該格式。必要時可在圖形介面逐項核對，但不要將真實身分欄位貼到公開求助內容中。核心啟動失敗時，優先檢查設定語法、未知欄位、連接埠占用和相依檔案；若核心已啟動但交握失敗，再檢查伺服器參數、系統時間和網路連線。兩類問題的處理方式不同，盲目更換核心只會讓線索更混亂。

建立可重複執行的驗收流程

每次修改後都依相同順序驗收：先確認核心成功載入設定，再確認本機入口可正常使用，接著測試一般網域、明確直連的目標，以及必須透過代理的目標，最後才檢查 TUN、UDP、IPv6 或合成位址等附加功能。瀏覽器成功開啟一個頁面，只能證明該頁面當下所經過的路徑可用。對長連線、背景應用程式和網路切換，應另外重新建立連線測試，避免舊連線掩蓋新設定的實際問題。

整理記錄時，應包含時間、目標、入站、命中規則和出站標籤；保留錯誤訊息的原始類型，但隱藏訂閱網址、身分欄位和不必要的個人存取紀錄。暫時提高記錄層級有助於定位問題，排除故障後應恢復適當層級，減少長期記錄。若一次修改涉及多個章節，請先回到最後一個可用狀態，再依序恢復訂閱、路由、DNS、流量接管及擴充功能；這比在異常狀態下繼續微調更容易重現與驗證。

本頁用於了解設定之間的相依關係，不需要啟用所有功能。最終應保留一組容易理解、驗證和復原的設定：一般應用程式依預期接管，本機服務可正常存取，解析路徑與路由一致，更新訂閱也不會破壞手動設定。若要重新完成首次連線，請回到快速入門指南；若要依現象搜尋解答，請參閱常見問題。將每次驗證結果與最近一次修改相互對照，才能讓進階設定從一次性嘗試轉變為容易維護的使用環境。