A focused hub for v2rayN and v2rayNG downloads, subscription import steps, and routing rule configuration. Choose a client for your device, then select the Xray or V2Fly core required by the node protocol instead of conflating the client, core, and subscription service.
The platform determines the package type, while the node protocol determines the core capabilities. Choose your device first, then check whether the subscription requires Xray or V2Fly; the download page explains architecture, chip, and installer format choices.
Built for desktop users who need full system proxy support, subscription groups, routing rules, and log-based troubleshooting. The download page offers both a modern cross-platform interface and the classic WPF interface; start with the desktop version on most newer devices, or keep the familiar interface if you already have an established workflow.
Go to DownloadsThe desktop client follows v2rayN configuration logic for managing subscriptions, outbounds, and routing rules. Check your device’s chip architecture before downloading: choose the arm64 package for Apple Silicon and the x64 package for Intel. Confirm the architecture in system information rather than guessing from the purchase year.
Go to Downloadsv2rayNG uses the Xray core and suits subscriptions requiring Xray capabilities such as VLESS and REALITY, making it a straightforward choice for many mobile devices. Prefer an arm64 package on newer devices; if the processor architecture is unclear or broader compatibility is needed, choose the universal package on the download page.
Go to DownloadsFor desktop Linux users who want to manage subscriptions, system proxy settings, and routing rules through a graphical interface. Match the installer to the distribution’s package system: Debian and Ubuntu generally use deb, while Fedora and Rocky Linux typically use rpm. Also choose the correct x64 or arm64 architecture.
Go to DownloadsA V2Ray client does more than connect to nodes. Subscriptions, cores, DNS, and routing jointly determine the result; the panels below explain each area separately and show configuration snippets that are easy to interpret.
Routing rules send different traffic to different outbounds: domains that need a proxy use the proxy outbound, local networks and specified address ranges use direct, and categories that should not be accessed go to the block outbound. Rules are checked from top to bottom and matching stops at the first hit, so specific rules generally belong first and broad fallback rules later. Unlike a simple tool with only a global switch, V2Ray rule objects can combine domains, addresses, ports, network types, and inbound tags, making usage scenarios easier to maintain as a clear rule set.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}After changing rules, first check that the tags match the outbound names in outbounds, then review the actual matches in the client log.
A subscription URL points to an updatable node list, while a vmess:// or vless:// share link usually describes a single node. After importing a subscription, update it first, then choose a node from the relevant group; importing a share link directly does not create a continuously updated subscription source. Keeping different sources in separate groups makes it easier to identify which URL failed and prevents duplicate names from being mixed together. Preserve the existing group before updating, then run latency or connectivity tests after a successful update for a clearer troubleshooting path.
Subscription Groups
├─ Work Configuration
│ ├─ Manual Update
│ └─ Automatic Update
└─ Temporary Share
└─ Single-Node ImportSubscription content is generated by the service provider. The client reads, updates, and displays it; it does not automatically turn a single-node link into a remote subscription.
v2rayN is a desktop graphical client that can manage multiple node types with the cores it supports; v2rayNG uses the Xray core, while v2flyNG follows the V2Fly core line. When choosing, do not start by comparing interface details. Check the node’s protocol, transport, and security parameters first. For capabilities such as REALITY, choose the corresponding core; for standard configurations supported by V2Fly, the V2Fly route may also be appropriate. The client is only the configuration entry point—the core interprets protocol fields and establishes the connection.
Selection Order
1. Check the node protocol and security parameters
2. Confirm the core’s supported capabilities
3. Choose the matching graphical client
4. Check the logs after importingEvaluate the core and client separately. Similar client names do not mean they use the same core maintenance path.
When a connection reports success but webpages will not open, DNS is one of the areas to check. Routing rules may match domains directly, or resolve them to addresses after no domain rule matches before continuing; settings such as domainStrategy help control this process. Conflicts among DNS servers, query paths, and routing policies can produce successful resolution with an unexpected outbound choice, or repeated resolution failures in the log. Start troubleshooting with a minimal configuration to confirm basic connectivity, then restore custom DNS and complex rules one at a time.
{
"dns": {
"servers": [
"localhost"
]
},
"routing": {
"domainStrategy": "IPIfNonMatch"
}
}DNS settings should not be judged separately from the system’s network environment. Check the system clock, basic connectivity, and node status first, then inspect the resolution strategy.
Do not change many advanced options at once during initial setup. Import the subscription and establish a basic connection first, then add routing and DNS rules as needed; this makes each change easier to correlate with a specific result.
View the Full Guide →Copy the complete subscription URL, add it as a source in the client’s subscription group, and run an update. For a single vmess:// or vless:// link, use an entry such as “Import from Clipboard.” After importing, confirm that the list shows node names, protocols, and addresses. If it is empty, first check that the copied content is complete, the subscription is still accessible, and the update produced no error message.
Choose a node from the subscription group, then enable the system proxy or the appropriate connection mode provided by the client. For an initial test, use a simple rule set so custom blocks, complex DNS, and multi-level outbounds do not affect the result at the same time. Node availability and network conditions change, so latency is only a reference; the real test is whether the target connection succeeds and whether the log shows handshake, resolution, or routing errors.
Once basic connectivity works, test common websites, direct addresses, and targets requiring a specific outbound to confirm that proxy and direct paths behave as expected. Then add rules such as direct access for private addresses or proxying for specific domains, changing only one group of settings at a time and keeping a restorable configuration. When something fails, check in this order: node, DNS, routing, and system proxy. This is usually more effective than repeatedly reinstalling the client.
Understanding the ecosystem layers matters more than memorizing a single client name. A configuration works only when the graphical client, core, protocol fields, and subscription content fit together correctly.
V2Fly continues Project V’s community-maintained path, interpreting configuration, implementing protocols, and handling underlying inbound, outbound, DNS, and routing capabilities. Objects such as inbounds, outbounds, routing, and dns in configuration files belong to the core layer, not to any particular graphical client interface.
Xray developed an independent maintenance path from a related ecosystem foundation and extended capabilities such as VLESS and REALITY. If subscription nodes contain specific extension fields, they must be interpreted by a core that supports those fields. Choose Xray because its protocol and configuration capabilities match the nodes—not because all client names represent the same implementation.
Project V originally brought together protocol implementations, configuration structures, and proxy capabilities. As desktop and mobile needs grew, the community created graphical clients for different systems. Graphical clients manage subscriptions, node selection, system proxies, logs, and configuration editing; the core establishes connections, applies routing, and handles protocol details. With these layers separated, interfaces can evolve around platform conventions while underlying capabilities continue along their own maintenance paths.
Therefore, “V2Ray client” is usually an ecosystem term rather than a single installer. v2rayN targets desktop systems, while v2rayNG and v2flyNG target Android; their interfaces, core paths, and use cases are not identical. Before downloading, identify the device platform and then check the node protocol to avoid import failures caused by the wrong architecture or core.
Project V-related cores and clients are maintained as open-source projects, with code released under the licenses each project declares. Open-source licenses specify the conditions for copying, modifying, distributing, and retaining license notices. For everyday users, the key point is that feature changes can be reviewed through release records, documentation, and community discussions. Developers extending or redistributing the software should read the applicable license text first.
Open source does not mean every client is released by the same team on the same schedule. v2rayN, v2rayNG, and v2flyNG each maintain their own interface adaptations and release processes, while the underlying cores follow independent change cycles. When configurations differ, confirm the client name, core family, and protocol parameters before reading the documentation for that combination.
v2rayN is the main graphical client for desktop systems, covering Windows, macOS, and Linux. It is suited to managing multiple subscriptions, editing routes, switching the system proxy, and viewing runtime logs. v2rayNG is a commonly used Xray-based client on Android for nodes that require Xray protocol extensions. v2flyNG uses the V2Fly core and serves as a mobile option for the V2Fly path.
All three focus on similar node configuration and subscription workflows, but their capabilities cannot be assumed identical from their names alone. Some fields depend on core support, while some operations depend on system permissions and the graphical implementation. The safest selection order is: device platform, node protocol, processor architecture, then client interface.
Updates generally occur at three levels. A client update changes the interface, system support, and configuration management; a core update changes protocol implementation, routing behavior, and low-level compatibility; a subscription update returns a new node list from the subscription source. These updates are independent: a failed subscription refresh does not mean the client must be reinstalled, and a client interface update does not automatically change node configurations.
When troubleshooting update issues, record the current configuration and check the logs first. For subscription failures, focus on the URL and network path; for protocol errors, check core support; when the system proxy has no effect, check the client mode and system settings. Classifying the problem at the right layer is usually more effective than replacing every configuration at once.
These questions cover the parts most likely to cause confusion during first use. The complete workflow and troubleshooting order are provided on the guide page.
First confirm that you imported the complete subscription URL rather than truncated text. Then manually update the relevant subscription group and review the update message or log. If the URL is accessible but the list remains empty, check whether the response uses a subscription format supported by the client. Do not rush to delete all configuration; keeping the group makes it easier to determine whether the issue comes from the URL, network path, or parsing process. View the subscription import steps →
A share link usually represents one node and includes its address, port, identifier, and transport parameters; a subscription URL returns an updatable node list. Share links suit single-node imports, while subscriptions are designed to maintain multiple nodes over time. Their entry points may differ in the client, and a single-node link should not be entered into the subscription update field with the expectation that it will generate a remote list automatically. View import methods →
Check in this order: node, DNS, routing, and system proxy. Start by switching to a node known to work, then check for domain resolution errors. Next, temporarily switch to simple routing to rule out an incorrect block; finally, confirm that system proxy mode is enabled. Change only one setting at a time and watch the logs so you can identify the failing layer. View the connection verification workflow →
Start with the protocol requirements of the subscription nodes. Choose v2rayNG with the Xray core when Xray extensions are required. If the configuration falls within V2Fly’s supported range and you want to follow the V2Fly core path, choose v2flyNG. Similar interfaces do not guarantee identical underlying capabilities, so check the protocol, security parameters, and transport before importing. View the client selection guide →
These articles cover client relationships, subscription updates, core differences, and connection failures, prioritizing diagnostic order, setting paths, and reusable checks.
A connected status only means the client has completed part of the process. This article breaks down failure points in the order of node, DNS, routing, and system proxy, explaining what to observe at each step and how to narrow the scope with minimal changes.
Read the Full Article →Covers the subscription URL, current network, update path, and automatic update settings, distinguishing an inaccessible URL, an invalid response, and a client that never ran the update instead of blaming every error on a failed node.
Read the Full Article →Explains the structural difference between single-node share links and updatable subscription lists, with separate import paths, update methods, and common mistakes for v2rayN and v2rayNG.
Read the Full Article →