Clients and Configuration Guides
A focused guide to client installation, subscription imports, and traffic routing, arranged in order from platform selection to connection verification.
client workflow
Client configuration is more than a single switch. Work through subscriptions, proxy settings, routing, and verification step by step to locate issues faster and keep your setup consistent across devices.
subscription
A subscription link provides configuration that the client can recognize and manage centrally. For the first setup, copy the complete address, add it as a new source in a subscription group, and run an update. Once configurations appear, select the one to use—“imported successfully” does not mean “connected.” Run future updates on the original group to avoid creating duplicate entries with the same name. If an update fails, first check whether the address was truncated and whether the system time is accurate, then check the network and subscription source.
View the subscription import stepssystem proxy
Starting the client only means that the local proxy service is ready; it does not mean every program will use it automatically. On desktop systems, you usually also need to enable the system proxy so browsers and apps that follow system settings can forward traffic. Some programs use their own proxy settings, in which case point them to the local address and the listening port shown by the client. Before exiting, restore the system proxy settings if needed so the operating system does not retain an invalid proxy address. If the client is connected but web pages do not open, check this layer first.
Troubleshoot an inactive system proxyrouting
Routing rules determine which outbound path different domains, addresses, and application traffic use. When getting started, choose a preset mode provided by the client and add custom rules only after the basic connection is stable. Rules are usually matched in order: precise conditions near the top take effect before broader ones below. When editing rules, check both the syntax and their position. Keeping local network addresses on a direct connection avoids sending traffic through an external exit when accessing routers, printers, or local services.
Read the routing rule syntax guide{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}verification
After configuration, check the client log first to confirm that the core starts and the local port is available. Then run the client’s connection test to distinguish an unusable configuration from a slow response. Finally, visit a familiar site in a browser to verify that the system proxy and routing rules work together. Test results in the list alone are not enough to judge the full path. If a step fails, troubleshoot that layer instead of repeatedly reinstalling the client or changing several parameters at once.
Open the connection troubleshooting guideplatforms
Use v2rayN on desktop platforms; on mobile devices, choose between v2rayNG and v2flyNG. The download center lists files by operating system and processor type, with platform-specific guidance at each entry.
desktop
v2rayN is a good fit for graphical desktop use. The desktop edition offers a cross-platform interface, while the classic WPF edition preserves the familiar Windows workflow. Both support subscription groups, system proxy, routing modes, and connection testing. Choose the edition that best matches your interface preferences on the download page.
Go to downloadsdesktop
Use the v2rayN desktop client. Before downloading, check your system information to identify the chip type, then choose the installer for Apple Silicon or Intel. Subscription imports and routing settings are similar to those on other desktop platforms, making it easier to compare matching options when migrating a configuration.
Go to downloadsmobile
v2rayNG with the Xray core is the preferred choice; v2flyNG is another option depending on the configuration source and core requirements. Most newer devices work well with arm64 files. If you are unsure of the processor architecture, check the system information before choosing a universal installer.
Go to downloadsdesktop
v2rayN provides packages for common distributions such as Debian, Ubuntu, and Fedora. Before downloading, confirm the package system and processor architecture. After installation, configure the desktop tray, system proxy, and launch-at-login service separately so distribution differences are not mistaken for client problems.
Go to downloadsquickstart
Start with a repeatable basic workflow before adjusting routing and advanced transport parameters. This makes it easier to tell whether an issue comes from the subscription, client, or system proxy.
View the complete guideOpen the v2rayN download area on desktop devices; on Android devices, choose v2rayNG or v2flyNG. Before installing, confirm the operating system, processor architecture, and package format. After the first launch, locate subscription groups, the server list, routing modes, and system proxy settings before changing advanced options.
Copy the complete subscription address, add a group in the client’s subscription manager, and run an update. Once configurations appear, select an available entry and check that the protocol, address, port, transport, and TLS fields were supplied correctly by the subscription. QR codes are useful for temporary device-to-device migration; for long-term management, keep a unified subscription source.
Start the core and enable the required proxy mode. First confirm that the log shows no port conflict or configuration parsing error, then run a real connection test, and finally verify access in a browser. Add custom routing and DNS settings only after the basic path is stable. Change one category of parameter at a time so results are easy to compare and revert.
open ecosystem
Clients, cores, protocols, and configuration formats belong to different layers. Understanding how they relate is more useful for migrating configurations and resolving compatibility issues than memorizing a particular interface button.
Project V grew into an open-source ecosystem around proxy protocols, transport methods, routing rules, and client tools. V2Ray is often used as a general name for this technology stack, but in practice it is important to distinguish graphical clients from the underlying core. A graphical client imports subscriptions, generates configurations, manages the system proxy, and displays logs. The core parses configuration, establishes connections, applies routing, and handles inbound and outbound traffic. Separating these layers explains why the same subscription can be read by different clients and why some parameters work only with a particular core.
V2Fly continues V2Ray’s community development direction, covering VMess, VLESS, routing, DNS, and various transport combinations. Xray has continued evolving within a similar configuration ecosystem, adding further transport and protocol capabilities. Neither is a client name; each is a core program that graphical clients can call. When choosing a client, also check its default core, the protocol parameters supplied by the subscription, and the server configuration. Interface appearance alone cannot show whether a configuration will load completely.
v2rayN targets Windows, macOS, and Linux desktops, offering graphical subscription groups, routing, system proxy controls, and log viewing for users who want one consistent desktop workflow. v2rayNG targets Android and commonly uses the Xray core, with a focus on mobile network changes, per-app proxying, and QR-code imports. v2flyNG also targets Android and primarily uses the V2Fly core, making it an alternative when its core behavior is required. All three are community-maintained open-source clients, but their platform focus and core combinations are not identical.
Source code, licenses, and release records provide traceable evidence of how an open-source project is maintained. Client updates may include interface fixes, system compatibility changes, core integration, and configuration-format changes; core updates may affect protocol implementation, routing capabilities, and transport behavior. Read the change notes before updating and keep a working configuration. If problems appear after a new installation, check client settings and core logs separately instead of blaming every issue on the subscription. The download center organizes entry points by platform, while the documentation explains the impact of changes by task.
common questions
These questions cover the parts of a first-time setup that most often cause confusion. For the complete workflow, continue to troubleshooting or consult the troubleshooting manual by symptom.
First confirm that you copied the complete subscription address, then run a manual update on the relevant group. If it is still empty, check the system time, local network, and response details in the client log. Do not keep creating duplicate groups, or it will be difficult to tell which source was actually updated. See Troubleshooting for the recommended order of checks.
First confirm that the core started successfully, then check whether the system proxy is enabled. Some browsers or apps use their own proxy settings and require the local listening address and port to be entered separately. If the log reports a port conflict, stop the process using it or change the listening port. See system proxy troubleshooting for detailed steps.
For an initial setup, use the more direct mode to confirm the basic connection, then switch to a preset route. Routing mode chooses an outbound path based on domains, addresses, or rule sets, making it better for long-term use. Add custom rules only after the basic path is stable, and remember that matching proceeds from top to bottom. See the full configuration guide.
A successful test only means that the selected test method received a response; it does not replace real-world access verification. Also check the system proxy, DNS, routing rules, and whether the target application is using the correct outbound path. Verify each layer in order: core startup, connection test, and actual access. When one fails, troubleshoot only that layer.
latest notes
In-depth guides on platform installation, routing rules, and multi-device migration. Each article focuses on one practical scenario so you can find the relevant steps quickly.
Explains package selection for Debian, Ubuntu, and Fedora distributions, dependency handling, tray display, and user-service setup, followed by a post-installation checklist.
Read the full article →Breaks down domain, exact-match, regex, address, and rule-set syntax; explains how rule order affects the final outbound path and organizes maintainable grouping methods.
Read the full article →Compares unified subscriptions, configuration-file export, and QR migration, explaining when to use each for automatic updates, temporary migration, and cross-device management.
Read the full article →