CLIENT CONFIGURATION INDEX
A step-by-step guide to downloading clients, importing subscriptions, and routing traffic, covering the platforms, core differences, system proxy settings, and common connection issues for v2rayN, v2rayNG, and v2flyNG.
PLATFORM DOWNLOAD
Confirm your device platform and processor architecture first, then choose the matching client. The homepage routes you to the right platform; check package types, system requirements, and file details on the download page.
DESKTOP
For Windows desktops, start with v2rayN. The download page explains which systems support the newer desktop interface and the classic WPF interface. If you already have settings, back up subscription groups and routing rules before choosing an installation method.
Go to DownloadsDESKTOP
On macOS, use the v2rayN desktop client. Check the processor type in System Information before downloading, since Apple Silicon and Intel require different files. After importing a subscription, proxy modes, routing rules, and desktop workflows are broadly similar across platforms.
Go to DownloadsMOBILE
On Android, choose between v2rayNG and v2flyNG. The former uses the Xray core and suits common Xray configurations; the latter uses the v2fly core and matches V2Fly ecosystem configurations. Also distinguish between arm64 and universal builds when downloading.
Go to DownloadsDESKTOP
On Linux desktops, use v2rayN and choose a deb or rpm package for your distribution, while checking whether you need x64 or arm64. After installation, verify the client process, system proxy status, and desktop network settings separately so the core does not run without taking over application traffic.
Go to DownloadsCLIENT WORKSTATION
The client names are similar, but their platforms, core families, and settings entry points are not identical. Choose a client for the device first, then configure subscriptions, nodes, proxy mode, and routing rules in that order.
v2rayN supports Windows, macOS, and Linux, making it suitable for desktop environments that manage multiple subscription groups, manual nodes, and routing rules. A typical workflow is to create a subscription group, update the server list, run a real connection test, choose an active node, and enable the appropriate system proxy mode. The client can use Xray or V2Fly core capabilities; available protocols depend on the selected core and configuration. When troubleshooting, verify client logs, system proxy settings, and browser connectivity separately rather than relying on a single status in the node list.
v2rayNG is built for Android and uses the Xray core, making it suitable for common VLESS, VMess, and Trojan configurations. After updating a subscription, confirm that the new configurations were added to the active group, then select a node and start the system connection. Per-app proxying, LAN bypass, and routing presets directly determine which traffic enters the proxy chain. If some apps work while others fail, check these options first. After switching between mobile data and Wi-Fi, reconnect and review domain resolution, handshake, and routing results in the logs.
v2flyNG also targets Android, but follows the V2Fly core family. It suits configurations that explicitly depend on v2fly core behavior or need to stay consistent with V2Fly configurations on other devices. The workflow remains: import the subscription, update the group, choose a node, start the connection, and check the logs. If the same subscription behaves differently across clients, compare protocol parameters, transport fields, DNS settings, and routing rules instead of copying every toggle from one client. Check core support and client interface options separately.
QUICK START
Do not change many advanced options at once during initial setup. Establish one reproducible basic connection first, then add routing, DNS, and per-app rules step by step so you can identify exactly what caused a problem.
Copy the complete V2Ray subscription link, add it under the client's subscription group or subscription settings, and run an update. When the update finishes, do not connect immediately. First confirm that configurations actually appear in the server list and that they are in the group you just created. If the list is empty, check the link for missing characters, whether the subscription source is reachable, and whether the client log reports a format parsing error. QR codes and single-node links work well for temporary imports; for maintaining multiple nodes long term, subscription groups make updates and source tracking easier.
Choose a node from the current group as the active configuration, and run a real connection test first to confirm that the full handshake can be established. On desktop, set the system proxy mode; on Android, start the system connection. For the first verification, use the client's basic proxy mode and postpone complex routing. Global proxy sends more traffic through the proxy outbound, while rule mode uses domains, IPs, ports, processes, and other conditions to choose direct or proxied connections. These are traffic-selection strategies; they cannot fix incorrect subscription parameters or an unreachable node.
After starting the connection, use a browser to open a page known to work, then check whether the client log records the request. On desktop, confirm that the operating system proxy settings were applied and that they are restored as expected when the client closes. If only some sites fail, inspect domain resolution and route matching; if every connection times out, check the node address, port, protocol parameters, and local network first. Once the basic path works, add geosite, geoip, ad-blocking, or per-app rules one group at a time, preserving logs before and after each change.
OPEN SOURCE ECOSYSTEM
The client handles the interface, subscriptions, and system integration; the core handles protocols, transports, routing, and outbound processing. Separating these layers is essential for understanding client differences and troubleshooting configurations.
Project V was the early open-source ecosystem built around V2Ray-related technologies and tools, with a configuration model organized around inbounds, outbounds, routing, DNS, transports, and policies. As the community evolved, V2Fly continued and maintained the v2ray-core line, while Xray developed a separate core path based on similar configuration ideas. They share many concepts, but protocol support, field details, transport capabilities, and default behavior may differ. When you see a “V2Ray configuration,” confirm not only the name but also which core the client actually invokes and what configuration target generated the subscription.
A graphical client is not the same thing as a core. v2rayN primarily handles desktop subscription management, node selection, system proxy settings, route editing, log viewing, and core invocation; v2rayNG and v2flyNG bring similar capabilities into Android's system connection workflow. When a connection fails, the interface may display a node normally while the core stops processing because of incompatible fields, a certificate name mismatch, missing transport parameters, or an incorrect routing tag. The specific stage shown in the logs is more informative than a simple “started” status.
Open-source licenses define the boundaries for using, modifying, and redistributing code; follow the license text published by each project. For everyday users, the practical value of open-source maintenance is that configuration formats, issue discussions, and change records can be reviewed over time. Client choice should still be based on platform, core requirements, and configuration source rather than treating every client with similar protocol names as interchangeable.
Updates should also be understood in layers: client updates change interface features, platform support, and subscription management; core updates change protocol implementation, routing capabilities, and low-level network handling; rule-data updates affect domain and IP classification. These releases do not necessarily arrive together. If an old configuration behaves differently after an update, record the client settings, core type, rule source, and error logs, then compare them one by one. Clearing all configuration immediately discards valuable troubleshooting context.
An open-source desktop client for subscription groups, node management, proxy modes, and routing across multiple desktop systems. Confirm the interface version, selected core type, and system proxy status together.
An open-source Android client using the Xray core path. Suitable for per-app proxying, mobile network switching, QR-code imports, and common Xray protocol configurations.
An open-source Android client using the v2fly core path. Suitable when matching V2Fly configuration behavior or retaining that core ecosystem on a mobile device.
CHECKLIST
The questions below follow the configuration path. Check local proxy takeover first, then node handshakes, and finally routing and DNS. This is usually more effective than repeatedly switching nodes.
First confirm that you updated the subscription group currently in use, then check that the subscription address is complete and that the update log reports no parsing error. When several group names are similar, the nodes may have been added to a different group.
View Subscription Troubleshooting →On desktop, check whether the system proxy was applied and whether the browser uses system settings; on Android, check that the system connection is established. Then review the node handshake and domain resolution logs.
Open Troubleshooting →Global mode sends more traffic to the proxy outbound; rule mode chooses direct, proxied, or blocked handling according to matching conditions. For the first connection, verify the basic path before adding routing rules.
Explore Routing Terms →Ping, real connection latency, and download speed tests measure different things. Overall speed is also affected by the handshake, line congestion, server load, transport method, and the destination site's response.
Understand Speed-Test Differences →LATEST NOTES
Find practical details through three entry points: routing rules, first connections, and the client interface. The articles correspond with the terminology and troubleshooting pages, making it easy to continue researching by issue.
Use domain and IP rules to demonstrate direct, proxied, and blocked matching order, explain how outbound tags map to rules, and show how to verify routing results.
Read the Full Article →Starting with the imported node list, complete a real connection test, choose an active node, start the proxy, and verify it in a browser, with a troubleshooting order for failed first connections.
Read the Full Article →Walk through the server-list fields, subscription-group organization, log location, and core settings entry points to build a practical map of the desktop client interface.
Read the Full Article →