What Each Client Does
v2rayN is a desktop client for managing servers, subscriptions, system proxy settings, and routing through a GUI, with support for configuring multiple cores. Menus may differ between platforms and releases; if your interface does not match a guide, first check which desktop release you are using. Available cores also depend on what is included in your installation, so do not assume every platform has the same options based on a screenshot.
v2rayNG is for Android and uses the Xray core to route traffic through the system VPN interface. v2flyNG uses the V2Fly core and may suit configurations that require its capabilities. The names are similar, but these are separate apps, not different skins of the same app, and they do not share all settings. When migrating a subscription, check protocol compatibility, routing mode, app-specific routing, and system permissions. Matching node names alone does not mean the migration is complete.
Open-Source Licenses and Service Providers Are Separate
All three clients are open source under the GPL-3.0 license; their cores and other dependencies follow their own project licenses. Open source means the code and license terms are available for review, with conditions for using, modifying, and distributing the software. It does not mean the client projects provide remote subscription services, nor does it establish whether a subscription source is trustworthy. Whether a client is free to download and whether a remote service charges a fee are separate questions.
Subscription URLs may contain credentials for retrieving your personal settings, and node configurations may include authentication details. Treat them as sensitive information and store backups only in trusted locations. Before sharing logs or screenshots, check for exposed subscription URLs, server credentials, and QR codes. For support, share the error type, steps taken, and a redacted configuration structure rather than the full original configuration.
Client, Subscription & Routing Data Updates
Updating a subscription usually refreshes node settings from the provider; it does not upgrade the client. Updating the client may change its interface, core, or configuration generation, but it will not necessarily restore a remote node. GeoIP data, routing rules, and DNS settings are separate items to maintain. When something breaks, identify which layer changed before taking action. Repeated updates will not help if they do not address the actual cause.
Before upgrading, back up your subscription source, custom routing rules, and essential settings. After the upgrade, test the basic connection that worked before, then check app routing, local network access, and TUN behavior one at a time. If a new setting is unrecognized, check client and core compatibility. Do not delete security-related fields just to dismiss a warning, or overwrite a different core's configuration with an older one without checking it.
From a Basic Connection to Reading Configurations
Once importing and connecting work reliably, read the generated configuration in this order: inbound, outbound, then routing. Inbound describes how the client receives local requests; outbound describes how it connects to a destination or upstream; routing links them through tags. The direct-connection rule shown in the homepage panel only works when the corresponding outbound and classification data exist. Copying the snippet alone does not create a complete configuration.
To learn more, use the glossary to distinguish protocols, transport, cores, and routing, then check supported platforms in the client comparison. For a systematic guide to setup and maintenance, read the user guide. For a specific connection issue, work through the Help Center by symptom. Keeping one known-good configuration is more useful than repeatedly switching unrelated settings.