A focused guide to client downloads for four platforms, subscription and routing setup, and V2Fly and Xray core details. Coverage runs from first installation through TUN mode, rule-based routing, and routine maintenance.
The client handles the graphical interface; the core handles protocols, transport, routing, and outbound processing.
Clients and cores are maintained by their respective projects, with public records of releases, fixes, and feature changes.
Start with a basic connection, then add routing rules and system-level proxy features layer by layer for your use case.
Read the advanced handbook →When starting out, you do not need to understand every protocol and parameter at once. A safer order is to identify the operating system and client, import a working configuration, complete a connection test, and only then adjust the system proxy, routing mode, and TUN settings. Each step produces a clear result, making it easier to identify which layer is causing a problem.
Start with the three parts most often confused in everyday client use. Each explanation maps to a real setting instead of replacing practical judgment with abstract performance scores.
A subscription URL manages the source of your configuration; it is not the same as the node currently in use. After importing it, run an update and check that the group contains recognizable server entries. When using multiple subscriptions, organize them by purpose or source so you can see exactly what changed after updating one.
Keep daily use simple: update subscriptions, review groups, select a node, and run a real connection test. Automatic updates suit stable subscriptions, but keep a manual update option available. If the list is empty after an update, check the URL, whether the returned format is supported by the client, and whether group filters are hiding entries before repeatedly switching the system proxy.
View the subscription import steps →Rule-based routing sits between connection settings and the system proxy. It does not change subscription content; instead, it selects an outbound action such as direct, proxy, or block based on the destination. When getting started, use the client’s built-in basic mode. Add custom rules only when you know a particular domain or network needs separate handling.
Rules are usually matched in order, so an earlier rule can override a broader condition later in the list. Before editing, record the current mode and change one set of conditions at a time. Domain rules suit fixed sites, IP rules suit defined networks, and rule sets make groups of entries easier to maintain. After editing, test both direct and proxied destinations so neither side is left unverified.
Read the routing chapter →Some programs do not read system proxy settings or establish network connections themselves. TUN mode receives this traffic through a virtual network interface, then passes it to the core for routing and outbound processing. It covers more traffic, but depends more heavily on system permissions, driver status, DNS settings, and compatibility with other network tools.
First confirm that the node and subscription work in ordinary system proxy mode, then enable TUN. If domains stop resolving, local network resources become inaccessible, or some apps lose connectivity, disable TUN to restore the baseline and check DNS, bypassed networks, strict routing, and permissions. Separating node failures from system-capture issues is usually faster than changing several settings at once.
View the TUN mode guide →For desktop systems, start with v2rayN. On Android, choose between v2rayNG and v2flyNG based on core requirements. The download page explains supported architectures and package formats.
Choose the v2rayN desktop edition or the classic WPF edition. Both suit desktop users who need subscription groups, routing rules, system proxy settings, logs, and TUN configuration. Their workflows are similar, so choose based on your system environment and interface preference.
Go to downloadsv2rayN provides desktop downloads for different processor architectures. Check your chip type in the system information before choosing a file. After installation, start by importing a subscription, verify the basic connection, and only then decide whether to enable additional traffic-capture features.
Go to downloadsv2rayNG uses the Xray core and suits users who need capabilities related to VLESS and REALITY; v2flyNG uses the V2Fly core as another option in the same ecosystem. Most newer devices should start with arm64. If you cannot confirm the architecture, use the generic package.
Go to downloadsv2rayN provides common package formats and separates them by processor architecture. Confirm your distribution’s package system, then verify the device architecture. If you need TUN after installation, also check system permissions, network management services, and existing firewall rules.
Go to downloadsBuild a working baseline first, then add more advanced features gradually. Keep a verifiable result at every step to make troubleshooting easier.
For Windows, macOS, and Linux desktops, start with v2rayN; on Android, choose v2rayNG or v2flyNG based on the core you need. Before downloading, confirm the operating system, processor architecture, and package format. Do not cross-install packages merely because their filenames look similar. After the first launch, learn the server list, subscription groups, logs, and settings areas while leaving routing and proxy defaults unchanged.
If the system requests permission, consider what the current feature needs it for. Ordinary system proxy mode usually only changes system network settings; TUN may require elevated permissions. Until the basic connection works, avoid enabling TUN, strict routing, or complex DNS options.
Add the complete URL under Subscriptions and run a manual update after saving it. Confirm that server entries appear in the group, then select one as the active configuration. A successful subscription update only means the client received data; it does not mean every node can connect. Validate it with a real connection test or by accessing the target service directly.
If no entries appear after import, first check that the URL was copied completely, the response uses a subscription format supported by the client, and the current group has no filters hiding entries. If entries exist but fail to connect, inspect parsing, handshake, timeout, and DNS details in the logs. Treat subscription retrieval and node connectivity as separate stages to avoid unproductive changes.
After selecting the active configuration, enable the client’s system proxy so programs that honor system proxy settings can use the connection. Test at least one destination expected to connect directly and one expected to use the proxy, and check the logs for the corresponding requests. Once ordinary mode is stable, decide whether TUN is needed based on whether the application reads system proxy settings.
Apply the smallest-change principle when editing routing rules: add one rule category at a time and continue only after the result matches expectations. If something breaks, restore the last known working state instead of replacing the subscription, node, DNS, and routing mode simultaneously. Routine maintenance means updating subscriptions, reading release notes, keeping a rollback configuration, and retesting after changes to the system network environment.
V2Ray is generally not the name of a single desktop application, but a technology ecosystem made up of cores, protocol implementations, configuration formats, and graphical clients. Graphical clients provide subscription management, configuration editing, system proxy settings, logs, and update controls; the underlying core handles inbound, outbound, transport, and routing logic. Understanding this division helps identify whether a problem belongs to the interface, configuration, or core capabilities.
Project V established the configuration structure and core concepts of the V2Ray ecosystem. The V2Fly community later continued maintaining V2Ray Core and advancing protocol implementations, transport methods, routing capabilities, and compatibility. Xray developed from related technical foundations into an independent core branch, with its own implementations and release cadence around features such as VLESS, XTLS, and REALITY.
The two core families are not client names. v2rayNG commonly uses the Xray core, while v2flyNG corresponds to the V2Fly core. As a desktop graphical client, v2rayN manages configurations and invokes the core. Choose a client by platform and workflow first, then check whether the subscription’s protocols and transport settings require a particular core.
v2rayN targets desktop systems and suits users who need server lists, subscription groups, batch testing, log panels, routing settings, and TUN. v2rayNG targets Android, organizing its interface around mobile connections, subscriptions, and routing while using the Xray core for relevant configurations. v2flyNG also targets Android, but follows the V2Fly core path and can be used when a configuration requires its compatibility.
There is no universal rule that the client with more features is always the better choice. Desktop and mobile systems use different network models, permissions, and background behavior. More useful criteria are platform fit, configuration format support, whether the current core recognizes the protocol and transport parameters, and how clearly everyday maintenance tasks are exposed.
Cores and graphical clients are released under the open-source licenses declared by their respective projects. Licenses define the terms for using, modifying, and redistributing code; consult the license text supplied with the relevant project release for its exact scope. The practical value of open source is that implementation logic can be reviewed, feature changes can be tracked through commits and release notes, and compatibility issues can be discussed reproducibly.
Open source does not replace configuration judgment. Subscription content comes from the service selected by the user, while node availability, protocol parameters, and network conditions are not controlled by the client alone. Troubleshooting should therefore distinguish among the client, core, configuration source, system proxy, and local network instead of attributing every connection problem to one program.
Client updates commonly change the interface, subscription parsing, system integration, and bug fixes; core updates may affect protocol behavior, transport implementations, routing rules, and security fixes. Their release schedules can differ. When a new protocol parameter is not recognized, first identify which core is in use, then check whether the client exposes the corresponding configuration option.
Before updating, record the current subscription groups, routing mode, DNS choice, and TUN status, then retest the basic connection afterward. For complex configurations, keep a minimal working setup to distinguish version compatibility problems from conflicts in existing rules. Routine maintenance does not require rebuilding configurations often, but subscription formats and core capabilities should not be ignored indefinitely.
Clear answers to the concepts most often misunderstood during first installation. The terminology section provides further explanations of protocols, cores, subscriptions, and routing.
For desktop systems, start with v2rayN. On Android, choose v2rayNG when the configuration depends on Xray-related capabilities, or v2flyNG when the V2Fly core is required. Match the operating system first, then verify the protocol and transport parameters rather than choosing based on similar names.
Run a manual update first, then confirm that the subscription URL is complete, the response format is supported by the client, and no group filter is hiding entries. An empty list points to subscription retrieval or parsing; if entries exist but fail to connect, investigate node parameters, network conditions, and core logs.
System proxy mainly serves programs that read the system proxy settings. TUN captures a broader range of traffic through a virtual network interface, while also involving permissions, DNS, routing, and local network compatibility. Complete a normal system proxy test first, then decide whether TUN is necessary.
Most standard subscriptions and basic configurations can continue to work, but complex routing, DNS, TUN, and protocol-specific parameters may be affected by client or core changes. Record key settings before updating, test a minimal configuration afterward, and restore advanced features one at a time.
Notes on subscription formats, node selection, client interfaces, core differences, and troubleshooting methods. Each article focuses on a specific problem, making it easy to jump from search results to the relevant steps.
A section-by-section guide to server-list sorting and testing, subscription-group management, log-panel reading, and the locations of tray-menu and core settings. Ideal for building a clear map of the interface after installation.
Read the full article →Troubleshoot four areas in order—expired URLs, network connectivity, format compatibility, and client settings—and learn when to use manual or automatic updates instead of mistaking a subscription issue for a node failure.
Read the full article →Review the development and maintenance paths of the two core families, compare capabilities such as VLESS, REALITY, and XTLS, and use v2rayN, v2rayNG, and v2flyNG to illustrate how to choose.
Read the full article →