V2Ray FAQ

Use v2rayN on Windows, macOS and Linux desktops, choosing a build that matches your operating system and processor architecture. On Android, v2rayNG with the Xray core is usually the right choice; consider v2flyNG if an existing configuration specifically depends on V2Fly behavior. The graphical client imports subscriptions, lets you select servers and manage settings; the core handles connections and routing. Similar client names do not mean identical features, so check protocol, security layer and transport support. Before migrating, keep your existing configuration, test one known-working profile, then import the remaining groups.

Installing a client gives you configuration and connection tools; it does not provide a server. You’ll need a subscription URL, share link or complete server details that you manage or are authorized to use. A subscription URL retrieves a set of configurations, while a share link usually contains a single profile; they are not interchangeable in every import flow. Check which type your provider supplies, then use the subscription group or clipboard import option. Subscription URLs may contain access credentials, so treat them like passwords: don’t post them in public comments, screenshots or online conversion tools. This site provides client documentation and does not distribute subscriptions.

VMess, VLESS, Trojan and Shadowsocks are proxy protocols; REALITY is a security layer, not a proxy protocol you can swap in directly. A connection also depends on the transport, security layer, server address and authentication details, all of which must match the server. For example, a VLESS profile in a subscription may include REALITY parameters; preserve details such as its public key and server name when importing it. Changing only the protocol in a dropdown won’t restore a connection. Choose based on the server’s existing configuration and client support, then compare features rather than guessing speed from protocol names.

For most Android phones released since 2015, arm64 is a reasonable first choice, but check the app architectures supported by your operating system rather than relying on processor marketing. Some devices have 64-bit hardware but only a 32-bit app environment, so an arm64 APK may not install. If you’re unsure which architecture your device supports, choose universal. It includes components for multiple architectures and is usually larger, but still requires a supported Android version. If installation fails or the package can’t be parsed, check the OS version, available storage and whether a previously installed app has a conflicting signature. Don’t keep downloading the same incompatible APK.

First check whether the clipboard contains a share link, a subscription URL or webpage text. Copy share links in full, without explanatory text, line-break truncation or punctuation added by a chat app. Add subscription URLs to a subscription group and update it; don’t import one as an individual server. If the list is still empty, check the client log for an unsupported format, missing fields or a parsing error. Don’t send anyone the full link for troubleshooting; describe the protocol and error summary instead. Confirm that the client supports the profile’s protocol and security layer, then ask the configuration provider for a compatible source format.

Open the subscription group and check that the URL is complete, especially its trailing parameters. Update the group once and review the log. For authentication failures or access denied errors, check subscription permissions, expiration and the provider’s access requirements. A connection timeout usually points to the current network or the proxy route used for the update; a parsing error may mean the response was a login page or incompatible content. If the client offers an option to update through a proxy, use it only when the current proxy works—otherwise you may be relying on a broken configuration to fetch a new one. Don’t delete the existing group first; keeping it makes changes easier to compare.

TUN takes over traffic through a virtual network interface and requires different permissions from a regular system proxy. Turn TUN off first and confirm the same server connects in regular proxy mode. Then follow the prompts for your current v2rayN version and operating system to grant administrator access or configure the required service or virtual interface component. On Windows, try running as administrator to see whether that resolves the permission error. On macOS and Linux, use the platform’s own authorization process rather than following steps for another system. Close other tools that may use the virtual interface or change routes. If the internet drops immediately after TUN starts, turn TUN off to restore the connection, then check logs for interface, route or permission errors.

Use the client’s backup or export feature to save subscription groups, manually added servers, routing rules and custom DNS settings. Note your local listening ports and system proxy mode as well. Backups may contain subscription credentials and authentication details, so store them securely. When switching between the desktop and classic WPF versions, migrating across operating systems or making a major version upgrade, don’t overwrite a configuration folder unless you know what it contains. Close the old client before launching the new version to avoid port conflicts. Test one profile and a subscription update in the new version; once you’ve confirmed the routing rules behave as expected, decide whether to clean up the old setup.

The system proxy only affects apps that use that setting; it does not route all device traffic through the client. First make sure the client is running and the core has started, then check that the system proxy address and port match the current listening port. Browser extensions, an app’s own proxy settings or enterprise policies may override the system setting. Compare results using a browser without separate proxy settings. If you enter proxy details manually, select the right type—HTTP or SOCKS—instead of copying only the port number. If the app doesn’t support the system proxy, consider TUN. Don’t enable multiple traffic-capture modes before verifying that regular proxy mode works.

System proxy mode determines whether an app sends requests to the client. Routing mode determines whether requests that reach the core are proxied, connected directly or blocked. Choosing a proxy route won’t make an app that ignores the system proxy send traffic to the client; clearing the system proxy may not stop traffic handled by TUN or an app’s manual proxy settings either. For troubleshooting, keep the traffic entry point fixed, then change routing rules and compare the result for the same destination. Presets such as bypassing mainland China depend on their specific rules and DNS results, and custom rules may take precedence. Note the current mode before changing it so you can tell what worked; changing the entry point, routing and DNS all at once makes that difficult.

In v2rayNG’s per-app proxy settings, first check whether the current mode proxies only selected apps or bypasses selected apps, then choose the apps you want to handle. The two lists work in opposite ways, so the checkmarks alone can be misleading. Save your changes, reconnect as prompted and test by making a request in the target app. Existing persistent connections may require closing and reopening the app. System components, shared services and external apps launched by an app can also affect the result. If other apps unexpectedly connect directly, check the list mode and selected apps first, then review routing. Don’t immediately switch servers or clear all your settings.

First check whether disconnections happen only when the screen is locked, the app is in the background or the network changes. Check whether Android restricts v2rayNG’s background activity, battery use or mobile data, and allow the background activity the app needs in your device settings. Some systems also have autostart or background-lock options. After changing a setting, lock the screen and wait before testing; don’t change every battery-saving option at once. Keeping a connection active uses some battery. Per-app proxying can limit which apps are handled, but won’t reduce power use in every situation. If disconnections also happen while the app is open, check the connection, server and logs instead of expanding background permissions further.

A single timeout isn’t enough to tell whether a server is down. First distinguish a TCP connectivity test from a real connection test: the former mainly checks whether the target port accepts a connection, while the latter also depends on the proxy handshake, test address and DNS resolution. Run a few tests against the same server, then compare with a known-working profile. If only one profile fails, check its address, port, authentication details and security layer parameters. If all profiles fail, check your local network, whether the core started and whether the test destination is reachable. An incorrect system clock can also affect authentication or certificate validation. Sync the time, then use the logs to narrow down the cause.

Connected often means only that the local proxy service or Android VPN interface has started; it doesn’t confirm a successful handshake with the remote server. Make sure the right server is selected, run a real connection test and review the logs. Then check that the browser is using the current proxy, the system proxy port matches and no other traffic-capture tool is running. If some sites work but others don’t, check routing rules and DNS. If nothing works, compare with a known-working profile. Change one setting at a time and keep a record of the original value. If direct connections still fail after closing the client, check whether the system has a manual proxy set to a port that is no longer listening.

First identify whether the unresolved name is the server’s hostname or a destination hostname accessed through the proxy. If the server hostname can’t be resolved, the remote connection can’t start; check that DNS works on your local network and that the server name is correct. For a destination hostname, check the core’s DNS settings, routing rules and the route used for DNS requests. With TUN, also consider whether system DNS is being intercepted or another network tool is changing settings. Don’t replace every resolver at once, or casually substitute an IP address when the server name is required for verification. Note the exact error and which type of hostname is affected, restore a working setup, then adjust one setting at a time.

Close any duplicate client instances, then check whether another proxy tool is listening on the same port. On Windows, use the Network tab in Resource Monitor to find listening ports and their processes; on other systems, use the available port inspection tools. Identify a process before deciding whether to stop it—don’t terminate an unfamiliar system service. You can also choose an unused local port in v2rayN’s settings, then restart the relevant services. After changing ports, reapply the system proxy and update any proxy address entered manually in browsers, terminals or other apps. Check the HTTP and SOCKS listeners in your current version; don’t assume every version uses the same ports.