For nodes using REALITY or xtls-rprx-vision, choose an Xray core that supports those features. For standard VMess, WebSocket, and TLS configurations, check each field rather than assuming compatibility from the protocol name alone. This guide is for users switching cores, migrating subscriptions, or troubleshooting failed connections after import. It explains how clients relate to their cores and which settings to preserve during migration.
1. Xray and V2Fly: Shared origins do not mean interchangeable configurations
Project V is an ecosystem built around proxy tools, protocols, and configuration capabilities, with V2Ray as one of its major implementations. The V2Fly community continues to maintain V2Ray, while Xray branched from the V2Ray codebase in 2020 and has developed independently since. The two still share similar structures for inbounds, outbounds, routing, and DNS, but they are not simply two names for the same program.
The core handles the actual connection: receiving local requests, selecting an outbound, establishing transport, and completing protocol exchanges. The client provides the interface, manages subscriptions, generates settings, and controls the process. An option appearing in the client does not mean the active core can use it; likewise, a core may support a field that the client does not yet expose in its graphical interface.
Check compatibility at every step in this chain. If a share link imports, that only confirms the client recognizes its format. If a configuration file loads, that only confirms its syntax and some fields passed validation. The connection path is working only when a connection is established, authentication succeeds, and the destination site responds.
2. What do XTLS Vision and REALITY do?
XTLS Vision is an Xray flow-control feature, commonly specified with the value xtls-rprx-vision. It optimizes how TLS traffic is handled within proxy connections, reducing unnecessary repeated processing when the protocol, transport, and security-layer combination meets its requirements. It is not a standalone proxy protocol that works with just a server address, nor is it a switch that speeds up any node.
REALITY is a security-layer option provided by Xray. It uses a TLS handshake mechanism along with specific authentication parameters. Its configuration and verification differ from standard TLS: clients generally need a server name, public-key material supplied by the server, a short ID, and other details. Common REALITY deployments do not require users to configure their own domain certificate for the proxy entry as they would with standard TLS, but they still depend on correct destination, handshake, and authentication settings.
| Feature | Layer | What to check | Migration to V2Fly |
|---|---|---|---|
| XTLS Vision | Flow control | flow matches the server requirements | Do not copy Xray Vision settings as-is |
| REALITY | Transport security layer | Server name, public-key material, short ID, fingerprint | Xray REALITY settings cannot be used directly |
| Standard TLS | Transport security layer | Certificate, server name, and trust chain | Both support related features; configuration formats still need checking |
| WebSocket | Transport method | Path, Host, and reverse-proxy settings | Common combinations may be migrated; verify each field |
Bottom line: match the server setup before choosing a core
If the server specifically requires VLESS, REALITY, and Vision, use an Xray client that supports this combination. Do not try to make it work with V2Fly by removing flow or switching to standard TLS.
Vision and REALITY can be used together in one node, but they are not interchangeable; Vision can also be used with supported standard TLS combinations. Other XTLS flow names found in older guides cannot be substituted directly for Vision. Check the protocol, flow control, transport, and security layer as a complete combination. The supported options also depend on the core versions at both ends.
3. Configuration comparison: the same interface label does not guarantee the same JSON
The cards below show what to check for two common combinations; they are not ready-to-connect nodes. Get the server address, user ID, and authentication material from the actual server configuration. The /ws path shown in the cards works only if the server and reverse proxy use the same path.
VLESS + REALITY + Vision
- Protocol
- VLESS
- Transport
- TCP, labeled RAW in some interfaces
- Security layer
- REALITY
- Flow
xtls-rprx-vision- Authentication parameters
- User ID, public-key material, short ID
Use the information provided by the server, and confirm that the current Xray core and client support this combination.
VMess + WebSocket + TLS
- Protocol
- VMess
- Transport
- WebSocket
- Security layer
- TLS
- Example path
/ws- Authentication parameters
- User ID and encryption settings matching the server
Check the path, Host, and TLS server name. WebSocket does not automatically provide relay capability.
In common Xray configurations, streamSettings.security selects the transport security layer, while flow belongs to the relevant user configuration. They are not interchangeable. The TLS server name and WebSocket Host are often set to the same domain, but one is involved in the TLS handshake and certificate verification, while the other is part of the HTTP request. Check them separately when troubleshooting.
- Structural compatibility: Similar names such as
inbounds,outbounds, androutingdo not mean every field inside them is identical. - Protocol compatibility: Even commonly supported protocols such as VMess, Trojan, and Shadowsocks depend on the specific encryption method, transport combination, and version. Do not compare protocol names alone.
- Version compatibility: V2Fly configuration formats and Xray fields have each changed over time. Field locations or names in older guides should not be treated as fixed interfaces in current versions.
- Resource compatibility: Routing rules using
geosite:orgeoip:also require the relevant data files and correct loading paths.
4. How v2rayN, v2rayNG, and v2flyNG relate to their cores
v2rayNG is an Android client that uses the Xray core, while v2flyNG is an Android client that uses the V2Fly core. Their names and some interface elements are similar, but a node importing successfully in one client does not mean it will run in the other. For nodes using REALITY and Vision in particular, check core capabilities first, then make sure the import process preserved all the required parameters.
v2rayN is a desktop client, and its interface should be considered separately from the core program it actually runs. When troubleshooting, refer to the active configuration, startup logs, and the core being called rather than assuming every node runs through the same core based on the client name. Menu labels may change between desktop versions, so record both the client and core when documenting settings.
- Identify the client: Record the client name from its About or version information page; do not rely only on the installer filename.
- Identify the core: Check the core name and version in the startup logs. If startup fails, check configuration parsing errors first.
- Check node details: Verify the protocol, transport, security layer, server name, and flow one by one; do not rely on the node label alone.
- Check the application entry point: On Android, confirm VPN permission and per-app settings. On desktop, check the local proxy address and port used by the application.
5. Migrate subscriptions and custom configurations: verify each layer
A subscription is a way to distribute configuration, not a universal core configuration standard. The same subscription may be parsed differently by different clients, with different field mappings and default values. Seeing a name, address, and port does not confirm that REALITY parameters, flow control, or routing rules were preserved. During migration, keep the working configuration in the original client, then test a single node separately in the target client.
These ports belong to different connection stages. The remote entry can use another port, and the local listener can also be changed; they do not need to match. Pointing a browser proxy at remote port 443 or changing the server port to local port 10808 will not fix an incompatible core.
- Save a baseline: Record one working node and save its original protocol, transport, security layer, and routing settings. Keep sensitive authentication details on your own device.
- Test a minimal connection first: Temporarily leave out complex routing and confirm that the target client can connect to a single node. Do not change DNS, routing, and protocol at the same time.
- Check imported fields: If the source node uses Vision, confirm that flow remains
xtls-rprx-vision. For REALITY, check the server name, short ID, and public-key material. - Restore routing: Migrate routing rules one by one. Check that each
outboundTagmatches a defined outbound and confirm the rule order. - Check update behavior: Refresh the subscription once and confirm whether custom changes are overwritten. For ongoing changes, use a persistent configuration option provided by the client.
Do not replace the server name with an arbitrary popular domain, and do not generate REALITY public-key material in the client as a substitute. These settings depend on the server configuration. If a subscription is missing fields, ask the configuration provider for the complete parameters rather than repeatedly switching cores to compensate.
6. Troubleshooting errors: from parsing and listeners to the remote handshake
The most effective troubleshooting sequence starts by identifying the layer where the failure occurs. If the configuration has not parsed successfully, speed tests and DNS changes are pointless. If the core starts normally but the connection times out, a timeout alone does not prove that a protocol is unsupported. The error snippets below indicate common causes; exact log wording varies by version and operating system.
| Symptom or log snippet | Check first | Next step |
|---|---|---|
unknown field or configuration load failure | Configuration format and core support | Confirm which core is running; check field nesting and version requirements |
address already in use | Local listener conflict | Stop duplicate processes, or change the listening port and update the application settings |
connection refused | Destination address and port in the log | First determine whether the local proxy or remote entry refused the connection |
i/o timeout | Connection path and reachability | Check the server address, port, firewall, and network status |
| TLS or REALITY handshake failure | Security-layer parameters and system time | Check the server name, authentication material, fingerprint, and settings at both ends |
Bottom line: change one configuration layer at a time
First get the core running, then confirm the local proxy works, verify the remote handshake, and finally restore routing. Keep the relevant logs at each step to distinguish core compatibility issues from network problems.
Temporarily increasing log verbosity can help with diagnosis, but restore the usual level afterward. Before sharing logs, remove server addresses, user IDs, subscription URLs, and authentication material. Do not treat disabling certificate verification as a long-term fix for standard TLS; correct the root cause if the certificate chain, server name, or system time is wrong.
7. Choosing a core: common questions
My existing nodes work. Do I need to switch everything to Xray?
No need to migrate just because the names differ. If the current V2Fly configuration meets your protocol and routing needs, you can keep using it. Choose a suitable core when you need Xray features such as REALITY or Vision, and confirm that the server uses a matching configuration.
Can I connect with V2Fly by changing REALITY to TLS?
Changing only the client field is not enough. The two security layers use different authentication methods and server configurations. A separate connection is possible only if the server also provides a standard TLS entry and the corresponding certificate name, port, protocol, and transport parameters.
Is Xray always faster than V2Fly?
There is no such guarantee. Link quality, server load, transport combination, device performance, and the destination site all affect speed. For a meaningful comparison, keep the node, network, destination file, and test period consistent, then compare latency, throughput, and stability. One speed test cannot establish a general advantage for either core.
Should I switch clients first or change the configuration?
First check whether the current core supports the required features. Changing the port will not make a core that lacks REALITY support work; if the core supports it but the handshake fails, check the parameters first. For details on configuration fields, see the configuration field guide before deciding whether to migrate.