V2Ray FAQ

For desktop use on Windows, macOS, and Linux, start with v2rayN. On Android, v2rayNG, which uses the Xray core, is the usual choice; consider v2flyNG when you need a V2Fly-based configuration environment. The client handles subscription management, the interface, and proxy controls, while the core parses configurations and establishes connections—they serve different roles. Choose based on your operating system, then check that the client supports the server's protocol, transport, and security layer. Don't judge compatibility by the client name alone. Installing a client does not provide a working service; you'll still need a subscription or connection configuration you're authorized to use.

VMess and VLESS are proxy protocols; REALITY is a security-layer mechanism, not a separate outbound protocol on the same level. A common setup pairs VLESS with REALITY, but the client must support the protocol, transport, and security layer together. After importing a configuration, compare its address, port, user ID, and serverName with the server settings. Check the REALITY publicKey and shortId as well, and match the required flow if the server specifies one. Simply selecting REALITY as the security layer won't make an existing configuration compatible. Ask the configuration provider about any missing parameters.

A subscription URL lets a client fetch a set of configurations and is accessed again for future updates. A single-node share link describes one connection and won't automatically reflect subscription changes after import. Check whether the provider gave you a subscription URL or a node share link, then use the matching import option. Pasting a subscription URL into a single-node editor may cause a format error or leave the list empty. Subscription URLs may contain access credentials, so treat them like account information. Don't post the full URL, QR code, or screenshots containing credentials in public forums when troubleshooting.

Consider converting a subscription only when its original format isn't supported by the target client. If the client can import it directly, keep the original subscription. Conversion usually just reshapes configuration fields; it won't extend the subscription or fix an unavailable server or missing authentication parameters. Third-party conversion services may access the full subscription URL and its credentials. Check that you trust the service, and prefer a compatible format provided by your subscription provider. After conversion, verify the transport, security layer, flow, and routing settings individually. A successfully generated configuration doesn't guarantee a working connection.

In v2rayN's subscription group settings, adding a label and subscription URL and saving usually creates a group—it doesn't fetch nodes. Return to the main window, update that group, confirm configurations appear in the list, then select the one you want as the active server. Menu names may vary slightly by version, so follow the options in your current interface. If the group already exists, check that the URL wasn't truncated or copied with extra spaces, and that you're updating the right group. Creating multiple groups with the same name can leave duplicates and make results harder to verify.

In v2rayNG's subscription settings, add a name and the complete subscription URL. Save, return to the configuration list, and update the subscription to fetch its entries. If you have a single-node share link instead, use the matching option, such as importing from the clipboard. Once the configuration appears, select it and start the connection. The first time, approve the VPN connection prompt from Android. The status icon means the local connection service has started; it doesn't guarantee the remote server is reachable. If you still can't access the internet, check the logs, active configuration, and DNS settings instead of repeatedly importing the same content.

Choose arm64 if your device uses a 64-bit ARM architecture. If you're unsure of the architecture or need compatibility with other supported architectures, choose universal; the package is usually larger. Most recent mainstream phones use 64-bit ARM processors, but the device's actual system environment may differ, so check its specifications and the app's compatibility requirements. If installation fails, check the Android version, available storage, signing compatibility with any existing app, and whether the package downloaded completely. An installation issue doesn't mean you need a different protocol; package architecture and connection settings are separate concerns.

Close other apps that may be managing network traffic, then grant the permissions required to create a virtual network adapter and modify routes on your platform. Windows usually requires administrator privileges; on macOS and Linux, follow the authorization prompts in the client. The exact steps depend on the version and installation method. Once permissions are granted, check that the core starts normally, then enable TUN and review the logs. If the regular system proxy worked before, keep it as a baseline and test changes one at a time. Don't leave system protections disabled to get around a permissions issue. If an adapter or route is left behind, stop TUN first and check the system's network status.

The system proxy provides a proxy address to apps that honor system proxy settings; it doesn't force every process to use it. First check that the v2rayN core is running, the local listening port is correct, and automatic system proxy configuration is enabled. Then see whether the app uses its own proxy settings, environment variables, or networking implementation. Browser extensions may also override system settings. If only a few apps bypass the proxy, configure a local proxy in those apps. Consider TUN only if you need broader traffic capture. Clear the system proxy before closing the client so the system doesn't keep pointing to a stopped local port.

The system proxy determines whether an app sends traffic to the client; routing rules determine whether traffic that reaches the core is proxied, sent directly, or blocked. These are separate settings. For everyday use, start with a routing preset that matches your needs, then check whether specific domains match the expected rules. Temporarily routing all traffic through the proxy can help identify a split-routing issue, but it still won't make every app send traffic to the core. Restore your usual policy after testing and check LAN access and DNS behavior. Avoid permanently rerouting all connections to fix a problem with just one site.

It depends on whether your current network can reach the subscription URL directly, not on the node protocol. If direct access works, update without the proxy to avoid relying on an existing connection. Use the proxy only if the subscription URL requires an already working connection. If the active node is down, updating through it will likely fail too; switch to a direct update or select another configuration you've confirmed works. Before changing the automatic update interval, complete one manual update successfully. Then set the interval based on the subscription's validity and how often you use it, rather than using frequent requests as a substitute for troubleshooting.

When migrating, first add the existing valid subscription to the new client. Check local ports, system proxy, DNS, and routing separately, since these settings may not be included in the subscription. If you must export a configuration, transfer it only through a trusted local or controlled channel, then delete temporary files and clear clipboard history. Configuration fields aren't universally compatible across clients and cores, especially transport options, flow, and security-layer parameters. Don't overwrite the entire configuration directory and immediately enable TUN. Verify one connection first, then restore split routing and traffic capture step by step.

First confirm the device itself can access the internet. Then check whether the subscription has expired, the correct configuration is active, and the address or port was changed by mistake. Review the client logs to distinguish DNS resolution failures, connection timeouts, authentication failures, and handshake errors; each calls for a different fix. Compare with another configuration from the same subscription, but don't conclude that a protocol is unusable based on one test. If all entries fail, check the local network, DNS, firewall, and system time first. If only one entry keeps failing, ask the service provider to check its status. Reinstalling the client repeatedly can hide the error rather than solve it.

Connected may only mean the core or local network service started successfully; it doesn't mean the destination site is reachable. Check that the right configuration is active and the system proxy is set correctly, then use the logs to determine whether DNS resolution failed, the remote connection failed, or traffic never reached the client. If you're using TUN, stop it temporarily and test the basic connection with the system proxy to separate virtual adapter issues from protocol issues. Also check for other proxy apps, browser extensions, or security software changing network settings. Change one thing at a time and note the result. Resetting DNS, routes, and the subscription all at once makes the cause harder to identify.

Check that the subscription URL is complete, especially any parameters after the question mark, and remove line breaks or spaces added during copying. Then confirm the account is active and the provider's required subscription format. A URL that opens to a login page, error page, or empty response hasn't necessarily returned configuration data to the client. If the error mentions Base64 or protocol fields, don't repeatedly re-encode the entire content. Check whether the client supports the source format and keep the original URL. After updating, verify the selected group and filters so a filtered list isn't mistaken for an empty subscription. If needed, ask the provider for a format supported by your client.

Check whether the error occurs while accessing the subscription URL, downloading the response, or parsing its contents. Confirm the subscription hasn't expired or been reset. If the link was reset, the old URL may no longer work even if it's still saved in the client; replace it with the complete new URL. You can test both direct and proxied updates, but only if each network path is available. For a proxied update, also check the active node. If the server limits request frequency, stop retrying and wait as the provider recommends. When reporting the issue, share only the client name, system environment, and an error summary with credentials removed—never the full subscription URL.