Open-source clients · Setup guides
Use v2rayN on desktop and v2rayNG on Android. Follow the steps to configure subscriptions, routing, and DNS, then check that your apps are using the proxy.
PROJECT V / V2FLY / XRAY
Start by distinguishing the core from the client. The core handles protocols, connections, and routing; the graphical client manages subscriptions, settings, and processes. Similar client names don’t mean their cores have identical features or configuration fields.
Project V is a good starting point for understanding the technology behind V2Ray. V2Ray divides inbounds, outbounds, routing, and transports into composable configuration modules. A local listener can accept requests from apps and route them to different outbounds based on rules. This modular design also explains why clients configure the system proxy, servers, and routing separately instead of offering a single connection toggle.
Explore the project →V2Fly is a community project that continues to maintain V2Ray, with a core implementation that follows the same modular configuration approach. v2flyNG offers an Android alternative built around this core family. If your configuration depends on a specific feature, check protocol, transport, and field support before choosing a client. Being able to import a subscription doesn’t mean the current core can run every entry.
Understand cores and clients →Xray grew out of the V2Ray technology ecosystem and follows its own development path for protocols and transports. v2rayNG uses the Xray core, and v2rayN is also commonly used to manage Xray configurations. VLESS, Trojan, and REALITY refer to different configuration concepts and are not interchangeable. A setup works only when the server requirements, client fields, and core capabilities are compatible.
Explore advanced configuration →v2rayN is designed for desktop use, bringing server lists, subscription groups, system proxy settings, and routing together in one interface. v2rayNG is for Android and uses the system VPN interface to handle app traffic, with options such as per-app proxying. v2flyNG also targets Android and suits configurations that need a V2Fly core. All three have open-source projects behind them and are free to use. Server addresses and subscription details must be provided separately; installing a client does not create a working service.
Open-source licenses define the terms for using, modifying, and distributing code; check each component’s license separately. Graphical interfaces, proxy cores, and routing resources may update independently, so updating the client, subscription, and rule data are three separate tasks. Back up subscription groups, custom routes, and DNS settings before upgrading. Afterward, test your existing configuration before enabling new features one at a time. When something goes wrong, note the error location and relevant settings; this usually narrows down the cause faster than repeated reinstalls.
This site organizes setup guides by client choice, installation, and configuration task. Project names describe technical relationships; the site brand does not imply official maintenance by Project V, V2Fly, or Xray. Interface examples illustrate settings layouts; menu names may vary by client version.
Check your operating system and processor architecture before choosing a package. Start with v2rayN for desktop and v2rayNG for Android; consider v2flyNG if you need a V2Fly core. The download page lists download options, compatibility details, and pre-installation checks.
Use v2rayN. The desktop edition offers a cross-platform interface, while the WPF edition retains the classic desktop interface. Check your architecture on the system About page, then choose a package as described on the download page. The two interface options don’t mean you need separate servers; back up your configuration before migrating.
Go to DownloadsUse v2rayN. Check your chip under About This Mac and choose the matching package for Apple Silicon or Intel. Follow the system prompts to grant permissions on first launch, then check your network proxy settings so another proxy tool doesn’t override them.
Go to DownloadsUse v2rayNG by default, with v2flyNG as an alternative core. Most current devices use arm64; if you’re unsure, check the universal package details. On first connection, allow the system VPN request. Before enabling per-app proxying, verify that the default connection works.
Go to DownloadsUse v2rayN. Choose deb for Debian- and Ubuntu-based distributions, or rpm for Fedora and similar distributions; also confirm whether you need x64 or arm64. The desktop system proxy and terminal environment variables work separately, so test in the apps you actually use after installation.
Go to DownloadsAfter installation, import an existing subscription or server configuration, then select an available entry. A subscription provides a way to update a set of configurations; the client only reads and manages them. Treat subscription URLs as private information—don’t include them in public screenshots or share them with people who don’t need access. When restoring settings, first determine whether you need to restore subscription content or client preferences; they require different steps.
For your first setup, start with the system proxy or the default VPN mode. Once you’ve verified your browser and common apps, configure routing, LAN sharing, or TUN. Change one setting at a time and keep a working baseline so you have a clear point of comparison when troubleshooting.
Browse all clients →Check settings in this order: configuration source → traffic destination → app scope → DNS resolution. The settings examples below stay expanded for easy comparison; use the task tabs to see what to check at each step.
First, confirm the configuration loaded. After updating, check the active group and server list. An empty list isn’t necessarily a network connection problem. If a subscription update fails, note the error type in the log before checking the URL and update method.
Compare with subscription group settings ↓Next, check which outbound handles the request. Rules are evaluated in order, so a broad rule may match first. Note the current routing mode before making changes, and test with the same destination to avoid mistaking a server change for a rule change.
Compare with routing rules ↓Distinguish the system proxy from VPN traffic coverage. The system proxy only works with apps that read its settings; Android per-app proxying also depends on the app list mode. Before testing, check what it means for a target app to be on the list—don’t just look at whether the toggle is on.
Compare with app scope settings ↓Finally, check the DNS resolution path. The DNS server must be reachable before connections can succeed. Start with a known-working basic DNS setup, then test routing and FakeDNS to avoid changing multiple variables at once.
Compare with DNS fields ↓In Subscription Group Settings, create a separate group for each source, enter the full subscription URL, and then update it. Groups organize sources; they don’t change a server’s protocol or availability. After updating, confirm which group is selected, then filter the list by name. If it’s empty, check the filter before assuming the subscription failed. Unlike importing individual share links, subscriptions can keep configurations up to date, but updates may overwrite manual changes. Keep a separate record of important edits.
Manage subscription groups and multiple subscriptions →Filter the current group by nameStart with a routing preset that fits your needs, then add a few custom rules. Domain and IP matches are different conditions, and rule order affects the outcome. In this example, LAN addresses go to the direct outbound, while the sample domain goes through the proxy outbound. These snippets illustrate matching syntax; they aren’t complete, ready-to-run configurations. Routing by destination preserves LAN access better than simply switching global mode, but requires understanding how DNS relates to destination matching. Save each change and retest with the same destination.
Explore routing rules and outbound matching →domain:example.comgeosite:privateip:192.168.0.0/16On first connection, v2rayNG requests system VPN permission. Allow it to route traffic through the virtual network interface. To handle only selected apps, open Per-App Proxy and check whether the current mode includes listed apps or bypasses them; the same checkbox means different things in each mode. Compared with the desktop system proxy, VPN mode covers more traffic, but actual behavior still depends on the app list, routing, and system restrictions. After changing the list, reconnect as prompted and check background battery restrictions so a paused process isn’t mistaken for a dropped server connection.
See Android connection and verification steps →If a domain won’t open but its IP address works, check the DNS logs before replacing all your servers. Confirm whether DNS requests go through the local network or the proxy, then check that the upstream resolver is reachable. Encrypted DNS addresses may themselves need to be resolved, so a poor setup can create a startup dependency. Per-domain DNS routing offers more control than simply changing the resolver, but it needs to align with your routing rules. FakeDNS returns mapped addresses; read the related setup guidance before enabling it. When troubleshooting, start with a simple, verifiable resolution path.
Explore DNS optimization and FakeDNS →223.5.5.5https://dns.example.com/dns-queryUseIPv4First, confirm that the core process is running. Then check the local listening port, followed by the system proxy or VPN status. Finally, make a request from the target app. A “Connected” status only shows that the connection process started; it doesn’t verify traffic at the app level. If a browser works but the terminal doesn’t, check browser extensions, terminal proxy environment variables, and app-specific settings separately. Logs can help pinpoint whether an error occurred during DNS resolution, connection setup, or protocol handshake. Before sharing logs, remove subscription URLs, personal information, and server credentials.
If only one site is affected, keep the current client and server, test other destinations, then check which routing rule matches the affected site. If all apps fail, check the local network and core process first. Troubleshooting by scope helps preserve useful clues instead of changing subscription, DNS, and routing settings back and forth. See the user guide for the basic setup, or visit the Help Center to find fixes by symptom.
Read the article that matches your symptoms before changing configuration. The three articles below are sorted by publication date, newest first, and cover app proxy scope, configuration file structure, and desktop installation. For virtual network adapters or LAN sharing, browse the article list for related topics.
Troubleshoot along two paths: in the browser, check whether extensions or proxy settings override the system settings; in the terminal, set the http_proxy environment variable and verify each step with commands. First identify which settings layer the app reads, then adjust the proxy entry point.
Read the troubleshooting steps →Using a minimal working configuration, this guide explains each field and how they reference one another, covering log, inbounds, outbounds, routing, and dns in order. Use it as a reference when moving from graphical settings to reading core configuration files.
Read the config reference →Step-by-step installation commands for Debian/Ubuntu and Fedora-based distributions, with dependencies, desktop launchers, startup configuration, and common permission errors. Get it running manually before setting it to launch automatically at login.
Read the installation guide →