Xray 核心與 V2Fly 核心差異比較：功能差異與用戶端選擇建議

兩條核心分支從何處開始出現差異

V2Fly 與 Xray 都源自 V2Ray 技術體系，基礎結構相近：設定中通常包含入站、出站、路由、DNS、日誌與策略模組。兩者都能處理常見代理協定，也都能依據網域、IP、連接埠或規則集選擇出站。差異不在於「能否啟動代理」，而在於後續加入的協定擴充、傳輸實作、設定欄位與維護方向。

V2Fly 由社群持續維護 V2Ray Core，並逐步推進 v5 設定與 API。它適合依賴 VMess、VLESS、Trojan、Shadowsocks、WebSocket、gRPC 等常見組合的環境。Xray 則在相容既有設定的基礎上，持續發展 VLESS、XTLS Vision、REALITY 與相關流量控制能力。節點設定一旦出現這些專屬欄位，核心選擇就不再只是偏好問題，而是能否解析並建立連線的問題。

維護現況也會影響問題定位。看到錯誤時，應先記錄用戶端版本、核心版本、協定、傳輸方式與安全層，而不是只寫「V2Ray 連線失敗」。例如，測試環境固定使用 Xray-core 25.6.8 與 V2Ray 5.30.0 時，所得結果只對該組合有效；升級後若設定解析規則改變，就需要重新測試，不能直接套用舊版本結論。

• 共同基礎：入站與出站模型、路由比對、DNS 處理、日誌層級等概念相近。
• Xray 方向：優先支援 REALITY、XTLS Vision 等 Xray 體系功能。
• V2Fly 方向：延續 V2Ray Core 的社群維護，並發展自身的 v5 設定體系。
• 遷移原則：先辨識專屬欄位，再驗證協定與傳輸，最後比較效能。

VLESS、REALITY 與 XTLS 的支援範圍

VLESS 本身不能作為唯一判斷依據。兩條核心都有使用 VLESS 的情境，但具體設定可能附帶不同的流量控制、安全層與傳輸參數。一個只包含位址、連接埠、使用者識別碼、TCP 與 TLS 的 VLESS 節點，和一個同時包含 REALITY 公開金鑰、短識別碼、伺服器名稱、指紋及 Vision 流量控制的節點，實際依賴完全不同。

REALITY 屬於 Xray 體系。分享連結中常見的相關參數包括 security、pbk、sid、sni、fp 與 flow。若節點要求 security=reality，用戶端就需要使用支援該能力的 Xray 核心。將這類連結交給無法辨識對應欄位的核心，可能出現匯入欄位遺失、啟動時顯示未知設定，或建立連線後立即中斷等情況。

XTLS 也需要區分歷史名稱與目前的流量控制設定。現在的設定中更常見的是 VLESS 搭配 flow=xtls-rprx-vision。這不是把 TLS 開關換個名稱，而是涉及 Xray 的資料路徑與流量控制實作。伺服器端要求 Vision 時，用戶端應保持相同的 flow；刪除該欄位通常不會自動降級為一般 TLS，反而會造成雙方參數不一致。

設定檔能否直接互換

基礎 JSON 結構相似，不代表完整設定可以不經修改直接互換。常見的 inbound、outbound、routing 與 dns 模組，容易讓人產生「換個執行檔就能執行」的錯覺，但核心會分別驗證協定欄位、傳輸層欄位與物件階層。無法辨識專屬欄位時，輕則被用戶端匯入器忽略，重則導致核心啟動失敗。

以下是一段用於辨識 Xray REALITY 節點的精簡結構。它不是可直接連線的完整設定，但能展示最關鍵的判斷點：security 為 reality，flow 為 xtls-rprx-vision，且在 realitySettings 中出現 publicKey 與 shortId。

{
  "protocol": "vless",
  "settings": {
    "vnext": [{
      "address": "example.invalid",
      "port": 443,
      "users": [{
        "id": "00000000-0000-0000-0000-000000000000",
        "encryption": "none",
        "flow": "xtls-rprx-vision"
      }]
    }]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "serverName": "server.example",
      "fingerprint": "chrome",
      "publicKey": "範例公開金鑰文字",
      "shortId": "0123456789abcdef"
    }
  }
}

遷移訂閱時，還要區分「訂閱內容」與「核心設定」。訂閱通常先由用戶端解析分享連結，再轉換成核心需要的 JSON。即使兩個用戶端收到同一條連結，產生的結果也可能因預設指紋、Mux 開關、DNS 策略與路由規則不同而改變。因此，匯入成功只代表用戶端辨識了文字，不代表核心一定支援其中的所有欄位。

1. 先複製原始設定並記錄目前的核心版本，不要直接覆蓋唯一可用的設定。
2. 在節點詳細資訊中檢查協定、傳輸、安全層、flow、SNI、ALPN 與指紋。
3. 切換核心後先啟動單一節點，觀察核心日誌是否出現 unknown field、failed to parse 或 handshake 類錯誤。
4. 確認本機監聽連接埠，例如 SOCKS 連接埠 10808，沒有被其他程序佔用。
5. 依序測試 DNS 解析、TCP 頁面存取與持續傳輸，不要只看一次延遲數值。

效能差異應如何測試

同一個節點在兩條核心上的延遲相差幾毫秒，通常不足以證明某個核心更快。網路路徑、伺服器負載、DNS 快取、連線重用與測試時間都會改變結果。更可靠的做法是固定節點、設定、網路與測試目標，交替執行多輪，再比較中位數、失敗次數與持續傳輸穩定性。

可重現的桌面測試可以這樣設定：本機 SOCKS 連接埠固定為 10808，連線逾時設為 2 秒，關閉會改變路徑的額外鏈式代理；每個核心執行 50 輪短連線，再完成 3 輪、每輪 5 分鐘的持續傳輸。測試期間不要同時更新訂閱或執行測速工作，否則核心日誌與頻寬競爭會干擾結果。

• 建立連線：記錄 50 輪中的成功次數與中位耗時，不採用單次最低值。
• 持續傳輸：觀察 5 分鐘期間是否重新連線、停頓或出現握手錯誤。
• 資源使用量：在相同連線數下記錄記憶體與處理器使用量，至少等待 60 秒後再讀取。
• 日誌結果：分開統計協定錯誤、DNS 錯誤、逾時與連接埠佔用。

在一般 VMess + WebSocket + TLS 節點上，兩條核心往往都能達到接近的實際吞吐量，此時用戶端操作習慣與設定穩定性比些微數值差異更重要。對於 REALITY 或 Vision 節點，測試前提已限定為 Xray；使用不支援對應欄位的核心參與速度比較沒有意義，因為連線能力本身就不等價。

如何選擇 v2rayN、v2rayNG 與 v2flyNG

用戶端名稱和核心名稱不是同一個概念。用戶端負責訂閱、介面、路由入口、系統代理與設定產生；核心負責實際解析設定並轉送流量。選擇時應先看平台，再看節點所需能力，最後確認用戶端是否提供對應的設定入口。

v2rayN 適合 Windows 桌面環境，方便管理分組、查看核心日誌與切換路由。需要確認目前設定時，可開啟「設定」→「參數設定」，檢查核心類型、本機監聽連接埠與 DNS 相關選項。不同版本的選單文字可能略有差異，但核心日誌仍是判斷實際執行元件的直接依據。

v2rayNG 使用 Xray 核心，適合 Android 上的 REALITY、XTLS Vision 以及常見的 VMess、VLESS、Trojan 節點。匯入後可進入節點詳細資訊，核對傳輸層、安全類型、SNI、指紋與 flow。若訂閱更新後突然無法連線，應比較更新前後的欄位，而不是先刪除所有設定。

v2flyNG 使用 V2Fly 核心，適合希望維持 V2Fly 設定鏈路的 Android 使用者。它更適合既有 VMess、標準 TLS、WebSocket、gRPC 等組合。若伺服器端明確要求 REALITY 或 Vision，就不應透過刪除欄位強行匯入，而應改用支援該設定的 Xray 用戶端。

常見選擇問題與排查步驟

核心不相容通常有相當明確的訊號：匯入後關鍵欄位為空、核心無法啟動、日誌提示未知欄位、握手階段反覆失敗，或一般節點可用但 REALITY 節點全部失敗。排查時應先確認核心是否確實啟動，再查看節點參數，最後處理系統代理與路由。

最終選擇可濃縮為三個步驟：先看設定是否包含 REALITY 或 Vision，再確認用戶端實際使用的核心，最後透過日誌與多輪連線測試驗證。一般節點不必在兩條核心間頻繁遷移；專屬協定則應嚴格匹配實作。這樣處理比根據一次延遲、節點名稱或用戶端名稱判斷更可靠。