v2rayN offers downloads for its desktop edition and classic WPF edition. The desktop edition uses a cross-platform interface, while the WPF edition retains a familiar desktop workflow. Check your system architecture first, then choose the interface that suits you.
For your first install, place the client in a writable directory. Import a subscription, select a server, then enable the system proxy. If the app won’t start, check the required runtimes and directory permissions first.
v2rayN offers separate downloads for Apple silicon and Intel Macs. Check your chip in About This Mac rather than guessing the package architecture from your computer’s appearance.
After installation, grant any permissions required by macOS. For regular web browsing, start with the system proxy. If you need to route more apps, learn about TUN and watch for network extension permission prompts.
Start with v2rayNG, which uses the Xray core. If you need the V2Fly core, look into v2flyNG. Most current devices use arm64; if you’re unsure of your architecture, check the universal build details.
On the first connection, Android will request VPN permission. Approve it, run a real connection test, then check that apps can reach their destinations. If the connection drops in the background, review battery optimization and background activity restrictions.
v2rayN offers deb and rpm packages, with arm64 builds also available. Choose a package that matches both your distribution’s package format and your processor architecture.
After launching the graphical interface, check your server profile and local proxy port. Desktop environments handle system proxies differently, so check each app’s own proxy settings to confirm it’s using the proxy.
The installer contains the client app, not a ready-to-use server. Before setup, get a valid subscription URL or server details. Subscription URLs may contain account credentials, so don’t post them publicly or include them in screenshots.
Start with a basic connection you can verify, then adjust settings one at a time. The interface below is illustrative; menu names vary by client version.
System proxy: get your everyday apps connected
A system proxy gives apps that honor your system settings a local proxy address, making it a good first step for testing browser access. Import a subscription, select a server, enable the system proxy in the client, then open a new webpage to check the connection. Unlike TUN, this usually doesn’t create a virtual network interface. Some apps ignore system proxy settings, so you may need to configure them individually. Clear the system proxy before closing the client to avoid leaving your system pointed at a local port that is no longer running. If the connection fails, first confirm the core is running, then check whether the app uses the system proxy. Avoid changing multiple settings at once.
Routing rules decide whether a request connects directly, goes through a proxy, or is blocked—they don’t simply switch servers. Start with a preset that fits your network, then add a few rules for specific domains or IP addresses. Unlike global proxy mode, routing can keep local resources on a direct path while sending selected services through a proxy. Rules are usually evaluated in order, and a match can stop further checks. A broad rule near the top may override more specific rules below it. After editing, check access results and logs to confirm which route was used. If something breaks, undo the latest change first.
Subscription management: update groups and keep sources organized
A subscription URL retrieves server profiles; it isn’t a website you can browse to. Keep different sources in separate groups, then update each subscription to make filtering and troubleshooting easier. Unlike pasting server links one by one, subscription updates can sync changes from the source—but they may also replace older entries, so back up any local edits first. If an update fails, check the URL, account status, and network path used for the update. Don’t add the same subscription repeatedly, and never share a full URL that contains access credentials.
TUN receives traffic through a virtual network interface, making it useful for apps that can’t use the system proxy directly. First confirm the server works in regular proxy mode, then grant the required permissions and enable TUN as prompted by the client. TUN and the system proxy intercept traffic at different layers, but TUN doesn’t guarantee that every request will use the proxy; routing and exclusion settings still determine the path. Before enabling it, check whether other network tools are already handling traffic. Afterward, test both proxy access and local resources. If your connection drops, disable TUN to restore the previous network state, then check permissions, routing, and DNS separately.
Switching cores: check protocol compatibility first
The graphical client handles configuration and controls; the core processes connections. Within the supported configuration options, v2rayN can use different cores. Before switching, check the server protocol, transport, and related settings. Reviewing the complete configuration—not just the protocol name—helps avoid a successful import that still won’t connect. Changing cores won’t fix an expired subscription or server outage, and custom settings may not carry over as-is. Keep a working configuration, migrate settings one at a time, and review the startup logs. On mobile, choose v2rayNG or v2flyNG based on the core each one requires.
Understanding how clients, cores, and servers fit together is more useful than memorizing a list of switches. It also helps narrow down what to check when something goes wrong.
The ecosystem: clients and cores work at different layers
V2Ray is a network proxy tool in the Project V ecosystem, organizing connections around components such as inbounds, outbounds, routing, and transport. The V2Fly community continues development related to V2Ray, while Xray is a related core project with its own direction. They share technical roots, but they aren’t simply the same software under different names, nor are their configurations necessarily interchangeable. Check protocol support, field meanings, and default behavior against the core you’re actually using.
v2rayN, v2rayNG, and v2flyNG are graphical clients for end users. They provide interfaces for importing subscriptions, selecting servers, and viewing logs, then pass configuration to a core for processing. So, being able to save a profile in the interface doesn’t mean the server is reachable. Importing only confirms that the client accepted the configuration; the core must still start, the server must be reachable, and the settings at both ends must match.
When following a guide, first identify which layer the problem is on. If the app won’t open, check the installation environment. If the core won’t start, check the configuration and permissions. If the core is running but access fails, check the server, routing, and DNS. This order helps avoid irrelevant changes. Troubleshooting several layers at once can make it hard to tell what fixed the issue—or what caused a new one.
Choosing a client: match your device and configuration needs
v2rayN is the main desktop option, bringing server, subscription, and routing management into one graphical interface. Installation and permission steps still vary by operating system, and a cross-platform interface doesn’t make network behavior identical across systems. When switching devices, you can reuse the same configuration principles, but check system proxy settings, TUN permissions, and local file paths again rather than copying another machine’s setup wholesale.
For mobile, start with v2rayNG, which uses the Xray core. If you need a V2Fly core configuration, take a look at v2flyNG. Choose based on your subscription, server requirements, and device compatibility—not just similar names. Both are open-source client projects, but their features, core capabilities, and update schedules differ. Don’t assume that menus or steps in one app match the other.
The client itself doesn’t provide a server you can connect to, and it isn’t a subscription service. After installation, you’ll still need a configuration obtained through legitimate means and must follow the laws and network-use rules where you are. Subscription details such as plan, traffic multiplier, expiry, and server availability depend on the provider. A successful launch only confirms that the app is installed; verify usability with a connection test and real-world access.
Open-source licenses: code access and service boundaries
V2Ray, Xray, and related clients are available as open-source software. The V2Ray and Xray cores use MPL 2.0; the three graphical client projects covered here use GPL 3.0-family licenses. See each project’s license files for the applicable terms and additional notices. Open-source licenses set conditions for using, modifying, and distributing code. They don’t replace a server provider’s terms of service or endorse every configuration source.
For everyday use, understanding permissions and traffic flows matters most. The system proxy tells some apps to use a local proxy port; TUN handles a broader range of network traffic; allowing LAN connections may let other devices on the same network access your local proxy. Before enabling a feature, be clear about what you need it to do. In particular, don’t expose the listening interface more broadly than necessary if you’re unsure about your network boundaries.
Subscription URLs may contain account identifiers or access credentials, and client configurations may include server passwords and user IDs. When reporting an issue, share redacted log excerpts, error names, and the steps you took—not your entire configuration directory. Keep backups secure, too. Open-source code makes it easier to understand how an app works, but protecting your information in daily use still depends on careful configuration and sharing.
Updates and testing: change one thing at a time
Client updates, core updates, and subscription updates are three different things. A client update mainly affects the interface and configuration management; a core update may change protocol implementation or configuration support; a subscription update fetches server profiles from the source again. Don’t apply all three when troubleshooting. Note the current behavior and recent changes first, then update the component relevant to the problem so you can tell whether it helped.
Back up your current configuration before updating, and note your subscription groups, custom routing, and DNS settings. Afterward, check that the app starts, test a connection that used to work, then verify any special rules. Use the current interface if menu names or option locations have changed; don’t repeatedly overwrite your configuration to match an older guide. The download page helps you choose an OS and installer, the quick-start guide covers initial setup, and the advanced guide explains how settings work together.
Start testing with a small scope: select one server, confirm the core is running, then test browser access. If the browser works but another app doesn’t, check that app’s proxy settings. If no apps can connect, check the server connection and logs first. If only certain domains fail, check routing matches and DNS. A displayed latency doesn’t guarantee that every protocol or destination works. Treat real connection tests as one part of the picture and confirm with actual access.
This site brings together download links and technical guides. The brand name identifies the site and doesn’t change ownership of the open-source projects; refer to each project’s documentation for its features and license. See About This Site for our purpose and editorial principles.
Recent articles
Connection checks and practical routing
Verify your configuration first, then work through server selection and rule priority. Focus on the issue at hand; there’s no need to change everything at once.
A complete walkthrough for your first connection after importing a subscription: choose a working server, use a real connection test to rule out false positives, then check your IP and test access to confirm the proxy is working.
Learn how the domain, full, regexp, geosite, and geoip match prefixes work, how rules are evaluated from top to bottom, and how to resolve common conflicts.
Compare subscription servers across four factors: what latency tells you, how traffic multipliers affect usage, which locations suit your needs, and the trade-offs between VMess, VLESS, and Trojan.