| Platform / Project | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Windows | Supported | Not applicable | Not applicable |
| macOS | Supported | Not applicable | Not applicable |
| Linux | Supported | Not applicable | Not applicable |
| Android | Not applicable | Supported | Supported |
| Default core | Multiple cores, including Xray | Xray | V2Fly |
| Subscription link import | Supported | Supported | Supported |
v2rayN · v2rayNG · v2flyNG
Choose a client for your device, then follow the steps for importing subscriptions, setting routing rules, and testing your connection.
Choose a platform firstUse v2rayN on desktop; compare v2rayNG and v2flyNG on Android. Clients manage configuration, but connecting also requires working node details or a subscription URL.
Client downloads by platform
v2rayN
Choose between the Desktop edition and the classic WPF edition. The former uses a modern cross-platform interface; the latter retains the classic workflow. Check your OS and processor requirements before following the relevant setup guide. For your first setup, run only one instance to avoid local port conflicts.
Go to downloads →v2rayN
Choose the Apple Silicon or Intel build for your Mac; check About This Mac if you're unsure. After installation, complete the system's app launch approval steps before importing a subscription. If you enable the system proxy, make sure your browser uses system settings—an open client alone doesn't confirm that the connection is working.
Go to downloads →v2rayNG / v2flyNG
v2rayNG uses Xray, while v2flyNG is an alternative based on V2Fly. Installers are available for arm64 and universal builds; choose based on your device's architecture. On first connection, approve the system VPN prompt. If another VPN app is running, resolve any interface conflict before testing a node.
Go to downloads →v2rayN
Choose deb or rpm based on your distribution's package system, then select x64 or arm64. Not all apps use the system proxy settings configured in the GUI, and terminal programs may use separate environment variables. After installation, test your browser first, then check other apps that need a proxy.
Go to downloads →The installer format determines whether an app can be installed; the processor architecture determines whether it can run; node and core compatibility determine whether it can connect. Checking these separately makes problems easier to isolate than repeatedly switching clients. Before upgrading, preserve your subscription groups, routing rules, and custom settings. After upgrading, test a connection with an existing node before enabling new features.
View all clients →Feature comparison at a glance
"outbounds": [{ "protocol": "vless" }]Subscriptions let you fetch multiple nodes at once; share links typically describe a single node, while native JSON may contain complete inbound, outbound, and routing settings. All three clients offer subscription import, but supported protocols and fields depend on the client and core. After importing, update the subscription and confirm that nodes appear in a group before selecting one. The snippet above shows a core outbound key, not a subscription URL format. If importing fails, check the source format and update logs first—don't paste a full configuration into the URL field.
"routing": { "domainStrategy": "AsIs" }Routing rules select an outbound based on conditions such as domain or destination IP, and are usually evaluated in order. All three clients support rules through their own interfaces and cores, but presets and editing workflows differ. Keep local network access intact, add specific domain rules next, then check where unmatched traffic goes. If rules reference geosite or geoip, make sure the data files are available. Global proxy mode can help narrow down a problem, but it isn't a substitute for everyday routing. Restore your intended mode after testing and review the logs.
"inbounds": [{ "listen": "127.0.0.1", "protocol": "socks" }]A system proxy provides a local proxy endpoint to apps that follow system settings. TUN captures traffic through a virtual network interface. Check v2rayN TUN availability, permissions, and setup for your platform and core; steps for one OS may not apply to another. v2rayNG and v2flyNG use Android's VPN interface, not a desktop system proxy toggle. For your first test, enable only one traffic-capture method. Once connected, check app coverage, local network exceptions, and permissions to avoid confusing routing caused by multiple methods running at once.
"outbounds": [{ "protocol": "vmess" }]The client manages configuration; the core handles protocols. They are separate layers. v2rayN can manage multiple cores; the right choice depends on what's installed, the node type, and client settings. v2rayNG uses Xray, while v2flyNG uses V2Fly. Neither is a general-purpose multi-core switcher. Before changing cores, check transport and field compatibility, and keep a working configuration. The same protocol name doesn't guarantee that all extended parameters are interchangeable. If you see an unknown field, check where the configuration came from and what the core supports.
"dns": { "servers": ["localhost"] }DNS settings control how domain names resolve; routing rules control where connections go. Check both together. First determine whether the issue involves the node server's domain or the target website's domain, then check the resolver's network path. Each client uses its core's DNS capabilities, so interface toggles don't map exactly to JSON fields. The example above shows key names and local resolution syntax, not a universal routing solution. Encrypted DNS in the browser, private DNS in the OS, and the client's own DNS may all affect resolution. Change one variable at a time and record the result.
"log": { "loglevel": "warning" }When troubleshooting logs, distinguish a core that won't start from a failed node connection or an app that isn't using the proxy. If the core won't start, check the first error, port conflicts, configuration syntax, and data files. For connection timeouts, check the node address and network reachability. All three clients show runtime information, though the log locations and level of detail vary. If needed, raise the log level temporarily, reproduce the problem once, then restore it. Before sharing logs, remove subscription URLs, identifiers, and node credentials. Share only the relevant error context, not your full configuration.
These settings affect different layers: configuration sources, matching rules, traffic entry points, the core, and DNS resolution. Don't change everything at once. First confirm the node connects, then check whether the app's traffic reaches the proxy, and finally verify routing and DNS behavior. Record the result at each step to give later changes a clear baseline.
View the complete cross-platform setup guide →A three-step quick-start preview
01 / IMPORT
After installing a client, get a working subscription URL or node share link. In subscription management, add a group, enter the URL, and update it. Confirm that the node count and names change. Clipboard import works well for share links; subscription management is for ongoing updates. Don't confuse the two workflows.
If an update fails, read the message to determine whether the URL is unreachable, the content format is unsupported, or the subscription has expired. Installing the client doesn't provide nodes by itself. If the list is empty, fix the configuration source rather than repeatedly changing proxy modes.
02 / CONNECT
Select a node as the active configuration, then use the client's connection test to check reachability. A region label helps organize a list but doesn't prove the connection works. After a successful test, enable the system proxy on desktop, or start the connection on Android and approve the VPN prompt.
For your first connection, use a straightforward routing preset and keep local network access. Don't run another proxy app, a manually configured browser proxy, and multiple virtual interfaces at the same time. Fewer entry points make it easier to identify which setting is changing an app's traffic route.
03 / VERIFY
Use a browser to visit a page expected to go through the proxy, then check the egress IP and client logs. A page loading is only one signal; confirm that the request actually used the intended outbound. With routing enabled, direct and proxied sites may show different egress IPs. That's expected when the rules call for it, so test both separately.
If your browser works but another app doesn't, check whether that app uses the system proxy before switching nodes. If every app fails, return to the node connection test and core logs. Change one setting at a time and repeat the same tests to establish a clear cause and effect.
Before closing the client, turn off the system proxy or stop the VPN connection to avoid leaving an entry point that targets a stopped service. When you start again, confirm the active node is still available before reconnecting. To move to another device, transfer the subscription source and essential rules where possible. Don't overwrite its configuration with a full setup that includes local paths, listening ports, or platform-specific permissions.
View the full guide →Project V · V2Fly · Xray
PROJECT V
Project V is an open-source ecosystem built around proxy tools and modular configuration. V2Ray is one of its widely used project names. People searching for a “V2Ray client” usually want a graphical app to manage nodes, generate configuration, and control connections—not a standalone core binary. v2rayN, v2rayNG, and v2flyNG serve this user-facing role, with features such as subscription management, settings editing, and runtime information.
Understanding the distinction makes troubleshooting easier to break down by layer: did the interface save the settings, did the core accept the generated configuration, and did the OS or app route traffic to the entry point? Each question points to a different place to investigate; not every failure means the client itself is unusable.
CORE FAMILY
V2Fly continues the community maintenance and development of V2Ray-related projects. Xray grew from related code and developed its own features and protocol implementations. Their basic configuration concepts overlap, but independent development means supported fields, transport combinations, and extensions aren't identical. Match node configuration to the core actually in use; a share link's prefix alone doesn't guarantee every parameter is compatible.
v2rayNG uses Xray, and v2flyNG uses V2Fly. v2rayN offers desktop users a choice of multiple cores. Choose based on the requirements of your existing nodes, not on the assumption that a core name implies a speed ranking. Network path, server setup, and local traffic capture also affect results.
OPEN SOURCE
All three clients make their code available as open source, but their cores and graphical interfaces are separate projects. V2Fly's V2Ray core and the Xray core use the MPL 2.0 license. Each client and bundled component is subject to its own license. Open source means code and license terms are available for review; it doesn't mean every project uses the same terms or that every configuration can be used as-is.
For everyday use, focus on understanding your settings. If you modify, redistribute, or integrate components, read the relevant license texts. Node addresses, identity parameters, and server arrangements in a subscription come from its provider; the GUI client doesn't supply them. Installing the software and obtaining connection details are separate steps.
UPDATE PATH
Client updates may change the interface, subscription parsing, or configuration generation. Core updates may change protocol support and parameter requirements. Rule data updates affect domain or IP matching. These don't always happen together. Before updating, note a working node, proxy entry point, and custom rules. Afterward, repeat the same tests against the same targets to identify which layer changed.
Updating a subscription refreshes the configuration list; it doesn't upgrade the app or fix local permission and port conflicts. If something goes wrong, identify what changed most recently before deciding whether to revisit the subscription, adjust the core, or restore rules. Keep a record of essential settings for long-term use, but don't put credential-containing configurations in public documents.
For managing multiple nodes and routing on desktop, start with v2rayN. For an existing Xray setup on Android, start with v2rayNG. If your configuration depends on V2Fly behavior, check v2flyNG. Choose a client based on platform, core, and maintenance practices; test connection quality on your own network. They're separate considerations, not the same conclusion.
Compare the three clients by platform and core →Configuration guides
Covers common errors including port conflicts, JSON syntax issues, unknown protocol fields, and missing geo files. Learn to locate and fix errors in v2rayN and v2rayNG logs.
Read the article →From bypassing local networks and mainland China traffic to global proxy mode, learn how to combine domain, ip, and outboundTag rules, with ordering tips and custom rule-set examples.
Read the article →Explore dns servers, domains matching, and queryStrategy. See how to resolve domains in mainland China locally and other domains through remote DNS, while avoiding common DNS spoofing and leak issues.
Read the article →Just imported a subscription? Follow the quick-start guide to test a node and the system proxy. If the connection works but routing results are unexpected, read the routing and DNS guides. If the core won't start, fix configuration errors in the logs first; resolver and routing tweaks can't replace the basic startup requirements.
View all articles →