Client FAQs

Use v2rayN on Windows, macOS, or Linux. On Android, v2rayNG with the Xray core is the usual choice; consider v2flyNG when you need compatibility with V2Fly configurations. Choose based on your operating system, then check the protocols, transport, and security settings required by the server. The clients have different menus and configuration support, so similarly named options are not necessarily interchangeable. For settings such as REALITY, confirm that your client and core versions support the required fields.

A client reads configurations, connects to servers, and applies routing rules; installing one does not provide a server. Before getting started, make sure you have permission to use a subscription URL, share link, or complete server configuration. Check that the address, port, authentication details, transport, and security settings are all available. Subscription URLs and share links may contain credentials, so don't post them publicly or share QR codes from configuration screenshots. If you only have some of the required details, get the rest before importing or connecting.

VLESS is a proxy protocol, REALITY is a transport security option, and Xray is the core that applies these settings. They are not interchangeable options at the same level. A common setup uses VLESS as the protocol and REALITY for security, with the transport and related parameters set as required by the server. Changing the protocol to REALITY or switching cores alone will not supply missing fields. If a configuration isn't supported, check the client and core capabilities, then verify the combination required by the server.

On desktop, a system proxy tells apps that honor the setting which proxy address to use; some apps ignore it. TUN routes matching traffic through a virtual network interface and usually requires permissions, routing, and DNS configuration. On Android, v2rayNG uses the system VPN interface to create a local forwarding tunnel and requests permission the first time it connects. This doesn't mean all traffic necessarily goes through the remote server; routing rules and app scope determine what is covered. When troubleshooting, choose one traffic-capture method to avoid overlapping routes from multiple proxy tools.

Most recent Android phones support arm64, but choose based on the app architectures supported by the device's operating system, not just the processor model or purchase date. If you know the system supports 64-bit ARM apps, choose arm64. If you're unsure, choose universal; it includes multiple architectures but is usually a larger download. If installation fails with a parsing error, check the Android version requirement, confirm the download completed, and look for a signature conflict with an older version. Before uninstalling an existing client, export any configurations you want to keep.

First check whether you copied a subscription URL or a single share link. Add subscription URLs to a subscription group; use the client's link import option for share links. Check for extra text, line breaks, spaces, or punctuation added by a chat app, then make sure the app can access the clipboard. If the group exists but the list is empty, update the subscription; saving the URL alone doesn't confirm that it was fetched successfully. If it still fails, check the update log to see whether the link couldn't be reached or the response couldn't be parsed.

The first time v2rayNG connects, allow the VPN connection request shown by Android. If you denied it, stop the connection, start it again, and approve the request. Also check for another app using the VPN interface, work profile policies, or an always-on VPN restriction. Desktop TUN requires the services and permissions specified by the client; Android steps don't apply. If it still fails, check the logs for permission or virtual interface errors. Repeatedly changing protocols won't fix a system authorization issue.

Use the current client's export or backup option to save subscription groups, manually added servers, and custom routing rules. Note your local ports, DNS settings, and app scope as well. Backups may contain credentials, so store them somewhere secure. After importing into the new client, check the fields and test a configuration you know works. Extended fields may not transfer fully between different cores. Keep renewable subscription entries separate from manually edited ones, and remove the old configuration only after confirming the migration worked. Don't make reinstalling your first step.

Choose a routing preset that matches your needs, then check local network addresses, domains that should connect directly, and the default outbound route. Custom rules are usually matched in order, so put specific exceptions before broader rules. Make sure the geosite and geoip data your rules reference are available in the current core. Don't judge routing only by whether a page loads; check the destination and outbound route in the client logs. After changing rules, start a new test connection and, if needed, close existing app connections so connection reuse doesn't preserve the old route.

Make sure the client has a working configuration selected and the core has started. Then check that the system proxy points to the local listening address and port currently in use. SOCKS 10808 and HTTP 10809 are common defaults, but use the values in your client rather than assuming they apply. Check whether browser extensions, app-specific proxy settings, or other proxy tools override the system settings. As a comparison, configure the same local port in an app that supports manual proxy settings. If that works but the system proxy doesn't, check whether the app follows system proxy settings.

Subscription entries are usually managed by the content returned from the subscription and may be regenerated or replaced during an update. Don't rely on edits to subscription entries for settings you need to keep. If you need to change the transport, remarks, or other parameters, duplicate the entry as a standalone configuration if the client allows it, and label it clearly. Standalone entries may still stop working if the server changes. Routing rules, subscription group settings, and server fields are separate configuration layers, so check and back them up separately. After updating, make sure the selected server is still there and hasn't been removed or replaced.

First check whether the system is stopping the app or the connection is repeatedly retrying. If the app is being stopped, the tunnel may disappear when the system closes it; repeated connection errors usually appear in the logs. Allow background activity as needed, and check battery optimization and auto-start restrictions. Don't disable power saving for every app. Reduce unnecessary automatic tests, overly frequent subscription updates, and continuous verbose logging, then compare performance on the same network. Battery use also depends on signal strength, transport, and traffic; a protocol name alone can't tell you which configuration will use less power.

Check the logs to see whether a response was received. A connection timeout, certificate error, and parsing failure are different issues. Make sure the subscription URL hasn't expired and its credentials are still valid. Check whether the response is actually a login page, an error page, or a format the client doesn't support. If updates need to use an existing proxy, verify that proxy works before choosing the appropriate update method. Don't post the full subscription URL publicly or repeatedly delete and recreate the group. Keep the existing configuration and check one issue at a time so you can continue using valid entries while updates are unavailable.

A test timeout only means that particular test didn't complete within its time limit. It may depend on the test address, DNS, connection method, or server status; it doesn't necessarily mean all traffic is unavailable. First check whether the test measures TCP connectivity or makes an actual request. Then use the same configuration to visit a known test page and check the logs. If requests also fail, verify the address, port, authentication, transport, and security settings, and compare results on another network. Don't treat occasional results from repeated tests as a performance benchmark or choose a configuration based on a single test number.

Connected often only means the local core or VPN interface has started; it doesn't guarantee that the remote connection, DNS, and routing are working. Check the logs for authentication, handshake, or resolution errors, then confirm that browser traffic is reaching the client. If domain lookups fail, check DNS settings and the query path. If only some sites fail, check which routing rules match and which outbound route is selected. If all requests fail, verify the server settings and system time. Change one type of setting at a time and keep the original values so you can identify the cause.

Disabling certificate verification isn't a recommended general fix. First check the device's date and time, the server name, the server's certificate configuration, and the security fields required by the protocol. A TLS server name may differ from the connection address; use the values provided by the server. For REALITY, also verify the public key, short ID, and other parameters. Changing the server name at random won't make them match. Note the error type and when it occurs, then ask the configuration provider which fields are required. If the error only occurs on one network, compare with another, but identify the cause before changing security settings.