Xray 核心與 V2Fly 核心有什麼差異：協定支援、效能與設定相容性比較

先看結論：依節點協定選擇核心

Xray 與 V2Fly 並不是簡單的「新版」與「舊版」關係。兩者沿用相近的設定結構，也共用 VMess、VLESS、SOCKS、HTTP、本機路由與 DNS 等基礎概念，但維護方向已經分開。選擇時不要只看核心名稱，更不要單憑延遲數字判斷。先讀取節點的協定、傳輸層、安全層與 flow 欄位，再確認用戶端實際呼叫的核心。

如果節點使用 VLESS、REALITY 與 XTLS Vision 組合，應選擇 Xray。REALITY 與 xtls-rprx-vision 是 Xray 體系中的關鍵能力，換成 V2Fly 後無法依原參數建立等效連線。如果設定主要使用 VMess、一般 VLESS、WebSocket、gRPC、TLS 與傳統路由規則，兩者可能都能處理，但仍須核對具體版本與欄位支援情況。

兩套核心的關係與分工

V2Fly 延續 Project V 原有技術路線，設定通常圍繞入站、出站、路由、DNS、策略與傳輸設定展開。常見 JSON 頂層結構包括 inbounds、outbounds、routing、dns 與 log。熟悉這些結構後，閱讀 Xray 設定也不會完全陌生。

Xray 源自相同的技術脈絡，保留大量相似概念，同時持續擴充 VLESS、XTLS、REALITY、傳輸機制與路由能力。因此，兩份設定可能有大段相同內容，但某個安全層欄位、flow 值或傳輸參數，就足以決定它們無法互換。

「設定檔能被讀取」也不代表「連線行為完全一致」。某些未知欄位可能在解析階段被忽略，某些欄位會直接觸發啟動錯誤，還有一些欄位雖然名稱相同，但可接受的值或預設行為會隨核心版本改變。遷移設定時必須查看執行記錄與連線結果，不能只看用戶端是否成功啟動。

核心與用戶端介面不是同一層

v2rayN 是桌面用戶端，負責訂閱管理、節點選擇、系統代理、路由模式與核心程序控制。真正處理連線的是用戶端呼叫的核心。不同版本或不同安裝包可能提供不同的核心管理方式，因此應在設定頁或記錄開頭確認目前的核心名稱與版本，不要根據視窗標題猜測。

Android 上的區分更直接：v2rayNG 採用 Xray 核心路線，v2flyNG 採用 V2Fly 核心路線。兩者介面操作可能相近，但協定擴充、匯入結果與可用參數會受到核心影響。節點提供者若明確給出 REALITY 或 Vision 參數，應將這些參數與對應核心一併考量。

協定支援差異：重點檢查 VLESS、XTLS 與 REALITY

VMess：共通基礎不代表所有組合都一致

VMess 是兩套核心都常見的協定。典型的 VMess 節點還會搭配 TCP、WebSocket、HTTP/2 或 gRPC 等傳輸方式，外層也可能使用 TLS。只看「VMess」三個字不足以判斷相容性，還要核對傳輸類型、TLS serverName、路徑、Host、連接埠與使用者識別碼。

對於結構較傳統的 VMess 設定，Xray 與 V2Fly 通常都有良好的處理基礎。實際遷移時仍要留意舊欄位、傳輸名稱變更與訂閱轉換結果。若匯入後節點存在但連線失敗，應展開節點詳細資訊逐項比較，而不是反覆切換系統代理。

VLESS：協定名稱相同，擴充能力可能不同

VLESS 將驗證資訊與傳輸、安全層組合分開，節點通常包含位址、連接埠、使用者識別碼、傳輸方式與加密安全參數。一般 VLESS 設定在不同實作間可能具備一定的相容基礎，但 Xray 對 VLESS 相關擴充的維護更集中，尤其是在與 Vision、REALITY 組合時。

訂閱項目只寫 vless://，並不能證明兩套核心都能直接使用。還要檢查查詢參數中的 security、flow、type、sni、fp、pbk 與 sid。其中部分參數用於 REALITY 握手，遺漏後常見的情況是握手失敗、建立連線後立即關閉，或用戶端提示設定欄位不完整。

XTLS Vision：不能當成一般 TLS 開關

XTLS Vision 通常透過 flow=xtls-rprx-vision 標示。它不是「把 TLS 改成 XTLS」這種單一介面選項，而是需要用戶端、伺服器、協定與傳輸組合共同匹配。節點提供 Vision 時，應保留完整的 flow 值，不要在訂閱轉換或手動編輯時刪除。

Vision 主要面向 Xray 體系。將同一節點切換至 V2Fly，即使位址、連接埠與使用者識別碼完全相同，也不能據此推斷連線會成功。伺服器期待的握手與流量控制行為未能匹配時，用戶端可能出現逾時、連線重設或 TLS 類錯誤。

REALITY：需要成組核對參數

REALITY 是 Xray 中常用的安全與握手方案，常與 VLESS、TCP 和 Vision 搭配。用戶端通常要核對 serverName、公鑰、shortId、指紋參數以及 flow。伺服器使用的私鑰不會出現在用戶端訂閱中，用戶端取得的是建立握手所需的公開參數。

serverName 必須符合伺服器設定允許的名稱；公鑰或 shortId 多一個字元、少一個字元都會失敗。指紋參數用於描述用戶端握手特徵，也必須使用核心支援的值。遇到 REALITY 節點無法使用時，先比對這些欄位，再確認系統時間、網路出口與伺服器狀態。

設定相容性：相似 JSON 中最容易遺漏的差異

Xray 與 V2Fly 的基礎設定都常採用 JSON。入站負責接收本機流量，出站負責連線至目標或代理伺服器，路由規則決定流量交給哪個出站。由於結構相近，許多使用者會直接複製整份設定並替換執行核心。這種做法只適用於欄位明確屬於雙方共通能力的設定。

第一類差異：安全層與 flow

檢查 streamSettings 下的安全類型。一般 TLS 設定通常涉及 serverName、ALPN 等資訊；REALITY 設定則會出現專用設定。接著檢查 VLESS 使用者或節點資訊中的 flow。若保留 Xray 專屬值卻改用 V2Fly，設定可能無法啟動，也可能啟動後無法完成連線。

第二類差異：傳輸參數與版本

WebSocket 的路徑與 Host、gRPC 的服務名稱、TCP 的標頭設定，都可能因設定格式、版本演進或訂閱轉換而產生差異。即使兩套核心都支援某種傳輸，用戶端產生的最終 JSON 也未必完全相同。排查時應查看用戶端寫入的實際設定，而不是只檢查訂閱原文。

伺服器與用戶端版本差距過大時，還可能出現新欄位無法識別、舊寫法調整或預設值變更。升級前先記錄目前可用節點、路由模式與核心類型；升級後先測試一個節點，再恢復複雜的分流規則。如此可以將協定問題與路由問題分開。

第三類差異：DNS 與路由分流

路由規則通常依據網域、IP、連接埠、網路類型或入站標籤選擇出站。兩套核心都具備相關能力，但規則欄位、匹配行為與可用擴充會隨版本變化。遷移時應重點檢查 domainStrategy、規則順序、出站標籤與 DNS 查詢路徑。

規則若依序由上至下匹配，前面的寬鬆規則可能提前接管流量，使後續精細規則無法執行。出現「節點能連線但部分網站沒有走預期出口」時，應暫時切換至較簡單的全域測試模式。確認核心與節點可用後，再逐條恢復網域與 IP 分流。

第四類差異：標籤引用

設定中的 tag 是內部引用名稱。路由規則指向的出站標籤必須確實存在，DNS 或入站相關規則也要引用正確物件。複製設定時若只複製出站、遺漏對應標籤，核心可能提示找不到目標，或讓流量落入預設出站。標籤名稱本身不決定協定，但錯誤引用會偽裝成協定不相容。

效能比較：不要用一次測速取代判斷

Xray 或 V2Fly 的名稱本身不能直接決定速度。實際吞吐量與延遲由伺服器線路、往返距離、壅塞程度、裝置效能、協定組合、傳輸層、加密處理、分流規則與測試目標共同決定。兩次測試若使用不同節點、不同時間或不同網路，結果並沒有直接可比性。

在同一線路與相近設定下，Xray 的 Vision 等方案可以降低特定組合中的額外處理，並針對現代連線方式進行最佳化。但這不代表所有 Xray 設定必然比所有 V2Fly 設定快。一般 VMess 或 VLESS 節點若瓶頸位於伺服器頻寬與網路路徑，切換核心後可能幾乎沒有變化。

正確的比較方法

1. 固定使用同一台裝置、同一個本機網路與相同測試時段。
2. 使用同一條伺服器線路，並確保連接埠與傳輸條件具有可比性。
3. 先關閉複雜路由規則，排除 DNS 與分流造成的干擾。
4. 每種組合至少測試多次，分別記錄建立連線時間、延遲、下載吞吐量與長連線穩定性。
5. 查看用戶端記錄中的重新連線、逾時與握手錯誤，不要只記錄最高速度。

記憶體與 CPU 使用量也要放在實際情境中觀察。大量並行連線、複雜網域規則與頻繁 DNS 查詢都會增加資源消耗。桌面裝置與 Android 裝置的背景策略不同，不能直接將兩個平台上的數字放在一起比較。

如果連線每隔幾分鐘就中斷，優先檢查網路切換、系統省電限制、伺服器閒置逾時與用戶端背景狀態。單純替換核心可能暫時改變表現，卻不一定觸及真正原因。

訂閱相容性：匯入成功不代表參數完整

訂閱負責批次傳遞節點資訊，但不同訂閱格式對擴充欄位的表達能力不同。用戶端顯示節點名稱，只能表示項目已被識別，不能證明 REALITY 公鑰、shortId、serverName、指紋與 flow 都已正確寫入最終設定。

v2rayN 匯入訂閱後，應開啟節點詳細資訊，核對協定、傳輸、安全類型與 flow。更新訂閱前手動修改的欄位，可能在下一次更新時被覆蓋。需要長期保留的參數應由訂閱來源正確提供，而不是依賴每次更新後重新補寫。

v2rayNG 處理 Xray 路線的節點時，應確認應用程式版本與節點參數相符。v2flyNG 更適合明確面向 V2Fly 的設定。將同一條進階 VLESS 連結分別匯入兩個用戶端，即使兩邊都產生節點，也不能據此認為底層能力一致。

訂閱轉換還可能調整欄位名稱、刪除無法識別的參數，或將傳輸類型對映為舊寫法。發現原始分享資訊可用、匯入訂閱後卻無法使用時，應比較兩者產生的節點詳細資訊。重點找出遺漏欄位，不要先修改連接埠或任意關閉安全設定。

依使用情境選擇 Xray 或 V2Fly

情境一：節點明確使用 REALITY 或 Vision

選擇 Xray。不要嘗試將 REALITY 改成一般 TLS，也不要刪除 Vision flow 來追求表面上的相容性。安全層與流量控制是伺服器設定的一部分，用戶端必須依伺服器要求連線。桌面端可在 v2rayN 中確認實際呼叫的核心；Android 端使用 v2rayNG 並核對匯入欄位。

情境二：已有穩定運作的 V2Fly 設定

如果現有設定使用一般 VMess、VLESS、WebSocket、gRPC、TLS、DNS 與路由規則，而且伺服器與用戶端長期穩定，沒有必要只為了更換名稱而遷移。繼續使用 V2Fly 時，應記錄目前版本與設定結構，升級後依節點、DNS、路由的順序驗證。

情境三：同一份訂閱混合多種節點

先依能力將節點分類。一般 VMess 或一般 VLESS 放在一組，REALITY 與 Vision 節點放在另一組。用戶端切換核心後分組測試，避免將所有失敗都歸因於訂閱。若用戶端允許為不同節點選擇適合的核心，也應在切換後重新產生設定並查看記錄。

情境四：設定依賴複雜分流

先選擇能完整支援節點協定的核心，再遷移分流規則。節點層尚未連通時，複雜路由只會增加變數。建議先保留一個本機代理入站與一個節點出站，確認基礎連線；然後增加直連出站、網域規則、IP 規則與 DNS 策略。

情境五：只在意低延遲與穩定連線

優先選擇與伺服器設定一致、用戶端維護正常且記錄清晰的組合。延遲差異很小時，穩定性比單次測速峰值更具參考價值。持續使用一段時間，觀察斷線、重新連線、DNS 失敗與背景維持情況，再決定是否遷移。

從 V2Fly 切換至 Xray 的檢查清單

1. 記錄目前環境。記下用戶端版本、核心名稱、可用節點、監聽連接埠、系統代理模式與路由模式。
2. 備份設定內容。儲存訂閱網址與自訂路由規則，避免升級或切換後無法還原。
3. 確認節點協定。逐一標記 VMess、VLESS、傳輸方式、安全層與 flow，不要只依節點名稱分類。
4. 檢查本機連接埠。確認 SOCKS 與 HTTP 入站連接埠未被其他程序佔用，切換核心時避免舊程序仍在背景執行。
5. 先測試單一節點。關閉複雜分流，選擇一個參數完整的節點驗證基礎連線。
6. 檢查執行記錄。區分設定解析、DNS、握手、驗證、逾時與路由錯誤。不同錯誤對應不同的檢查方向。
7. 恢復路由規則。依由簡到繁的順序加入直連、代理與攔截規則，每次修改後測試具代表性的網域。
8. 更新訂閱後重新核對。確認更新沒有覆蓋手動參數，尤其是 REALITY 與 Vision 所需欄位。

反向從 Xray 切換至 V2Fly 時，應先移除對 Xray 專屬能力的依賴，而不是直接替換核心檔案。只要節點仍要求 REALITY 或 Vision，V2Fly 就無法提供等效連線。需要繼續使用原節點時，應保留 Xray；需要使用 V2Fly 時，則要準備伺服器明確支援的設定組合。

常見問題

最終選擇原則

Xray 的明確優勢在於 XTLS、REALITY，以及圍繞 VLESS 的持續擴充。V2Fly 的重點是延續原版設定體系與既有功能路線。兩者都有適用情境，判斷核心不是品牌偏好，而是伺服器要求、節點欄位、用戶端支援與現有設定成本。

實際選擇時執行三步：第一步確認節點是否包含 REALITY 或 Vision；第二步確認用戶端實際執行的核心；第三步在關閉複雜分流後測試基礎連線。基礎連線通過後，再恢復訂閱更新、DNS 與路由規則。依此順序處理，可以避免將核心相容性、訂閱缺少欄位與分流錯誤混為一談。