The Complete v2rayN Troubleshooting Guide

Diagnostic layers › App entry point › Local listener › Outbound connection

No internet access: break down what “connected” means

A server selected in the main window, a running core and an enabled system proxy are three separate states. A node marked active only means it is queued for future requests; it does not confirm a successful handshake with the remote server. Start by distinguishing between “nothing loads in any app,” “only the browser fails” and “only certain domains fail.” Note the client, operating system, proxy mode and when the issue first appeared so you have a baseline for comparison.

Separate direct-connection and proxy failures

In the v2rayN tray menu, choose “System Proxy → Clear System Proxy” and temporarily turn off TUN mode. Visit a site that normally works without a proxy to confirm the device has internet access. Hotels, campuses and public Wi-Fi networks may require a sign-in first. If nothing works even after clearing the proxy, troubleshoot network access, the gateway or system DNS before changing node settings. When you finish, select “Automatically Configure System Proxy” again.

Next, quit other proxy apps and disable browser proxy extensions, leaving only v2rayN running. When multiple programs take turns changing the system proxy, the setting shown in the interface may not match the actual configuration. If only one browser is affected, test with a new temporary browser profile to rule out extensions, cached data and security policies. Don’t delete your existing profile yet; preserving the setup that reproduces the issue can help identify its cause.

Check the local mixed-protocol listening port

Go to “Settings → Parameter Settings → Core: Basic Settings” and check “Local mixed-protocol listening port.” The commands below use port 10808; if your port differs, update the command accordingly. Specifying a proxy explicitly bypasses the system proxy and helps test whether the local listener and outbound connection work. In Windows PowerShell, use curl.exe to avoid confusion with other commands named curl.

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

An HTTP response header confirms that this request made it through the proxy chain; it doesn’t mean every site is reachable. If the local address cannot be reached immediately, check whether the core is running and whether another process is using the port. If the request times out after waiting, investigate the remote connection and DNS. For certificate errors, check the system clock and the target certificate; don’t simply disable certificate verification. If the target site may be having problems, repeat the test with another known-good address.

Use logs to distinguish the entry point, routing and handshake

Open the log panel in the main window, clear the old entries and make one request. Check the logs for entries at the same time. If there’s no matching entry, the request may not have reached the client, or access logging may be disabled. Use an explicit-proxy test to narrow it down; a blank log alone isn’t conclusive. Once you see a local connection entry, check the destination domain, outbound tag and error type to confirm whether routing sent the request through the intended outbound.

Temporarily setting “Log level” to info can provide useful startup and error context. Whether access logs appear also depends on the core and its logging configuration. After reproducing the issue, switch back to warning to avoid generating excessive logs. Before sharing logs, remove subscription URLs, server addresses, user identifiers and credentials. Keep only the error text, destination type and sequence of events.

Fix the issue based on test results; don’t reinstall everything at once

If an explicit proxy works but the browser doesn’t, go to System proxy not working. If the local port works but all remote connections time out, see Node timeouts. If only domain names fail, check DNS and routing. If only one site is affected, compare its behavior across nodes and with a direct connection first. Don’t mistake a site-specific access policy for a client-wide failure.

After applying a fix, retest in your original browser and network environment to make sure it works outside a temporary setup. For a shorter checklist, see Troubleshooting: Connected but Can’t Open Websites. Keep the changes that fixed the problem and undo any extra rules added during diagnosis so temporary settings don’t obscure the next issue.

Diagnostic layers › Server address › Transport port › Protocol handshake

Node timeouts: distinguish TCP reachability from protocol connectivity

V2Ray latency tests don’t all measure the same thing. Tcping mainly checks the connection to a server’s specified port, while a real-connection test usually sends a request to a test URL through the selected proxy configuration. A successful TCP test doesn’t confirm that authentication, TLS or transport settings are correct; a failed real-connection test may mean the test URL is unreachable. Note the test method and full error so you don’t compare different metrics as if they were the same.

Start with address resolution and port connectivity

Open the node editor and check for accidental spaces in the server address and confirm the port matches the server details. The address field should usually contain a hostname or IP, not a full web URL with a path. If the hostname won’t resolve, check name resolution on the current network first. A connection refused error differs from a timeout: refusal often means the destination is reachable but nothing is accepting connections on that port, while a timeout may involve the network path, a firewall or a lack of response from the remote server.

On Windows, use Test-NetConnection to check the server port. Replace the address in the command with the actual server address; this test only checks connectivity. Don’t substitute a website’s port for the node’s port. If the node works on a mobile hotspot but not on your home network, compare DNS, IPv6, egress policies and security software rules on the two networks before changing protocol settings.

Check TLS, transport and authentication settings

If TCP connects but the handshake fails, compare the node’s settings with the provider’s original details: user ID, password, transport, TLS, server name and path. A WebSocket path or Host value is not the server address; a gRPC service name is not a free-form label. Whether a field should be blank depends on the server configuration, so don’t copy settings from another node. Change one field, test once and restore the original value if it still fails.

For REALITY nodes, the public key, short ID and server name must also match the values supplied by the server. Don’t generate replacements for fields in your subscription or change a server name to its IP just because it looks like a website. These parameters work together, and “optimizing” one field on its own can break the entire configuration. If fields are missing after import, check that the client and selected core support the configuration, then ask the provider to verify it.

For certificate expiry, hostname mismatch or handshake verification errors, first check the system date, time and time zone. Then confirm that the certificate name matches the server name. HTTPS inspection on a corporate network may also affect the connection. Don’t use “Allow insecure” as a general fix: it weakens certificate verification and won’t resolve a blocked port, incorrect password or mismatched transport path.

Narrow down the issue with cross-tests

Keep the test URL the same. Compare two nodes in the same subscription, then test the same node on different networks. If just one node fails, suspect its settings or the server. If all nodes fail at once, check the local network, core startup and subscription status first. If only one protocol type fails, check whether the selected core supports it and review shared settings for that transport. Don’t delete the entire subscription.

Know the limits of each test

Keep the real-connection test URL consistent; don’t rank results from before and after changing it as if they were comparable. Some sites limit automated requests, redirect them or block certain exits, so a failed test doesn’t mean the proxy is completely unusable. Open a real page in a browser and check the logs at the same time to cover what an automated test may miss.

If the connection still times out, include the protocol, transport, TLS status, results for the same node on another network and a redacted error report when asking for help. Don’t share a full subscription link. For help choosing a node and testing a connection, see First Connection: Real-Connection Speed Tests and Proxy Checks. Download the client and choose a platform from the Download page.

Diagnostic layers › Subscription request › Response content › Node parsing

Subscription update failed: check the download, then the parsing

A subscription update has two stages: retrieving the subscription data and parsing it into nodes the client can use. Network timeouts, authentication failures and incompatible content formats need different fixes. First open “Subscription Group Settings” to confirm which group is being updated, then check the latest update log. Don’t repeatedly import the same URL and create duplicate groups; it makes it harder to tell old nodes from the latest results.

Check that the URL is complete and access is still valid

Edit the subscription group and check the beginning, end and query parameters of the URL. Messaging apps may truncate long links, and copying can introduce line breaks or non-ASCII punctuation. A subscription URL with authentication parameters is a credential. Don’t paste it into public pages, online converters or screenshots. If the provider has reset the URL, the old one may still open but no longer return valid nodes.

An expired subscription, exhausted data allowance or changed account permissions may cause the service to return an information page instead of a node list. For an HTTP authentication or access-denied error, check your account status with the provider first. Don’t treat an authentication error as a missing client setting or try to bypass access controls by changing identifiers in the URL. Continue with network troubleshooting only after confirming the URL and account are valid.

Compare direct updates with updates through the proxy

The v2rayN “Subscription Group” menu usually offers options to update a subscription directly or through a proxy, though the exact labels may vary. If a direct update fails while an existing node still works, try updating through that proxy. Conversely, proxy updates will fail if the current node is down. Switch to a working node or test a direct update instead of repeatedly sending the request through the same failed route.

If both direct and proxied updates fail, check where the error occurs. For a DNS resolution error, check DNS; for a connection timeout, check the network path; for a TLS error, check the time and certificate environment. Opening the subscription URL in a browser doesn’t prove the client can retrieve it: the browser may use a different proxy, login session or security challenge. Confirm that both use the same network route before comparing them.

What to do when the download succeeds but no nodes appear

If the update log reports success but the node count hasn’t changed, check whether the response is a web page, an error message or an incompatible format. A successful HTTP status can still return a login page. Standard share links, encoded node lists and configuration formats for other clients aren’t interchangeable. An extension or the word “subscription” in a URL doesn’t guarantee that v2rayN supports its format.

If only some nodes fail to import, compare their protocols, transports and shared settings. An older client may not recognize newer parameters. Back up your configuration, then update from the v2rayN download page using a package that matches your system. Don’t delete fields you don’t recognize just to force an import: nodes missing essential authentication or transport settings won’t connect even if they appear in the list.

A node that appears not to have updated may simply be hidden by a filter. Check the selected group, keyword filter and sort order to make sure new nodes aren’t hidden. Review any filters set on the subscription group, then compare notes and server addresses before and after the update. A changed note doesn’t mean a new server, and duplicate nodes don’t necessarily mean the update failed; use the log and actual subscription content to confirm.

Keep the old configuration and make updates easy to roll back

Before updating, export the current working configuration and note the group settings. Backup files contain sensitive node details, so store them securely. If you suspect a subscription format is the problem, test it in a temporary group before replacing the original. If the test fails, delete the temporary group; there’s no need to clear every server. Before bulk deletion, deduplication or overwriting, confirm exactly what the operation will affect.

Once troubleshooting is done, decide whether automatic updates make sense. If an update on every launch causes the client to hang, temporarily disable the scheduled task and verify that manual updates work reliably. Automatic retries won’t fix an invalid URL or incompatible content, and may obscure the original error. Record which update method, network and group worked; that’s more useful than a vague note like “fixed after restart.”

Diagnostic layers › Baseline comparison › Exit load › Transport path

Slow connections: separate latency, throughput and app response time

Slow page loads, low download speeds and frequent video buffering aren’t necessarily the same problem. Latency affects how long it takes to start a request, throughput measures sustained transfer speed, and packet loss and retransmissions can make performance fluctuate. A low-latency node may not be best for large downloads. First note whether the slowdown happens on initial load, during sustained transfers or after the connection has been running for a while, then choose the right comparison.

Set a consistent baseline for testing

Pause cloud sync, system updates and other downloads. Keep the device, Wi-Fi location, destination and test window as consistent as possible. Don’t run bulk speed tests while judging browser performance; concurrent requests compete for bandwidth. Run the same real-world task on two nodes several times and look for a consistent difference. A one-off peak may be due to caching or a brief lull, not typical performance.

Next, test the underlying connection with the system proxy cleared and TUN turned off. If direct downloads are also slow, check the Wi-Fi signal, router load and broadband usage. If possible, compare using Ethernet. A mobile hotspot is useful as a test on another network, but it won’t have the same bandwidth as your regular connection. If the baseline is unstable, changing proxy settings is likely to produce inconsistent results.

Compare node load and destination-site behavior

If only one node is slow at a given time, the cause may be exit load, connection quality or the route from that exit to the destination. Keep the destination the same when switching nodes and check whether the improvement is repeatable. If only one download site is slow, while others work normally, consider rate limits, account tier, connection limits and content delivery policies. A different exit can change the route, but it can’t guarantee that the site’s own limits will go away.

Don’t assume a node’s location label tells you how good its physical route is. The label is just a note; the actual path also depends on the provider’s deployment and network peering. If the connection slows during peak hours and recovers off-peak, node load is a more likely factor than your local listening port. Record real-world results and errors at different times; a report of persistent issues is more useful to a provider than a single latency reading.

Check the effects of routing, UDP and TUN

First confirm which outbound is handling the slow request. A download may be routed directly by a domain rule, while a browser extension may send browser traffic through a different exit. Check the active preset and custom rules under “Routing Settings.” If needed, use a narrowly scoped temporary rule for comparison, then remove it. Don’t route all private network traffic through the proxy just to run a speed test; that can disrupt local services and devices.

Some apps use UDP or QUIC. If a node doesn’t support that traffic, the app may wait before falling back, making the initial connection slow even if it works normally afterward. “Enable UDP” allows local handling; it doesn’t make the remote server support UDP. Establish a baseline with a standard HTTPS request before comparing an app’s protocol behavior. If you change a browser protocol setting, record its original value and restore it after testing.

TUN mode also involves a virtual network adapter, route interception and system permissions. If performance is poor only in TUN mode, turn it off and run the same task through an explicit proxy. If that works, check TUN routes, DNS interception and conflicts with other virtual adapters. An MTU mismatch can affect certain paths, but don’t copy a value from an online post without evidence. First confirm that large transfers fail while smaller requests work, then change one setting at a time.

Skip speculative tweaks and verify performance over time

Connection reuse, transport settings and core selection don’t make a connection faster simply by being enabled. Features that don’t match the server may create compatibility issues. Keep the transport defaults supplied by the subscription and first address visible packet loss, exit load and routing errors. If switching cores improves performance, confirm you’re testing the same node and rules so differences between routes aren’t mistaken for a core-related improvement.

Finish by observing everyday apps over time, not just a speed-test page. Note when the slowdown occurs, whether it comes with connection errors, and whether switching nodes or networks helps. For routing issues, see geosite and geoip routing rules. The goal is to find a consistent bottleneck, not to get lucky with one fast result after repeatedly changing settings.

Diagnostic layers › System resolution › Core DNS › Routing resolution

DNS issues: find out which layer resolves the domain

The same domain may be resolved by the operating system, browser Secure DNS, core DNS or the proxy server. If changing system DNS makes no difference, that doesn’t mean the setting failed to save; the request may not be using it. Note the app, proxy entry point and node type, then check the logs for resolution errors. Identify where resolution happens before deciding whether to change system settings or core configuration.

Distinguish DNS errors from connection errors

A nonexistent domain, a DNS timeout and a timeout connecting to the destination are different problems. Successful resolution only means an address was returned; it doesn’t guarantee that the address is correct or reachable. Don’t rely solely on “the IP works but the domain doesn’t” as evidence: connecting to an HTTPS site by IP may fail because of the certificate name, server name indication or virtual hosting. That doesn’t necessarily mean DNS is the problem.

Run nslookup example.com in a system terminal to check whether the system resolver returns a result. This tool usually doesn’t use a browser’s Secure DNS and doesn’t automatically use v2rayN’s core DNS. It’s useful for testing the system layer, but not enough to prove which DNS path a proxied request uses. Note the resolver when comparing results so you don’t draw conclusions from two different paths.

Understand what domainStrategy controls

routing.domainStrategy controls how routing rules use domain names and their resolved IP addresses. AsIs generally keeps the domain name for rule matching; IPIfNonMatch attempts to resolve the domain and check IP rules if no domain rule matches. This field is not a master switch that sends all DNS requests through the proxy, and it doesn’t replace app-level or system-level DNS settings.

The snippet below is a partial Xray/V2Ray-style configuration to illustrate how the fields relate; it isn’t a complete client configuration. Merge it into the configuration system for the relevant core, and confirm that the existing direct outbound tag is actually direct. v2rayN’s graphical routing editor generates the configuration, so edits to temporary runtime files may be overwritten on the next launch. The rule data referenced here must also be available.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Check whether the DNS server itself is reachable

With DoH, consider the DNS server address, certificate verification and network path to the server together. DoH encrypts DNS traffic; it doesn’t decide whether requests use a direct or proxied route. If the DNS server’s hostname needs resolving and reaching the server depends on a proxy that hasn’t connected yet, startup may be blocked by a dependency loop. Plan bootstrap resolution and routing around the capabilities of the core you use; simply changing the URL may not help.

Restore a known-good DNS setup first and confirm basic resolution before adding routing rules. DNS fields differ between cores, so don’t paste a snippet for one core into another. The “DNS Settings” and “TUN Mode Settings” in the interface may control different stages. Check which core is active and what traffic it intercepts before choosing where to make changes.

If some sites time out only when IPv6 is enabled, check whether the local network has a working IPv6 route, not just whether the network adapter has an IPv6 address. Some networks return IPv6 records but can’t complete the connection. You can temporarily compare results with IPv4 only under controlled conditions, but don’t treat disabling IPv6 as the default fix for every DNS issue. Reassess your original requirements after resolving the problem.

Clear caches and verify the DNS path

After making changes, close and reopen the affected apps. If needed, run ipconfig /flushdns on Windows to clear the system DNS cache. This doesn’t clear browser, core or server-side caches. Retest the same domain and check whether the error has changed from a resolution failure to a connection failure. A change in failure stage means troubleshooting has made progress; don’t simply label it “still broken.”

Online DNS tests show the resolution path visible to that test method; they don’t prove how all traffic is routed. Browser Secure DNS, caching and proxy mode can all affect the result. For routing details, see DNS and DoH Setup Notes; for path verification, see DNS Leak Tests and Prevention. Identify the expected DNS exit first, then check whether the test result differs.

Diagnostic layers › App proxy › System entry point › TUN interception

System proxy not working: check whether the app uses it

“Automatically Configure System Proxy” mainly writes the local proxy entry to the operating system settings; it doesn’t mean every app will use it. Some apps have their own proxy settings, some only read environment variables, and others open sockets directly. The key is to identify which entry point the target app uses and whether it points to the address and port currently being monitored—not to keep toggling the setting on and off.

Compare the system settings with the active listener

In the v2rayN main window or tray menu, choose “System Proxy → Automatically Configure System Proxy.” Then open Windows “Settings → Network & Internet → Proxy” and check the address and port. The address should usually point to the local loopback address, and the port must match “Local mixed-protocol listening port.” If the setting changes back immediately, check whether another proxy app, management tool or organization policy is taking control.

Use the command below to check whether common ports are listening. If there’s no output, first confirm the actual port and then check the core process. If there is output, the listener may not be v2rayN; identify the program using the process ID. Don’t terminate system processes just to troubleshoot. If another app is using the port, switch to an unused one, then update the system settings and any apps configured manually.

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

You don’t need to enable “Allow connections from the local network” for apps on the same computer. That option changes who can reach the listener; it won’t make apps that ignore the system proxy start using it. Enable it only if other devices actually need to connect to this computer, and consider the listening address, firewall and access scope together. When troubleshooting is complete, restore the narrowest listening scope you need.

Rule out separate browser and command-line proxy settings

Browser proxy extensions, enterprise policies and browser settings can override the system proxy. Disable extensions and restart the browser, then compare it with an explicit-proxy request. Command-line tools may read environment variables such as HTTP_PROXY, HTTPS_PROXY or ALL_PROXY; existing terminal sessions retain the environment they started with. Open a new terminal after changing variables instead of repeating the request in the old one.

Windows user proxy settings and WinHTTP proxy settings come from different sources. Run netsh winhttp show proxy to check WinHTTP, but a direct-connection result doesn’t prove that a regular browser isn’t using the user proxy. Don’t run a global reset command to troubleshoot every app at once. First find out which settings the target program reads, then check its official proxy options to avoid affecting system services or organization policies.

Distinguish PAC, routing rules and app-level bypasses

With PAC, the script decides which requests go to the proxy entry point. Core routing decides which outbound handles a request after it reaches the client. These are separate routing layers. If a site doesn’t appear in the proxy logs, the PAC script may have sent it directly, or the app may not be using the system proxy at all. To narrow it down, temporarily test with an explicit manual proxy entry, then check core rules. Don’t change both layers at once.

If a request reaches the core but takes the wrong outbound, check the order of the rules under “Routing Settings.” Place more specific rules before broad rules that might match first, and preserve any required local network access. Domain matching can also depend on traffic sniffing and DNS policy, so don’t guess which rule matched based only on the final IP. Retest with the same URL and browser to avoid confusion from redirecting to other domains.

Check TUN interception only if you need it

If the target app doesn’t support a proxy entry point, consider TUN mode. First confirm that the regular system proxy works, then grant the virtual adapter and route-management permissions required by the system. TUN won’t fix a remote node that can’t connect; if an explicit proxy also fails, troubleshoot the node first. After enabling TUN, check for conflicts with other VPNs, virtual machine adapters and security software that may also change routes.

Desktop proxy entry points differ on macOS and Linux, and apps vary in whether they follow the desktop settings. Don’t copy Windows-specific paths. To rebuild the basic setup, return to the system proxy steps in the guide. When troubleshooting is complete, quit unnecessary proxy tools and confirm the settings still match after reopening the app and restarting the client.

Diagnostic layers › Graphical interface › Core process › Runtime environment

Client crashes: distinguish the app closing from the core exiting

A window that won’t open, a window that closes immediately, a core that keeps restarting and a client that exits after connecting are four different problems. Note the last time it worked and any recent changes: did you update the client, move its folder, import a custom configuration or enable TUN? Don’t delete the entire folder right away. Clearing configuration, logs and runtime files together often leaves only an issue you can no longer reproduce.

Check the operating system, architecture and installation location first

Choose an installer for your platform and processor from the Download page. Windows desktop and classic WPF builds use different interface frameworks; don’t assume their configuration directories can be freely overwritten. For macOS, choose between Apple Silicon and Intel. For Linux, match the package format and processor architecture to your distribution. If you downloaded the wrong package, choose the correct one instead of renaming files or mixing files from other architectures.

If you run the client from an extracted folder, extract it fully instead of opening it from the archive preview. Make sure the folder is writable, there’s enough disk space, and the path isn’t a restricted temporary location. Portable and installed versions may store settings in different places, so don’t overwrite the program folder with a backup based on guesswork. Export the configuration or back up the actual data directory before migrating or updating.

Use a clean configuration to isolate data problems

After backing up your data, launch the same platform’s client from a separate folder or user data environment without importing the old configuration. Check whether a clean setup opens reliably. Don’t let two instances compete for the same port. If the new environment works, import the subscription, routing and DNS settings one category at a time, restarting and testing after each. This can reveal whether the data is corrupted or a custom feature is triggering the crash.

If the client still closes with a clean configuration, check system error records and runtime requirements. On Windows, look for the faulty module in Event Viewer’s Application log. On macOS, check the system crash reports. On Linux, launch the graphical app from a terminal and review startup errors. Record the error text instead of only capturing the last window. Follow the runtime requirements for your installer; don’t download random components from unknown sites.

If the core exits, start with the first error

If the interface stays open but the core won’t keep running, look for the first clear error in the startup log. A port conflict, invalid configuration field, missing rule data or insufficient permissions can cause a cascade of connection failures. Fix the first error, restart and then check what remains. Don’t treat the final “connection refused” message as the root cause; it may only mean the core has already exited.

For a custom configuration, check that the syntax is valid, outbound tags exist and referenced rule data is available. Core settings aren’t interchangeable, so review custom snippets after switching cores. Generated runtime configuration may be rebuilt at the next launch; make changes in the graphical settings or the original custom configuration instead. If the error started after adding a routing rule, remove that rule first rather than replacing both the client and node.

Updates, rollbacks and security software

If the issue started after an update, save the error and old configuration, then compare the behavior before and after the update in an isolated environment. Don’t copy all the old program files over the new installation; mixing runtime files can create new compatibility issues. If you need to roll back, use a complete installer from a known source and keep the current data separate so old and new configuration formats don’t overwrite each other.

If security software blocks the client, check the specific event, file path and time to see whether it matches the startup failure. Don’t disable all protection as a routine step or add an exclusion for the entire disk. On a managed work or school device, ask the administrator what’s permitted. After resolving the issue, clear any leftover system proxy settings, reopen the client and make a real connection to confirm that both the interface and core run reliably.

Diagnostic layers › VPN permission › App routing › Background activity and network changes

Android troubleshooting: VPN permissions, per-app routing and background disconnects

On Android, v2rayNG is the recommended client, with v2flyNG as an alternative using the V2Fly core. The desktop “system proxy” approach doesn’t apply directly: Android clients typically route traffic through the system VPN interface, while the configuration determines the outbound path. A VPN icon only confirms that the system tunnel is established; the remote node may still fail authentication or time out. Verify with real traffic and logs.

First launch and VPN permission

After importing a node, select it and confirm the system VPN permission prompt when starting the connection. If the prompt doesn’t appear or is hidden behind another screen, bring the client to the foreground and try again. Check whether another VPN app is running. Android typically allows one app per user to hold the VPN connection; switching between two clients can replace the active tunnel and cause seemingly random disconnects.

Choose an installer that matches your device architecture from the Android download page. Most newer devices use arm64. If you’re not sure, check the system information or choose a universal package. If installation fails, check for an Android version requirement, installation permissions, a signature conflict or insufficient storage instead of downloading repeatedly. If an update fails because of a signature conflict, export your configuration first, then consider how uninstalling and reinstalling may affect your data.

Check per-app proxy and routing modes

If a browser works but another app doesn’t, check the client’s per-app proxy settings. Confirm whether it’s set to “proxy selected apps only” or “bypass selected apps”—these work in opposite directions. System apps, work-profile apps and regular user apps may also run in different environments. A similar name in the list doesn’t prove that the target app is included. Restart the connection after making changes, then test again.

If no apps work, temporarily remove extra per-app filters and test with one known-good node and basic routing. Don’t change remote DNS, traffic sniffing, IPv6 and the app list all at once. If an app uses UDP, check whether the node and core actually support it. The VPN tunnel can capture traffic without guaranteeing that the remote server can forward every protocol the app needs.

Some apps cache connections or DNS results, so they may keep using an old connection after routing changes. Stop and reopen the app, or disconnect and reconnect the client. Clearing app data can affect logins and local files, so don’t make it your first step. Cross-test with a browser and another regular app before deciding whether the issue is limited to one app.

Disconnects with the screen off and network changes

If the connection works with the screen on but fails after the device has been locked for a while, check battery optimization, background activity limits and the manufacturer’s task manager settings. Follow the device’s settings to let the client run in the background and keep its connection notification enabled. Don’t grant background permissions to every app; change them only for the client that needs to maintain the tunnel. These settings may change after a system update, so check them again if the problem returns.

Android’s “Always-on VPN” and “Block connections without VPN” settings change what happens to network traffic during a disconnect. With the latter enabled, internet access may stop while the client exits or reconnects—that’s expected. Decide whether you need this behavior. To test basic connectivity, you can temporarily turn off the relevant restriction, but note its original setting and restore it after testing if needed.

If the connection fails after switching from Wi-Fi to mobile data, disconnect and reconnect, then check whether it recovers. A network change affects the IP address, DNS and existing connections; the old connection may not survive. If the issue occurs only on one network, test the same node on both and check whether the network requires a sign-in or has an unreliable IPv6 route. Don’t assume every failure after a network switch is caused by the client being stopped in the background.

Mobile DNS and troubleshooting evidence

Android Private DNS, browser Secure DNS and the client’s DNS settings can all affect resolution. If domains fail, note these settings instead of turning them all off at once. For DNS timeouts in the logs, check the current network and the client’s remote DNS path. If only one browser is affected, compare its DNS behavior first. For more detail, work through the DNS troubleshooting section layer by layer.

When reporting an Android issue, include the device OS, client name, network type, screen-lock and network-switch conditions, and whether the VPN connection remained active. Add the first error after removing sensitive details, and say whether the same node works in desktop v2rayN. Cross-device tests can narrow down the cause, but don’t prove that configurations are identical. After a fix, test again by locking the screen, waking the device and switching networks to make sure it covers the scenario that triggered the problem.