Windows
v2rayN comes in a desktop edition and a classic WPF edition. The desktop edition uses a cross-platform UI, while WPF retains the classic interface. Check the system requirements, then choose the one that suits your workflow.
Download →Choose a client for your operating system, build your setup with subscription import, and use routing rules to separate direct and proxied traffic. Then adjust the core, TUN mode, and DNS as needed.
CLIENT SELECTION
Check your operating system and processor architecture before choosing an installer. Use v2rayN on desktop and v2rayNG on Android. If you already have a V2Fly configuration, consider v2flyNG. The client manages your settings; connecting still requires valid server details.
v2rayN comes in a desktop edition and a classic WPF edition. The desktop edition uses a cross-platform UI, while WPF retains the classic interface. Check the system requirements, then choose the one that suits your workflow.
Download →Choose the v2rayN desktop edition. Check your chip in About This Mac: Apple Silicon and Intel require different installers. Don’t choose based on how the device looks.
Download →We recommend v2rayNG with the Xray core. v2flyNG is an alternative with the V2Fly core. Start by checking the arm64 build; if you’re unsure of your device’s architecture, see the universal build notes.
Download →Use the v2rayN desktop edition. Choose deb or rpm for your distribution, then select x64 or arm64. Package format and processor architecture are separate requirements; match both.
Download →The installer determines whether the client can run on your device; it doesn’t determine which protocol the server uses. If you already have a subscription, check its core and protocol requirements before choosing an installer. An installation failure on a different desktop architecture doesn’t mean your subscription is invalid.
Browse all clients →CONFIGURATION WORKSPACE
Subscriptions determine where server details come from, routing determines where traffic goes, and the core determines whether a configuration can run. Understand these layers before changing settings. The snippets below explain individual fields; they are not complete files you can use to replace an existing configuration. Menu names may vary between client versions.
A subscription URL provides server configurations; it isn’t a share link for a single server. In your client, create a group for the source, enter the subscription URL, and update it. Compared with adding servers one by one, subscriptions make connection details easier to maintain centrally, but local edits may be replaced during the next update. Use clear group names to distinguish sources, run one manual update first, then enable automatic updates. Subscription data includes connection credentials, so hide the full URL when troubleshooting and never include it in public screenshots.
{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
},
{
"tag": "http-in",
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {}
}
]
}
Subscriptions are managed by the client, not defined by a universal core field. This example shows a local inbound structure available after importing a configuration. Make sure the port matches your actual settings.
See how to import a subscription →Routing rules are checked in order, and matching traffic is sent to the specified outbound. Put LAN and specific-domain rules first, broader rules next, and catch-all traffic last. Unlike switching the entire client to global mode, routing lets you assign traffic to direct, proxy, or block actions separately. Before configuring a rule, confirm that its outbound tag exists and that the domain and IP rule sets are available. Conditions within a rule usually all need to match; don’t combine conditions that you expect to match independently. After making changes, check the logs to see which rule matched.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
This snippet assumes the direct and proxy outbounds and their associated rule data already exist. Put the fallback rule after the specific rules.
Read the routing guide →The core handles protocols and connections; the client provides the interface and manages configuration. Choose a core based on the server’s protocol and transport requirements, not its name alone. REALITY and XTLS Vision require an Xray configuration stack that supports those features. For an existing V2Fly configuration, check the target core’s field documentation. The two cores share some configuration concepts, but that doesn’t mean every field is interchangeable. Save your original configuration before switching, then check the startup logs and test the connection. This helps distinguish incompatible fields from server issues.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}
These are basic outbound structures commonly used with both core families. This isn’t a core-switching command and doesn’t include a proxy server outbound.
Compare core differences →A system proxy works for apps that follow the operating system’s proxy settings. TUN mode uses a virtual network interface to capture traffic, including traffic from some apps that ignore system proxy settings. It doesn’t replace routing rules: captured traffic still needs to be assigned to a direct or proxy outbound. Before enabling it, make sure a regular proxy connection works, grant the required permissions, and check for other VPNs or proxy apps that may be running. Android clients typically use the system VPN interface for traffic capture; this isn’t directly equivalent to the desktop implementation. If something goes wrong, turn off traffic capture first, restore a basic connection, and troubleshoot one setting at a time.
{
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["socks-in", "http-in"],
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
This snippet illustrates the difference between traffic capture and routing; it doesn’t create a virtual network interface. TUN settings depend on the client and its supporting components.
Explore proxy modes →DNS resolution translates domain names into IP addresses, so consider the resolution path alongside the connection path. Domains routed directly can use a resolver reachable on your current network; for proxied domains, check that remote resolution works. Changing a single DNS address doesn’t mean every app will use the same resolver: browser secure DNS, the system cache, and the client’s built-in DNS may all take effect separately. Keep a working baseline, then test name resolution and the target connection independently. With encrypted DNS, also consider how the resolver’s own domain is resolved the first time.
{
"dns": {
"servers": [
{
"address": "223.5.5.5",
"domains": ["geosite:cn"]
},
"https://1.1.1.1/dns-query"
]
}
}
The resolver addresses are examples only. This snippet doesn’t specify which outbound DNS requests use; check it alongside your routing rules and the behavior of your current core.
Read the DNS setup guide →FIRST CONNECTION
Start with a basic connection you can verify, then add routing and traffic-capture settings. v2rayN is mainly used on desktop and v2rayNG on Android. Their interfaces differ, but the setup sequence is the same: import, select, connect, and verify.
STEP 01
Create a group in subscription management, paste the full subscription URL, save it, and run a manual update. If you have a single share link, use clipboard import or the relevant share-link import feature instead of entering it in the subscription URL field.
After the update, check that the list contains selectable configurations, then verify that the protocol, port, and transport fields are present. If the list is empty, first check that the URL was copied in full, the subscription is valid, and your network can reach the subscription service. Reinstalling the client repeatedly usually won’t fix a problem with the source URL.
STEP 02
Select the server configuration you want to use and make sure its protocol is supported by the active core. On desktop, you can start by enabling the system proxy and choosing a routing mode that suits your needs. On Android, grant VPN connection permission when prompted.
The system proxy switch determines which apps send requests to the client; the routing mode determines how the client forwards those requests. They aren’t interchangeable. Start with easy-to-understand defaults, verify the connection, then add your own domain rules. Avoid changing several settings at once so you can troubleshoot effectively.
STEP 03
Once connected, visit one site expected to go direct and another expected to use the proxy. Check the client logs to see which outbound was actually used. A successful test only confirms that specific test; it doesn’t mean your browser, download manager, and other apps all use the same route.
If your browser works but other apps don’t, first check whether they follow the system proxy. When you’re done, turn off the system proxy or virtual-interface traffic capture before exiting the client. If your network stops working afterward, check whether the system proxy still points to a local port that is no longer running before changing other network settings.
A failed subscription update, a core that won’t start, and an app that can’t connect are problems at different stages. Note where the failure occurs, change one setting related to that stage, and repeat the same test. This preserves working settings and helps keep DNS, permissions, and server parameters from getting mixed up.
PROJECT V ECOSYSTEM
V2Ray is a common name for an ecosystem, not a single app with one consistent interface. Understanding how clients, cores, and protocols fit together helps you decide whether to change the installer, adjust your configuration, or check the server’s requirements.
Project V centers on modular network proxy tools, with configurations commonly covering inbounds, outbounds, routing, and DNS. V2Fly continues community development of V2Ray-related cores, while Xray has evolved from related code into its own set of protocol and transport features. The two projects share a background but have developed their configurations independently; they aren’t interchangeable executables.
Choose based on what the server requires: identify the protocol, then the transport and security layer, and finally confirm core support. VLESS, REALITY, and Vision each involve different configuration concepts. Seeing one of those names doesn’t guarantee the entire connection setup is compatible. A client displaying an option doesn’t mean the server has enabled the corresponding feature.
Core names aren’t speed rankings. Connection performance also depends on the server route, destination, DNS results, and your local network. When troubleshooting, keep a known-working setup and compare changes under the same conditions. This is more reliable than replacing every component at once.
v2rayN provides a desktop interface for organizing server details, subscription groups, and routing options, then hands them off to a compatible core. v2rayNG is for Android and uses the Xray core; v2flyNG is for Android and uses the V2Fly core. All three are open-source projects, but their features, core pairings, and platform integrations differ.
Cross-platform desktop support doesn’t mean every operating system handles permissions and traffic capture the same way. Proxy settings, virtual network interface permissions, and package formats vary by system. When migrating a configuration, start with the server details or subscription source, then check local ports, file paths, and operating-system-specific settings.
A client isn’t a server service. After installation, you still need to import valid connection details. Check subscription validity, server reachability, and client status separately. This site organizes its documentation around client installation and setup, with download links and getting-started steps on their respective pages.
Open source makes source code available under license terms for the community to review, study, and help maintain. The V2Fly core is licensed under MIT, while Xray-core uses MPL 2.0. Graphical clients and their dependencies may have their own license requirements. Before using, modifying, or redistributing software, read the license terms for each project and dependency; one ecosystem name can’t summarize them all.
Open-source licensing and server service fees are separate matters. You may be able to use a client for free, while external providers set their own pricing, connection limits, and service periods. A successful client installation doesn’t guarantee that a subscription will work, and subscription limits aren’t client feature limits.
Connection details are sensitive. Before sharing logs, remove the full subscription URL, user identifiers, and authentication data. Keep the error type, relevant configuration layer, and steps to reproduce. A clear problem description is more useful than posting your entire configuration.
UI updates, core updates, rule-data updates, and subscription updates are four different operations. A UI update may change menus or defaults; a core update affects protocol implementations and field compatibility; a rule-data update changes domain or IP lists; a subscription update fetches server details again. When troubleshooting, first identify which layer changed most recently.
Before updating, save your subscription groups, custom rules you need, and known-working settings. After updating, verify the basic connection before enabling new features. Automatically generated runtime configuration may be overwritten on restart or save, so manage long-term rules through the client’s persistent settings instead of editing a temporary generated file.
Keep a brief configuration record: the core family in use, traffic-capture method, DNS strategy, and any custom outbound tags. It doesn’t need connection credentials, but it can help distinguish overwritten settings, unmatched rules, and unreachable servers—and make it easier to follow advanced guides one step at a time.
First see how inbounds receive app requests, then how routing selects an outbound, and finally check the outbound protocol and DNS resolution path. When reading examples, distinguish complete configurations from snippets. Copying a routing rule without its matching outbound tag won’t create a working connection.
Explore protocols and advanced setup →CONFIGURATION NOTES
Once your first connection works, explore the guides that address your needs. Proxy modes, desktop client differences, and server configuration requirements involve separate decisions. Learn them one at a time; you don’t need to master every detail during installation.
Understand the difference between the system proxy switch and routing modes. Learn how global and bypass-mainland-China routing work, and when TUN mode is useful for capturing all traffic.
Useful if your browser works but other apps don’t. First check whether their traffic reaches the client, then see which rule it matches—rather than repeatedly switching between mode names.
Read the article →Compare the availability, appearance, and dependencies of v2rayN builds using two UI frameworks across desktop operating systems, with recommendations on which version to download for each system.
Check this before downloading to find the right installer. The UI framework affects the user experience and platform support, but it isn’t a protocol. After choosing an interface, check its compatible core and your server’s requirements.
Read the article →Learn what client latency tests can and can’t tell you, how traffic multipliers affect usage, and how to choose a region and protocol for your needs—without unnecessary trial and error.
For users who have imported a subscription but aren’t sure which configuration to select. Test results reflect specific conditions; consider your destination, connection stability, and provider’s documentation rather than relying on a single metric.
Read the article →Topic guides explain one configuration decision at a time; start with the Getting Started guide for step-by-step instructions. For multiple subscription groups, custom outbounds, or more complex DNS policies, move on to the advanced configuration guides and verify each change before saving.
Browse all articles →