Choosing a core is primarily a configuration compatibility question, not a name or version-number comparison. This guide is for users checking core options in v2rayN or moving configurations between v2rayNG and v2flyNG. It covers project history, protocol fields, switching steps, and log troubleshooting, including where REALITY, Vision, subscription conversion, and local ports take effect.
Project Origins: A GUI Client Is Not a Proxy Core
V2Fly-core continues the V2Ray technology stack of Project V and is maintained by the V2Fly community. Xray-core forked from the V2Ray codebase and later developed its own independent release path. The projects share a common origin, but their features, configuration fields, and default behavior are not guaranteed to stay in sync. Calling Xray simply “the newer V2Ray” obscures the differences that matter when migrating.
A GUI client handles subscriptions, node editing, and settings; the core parses the runtime configuration, accepts local traffic, and makes proxy connections. A node appearing in the client does not mean the selected core can use all its options. Importing a subscription, generating a configuration, and starting the core are three separate steps that can each fail.
- v2rayN: A desktop GUI client. Available cores and selection options vary by client version, installed files, and node type. Check the interface and startup logs on your device.
- v2rayNG: An Android client that uses the Xray core. Replacing an executable on desktop is not an approach you can apply to Android.
- v2flyNG: An Android client that uses the V2Fly core. When migrating, recheck node parameters and the results of subscription parsing.
Versioning: Track Three Versions Separately
The client, Xray-core, and V2Fly-core each have their own release versions. A client update may change both configuration generation and core files, or it may only change the interface. Manually updating a core does not necessarily update the client's support for newer fields. When troubleshooting, record the actual combination instead of saying only that everything is “up to date.”
Historical references often mention V2Fly's v4 and v5 release lines, as well as Xray's 1.x releases and later date-based version identifiers. These are not directly comparable scales, so they do not indicate relative feature count or compatibility. In particular, distinguish V2Fly's software version from its configuration format: v5 does not automatically mean old configurations must be rewritten, and newer-format fields are not necessarily recognized by older tools.
- Record the full version shown on the client's About page, along with the operating system and processor architecture.
- Start a connection and note the core name, version, and startup result in the logs.
- Distinguish configurations generated from regular nodes from manually maintained custom configurations, which may bypass some interface conversions.
- Before upgrading, keep a copy of the original client settings and core combination. If problems arise, roll back the combination rather than replacing just one file.
Matching version numbers do not guarantee identical behavior across devices. Routing data files, DNS settings, and client-generated parameters may still differ. Subscriptions can also change between updates, so use the same node entry when reproducing a problem.
Protocols and Transports: Matching Names Don't Mean Matching Fields
VMess and VLESS are proxy protocols; TCP, WebSocket, and gRPC are transport options; TLS and REALITY concern connection security; Vision is a flow-control option that must match at both ends. These are not interchangeable “modes.” The combination required by the server determines which capabilities the client needs.
| Check | Xray-core | V2Fly-core and migration notes |
|---|---|---|
| VMess | Supported; authentication details and transport parameters must still match | Supported; sharing a protocol name does not mean the entire configuration can be copied as is |
| VLESS and extension fields | Check the flow-control and security settings required by the node | Check support against the specific version and configuration format; do not assume Xray-specific extension fields will work |
| REALITY and Vision | Key options for the relevant configuration; parameters must match at both ends | Do not migrate these as generally compatible options; obtain server settings that work with the target core |
| WebSocket、gRPC | Check support in the current version and the corresponding server settings | Check the path, service name, hostname, and TLS settings individually; comparing transport names alone is not enough |
| DNS, routing, and sniffing | Depend on the runtime configuration and supporting data | Fields, parsing behavior, and data formats may differ; validate them separately |
For example, if a VLESS node requires xtls-rprx-vision, deleting the flow field does not turn it into a standard VLESS node. REALITY server public keys, server names, and short IDs also serve distinct purposes. Switching cores alone cannot supply parameters that are missing or mismatched.
How to Decide: Check for Required Fields First
First check whether the node explicitly requires REALITY or Vision. Then confirm that the target core and client can represent all the required parameters. If a field is incompatible, ask the service provider for another working configuration rather than repeatedly deleting fields.
Choosing a Core: Start With Your Existing Nodes
“Newer protocols are always faster” is not a sound reason to switch. Network routes, server load, connection quality from your ISP, and routing rules all affect performance. Choose a core that meets the node's requirements first; only then compare stability, resource use, and features under equivalent conditions.
Xray Core
RecommendedIf a node explicitly uses REALITY, Vision, or another confirmed Xray-specific configuration, choose a client and core combination that can generate all the required fields. This recommendation applies to that configuration scenario; it does not imply better performance on every network.
Best for: Existing nodes with Xray-specific parameters that must connect as required by the server.
V2Fly Core
If you already have a verified V2Fly configuration, along with its DNS and routing rules, you can keep using the same setup. Before migrating, identify the specific problem the new setup is meant to solve. There's no need to switch just because another project's version number changed.
Best for: Maintaining existing V2Fly configurations and keeping rules and runtime behavior consistent.
If both cores can run the same server setup, keep the node, test window, and test target constant, then compare connection success rates and log errors. Do not draw conclusions about core performance from one-off speed tests through different exit nodes.
Switching Steps: Back Up First, Then Test a Basic Connection
In v2rayN, open Settings → Parameter Settings and note the options for local listeners, DNS, and routing. Group names and core selection options can change between versions. If your current interface does not offer the target core, do not follow an old guide to edit unfamiliar files, and do not mistake a subscription group name for a core selector.
- Keep the original setup. Back up the client configuration, custom rules, and any necessary node parameters. If the backup contains subscription URLs or authentication details, restrict access and do not upload it publicly.
- Confirm the target setup. Check the node's protocol, transport, security mode, and flow control. Make sure the client can generate fields accepted by the target core.
- Stop the current core. Use the client's stop or restart controls to prevent two cores from competing for the same local listening port.
- Change one variable at a time. Switch the core or the client first; do not also change DNS, nodes, or routing. After startup, check the configuration parsing and listener logs.
- Test a basic connection. Verify a proxy request with one node whose parameters are known to be complete. Then restore your usual routing rules and test subscription updates last.
Migration Guide: Test Desktop and Android Separately
Desktop: v2rayN
- Record the current core startup log and listening port.
- Use the core selection option actually available in your current version.
- After switching, confirm that the system proxy still points to the correct port.
Android: v2rayNG / v2flyNG
- Before migrating, check whether subscription entries contain fields unsupported by the target core.
- After importing, check the node editor rather than just the number of entries in the list.
- When connecting, confirm system VPN authorization and the per-app scope again.
Using the same subscription guarantees only the same input source; the resulting nodes, routing, and DNS behavior may still differ between clients.
Ports and Logs: Distinguish Local Startup From the Remote Handshake
The three numbers below illustrate port roles; they are not default values for every client. Use the values in your local settings and node parameters. Entering a local proxy port as a server port, or a remote port in the system proxy, can cause connection failures unrelated to core selection.
If you have confirmed in Settings that the HTTP proxy listens on 127.0.0.1:10809, use the command below to test an HTTPS request explicitly routed through that listener. The test URL is for connectivity checks only; its response does not by itself prove the exit location or that every app is being proxied.
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/unknown fieldappears: Check the configuration fields and target core version first; don't change the server address as a first step.address already in useappears: Check whether the old core or another program is using the listening port. Stop the duplicate process and try again.- The local listener starts, but the remote handshake fails: Check the server port, system time, TLS server name, and REALITY parameters, then review the full error message.
- The command works, but the browser doesn't: Check the system proxy, the browser's own proxy settings, and routing matches. Don't immediately assume the protocol is incompatible.
FAQ: Subscription Imports, Failed Switches, and Rollbacks
Why does the client exit as soon as I connect, even though the subscription imported?
A successful import only means the client parsed the subscription. Check startup logs for unrecognized fields, then open the node editor and verify the protocol, transport, and security options. Repeatedly updating the subscription is not a substitute for checking the configuration. If parsing fails, restore the original core or obtain a compatible configuration.
Can I change REALITY to TLS and run the node with V2Fly?
Changing one client option is not enough. The server must provide a corresponding TLS service and authentication settings. Ask the service provider for node parameters explicitly supported by the target core, then import them again. Removing public key or flow-control fields does not convert the configuration.
Why did routing change after I switched cores?
First check whether the current routing mode, DNS resolution policy, and rule data match your backup. Then review rule matches and outbound traffic in the logs. The system proxy only determines whether some apps send traffic to the client; it does not ensure that different cores use identical routing configurations.
How do I restore my connection if switching cores fails?
Stop the new core, restore the original client configuration and core combination, and make sure the local port is not in use. Then restart and set up the system proxy again. Test with the same node that worked before. If it still fails, check whether the subscription changed and whether the remote service is available.
Your final choice should answer three specific questions: Which fields does the node require? What configuration did the client generate? Which core did the runtime log confirm it launched? Once these match, consider updates and performance. If they don't, switching versions again will usually add more variables to troubleshoot. For further help, follow the connection, subscription, and routing steps in Troubleshooting.