chapter one
No internet access: separate local network problems from proxy failures
“No web pages load after enabling the proxy” does not automatically mean the node is down. A browser request travels from the application to the target site through the system proxy, local listening port, client routing, protocol connection, and DNS resolution. An interruption at any layer can look the same. The most effective starting point is not reinstalling the client, but checking whether the network recovers after closing it and then deciding whether the fault is in the proxy path or the underlying network.
Establish a direct-connection baseline
First disable the system proxy or stop the connection in the client. Fully quit any browser configured with its own proxy, then open an ordinary web page again. If access still fails, prioritize Wi-Fi, wired networking, router login, network authentication, or upstream connectivity. You can temporarily switch to another known-good network for comparison, but do not immediately change the client configuration. If access works with the proxy off and fails as soon as it is enabled, the fault is in the client path.
On desktop systems, also distinguish between closing the client window and exiting the background process. v2rayN usually remains running in the system tray after its main window is closed, and the system proxy may still point to a local port. Exit from the tray menu, then check that the system proxy is disabled. If the browser has its own HTTP or SOCKS proxy configured, temporarily switch it back to “Use system settings” or disable the manual proxy so an old port cannot continue handling requests.
Confirm that the local listening port exists
The system proxy only forwards requests to a local address such as 127.0.0.1 and a listening port; the client core actually receives those requests. If the core has not started or the port is occupied by another program, the system proxy will not work even when it appears enabled. In v2rayN, first inspect the runtime log and confirm that the configuration loaded without a port-conflict message such as “address already in use”. On Windows, check whether common local ports are listening from a terminal:
netstat -ano | findstr LISTENING
netstat -ano | findstr 10808Replace the port in the second command with the actual port shown on the client settings page. No output means that no process is listening on the current port. If the process ID belongs to something other than the running client, a port conflict may exist. Exit the program using the port, or change the local listening port in v2rayN, then update the browser’s manual proxy, command-line environment variables, and any other software that depends on the old port. For more detail, see Troubleshooting local port conflicts.
Use a minimal configuration to rule out routing interference
Once the listener is confirmed, temporarily switch the routing mode to global and select a known-good node. Global mode bypasses custom rules, domain categories, and direct-connection settings, making it useful for determining whether traffic splitting is the cause. If global mode works but the original mode does not, restore the original mode and check the rule order one by one, especially the leading domain, geosite, geoip, and fallback rules. Rules are usually matched from top to bottom; an overly broad direct rule can end matching before a request reaches the proxy.
If global mode still fails, try another node from the same subscription. If one node fails while others work, the local proxy path is probably intact and the issue is limited to the node parameters or server status. If every node fails, continue with the system clock, firewall, protocol parameters, and DNS. Do not equate a numeric latency result with guaranteed web access: some tests verify only TCP connectivity and do not cover the complete protocol handshake, transport layer, or target request.
| Baseline result | Priority checks | Next step |
|---|---|---|
| No internet access with the proxy off | Local network, router, network authentication | Restore the underlying network first |
| Everything fails with the proxy on | Listening port, core startup, system proxy | Check the log and port |
| Only some nodes fail | Node status, protocol, and transport parameters | Go to the node timeout section |
| Global mode works, traffic splitting fails | Routing rule order and outbound path | Reduce custom rules |
chapter two
Node timeouts: check parameters by connection layer
A node timeout means the client did not receive the expected response within the allowed time, but the timeout may occur at different stages. A domain that cannot resolve, a target port that cannot establish a TCP connection, a failed TLS handshake, and mismatched protocol identity parameters can all produce similar errors. Start with conditions independent of the node configuration, then move into protocol details. Avoid repeatedly editing the UUID, path, or transport before the local network has been confirmed.
Check the system clock and target address first
Clock drift affects TLS certificate validity checks and can also break authentication flows that depend on a time window. Windows, macOS, Android, and Linux should all use automatic date, time, and time-zone settings, followed by a manual resynchronization. Drift is more likely after long sleep periods, dual-booting, or a failing motherboard battery. After correcting the time, fully stop the core and reconnect; existing connections will not redo the entire handshake automatically.
Next, verify the node address. If it is a domain, first confirm that the device can resolve it. If it is an IP address, rule out extra spaces, an incorrect port separator, or a protocol prefix introduced during copying. The node address field should contain only a hostname or IP; do not include the full subscription URL, web path, or https://. The port must be the target port supplied by the subscription, not the local SOCKS or HTTP listening port.
Distinguish network reachability from protocol handshake failure
On desktop systems, use system tools to check whether the target host can establish a TCP connection. In Windows PowerShell, run the following command, replacing the host and port with the values in the node configuration:
Test-NetConnection example.com -Port 443On Linux or macOS, use:
nc -vz example.com 443The command checks only the target port; it does not validate VMess, VLESS, Trojan, or transport-layer settings. If the port test fails, first check the local network, target address, port, and server reachability. If the port test succeeds but the client handshake fails, focus on the protocol parameters. Some networks restrict diagnostic commands, so one failed test is not conclusive; repeat it on another network if possible.
When reading logs, note the stage where the error occurs. Domain-resolution errors commonly mention lookup, resolve, or DNS. “connection refused” means the target explicitly rejected the connection. “timeout” means the request did not return within the time limit. Errors mentioning certificate, handshake, or TLS are often related to the domain, certificate name, system clock, or TLS parameters. Do not capture only the final line; the preceding and following dozen lines often contain the address and outbound path that triggered the failure.
Compare protocol and transport fields one by one
When entering a node manually, check the protocol and transport layers separately. Common VMess fields include the address, port, user ID, and encryption or security options. For VLESS, verify the user ID, flow control, encryption, and corresponding transport settings. For Trojan, focus on the password, TLS server name, and transport parameters. For WebSocket, also check the path and Host; for gRPC, check the service name. REALITY settings must match the subscription, including the server name, public key, short ID, and fingerprint. Any field that looks similar but is not identical can cause the handshake to fail.
If the node comes from a subscription, update the subscription again instead of patching fields manually. After the provider changes transport parameters, the old node name may remain unchanged while its internal configuration differs. Confirm that the subscription URL itself is valid, update it, select a newly generated node, and restart the core. If every node times out, follow the node timeout troubleshooting checklist to check the local network and system clock. If only one node fails, keep the others for comparison instead of deleting the entire subscription group.
chapter three
Subscription failures: identify download, parsing, or overwrite problems
A subscription update has three consecutive stages: the client requests the subscription URL, receives the response, and parses it into nodes before writing them to the subscription group. When the interface shows only “Update failed”, use the log and update result to identify the failed stage. An unreachable subscription URL, a login page in the response, an unsupported format, or a group filter hiding nodes can all appear as an empty list.
Confirm that the subscription URL is complete and valid for its purpose
Copy the subscription URL in full from the management page that provides it; do not manually remove query parameters. The token, parameters, or path at the end of the URL usually identify the subscription, and one missing character can return an error page. After pasting it into v2rayN, v2rayNG, or v2flyNG, check that the beginning and end contain no Chinese quotation marks, line breaks, spaces, or punctuation added by a chat app. After importing a QR code, inspect the subscription entry instead of merely confirming that scanning completed.
A subscription URL and a single-node share link serve different purposes. A subscription URL periodically retrieves a set of configurations, while a single-node link usually begins with a protocol name and represents one configuration. Putting a single-node link into subscription management may produce a format error; importing a subscription URL as a single node will not produce the expected result either. For moving configurations between devices, see Subscription URLs, configuration exports, and QR-code migration compared and choose a method based on your update needs.
Use the response to locate the request stage
During an update, watch the log for HTTP status codes, redirects, timeouts, and parsing messages. A connection timeout means the client has not received a response; check the current network, subscription-domain resolution, and system proxy path. An unauthorized or forbidden response usually means that a new valid subscription URL is required. A successful response with zero parsed nodes suggests an unsupported subscription format or web-page content. Subscription URLs may expire or be restricted by device rules. When they become invalid, generate a new one through the original service entry point rather than trying to repair it by editing local node parameters.
If the subscription can be requested directly over the ordinary network, first disable “Update subscriptions through proxy” for a test. If it is available only when the proxy connection works, choose a known-good old node and then enable proxy-based updates. Avoid circular dependencies: when no usable node exists, requiring the subscription update to go through the proxy prevents the update from starting. Option names vary slightly between clients, so use the subscription settings and update log as the reference.
The update succeeds but no nodes appear
After the log confirms a successful subscription retrieval, check the group, filters, and overwrite behavior. Switch to the group just updated, clear any name filter, and check whether keyword include or exclude rules are enabled. Spaces, regular expressions, or case differences in a filter can hide every node. If the client can delete old configurations during an update, an empty result may also clear the existing list, so export currently working configurations before changing subscription settings.
Adding the same subscription more than once can create groups with identical names but different sources, making it easy to look for new nodes in the old group. Keep one valid entry, give the group a name that identifies its source, and perform a complete update. When the subscription changes, the currently selected node may no longer exist; choose a node from the new list and start the connection again. A refreshed list does not mean that the running core has switched to the new configuration.
If nodes exist after import but all time out, stop investigating the subscription and return to the previous section to check the network and node parameters. If only some nodes are missing, compare them with the protocols and transports supported by the client. Prefer v2rayN on desktop and v2rayNG on Android; choose v2flyNG when the v2fly core ecosystem is required. Use the Download Center for client entry points and supported platforms.
| Update result | Possible stage | What to check |
|---|---|---|
| Request timed out | Subscription download | Network, DNS, proxy update settings |
| Unauthorized response | Subscription access | URL validity and complete parameters |
| Zero nodes parsed | Content parsing | Response format, web redirects, client support |
| Success but the list is empty | Writing and display | Group, filter, and overwrite settings |
chapter four
Slow speeds: separate local bandwidth, node, and routing effects
A single page load cannot determine why speeds are slow. The first visit includes DNS, TCP, TLS, and content loading, while browser cache, target-site load, and local wireless signal also affect the result. Troubleshoot with a controlled comparison on the same device, network, and roughly the same time: measure the baseline with the proxy off, test several nodes with it on, then compare global and split-routing modes. Only controlled variables can show whether the bottleneck is local, on the node, or in the rules.
Build a repeatable comparison test
First stop large-file synchronization, system updates, cloud uploads, and high-traffic tasks on other devices. With the proxy off, choose a fixed test target and record download, upload, and response performance. Then enable the proxy and repeat the test against the same target. Run each state at least twice and discard one obvious outlier. Do not change the Wi-Fi band, browser, node, and DNS during the test, or the results will not be comparable.
For wireless networks, pay close attention to signal quality and interference. If moving the device closer to the router restores speed, the proxy is probably not the main bottleneck. Use a wired connection for comparison on a computer; on Android, switch once between Wi-Fi and mobile data. Switching mobile networks changes the address and route, so use it only to determine whether the current Wi-Fi is abnormal. Do not treat absolute speeds on the two networks as a direct measure of node quality.
Interpret latency tests and sustained throughput correctly
A latency test measures the time needed to establish a connection or complete a specific request; it is not sustained download speed. A low-latency node may have limited bandwidth, while a high-latency node may remain stable during a large-file transfer. A real connection test helps rule out completely unusable nodes, but node selection should also consider the target, sustained transfers, and stability. Do not switch repeatedly based on a single ranking; rebuilding connections creates additional waiting time.
Test two or three nodes from the same subscription. If every node is much slower than the baseline network, check for an extra proxy chain, overly complex routing, or unsuitable transport settings in the client. If only one node is slow, replace that node first. If performance drops only during peak hours, the cause is usually path or server load variation; reinstalling the client cannot increase upstream capacity.
Check split routing, concurrency, and application proxy settings
In global mode, every request goes through the proxy, including large files that could connect directly, system updates, and local-network services. This adds load to the node and may route local traffic unnecessarily. Switch back to a mode that bypasses the LAN or uses sensible split routing, then confirm that local addresses, printers, storage devices, and commonly direct domains use the correct outbound path. Order custom rules from specific to broad so an overly broad proxy rule does not capture all traffic too early. See domain, ip, and geosite routing rules explained for syntax and priority.
Browser extensions, download tools, and development environments may not use the system proxy and may instead have their own SOCKS or HTTP port configured. If the port type is wrong, some requests will fail and retry, appearing slow. Check that the application’s protocol type matches the client inbound, and do not enter a SOCKS proxy in the HTTP proxy field. Command-line tools may also read HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY; old environment variables can override the current system setting.
If performance slows only after enabling a specific DNS mode, the resolver may be slow, falling back incorrectly, or sending the domain through an unsuitable outbound path. Restore the client’s default DNS configuration and restart the core, then compare the first request with later requests. A slow first request followed by normal refreshes points more toward DNS or connection setup; persistently low transfer speed points more toward link bandwidth, node load, or local network quality.
chapter five
DNS issues: check from resolution results to outbound routing
DNS converts domain names into addresses that can be connected to. When an IP address works but the domain does not, some domains fail intermittently, or the connection log reports a lookup error, investigate DNS as a separate layer. A V2Ray client may use the system resolver or specify servers, query policies, and an outbound path in its core configuration. Changing system DNS and client DNS at the same time makes the causes harder to separate.
First determine whether DNS resolution is actually failing
Query the same failing domain with the proxy off and on, and check whether an address is returned. On Windows, use:
nslookup example.comOn Linux or macOS, use:
dig example.com
# When dig is not available on the system
nslookup example.comA result from the query does not guarantee that the final connection will succeed, but no result, a server failure, or a long wait means the resolution path needs further checking. A browser may use its own encrypted DNS and follow a different path from system commands, so temporarily restore the browser’s system-default resolver and compare again. If the command works but only one browser fails, focus on the browser cache, extensions, and independent DNS settings.
Clear caches and restore a single control point
After DNS records change, the system, browser, and client may all retain stale cache entries. On Windows, run the following from an administrator terminal:
ipconfig /flushdnsAfter clearing the cache, fully close the browser and restart the client core. On Linux, the cache method depends on the system service. First check whether systemd-resolved is in use, then run:
resolvectl status
sudo resolvectl flush-cachesDo not change router DNS, system DNS, browser DNS, and client DNS in the same troubleshooting round. First restore the browser to follow the system and restore the client DNS to its default, leaving the system as the only observable setting. Once basic resolution works, enable the client’s remote resolution, domain policy, or split DNS one item at a time. This makes it clear which layer introduces the problem.
Check the relationship between query policy and outbound path
The domainStrategy setting determines when routing rules use resolved domain results. AsIs tends to keep the domain available for matching; other strategies may resolve it to an IP when needed and then apply IP rules. It is not simply a “DNS switch”; changing it affects routing matches. If rules depend on geoip but the domain is never resolved to an IP, those rules may not work as expected. If resolution happens too early, domain rules may lose their opportunity to match first.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}The example keeps the domain and sends private addresses through the direct outbound path. Actual clients may generate a complete configuration through their graphical interface, so do not overwrite a client-managed configuration file directly. If customization is necessary, export the current configuration for reference, change only the relevant fields, and inspect the generated log after restarting the core. A misplaced comma, quotation mark, or hierarchy error in JSON can prevent the entire configuration from loading rather than affecting only DNS.
Also check which outbound path carries the DNS query itself. If the specified resolver is reachable only through one path but DNS requests are sent through another, the result may be “the node is connected but the domain cannot be resolved”. First validate the client’s default settings, then bind the DNS outbound path if needed. LAN domains, device names, and internal services usually depend on local resolution. Sending everything to a remote resolver may make local devices undiscoverable, so keep a direct path for private domains and private addresses.
| Symptom | Common cause | How to verify |
|---|---|---|
| All domains fail | System DNS unavailable or incorrect DNS outbound path | Test the system and client separately |
| Only the browser fails | Browser-specific DNS, cache, or extensions | Restore system DNS and disable extensions |
| LAN names fail | Local queries are sent to a remote resolver | Keep a local path for private domains |
| The first visit is very slow | Fallback after a query timeout | Check resolution time and errors in the log |
chapter six
System proxy has no effect: check scope and port consistency
When a client says “System proxy enabled”, it only means that the operating system’s proxy fields were written; it does not mean every application will follow them. Browsers usually use the system proxy, while some command-line tools, store apps, games, and standalone network programs may ignore it. First confirm that the local proxy service works, then determine which proxy mechanism the target application uses, and finally check that the system proxy address and client listening port match.
Verify the proxy address and listening port
In v2rayN settings, check the local HTTP, SOCKS, or mixed inbound port. Then open the operating system proxy settings and confirm that the address is the local loopback address and the port matches the client. After changing a port, the old system proxy value may not update everywhere automatically. If the system still points to the old port, disable the system proxy first and enable it again from the client menu. Do not enter the server port as the system proxy; the system proxy connects to the local client, not the remote node.
On Windows, use PowerShell to view the current user proxy configuration:
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
Select-Object ProxyEnable, ProxyServer, AutoConfigURLProxyEnable, ProxyServer, and the automatic configuration URL may all be present. If a proxy script was used previously, AutoConfigURL may still affect application behavior. Record the original values first, then disable unused automatic configuration in the system settings. Do not delete an unfamiliar enterprise or organizational policy; on managed devices, confirm the network policy requirements first.
Distinguish the system proxy, TUN, and app-specific proxies
The system proxy mainly affects applications that actively read the operating system proxy settings. TUN mode uses a virtual network interface to capture a broader range of traffic. They are not the same switch and should not both be toggled repeatedly while the fault is unknown. If the browser works but one application does not, check whether that application supports the system proxy. If it offers HTTP or SOCKS settings, enter the local address and port manually according to the client inbound type. If it does not support proxies at all, consider TUN instead of turning a system-proxy issue into a global configuration overhaul.
Command-line tools often have their own settings. For temporary environment variables, HTTP and SOCKS proxy formats differ:
# HTTP proxy example
set HTTPS_PROXY=http://127.0.0.1:10809
# PowerShell current session
$env:HTTPS_PROXY="http://127.0.0.1:10809"The port is only an example and must be replaced with the client’s actual HTTP inbound port. Environment variables apply only to the current session or its child processes; persistent variables may continue to exist after the client exits. Clear variables that are no longer needed after troubleshooting to avoid a situation where the system proxy is off but command-line tools still use an old port.
Remove proxy remnants and handle LAN exceptions
After an abnormal exit, system update, or account switch, proxy fields may remain set. A typical symptom is that the client is gone from the tray but the browser still reports that the proxy server refused the connection. Manually disable the proxy in system settings, restart the client, confirm that the core is listening, and then enable the proxy again. If the client keeps writing an incorrect port after restarting, check whether the local port is duplicated or multiple v2rayN instances are running.
For LAN access problems, check proxy exceptions and routing rules. Loopback addresses, private subnets, and local domains should usually connect directly. The proxy bypass list affects only applications that follow system settings, while routing rules in the V2Ray core decide which outbound path requests already inside the core use. These are different layers, so changing only one may not fix every application. First access the LAN device by IP, then by its device name. If the IP works but the name fails, return to the DNS section for local resolution.
When one browser works and another fails, compare whether both use the system proxy. An extension may force a fixed proxy, an automatic configuration script, or direct mode. Testing with a temporary browser profile that loads no extensions is faster than guessing which extension is responsible. If every application that follows the system proxy fails, return to the listening port and core log. If only one application fails, its own configuration is usually the cause.
chapter seven
Client crashes: preserve logs and reduce runtime conditions
If the client will not start, exits immediately, freezes while importing a configuration, or crashes after running for a while, first distinguish the graphical interface from the core process. The interface can close without stopping the core, and a core error does not necessarily crash the interface. Before making changes, record the action that triggered the problem, the log path, and the system environment. Then start with a minimal configuration and restore the subscription, routing, and extra features step by step.
Determine whether the interface exited or the core failed
First check the system tray and Task Manager. v2rayN may remain in the tray after its main window closes. During a real crash, the interface process disappears and the system event log may contain an application error. If the interface remains but nodes cannot connect, inspect the client runtime log; this points more closely to core startup or configuration loading failure. If the interface never appears, check the application log, system events, runtime-directory permissions, and dependencies.
On Windows, open Event Viewer and look for a matching record under Application in Windows Logs around the failure time. On a Linux desktop, launch the application from a terminal to observe standard output, and inspect the current user service log. If user-level autostart is configured, run:
systemctl --user status v2rayn
journalctl --user -u v2rayn --since todayUse the actual unit that was created as the service name. For Linux installation and user-level autostart, see the v2rayN Linux desktop installation guide. If macOS cannot start the application, confirm that it is in a stable directory, that the current account can read the configuration directory, and locate errors in the system log by startup time.
Verify basic startup with a blank configuration
Before modifying configuration files, exit the client and related core processes, then back up the configuration directory. Do not delete the only copy. Rename the existing configuration directory so the client generates a fresh default configuration. If the blank configuration starts, the program itself can run and the fault is likely in the old settings, subscription data, routing rules, or interface state. Do not copy the entire old directory back at once; restore subscriptions, routing, custom DNS, and interface settings one at a time.
If importing one configuration causes an immediate crash, use the backup to identify the subscription or node changed most recently. Exceptionally long node names, damaged JSON, incorrect encoding, and incomplete imports can all trigger parsing problems. When editing JSON manually, use a UTF-8-capable text editor and check the basic syntax first. On a desktop system with Python installed, the following command verifies whether the JSON can be parsed:
python -m json.tool config.jsonThis command checks JSON syntax only; it does not verify that V2Ray fields meet the client’s requirements. After the syntax passes, use the log to check outbound tags, routing references, DNS servers, and protocol fields. Files generated by the client may be overwritten when it exits, so do not edit them directly while the client is running.
Check permissions, file locks, and resource pressure
If the application or configuration directory is not writable, the client may fail to save settings, update subscriptions, or unpack runtime files. Place the application somewhere the current user can read and write normally, rather than running it from a compressed archive preview. Corporate devices, controlled folders, and sync drives may add permissions or file locks; test in a regular user directory. Do not use administrator privileges permanently to hide a directory problem; first determine which files actually need to be written.
Security software may block new processes, restrict local listeners, or quarantine runtime files. Check system records for an explicit blocking event, then handle it according to organizational policy. Blindly disabling all protection cannot provide a reliable diagnosis and may conceal a real port or permission error. If there is no blocking event, continue with port conflicts, configuration parsing, and dependency errors.
When there are many nodes and subscriptions, startup parsing, interface rendering, and latency tests consume more resources. Disable automatic testing, remove duplicate subscriptions, and narrow the filter scope first. If crashes occur only during bulk testing, reduce concurrent tasks. If memory keeps increasing during use, record the triggering action and resource change, then reinstall the current client for your platform over the existing installation. Back up the configuration first; after installation, start with the default configuration and import only what is needed.
chapter eight
Mobile-specific issues: Android background behavior, VPN, and network switching
On Android, v2rayNG and v2flyNG usually capture application traffic through the system VPN interface. Mobile issues can involve battery policies, background restrictions, always-on VPN, Private DNS, and switching between Wi-Fi and mobile data in addition to nodes and subscriptions. Start with the basic network as usual, but also confirm that the system allows the client to keep running in the background and that no other application is using the current VPN interface.
Confirm the system VPN interface and basic network
First stop the client connection and confirm that the browser can access ordinary web pages over the current Wi-Fi or mobile network. Then start v2rayNG or v2flyNG, accept the system VPN connection request, and check for the VPN indicator in the status bar. If the system says another VPN is already running, close other applications that use the VPN interface. Within one Android user space, there is generally one primary VPN interface; multiple applications cannot take control at the same time.
If the connection button says started but no VPN indicator appears, check whether the system revoked authorization or the client reported an error while creating the interface. Open the system VPN settings and review “Always-on VPN” and “Block connections without VPN”. If these options are bound to another application, the current client may not work. If they are bound to the current client but the node is unavailable, blocking direct connections will make the entire network appear down. Temporarily disable enforcement during troubleshooting, then restore it after basic connectivity is confirmed.
Handle background termination and lock-screen disconnects
If the connection works in the foreground but drops after the screen has been locked for several minutes, focus on battery optimization and background-activity restrictions. Add the client to the unrestricted or allowed-background range and permit required foreground-service notifications. Device vendors use different names for these policies, but the diagnostic pattern is consistent: a stable connection with the screen on followed by a vanished process or VPN indicator after locking points more to system reclamation than to a node failure.
Some systems also restrict background data per application. Confirm that the client can use Wi-Fi, mobile data, and background data. If it fails only on mobile data, check whether mobile-data permission is disabled for the app. Data Saver mode may limit background connections; temporarily allow unrestricted access during testing. After changing the setting, swipe the client away from recent tasks and reopen it so the new policy applies to a new process.
Avoid repeatedly changing system state with several “auto-start” or “background protection” tools at once. Adjust only the system battery and data permissions first, then observe for a while. If the issue disappears, restore other restrictions gradually. EOF, network changed, or interface-closed messages in the connection log, combined with the time the VPN indicator disappears, can help distinguish a network switch, system reclamation, and a remote disconnect.
Check Private DNS, per-app proxying, and network switching
Android Private DNS is in the system network settings and is separate from the client’s internal DNS layer. If domains cannot be resolved, temporarily set Private DNS to Automatic, restore the client DNS to default, and reconnect. If the problem disappears, enable the two settings separately to identify the cause. If the Private DNS hostname itself cannot be resolved or reached, the system may encounter the domain failure before the client establishes the VPN.
Per-app proxying controls which applications enter the VPN. If the browser works but the target application does not, confirm that it is included and not excluded. After changing rule modes, some existing connections may continue using the old network; fully close and reopen the target application. System components, download services, and the main app process may use different processes for requests, so selecting only the visible app may not capture all traffic. Temporarily route all applications through the VPN to confirm the cause, then narrow the scope again.
Switching between Wi-Fi and mobile data changes the underlying connection. The client usually needs to rebuild the session, so a brief interruption is part of reconnection. If it does not recover, stop and restart the connection manually. If it fails only on one Wi-Fi network, check its captive-portal authentication, DNS, and routing. If it fails only on mobile data, check the client’s data permission, network type, and target reachability. Do not compare old results from before the switch directly with tests from the new network.
| Mobile symptom | Priority check | Recommended action |
|---|---|---|
| Disconnects after the screen locks | Battery optimization, background restrictions | Allow background and foreground-service operation |
| Cannot create a VPN | Another VPN app, system authorization | Release the interface and authorize again |
| Only some applications fail | Per-app proxy list | Temporarily test with all applications included |
| Does not recover after switching networks | Old session and underlying network changes | Stop and establish the connection again |
| Domain fails while the connection exists | Private DNS and client DNS | Restore a single DNS control point |
If you still cannot identify the cause after this chapter, use troubleshooting to find a short answer by problem category. If you need to reconfigure the client, start over with the quick-start guide, including subscription import, node selection, and connection verification. Do not keep layering unverified changes onto the old configuration.