Start by choosing a client, then work through subscription import, routing, and connection troubleshooting—a clear path through the key desktop and Android settings.
Use v2rayN across desktop platforms; on Android, choose between v2rayNG and v2flyNG. The download page separates packages by CPU architecture and installer format. Select your platform first to avoid using the wrong file later.
Windows users can choose v2rayN’s modern desktop interface or classic WPF interface. The former feels closer to other desktop platforms, while the latter suits users familiar with traditional menus and tray controls. After installation, import a subscription first, then configure the system proxy or enable TUN if needed.
On macOS, use the v2rayN desktop client and confirm whether your device has an Apple Silicon or Intel processor before downloading. Architecture affects only the package you choose, not subscription formats or routing settings. On first launch, confirm the required system permissions, import a subscription, and check whether your browser follows the system proxy.
On Android, v2rayNG is the usual choice, with a kernel path and interface suited to common subscription setups; choose v2flyNG when you need the V2Fly kernel. Most newer devices use the arm64 package. If you cannot confirm the architecture, use the universal package. Before connecting, allow the client to create a local network connection.
On Linux, use v2rayN and choose deb or rpm according to your distribution, then select x64 or arm64 for the device architecture. If the GUI starts but application traffic does not reach the client, check the desktop proxy settings, terminal environment variables, and permissions required by TUN separately.
A connected status only shows that the core process is running. To verify the configuration, also check subscription content, the active server, how traffic is intercepted, routing matches, and runtime logs. The four topics below cover the most common configuration chain.
First confirm the subscription URL and group, then update the server list locally.
Rules are matched in order; the first matching rule determines the request’s outbound route.
Use the system proxy for basic verification first, then decide whether to enable TUN based on the apps you need to cover.
The status bar shows the result; the runtime log records where a connection failed.
For a first setup, keep one clearly working server and verify the connection through the simplest system-proxy configuration. Once browser requests are confirmed to pass through the client, add routing rules, DNS policies, and TUN settings. Changing the subscription, kernel, routing, and interception mode all at once makes the cause of a problem difficult to isolate.
Change only one related group of options at a time and record what changes. After switching servers, observe only the connection result; after adjusting routing, check matches and outbound handling; after enabling TUN, focus on permissions and DNS. This extra confirmation step greatly reduces time wasted on reinstalling or changing settings without a clear direction.
Here is a streamlined path through the full guide for users who already have a subscription URL. Each step has a clear checkpoint: the client starts, the server list updates, and real requests pass through the proxy. Move on only after the checkpoint passes.
In the download hub, switch to your operating system first. Windows users can choose the desktop or classic WPF edition; macOS packages are selected by processor; Android users can choose v2rayNG or v2flyNG by kernel path; Linux users should select a file based on their distribution’s package system and CPU architecture. After installation, launch the client and confirm that the main interface, tray menu, or connection permissions work normally.
If the system blocks the first launch, use its application-permission settings to confirm the file source and execution permissions. Do not try to bypass the issue by repeatedly extracting or reinstalling. On Linux, also confirm that desktop components and installation dependencies are complete. Do not change complex routing yet; the goal at this stage is simply to start the client reliably and reach its settings.
Add the URL under Subscription Groups, save it, and manually update that group once. A successful update should show server entries. If the group exists but the list is empty, check the URL first, then confirm that the update targeted the correct group. Once entries appear, choose one as the active server and verify it with a real connection test or by opening a page; do not rely only on a simple network-level response.
Subscription content may include multiple protocol and transport combinations, and the client invokes the corresponding kernel capabilities from the configuration. Most users do not need to rewrite every field manually, but server and client parameters must match. If the logs report authentication, address, or transport errors, return to the subscription source and verify its configuration instead of randomly switching local options.
On desktop, start by enabling the system proxy so browsers and apps that follow system settings use the client. On Android, confirm permission to create the system network connection. Then open a page that is not cached and watch the client log for the corresponding request. Only when the request appears on the correct outbound route is the path from the app through the system proxy to the client core confirmed.
If the browser works but command-line tools do not, they probably read proxy settings differently. If every request fails after enabling TUN, check permissions, DNS, and routing conflicts. Do not rely on the client’s connection icon alone; judge the result from actual access, log records, and routing matches together.
Client names, kernel names, and protocol names often appear together. Understanding their layers makes downloading and troubleshooting more straightforward: the graphical client handles interaction and configuration, the kernel handles network processing, and protocol and transport parameters describe communication between client and server.
Project V established a tool ecosystem around proxy protocols, routing capabilities, and network transports. As the projects evolved, V2Fly continued related V2Ray implementations and community maintenance, while Xray developed along the same technical lineage with different feature priorities and release cadence. The two kernel paths share many concepts, but protocol capabilities, configuration fields, and implementation status may not stay fully in sync.
v2rayN, v2rayNG, and v2flyNG are graphical clients, not the underlying kernels. They manage subscriptions, server lists, system proxies, routing, and log displays, then pass the prepared configuration to the kernel. A normal-looking interface therefore does not mean every kernel parameter is valid; when connections fail, check the client settings, active kernel, and server configuration together.
This layered structure also explains why the same subscription may look slightly different across clients. Each client reads configuration through its own interface model, while the kernel executes only what it supports. Choose a client based on your operating system, required kernel path, and usage habits—not by treating every product name as an interchangeable equivalent.
v2rayN covers Windows, macOS, and Linux, with graphical controls for subscription groups, server selection, system proxy, TUN, routing, and logs. Desktop package formats differ, but the basic subscription and configuration workflow remains consistent, making it suitable for users who repeat the same process across several desktop devices.
v2rayNG targets Android and is commonly paired with the Xray kernel path. Its interface focuses on mobile connection permissions, server switching, routing, and per-app handling. Because mobile networks change frequently, troubleshooting should consider Wi-Fi and cellular transitions, background restrictions, and system network permissions in addition to the configuration itself.
v2flyNG also targets Android, with the main distinction being its V2Fly kernel path. Choose v2flyNG when a subscription explicitly relies on V2Fly behavior or when you want to stay within that kernel ecosystem. Base the decision on the server configuration and actual protocol requirements.
These projects are maintained as open source, with licenses defining how code may be used, modified, and redistributed. The practical value of open source is that implementation details can be reviewed, issues can be discussed against specific code and configuration, and derivative clients must follow the applicable license. Users should still obtain a platform-appropriate build from a clear download source and read release notes and configuration changes.
Graphical clients and underlying kernels are maintained by different projects, so their release schedules do not have to align. Client updates may change the interface, installation method, or configuration conversion, while kernel updates may affect protocol behavior, routing, or supported parameters. When behavior changes after an upgrade, first determine whether the change belongs to the client or kernel layer, then review the settings, logs, or subscription content accordingly.
A protocol name is only one part of a configuration. The address, port, identity parameters, transport, TLS-related settings, and routing action can all affect a connection. Even when two clients list the same protocol, confirm their kernel, supported parameters, and configuration format. For compatibility issues, checking the complete configuration path is more effective than comparing protocol names alone.
Most first-time setup problems involve an unupdated subscription, no active server selected, an app that does not read the system proxy, or too many routing or DNS changes. The four entry points below suggest where to look; related concepts are covered in more detail in the terminology guide.
First confirm that the subscription group was saved, then manually update it and check the logs. Seeing the group name only means the URL record exists; it does not mean the subscription was downloaded and parsed successfully. For request errors, check the URL and current network. If the download completed but parsing failed, verify the subscription format.
View subscription and node terminology →Applications do not all read proxy settings the same way. Browsers usually follow the system proxy, while some terminal tools, development environments, and standalone network programs need their own proxy parameters or TUN interception. First determine whether one application is disconnected or all traffic is bypassing the client.
View system proxy and TUN →A test result covers only one part of the connection process. Continue by checking system time, DNS, routing matches, the active server, and the application’s proxy settings. Clear the logs and try the request again. If no corresponding request appears, the issue likely lies between the application and client; if a request and error are present, use the keywords to locate the kernel or configuration problem.
View log and troubleshooting terms →Consider TUN when the target application does not read the system proxy or when you need to handle a broader range of network traffic uniformly. Verify the basic connection through the system proxy first, then address permissions, DNS, and LAN routing. This separates server-configuration issues from traffic-interception issues.
View routing and split-tunneling terms →Each article focuses on one practical problem, explaining the check order, relevant log evidence, and relationships between settings. For a specific issue, start with the closest title, then return to the full documentation for the related concepts.
Check server availability, system time, DNS, routing rules, and the system proxy in order, separating connection status from whether real requests successfully pass through the client.
Read the full article →Explains common log keywords such as rejected, timeout, and invalid user, and shows how to trace an error to a specific setting using its timestamp, target address, and outbound tag.
Read the full article →Maps the relationship between the two kernels within the Project V technical lineage, then connects it to platform and kernel choices for v2rayN, v2rayNG, and v2flyNG.
Read the full article →