Check the server requirements before choosing a core. VLESS, transport, TLS or REALITY, and flow are separate configuration layers; a protocol name alone does not determine compatibility. This guide is for users switching cores in v2rayN or choosing v2rayNG or v2flyNG on Android. It covers which fields to verify, how to switch, and what to troubleshoot if the connection fails.
Two core branches, and how they relate to clients
The V2Fly community maintains the V2Ray core, while Xray-core is a separate development branch that split from the V2Ray project. They share a configuration history, but their protocol implementations, transport capabilities, and configuration fields have evolved separately. Xray is not a V2Fly interface, and renaming a program does not guarantee that the same JSON config will work.
Clients handle subscriptions, server lists, system proxy settings, and config generation. Cores handle connections, protocol processing, and routing. v2rayN is a desktop client, and the cores it can use depend on the installer, client version, and its ability to generate the required configs. On Android, v2rayNG uses the Xray core and v2flyNG uses the V2Fly core; they are separate apps, not two skins for one app.
- Client support: Can you enter the required transport, security, and flow-control settings when editing a server?
- Core support: Can the program actually launched parse the config and implement the required features?
- Server compatibility: Does the server use the same protocol combination, credentials, and handshake parameters?
All three layers must line up. A successful import only means the client recognized the shared link; seeing a server in the list does not mean the core has connected. When something fails, first check whether fields were lost during import, then whether the config failed to parse at startup, and finally whether the remote handshake failed.
What are VLESS, XTLS, and REALITY?
VLESS is a proxy protocol. XTLS Vision is a flow-control feature in the Xray ecosystem, commonly configured with the value xtls-rprx-vision. REALITY is a separate connection security mechanism. All three can appear in the same server config, but they are not interchangeable “protocol buttons.” VLESS does not provide transport encryption on its own, so the name VLESS is not proof that TLS is enabled.
| Feature | Xray core | V2Fly core | What to check |
|---|---|---|---|
| VMess | Supported | Supported | Credentials, security settings, and transport must still match |
| VLESS base protocol | Supported | Implemented; details depend on the version and config format in use | Base protocol support does not guarantee support for Xray-specific extensions |
| XTLS Vision | Supports the corresponding VLESS flow-control mode | Cannot use an Xray Vision config as-is | flow must match the server requirements |
| REALITY | Supported | Cannot run an Xray REALITY config as-is | Security type, server name, public key parameters, and short ID |
| WebSocket + TLS | Supports common combinations | Supports common combinations | Path, Host, server name, and certificate verification |
So “V2Fly does not support VLESS at all” is too broad; “VLESS support means it can connect to any VLESS server” is just as misleading. For links that use REALITY or Vision, check Xray’s capabilities and the client’s supported features. Don’t draw conclusions from the vless:// prefix alone.
Bottom line: check security and flow before choosing a core
If the server explicitly requires REALITY or xtls-rprx-vision, use an Xray client setup that can generate the required config. For standard VMess or common TLS transports, compare your existing config and maintenance needs.
Choose a core based on server requirements
The recommendation below has a specific use case: connecting to servers that use REALITY or Vision. It is not a speed ranking, nor does switching the same connection to Xray guarantee lower latency. Connection quality, server load, transport settings, and your local network all affect performance. Without consistent test conditions, performance percentages are meaningless.
Xray core
RecommendedWhen a server requires VLESS + REALITY or Vision, stick with an Xray-based config workflow. On desktop, make sure Xray core is available in v2rayN. On Android, use v2rayNG and check that the key settings survived import.
Best for: Servers that explicitly require REALITY or Vision, or configs that already work with Xray.
V2Fly core
You can keep using V2Fly for existing V2Fly configs, VMess, or common WebSocket + TLS servers. Verify the actual config before migrating; there’s no need to rebuild every server and routing rule just because the core names differ.
Best for: Existing configs that rely on V2Fly, when the server does not require Xray-specific features.
Older references to “XTLS” may mean an earlier config format, not Vision. If your provider only says “VLESS supported,” ask for the transport type, security type, and flow-control value. Without those details, don’t guess at the server config by repeatedly switching cores.
Config compatibility: check each item on this list
A share link is a way to pass settings between clients, not a complete core config. After importing a subscription, the client converts its parameters into its own data and generates a runtime config for the core. A field can be lost at any step, resulting in a link that imports but won’t start, or a core that starts but can’t connect.
| What to check | Common fields | What to do |
|---|---|---|
| Server address and port | address、port | Use the values provided by the server; 443 is common, not mandatory |
| User identity and flow control | id、flow | Verify credentials; for Vision, use the flow value required by the server |
| Transport layer | streamSettings.network | Generate the config using the transport name supported by the core version in use; don’t blindly copy settings from another branch |
| Connection security | streamSettings.security | Distinguish tls from reality; they are not interchangeable |
| Server name | serverName | Match a name allowed by the server; it may differ from the address you connect to |
| REALITY settings | Public key parameters and shortId inside realitySettings | Use field names supported by the current client and core, and verify values against your provider’s documentation |
| WebSocket request | wsSettings.path、headers.Host | Keep the path and request headers; copying only the domain and port is not enough |
Custom JSON configs require extra care. Even if both cores have inbounds, outbounds, and routing, their fields, defaults, and rule data dependencies may differ. Back up the original file, then test whether the target core can parse it. Valid JSON syntax does not automatically make a valid core config.
Switching cores in v2rayN and choosing an Android app
Menu locations may vary between v2rayN versions. A common path is Settings → Parameter Settings → Core Type Settings. Check the core mapping for each protocol rather than assuming every server will switch together. If you can’t find this option, first check which core types your installer supports. Don’t change VLESS to VMess in the server’s protocol dropdown.
- Keep a fallback config. Back up your servers and subscription details, and note which servers currently work, the core name, and local listening ports. Don’t change routing, DNS, and security settings all at once during your first test.
- Check that the program can run. Make sure the target core is installed and matches your operating system and CPU architecture. Program files for Windows, macOS, and Linux are not interchangeable.
- Update the protocol mapping. In Core Type Settings, check which core is assigned to the target protocol. Save and restart the core. For custom configs, also check the core type specified by the config.
- Check the startup log. Confirm which core actually launched and check its version. First make sure there are no config parsing errors, then investigate the remote connection. This helps avoid mistaking a startup failure for an unavailable server.
- Test the proxy and app separately. If the local SOCKS port is set to 10808, point your test tool to that port. Don’t assume the HTTP port is 10809; check your local settings.
Setup guide: check the desktop mapping, choose an Android app by core
Desktop: v2rayN
- In Parameter Settings, check which core is mapped to each protocol.
- Save the config, restart the core, and check the log to confirm which program is running.
- Keep your existing DNS, routing, and local listening settings while switching.
Android：v2rayNG / v2flyNG
- Choose v2rayNG when you need Xray features.
- If you’re keeping a V2Fly config, check what v2flyNG actually supports.
- Import the same subscription, check the fields, and verify system VPN permission.
The subscription URL can be the same, but the generated configs and available servers may differ. Test an actual connection on both clients.
Can’t connect after switching? Troubleshoot by failure stage
Troubleshoot in this order: config parsing → local listener → server connection → handshake and authentication → routing and DNS. Don’t move on to the next step until the previous one works. Note the relevant error fields and outbound tag. Before asking for help, remove subscription URLs, credentials, and sensitive server details.
Getting an unknown field error after switching? Is the server broken?
This usually happens during config parsing, before the client connects to the server. Check the log to confirm which core is running, then see whether the field in the error belongs to the other core branch. Save the server again in the client to generate a compatible config instead of copying custom JSON that may not work.
Why does the same VLESS link fail with V2Fly?
Open the server editor and check whether REALITY is enabled or the flow is set to xtls-rprx-vision. If either is required, switch back to an Xray core that supports that combination. Don’t remove security settings just to get the core to start.
The core starts, but the log keeps reporting handshake failures. What should I do?
Check the server address, port, credentials, server name, REALITY public key parameters, and short ID one by one. Also make sure the device clock is correct. For WebSocket + TLS, check the path and Host as well. Change one category of settings at a time, save, and test again.
The log says address already in use. Do I still need to switch cores?
Check the local listening port first. For example, if it is set to 10808, close any other process using that port, or change the local listening port in Parameter Settings and update your app’s proxy settings. This is a port conflict, not a protocol difference between Xray and V2Fly.
The real test is whether the target core can parse the config, start listening, complete the server handshake, and route traffic from your apps as expected. If only your browser fails but the proxy connection test works, check system proxy and browser settings. If only some domains fail, check DNS and routing rules. Don’t blame every problem on choosing the wrong core.