v2rayN and v2rayNG
FAQs

For desktop, start with v2rayN and choose the package for Windows, macOS or Linux. On Android, v2rayNG with the Xray core is the usual starting point; consider v2flyNG if you need the V2Fly core. Similar names do not mean these are different skins of the same app. Check that the client supports the protocols, transport and security settings your configuration requires—features may differ between the two core branches. Before switching, keep your existing configuration. Import it into the new client and verify the connection before removing the old one.

The client reads configuration, runs the proxy core and handles traffic on your device; it is not a server you can connect to by itself. A subscription URL usually provides a set of server configurations, while a share link typically contains one configuration. Both must come from a service you are authorized to use. After importing, check that servers appear in the list, select one as active and start the connection. Subscription URLs may contain credentials, so do not post them in public comments, screenshots or online parsing tools. When asking for help, share only the error type and relevant settings, and redact URLs, user IDs and subscription parameters.

VLESS is a proxy protocol, REALITY is a transport security mechanism, and Xray is a core that processes the configuration. They are not interchangeable client names. A connection also depends on the transport, port, flow control and security settings provided by the server. For a REALITY configuration, confirm that the selected client and core support it, then check fields such as the public key, server name and short ID. Do not simply switch the security setting to REALITY and try to connect, or reuse a standard TLS configuration. Use the exact values supplied by the server.

Most recent Android phones can use arm64, which targets the corresponding processor architecture and is usually a smaller download than the universal build. The universal package includes components for multiple architectures, making it a suitable choice if you are unsure which one your device uses; it is not a feature-enhanced edition. A phone’s age alone does not reliably indicate its architecture, so check the system information on older or unusual devices. If installation fails, check the Android version, architecture and available storage. If you see a signature conflict, do not immediately uninstall the existing app. Back up your configuration and confirm that both packages are for the same client and that the new release supports upgrading over the existing installation.

First distinguish a subscription URL from a single server share link, then use the corresponding option, such as a subscription group or import from clipboard. Check for leading or trailing spaces, line breaks and text added by chat apps, and make sure you copied the full URL—not the subscription management page URL. If the group exists but the server list is empty, try updating it once and check the logs. For a fetch error, check the network, URL expiry and access permissions; for a parsing error, check the response format and client compatibility. A URL opening in a browser does not mean it contains a valid subscription—it may return a login page or an error message.

Keep your existing server list; do not clear all configurations just to retry. Check whether the subscription has expired, its URL has changed, and the device date and time are correct. Then use the logs to identify a connection timeout, certificate error or access denial from the server. If the client can update subscriptions through a proxy, confirm that the active server is reachable. If the update relies on a server that is no longer working, try a direct update if your network allows it. Change one setting at a time and record the result. If the problem persists, ask the subscription provider to check its status. Repeatedly clicking Update will not fix expired URLs or access issues.

First make sure a server is selected as active and the core has started normally. Then choose the option to set up the system proxy automatically from the system proxy menu. Starting the core and changing the system proxy are separate actions; an open main window does not confirm that both have happened. Check that the system proxy address and port match the client’s local listener, that your browser uses the system proxy, and that no other proxy tool or extension is overriding the settings. Some apps do not use the system proxy, so configure a proxy within the app or use an appropriate traffic-routing mode. If the network behaves unexpectedly after you exit the client, check for proxy settings still pointing to a closed local port.

Turn off TUN first and confirm that a standard proxy connection works, so you do not mistake a server issue for a permissions problem. TUN uses a virtual network interface and routing settings; required permissions depend on the operating system and client version. On Windows, grant administrator access as prompted by the client. On other desktop systems, follow the authorization instructions for your version. If the logs report that the interface could not be created, check the virtual adapter components, security software blocks and conflicts with other tunneling tools. Do not leave the firewall disabled as a troubleshooting measure. Run only one traffic-capturing tool during testing, then check that DNS and routing behave as expected.

A system proxy usually tells apps that honor the setting to send requests to a local proxy port. TUN uses a virtual network interface to capture traffic that matches its rules, so its reach is broader. Android clients commonly use VpnService to create a local traffic-forwarding interface; the first connection requires system authorization, but that does not give the client server configuration automatically. All three approaches are still affected by routing, DNS and app behavior. For everyday browsing, start with the simplest option that meets your needs. Consider TUN or mobile traffic capture when you need to cover apps that ignore the system proxy; there is no need to enable every mode at once.

Choose a routing mode based on what you need to access. Bypass mainland China typically sends traffic matching domain and IP rules directly, while routing the rest through the proxy. Global proxy generally prioritizes proxy routing for traffic that reaches the client, but it does not guarantee that every app is captured. For troubleshooting, switch temporarily to global proxy and test the same destination; if it works, the issue may be with split-routing rules. Reconnect after switching, since existing connections may keep using the old route. If only certain domains fail, check rule order, rule sets and DNS results rather than treating global proxy as a permanent fix for every problem.

After enabling per-app proxy, confirm what the selected mode means. Bypass mode usually excludes selected apps from the proxy tunnel, while Proxy Only mode usually sends only selected apps through it; check the current screen’s description. Test with one easy-to-check app, then add more gradually so you can identify the effect of each change. Restart the client connection and fully close and reopen the target app. System components, download services and requests handled on behalf of another app may not follow the foreground app selection exactly. Check the logs and test real requests rather than relying only on which apps are checked.

First confirm the proxy works on the host, then enable connections from the LAN and check the actual listening protocol and port. In the host firewall, allow the relevant inbound connection only from a trusted local network. On other devices, enter the host’s LAN IP address and proxy port—not 127.0.0.1, which refers to the device itself. The devices must also be able to reach each other; guest networks and wireless client isolation can block connections. Never expose the local proxy port directly to the public internet. Turn off sharing when you are done. The proxy will stop working for other devices if the host sleeps, its IP address changes or the client exits.

Check the logs to see whether the server hostname resolves, then whether a connection can be made to the target address and port. A DNS resolution failure is different from a connection timeout. Check the port, transport, system time and server status, then compare with another configuration known to work. If possible, test using a phone hotspot, but do not change multiple settings at once. If every configuration times out only on one network, check that network, its firewall and local traffic-capture settings first. If only one configuration keeps failing, ask the configuration provider to check the server. A failed latency test alone does not prove that the actual connection cannot work.

Connected may only mean that the local service has started or a system tunnel is up; it does not mean requests to a website are succeeding. Test a regular HTTPS page, then check whether the request appears in the client logs. If there is no entry, check the system proxy, browser settings, per-app list or TUN capture scope. If the request appears but fails, check the active server and protocol settings. If only domain names fail, investigate DNS. During testing, turn off other proxy tools and browser extensions that may override proxy settings. After each change, reload the page or reconnect to avoid interference from cached data or old connections. Do not reset every setting at once.

It could be, but routing rules, restrictions on the destination site or a server-side connection failure are also possible. Note the affected domain and error, then check the logs for the resolution result, matching rule and selected outbound route. If the same domain behaves differently over direct and proxy routes, review how client DNS, system DNS and browser encrypted DNS interact, and whether any of them bypasses the intended resolution path. Do not enter DNS server addresses from unknown sources. Testing an IP address instead of the HTTPS domain is also unreliable because certificates and site hosting can affect the result. Change one setting, clear the relevant cache or reconnect, then repeat the same test.

First use the system battery stats to confirm that the client is actually using significant power, and distinguish sustained heavy data transfer from frequent reconnections. If it disconnects only when the screen locks, check background activity restrictions, autostart permissions and battery optimization. If you need a persistent connection, allow background activity in the system settings, keeping in mind that this can increase standby battery use. Do not run multiple apps that compete for the system VPN slot. If the connection keeps restarting, check Wi-Fi or mobile network switching, server stability and errors in the logs; do not use keep-alive settings to mask a broken link. After making changes, observe the client under similar conditions for a while rather than comparing a single short battery reading.