v2rayNG FAQ

Work through three steps. First, make sure you have a subscription URL rather than a web page address: opening a subscription URL returns encoded text or a node list, not an introduction page. Second, check whether the address was truncated - copying from a chat window or web page easily drops trailing path parameters, so copy it again in full. Third, verify with another import method: in v2rayNG use Import subscription from clipboard to paste the address, and if it still errors, open the address directly in a browser and see whether the response is an error page or a login page.

If the address itself has expired, no amount of fiddling in the client will fetch nodes - ask your provider for a new subscription URL. After a successful import the nodes appear in the list by group; run a Real delay test before picking one.

It depends on the processor architecture. Most phones released after 2015 use 64-bit ARM chips, so the arm64 build is the right pick - smaller package, better performance. The universal build bundles libraries for several architectures, which covers older devices and emulators at the cost of a larger installer.

If unsure, install arm64 first and switch to universal only if the system reports that the app was not installed or the package could not be parsed. App data is not shared between the two builds, so copy your subscription URL before switching and import it again afterwards.

Proxy only sends just the traffic matched by routing rules through the proxy and connects everything else directly, which suits finely written rules; Bypass LAN proxies all traffic while excluding private network ranges (192.168.x.x, 10.x.x.x and so on), the usual choice on home and office networks; Global sends everything through the proxy and is handy for a quick check of whether a node works.

Switching takes effect only after you disconnect and reconnect. For everyday use, stay on Bypass LAN; when one app misbehaves, switch to Global temporarily for a comparison and you can tell whether the problem lies in the split rules or the node itself.

v2rayNG's per-app proxy offers two modes: a whitelist that proxies only the selected apps, and a blacklist that proxies everything except the selected apps. By default all apps go through the proxy.

A common approach: whitelist browsers, mail clients and developer tools, and exclude banking, payment and food delivery apps that are sensitive to network environment, reducing friction from login risk checks and region verification. After any change, disconnect and reconnect so the new split rules take effect. The list is sorted by app name, so leave anything you cannot identify unchecked for now.

Tap Update subscription manually once and read the message it returns. There are three common causes: the provider changed the token or path in the subscription URL, so the old address returns 404; the subscription domain cannot be resolved on the current network, so try another connection (switching from Wi-Fi to mobile data, for example); or the client's automatic update interval is long and it does not refresh on every launch.

Once the address is confirmed working, turn on automatic updates in the subscription settings. It is worth keeping a copy of a node share link as a fallback, so you can import the key nodes by hand while the subscription is temporarily unavailable.

Troubleshoot from the outside in and change only one variable at a time. Step one: turn the proxy off and confirm the device's own network works. Step two: switch to another node to rule out a single dead node. Step three: check routing mode and per-app proxy to confirm the current app is covered. Step four: look at DNS settings, since local resolution failures block pages even through a working proxy. Step five: if only a few sites misbehave, it is most likely those sites' own access policy and nothing to do with the node.

It helps to note the result of each step; once you have located the specific link, adjust it directly - far more effective than reinstalling the client over and over.

When every node fails at once, the problem is usually outside the client. Update the subscription manually to confirm the node information has not expired; then test on another network to see whether the current Wi-Fi or line is at fault; then check the system clock, because time-sensitive protocols such as VMess are very sensitive to clock drift and an inaccurate clock causes handshake failures outright.

If some nodes recover on another network, the issue is with individual lines; if everything still fails on mobile data, the problem is almost certainly on the subscription side and you should check with your provider.

TUN mode takes over traffic through a virtual network interface and needs VPN permission from the system. The first time you enable it, the system shows an authorisation dialog and you must tap allow, or the connection drops immediately. If you declined before, re-authorise it in the system settings under VPN or app permissions.

Two other common causes: only one app can hold the VPN channel at a time, so first confirm no other proxy app is running; and some customised systems restrict background launches, so add the client to the background-run whitelist in the battery and performance settings. TUN mode captures more traffic than the system proxy, so after enabling it, confirm the outbound address has changed with a test page.

First confirm the system proxy switch is on and the mode is set to Auto configure system proxy or Global. If the browser has a proxy management extension, the extension overrides system proxy settings, so switch it to follow the system or disable it temporarily.

One more case: programs running with administrator rights do not always read the current user's proxy settings, and those need TUN mode to capture their traffic. After changing settings, restart the browser so the new proxy configuration takes effect, then open a test page to confirm the outbound address.

A DNS leak means domain resolution requests bypass the proxy tunnel and are resolved by the local network or ISP DNS. To detect one: connect and open a DNS leak test page, then check where the resolving server is located; if it shows a local ISP or router address, there is a leak.

To prevent leaks, enable remote DNS so resolution happens on the node side, and give DNS queries their own route in the routing settings; on desktop you can also specify a resolver address that does not go through the local network in the DNS settings. Reconnect after the change and test again to confirm. DNS settings and routing rules affect each other, so change one item at a time.