v2rayN Troubleshooting
Connections, subscriptions and client settings

1. Connected but can't access the internet: identify the failing layer

Compare direct and proxied connections

“Can't access the internet” can have several causes. Exit the client, restore the system's original proxy settings and open a site that normally works without a proxy. If it still fails, check Wi-Fi, the gateway, system time and any network sign-in page first. Hotel, campus and public Wi-Fi may require browser authentication before use. A client showing as started does not prove that the underlying network is connected. Don't keep changing protocols until the basic connection works.

Once direct access works, start the client and confirm that the server list contains an active server—not just an entry selected with the mouse. Then check the logs to make sure the core started successfully and the local inbound is listening. A tray icon only means the GUI is running. If the core failed to start, the port is in use or configuration generation failed, your browser may be pointing to a local address with no service listening.

Choose one test site and record the results with and without the proxy. Make one request at a time and note when it was made so you can find the matching log entry. If the browser reports an error but the client logs nothing new, the issue is likely with application routing or the local inbound. If the logs show an outbound connection error, investigate the server and protocol. Don't mistake a cached browser error page for a fresh test result.

Use an explicit proxy to verify the local inbound

In v2rayN's settings, check the actual HTTP or mixed inbound port. The example below assumes the port is 10808; if your setting differs, replace the number before running the command. On Windows, use curl.exe to avoid conflicts with aliases that may use the same command name. This test checks whether a request reaches the local inbound; it does not guarantee that every site will work.

curl --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

If the connection to the local port fails, check the core process, listening address and port type before changing the remote server. If the local connection succeeds but the handshake fails or the remote server times out, continue to the next section. Any HTTP response from the site—even an error status—shows that the request received an application-layer response. Check the response content to determine whether the issue is a site restriction, authentication or another part of the proxy route.

If the explicit proxy works but the browser doesn't, check the browser's own proxy settings, extensions and system proxy. Private browsing doesn't necessarily disable every extension or bypass system settings. Compare with a browser profile that has no separate proxy rules. If only one app fails, check whether it follows the system proxy; a working browser doesn't mean every application will use the same inbound automatically.

Restore a minimal configuration, then add features back one at a time

If you have several custom settings, back them up first, then keep one confirmed working server and a simple routing setup. Temporarily disable extra proxy chains, complex rule sets and duplicate network tools to prevent requests from looping between local inbounds. During testing, don't enable the system proxy, another traffic interception tool and a browser proxy extension at the same time unless you know how each one handles inbound and outbound traffic. Otherwise, it is difficult to match logs to a single route.

If every site fails, check the shared inbound, DNS and outbound connection. If only certain domains fail, check routing rules, the destination and the site's status. Temporarily route a test domain through a known proxy outbound, then restore the original rules. Don't leave global proxy mode enabled as a permanent fix: it may bypass a faulty rule without fixing the underlying configuration.

After the issue is fixed, restore custom routing, browser settings and other network tools in sequence, retesting the same destination after each change. Then fully exit and restart the client to verify that the settings persist. Note the working inbound, active server and proxy mode as a baseline for future troubleshooting. If you're unsure about the connection steps, revisit the quick start guide instead of importing multiple copies of the same configuration.

2. Server timeouts: distinguish transport connection from protocol handshake

Find out which stage is timing out

A client test can time out because the server hostname won't resolve, a connection to the destination port cannot be established, or the transport connects but the protocol handshake never completes. Different test features may use different destinations and methods, so a result in the server list isn't a substitute for testing an actual connection. Start with the first error in the logs. Later errors may just be retries from the same failure, not separate issues.

On Windows, you can run the port test below. The address and port are examples; replace them with the values in your configuration. A successful test only confirms that a TCP connection can be established. It does not verify VLESS, REALITY or user authentication. If the test fails, consider whether the server only accepts connections over a specific network path before concluding that the client is broken.

Test-NetConnection -ComputerName your-server.example.com -Port 443

This test is even less useful if the server uses a transport other than a plain TCP connection. For UDP-based paths, also check whether the local network and server allow the relevant traffic. Being able to browse ordinary websites doesn't prove that every transport is reachable. Compare the same destination over Wi-Fi and mobile data; this is usually more informative than changing several protocol settings in a row.

Check VLESS and REALITY parameters field by field

If the transport port is reachable but the handshake fails, compare every field with the original details from the server administrator. The server address determines where to connect; the server name is used during the secure handshake, and the two may differ. Don't automatically replace the server name with the connection address or disable transport security just because the address uses a particular port. The client and server must use a matching protocol combination.

With XTLS Vision, also check that the flow control setting matches the selected transport and security options. Don't copy a flow control value from another server just because its configuration looks similar. The REALITY public key, short ID and server name must match the server's requirements. Short ID requirements vary; whether it can be left blank depends on the server configuration, so don't rely on a screenshot from a tutorial as your only reference.

A significantly incorrect system clock can also affect the secure handshake. Enable automatic time synchronization in your operating system and confirm the date and time are correct. If the error mentions a certificate or server identity, check the server name, certificate deployment and system trust store. Don't disable identity verification as a routine fix. Hiding the handshake error may make the connection appear to recover, but it leaves the configuration or security issue unresolved.

Identify whether the issue is on the server, core or local network

If only one server keeps timing out on the same network while other known-good servers work, first verify its address, service status and account. If all servers fail at once—especially after a router change or network switch—check the shared network path. For a meaningful comparison, use the same configuration; otherwise you can't tell whether the difference comes from the network or the settings.

Also check whether the selected core supports the features your configuration requires. Xray and V2Fly don't have identical feature sets; being able to import a shared configuration doesn't mean the core can run it. For background on REALITY and configuration compatibility, see Xray vs. V2Fly core differences. Change the core or client only when the logs clearly indicate an unsupported feature.

When reporting the issue to the configuration provider, include the test time, network, connection target, failure stage and first error with sensitive details redacted. Don't send only a screenshot saying “timeout,” and never share subscription credentials. If the same configuration works on another network, describe the differences between the two environments. If it fails everywhere, server-side logs may be needed. The client alone cannot fix a remote server that isn't listening, a disabled account or mismatched server settings.

3. Subscription failures: distinguish fetching, parsing and updating

Check that the URL returns the expected content

A subscription update has three stages: fetching the URL, parsing its content and writing entries to the server list. When an update fails, read the specific error first. DNS failures, connection timeouts, authentication errors and unparseable content require different fixes. Some services return a normal HTTP status while actually serving a login page or access notice. That isn't valid subscription data, and clicking Update repeatedly won't change it.

Copy the complete subscription URL again from the trusted configuration management page. Check that the scheme, path and query parameters are intact. Line breaks in chat apps, manually removing trailing characters or copying extra spaces can change the URL. Subscription links often contain access credentials, so treat them like passwords. Don't paste them into public speed test sites, online decoding tools or discussion forums, and don't share screenshots that show the full URL.

If the logs show an authentication error or missing resource, check on the original configuration management page whether the subscription is still active, the account has access and the URL has changed. A working server and an updateable subscription are separate things: existing server entries may still work after the subscription credentials change. Conversely, a successful subscription fetch doesn't prove that every server in it is reachable.

Check which network path the update request uses

Subscription updates may connect directly or use an existing proxy, depending on the client settings. Check the update options rather than assuming they follow the system proxy. If the client has just been installed and has no working server, but the subscription requires a proxy, you can end up in a bootstrap loop: you need a configuration to fetch the configuration. Use a reachable URL or trusted manual setup method supported by the provider instead of repeatedly trying the same broken route.

If you already have a working server, keep it active and test direct and proxied updates separately, changing only the update method each time. If one works, the issue is more likely the subscription URL's network path or DNS. Don't change the system proxy, DNS and update method all at once. If the update then succeeds, you won't know which change fixed it.

For URLs that return a web page, redirect unexpectedly or fail a secure connection, check system time, network sign-in status and whether the request passes through an upstream network that requires authentication. Don't leave secure connection checks disabled just to fetch a subscription. If the request redirects to a login page, confirm your authorization through the service's normal management page; don't save the login page as a configuration file and import it.

Handle format incompatibility, duplicate entries and overwrite risks

If the content downloads but parsing fails, check that its format is supported by the client. A collection of share links, encoded subscription text and certain client-specific configuration files aren't interchangeable. Don't rely on the file extension alone or try to fix the issue by randomly adding or removing encoding. Use the format the provider explicitly supports for your client, and confirm that its protocol features match the selected core.

Before updating, back up the subscription group and any manually edited entries. A refresh may rebuild the group and overwrite custom names, addresses or transport fields. Keep manual configurations you want to preserve in a separate, clearly named group. Avoid maintaining multiple groups that point to the same URL: the server list may appear larger, but it will contain duplicate entries that are easy to confuse during troubleshooting.

If entries disappear after an update, check group filters, name filters and the subscription response before clearing the entire list again. An empty list may be caused by a filter or by the URL returning no data. Keep your backup and test the URL in a separate group to distinguish a display issue from a problem with the remote content. A success message only means the client completed an operation; it doesn't guarantee that the result is what you expected.

Finally, select a specific entry from the updated list as the active server and test the connection again. Some clients don't automatically map the previous active server to a newly generated entry, so “subscription updated successfully, but I can't connect” may simply mean no active server was selected. For the basics of subscriptions and server selection, see the FAQ. If the logs have reached the protocol handshake stage, return to the server timeout section.

4. Slow speeds and intermittent stalling: compare like with like

First identify whether the delay is on initial load, ongoing transfers or one site

If a page takes a long time to open the first time but transfers normally afterward, the cause may be DNS, connection setup or the security handshake. Slow speeds throughout a download are more likely related to throughput, packet loss, server load or the local device. Occasional video stalls may also be caused by the service's caching or scheduling. Start by describing a reproducible symptom. Calling every delay a “slow server” can lead you to switch servers without addressing the real issue.

For a fair comparison, keep the device, network, active server, test destination and approximate time the same. Pause cloud sync, system downloads and other high-bandwidth tasks. Test a service you actually use rather than relying only on a generic speed test. Different destinations may use different routes and service policies, so a good speed test result doesn't guarantee fast downloads, smooth video or reliable real-time communication.

Before comparing results, confirm that requests use the same route. The same domain may take a different outbound route if rules, DNS results or application settings change. Check the connection logs to see which outbound was selected for the destination. If one test went direct and the other used a proxy, the results aren't comparable. A few repeat tests are enough; running frequent concurrent requests can distort the results.

Check the local network, remote route and device resources

First check whether ordinary traffic without a proxy is also slow. If it is, look at Wi-Fi signal strength, router load and whether the broadband upload is saturated. Upload congestion can delay acknowledgements and interactive requests, making pages slow to respond even when download bandwidth appears available. If possible, compare using Ethernet or moving closer to the router. Don't switch servers at the same time, or you won't know which change helped.

If only proxied traffic is slow, compare the same server against different destinations, then different servers against the same destination. The first comparison helps identify destination or exit routing issues; the second reveals differences between server paths. Routes can change over time, so a short test only reflects current conditions. Evening congestion, server-side rate limits or limited remote resources require repeated tests under the same conditions; one peak result isn't enough to draw a conclusion.

Also check Task Manager or Resource Monitor. If the client or another process is using a lot of CPU, or memory pressure is causing frequent paging, your device may be the bottleneck. Too many concurrent connections, verbose logs and frequent speed tests can add overhead. Close unnecessary tasks and use a normal logging level. Don't disable security software or change system network settings just because you saw one CPU spike.

Adjust transport, multiplexing and traffic routing with care

Connection multiplexing doesn't improve every protocol or network. Some combinations can increase head-of-line blocking, while other features have core or protocol limitations. Change these settings only when the configuration provider confirms they're supported and you can compare results before and after. Don't copy a set of “speed boost” settings from the internet to every server. Incorrect multiplexing, flow control or transport options can make a working connection unstable instead of faster.

If simple pages load but large pages or long-lived connections often stall, investigate traffic interception mode, path MTU or UDP behavior. MTU should be a later troubleshooting step, not the first. Compare the explicit proxy with your current interception mode. Only investigate its network interface and settings if the issue changes with the mode. Record the original values before making changes, adjust one at a time and verify that you can restore them.

If only one site is slow, use the browser's developer tools or the app's error messages to distinguish the main document from images, scripts and API requests. A page may rely on several domains; one routed incorrectly or failing to resolve can make the whole site appear stuck. Fix the rules for the affected domains instead of permanently forcing all traffic through one outbound. If the service itself is rate-limiting you or restricting your account, client settings can't fix that.

After making changes, test at least three scenarios: initial load, sustained transfer and reconnecting after idle. Make sure an improvement in one doesn't break another. Record successful changes and how to undo them, then stop any temporary speed tests. If Android only stalls after the screen turns off, see the mobile section. Background restrictions can look like poor throughput, but the fix is to address system power management—not blindly increase the number of connections.

5. DNS issues: identify where name resolution happens

Distinguish system, browser and core DNS resolution

DNS issues can cause domains to fail to load, work intermittently, resolve to the wrong address or take a long time before the first request. A single device may use the system resolver, secure DNS in the browser, the client core's DNS and an application's own resolver. They may use different servers and routes. First identify which resolver handles the request, then change the relevant setting. Replacing system DNS won't necessarily affect every app.

On Windows, use the command below to check the system's DNS result. It reflects the system resolution path, not the final result used by the client core or browser. Note the returned address, error and query time, then compare them with the client logs. Opening a site by IP isn't a reliable general test: many sites require a hostname for the secure handshake and virtual hosting. A failed IP request alone doesn't prove that the network is down.

Resolve-DnsName example.com

If system DNS works but the browser doesn't, check whether the browser uses its own secure DNS and whether it can reach the selected resolver. Conversely, a browser may work while another app fails because they use different DNS paths. For a test, temporarily standardize one setting and record its original value. Don't change browser, system and core DNS all at once, or you won't know what caused the result.

Check for DNS loops and bootstrap dependencies

A remote DNS resolver may itself have a hostname that needs to be resolved first. If the system sends every query to that resolver, but reaching it requires a proxy that isn't available yet, you create a bootstrap dependency. A similar loop can occur when the server address is a hostname and its DNS request is routed through that same server. Keep a clearly reachable bootstrap path; don't make every step depend on the next one already working.

The DNS snippet below is part of a core configuration. It illustrates the relationship between resolver addresses and query strategy; it isn't a complete client configuration and shouldn't be used to overwrite a GUI client's generated file. Make changes through settings supported by the client and check the selected core's documentation for field behavior. This example uses standard DNS queries; assess whether that suits your network and privacy requirements before using it.

{
  "dns": {
    "servers": [
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

Whether a DNS server is reachable, how its queries are routed and how the resulting address is used to connect are three separate issues. A server responding to queries doesn't guarantee that its results are suitable for the selected outbound. In environments that distinguish direct and proxied traffic, keep domain rules, DNS strategy and outbound selection consistent. Faster DNS doesn't automatically mean a faster connection; geographic routing can also affect the route that follows.

Check IPv6, caches and rule matching

On a dual-stack network, a domain may return both IPv4 and IPv6 addresses. If your device gets an IPv6 address but the actual route is incomplete, the app may try an unreachable path first and wait. Check that both address types are reachable before changing DNS or connection behavior. Don't disable IPv6 across the entire system just because you see an IPv6 result. A targeted change is easier to revert and avoids disrupting other services that depend on IPv6.

After changing DNS settings, old results may remain in the operating system, browser and core caches. On Windows, you can use ipconfig /flushdns to clear the system cache if needed, but it won't clear every application's cache. Stop test requests first, restart the relevant apps or core as needed, then query again. Repeatedly clearing caches without checking the configuration may change what you observe without fixing the source of the problem.

If only a few domains fail, check whether the hosts file, custom client domain mappings, ad blockers or security software are changing the result. Domain and IP rules may be applied at different stages, and the resolved address may match a different rule. Use the connection logs to confirm the final outbound rather than guessing based on rule order. If you need a temporary rule, limit it to the test domain and note when to remove it.

Verify the result using three things: a system DNS query, an actual request in the affected app and the client logs. Successful resolution is only one step; the secure handshake and page request must also complete. If only the browser works after a change, check whether other apps use their own resolvers. If all domains resolve but connections still time out, return to the transport and handshake sections. Separating these issues prevents repeated DNS changes when the server port is actually at fault.

6. System proxy not working: check whether the app uses it

Understand the difference between a system proxy and routing all device traffic

A system proxy is a network setting that apps can read. It doesn't mean the operating system forces all traffic through the client. Browsers usually follow the setting, but command-line tools, games, background services and apps with their own networking stack may ignore it. If an app connects directly while the system proxy is on, that doesn't necessarily mean v2rayN is misconfigured. Check which proxy method the app supports, then choose an appropriate way to connect it.

First check v2rayN's current system proxy status and make sure it isn't set to clear the proxy or leave the existing settings unchanged. Then open the operating system's network proxy page and verify the address, port and any automatic configuration script. The system and apps determine the priority between proxy methods; having both a manual proxy and an automatic script can cause confusion. During troubleshooting, use one clearly defined method and note the original settings so you can restore any required work-network configuration.

Apps on the same device usually connect to a local inbound using the loopback address. 127.0.0.1 points to the device itself. If you enter this address as the proxy on a phone, it won't connect to your computer. To share a proxy over your LAN, enter the host computer's local network address and the correct inbound port, and restrict access to the appropriate network. That's a different route from the host's system proxy; don't open a LAN listener just to fix a browser on the host.

Check the protocol, port and app settings

If an explicit proxy test works but an app doesn't, first check whether the app has options such as “connect directly,” “use system settings” or its own proxy. Some tools read environment variables, while others use system settings; even tools running in the same terminal aren't guaranteed to behave alike. After changing proxy settings, close existing connections or restart the app, since long-lived connections may not switch to the new outbound immediately.

The port must match the inbound protocol. Don't point an HTTP proxy to a port that only accepts SOCKS. Check the current client settings to see whether a mixed inbound accepts both types of request. If you want a SOCKS proxy to resolve the destination hostname remotely, tools that support it can use socks5h. This behaves differently from resolving the hostname locally, so account for that when testing.

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

The port above is still an example; first confirm that it actually accepts SOCKS requests. If an HTTP test works but a SOCKS test fails, don't immediately blame the server. The two tests may use different local inbound capabilities. Also check the app's proxy bypass list for exclusions such as local addresses, specific domains or subnets. Requests explicitly excluded from the proxy won't use it.

Check for conflicts and leftover settings from other tools

Multiple network tools may all try to manage the system proxy. Common signs include a setting that reverts right after you change it, or other apps losing internet access when the client exits. Stop other programs that manage proxies and check whether the system setting remains stable. Browser extensions can also override system settings, so check both the system and browser layers. The selected item in the tray menu alone doesn't prove that traffic is being routed through the proxy.

If the client exits unexpectedly, the system may keep a proxy address pointing to a local port that no longer has a process listening. Restart the client and clear the system proxy normally, or remove the stale manual setting on the system's network page. Rebooting the router won't help: the request is failing before it leaves your device. Once direct access is restored, investigate why the client exited to prevent the issue from recurring.

For LAN sharing, allow access only from the network ranges that need it, and limit the relevant port and network profile in the firewall. Don't disable the firewall entirely or expose a local proxy inbound to the public internet. See how to allow LAN connections in v2rayN for detailed steps. The host's local network address may change when it connects to another network, so check the settings on other devices too.

For a complete check, turn the proxy on, reconnect the app, turn the proxy off and exit the client. With the proxy on, confirm in the logs that requests use the correct outbound. With it off, verify that direct access works again. After exiting, make sure the system isn't left pointing to an inactive inbound. If an app doesn't support the system proxy, use its own proxy setting or a suitable traffic interception method instead of repeatedly writing the same system proxy address.

7. Client crashes and core exits: preserve the first error

Distinguish a GUI crash from a core startup failure

A disappearing window, a visible tray icon, an unreachable server and a repeatedly restarting core are different failures. First determine whether the GUI exited or the core process stopped. If the interface works but the logs report a configuration error, check the generated configuration and feature compatibility. If the whole program won't open, check the installer architecture, system requirements, runtime dependencies and file permissions. Don't start by deleting every configuration directory.

Note what triggered the issue: the client exits on startup, after a subscription update, after switching cores or when opening a particular settings page. Then check the client logs and the operating system event records for the same time. Preserve the first error and the context immediately around it. Later connection failures may simply result from the program stopping. If the logs are large, copy them before clearing and reproducing the issue once so useful details aren't overwritten.

Before sharing diagnostic information, check for paths, usernames, subscription credentials and full configuration data. Don't publish your entire user directory or upload crash attachments that contain server authentication details. The client name, system architecture, steps to reproduce and a redacted error are usually enough to begin troubleshooting. If more information is needed, agree on what to collect and use a trusted channel instead of posting local files indiscriminately.

Check the installation environment, permissions and port conflicts

Choose an installer for your operating system and processor architecture on the client download page. The Windows desktop and classic WPF editions use different UI technologies and have different requirements. Back up your configuration before switching; don't mix their installed files by overwriting one installation with another. See Avalonia desktop vs. WPF edition for help choosing. Don't copy runtime components from untrusted sources to fix a UI issue.

Store portable files in a location your current user can read and write. Avoid restricted directories, read-only media and folders that sync frequently. If the logs report access denied, check the specific path and permissions instead of running as administrator indefinitely. If security software blocks the client, review the alert and source, then respond using the operating system's normal controls. Disabling all protection shouldn't be part of a standard installation.

If the core reports that a port is in use, another client instance may still be running or another service may be using the same port. Check the tray and process list, close duplicate instances and confirm that the port is available again. If you must change the port, update the system proxy and app-specific proxy address too. Changing it in only one place turns a port conflict into an app that can't reach the local inbound—though it may still look like a network problem.

Use a separate configuration to isolate corruption and compatibility issues

If a startup error began immediately after a settings change, revert that change first. If you can't open the interface, identify the configuration location and make a backup before testing with a separate directory or new user profile. Don't delete the original directory; it may contain subscription groups, manually added servers and routing rules. A test environment with a single known-good configuration can help distinguish a program issue from corrupted historical settings.

If the new environment works but the old one doesn't, migrate servers, subscriptions and routing settings one at a time, restarting to test after each change. If importing a rule set triggers the failure, check its file path, field format and core compatibility. The GUI saving a setting doesn't guarantee that the generated core configuration is valid. Use startup logs and the actual runtime behavior to confirm whether fields are supported.

If the same minimal configuration still makes the program exit in a clean environment, check system resources, disk space, runtime dependencies and software conflicts. Keep your original backup when updating or reinstalling, and don't restore all old settings at once during testing. Choose an alternative only after identifying a specific unsupported feature. A temporary fix after reinstalling doesn't mean you should ignore the setting that triggered the issue.

After fixing the issue, fully exit and restart the client. Confirm that only one core instance starts, the local inbound works and the system proxy is restored on exit. Then test subscription updates and your usual routing rules to ensure the problem wasn't hidden by a temporary empty configuration. Record both the steps that triggered the issue and the fix; “reinstalled and it works” won't help you identify the same problem if the environment changes again.

8. Android disconnects and battery drain: check permissions and background settings

Confirm VpnService permission and that only one VPN is running

On Android, first determine whether the service never started, started without passing traffic or stopped after the screen turned off. v2rayNG and v2flyNG use Android's VpnService to route the selected traffic; the first connection requires system approval. Granting permission only allows the service to create a local virtual network interface. It doesn't mean the server handshake succeeded. If the status shows running but you can't connect, check the active server, DNS and outbound settings in the logs.

Android generally allows only one VPN service to be active for a user at a time. Another network filter, work network or proxy app may replace the current service. Check which app is actually running in system settings and whether its persistent notification is present. Don't start v2rayNG and v2flyNG at the same time to compare speeds. Fully stop one before testing the other, or your results may reflect the change in traffic routing rather than client performance.

Switching clients doesn't guarantee that the existing configuration is compatible. v2rayNG uses the Xray core; v2flyNG is an alternative using the V2Fly core. Choose based on the features your configuration requires. If it depends on REALITY or a specific flow control setting, check core support first instead of treating a handshake failure as a system permission issue. For an overview of first-time authorization, background settings and per-app proxying, see v2rayNG Android setup tips.

Fix disconnects after screen-off and network changes

If the connection works in the foreground but drops after the screen has been off for a while, check the app's battery settings, background permissions and the manufacturer's autostart controls. Menu names differ between Android versions and manufacturers; look for battery settings in the app info page. Allow the background activity the service needs, then test with the screen locked. Don't relax restrictions for every app. The persistent notification indicates that the service is running; hiding it shouldn't come at the cost of breaking its background operation.

Relaxing background restrictions can increase battery use, so set them according to your stability needs. At regular intervals, compare logs and battery stats before and after the screen turns off. Determine whether the process was killed, network access was suspended or the remote connection dropped on its own. If the service notification remains but requests fail, reconnecting may be enough; the system may not have closed the app. Repeatedly force-stopping the app or clearing it from recent tasks undermines the background behavior you're trying to preserve.

Switching between Wi-Fi and mobile data changes addresses, routes and reachability, and existing connections may break. Give the client time to reconnect before sending a new request; don't use a page left open before the switch to judge the current connection. If every switch causes a failure, check whether Android restricts background mobile data, Data Saver is enabled or the client is set to reconnect. If both networks work separately but switching fails, focus on the transition process.

Troubleshoot per-app proxying and unusual battery drain

If only some apps bypass the proxy, check whether per-app mode means “proxy only selected apps” or “bypass selected apps.” These modes do the opposite, so selecting an app but getting an unexpected result often means the wrong mode is active. After changing the setting, stop and restart the service, then close and reopen the target app to test. System components, work-profile apps and cloned copies of the same app may have different identities; don't rely on the home screen name alone to confirm you've selected the right one.

For high battery use, first check the reporting period, total runtime and foreground/background split. Android may attribute network activity routed through the VPN service to that service, so the percentage on the battery page doesn't necessarily represent extra power used entirely by the client. Keep usage similar when comparing before and after; comparing continuous video playback with idle time isn't meaningful. Also account for weak signal, hotspot use and other apps that connect frequently.

If the logs keep showing reconnects while idle, check server reachability, DNS failures and network instability. Frequent handshakes, automatic tests and overly frequent update tasks can wake the device; reduce unnecessary polling rather than increasing every timeout at random. Conversely, a timeout that's too short can treat temporary congestion as a disconnection and trigger even more retries. Keep the default or use settings with a clear reason, and compare one change at a time instead of copying a supposed battery-saving preset.

Test four scenarios: foreground use, screen-off idle, network switching and per-app access. For each, record the service status and error time. If battery use is the main issue, see v2rayNG battery drain and background troubleshooting. If every scenario fails at the same handshake stage, return to the server timeout section. Android background policies, core compatibility and remote connectivity are separate leads; handling them separately makes it easier to get a repeatable fix.