V2Ray Downloads v2rayN · v2rayNG · v2flyNG clients

Once installation is complete, work through the steps in order: load a configuration into the client, route apps through the proxy, then let routing rules direct requests. A problem at any of these stages can look like a connection failure. Checking each step separately is more effective than changing the protocol, DNS and ports all at once. Use the quick overview below, then follow the full guide for exact menus and steps.

1. Import a subscription and check its entries

   Add a URL and update a subscription group in v2rayN, or use the corresponding import option in v2rayNG. When copying a link, check its beginning and end and watch for line breaks so you don't include surrounding text. After updating, check the group, protocol type and remarks for each entry, then select one as the active configuration.

   An empty subscription response and a failed request are different problems. The first may point to a service issue or an unexpected response format; the second calls for checking the URL and request error. Don't post your subscription URL publicly or assume from its appearance whether it contains access credentials. If you need help, share an error description with sensitive details removed.

2. Choose a mode and start the local proxy

   On desktop, confirm the core is running, then choose a system proxy mode and routing preset. On Android, check the connection configuration and approve the system VPN request. Keep custom settings to a minimum during the first test so you can verify that the configuration itself works. If another proxy tool is running, check for conflicts involving local ports or system proxy settings.

   If an app has its own proxy settings, point them to the address and port the current client is listening on. Don't enter a SOCKS port as an HTTP port. Only adjust LAN access, extra inbound connections or complex routing if you need them; first establish a basic configuration you can test repeatedly.

3. Test access, then check the error logs

   Open the target site in your usual browser and confirm that local services are still accessible. A single failed attempt doesn't prove the protocol is unusable: DNS resolution, system time, app proxy settings and server status can all play a part. First check whether the core started, then see whether the request reached the proxy.

   V2Ray latency tests and V2Ray node speed tests serve different purposes. A connection test reflects only a particular target at a particular time; it can't replace testing the sites you actually use. If you see a timeout or handshake failure, note the error type, change one setting at a time and retest against the same target to see whether the change helped.

Read the full guide →

“V2Ray” is often used as an umbrella term for a family of configurations and clients, but downloads involve several distinct layers. Project V is an important starting point in this ecosystem, and V2Ray provides composable network proxy capabilities. The V2Fly community continues V2Ray development and maintenance, while Xray is a separate core line developed from related code. They share some concepts and configuration conventions, but their capabilities do not evolve in exactly the same way.

What clients and cores do

GUI clients provide groups, menus, subscription updates and connection controls. Cores parse configurations, establish connections, match routes and handle traffic. So a similar-looking client interface doesn't guarantee identical underlying capabilities. A client may also gain support for new configuration options as its core is updated. To assess compatibility, consider both the client and the core it uses, not just the app's name.

v2rayN is designed for desktop environments and supports multiple core configurations. v2rayNG is an Android client that uses the Xray core, while v2flyNG is an Android alternative based on the V2Fly core. All three are open-source software, with different features and use cases. Choose based on your device and existing configuration. Desktop and Android menus don't need to match; just check that the key fields express the same connection requirements.

A protocol name alone doesn't determine performance

VMess, VLESS, Trojan and Shadowsocks are common protocol types. REALITY is related to the security layer, so these are not all mutually exclusive options at the same layer. A working configuration may also require transport settings, a server name, certificate verification and flow control. Configure the client to match the combination provided by the server; changing only the protocol dropdown won't make a connection work.

You can't rank connection speed, resource use or mobile battery life by protocol name alone. Server distance, link quality, the handshake, transport encapsulation and device performance all affect results. If your current configuration is stable, keep using a solution that meets your needs. For comparisons, test on the same network against the same target at around the same time. For most users, complete fields, core support and maintainable settings matter more than chasing a particular protocol name.

Open-source licenses and usage

Open source means the code is available under the license adopted by each project; it doesn't mean every component uses the same license. Clients, cores and their dependencies may be subject to different terms. Read the license accompanying each project before using, modifying or redistributing it. Open source makes implementation and maintenance easier to review, but it doesn't replace checks on the runtime environment, service source or configuration.

The client itself does not provide a remote server or generate a working account for you. Subscription URLs, credentials and expiration dates depend on the configuration provider and are separate from whether the local app installed successfully. This site organizes downloads and setup guides to help clarify these distinctions. For service-specific issues, check the provider's guidance alongside the client logs.

Client updates and subscription updates are different

A subscription update fetches configuration data; a client update replaces the app, while a core update may affect protocol support and configuration parsing. These are not interchangeable. A successful subscription update doesn't mean the app is up to date, and installing a new client won't automatically fix an expired service address. Identify which layer is causing the issue before choosing an action to avoid unnecessary reinstalls.

Before updating, note your routing mode, custom rules and local listener settings, and use the client’s built-in method to save any configuration you need. After updating, test your usual setup before enabling new features one at a time. When switching cores, pay particular attention to protocol fields and DNS behavior. Configurations that worked in one environment still need to be tested with another core; don't assume compatibility.

Where to start troubleshooting

v2rayN subscription update failed: Check that the URL is complete and hasn't expired, then review the request result in the logs. If nodes still work, troubleshoot subscription retrieval first rather than deleting all your configurations. See the terminology guide for the difference between a subscription and a node.

V2Ray won't connect: Check core startup, local listening, app proxy settings, routing and the remote handshake—in that order. A failure in one browser calls for a different approach than a failure in every app. Handle configuration errors separately from connection timeouts. Review the core, listening and routing terminology, then follow the guide.

V2Ray node speed test results differ: Test methods may use different targets and connection steps. A result showing that a node connects doesn't mean every site will be accessible, and one test can't predict long-term performance. Check what the test measures, then compare it with your actual use case. See the terminology guide for related concepts.

Read the technical reference for protocols and cores →