Desktop and Android client resources
A focused reference for v2rayN client downloads, subscription imports, and traffic routing. Coverage includes desktop and Android clients, with setting names matching the client interface.
Start with v2rayN on desktop platforms; on Android, choose v2rayNG or v2flyNG based on the required core. Each link opens the matching platform tab on the download page.
Use the v2rayN desktop edition or the classic WPF edition. The desktop edition uses a cross-platform interface and suits new environments; the WPF edition keeps the traditional layout, with the tray menu, server list, and system proxy controls grouped together.
Use the v2rayN desktop client. Before downloading, check the processor type in system information, then choose the Apple Silicon or Intel package. On first launch, follow the system prompts to confirm the app and configure network permissions.
Use v2rayNG with the Xray core by default; choose v2flyNG when V2Fly is required. Most recent devices suit the arm64 package. If the architecture is unknown, choose the universal build.
Use the v2rayN desktop client. Choose deb for Debian, Ubuntu, and similar systems, or rpm for Fedora, RHEL, and related distributions. Also match the x64 or arm64 package to the device processor.
The feature directory follows the practical configuration sequence. Select an item on the left to see its purpose, scope, and related settings.
Subscriptions centralize server configuration and make it easy to switch between nodes. Before importing, verify the link source and group name, then refresh the subscription so the client reads the current content. After the update, servers are added to the matching group using the names supplied by the subscription; existing manual entries can usually remain separate. If the list is empty after import, check the selected subscription group and confirm that the link is complete instead of repeatedly toggling the system proxy.
v2rayN supports scheduled refresh intervals and manual updates for individual groups. When the same subscription is used on multiple devices, each client must still be refreshed separately. The subscription does not directly synchronize routing mode, system proxy status, or interface preferences. This keeps server configuration separate from local policy, so changing one does not overwrite the other.
The system proxy setting controls which applications follow the operating system proxy and use the current client. Automatic configuration suits browsers and desktop programs that honor system proxy settings; when enabled, the client writes the local proxy address. When disabled, clear the system proxy state as well so applications do not keep pointing to a port that is no longer listening. Some programs use an independent network stack and ignore the system proxy; check their own proxy options or use another interception method provided by the client.
Connecting a node and enabling the system proxy are separate actions: the first lets the core establish a working outbound connection, while the second determines whether system traffic is sent through it. For troubleshooting, confirm in order that the current server is active, the core is running normally, and the system proxy state has changed. Checking these separately is more effective than repeatedly restarting the client.
Routing rules determine whether requests entering the core connect directly, use the proxy, or are blocked. Common presets match domains, address ranges, and LAN destinations; for example, bypassing LAN and mainland China preserves local-device access and reduces connections that do not need the proxy. Routing decisions occur after traffic enters the client, so routing mode cannot replace a system proxy or a TUN traffic entry point. Configure them separately.
When creating custom rules, start with clearly scoped conditions: handle LAN ranges, specific domains, and application requirements first, then set a fallback outbound. Rule order affects the final match. After editing, reconnect the current node and verify access to a target site. If there are many rules, temporarily return to a preset mode to determine whether the issue comes from the node or the custom matching conditions.
The graphical client handles the interface, subscriptions, and system integration; the core establishes protocol connections. Xray and V2Fly belong to the Project V ecosystem. Their basic configuration concepts are similar, but extended features and protocol support are not identical. For VLESS, REALITY, and XTLS Vision configurations, verify the server requirements and the client core's capabilities. Standard VMess, VLESS, and Trojan configurations also require matching transport parameters.
v2rayN manages multiple core configurations on desktop, v2rayNG primarily uses the Xray core, and v2flyNG corresponds to the V2Fly core. Choose based on the node protocol and transport parameters, not just the client name. If a configuration imports successfully but will not connect, compare the protocol, address, port, transport, and security settings before checking whether the core supports the relevant extensions.
ICMP ping, real connection latency, and download speed measure different stages. Ping mainly measures round-trip time to the server's network interface and does not include a complete proxy handshake. Real connection latency includes protocol and transport setup, making it closer to the wait before a webpage opens. Download speed measures sustained throughput and is easily affected by server load, intermediate routes, and local network conditions. Different results are normal; no single number can determine configuration quality.
For connection failures, first check the client log for completed DNS resolution and protocol handshaking, then check whether a local port is occupied by another program. For slow speeds, compare three layers—node, route, and local settings: test the same target with another node, compare different times to identify congestion, and finally inspect routing, core, and concurrency settings. Change one thing at a time so results remain reproducible.
Clients, cores, and protocols operate at different layers. Understanding their relationship helps you choose the right package, assess configuration compatibility, and quickly identify what changed after an update.
Project V established a technical ecosystem built around configuration-driven proxy cores. V2Ray's concepts of inbound and outbound connections, routing, and transport layers provided a common configuration foundation for later clients. Graphical clients do not redefine these protocols; they turn JSON configuration, subscription content, system proxy settings, and process management into an accessible interface. When a user switches nodes in the server list, the client generates a runtime configuration the core can read.
V2Fly continues the community maintenance direction of the V2Ray core, focusing on general-purpose protocols and modular configuration. Xray developed its own extensions within a similar configuration model, including implementations related to XTLS and REALITY. The two share many fundamentals, but feature timelines, parameter names, and compatibility boundaries may differ. When a configuration provider specifies a required core, follow that requirement rather than assuming every extension is interchangeable.
VMess, VLESS, and Trojan are proxy protocols; WebSocket, gRPC, and TCP are transport methods; TLS and REALITY handle security and handshake settings at different layers. A subscription is only a way to distribute configuration and does not change the protocol itself. Checking these fields by layer helps distinguish a failed subscription refresh from core incompatibility or an inactive routing rule.
Related projects are maintained as open source, with their communities continuing to develop code, fix issues, and implement protocols. Open-source licenses define the boundaries for using, modifying, and redistributing code, while enabling different graphical clients to provide interfaces and system integration around the same core ecosystem. Client updates commonly change the interface, subscription parsing, platform support, or core management; core updates affect protocol support and connection behavior more directly.
In practice, clients and cores do not always release updates together. When behavior changes after an update, first identify whether the change is in the client interface, subscription content, or underlying core, then revisit settings or adjust the configuration accordingly. Keeping records of the working subscription source and routing policy makes it easier to reproduce the same connection conditions when moving between devices.
A graphical client for Windows, macOS, and Linux. Features include subscription groups, server switching, system proxy controls, routing rules, log viewing, and core management. Desktop settings are organized in one workspace, making it suitable for environments that maintain multiple subscriptions, manual nodes, and custom routes.
A graphical Android client built primarily around the Xray core. Import configurations from subscription links, clipboard content, or QR codes, then use the system VPN service to handle device traffic. Suitable for configurations that use Xray extensions and related transport parameters.
An Android client for the V2Fly core, with controls similar to those found in common Android proxy clients. It suits configurations that explicitly require the V2Fly core and serves as an alternative when choosing by core type. Always verify the protocol, transport method, and security parameters before importing.
Articles cover installation, cores, speed testing, and multi-device management, with a focus on how settings affect one another.
Locate bottlenecks across the node, intermediate route, and local configuration. Compare different nodes, test during off-peak hours, and inspect routing and core settings one at a time instead of changing several variables at once.
Read the full articleCompare centralized subscription management, configuration-file transfer, and QR-code sharing. Learn which fields can sync between desktop v2rayN and Android clients, and which local settings must be configured separately.
Read the full articleExplains which network stages each test covers, why a short round-trip time does not mean high throughput or a successful proxy handshake, and which test to run first for different problems.
Read the full articleInstall the client and import a subscription first, then select the current server, enable the system proxy, and verify access. When problems occur, note the time and failure stage in the logs and work back through the guide.