A focused guide to three open-source clients, four platform downloads, and Chinese configuration docs, with clear steps from installation to subscription imports, traffic routing, and log-based troubleshooting.
A client’s core value is not a pile of switches. It is a clear, reviewable workflow for organizing server sources, connection rules, and runtime status.
Subscription groups keep servers from different sources separate. Create a group before adding its link, then set the group’s update source; future refreshes replace only that source instead of mixing every configuration into one list. Keep manually added nodes in a separate group so subscription updates do not affect temporary profiles.
v2rayN’s desktop list is built for bulk filtering, sorting, and switching, while Android clients condense group access for mobile screens. Both organize information around “source → profile → current selection.” When changing devices, re-import the same subscription instead of entering protocol parameters again.
View the subscription import steps →Routing rules answer one question: “Which path should this type of connection use?” Common conditions include domains, IP addresses, ports, and network types. Rules are matched from top to bottom, so specific entries usually come first and fallback rules go last. After editing, reapply the configuration and verify the result with an actual request.
Preset modes are a quick starting point; custom rules suit users who need predictable traffic routing. Unlike tools with a single proxy switch, v2rayN clearly shows match conditions and outbound targets. When you need to take over more app traffic, combine system proxy settings or TUN mode with the appropriate scope.
Read the practical routing guide →The log window records core startup, configuration loading, DNS resolution, and connection results. It is the most direct place to start when a client says it is connected but sites do not open. Check that the configuration loaded successfully, then review the target domain’s resolution and route, and finally confirm that the outbound connection was established.
Info level is enough for everyday use; raise verbosity temporarily only when more context is needed. Read logs alongside the action in progress: watch resolution and writes during subscription updates, configuration reloads when switching servers, and virtual network adapter, DNS, and route initialization when enabling TUN mode.
View troubleshooting answers →Subscriptions, QR codes, and manual profiles are all import methods. Name groups after their source or purpose to make future updates, filtering, and migration clearer. A subscription link is not a protocol; one subscription can contain VLESS, VMess, or Trojan profiles.
System proxy is suitable for ordinary apps that follow system settings. TUN mode covers more traffic but also requires attention to DNS, routing, and the virtual network adapter. There is no need to enable both; choose based on the apps involved and the troubleshooting cost.
A connect button only means the client has started applying the configuration. Confirm the actual state through core startup messages, matched routes, and access results. When troubleshooting, change one category of setting at a time and keep before-and-after logs; this is usually clearer than changing several switches at once.
v2rayN is the main desktop choice, while Android users can choose v2rayNG or v2flyNG based on core preference. Each entry opens the matching platform tab on the download page.
Designed for everyday desktop use, it manages multiple subscription groups, bulk server filtering, system proxy switching, and dedicated logs. The download page offers both the new desktop interface and the classic WPF interface: the former has a more consistent layout, while the latter preserves familiar Windows workflows.
For first-time setup, import a subscription, select a profile, and then enable the system proxy. To cover more app traffic, configure TUN mode after understanding how DNS and routing interact.
Download for WindowsOn macOS, v2rayN uses a cross-platform desktop interface with subscription management, server lists, routing modes, and logs arranged similarly to other desktop systems. Check the device chip before downloading; the download page provides separate entries for Apple Silicon and Intel.
If the system requests network-related permissions after installation, grant them according to the mode you use. Browsers and apps that follow system settings can start with the system proxy; there is no need to change every advanced network option immediately.
Download for macOSv2rayNG is the usual Android choice, with the Xray core and support for common protocol and transport combinations. Choose v2flyNG when you need the V2Fly core. Both import profiles from subscription links, clipboard content, or QR codes, with interfaces suited to touchscreens.
Most newer phones can use an arm64 package; if the processor architecture is uncertain, choose the universal package on the download page. After importing, check the profile name and protocol before starting the connection and reviewing the system status.
Download for AndroidOn Linux desktops, v2rayN can manage subscriptions, routing, and the system proxy. The download page offers deb and rpm packages for common distributions and separates x64 from arm64 builds. Confirm the system’s package format and processor architecture before choosing a file.
If the system proxy does not affect the target app after installation, first check whether the app reads the desktop environment’s proxy settings. Apps that manage network connections independently may need an in-app proxy or TUN mode instead.
Download for LinuxClients, cores, and protocols belong to different layers. Understanding each role is more useful for choosing and troubleshooting than memorizing a software name.
Project V developed an open-source ecosystem around proxy protocols, transports, routing capabilities, and configuration formats. v2rayN, v2rayNG, and v2flyNG are GUI clients: they provide subscription imports, server selection, system proxy controls, routing rules, and log views. The core usually handles protocol connections, transport layers, and routing logic.
Separating the client from the core explains many common behaviors. The same subscription may be organized differently after import into different clients; the same protocol may expose different transport options and parameter names with different core combinations. Usability depends not only on a GUI switch, but also on compatible protocol fields, core capabilities, DNS settings, and routing rules.
V2Fly continues V2Ray’s core capabilities with ongoing work on protocol implementations, routing, DNS, and transport components. Xray remains compatible with common configuration approaches while extending protocol and transport support. They are not a simple ranking of three clients, but core choices following different maintenance paths and feature sets.
v2rayN can manage these core features in a desktop environment; v2rayNG primarily uses the Xray core on Android, while v2flyNG follows the V2Fly core path. Most users do not need to edit a complete core configuration manually. Choose a client compatible with the subscription, then adjust advanced DNS, outbound chains, or routing one item at a time when needed.
All three clients and the related cores are maintained as open source. Here, open source means community developers can read and discuss implementation logic, configuration formats, and changes, while different clients can build compatibility around shared protocols. It does not replace judgment about configuration sources, network permissions, or the runtime environment, but it keeps technical issues describable and reproducible.
Client updates usually cover interface changes, core capabilities, protocol compatibility, and bug fixes. Because GUI clients and cores may follow different release schedules, the download page lists currently available entry points, while guides favor stable feature names and workflows. If the interface moves, relocate functions by concepts such as “subscription groups, server list, system proxy, routing, and logs” rather than relying on one fixed screenshot.
For Windows, macOS, and Linux desktops, v2rayN is the main choice because it offers comprehensive list management, route editing, and log views for maintaining multiple subscriptions or manual profiles. For everyday Android use, choose v2rayNG. If a profile explicitly requires the V2Fly core or you want to stay on that core path, choose v2flyNG.
Do not choose a client by protocol name alone. Compatibility for VMess, VLESS, Trojan, and Shadowsocks also depends on the transport layer, TLS, REALITY, server parameters, and core capabilities. The safest approach is to confirm the subscription’s configuration format, choose a client on the target platform that supports that combination, and verify through logs that the profile was recognized correctly.
Import the subscription first and confirm that the server list appears correctly. Select a profile and connect using the default routing mode. Once the basic connection works, adjust bypass rules, custom domains, or TUN mode as needed. This keeps subscription-format issues separate from routing issues.
System proxy is simple and suits browsers and apps that follow system network settings. TUN mode covers more traffic and involves the virtual network adapter, DNS, and system routes. Start with the system proxy for everyday desktop use; enable TUN only when an app ignores system settings or you need broader coverage, after reviewing the advanced guide.
First confirm that the correct group was updated, then check whether name, protocol, or keyword filters are hiding the entry. If the list still has not changed, review the update logs to confirm that the subscription content parsed successfully. Avoid deleting groups and changing routes at the same time, or the source of the problem may become unclear.
Check in order whether the app uses the system proxy, which routing rule matches the current domain, whether DNS returns a usable result, and whether the logs show an outbound connection. This sequence distinguishes an app that is not using the proxy, a misrouted request, a resolution problem, and a failed remote connection.
From interface entry points and configuration sync to protocol differences, each article focuses on one question so you can find the relevant steps quickly during setup.
Explains how the two protocols differ in encryption responsibilities, performance overhead, and transport pairings, then highlights the fields that matter when importing a node.
Read the full articleIdentify the main window’s common sections, learn what each server-list column means, and find the entry points for subscriptions, logs, and settings.
Read the full articleCompares unified subscriptions, QR-based transfer of individual profiles, and file exports, explaining which device counts and maintenance scenarios suit each method.
Read the full article