The Complete v2rayN Troubleshooting Guide

No Internet Access: Find Where the Request Stops

“The client is running” and “the app is using the proxy” are two different things. A request typically passes through the app, the system proxy or virtual network adapter, a local inbound, routing rules, and a remote node before reaching its destination. If any step fails, the page may not load. Start by noting the scope: do all apps fail, or just one browser? Do all sites fail, or only one domain? Does regular internet access return when you close the client? This helps narrow down the cause better than a single error message.

Compare regular and proxied connections

Close any other proxy tools, turn off the system proxy and TUN in v2rayN, and check whether you can open a site that normally works without a proxy. If not, check your network connection, gateway, Wi-Fi sign-in page, and system DNS before switching nodes. Public Wi-Fi may require a sign-in first; starting the proxy can make that page inaccessible. Once the regular connection works, start v2rayN, select a configured node, enable the system proxy, and visit the same test page in the same browser.

Next, open the client log, clear the current display or note the start time, then make one request. If no new connection appears, check whether the app uses the system proxy, whether the local port is correct, and whether a browser extension is intercepting requests. If the log shows the destination domain and outbound, the request reached the core. Check whether it failed during DNS resolution, dialing the remote server, the handshake, or the destination response. Informational logging is usually sufficient; enable more detail briefly only when needed to pinpoint an issue.

Test the local inbound without the system proxy

Use a SOCKS inbound for comparison, and replace the port with the one shown in the client settings. 10808 is only an example, not a universal port. On Windows, use curl.exe in Terminal; on macOS and Linux, use curl. The test URL helps check whether a connection completes, but it doesn’t represent every service. An HTTP status code alone doesn’t mean the proxy failed; consider whether the connection was established.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl --noproxy "*" --connect-timeout 10 -I https://example.com

The first command explicitly uses the proxy; the second bypasses it. Record both results. socks5h lets the proxy resolve the destination domain, keeping local DNS out of this test. If the first command can’t connect to the local port, check that the core is running and listening. If the proxy request succeeds but the browser fails, look at the browser’s proxy settings, extensions, or cache. Don’t use an HTTP inbound port as a SOCKS port; mixing the two can result in an empty response or protocol error.

Distinguish routing errors from destination outages

Once a request reaches the core, check whether it selects direct, proxy, or block. If a site is incorrectly routed to block, switching nodes won’t help; find the domain rule that matched. A request incorrectly routed to direct may also time out. Temporarily switch to a simplified proxy route and retry the same request. If it works, restore the original rules one at a time. Use this comparison only for diagnosis; don’t route every request through one outbound indefinitely. Keep appropriate direct routes for local networks and node server addresses.

If several commonly used services work but one destination doesn’t, consider a site outage, account restrictions, regional service policies, or a browser session issue. Try another browser session and another device on the same network before reinstalling the client. Final verification should cover one proxied destination, one direct destination, and one local network destination, with logs confirming the expected outbound. A working connection with incorrect routing is not a complete fix.

Node Timeouts: Check the Address, Port, and Handshake Separately

A failed node test doesn’t necessarily mean the server is down. A client test may include DNS resolution, establishing a transport connection, the protocol handshake, and a request to a test URL. A timeout at any step may produce the same result. First determine whether all nodes fail or just one configuration, and whether the issue occurs only on the current network. If all nodes fail, check the local network, DNS, proxy loops, and test URL first. If just one node fails, check its settings one by one.

Verify the connection target and put each setting in the right field

Open the node editor and compare the server address, port, protocol, transport, and security settings with the provider’s configuration. The server address is usually a domain or IP; it shouldn’t include a web protocol prefix or path. A WebSocket path, Host, and TLS SNI are separate fields; similar-looking values aren’t interchangeable. The port must be the remote service’s listening port. The local SOCKS port is for apps connecting to the client; using it as the server port sends traffic to the wrong service.

If the node came from a subscription, update it first in case the address has changed. Updating can overwrite subscription-managed nodes, so save a copy before making manual changes. Compare settings by changing only one at a time, not the transport, port, and security settings together. A password, user ID, or public key can be formatted correctly and still not match the server. Increasing the timeout won’t fix that; re-import a valid configuration.

Use the error type to see how far the connection got

A connection refused message usually means the connection attempt was rejected. Check the port, service status, and network policy. An i/o timeout or dial timeout means only that the expected operation didn’t finish in time. network is unreachable points more toward a local routing or address-family issue. Don’t treat all these messages as the same problem, and don’t assume a proxy is unavailable just because the server doesn’t respond to ping. A service can block that kind of probe and still accept normal connections.

If the TCP connection is established but a TLS or authentication error follows, check the handshake settings. First sync the system clock, then verify the SNI, certificate domain, and transport selected by the client against the server configuration. For REALITY, also check the public key, short ID, server name, and fingerprint, and confirm the selected core supports that combination. To limit variables, use settings the provider explicitly supports. Don’t mix parameters from another protocol into the current node.

Rule out network path issues and proxy loops

Test the same node on another trusted network. If it works over a mobile hotspot but not on the current Wi-Fi, check that network’s outbound restrictions, address-family support, and firewall. If it fails on every network, revisit the configuration and remote server. Reconnect after switching networks instead of reusing a session from the old one. If the node domain resolves to different address families, one address may resolve but be unreachable, slowing the connection. Check which address is actually dialed before changing address-selection behavior.

If timeouts start only after enabling TUN, traffic to the node server may be sent back through the proxy, creating a recursive route. Make sure the node server address is excluded correctly or that the client has created a direct route for it. Another possibility is that resolving the subscription URL or node domain depends on a proxy outbound that isn’t available yet. Turn off TUN, resolve the address and update the subscription over the regular network, then restore settings one at a time. This can help distinguish a startup dependency from a genuinely unreachable server.

Finally, verify the node connection separately from access to services. An unusual client test result may make several working nodes appear to fail. If websites work, check the test URL and method before deleting all your nodes. Note when the error occurred, which network you used, and the error type. Hide credentials before reporting it to your provider. For certificate-related issues, see Troubleshooting TLS Handshake and Certificate Errors. After fixing the issue, restore your original routing and operating mode.

Subscription Errors: Separate Download, Parsing, and Node Updates

Importing a subscription involves three steps: saving the URL, downloading its contents, and converting them into a node list. Saving a link doesn’t mean the download succeeded; receiving text doesn’t mean the client can parse it as node configuration. First identify which step failed and whether the list actually changed after updating. If existing nodes still connect but the subscription update fails, keep the working configuration and fix the update path first. Don’t delete the whole node list and lose the connection path you need for troubleshooting.

Check the URL and service status first

Verify the full URL in the subscription group settings, especially for line breaks, leading or trailing spaces, and non-ASCII punctuation added when copying. Some URLs include query parameters or access tokens; don’t remove everything after the question mark or change any characters. A provider’s management page may differ from its subscription endpoint, so use the URL explicitly labeled for subscriptions. An expired link, changed account status, or reset access token can make the old URL return an error page.

The response type can help identify the issue. Unauthorized or forbidden responses usually relate to credentials, account permissions, or service policy. A missing resource may mean the URL path changed. If requests are rate-limited, reduce the update frequency and try again when permitted. A temporary server error won’t be fixed by changing node credentials. Even a seemingly successful response may contain a login page or message instead of subscription data; check the client’s parsing error to confirm the response isn’t a web page.

Resolve the “subscription needs a proxy, but the proxy needs a subscription” loop

Some subscription URLs aren’t directly accessible on your current network and require an existing proxy. In that case, choose the client’s update-via-proxy option and confirm that the selected node works. If you’ve just installed the client and the node list is empty, updating through a proxy will fail because there’s no available outbound. First connect using a single-node configuration from the provider, then update the subscription. If you don’t have a separate working configuration, ask the provider for an accessible subscription endpoint instead of repeatedly switching between unusable nodes.

Conversely, a subscription URL that normally works directly may fail through a proxy due to proxy-side DNS, certificates, or outbound restrictions. Try direct and proxied updates for the same URL and record both results. If only one method fails, the problem is likely in that download path. If the URL opens in a browser but not in the client, check whether the browser uses a different proxy, login session, or automatic redirect. Account status in the browser may not be passed to the client’s subscription request.

Check the format; don’t mistake a parsing error for a network timeout

Support for protocols and configuration formats in v2rayN, v2rayNG, and v2flyNG depends on each client’s implementation and the core it uses. Providers may offer different endpoints for different clients. A complete configuration file in the wrong format may still fail to import. Confirm that the subscription endpoint supports your client, then check whether the error is an unrecognized format, an unsupported node, or an empty response. Don’t remove security settings just to import an unsupported configuration; that can change how the connection works.

If an update succeeds but you see “no new nodes,” check the selected subscription group, search filters, and sort order. Some updates replace node IDs, so the previously selected node may no longer exist; select and apply another one. An unchanged node name doesn’t mean its server address and settings stayed the same; compare its configuration details. If only some nodes remain, check for protocol support differences or changed subscription contents before assuming the client lost data.

Limit update frequency and verify the result

Repeatedly clicking Update isn’t a good retry strategy. Frequent requests can trigger rate limits and make it harder to match log entries to a specific operation. Pause automatic updates, make one manual request, and record the time, download path, and error before addressing the cause. When you re-enable automatic updates, set a reasonable interval and avoid repeated requests from multiple devices in a short time. After the network comes back, check node connectivity before updating the subscription to avoid stacking failed requests.

After fixing the issue, confirm that the group updated, a node can be selected, and the core loaded the new configuration. Then test a real connection. Subscriptions usually sync nodes; they don’t guarantee matching routing, DNS, app filtering, or TUN settings between desktop and Android. A successful update on a computer doesn’t verify the phone. See Syncing Configurations Across Devices with v2rayN and v2rayNG for more on cross-device setup. Keep a secure backup of working settings, but don’t store exported files containing credentials in a public folder.

Slow Speeds: Separate Slow Connection Setup from Slow Transfers

Slow connections can show up in at least three ways: a long wait before a page opens, consistently slow transfers after they start, or connections that pause and recover. These may involve DNS and handshakes, bandwidth and congestion, or network changes and packet loss. Describe the symptom instead of relying on a single speed test. A small file downloading quickly while a large one is slow is a different problem from every site taking a long time to open. Test with the same node, destination, and device so differences in the destination server aren’t mistaken for node performance.

Keep test conditions consistent and repeatable

Pause syncs, downloads, and system updates that use the network, then repeat the same task. On Wi-Fi, test once closer to the access point; if possible, compare wired and wireless connections. If regular direct traffic is also slow, fix the local network first. If only proxied traffic is slow, compare two working nodes on the same network. Don’t change nodes, DNS, and routing at the same time; even if performance improves, you won’t know which change helped.

Keep the test destination consistent too. Different download sites may limit single-connection speeds, and a web page’s third-party resources may use different networks. One speed test can’t represent streaming, calls, and file downloads. Record the initial response time, transfer stability, and whether the connection repeatedly reconnects; these are often more useful than a momentary peak. A node’s performance can vary at different times due to network congestion. Repeat the test under similar conditions rather than immediately reinstalling the client.

For slow first loads, check DNS, handshakes, and retries

If a page is slow to open the first time but loads much faster on a second visit, check DNS resolution time, address selection, and connection reuse. When a node or destination domain resolves to multiple addresses, the client may try an unreachable one and wait for it to fail before trying another. Repeated dialing, handshake failures, and DNS timeouts in the log are more useful clues than a low speed-test result. Check the system clock, transport settings, and DNS path, and make sure the connection isn’t succeeding only after repeated retries.

If most of a page loads quickly but images, fonts, or scripts take a long time, their domains may be routed through different outbounds, or a blocking rule may affect a required resource. Check the failed resource’s domain in the browser’s network panel and compare it with the client log. Don’t label the entire site “slow” without checking. If a simplified route fixes the issue, check rule order and rule-set contents one at a time. Put specific domain rules before broader rules so they aren’t matched prematurely.

For slow sustained transfers, check congestion, device resources, and transport

If a transfer starts but remains consistently slow, check whether the CPU, memory, or disk is near capacity. Background connections, overly verbose logs, real-time scanning, and power-saving modes can all add overhead. Mobile devices may also throttle when they get hot, slowing the same connection over time. Test desktop devices in their normal performance mode. On Android, check temperature and background tasks too. Reducing unnecessary concurrency is easier to assess than blindly enabling multiple optimizations.

If large transfers stall only in TUN mode but work with the system proxy, check the virtual network adapter path, MTU, and extra encapsulation. A path that handles small packets but not larger ones can establish a connection and then stall during transfer. Don’t copy a fixed MTU value from the internet. Compare both modes first, confirm the virtual adapter path is where the issue occurs, then make a small, reversible adjustment using the client’s settings and retest the original task.

Protocol names alone don’t determine speed. VMess, VLESS, Trojan, and Shadowsocks performance also depends on the transport combination, server load, and network path. Changing protocols without a matching server configuration won’t improve anything. Read Proxy Protocols: Differences and Use Cases to understand how settings relate, then choose a combination supported by your provider. After fixing the issue, verify common services and make sure direct traffic hasn’t slowed because of routing changes.

DNS Issues: Separate System, Core, and Proxy-Side Resolution

DNS maps domain names to addresses, but proxy setups don’t always use a single resolver. An app may resolve a domain locally and send the IP through the proxy, or pass the domain to a SOCKS or HTTP proxy for the core or remote server to resolve. TUN may also handle system DNS requests. So a successful system lookup proves only that one resolution path works; it doesn’t confirm that the browser, core, and remote paths are working. Before troubleshooting, identify the failing domain and which layer handles its lookup.

Check the node domain and destination domain separately

If the node server uses a domain name, the client must resolve it before connecting. Only after the proxy connection is established can it access the destination site. These are two separate DNS lookups. If the node domain can’t be resolved in the log, check the DNS used during startup rather than changing the destination’s routing. If the destination domain can’t be resolved, check whether the app sends the domain name, the core has the appropriate DNS settings, and the selected resolver is reachable through the expected outbound.

On Windows, macOS, and Linux, use an available terminal tool to run a basic lookup. Check the returned addresses, resolver, and error type, not just whether there’s output. If the system lookup succeeds but proxy access fails, continue with the core logs. Results may come from a cache, so after changing settings, confirm that new requests use the new resolution path. Repeatedly refreshing a page may keep using an old result saved by the browser.

nslookup example.com

Use proxy tests to distinguish local from proxy-side DNS

In a SOCKS test, socks5 generally makes curl resolve the destination domain locally, while socks5h passes the domain to the proxy. Testing the same destination both ways can show whether local DNS is involved. Replace the port with the actual SOCKS port. One method working doesn’t mean the other should be disabled permanently; it shows that the two paths differ. Choose the appropriate path based on your routing needs and app behavior.

curl --proxy socks5://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

If proxy-side resolution works but local resolution fails, check system DNS, browser Secure DNS, and the network’s resolver. If both fail but the errors in the log differ, investigate them separately instead of changing several settings at once. A browser using its own encrypted DNS may ignore changes to system DNS. Conversely, a successful browser lookup doesn’t prove other apps work. Temporarily make the browser follow system settings for comparison, then restore the configuration you need.

Understand domain strategies in routing

domainStrategy affects whether a domain needs to be resolved to an IP address during route matching. In V2Ray-family cores, AsIs, IPIfNonMatch, and IPOnDemand serve different purposes; they aren’t simply three performance levels. The snippet below is a routing fragment, not a complete, ready-to-run configuration. It assumes outbounds named direct, proxy, and block are already defined and the required rule data is available. In a graphical client, configure routing in its settings rather than overwriting the entire generated configuration.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

With an explicit final matching rule, subsequent resolution behavior also depends on rule order and core implementation. Selecting a strategy doesn’t guarantee that every request will undergo IP matching. Check the actual logs after making a change, not just the setting name. Ad domain rules, LAN IP rules, and regional domain rules rely on different information. Missing rule sets or unavailable category names can also prevent the configuration from loading. For more on rule order, see Practical geosite and geoip Routing Configuration.

Avoid resolution loops and handle virtual addresses carefully

Encrypted DNS servers also need network access. If a resolver must use a proxy while the node address must be resolved through that resolver, the setup can create a loop. Keep a reachable path for the DNS needed at startup, and confirm DNS requests use the expected outbound. With virtual address mapping, the system may return an address that isn’t the actual server address; that’s part of how it works. However, stale routes or cached results after the client exits, or LAN domains being mapped incorrectly, can prevent apps from reaching their destinations.

To fix DNS issues, start with the simplest configuration, disable conflicting DNS interception, then add settings one at a time. LAN hostnames, printers, and internal services usually need local resolution, not a single remote resolver. After each change, test the node domain, a proxied destination, a direct destination, and a LAN hostname. See the Quick Reference for fake DNS, domain strategies, and rule sets to avoid breaking the rest of the DNS setup just to open one site.

System Proxy Not Working: Check App Traffic and TUN Coverage

The system proxy is a proxy setting provided by the operating system, not a way to force every connection through a proxy. Browsers that follow system settings usually use it, but command-line tools, some games, and apps with their own networking stack may ignore it. TUN captures traffic through a virtual network adapter and routes, with a different scope and additional requirements for permissions, routing, and DNS. If an app doesn’t use the system proxy, check how it handles network traffic instead of assuming that enabling the system proxy sends everything to the core.

Check the values saved by the operating system

After enabling the system proxy in v2rayN, open the operating system’s network settings and confirm that the proxy address and port point to the client’s current local HTTP or mixed inbound. The address is usually the loopback address, but the port must match the actual setting. If the core’s listening port changes while the system proxy still points to the old one, apps that follow system settings will fail. If the system shows an automatic configuration script instead of a manual proxy, check which method is active so the two settings don’t override each other.

Close other software that may change proxy settings, including browser proxy extensions, other proxy tools, and device management policies. On a work-managed device, policy may restore a fixed proxy even after the client changes it. Follow the device management requirements instead of repeatedly overriding system settings. On a personal device, compare the settings before and after enabling the proxy to confirm that v2rayN is changing the active network connection, not a disconnected one.

Use app logs to confirm whether traffic uses the proxy

Make a new request and check the client connection log. If nothing appears, check the app’s own proxy settings. If the request appears but uses the direct outbound, the system proxy may be working; routing may simply be choosing a direct connection. Checking an IP address on an exit-test site has limits: if that site matches a direct rule, an unchanged address doesn’t prove the proxy is broken. Check whether the request reached the core and which outbound it selected before deciding whether the issue is with the app or the rules.

Command-line apps often use HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY. Some recognize only lowercase names; others support only some of these settings. First specify the proxy explicitly in a command to confirm the local inbound works, then check environment variables. If NO_PROXY includes the destination domain or network, the request will bypass the proxy. After changing a variable, restart the app or terminal; an existing process may not pick up the new value.

Handle TUN startup failures separately from problems after startup

If TUN won’t start, check the logs for permission, virtual adapter creation, and route-writing errors. Desktop operating systems may require elevated permissions or approval for a network component, but don’t permanently disable system protection. Address only the operation explicitly rejected in the logs. If the core starts but virtual adapter creation fails, a running status in the interface doesn’t mean TUN is capturing traffic. Check the client mode, adapter state, and startup entries in the logs.

If TUN starts but cuts off internet access, turn it off and test the same node using the system proxy. If the system proxy works, the issue is more likely with routing, DNS interception, or another virtual adapter conflict. Running multiple VPNs or virtual networking tools at once can repeatedly change the default route. Traffic to the node server needs a valid external route, and LAN traffic may need exclusion rules. Don’t clear every exclusion; that could capture traffic to the node and local services too.

Restore network access after exit and keep changes reversible

If the client exits unexpectedly, the system proxy may still point to a local port that’s no longer open. If the browser fails but an explicitly direct test works, that’s a useful clue. Open system proxy settings to remove stale values, then check whether TUN left behind an adapter or route. Normally, exit cleanly, restart the client, and disable the proxy before considering manual adapter removal. Before changing network settings manually, note the original values, especially on a managed network.

Finally, test a browser, a terminal, and an app that doesn’t follow the system proxy. Testing just one type of app isn’t enough to confirm the fix. Also verify that LAN devices and direct destinations are reachable and that regular internet access returns after closing the client. App-level proxies and TUN have different use cases; prefer the option that meets your needs with fewer variables. Review the Quick Start Guide for basic setup. During troubleshooting, don’t introduce a new routing template and a new traffic-capture mode at the same time.

Client Crashes: Distinguish Interface, Core, and Configuration Failures

A client window that suddenly closes, an open window with no internet access, and a client that stops immediately after startup point to different problems. The v2rayN interface and proxy core are separate components: a working interface doesn’t mean the core is running, and the core can exit without closing the window. First note what triggers the issue: does it fail on startup, after importing a particular node, after enabling TUN, or only after running for a while? A single reproducible action is the best place to start.

Save the configuration and logs before repairing the installation

If the interface still opens, use the client’s export feature to save the necessary configuration and note the current subscription group, routing mode, and DNS settings. Backups may contain credentials, so store them securely. If you can’t open the interface, don’t immediately clear the user data directory. Save a copy first, then check startup logs or the operating system’s application error records. Before sharing logs, remove server credentials, subscription URLs, user paths, and other unnecessary sensitive information.

Before reinstalling, check the operating system and processor architecture on the downloads page. The v2rayN desktop and classic WPF versions for Windows have different interfaces; don’t mix their program files. On macOS, choose the package for your chip. On Linux, check both the processor architecture and distribution package format. If the system reports a missing dependency, install the official runtime that the specific error calls for. Don’t download supposed fixes from unverified pop-ups.

For an interface crash, check startup and resource errors

If the client exits immediately on startup, check whether the operating system blocked it, installation completed, and the user data directory is writable. On macOS, move the app to an appropriate applications folder before addressing security prompts. On Linux, launch the installed app from a graphical terminal, check standard error output, and verify components required by the desktop session. Permission and dependency problems should leave specific clues; don’t hide them by always running as an administrator.

If the client crashes after running for a while, check whether it happens with many connections, accumulated logs, waking from sleep, or display changes. Check free disk space and memory pressure, reduce unnecessary verbose logging, and repeat the same steps. After sleep, network interfaces may change; restart the connection before reinstalling the app. If the issue occurs only with a particular interface action, temporarily avoid that action while keeping the connection available. Record the steps so an intermittent system issue isn’t mistaken for broken node configurations.

If the core exits immediately, start with the first configuration error

Configuration loading errors usually identify a field, outbound tag, rule data, or listening port. Fix the earliest meaningful error in the log first; many later errors may be consequences. If a port is in use, identify the process, close duplicate client instances, or change the local inbound port and update the system proxy to match. Don’t delete all routing rules just to get the core started. Fix missing rule data and invalid outbound names separately.

If only one node makes the core exit, check whether its protocol is supported by the core. v2rayNG primarily uses the Xray core, while v2flyNG uses the V2Fly core; their capabilities aren’t identical. Switching the core in v2rayN won’t make an unsupported combination compatible. Match the node, transport, and core, and re-import from a valid subscription if needed. Don’t remove required fields such as those for REALITY to bypass a loading error; starting successfully doesn’t mean the connection will work.

Use a minimal configuration to narrow down the cause

After saving a backup, create a comparison setup with one known working node, basic routing, and default DNS. Temporarily leave out TUN, complex rules, and custom configuration. If this minimal setup works, restore subscription groups, routing, DNS, and traffic capture one at a time, testing after each change. This narrows the issue down to a specific configuration layer. Don’t run the test and original setups on the same port, or let two instances compete to control the system proxy.

After fixing the issue, exit normally and restart once, then verify the actual state of subscriptions, nodes, system proxy, and TUN. If reinstalling helps but restoring the old configuration causes the problem again, the configuration is more likely at fault than the installer. See About This Site and the Project V Ecosystem for more on the relationship between cores and clients. When reporting an issue, include the operating system, architecture, client name, steps to reproduce, and redacted error text. This is safer and more useful than uploading the entire configuration.

Android Connection Problems: Check VPN Permission, App Routing, and Background Restrictions

On Android, v2rayNG and v2flyNG route traffic through the system VPN interface, so troubleshooting differs from the system proxy on desktop. A VPN icon in the status bar confirms only that the system interface was created; it doesn’t mean the remote node works. Select a working node, approve the connection request, then make a browser request and check the client log. If the client stops immediately, check permissions, configuration loading, and conflicts with other VPNs first. If it stays running but can’t access the internet, check the node, DNS, and routing.

Check system permission and VPN status

The first connection usually requires approval of an Android VPN request. If the prompt was canceled or hidden behind another window, or device policy restricts VPN access, the client may not be able to create the interface. Open the system VPN settings to confirm the active connection, and stop other apps that are capturing traffic. Some local filtering tools use the same interface and may conflict even though they don’t look like proxy apps. Test with just one traffic-capturing app at a time, then decide how to run them together.

Check whether always-on VPN or blocking connections outside the VPN is enabled. If it points to another disabled app, even regular internet access may be blocked. If the current client exits unexpectedly while the block-outside-VPN policy is active, the whole device may lose internet access. Understand these settings before changing them, and restore them after testing if needed. Don’t permanently disable every restriction. On managed devices, follow the administrator’s policy; reinstalling repeatedly won’t resolve an authorization restriction.

If some apps work and others don’t, check app routing

App routing can either proxy only selected apps or bypass selected apps. The same list has opposite results depending on the mode. First check the current mode, then see whether the failing app is on the list. System components, work profile apps, and personal apps may also have different traffic coverage. If a browser works but another app doesn’t, don’t switch nodes immediately. Check whether that app’s requests appear in the client log.

After an app’s traffic enters the VPN, domain and IP routing still apply. The app list determines whether traffic is captured; routing determines which outbound it uses. One doesn’t replace the other. Some apps use their own DNS, fixed IPs, or persistent connections, and behave differently from browsers. After changing routes, fully close and reopen the app so it doesn’t keep using an old connection. For LAN access issues, check the LAN direct rules and app routing rather than forcing every destination through the proxy.

If the connection drops when the screen turns off, check battery and background settings

If everything works in the foreground but fails when the screen is off, background restrictions are a likely cause. Check whether the system’s battery settings allow the client to run in the background. Also check power-saving mode, background data limits, and device manufacturer task management. Settings have different names across devices, so look for the relevant function. After changing a setting, let the screen turn off and check whether the connection stays up; testing only with the screen on won’t confirm a background fix.

Also distinguish a stopped process from a temporary network interruption. If the client has exited, focus on background management. If it’s still running but the log shows disconnections, the cause may be switching between Wi-Fi and mobile data, network sleep, or a closed remote session. Allowing background activity doesn’t guarantee that every session stays connected; the client may need to reconnect after a network change. Wait for a new connection, then make a new request instead of using a failed old session to judge the current network.

Test mobile data and Wi-Fi separately

If the same node works on Wi-Fi but not on mobile data, check differences in address-family support and DNS, along with any system data-saving restrictions. You can temporarily disable a custom Private DNS setting for comparison, but that doesn’t mean you should leave it off. If only UDP-related services fail, confirm that the node, transport, and server support the required forwarding. A working web page doesn’t mean every protocol is working; a regular HTTP request tests a different connection path.

If the first connection is slow after switching Wi-Fi networks, stale DNS cache or a changed address may be involved. Stop and restart the connection, then confirm that the server address in the log comes from the current DNS lookup before changing DNS settings. Complete any public Wi-Fi sign-in before starting the VPN. If internet access still fails with the client closed, check system network and VPN policies instead of changing the node. An incorrect system clock can also affect TLS; check automatic time and time zone on Android.

Choose the right client and verify the full connection path

v2rayNG is the recommended Android client. v2flyNG, which uses the V2Fly core, is an alternative, but switching clients won’t fix every issue. For nodes that need specific core features, confirm compatibility before importing. Choose an installation package for your device’s architecture. If you’re unsure, see the Android download guide for the right option; don’t change the node protocol just because installation failed. Even when sharing a subscription between the two clients, check app lists, DNS, and routing separately.

Final verification should cover foreground access, a new request after the screen turns off, switching between Wi-Fi and mobile data, LAN access, and regular internet access after stopping the VPN. Use the same task for each comparison and make sure the fix hasn’t broken another scenario. See the Subscription Import and Connection Guide for initial setup, and the Quick Reference if a term is unclear. Keep your working settings and redacted troubleshooting notes so the next time the same symptom appears, you can pick up from what you’ve already verified.