From choosing an open-source client to subscription management and proxy routing, find practical guidance organized around the setup process.
VMess
VLESS
Trojan
REALITY
Rules · Groups · Modes
Three ways to manage V2Ray configuration
Connecting to a server is just the start. Handle traffic routing, subscription sources, and system integration separately to make your setup easier to review.
Routing determines where a request goes; it does not send every connection through the same exit. The rules shown here send requests for matching domains to direct. Define that tag in the outbound configuration first, and make sure the required rule data is available. Before applying a rule, check which core the client uses, then place specific rules ahead of broader ones. Compared with switching everything to global mode, domain-based routing helps preserve access to local services and makes misrouted traffic easier to identify in logs. This is a rule snippet; see the configuration reference for the complete structure.
Subscription groups
Everyday use
Update each source separately
Filter to keep the regions you need
Temporary testing
Keep separate from everyday servers
Set as default after testing
Subscription sources and server lists
When multiple subscriptions share one list, the problem is often unclear sources and duplicate names—not a lack of servers. Create groups by source, then set update options and filters to keep the list organized and maintainable. Subscription updates are more convenient than importing servers one by one, but remote changes can also alter server names and settings. After an update, check the selected server and its group; a filtered-out server is not necessarily a connection failure. Subscription URLs often contain credentials, so hide the full address in screenshots and troubleshooting notes.
Desktop connection methods
System proxySet as needed
TUN modeEnable as needed
Routing rulesConfigure separately
Capture traffic and choose where it goes
System proxy and TUN determine how app traffic reaches the client; routing rules determine where that traffic goes next. They are separate controls. For ordinary browser access, start by testing the system proxy. Consider TUN only if an app ignores system proxy settings and you need to route its traffic. Enabling several connection methods at once makes port, permission, and DNS conflicts harder to track, so turn them on one at a time. Android typically connects through the system VPN interface; check which apps are included. Menu names vary between clients, so verify what each option does.
Separate connection issues from routing issues
If no sites load, first check whether the core has started, a server is selected, and the local port is listening. If only one domain has a problem, check rule order, DNS results, and the destination outbound. Copying a complete routing setup can introduce several variables at once. Keep a working baseline and change one set of rules at a time to identify what caused the difference.
Compare GUI settings with JSON
A graphical client translates interface options into core configuration, but a UI label such as “direct” may not match the tag used in the configuration. When reading an example, focus on how the fields relate rather than memorizing a menu location. Custom configuration may also override some GUI settings. Before troubleshooting, confirm which configuration is running, then compare its inbounds, outbounds, and routing with the complete configuration reference.
Choose a package for your OS, then check the architecture
V2Ray client downloads
v2rayN is the main desktop option. For Android, start with v2rayNG; consider v2flyNG if you need the V2Fly core. Find the available packages on the download page.
The desktop edition uses a cross-platform interface, while the WPF edition retains the classic UI. They suit different interface preferences; neither is inherently faster to connect. Before installing, check the system and runtime requirements. Choose one edition and set up a basic configuration first to avoid two clients competing for the same listening port.
Place portable apps in a fixed location where they have write permission; follow the prompts for installer packages. After the first launch, check that the core loads before importing a subscription. If you see a port-in-use error, identify the process using the port instead of reinstalling repeatedly.
Check your chip in About This Mac: choose arm64 for an Apple silicon device and x64 for an Intel Mac. Select the right architecture before choosing an installer format; file size alone is not a reliable guide. After installation, launch the app from a permanent location rather than running it from a temporary mounted volume.
The system proxy mainly affects apps that follow system settings. If a browser works but another app connects directly, check how that app handles proxies. When prompted to allow a network extension or permission, review what it is for and enable it only if needed.
v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Choose based on the server settings and protocol requirements. Most recent phones use arm64; if you're unsure which architecture your device has, check its system information or the download page's universal package notes. Installing the app does not guarantee that every imported configuration is supported by its core.
On the first connection, Android asks you to authorize the system VPN. If the connection drops when the app moves to the background, check battery optimization, background restrictions, and per-app proxy settings. Adjust background limits for reliable use; there is no need to disable every battery-saving feature at once.
Check your distribution's package system before choosing deb or rpm, and verify the processor architecture: x64 and arm64 packages are not interchangeable. If the interface opens but networking does not work, check the core process, desktop proxy settings, and required permissions separately. An open window does not mean the connection is working.
Desktop environments may handle system proxy settings differently, and command-line apps often need proxy settings of their own. Test with an app known to support proxies first, then check other programs. This keeps troubleshooting focused.
The client runs your configuration; a subscription supplies server settings. You need to prepare each separately. After downloading the client, complete the first launch, then import your subscription URL through its subscription settings. If you do not know where the settings came from, do not add an unfamiliar subscription to your everyday group. Once servers appear in the list, select one and test access to a real website, using the logs to help assess the connection. A latency test compares response times under specific test conditions; it does not measure download speed or replace testing in an app.
If your setup is working, back up subscription groups, custom rules, and manually added servers before updating. Menu locations and default core settings may differ between client versions, so recheck the system proxy, routing mode, and selected server after upgrading. To start from scratch, follow the first-time setup and connection guide. For package formats and device architecture, check the download page.
“V2Ray” is often used as a catch-all term for a family of proxy tools. When choosing one, it is more useful to distinguish what the graphical client does from what the underlying core supports.
From configuration framework to graphical client
Project V is built around configuration modules for inbounds, outbounds, routing, and transport. Inbounds receive app requests, routing rules determine where they go, and outbounds handle forwarding. This structure can express complex network needs, but reading JSON directly can be challenging for beginners. Graphical clients make importing, grouping, switching, and editing settings easier by bringing common tasks into an interface and passing the results to the core to run.
That is why having an option in the interface does not necessarily mean the current configuration can use that feature. The same client may run different cores, and custom configuration may change its default behavior. When reviewing a client, first check the platform, core, and configuration source. Then consider whether subscription management is convenient and routing rules are easy to maintain. Comparing appearance alone can miss the compatibility requirements that matter in practice.
V2Fly and Xray: how they relate
V2Fly continues the V2Ray community ecosystem, while Xray is a separate core branch developed from related code. They share some configuration concepts and protocol foundations, but their later features, defaults, and support differ. If a server provides VLESS, Trojan, or other settings, also check the transport, security layer, and required extensions. A matching protocol name alone does not guarantee compatibility.
For example, REALITY is a security-layer configuration that requires core support; it should not be treated as a protocol that is interchangeable with everything else. If you have a working connection, note its settings before switching cores. Test basic access after the switch, then restore custom routing. If configuration parsing fails, start with the error field and the core's supported features instead of cycling through clients at random.
Open-source status of the three clients
v2rayN, v2rayNG, and v2flyNG are all maintained as open-source projects. v2rayN focuses on desktop server, subscription, and routing management. v2rayNG targets Android and uses the Xray core; v2flyNG is an alternative using the V2Fly core. Open source means the implementation and license terms can be examined and discussed. It does not mean every server configuration will work, or that server access is included with the client.
The three clients and the cores they use belong to different layers of the software stack. UI issues, core parsing errors, and remote server problems need to be diagnosed separately. These reviews focus on the conditions and settings involved rather than assigning a single score without context. Most users are better off choosing one client that meets their device and protocol needs, then considering a migration only after the setup is stable.
Open-source licenses and usage
Projects related to the V2Ray core use open-source licenses such as MPL 2.0; each client project has its own license terms. Check the license included with the specific project you use. Do not assume that a core's license applies to the entire toolchain. Everyday use differs from modifying or redistributing code. Before publishing a modified version, confirm requirements for retaining notices, documenting changes, and providing source code where applicable.
This site provides guidance on choosing clients and reading configurations; it does not operate subscription or server services. Clients may be free to use, but the costs, privacy policies, and availability of remote services depend on their providers. Configuration files may contain server addresses, user IDs, and subscription credentials. Remove this information before sharing logs, screenshots, or troubleshooting materials. Follow your organization's network-use policies when using work networks or managed devices.
Update cycles and review methods
Graphical clients, cores, and rule data can update on different schedules. A UI update may move menus or change how configurations are generated; a core update may affect supported settings; and a rule-data update may change domain routing results. If behavior changes after an update, note which layer changed and check what is currently running. Do not attribute every change to an “unstable server.” The homepage does not list a fixed set of maintained versions; find package information on the download page.
For useful before-and-after comparisons, keep the network, server, and test destination the same. Change one setting at a time, and note the error type and timestamp in the logs. Latency, throughput, and connection success measure different things, so a single test should not be presented as a long-term performance result. Our articles explain repeatable ways to assess issues, connecting setup, subscriptions, routing, and troubleshooting in one workflow.
Break battery drain, subscription clutter, and slow speeds into issues you can check. Start by identifying the scope, then troubleshoot layer by layer across the system, client, and remote service.
Unusual battery drain on mobile may be caused by repeated background wakeups, conflicts with battery optimization, or per-app settings. Check system and client options one at a time. Distinguish power use from continuous traffic from abnormal background activity, then decide how to balance keeping the app running with saving battery.
When managing multiple subscriptions, create groups by source first, then use keyword filters to keep the servers you need. Review sorting and update settings, and check that the selected server is still in the expected group. This helps avoid confusion caused by duplicates, name changes, and subscription updates.
Break speed issues into three layers: server and protocol transport, network path, and local routing and DNS. Keep the test destination consistent and rule things out one at a time before adjusting options such as Mux. Changing servers, rules, and DNS settings all at once makes it hard to tell what helped.
If the logs show a clear error, keep the original message and identify when it occurred. If only one app has a problem, first check whether its traffic is routed through the proxy. These notes are organized by symptom to help you find the next step without reconfiguring everything.