Xray Core vs. V2Fly Core: Protocol Support and Configuration Differences

First, distinguish the client, core, and Project V

The core establishes connections, handles protocols, resolves DNS, and applies routing. The client puts those capabilities behind an interface. v2rayN, v2rayNG, and v2flyNG are client names; Xray-core and the v2ray-core maintained by V2Fly are cores. Client and core versions are separate: updating the client interface does not necessarily switch you to a different core.

Project V is an ecosystem of tools and protocols built around V2Ray. The V2Fly community continues development of v2ray-core. Xray-core branched from related code in 2020 and has since followed a different feature roadmap. Their shared history explains why their JSON configs look similar, but it does not mean every field is interchangeable.

This chain also explains why a subscription can import successfully but fail to connect: a successful import only means the client understood some of the data. It does not prove that the core supports every feature or that the server address, authentication details, and transport parameters match.

• v2rayN: A desktop client. Available cores and switching options depend on the installed version. When troubleshooting, check which core the active node actually uses.
• v2rayNG: An Android client. This guide covers setups that use its Xray core.
• v2flyNG: An Android client that uses the V2Fly core. A similar interface does not mean you can configure it with Xray-specific fields.

Protocol support: VLESS is not REALITY

A connection usually combines a proxy protocol, a transport, and a security layer. VLESS and VMess are proxy protocols; TCP and WebSocket are transports; TLS and REALITY relate to connection security. XTLS Vision is a specific flow-control and data-handling scheme, not just a different name for a “TLS” toggle.

Claims like “V2Fly doesn’t support any VLESS” and “any VLESS setup can connect with REALITY” are both too broad. The first ignores differences between versions and implementations; the second confuses a protocol with a security layer. Legacy XTLS flow-control values are not interchangeable with Vision—especially in new configs.

Config checklist: what to check in two common setups

These two cards are field checklists, not working nodes, and contain no server credentials. The example path /proxy illustrates where a field goes; use the path specified by your server. The REALITY card shows a common VLESS + TCP + Vision setup—it does not mean every VLESS connection needs Vision.

Host and SNI are often the same, but they serve different purposes. The WebSocket Host is the target host in the HTTP request; SNI is the server name sent during the TLS handshake. The connection address is a separate field that determines where the network connection starts. If the server requires different values, don’t set them all to the same value just to make them look consistent.

JSON configs: similar structure doesn’t mean configs are interchangeable

Common Xray and V2Fly configs both include names like inbounds, outbounds, and routing. V2Fly also has different config versions and structures. A client may parse a share link first, then generate its own core JSON. So an identical share link, similar interface fields, and compatible final core configs are three separate things.

This snippet shows the streamSettings field in a traditional JSON config, and only illustrates how WebSocket and TLS fit together. example.com is a reserved example domain, not a usable server address. The snippet lacks complete inbound, outbound, and authentication settings, so it cannot run on its own.

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com"
    },
    "wsSettings": {
      "path": "/proxy",
      "headers": {
        "Host": "example.com"
      }
    }
  }
}

• Transport field: network selects the transport implementation. Names such as TCP and RAW have changed across versions; don’t infer the underlying JSON value from the label shown in the interface.
• Security field: Standard TLS uses the corresponding TLS config. Xray REALITY has its own config structure; changing the tls string to reality is not enough to migrate a setup.
• Flow field: In common Xray VLESS outbound configs, flow is a user-level setting and should not be placed inside streamSettings.
• Version-specific fields: REALITY client public-key parameters may have different names in the docs and interfaces for different Xray versions. Check legacy publicKey examples against the password field used in newer docs and the actual core version. Don’t blindly substitute one for the other without knowing the version.

The safest way to migrate is to reimport the complete subscription provided by your service, then check the generated config. Manually copying an entire JSON file is only appropriate when you know its source version, target version, and config format. Even if it passes syntax checks, verify that the fields are actually being applied.

Ports and routing: don’t confuse the local entry point with remote capabilities

The core handles routing, but traffic has to reach it first. The system proxy affects only apps that follow that setting; TUN takes over relevant traffic through a virtual network interface and usually requires additional permissions. Neither selects a proxy outbound by itself—once requests enter the core, routing rules still determine where they go.

These numbers are address and port examples, not benchmark results or universal client defaults. If an app is set to 127.0.0.1:10808, confirm that the client is listening on that local port and that the entry protocol matches what the app expects. You can’t tell whether an entry is HTTP proxy or SOCKS from the port number alone.

1. In v2rayN, check local listening and related options under Settings → Parameter Settings. Group names may vary by version, so use the options shown in your current interface.
2. Make sure the system proxy or app proxy points to the address that is actually listening, not a port used by an old client.
3. Check the active routing mode and the rule that matches. geosite:cn references a domain category; geoip:cn references an IP category. Both depend on the corresponding data files.
4. After switching cores, check that rule-file locations, tag names, and outbound tags still match. Don’t just copy the routing rules.

“Direct connections work, but proxied sites fail” often means requests are hitting a rule while the proxy outbound still has a problem. If switching clients makes no difference to any app, check the entry point and traffic capture method first. Trace the connection path instead of blaming core speed.

Choosing an Android client: test against your subscription requirements

If your current nodes explicitly require Xray REALITY or Vision, v2rayNG with support for those features is the more direct choice. If your service provides configs verified with V2Fly, you can keep using v2flyNG. Without those specific requirements, prioritize whether the config imports completely, logs are easy to inspect, and existing routing rules can be preserved.

1. Record your setup: Note the client version, core version, protocol, transport, security layer, and whether TUN is enabled. “Latest version” alone isn’t enough.
2. Keep your old config: Back up subscription groups and custom routing rules before migrating. Don’t post sensitive subscription URLs in public discussions.
3. Import just one test entry: Compare its port, SNI, path, Flow, and REALITY fields with the original parameters. If a key field is missing, stop and investigate before testing.
4. Avoid running both clients at once: Stop the current client’s proxy or virtual network connection before testing another one to reduce conflicts at the entry point.
5. Change one thing at a time: Keep the network, server, and test request the same when comparing results. Don’t change DNS, the node, and the routing mode all at once.

FAQ: successful imports, failed handshakes, and update order