GUI clients and Chinese configuration guides
A focused resource for GUI client downloads, subscription imports, and routing configuration. Choose a client for your device, then follow the guide to configure the core, system proxy, and rules.
// PLATFORM DOWNLOADS
v2rayN is the main choice for desktop devices. On Android, choose between v2rayNG and v2flyNG based on the required core. Each platform link takes you directly to the relevant download section.
DESKTOP / WINDOWS
Choose between the v2rayN desktop edition and the classic WPF edition. The desktop edition uses a cross-platform interface, while WPF suits a more traditional workflow. Both manage subscriptions, the system proxy, routing rules, and core settings.
Go to downloadsDESKTOP / MACOS
Use the desktop build of v2rayN. Before downloading, check your system information to confirm whether the processor is Apple Silicon or Intel. After installation, decide whether to enable the system proxy based on where you use the network.
Go to downloadsMOBILE / ANDROID
Choose v2rayNG with the Xray core by default; use v2flyNG when the V2Fly core is required. Most recent devices suit arm64 builds. If you cannot confirm the architecture, consider a universal build.
Go to downloadsDESKTOP / LINUX
v2rayN provides desktop builds for common package systems. Confirm whether your distribution uses deb or rpm, then choose between x64 and arm64. After installation, manage subscriptions and routing through the GUI.
Go to downloads// CLIENT WORKFLOW
A GUI client is only the entry point. Whether a connection works as expected depends on the subscription, active configuration, system proxy, routing rules, and DNS settings forming a complete chain.
STEP 01 / IMPORT
Add the URL under a subscription group, run an update manually, and confirm that the configuration list appears. If the import fails, first check the URL format, whether it was copied in full, and network reachability.
STEP 02 / ACTIVATE
A successful import does not mean the configuration is enabled. On desktop, set the target configuration as active. On Android, select the configuration and start the connection, then check the status indicator.
STEP 03 / ROUTE
Start with a routing mode suited to everyday use, then add rules for domains, IPs, and geosite entries as needed. Avoid piling on custom conditions that are difficult to verify from the outset.
// SUBSCRIPTION GROUP
The subscription URL provides a set of configurations, the group organizes sources, and the update action writes remote content into the client. A common issue is saving the URL without running an update, or remaining on an old active configuration after updating. A reliable approach is to create separate groups for different sources, then check added, removed, and renamed configurations after each update before manually selecting the one in use. Unlike editing a long configuration directly, a GUI client displays the source, update time, and active item separately, making later diagnosis clearer.
Daily configurationManual updateSelected// SYSTEM PROXY
When the client shows that it is running, only the local core has started; whether browsers and other applications use the connection also depends on the system proxy or the application’s own proxy settings. On desktop, note the local HTTP and SOCKS listening ports first, then enable the system proxy and test with a browser. If only certain programs remain inaccessible, check whether they ignore system settings or use different fixed ports. The value of a GUI is that core status, ports, and the system proxy switch appear in one troubleshooting path.
EnabledHTTP / SOCKSFollow system// ROUTING POLICY
Routing rules determine whether a request goes through a direct, proxy, or block outbound. Rules can match domains, IPs, geosite, and geoip data, but the more conditions there are, the harder their priority is to understand. For a first setup, use a common client-provided mode, confirm basic connectivity, then add a few explainable custom rules. After every change, test the target domain and local network access; do not change DNS, the core, and routing at the same time. Compared with tools that offer only a single switch, V2Ray ecosystem clients clearly separate match objects from outbound actions.
directdirectblock// TROUBLESHOOTING
Connection problems usually fall into six categories: the subscription was not updated, no active configuration was selected, a local port conflict, the system proxy did not take over, a route matched incorrectly, or DNS resolution failed. Start with the core startup result in the client log, confirm the local listening port, then check the system proxy and the routing action for the target request. On mobile, also verify connection permissions and background operation. Reinstalling restores program files but cannot fix an invalid subscription or rule set, so preserve the current state and narrow the cause one layer at a time.
Check firstConfirm nextLocate last// ROUTING RULES
Routing configuration is more than a simple domain list. The client checks domain, IP, port, or protocol conditions in rule order, then sends a match to the specified outbound. Direct is suitable for local networks and targets that clearly need no proxy; the proxy outbound handles traffic that must be forwarded; the block outbound rejects defined categories. Once these three actions are clear, rule text becomes much easier to read.
For custom rules, let each rule solve one problem and record whether it appears before or after the preset rules. When the same target matches several conditions, order often matters more than the number of rules. Read how domain, ip, and geosite syntax works and how matching priority is determined before deciding whether to override the client presets.
ip:private → directgeosite:cn → directcategory-ads-all → blockfinal → proxy// PROTOCOL CHOICE
VMess, VLESS, Trojan, and Shadowsocks describe different protocol designs; TCP, WebSocket, and gRPC are transport choices; TLS and REALITY handle different handshake and security responsibilities. Subscriptions usually provide a complete combination. When getting started, avoid changing one component in isolation, or you may end up with a reachable address but a failed handshake.
The “protocol type” field in a client is only one configuration entry point. For real troubleshooting, also verify the server address, port, user identifier, transport parameters, server name, and time settings. For the trade-offs behind each option, see the protocol and core technical reference, comparing compatibility, resource use, and intended use rather than names alone.
VLESSTCPREALITYXray// DNS SETTINGS
A domain request is resolved first, then routing rules choose its outbound. If the result does not align with the expected outbound, domain rules may appear to work while the actual connection takes an unexpected path, some sites may open only intermittently, or the system and client may receive different results. Distinguish system DNS, the client’s built-in DNS, and remote resolution during troubleshooting. Do not enable several complex strategies before basic connectivity is confirmed.
A clearer approach is to verify connectivity with the client’s default DNS first, then observe which layer resolves the target domain and whether the result enters the expected rule. If you suspect a resolution-path issue, see DNS leak testing and configuration in practice, then test again after changes instead of judging only by whether a page opens.
Basic networkingProcess by rulesMatch routingVerify again// OPEN SOURCE ECOSYSTEM
GUI clients, proxy cores, and protocol configurations belong to different layers. Putting each name back in its proper place makes selection and troubleshooting more accurate.
Project V established a proxy tool ecosystem centered on configuration-driven design. Its influence extends beyond a single executable: it introduced modular concepts such as inbounds, outbounds, routing, transport, and DNS. The protocol types, routing outbounds, rule objects, and log options shown in GUI clients largely operate these underlying capabilities. The GUI lowers the barrier to editing structured configuration, but the core still defines what that configuration means.
When features differ, first determine whether the issue belongs to the client interface or core support. A changed button location is a client-layer issue; whether a protocol or transport is available mainly depends on the core and configuration format. Mixing the layers can lead to mistaking a missing interface entry for unsupported core functionality, or a missing subscription field for a program failure.
V2Fly continues the community-maintained direction of the V2Ray core, retaining its modular configuration structure while addressing protocol implementations, transport components, routing data, and compatibility. It suits scenarios that require traditional V2Ray configuration semantics, broad compatibility, or migration from existing configurations. On Android, v2flyNG primarily uses the V2Fly core, giving mobile users a familiar GUI entry point into this core family.
A core upgrade may change field validation, defaults, or resource files. GUI clients often adapt, but subscription providers and client releases may not move in lockstep. If a configuration stops working after an upgrade, first identify which field the error points to, then determine whether the cause is legacy compatibility, client generation logic, or changed core behavior. Avoid replacing every setting immediately.
Xray developed from a similar configuration foundation into an independent core line and is common in VLESS, XTLS, and REALITY configurations. Both v2rayN and v2rayNG provide GUI management around Xray, bringing subscriptions, core startup, the system proxy, and routing into one interface. Some Xray and V2Fly configuration structures resemble each other, but that does not mean every field, protocol combination, or default can be exchanged directly.
When choosing a core, follow the explicit requirements of the subscription and the client’s support range first. If a configuration uses a core-specific capability, keep the client, core, and rule resources aligned. For ordinary protocol use, prioritize stable operation, platform support, and readable configuration. Compare further in the detailed protocol guide by protocol, resource use, and compatibility.
V2Fly, Xray, and all three GUI clients are maintained through public code and license terms, although their licenses are not identical. Public licenses define the conditions for copying, modifying, and redistributing software, while allowing the community to review protocol implementations and configuration handling. For ordinary users, the practical benefit is that an issue can be traced to a specific component instead of an opaque all-in-one program.
Updates generally follow four tracks: the client interface, proxy core, routing resources, and subscription content. Updating the client does not necessarily change the core, and updating a subscription does not replace the local program. The download page separates platform builds, while the guides explain the operating sequence. In practice, update one layer at a time and retain the existing configuration so compatibility changes can be traced quickly.
// V2RAYN
v2rayN brings subscription management, core switching, the system proxy, routing rules, and log viewing into one GUI. Cross-platform desktop builds run alongside the classic Windows interface, letting users choose based on their system and workflow.
// V2RAYNG
v2rayNG is a common V2Ray GUI client on Android, using the Xray core to support a range of subscription configurations. Key mobile tasks include importing configurations, granting connection permission, selecting the active item, and managing per-app rules.
// V2FLYNG
v2flyNG targets Android users who need the V2Fly core, with a workflow similar to familiar mobile GUI clients. Before choosing it, confirm that the subscription fields are compatible with the target core rather than switching clients by name alone.
// QUICK ANSWERS
Most issues do not require a full reinstall. Check subscriptions, the active configuration, core, ports, system proxy, routing, and DNS in that order to locate the cause faster.
After adding the URL, run a subscription update and confirm that the content was written to the correct group. If the result is empty, check that the URL is complete, has not expired, and is reachable from the client. See the subscription import steps.
First confirm that the target configuration is active, then check whether the system proxy is enabled and whether the local port is occupied. Some programs use their own proxy settings, so verify their address and port as well. See connection issue categories.
When troubleshooting basic connectivity, compare results with a mode that has a clearly defined scope. For everyday use, start with preset routing rules. Once everything works, add custom rules one at a time and observe the outbound action assigned to each.
REALITY commonly appears in Xray-based configurations. Beyond the protocol type, ensure that the server name, public key, short ID, fingerprint, and other fields match the server. See the protocol reference for configuration layers and selection guidance.
// TECHNICAL NOTES
These articles focus on concrete tasks and frequent failures. Their entry names, troubleshooting order, and configuration objects correspond to the actual GUI client interfaces.
From preparing the runtime environment to the first launch, this guide covers choosing between the two interfaces, extraction locations, permission issues, and what to check when the system proxy does not work.
Read the full article →Covers subscription entry points and update steps on desktop and Android, along with common content formats such as Base64, vmess://, and vless://.
Read the full article →Explains why DNS requests may leave the expected path, how to check settings on desktop and Android, and how to retest after making changes.
Read the full article →