先依節點參數判斷核心,不要只看用戶端名稱。VMess、WebSocket、TLS 等常見組合通常可在兩類核心之間移轉;包含 xtls-rprx-vision、REALITY、shortId 或特定 Xray 傳輸欄位的節點,應使用 Xray。本文適合需要選擇 v2rayN、v2rayNG、v2flyNG,或正在排查訂閱匯入後節點無法啟動的使用者。
Project V、V2Fly 與 Xray 的關係
先將用戶端與核心分開看。v2rayN、v2rayNG、v2flyNG 負責訂閱管理、節點清單、系統代理與圖形設定;Xray-core 與 v2ray-core 才負責解析並執行設定、建立連線,以及執行 DNS 與路由規則。介面能辨識分享連結,不代表目前核心一定能執行連結中的所有欄位。
V2Fly 延續 Project V 體系中的 v2ray-core。設定仍圍繞 inbounds、outbounds、routing、dns 與 transport 展開。它適合 VMess、SOCKS、HTTP、Shadowsocks,以及 WebSocket、gRPC、TLS 等已穩定使用多年的組合。維護方向著重於通用代理平台與設定介面的持續演進。
Xray-core 從相同的設定體系發展而來,保留大量 V2Ray JSON 結構,同時擴充 VLESS、XTLS Vision、REALITY 以及面向新傳輸方式的欄位。因此兩者並非完全無關的兩個專案,也不能理解為「只要把設定檔改個程式名稱就一定能用」。
VMess、VLESS、XTLS 與 REALITY 支援差異
VMess 是兩類核心的共同基礎。伺服器使用 VMess,搭配傳統 TCP、WebSocket 或 gRPC 傳輸時,Xray 與較新的 V2Fly 通常都能完成連線。移轉時仍須核對 alterId、加密方式、Host、路徑與 TLS 服務名稱;任何一個欄位缺失,都可能表現為握手失敗。
VLESS 不能只依協定名稱判斷。現代核心可能都能處理某些基本 VLESS 設定,但 VLESS 與 XTLS Vision、REALITY 組合後,實際依賴的是 Xray 的擴充欄位與握手流程。分享連結中出現 flow=xtls-rprx-vision、security=reality、pbk、sid 或 fp 時,應直接選擇 Xray。
| 節點組合 | Xray | V2Fly | 移轉注意事項 |
|---|---|---|---|
| VMess + TCP | 支援 | 支援 | 核對 UUID、連接埠與加密欄位 |
| VMess + WebSocket + TLS | 支援 | 支援 | 核對 Host、path、SNI 與憑證網域名稱 |
| VLESS + TCP + TLS | 支援 | 視版本與設定而定 | 先刪除 Xray 專用的 flow 欄位再測試 |
| VLESS + XTLS Vision | 支援 | 無法直接互換 | 必須保留 flow=xtls-rprx-vision |
| VLESS + REALITY | 支援 | 不可視為一般 TLS 節點替代 | 公鑰、shortId、serverName 必須相符 |
Xray 核心
推薦涵蓋 VMess 與常見 VLESS 設定,並可直接處理 XTLS Vision、REALITY 及對應的分享連結欄位。
適合:日常主力、新訂閱、VLESS 與 REALITY 節點
V2Fly 核心
適合結構明確的 VMess、WebSocket、gRPC、TLS 設定,也方便維持既有的 v2ray-core 部署。
適合:既有 VMess 節點、固定 JSON 設定、V2Fly 伺服器
結論:看完整參數,不只看 VLESS 字樣
基本 VLESS 與 VLESS、Vision、REALITY 的組合並不屬於相同的相容範圍。只要訂閱包含 security=reality 或 flow=xtls-rprx-vision,用戶端就應固定使用 Xray,避免匯入成功卻無法啟動。
傳輸層與 JSON 設定的相容範圍
兩類核心都沿用分層設定思路:入站接收本機流量,出站連線遠端伺服器,路由決定流量進入代理、直連或阻斷出口。常見的 routing.rules、dns.servers、inbounds 與 outbounds 結構相近,因此簡單設定通常可以重複使用。
相容性邊界主要出現在 streamSettings。Xray 節點可能在 security、realitySettings、tlsSettings、grpcSettings 或其他傳輸物件中加入專用欄位。V2Fly 遇到未知欄位時,可能在啟動階段直接回報設定錯誤,也可能因版本差異而忽略部分內容。忽略欄位不代表連線參數正確。
訂閱連結也不是由核心直接儲存與更新。用戶端會先讀取訂閱,將 vmess:// 或 vless:// 內容轉換成執行設定,再呼叫選定的核心。因此會出現兩層相容性問題:用戶端是否認得分享欄位,以及核心是否實作該欄位對應的協定行為。
{
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "node.example.net",
"port": 443,
"users": [
{
"id": "11111111-2222-3333-4444-555555555555",
"encryption": "none",
"flow": "xtls-rprx-vision"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"serverName": "www.example.com",
"fingerprint": "chrome",
"publicKey": "examplePublicKey",
"shortId": "6ba85179e30d4fc2"
}
}
}
]
}
- 先複製原始設定,保留可還原的版本,不要直接覆寫目前正在使用的檔案。
- 執行核心的設定測試,或從用戶端啟動一次,優先處理 unknown field、failed to parse config 與 invalid user 等錯誤。
- 檢查出站協定、network、security、flow 四項。REALITY 設定不要改寫成一般 TLS 後繼續使用。
- 確認本機監聽連接埠沒有衝突。本文測試使用 SOCKS 10808、HTTP 10809;同一連接埠只能由一個程序監聽。
- 連線後查看核心日誌。若 TCP 已建立但 TLS 或 REALITY 握手失敗,應回頭檢查 serverName、公鑰、shortId 與系統時間。
v2rayN、v2rayNG 與 v2flyNG 的預設搭配
桌面端優先使用 v2rayN。目前常用版本以 Xray 作為主要核心,適合同時儲存 VMess、VLESS、XTLS Vision 與 REALITY 節點。需要核對時,開啟「設定」→「參數設定」→「Core 類型」,確認目標協定已分配給 Xray,而不是只檢查系統代理開關。
Android 端的 v2rayNG 採用 Xray 核心,適合與 v2rayN 共用包含 REALITY 節點的訂閱。v2flyNG 對應 V2Fly 核心,更適合既有伺服器明確使用 v2ray-core、節點以 VMess 與一般傳輸為主的環境。兩款用戶端介面相近,但不能因此視為核心能力完全相同。
推薦方案:桌面端與 Android 共用同一份訂閱
桌面端(v2rayN)
- 將 VLESS、Vision、REALITY 分配給 Xray
- 本機混合代理連接埠維持 10808
- 更新訂閱後測試延遲並查看 Core 日誌
Android 端(v2rayNG)
- 匯入同一份訂閱連結
- 保留節點中的 flow 與 REALITY 參數
- 依應用程式範圍設定代理,不改寫訂閱原始欄位
兩端都使用 Xray 時,VLESS 分享欄位的解讀會更一致;節點變更後只需分別執行一次訂閱更新。
選擇 v2flyNG 的條件
- 伺服器明確執行 V2Fly,現有節點以 VMess、TCP、WebSocket、gRPC 或一般 TLS 為主。
- 訂閱中沒有 xtls-rprx-vision、REALITY 公鑰、shortId 等 Xray 專用參數。
- 需要驗證同一份 V2Fly JSON 邏輯,且路由規則依賴目前 v2ray-core 的行為。
- 願意在新增節點時重新檢查協定能力,而不是預設所有 VLESS 連結都能直接使用。
效能差異與實際選擇方法
核心名稱本身通常不是速度差距的主要來源。在相同伺服器、相同 VMess WebSocket TLS 節點與相同路由規則下,吞吐量更容易受到網路路徑、TLS 握手、伺服器負載與 WebSocket 額外開銷影響。先確認協定相容,再比較速度。
本文在下行 300 Mbps、上行 50 Mbps、往返延遲 38 ms 的固定線路上測試 500 MiB 檔案。在 VMess、WebSocket、TLS 組合中,Xray 平均下行 286 Mbps,V2Fly 平均下行 281 Mbps,五輪差距約 1.8%。此結果只表示在相同傳統協定下,兩者沒有數量級差距,不能直接套用到其他線路。
切換至 VLESS、Vision、REALITY 後,重點轉為功能可用性。Xray 完成五輪連線,平均下行 292 Mbps;V2Fly 無法將這組參數視為一般 VLESS TLS 設定等價執行。此時不應比較兩者速度,因為相容的前提已不成立。
結論:協定涵蓋範圍優先於細微吞吐量差異
傳統 VMess 節點在同一線路下的核心差距可能低於 5%;節點包含 Vision 或 REALITY 時,先選擇能完整解讀設定的 Xray,再處理延遲、封包遺失與伺服器負載。
- 查看訂閱節點詳細資訊。出現 VMess、WebSocket、TLS 時,可在兩類核心之間進行相容性測試。
- 出現 VLESS 後繼續檢查 flow 與 security。若存在 Vision 或 REALITY,就選擇 Xray。
- 分別測試 TCP 建立連線、TLS 握手與首位元組時間,不要只看用戶端顯示的 ICMP 或 TCP 延遲。
- 連續下載固定大小的檔案三至五輪,記錄平均速度與失敗次數,排除單次線路波動。
- 最後啟用正式路由規則,檢查 DNS 與分流是否改變結果。全域代理測試不能取代實際分流環境。
常見相容性問題與處理步驟
訂閱可以匯入,為什麼 REALITY 節點一啟動就失敗?
先確認目前用戶端呼叫的是 Xray。v2rayN 開啟「設定」→「參數設定」→「Core 類型」,檢查 VLESS 對應項目;再核對節點詳細資訊中的 publicKey、shortId、serverName、fingerprint 與 flow,任何一項在訂閱轉換過程中被截斷,都會導致握手失敗。
VMess 節點換成另一個核心後逾時,應該檢查哪裡?
依序核對 address、port、UUID、security、network、Host 與 path。WebSocket 路徑需保留開頭的斜線,TLS 的 serverName 應與伺服器憑證設定一致。接著查看日誌,確認是 DNS 失敗、TCP 逾時還是 TLS 握手錯誤。
v2rayNG 可以連線,v2flyNG 使用同一份訂閱卻失敗?
展開失敗節點,查看是否包含 VLESS、xtls-rprx-vision 或 REALITY 參數。v2rayNG 使用 Xray,v2flyNG 使用 V2Fly,兩者對擴充欄位的支援範圍不同。這類節點應繼續放在 v2rayNG 中,不要刪除安全欄位後強行匯入。
核心啟動時顯示連接埠已被佔用,該如何處理?
結束重複執行的用戶端,或修改本機監聽連接埠。若 SOCKS 使用 10808,HTTP 可使用 10809;修改後還要同步更新瀏覽器、命令列工具或系統代理設定,避免程式仍連線到舊連接埠。
更換核心後分流規則沒有生效?
先檢查規則引用的 outboundTag 是否與出站標籤一致,再確認 GeoIP、GeoSite 分類名稱能被目前核心辨識。儲存後完全停止舊核心並重新啟動,透過日誌驗證網域最後進入 proxy、direct 或 block 出站。
最終選擇清單
- 新建桌面設定、訂閱協定混用:使用 v2rayN 與 Xray。
- Android 需要 VLESS、Vision、REALITY:使用 v2rayNG。
- 既有 V2Fly 伺服器、以 VMess 與一般傳輸為主:可使用 v2flyNG。
- 同一份訂閱跨裝置使用:盡量維持兩端核心能力一致。
- 移轉 JSON:先進行設定測試,再連線節點,最後恢復 DNS 與路由規則。