Xray 與 V2Fly 核心有什麼差異：版本關係整理與用戶端選擇建議

先釐清用戶端、核心與訂閱的關係

v2rayN、v2rayNG 與 v2flyNG 是提供圖形介面的用戶端，負責儲存節點、更新訂閱、切換系統代理、產生執行設定並顯示日誌。Xray 與 V2Fly 則是實際處理連線的核心：監聽本機連接埠、執行路由規則、完成協定握手，再將流量傳送至遠端伺服器。介面能正常開啟，不代表核心已成功啟動。

訂閱位於兩者之間。訂閱服務回傳節點清單，用戶端會將連結中的協定、位址、連接埠、傳輸層與 TLS 參數轉換為核心設定。同一份訂閱匯入不同用戶端後，最後產生的 JSON 可能不相同，因為用戶端會補上本機入站、DNS、日誌與路由設定。

因此，「V2Ray 節點」通常只是生態圈中的泛稱，不能直接推斷底層一定執行 V2Fly。包含 VLESS、REALITY、XTLS Vision 參數的節點通常偏向 Xray；傳統 VMess、WebSocket、TLS 組合一般能在兩條核心路線中找到較成熟的實作，但仍須核對欄位與版本。

判斷順序：先看節點參數，再看用戶端名稱

節點出現 REALITY、shortId、spiderX 或 XTLS Vision 流控參數時，優先使用 Xray；只有 VMess、WebSocket、TLS 等一般欄位時，再依現有用戶端與設定相容性選擇。

V2Fly 與 Xray 的版本關係

兩者都與早期 Project V 生態有關，但如今不應將 Xray 理解為 V2Fly 的「進階模式」，也不應把 V2Fly 當成 Xray 的舊版本。兩者各自擁有發布節奏、功能取捨與問題修復路線。設定格式仍有許多相似之處，是因為雙方承襲了相近的入站、出站、路由與傳輸層模型。

V2Fly 延續 V2Ray 的社群維護路線，重點之一是維持傳統設定模型的連續性，並推進 v5 設定體系。常見設定仍由 inbounds、outbounds、routing、dns 與 log 等部分組成。現有 VMess 部署、標準傳輸層組合，以及依賴 V2Fly 行為的環境，通常會優先考慮這條路線。

Xray 從相近的程式碼基礎獨立發展，版本號採用 1.x 系列，重點功能包括 VLESS、REALITY 與 XTLS Vision 等。它與 V2Fly 的部分 JSON 欄位看似相同，但不代表所有新增欄位都能互換。將 Xray 設定直接交給 V2Fly，常見結果是出現未知欄位、缺少協定實作，或無法辨識流控值。

版本號不能交叉比較

Xray 1.x 與 V2Fly v5 的數字不屬於同一發布序列，不能依數字大小判斷新舊。有效標準是目標協定是否已實作、設定欄位是否能被辨識，以及用戶端打包的核心版本是否符合節點要求。

協定支援與設定欄位有什麼差異

VMess 是兩條路線都可能遇到的傳統協定，但實際傳輸層、加密選項與相容行為仍會受版本影響。對於既有的 VMess + TCP 或 VMess + WebSocket + TLS 節點，遷移時應先保留原始位址、連接埠、UUID、Host、路徑與 TLS 網域，不要同時修改多個參數。

VLESS 本身將驗證與加密傳輸層分開設定。在實際用戶端環境中，VLESS 經常與 Xray 的 REALITY 或 XTLS Vision 一起出現。這類節點除了伺服器位址與 UUID，還可能要求 serverName、publicKey、shortId、spiderX、指紋以及 xtls-rprx-vision 流控值。缺少任何一項必填內容，都可能表現為握手失敗，或建立連線後沒有有效流量。

路由結構也容易造成「看起來一樣」的誤判。兩條核心都能依網域、IP、連接埠與入站標籤執行規則，但規則資料檔、欄位擴充與 DNS 行為可能隨版本變化。遷移 routing.rules 時，應逐項檢查 domain、ip、port、network 與 outboundTag，並確認引用的標籤確實存在。

v2rayN、v2rayNG 與 v2flyNG 怎麼選

Windows 桌面端通常優先使用 v2rayN，並讓用戶端管理 Xray 核心。它適合匯入訂閱、批次測試節點、設定系統代理、路由分流與檢查日誌。節點包含 REALITY 或 XTLS Vision 時，這種組合能減少設定轉換造成的不確定性。

在 v2rayN 中排查核心選擇時，可先開啟「設定」→「參數設定」，查看與核心、基本設定或啟動參數相關的項目；不同版本的標籤可能略有差異。接著回到主視窗重新啟動服務，並立即查看日誌。若日誌第一頁顯示 Xray 版本資訊，表示目前執行的是 Xray，而不是只根據程式目錄中的檔名猜測。

Android 端需要在 v2rayNG 與 v2flyNG 之間依核心路線選擇。v2rayNG 搭配 Xray 核心，適合包含 VLESS、REALITY 或 XTLS Vision 的訂閱；v2flyNG 搭配 V2Fly 核心，適合明確依賴 V2Fly 行為的節點與設定。兩者的介面操作相近，不代表底層協定擴充功能完全一致。

本機連接埠也要一併核對

• v2rayN 常見的本機 SOCKS 監聽連接埠為 10808，HTTP 連接埠可能使用相鄰的連接埠；最終數值以「設定」→「參數設定」中的本機監聽設定為準。
• 瀏覽器或其他程式手動設定代理時，代理類型必須與監聽類型一致。將 HTTP 請求送到 SOCKS 連接埠，會表現為連線遭拒或頁面持續等待。
• 更換核心後若連接埠尚未釋放，日誌可能出現 address already in use。先退出仍在執行的舊程序，再重新啟動用戶端。
• 啟用系統代理後仍無法存取時，先測試單一節點延遲，再檢查路由規則是否將目標網域送往 direct 出站。

透過日誌確認目前執行的核心

用戶端標題、訂閱名稱與節點備註都不能證明實際使用的核心。最可靠的入口是啟動日誌。停止服務後重新啟動一次，從第一行往下查看版本標識、設定載入路徑、監聽位址與錯誤資訊。不要只擷取最後一行「啟動失敗」，因為真正原因往往出現在前面。

正常啟動通常會經過產生設定、解析設定、監聽入站連接埠與執行服務幾個階段。若在解析階段停止，重點檢查 JSON 語法與欄位；若已監聽 127.0.0.1:10808，之後連線遠端失敗，則應轉向檢查位址、連接埠、TLS、SNI、REALITY 公鑰與路由規則。

啟動檢查順序
1. 讀取核心名稱與版本行
2. 確認設定檔已成功載入
3. 確認 127.0.0.1:10808 開始監聽
4. 發起一次節點測試或網頁請求
5. 從第一個 warning / error 往上回看上下文

1. 出現 unknown field：目前核心不認得設定欄位。先確認該欄位屬於哪條核心路線，再檢查用戶端是否產生了不相容的擴充參數。
2. 出現 failed to listen：本機連接埠已被佔用或監聽位址無效。關閉重複執行的用戶端，或將 SOCKS 連接埠從 10808 調整至未被佔用的連接埠。
3. 出現 invalid user：檢查 UUID、使用者標識與協定類型。VMess 與 VLESS 的連結不能只修改協定名稱後繼續使用。
4. 出現 handshake failed：核對系統時間、伺服器名稱、TLS 參數、REALITY 公鑰、短標識與用戶端指紋，不要先修改路由規則。
5. 啟動成功但沒有流量：檢查系統代理、DNS 與出站標籤。路由規則引用不存在的 outboundTag 時，可能導致特定請求無法依預期傳送。

常見選擇問題與操作解答

核心選擇並非一次決定。訂閱提供者調整節點協定、用戶端升級核心或伺服器端遷移設定後，都可能需要重新確認相容性。保留一個已驗證的節點，並記錄其使用的協定與傳輸參數，可以大幅縮短後續排查時間。