Client FAQs

Choose a client based on your device. For Windows, macOS, and Linux desktops, start with v2rayN. On Android, v2rayNG with the Xray core is the first choice; v2flyNG, which uses the V2Fly core, is an alternative. The client imports and selects configurations and manages the proxy; the core handles connections and traffic forwarding. Whether a configuration works also depends on whether your installed version supports its protocol and transport combination, so similar names alone don't guarantee compatibility. If you already have a working configuration, check its protocol fields before switching clients.

First check whether the client's server list already contains a configuration. The installer provides the interface and components needed to run the client; it does not generate a remote server address, port, or authentication details. A subscription lets you retrieve multiple configurations, while an individual share link usually represents one configuration. Before importing, verify the source, validity period, and compatible clients. The client may be free, but the remote service's fees and terms are set by its provider. Installing the software does not mean the remote service is ready to use.

Start by distinguishing how traffic enters the proxy. A system proxy writes the proxy address to system settings and mainly affects apps that honor those settings. TUN mode receives matching network traffic through a virtual network interface and involves routing, DNS, and additional permissions. v2rayNG's VPN mode uses Android's VPN interface to receive traffic on the device; the permission prompt is required to create that interface. These options are not interchangeable global switches, nor do they guarantee that all traffic goes to the remote server. Actual traffic paths depend on routing rules, app scope, and exclusions.

Check the protocol, transport, and security settings in the configuration, then confirm that the current core supports that combination. VMess and VLESS are different protocols; changing the protocol name alone won't convert one into the other. TLS, REALITY, WebSocket, and other fields must also match the server. If a share link imports successfully, that only means the client recognizes its contents; it doesn't guarantee the remote parameters are correct. If a field isn't supported, use a subscription format compatible with your client or ask the configuration provider to confirm the details. Don't guess at authentication settings.

Check your device specifications or a trusted system information page to confirm the processor architecture. Most newer Android phones can use the arm64 package, which includes components for that architecture only and is usually smaller. The universal package supports multiple architectures and may suit devices with an unknown architecture, if installation requirements allow. Purchase date is only a clue, not a substitute for checking the architecture. If installation fails, also check Android compatibility, available storage, and whether an app with the same name but a different signature is installed. Back up your configuration and important settings before replacing an older version.

Open the subscription group settings and make sure you pasted the complete subscription URL, not a purchase page, information page, or individual share link. Check for spaces, line breaks, or quotation marks added during copying, and make sure the URL's trailing parameters weren't cut off. Then identify whether the error occurs when saving the URL or fetching its contents: the former is often a formatting issue, while the latter may involve the network, authorization, or the response. If the URL opens to a login page, the client still can't parse it as a subscription. Hide authentication parameters in the full subscription URL before sharing troubleshooting details.

First confirm that v2rayNG is set to VPN mode. The system must allow the client to create a local VPN interface so it can receive app traffic and pass it to the core for processing. Proxy-only mode instead requires other apps to be configured with the local proxy address. Read the system permission prompt before deciding whether to allow access. If the prompt doesn't appear or the connection stops immediately, check whether another VPN, work profile policy, or device management restriction is occupying the interface. Don't keep switching between VPN apps; disconnect existing VPNs and launch v2rayNG on its own to test.

Turn off TUN mode and confirm that a regular proxy connection works. Then check permissions and the virtual network interface as instructed by your current version. On Windows, you may need to run with elevated privileges or enable a service provided by the client. Authorization on macOS and Linux depends on the specific package and version. Follow the app's prompts and documentation for your version; don't reuse commands intended for another operating system. If it still fails after granting permissions, look for the first log error related to interface creation, routing, or a port conflict. Record the original settings before making changes, and adjust one item at a time to help identify the cause.

Select the server you want to use and run the client's connection test, then make sure system proxy or VPN mode is enabled. Open a known-working HTTPS page in the target app and check the client logs for the corresponding request. A successful test only confirms that the test destination is reachable; it doesn't mean every app and site will work. Don't change the server, routing, and DNS at the same time while testing. Keep one configuration as a baseline. If the browser works but other apps don't, check whether those apps use the system proxy before replacing the subscription.

In v2rayNG settings, open per-app proxy, read the explanation for the current mode, and then select apps. Bypass selected apps usually means apps on the list won't use the proxy interface, while other apps follow the current rules. Proxy only selected apps limits the scope to apps on the list. Labels can vary between versions, so follow the actual meaning shown in the interface. Even after an app uses the interface, routing rules may send its traffic through the proxy or directly. Reconnect after changing the list, then fully close and reopen the target app before testing so existing connections don't skew the results.

Make sure you changed the routing configuration currently in use, and check that the rules are enabled and in the right order. An earlier, broader rule may match first and prevent a more specific rule below it from running. After saving, reload the configuration or reconnect as required by the client, then close the target app's existing connections and test again. Browser, connection, and DNS caches may preserve previous results. Don't rely only on an external IP lookup to determine how every domain is routed. Check the target domain, matching rule, and logs to tell whether the rule failed to apply or the test was unsuitable.

In v2rayN's parameter settings, check that LAN connections are allowed, and confirm the actual listening port and supported proxy types. On other devices, enter the LAN address of the computer running the client, not a loopback address that refers to the device itself. Make sure both devices are on a network that allows them to communicate, and configure the firewall to allow the relevant port only on trusted networks. Guest network isolation may also block connections. Share access only on a controlled LAN; don't expose the listening port to the public internet. Turn sharing off when you're done and remove any firewall exceptions you no longer need.

Turn off the proxy and confirm that your local network can access sites normally. Then test another known-working configuration in the same client. If only one server times out, check its address, port, service validity, and transport settings. If all servers time out, first check your network connection, system clock, DNS, and local security software. A failed connection test alone doesn't prove the server is offline; the test destination may be unreachable. Note when the error occurred and the first connection error in the logs, then try another network. Avoid changing several settings at once, which can hide the original cause.

First confirm that a server is selected in the client. Check that the system proxy is set to automatic configuration, and verify that the proxy address and listening port in system settings match the client. “Connected” often means only that the local service has started; it doesn't confirm that the remote server is reachable. If no apps work, check the server test and logs. If only some apps fail, check their own proxy settings and whether they support the system proxy. Don't enable TUN before ruling out a port mismatch. If access still fails after closing the client, check for and clear any leftover local proxy settings in the system.

Keep your existing working configurations; don't delete the entire subscription group just to try again. Read the update error and determine whether it indicates a parsing failure, request timeout, or expired authorization. For a parsing failure, confirm that the response contains subscription data. For a timeout, check whether your current network can reach the subscription URL. If authorization has expired, ask the provider to confirm the URL and validity period. If the client offers an option to update through a proxy, first make sure that proxy works to avoid depending on the update itself. Also check the system clock and certificate errors. Once updates work again, review the group contents and then remove any old duplicates.

First distinguish a background process being stopped from a DNS resolution failure. If the connection icon disappears after screen lock and the client needs to be restarted, check the system's battery settings for background activity and power-saving restrictions, and see whether another VPN has taken over the interface. If the icon remains but domain requests fail, check the logs for resolution errors, then review DNS and routing settings. Don't assume every issue is caused by power saving or DNS. Record the connection state before and after locking the screen, the time, network type, and specific error. Remove subscription URLs and authentication fields before sharing, then retest each symptom separately.