Clients, cores, and configuration guides
Choose a client page for your operating system, with complete workflows for subscription import, protocol selection, and routing setup.
Choose by operating system
The homepage only routes you to the right platform. Package type, system architecture, and client differences are explained on each client page, helping you avoid choosing the wrong software before confirming your device details.
Desktop platforms
Windows users can use v2rayN and choose between its newer cross-platform desktop interface and the classic WPF layout. The download page explains the requirements, first-launch location, system proxy entry, and common runtime dependencies for each version. Users familiar with the classic interface can keep using it; new installations can review the desktop guide before choosing.
Desktop platforms
The v2rayN desktop client for macOS requires checking the processor architecture before installation. Apple Silicon and Intel use different packages, so the system name alone is not enough. The client page shows where to check the chip, how to choose a package, what to expect during first-run authorization, and how to perform basic checks after enabling the system proxy.
Mobile platforms
On Android, choose between v2rayNG and v2flyNG based on the core family. v2rayNG uses the Xray core and suits configurations that require Xray protocols and transport features; v2flyNG uses the V2Fly core for existing V2Fly configurations. Most recent devices should start with the arm64 package; if the architecture is unknown, consult the universal package guide.
Desktop platforms
On Linux desktops, use v2rayN and choose a deb or rpm package for your distribution, then confirm whether the architecture is x64 or arm64. After installation, check the client process, desktop proxy settings, and whether applications read the system proxy. The platform guide presents package selection and runtime checks as consecutive steps.
Client configuration workflow
The four setting groups correspond to different stages of real-world use. Select a tab to see its goal, operation order, and interface details.
Rule priority
Routing settings determine which outbound handles each connection. New users can start with a client preset, such as selecting “Bypass mainland China” and saving it, then return to the main screen to confirm the current routing mode. For finer control, add rules using domain, ip, geosite, and geoip conditions, keeping in mind that rules are usually matched in the order shown in the interface.
This is separate from the system proxy switch: the system proxy makes applications hand connections to the client, while routing rules determine how the client handles those connections. Keeping the two concepts separate avoids switching routing only to find that the browser never entered the proxy flow, or finding that a specific domain still follows an old rule even though the system proxy is enabled.
View protocol and routing references →Configuration management
Put a subscription URL in its own group instead of adding it directly as a single server address. The group stores the note, update URL, and auto-update interval. After an update, the client parses recognized configurations and adds them to the appropriate lists. Create separate groups for different sources so it is easier to identify where a configuration came from when disabling, updating, or troubleshooting it.
If the list is empty after an update, first check which group is currently displayed. Then confirm that the URL is complete, the update succeeded, and the subscription uses a format the client can recognize. Do not repeatedly change the protocol, routing, and system proxy in the same step; first make sure the group contains a configuration, then choose a server and connection mode.
View the subscription import steps →Connection handoff
Selecting a server does not mean desktop applications are already using that connection. Desktop clients usually also need the system proxy set to “Configure system proxy automatically,” so browsers and applications that read system proxy settings hand requests to the client. After switching it, reopen the application you are checking and confirm that it is not forcing a different proxy configuration.
Some programs do not read the system proxy. For those applications, check their network settings first instead of repeatedly changing servers. Connection checks should also proceed in layers: confirm that the client is running with a valid configuration selected, then check the system proxy, and finally verify that the target application inherits the system settings. This order makes problems easier to isolate than changing several switches at once.
View connection troubleshooting →Compatibility
The client is the graphical control layer; the core handles protocol parsing, transport establishment, and routing. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. On desktop, v2rayN’s settings interface clearly shows the current Core type. Confirm protocol and core capabilities before importing a configuration to reduce cases where fields exist but cannot be processed as expected at runtime.
VMess, VLESS, Trojan, Shadowsocks, and REALITY involve different protocol or transport combinations, so their names alone are not enough for comparison. The actual choice also depends on the server configuration, client version, core family, and subscription format. The protocol reference breaks down these differences by authentication, resource use, mobile performance, and configuration compatibility, making it useful before adding a server type.
View core and protocol comparisons →Quick start
Follow a fixed order for the first configuration. Complete each step before moving to the next so you can verify the subscription, client state, and application handoff separately.
Open the client’s subscription group manager, add a group, and enter an identifiable note and the complete subscription URL. Save it, run Update subscription, wait for parsing to finish, and return to the server list to check whether a usable configuration appears under the group. If the list is empty, first check the active group filter, the URL copied, and the update message; do not immediately change routing or the system proxy.
A subscription is a way to distribute a set of configurations. It is neither a client nor a protocol. The client reads only the fields and protocol combinations it supports. Create separate groups for different subscription sources and use clear notes; when an update produces unexpected differences, you can isolate one source instead of inspecting a mixed list item by item.
Once a configuration appears in the server list, select the one you want and open routing settings to confirm the handling mode. For typical use, start with a preset, then add custom domain, ip, geosite, or geoip conditions after understanding the connection path. Rule order affects matching results, so record each rule’s purpose and avoid overlapping broad conditions.
The protocol type must match the configuration. When adding a server manually, choose the actual VMess, VLESS, Trojan, or Shadowsocks entry and fill in the address, port, authentication details, and transport parameters one by one. Subscription imports usually include these fields; unless you clearly understand them, do not rewrite transport options just to experiment.
After selecting a configuration in the desktop client, set the system proxy to Configure system proxy automatically, then reopen the browser or application used for testing. On Android, complete authorization in the system connection confirmation screen and keep the client connected. The important check is not the button color, but whether the target application actually reads the current connection path.
When a connection fails, check each layer in this order: “subscription updated—configuration selected—core compatible—system proxy active—application reading system settings.” Logs help confirm problems during protocol handshakes, domain resolution, and routing matches, but complete the basic checks first. Change one variable at a time so you can tell whether an adjustment actually helped.
Open-source ecosystem
Clients, cores, protocols, and subscriptions each have different responsibilities. Understanding these layers is more useful for choosing and troubleshooting than memorizing software names.
Project V established an open-source technology ecosystem centered on proxy protocols, transport methods, routing rules, and configuration structures. Early users often used V2Ray to refer to the project, the core, and the whole toolset at once, but these concepts need to be separated in practice: the graphical client manages configuration and system integration, the core handles connections, protocols define communication methods, and subscriptions distribute a set of configurations.
V2Fly continues V2Ray’s community-maintained path, retaining widely used configuration models and protocol capabilities. Xray developed an independent core family within a related configuration ecosystem and expanded capabilities such as VLESS and REALITY. The two share many concepts, but that does not mean every field, transport combination, or new feature is interchangeable. The Core type shown by the client is important when judging configuration compatibility.
Choose a configuration based on the server’s actual parameters, not on a name selected in advance. If a subscription provides a VLESS and REALITY combination, use a core and client that recognize the corresponding fields. If an existing setup is based on V2Fly, confirm that the subscription format and protocol fields are within that core’s supported range. The protocol reference further compares authentication design, connection establishment, resource use, and mobile requirements.
Desktop clients
v2rayN provides graphical access to server lists, subscription groups, routing settings, the system proxy, and logs across Windows, macOS, and Linux desktops. Desktop packages vary by operating system, processor architecture, and interface type, so confirm the device details before downloading.
Android · Xray
v2rayNG is an Android graphical client built on the Xray core, suitable for configurations containing protocols and transport fields from the Xray ecosystem. Subscriptions, routing, and connection switches are managed in the mobile interface, and package selection also depends on the device architecture.
Android · V2Fly
v2flyNG targets V2Fly-based configurations and offers another core-family option for Android. Its main difference from v2rayNG is not the interface color, but the underlying core, protocol capabilities, and configuration compatibility range.
The three clients and their related cores belong to an open-source software ecosystem. Software behavior, configuration structures, and feature changes can be reviewed through public project materials and community documentation. Open source provides an inspectable, discussable, and reproducible engineering foundation; it does not make configuration decisions for the user. You still need to confirm that the download platform, core type, subscription source, and server parameters match.
Client updates may include interface changes, core integration, protocol capability changes, and fixes. When migrating across a substantial update, record the subscription groups, routing rules, and system proxy mode first, then read the download page and relevant technical notes. Subscription URLs can be imported again, but local custom rules, manually added servers, and application-level network settings must be checked separately.
Xray Core Hub organizes material around client selection and graphical workflows: the download page covers platforms and packages, the user guide covers the sequence from subscription to connection, the protocol reference covers core and protocol compatibility, and the help center answers installation, configuration, and troubleshooting questions. The documentation does not replace the client project’s own feature descriptions; when details differ, follow the actual interface and current configuration fields.
Technical notes
These articles focus on specific settings, adding distribution differences, rule combinations, and side-by-side client comparisons that do not fit in the user guides.
Starting from the v2rayN routing settings panel, this guide explains what presets such as “Bypass mainland China” actually cover, compares allowlist and denylist approaches, and provides workflows for combining rules, checking priority, and verifying applications.
Read the article →For Ubuntu, Debian, and Fedora desktop users, this guide covers deb and rpm package selection, system dependencies, per-user autostart, and the correct order for checking system proxy settings in a desktop environment.
Read the article →Compare the three clients by platform coverage, core family, protocol support, subscription management, and routing capabilities. Learn when to choose v2rayN on desktop and how to choose between Xray- and V2Fly-based configurations on Android.
Read the article →