PROJECT V CLIENTS · CONFIGURATION
A resource hub for desktop and Android clients, bringing together installer selection, subscription import, and routing. Coverage includes v2rayN, v2rayNG, v2flyNG, and configuration concepts related to the Xray and V2Fly cores.
PLATFORM ENTRY
The home page only routes visitors by operating system. On the installer page, choose files based on processor architecture, package format, and client core. v2rayN is the primary option for desktop devices, while Android users can choose between v2rayNG and v2flyNG.
Use the v2rayN desktop client. The installer page explains the differences between the newer desktop interface and the classic WPF version, and covers runtime requirements, extracted installation, system proxy setup, and port conflicts.
Go to downloadsUse the cross-platform v2rayN desktop client. Before downloading, check whether the device uses an Apple Silicon or Intel processor; the relevant tab covers architecture identification, first launch, and system proxy setup.
Go to downloadsFor the Xray core, start with v2rayNG; choose v2flyNG when the V2Fly core is required. The installer page separates arm64 and universal builds and covers subscription import, VPN permissions, and background operation.
Go to downloadsUse the v2rayN desktop client. Installers are organized by deb, rpm, and processor architecture for common desktop distributions. After installation, configure the system proxy for the desktop environment or use the client's TUN feature.
Go to downloadsCLIENT CAPABILITIES
The client is only the graphical layer between configuration and the core. Real-world behavior depends on node parameters, protocol fields, routing order, DNS paths, and how the system hands over traffic. The four most common areas are explained below.
ROUTING
Routing rules decide whether traffic goes through a proxy, uses a direct connection, or is blocked. Common conditions include domains, destination IPs, ports, inbound tags, and protocol types. v2rayN can use preset rules or load custom JSON. Start with a small set of understandable rules, then add geosite and geoip entries gradually; more rules do not automatically mean more accurate matching. When troubleshooting, check top-to-bottom match order, the final fallback outbound, and domain resolution results to prevent the same destination from matching conflicting conditions.
Compared with a simple global proxy, routing preserves control over different types of traffic. Direct connections for services in mainland China, proxying for specific domains, bypasses for local network addresses, and ad-domain blocking can be handled separately. Logs also make it easier to confirm whether a particular rule is active.
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}PROTOCOL
VMess, VLESS, Trojan, Shadowsocks, and SOCKS use different authentication methods and data encapsulation. The transport layer may also combine TCP, WebSocket, gRPC, HTTP/2, or QUIC. When importing a node, the client passes the protocol, address, port, user identifier, TLS, SNI, and transport parameters to the core. Any mismatch in a critical field can appear as a timeout, handshake failure, or a connection that succeeds but cannot reach the destination.
Choose a protocol according to the server's actual configuration; do not simply replace its name. VLESS is often paired with extensions in the Xray ecosystem; VMess has long been used in the Project V ecosystem; and Trojan configuration focuses on the TLS domain and certificate chain. When troubleshooting, verify each field first, then assess the protocol itself.
SUBSCRIPTION
A subscription URL usually returns a set of node configurations, which the client fetches, parses, and writes to its local configuration list. After the first import, run an update manually and check the client message. If the list is empty, verify the complete URL, system clock, network access to the subscription source, and whether the returned content uses a format supported by the client. A failed update does not necessarily remove existing nodes immediately, but continuing to use old settings may leave parameters outdated.
Node groups, notes, sorting, and automatic updates are local management features. Keep group names clear, and copy subscription-generated nodes into a separate configuration before editing them so a later refresh does not overwrite manual fields. Subscription URLs containing private information should not appear in screenshots, shared logs, or public documentation.
TRAFFIC CAPTURE
The system proxy mainly affects applications that actively read the operating system proxy settings; some command-line tools, games, and independent network components may bypass it. TUN mode uses a virtual network interface to capture a broader range of traffic, then lets the core handle routing and DNS. This reduces the need to configure each application separately, but also involves administrator permissions, routing tables, virtual network adapters, and local security policies, making troubleshooting more involved than with a standard system proxy.
Before enabling TUN, confirm that the standard system proxy connects normally, then disable other network tools that modify the routing table. If the network goes offline, exit TUN first, restore the system proxy, and check the virtual adapter and DNS configuration. This separates node, core, and system traffic-capture issues during troubleshooting.
OPEN SOURCE ECOSYSTEM
V2Ray is not the name of a single graphical client. It more commonly refers to the protocol, core, and client ecosystem that grew from Project V. Understanding the division between core and interface helps identify which layer is causing a configuration problem.
Project V established V2Ray Core and its configuration system in its early years, introducing concepts such as VMess, inbound and outbound handlers, routing, and transport layers. The community later took different maintenance paths: V2Fly continued developing and maintaining v2fly-core, while Xray developed xray-core while retaining compatibility with established configuration concepts. Both are common core implementations today, but their protocol extensions, configuration fields, and release schedules are not identical.
Graphical clients usually do not handle protocols directly. v2rayN, v2rayNG, and v2flyNG manage subscriptions, edit nodes, generate parameters, start the core, switch the system proxy, and display logs; the core they invoke performs the actual data connections. As a result, the same node may behave differently across clients because of the core type, core configuration template, or client-version compatibility. When troubleshooting, record the client name, core in use, protocol fields, and error logs rather than simply reporting that “V2Ray cannot connect.”
Open-source licenses allow developers to review code, study configuration implementations, and build derivative tools, but each project's license text, dependencies, and release method must be checked separately. The site's documentation is based on public configuration models and actual client interfaces, focusing on installation, parameter meanings, and troubleshooting order rather than treating different projects as one software package.
V2FLY
The V2Fly community-maintained core continues the Project V configuration model, covering inbound and outbound handlers, routing, DNS, and multiple transport methods. v2flyNG uses this core as a graphical Android entry point and suits configurations that need to stay on the V2Fly core path.
XRAY
The Xray core remains closely related to established V2Ray configuration concepts while adding capabilities such as VLESS and REALITY. v2rayN and v2rayNG commonly invoke Xray within their client ecosystems, although the exact support range depends on the client-core combination.
CLIENTS
v2rayN targets Windows, macOS, and Linux desktop systems; v2rayNG targets Android and primarily uses the Xray core; v2flyNG also targets Android but uses the V2Fly core. Their roles differ, so selection should not be based only on similar names.
The client, core, GeoIP data, and GeoSite data are separate components. Client updates usually affect the interface and configuration generation; core updates affect protocol handling and runtime behavior; geographic data updates affect routing-rule matching. If routing becomes inaccurate, check the data files first; if protocol fields are not recognized, verify core and client compatibility next.
Share links and subscription formats are only configuration exchange methods; they do not guarantee that every client supports every included field. A successful import only means the client recognized the basic structure. You still need to check whether transport, security, SNI, fingerprint, and routing settings are complete. When migrating between cores, compare fields one by one instead of overwriting the original configuration.
Useful logs should include the time of the event, the connection stage, and the error type. DNS resolution failures, TCP connection timeouts, TLS handshake failures, authentication-field errors, and routing misses each point to a different layer. Identify the failing layer before changing the corresponding configuration, avoiding new interference caused by changing multiple variables at once.
QUICK DIAGNOSIS
These questions cover four areas that are most easily confused after the first installation. For a systematic diagnosis, continue to the guides, concept reference, and advanced troubleshooting manual.
First, confirm that you used “Update subscriptions” rather than only adding a subscription group, and check that no characters were lost from the beginning or end of the URL. Then verify the system clock, current network connection, and client logs. If the request succeeds but the parsed list is empty, the returned format may not be supported by the client. Do not repeatedly delete all configurations; keep the original subscription entry and verify each point in turn.
View the subscription import steps →The system proxy only affects applications that read that setting. Check whether the target program has its own proxy option, then determine whether it uses an independent network stack. If broader traffic capture is needed, consider TUN mode, but first ensure the node works normally in standard proxy mode and avoid multiple network tools modifying the routing table at the same time.
View the system proxy and TUN guide →First distinguish slow DNS resolution from slow connection setup and slow content transfer. Test several destinations and watch the logs for repeated lookups or reconnects. Then check routing rules, the DNS query path, transport method, and local network. Do not rely on a single speed test, because results can vary significantly by destination, time, and route.
Open the speed troubleshooting section →The protocol must match the server configuration and cannot be swapped arbitrarily in the client. Check the protocol, port, user identifier, security layer, and transport parameters supplied by the server. If you have a complete subscription, importing it directly is usually more reliable than rewriting it manually; for manual setup, compare every field with the original information.
View the protocol reference →FIELD NOTES
Long-form guides on routing rules, geographic data, and the Windows installation process. Configuration snippets explain relationships between fields; actual parameters should always follow the current client interface and server configuration.
Using v2rayN routing settings as an example, this guide explains the matching order for domain, ip, and geosite rules, covers common combinations for direct access, proxying, and ad blocking, and shows how to use logs and outbound tags to locate rule conflicts.
Read the full article →Learn what geoip.dat and geosite.dat do, where they are commonly stored, and how they are loaded. The guide also explains how to verify geographic-data updates in v2rayN and v2rayNG, plus typical routing mismatches caused by stale data.
Read the full article →Starting with installer types, this guide covers runtime requirements, extracted startup, subscription import, system proxy setup, and connectivity checks, along with common issues such as security-software blocks, occupied ports, insufficient permissions, and configuration-directory migration.
Read the full article →