For desktop, start with v2rayN. On Android, choose between Xray-based v2rayNG and V2Fly-based v2flyNG according to your configuration requirements. This guide explains the differences between client apps, core engines, and node configurations; what subscription settings can be shared; how system proxy settings work with routing rules; and what to check when setting up or migrating between devices.
Platform support: choose separately for desktop and Android
The names are similar, but these are not three aliases for the same installer. v2rayN is a desktop client for Windows, macOS, and Linux; check your CPU architecture and package type before installing. v2rayNG and v2flyNG are for Android, and differ mainly in their core engines and supported configuration features. Desktop installers won't run on Android, and Android packages can't replace a desktop client.
| Feature | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platform | Windows, macOS, and Linux desktop | Android | Android |
| Core engine | Multiple cores supported; the core used depends on the configuration and settings | Based on Xray-core | Based on V2Fly-core |
| Configuration management | Subscription groups, node lists, and routing settings | Subscription and node management, plus mobile connection settings | Subscription and node management, plus mobile connection settings |
| Common connection methods | System proxy or per-app proxy; TUN support depends on the platform and configuration | Routes device traffic through Android's VPN interface | Routes device traffic through Android's VPN interface |
| What to prioritize | Desktop platform, CPU architecture, and required core engine | Android device with a configuration that requires Xray features | Android device with a configuration targeting V2Fly |
The “VPN interface” here is Android's mechanism for routing device traffic; it doesn't mean the node uses a particular VPN protocol. Once traffic enters the client, the core handles it according to the node configuration and routing rules. Also, an app being installable doesn't mean every configuration will work: check the Android version, CPU architecture, and supported core features separately.
Default core: check the bundled engine on Android and the active engine on desktop
The client app handles subscription imports, node editing, starting and stopping services, and displaying logs. The core engine handles protocols, transport connections, and routing. v2rayNG uses Xray-core, while v2flyNG uses V2Fly-core. There's no single fixed “default core” for v2rayN: the configuration type and client settings can affect which engine actually runs. Check the local core settings and startup logs.
v2rayN: desktop configuration management
Useful for managing multiple subscriptions, adjusting routing, and checking core logs on a computer. When switching cores, check both the protocol fields and the selected core; changing a name alone isn't enough.
Best for: managing subscriptions and traffic routing on Windows, macOS, or Linux desktops.
v2rayNG: Xray configurations on Android
RecommendedIf your Android configuration specifically requires Xray, VLESS, and REALITY, start by checking its fields against this client. This recommendation applies to those requirements; it doesn't mean every node should be migrated.
Best for: everyday Android use, especially with nodes that rely on specific Xray features.
v2flyNG: V2Fly configurations on Android
Consider v2flyNG if you already have a verified V2Fly configuration or need behavior consistent with that core. Support for VMess alone doesn't guarantee support for every combination of extensions.
Best for: Android setups where V2Fly compatibility or an existing deployment is the priority.
How to choose: check the configuration requirements before choosing a core
Ask the configuration provider which protocol, transport, and TLS or REALITY parameters are required. Then choose a client that can represent all those fields. If an import fails, don't rely on repeatedly switching cores and hoping for the best.
VMess and VLESS are protocols; WebSocket is a transport; TLS and REALITY are connection security settings. They're different layers, not interchangeable options. Both cores handle some common configurations, but that doesn't mean their full feature sets are identical. In particular, don't use V2Fly-core for a REALITY configuration. A standard VMess node won't become faster just because you use a different client.
Subscription management: reuse the URL, but don't expect settings to sync
A subscription is a URL for fetching a node list, not a complete backup of your account settings. All three clients support subscription management, but the returned content must be in a format the client can parse. A successful update only confirms that the request and parsing completed. Verify node authentication, server status, and network reachability separately using the connection status and logs.
- Check the subscription format first.Ask the provider for a subscription URL compatible with your target client. Don't paste a web dashboard URL into the subscription field or assume any configuration file will work as a universal node subscription.
- Create a separate subscription group.In v2rayN, go to “Subscription groups” → “Subscription group settings,” enter a name and URL, save, and update that group. Menu labels may vary by version.
- Import it separately on Android.In v2rayNG or v2flyNG, open subscription management, add an entry, and update it. Then select a node and connect. Importing a single share link from the clipboard is different from adding a subscription.
- Check your selection after updating.Make sure the current node is still listed and that its address, port, and transport parameters are intact. Don't assume an update will preserve the original node order or manual edits.
You can update the same subscription URL on both devices, but simultaneous use depends on the service terms. The lists may differ temporarily if the devices update at different times. Desktop routing rules, Android per-app lists, system proxy switches, and local listening ports usually aren't copied with the node subscription. Keep a separate record of node sources and device-specific settings when migrating.
Traffic capture and routing: ports, system proxy, and routing each do a different job
On desktop, the system proxy tells apps that honor the setting to send requests to a local proxy port. It doesn't capture traffic from every app; programs that ignore the system proxy may still connect directly. Routing rules then determine whether traffic entering the core goes through the proxy, connects directly, or gets blocked. On Android, traffic routed through the VPN interface also needs routing rules to determine its destination.
These ports illustrate how the settings correspond; they aren't defaults for every version. Enter 127.0.0.1:10808 or 127.0.0.1:10809 in an app only if the client has the corresponding inbound enabled. If your configuration uses a single mixed inbound port, use that port instead; there's no need to create two listeners. In v2rayN, check the local listener options under “Settings” → “Parameter settings,” and refer to the current interface and logs.
- Desktop browsers:First check that the system proxy points to an address the client is listening on, then check the routing rules. A node's latency result alone isn't enough.
- Android per-app routing:Check that the target app is included in the traffic capture scope, then check the proxy mode and rules. Excluded apps won't follow the expected routing path.
- Global proxy:This usually means captured traffic follows the selected proxy mode; it doesn't mean every desktop app that bypasses the system proxy can be forced through it.
- Bypass mainland China:This depends on matching against the active rules and data files, not on a webpage's language. DNS results and rule order can affect the final route.
A local listening port is not a remote server port. The server port in a node is set by the server configuration; don't change it to match the local port. On another device, 127.0.0.1 refers to that device itself, so it can't be used to connect to the desktop client. If you need to share a proxy over your local network, assess the listening address, authentication, and firewall restrictions separately.
Using desktop and Android together: share the source, verify each device separately
When using a computer and an Android device, there's usually no need to make every setting identical. A safer approach is to use the same authorized subscription source and configure traffic capture to suit each operating system. On desktop, focus on the system proxy and app compatibility. On Android, check VPN permission, per-app scope, and background restrictions.
Setup plan: one subscription source, two independent configurations
Desktop: v2rayN
- Choose a package for Windows, macOS, or Linux and your CPU architecture.
- After importing the subscription, check the selected node and the core that's actually running.
- Confirm the listening port, then enable the system proxy or configure an app proxy.
- Record the routing mode and any custom rules you need.
Android: choose based on the core
- For Xray configurations, check v2rayNG first; for V2Fly configurations, check v2flyNG.
- Add the subscription separately and grant Android VPN permission.
- Check per-app settings and background permissions one by one.
- Test the connection on both Wi-Fi and mobile data.
Sharing a subscription avoids entering nodes twice, but it doesn't replace checking permissions, routing, and connectivity on each device.
Before switching clients, save your subscription source and custom rules, then stop the old client's connection service. On Android, avoid running two services that require the VPN interface at the same time; starting one can disconnect the other. Test the new client with a known-good node first, then restore per-app settings and complex routing. This makes it easier to identify which layer is causing a problem.
Common client questions: importing, connecting, and switching
Why can my computer use the subscription, but Android can't import it?
First distinguish a download failure from a parsing failure. For a download failure, check the network, whether the URL has expired, and how the client updates subscriptions. For a parsing failure, ask the provider whether the returned format is supported by that client. Try importing a non-sensitive test configuration of the same type to check protocol support. Don't post the full subscription in a public forum.
If I switch from v2rayNG to v2flyNG, will my nodes work as-is?
Don't judge by the node name alone. Check the protocol, transport, and security parameters; a configuration that relies on Xray features isn't necessarily compatible with V2Fly. Even if you can import a share link, check that no fields were lost, then connect and review the logs. Routing and per-app lists need to be configured separately.
The node shows as available, but webpages won't load. Should I switch clients?
Not yet. On desktop, check that the system proxy points to the active listening port and look for port conflicts. On Android, confirm the VPN indicator, app capture scope, and service status. Then check DNS, routing matches, and node connection logs. A successful connectivity test only confirms that one test path worked; it doesn't prove that every app's traffic follows the same path.
Which client is fastest? Does it depend only on Xray or V2Fly?
The core name alone isn't enough. For a fair comparison, keep the device, network, node, destination, routing mode, and test time consistent. Repeat each test and record failures. Server load, network congestion, and transport settings can all affect results. Without consistent test conditions, speed rankings of the three clients aren't meaningful.
Before installing: turn your choice into a practical checklist
You don't need to start by comparing feature counts. First rule out packages that don't match your operating system, then check that the core supports your node's requirements, and finally make sure you can configure subscriptions, traffic capture, and routing. If your current setup is stable, keep a record you can restore before migrating one part at a time. Don't change the client, core, nodes, and rules all at once.
- Check the device:Use v2rayN on desktop. On Android, choose v2rayNG or v2flyNG based on the required core.
- Check the configuration:Record the protocol, transport, security parameters, and subscription format—not just the node name.
- Check traffic capture:On desktop, verify the local listener and system proxy. On Android, check VPN permission and per-app scope.
- Check the route:Test one node with simple routing first, then enable the rules you need.
- Prepare troubleshooting details:Keep redacted error logs. For step-by-step troubleshooting, see Troubleshooting; for unfamiliar terms, see Glossary.