On Android, choose a core based on what your nodes require before comparing client settings. If your subscription includes VLESS, REALITY, or a specific XTLS Vision flow, start with v2rayNG, which uses Xray. If you already have VMess configs generated for a V2Fly setup, you can keep using v2flyNG. This guide shows how to check protocol fields, import subscriptions, and migrate routing rules—and why an imported node isn't necessarily a working connection.
Core vs. client: Understand their separate roles
Project V is the broader ecosystem behind related proxy technologies and tools, with V2Ray as one of its key projects. The V2Fly community continues to maintain v2ray-core, while Xray-core branched from this codebase in 2020 as a separate core project. They share configuration conventions, but their features, field handling, and release cycles have since evolved independently. They are not simply the same program under different names.
The core handles connection protocols, transports, security handshakes, DNS, and routing. The client manages subscriptions, node editing, service startup, and integration with the system network interface. On Android, v2rayNG uses Xray, while v2flyNG uses V2Fly. An option in the client interface doesn't mean every core version supports it; likewise, a core feature may not yet have a corresponding input field in the interface.
- Client version: Determines subscription parsing, editing options, and integration with the Android VPN service.
- Core version: Determines whether config fields are recognized and which handshake and transport implementations are used.
- Server configuration: Specifies the protocol, security method, transport parameters, and credentials the client needs.
- Subscription format: Determines whether those parameters can be passed to the client; it won't fill in missing server details automatically.
When troubleshooting, note the app version and core version separately. Check the app's About page first, then look for version details in the service startup log. If the page only shows the app version, don't assume that it identifies the core version. Desktop v2rayN also has separate client and core layers, so when comparing devices, check which core each node actually uses—not just the app names.
Protocol compatibility: Check VLESS, REALITY, and transport
The protocol name is only part of the picture. A node also specifies a transport, a security layer, and additional parameters—for example, VMess over WebSocket with TLS, or VLESS with REALITY and a specific flow. The client must understand all of these layers to connect successfully. Use the table below as a guide to choosing a core, not as a substitute for checking support in the specific version you're using.
| Configuration requirement | Xray / v2rayNG | V2Fly / v2flyNG | What to check |
|---|---|---|---|
| VMess + WebSocket + TLS | Typical support | Typical support | UUID, path, Host, SNI, and security settings |
| Basic VLESS connection | Typical support | Don't judge compatibility by the protocol name alone; check the core and client implementation | Whether the transport, security layer, and available fields match |
| VLESS + REALITY | Prefer this option, and check the core version | Not a drop-in replacement | serverName, public key parameters, shortId, and fingerprint settings |
| XTLS Vision | Set flow as required by the server | Copying the flow field won't provide equivalent support | Whether xtls-rprx-vision is explicitly required |
| Custom JSON config | Check against the Xray config specification | Check against the V2Fly config specification | Config format, field hierarchy, outbound tags, and resource files |
VLESS and REALITY aren't interchangeable terms: VLESS is a proxy protocol, while REALITY is a security mechanism used for the connection. Vision affects how specific traffic flows are handled. Switching the security method to TLS, removing flow, or clearing REALITY parameters doesn't create a "compatibility mode"—it changes the handshake requirements. If the server doesn't offer a matching endpoint, the connection still won't work.
Bottom line: Choose a core based on the full parameter set
If a node requires REALITY or xtls-rprx-vision, start with v2rayNG and confirm that your core version supports the combination. For shared features such as VMess, compare subscription parsing and local settings; there's no need to migrate just for a different name.
Choosing an Android client: When to use each option
For most new setups, start with v2rayNG. Its Xray core aligns with common VLESS and REALITY configurations, so there's less parameter conversion when you use subscriptions with these protocols. This recommendation is about compatibility, not a promise of faster speeds on every network. Latency and throughput also depend on server load, your ISP's routing, transport, and device performance—not just the core's name.
v2rayNG: Xray core
RecommendedUse it for subscriptions with VLESS, REALITY, or Vision requirements. After importing, check the transport, security settings, and flow; don't infer the protocol from the node name.
Best for: everyday use on Android and nodes that explicitly require Xray features
v2flyNG: V2Fly core
Use it with an existing V2Fly setup when the connection is stable and the protocol parameters are supported. Keep your current config only if you can verify where it came from and what the server requires.
Best for: existing V2Fly configs and checking compatibility with shared protocols
If your VMess nodes work in v2flyNG and you don't need newer protocols, you can keep using it. If your subscription later adds a REALITY node, test that new config in v2rayNG without first removing the old app or routing rules. Both apps can store configs, but Android usually allows only one app to hold the active VPN connection. Stop the other app's connection before testing.
Subscription migration: A listed node isn't necessarily fully configured
A subscription link is a way to retrieve configs, not a guarantee of compatibility across cores. It may return individual node links, a collection of encoded links, or a proprietary config format. A parser might read the node name and server address but miss newer security parameters. That means you need to verify both that nodes appear in the list and that the core completes the handshake.
- Keep a copy of your existing config: Note the protocol, transport, security method, DNS, and per-app rules. Subscription URLs may contain access tokens, so don't include them in public screenshots or logs.
- Add a subscription group: In v2rayNG, open Subscription group settings, add an entry, enter the existing subscription URL, and save. Then return to the main screen and select Update subscription. Menu locations can vary by version; look for the feature with the same name.
- Open the node editor: Check the address, port, UUID, transport type, and security settings one by one. For WebSocket, check the path and Host; for TLS, check SNI; for REALITY, check the public-key parameters and shortId.
- Check flow: If the server explicitly requires Vision, make sure the client retains
xtls-rprx-vision. Don't clear this field just to dismiss a warning. - Start the service and check the logs: First make sure the config loads, then verify the handshake completes, and finally test websites and apps that should use the proxy. Change one field at a time to avoid confounding the results by changing DNS, routing, and protocol settings together.
Ports and authentication: Find errors by checking specific fields
The local proxy port, server listening port, and protocol authentication parameters belong to different layers. The examples below use two ports and one VMess parameter to illustrate the distinction. These ports are examples, not universal defaults; use the values specified by your client settings and server.
Suppose the local SOCKS endpoint is 127.0.0.1:10808. It's for apps on your device and must not be entered as the remote node's server port. Likewise, a server using port 443 isn't necessarily using TLS: the port is just where it listens; the config determines the security method. Apps using Android VPN mode usually don't need this SOCKS address entered individually.
VMess AEAD configs typically use alterId=0. Don't carry over a nonzero value from an old tutorial without checking; import an up-to-date config provided by the server. This value applies only to VMess and can't be added to VLESS as a "compatibility parameter."
- Unknown field or config parsing error: Check the config format and core version first; the issue occurs before network connectivity is tested.
- Connection refused or timed out: Check the server address, listening port, and network path first; don't assume the certificate is at fault.
- Certificate verification failed: Check the system clock, SNI, and certificate match. Keep certificate verification enabled.
- Connected, but some apps don't work: Check per-app proxy settings, DNS, and routing rules before changing authentication details.
Routing and multiple devices: What you can reuse
Both cores can route traffic based on domains, IP addresses, and other conditions, but rules with the same names don't guarantee that an entire config can be migrated as-is. Referenced outbound tags must exist, domain and IP data files must be available, and DNS resolution policies can affect which rules match. During migration, first use a minimal config to confirm the node connects, then restore your routing rules. This makes problems easier to isolate than importing every rule at once.
Migration plan: Match the node first, then restore local rules
Desktop: v2rayN
- Note the protocol, transport, and core used by the current node.
- Check what traffic is actually routed through the system proxy or TUN.
- Save custom DNS and routing settings separately.
Android: v2rayNG or v2flyNG
- After importing the same subscription, recheck the security and transport fields.
- Under Settings → Per-app proxy, check which apps are included.
- Test with minimal rules first, then restore domain and IP routing.
The same subscription can provide identical node details, but it won't sync system proxy settings, VPN permissions, per-app lists, or all local routing rules automatically.
Per-app proxy settings need special attention: selecting "proxy only selected apps" and "bypass selected apps" does exactly the opposite. If the new client is connected but your browser isn't following the expected route, first check the list mode and whether the browser is selected, then check domain rules. Stop the old client's VPN service during testing so you don't mistake its active connection for the new core's behavior.
Bottom line: No need to switch cores just for the name if you don't need a new protocol
Keep your existing setup if your V2Fly config is stable; switch to v2rayNG if you need REALITY or Vision. A successful migration means the parameters are complete, the handshake succeeds, and the target apps and routes behave as expected—not merely that nodes appear in the subscription list.