V2Ray grew out of Project V’s modular approach to network proxying. It separates inbound connections, outbound connections, routing, and transports so requests can be sent to different destinations according to rules. Searches for V2Ray today often turn up V2Fly, Xray, v2rayN, and v2rayNG. These names refer to different parts of the ecosystem, not simply different names for the same installer. Understanding what each one does helps narrow down where to look when something goes wrong.
For everyday use, the graphical client is the main control panel. A subscription supplies connection configurations; the core reads them and establishes connections; the system proxy or VPN interface determines which app requests reach the client; routing decides where those requests go. These four parts are connected, but none replaces another: a successful subscription update doesn’t mean the connection works, and a working connection doesn’t mean every app is using the proxy. Testing in this order is more effective than repeatedly importing subscriptions or reinstalling the app.
Project background
Understand configuration through modular design
Project V’s approach isn’t to squeeze every network function into one switch. Instead, it separates tasks into modules that can work together. Inbound connections accept requests from apps; outbound connections reach destinations or proxy servers; routing chooses where requests go; and the transport layer defines how connections are carried. This division explains why clients have separate settings for subscriptions, routing, DNS, and listening ports. The interface may have many options, but each one has a specific scope.
For example, the local listening port changes where apps connect to the client, while the remote server port changes where the client connects to the server. Both are ports, but they aren’t interchangeable. Similarly, global routing affects how requests are handled after they enter the core; it won’t make an app that ignores the system proxy start using the proxy. Once you understand these boundaries, you can establish a connection with basic settings, then add split routing and traffic capture as needed.
When looking up technical information, check which client, core, and settings layer it applies to. An article about a core configuration file doesn’t mean every field can be pasted unchanged into a graphical client. Identify the concepts first, then compare them with your current interface to avoid mixing instructions for different projects.
Explore technical terms →
Core projects
V2Fly and Xray develop independently
The V2Fly community continues to maintain V2Ray-related implementations, while Xray developed from related code into an independently evolving core project. They share technical roots but make their own implementation choices and release features at different paces. For users, the important question isn’t which name ranks higher; it’s whether the core currently running supports the protocols, transports, and security options your server requires.
Depending on the version and configuration, v2rayN can use the corresponding core. On Android, v2rayNG primarily uses the Xray core, while v2flyNG offers the V2Fly core. Switching cores isn’t a universal fix. If the problem is an expired subscription link, an incorrect system clock, or a local port conflict, changing cores will likely produce the same symptoms. Check which stage the logs point to before deciding whether to switch implementations.
Use the server’s parameters as the basis for compatibility checks. Don’t disable certificate verification just to clear an error, or delete every unrecognized field and keep going. Preserve the original configuration, check that the client and core are compatible, and consult the relevant terminology and troubleshooting guides if you’re unsure what a parameter means.
Diagnose by symptom →
Open-source licensing
Three clients and their licenses
v2rayN, v2rayNG, and v2flyNG are open-source graphical clients and are free to use. Open source means the project code and its licenses are available for review; it doesn’t mean the client provides remote servers, subscription plans, or connection configurations. To connect, you still need a subscription you’re authorized to use or a server configuration you manage yourself.
Not every component in an open-source ecosystem uses the same license. The v2rayN project is licensed under GPL-3.0, as are v2rayNG and v2flyNG. The V2Fly and Xray core projects use MPL-2.0. Other components included in a distribution may have their own license terms. The obligations for everyday use differ from those for modifying or redistributing software; before doing either, read the full licenses for the projects and components involved.
Configuration management and network services are separate concerns, too. A client can store and parse a subscription, but it can’t determine whether that subscription is valid or maintain the server for you. When a connection fails, first identify whether the cause is the app settings, configuration content, or remote server status, then choose the appropriate fix. This preserves your existing settings and helps you describe the issue clearly to whoever provided the configuration.
Compare the three clients →
Updates and verification
Update the app, core, and subscription separately
App updates can change the interface and configuration management; core updates can affect protocol capabilities and parameter support; subscription updates primarily refresh connection configurations. These updates do different things, so avoid applying all of them at once while troubleshooting. If a connection that used to work has failed, note what changed first, then test one component at a time to see whether an update caused the problem.
Before upgrading, save your subscription groups and custom routing rules, and confirm the installer matches your operating system and processor architecture. After upgrading, test a basic connection with a configuration that already worked, then check the system proxy and the apps you need. Test extras such as TUN and per-app proxy only after the basic connection is confirmed. If only a new feature fails, return to the verified mode and check the logs for permission or compatibility issues.
Logs can help pinpoint where a connection failed, but may include server addresses, subscription links, or other sensitive parameters. When sharing a report, include only the necessary error details and hide credentials. Also mention your device platform, operating mode, and affected apps. Clear reproduction steps are more useful than an unredacted screenshot of the entire configuration, and help prevent access credentials from being exposed.
View frequently asked questions →
For your first setup, keep the verification steps simple: import a subscription, choose a configuration, confirm the core starts, then enable the system proxy or mobile VPN mode and test the app you need. Add routing rules, per-app lists, or TUN only after the basic connection works. Each step can be undone on its own, making it easier to identify where to look if a problem comes up.
If your browser works but other apps fail, check how those apps connect to the proxy before updating all your servers. If every configuration times out, check your local network and core status. If a subscription update returns an empty list, check the link format and request method. These symptoms point to different parts of the setup. Follow the steps in Troubleshooting, or review the basics in Quick Start.