A central resource for four-platform client downloads, subscription import steps, and routing configuration, with practical menu paths, mode differences, and troubleshooting sequences.
v2rayN
GUI clients for Windows, macOS, and Linux
Xray
Evolving alongside the V2Fly ecosystem
Open source
Configuration behavior and release history are publicly reviewable
Use v2rayN on desktop systems, or choose between v2rayNG and v2flyNG on Android. These links open the matching platform panel on the download page, where package types, architecture options, and system requirements are explained.
Choose between a modern desktop interface and the classic WPF interface. For a first setup, the desktop version is a good starting point; if you prefer the familiar menus or classic layout, see the WPF version details on the download page.
Choose the Apple Silicon or Intel package for your processor. Open “About This Mac” in system settings to check the chip type. Subscription and routing menus remain broadly consistent with other desktop versions after installation.
v2rayNG uses the Xray core and is a practical everyday choice; v2flyNG follows the V2Fly core and can be selected based on server configuration and personal preference. Most current devices use arm64; when unsure, try the universal build.
Choose deb for Debian, Ubuntu, and similar systems; choose rpm for Fedora, Rocky Linux, and similar distributions. The download page separates x64 and arm64 builds and lists the desktop environment requirements to check before installation.
A client does more than import a connection. Subscription updates, which applications use the system proxy, the order of routing matches, and when to enable TUN mode all affect real-world results. This section breaks six capabilities into practical settings, starting with where to configure them and then covering their limits and verification steps.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}In v2rayN, open “Subscription groups → Subscription group settings” to save a subscription URL, then select “Update all subscriptions” to fetch the server list. Group names organize sources without changing node parameters. If the list is empty after an update, check in order that the URL is complete, the response can be parsed by the client, the current network allows the request, and the client log shows no format warning. Unlike pasting individual share links, subscriptions are better for maintaining configurations that change over time.
The system proxy mainly covers browsers and desktop applications that follow the operating system’s proxy settings. After v2rayN starts the core, you must also select the appropriate system proxy state from the tray menu; starting the client alone does not proxy every application. If an app connects differently, first check whether it reads the system proxy, then decide whether to configure the app’s own proxy or use TUN. This prevents application compatibility issues from being mistaken for node failures.
The routing section can select outbounds by domain, IP, port, protocol, or inbound tag. A common approach is to handle LAN and private addresses first, then match destinations that should connect directly or use the proxy, while retaining a default outbound at the end. Rules do not simply override one another; they search for a match in configuration order. After editing, check domain policies, rule order, and whether outboundTag matches an existing outbound. If the tag is misspelled, the core will usually report it clearly in the startup log.
TUN mode processes traffic through a virtual network interface, making it suitable for applications that ignore system proxy settings. Before enabling it, confirm the required client permissions, virtual interface status, and whether other network tools on the device may conflict. During troubleshooting, avoid changing several settings repeatedly: disable the system proxy to test TUN, restore a single routing approach, and use logs to verify DNS and outbound selection. Controlling variables clearly is more effective than reinstalling repeatedly.
v2rayN is a desktop GUI client that can work with supported cores to process connections; v2rayNG primarily uses the Xray core, while v2flyNG follows the V2Fly core. Both core families trace back to the Project V ecosystem, but their configuration coverage and feature development may differ. Choose based on the server protocol, transport parameters, and client support rather than the name alone. If import succeeds but startup fails, core compatibility is one of the first things to check.
Core startup failures, subscription parsing errors, and port conflicts usually leave actionable logs. Start near the time of the failure and prioritize the first useful error containing a field name, port, or configuration section instead of focusing only on the final exit line. For a port conflict, inspect local listeners; for a configuration error, check the relevant JSON field; for a transport mismatch, compare the server parameters. Change one variable at a time and restart to preserve a clear cause-and-effect trail.
Start with a basic connection you can reproduce, then add automatic updates, routing, and TUN one step at a time. During initial setup, change only one option at a time so it is easier to identify where a problem occurs.
On desktop, open the v2rayN panel for your platform; on Android, choose v2rayNG or v2flyNG based on the required core. Confirm the processor architecture and package type before installing so an incompatible build is not mistaken for a startup failure. After the first launch, keep the default routing and port until the basic connection works.
Add the URL in the client’s subscription group settings, save it, and run an update. Once the server list appears, select a configuration and set it as the active server. If the list is empty, check the subscription update log first; if a node appears but will not start, check the core log instead. Keep these two troubleshooting paths separate.
After selecting an active server, start the core and choose the system proxy based on the applications you use. Test the system proxy first with ordinary browsers; evaluate TUN for applications that ignore system proxy settings. Once the basic connection is stable, add routing rules for bypassing LAN addresses, matching domains, and selecting specific outbounds.
Clients, cores, protocol settings, and subscription services each have different responsibilities. Understanding these boundaries helps determine whether an issue belongs to the interface, configuration content, core compatibility, or a remote service.
Project V established the basic structure of the V2Ray configuration model: inbounds receive local traffic, outbounds define forwarding targets, routing matches traffic between them, while dns and log provide name resolution and runtime records. The V2Fly community continues to maintain V2Ray Core and related specifications, while Xray developed an independent core along the same technical lineage. They share many configuration concepts, but fields, protocol extensions, and release schedules may differ.
Therefore, “the client supports a particular share link” and “the current core can fully process its parameters” are two different questions. A GUI client can parse subscriptions, generate configurations, and manage processes; the core performs the actual protocol handshake, routing, and forwarding. When server parameters change, check both the client’s parsing capabilities and the core’s supported range rather than only whether the server name appears in the interface.
v2rayN, v2rayNG, v2flyNG, and the related cores are maintained as open-source projects. Source code, configuration formats, and change histories are managed publicly, while maintainers and community contributors continue to discuss features, fix issues, and improve compatibility. Open source makes it easier for developers to understand how configurations are generated and for advanced users to trace behavior differences through logs and field definitions.
Different components may use different open-source licenses. A license governs how code can be copied, modified, and redistributed; it does not mean every client is maintained by the same team. When using documentation, identify the component precisely: v2rayN menu paths do not map directly to mobile clients, and Xray extension fields should not be assumed to work in every V2Fly configuration. Consulting the documentation for each component reduces conceptual mix-ups.
Client updates commonly change the interface, subscription parsing, configuration generation, and core management; core updates focus more on protocol implementation, transport behavior, routing, and DNS. When something works before an update but fails afterward, first record whether the change affected the client, core, or subscription, then review the logs layer by layer. Replacing multiple components at once makes it difficult to identify the variable that caused the result.
For routine maintenance, use a consistent order: update the subscription and observe the node list, start a known-good configuration, and only then adjust the proxy mode and routing. For long-lived rules, document their purpose, match conditions, and outbound tags. Even when menu layouts change, these semantics let you restore the original behavior without relying on a particular button location.
A GUI client for Windows, macOS, and Linux that centralizes subscription groups, server lists, the system proxy, routing rules, TUN, and core logs. It suits users who maintain multiple configurations and monitor runtime status on desktop.
A mobile client built primarily around the Xray core, supporting QR code, clipboard, and subscription-based configuration import. Common tasks center on configuration lists, active nodes, routing settings, and connection logs.
A mobile option built around the V2Fly core, with a clear separation between interface actions and the usual subscription workflow. It suits scenarios that require compatibility with the V2Fly core or comparison of behavior between the two core families.
Most configuration issues can first be classified by when they occur. If the list is empty, focus on the subscription request and parsing; if the program will not start, focus on the core log; if only some applications are affected, focus on how traffic is being captured.
First confirm that the complete subscription URL was saved, then review the network request and parsing messages in the update log. Opening a URL successfully does not mean its response uses a subscription format supported by the client. If the subscription source recently changed, also check whether the group still contains the old URL.
View the subscription import steps →Check that an active server is selected, the core is running, and the system proxy is enabled in the tray menu. Some applications have their own proxy settings or ignore system settings; configure them separately, or use TUN after confirming permissions and checking for conflicts.
View the connection and verification steps →Find the first clear error in the log. Common clues include an occupied port, a missing outbound tag, an incorrectly typed configuration field, or missing transport parameters. Fix one item and restart; do not change the port, routing, and core at the same time.
View the complete troubleshooting path →A global proxy is useful for briefly verifying that the node and core work correctly. Once the basic connection is confirmed, switch to routing and add rules one by one. Verify the default outbound first, then add LAN, domain, and IP rules to expose matching-order problems faster.
View the routing section →Practical instructions covering the main interface, log analysis, and JSON configuration structure. Each article focuses on one issue, making it easy to consult after completing the basic guide.
A top-to-bottom tour of the main window, covering server-list columns, subscription-group tabs, the bottom log panel, and common settings entry points to build a clear operational map.
Read moreA practical sequence for investigating occupied ports, missing configuration fields, transport mismatches, and damaged core files.
Read moreA concise JSON configuration walkthrough explaining the relationship between inbounds, outbounds, and routing, along with the role of log and dns.
Read more