Troubleshooting / Find an issue by symptom

V2Ray Troubleshooting Guide

Connections, subscriptions, DNS, and proxy settings: identify where the failure occurs before changing the relevant settings.

This is a reference guide, not a start-to-finish tutorial. For a first-time install and import, follow the Getting Started Guide. If setup is complete but the results aren't what you expected, jump to the section that matches your symptoms. Desktop instructions focus on v2rayN; Android sections cover v2rayNG and v2flyNG. Menu names may vary slightly between versions, so use the function and actual listening address as your guide.

Troubleshooting notes · Change one thing at a time

Keep a record of: when the issue occurred, network type, client in use, proxy mode, affected app, and relevant error logs from the same time. Save a screenshot of the original settings, then run a repeatable test.

Capture only the log lines around the failure. Before sharing, remove subscription and server addresses, user IDs, passwords, and connection links. Never post a complete configuration file.

No internet: distinguish the local proxy from the remote connection

“Started” only means the client attempted to run. It doesn't mean browser traffic reached the proxy or that the remote server connected successfully. First pin down what failed: all apps or just one browser? Every site or only certain destinations? Does your regular connection work with the proxy off? This divides the problem into four stages—basic network access, local listening, app traffic routing, and remote connections—so you don't start by replacing every server.

Test your connection without the proxy

In v2rayN, clear the system proxy and make sure TUN is off. Then try a site you can normally access directly. If it still fails, check whether the Wi-Fi network requires sign-in, whether the system clock is correct, and whether your network adapter has an IP address. Public Wi-Fi sign-in pages usually need a direct connection. Testing servers before signing in will only produce unhelpful timeouts. Don't treat a basic network issue as a subscription problem.

Once direct access works, restore a known-good configuration and use just one connection method for now. On desktop, start with the system proxy; leave TUN off and close any other proxy apps. Check the local listening port under “Settings,” then confirm in the runtime log that the core started. If the port shown in the interface differs from the log, use the actual listening address from the successful startup. Ports aren't fixed; if you change one, update any apps where you've configured a proxy manually.

Use an explicit proxy request to isolate the connection

This Windows command explicitly specifies an HTTP proxy, making it useful for checking whether an app is bypassing the system proxy. The example assumes the current HTTP or mixed listener uses port 10808; replace it if your settings differ. This won't work with a SOCKS-only listener. Choose an HTTPS test site that is accessible on your current network and responds reliably.

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

If the command can't connect to the local proxy, check whether the core started, the port is correct, and another process is already using it. If the local connection succeeds but the remote connection or TLS handshake fails, continue to the next section. If the explicit proxy request works but the browser doesn't, check the browser's own proxy settings, extensions, and cached settings before changing the server configuration. This test is more reliable than checking the tray icon because it actually sends a request through the local listener.

Check whether routing is sending traffic to the wrong outbound

Open “Routing settings” and confirm that the selected ruleset matches your expectations. If a rule sends a destination direct, it can fail in exactly the same way as a proxy connection—even when the server is healthy. Temporarily try a test setup with fewer rules just to see whether the destination works through the proxy, then restore your original routing. Don't leave proxy coverage expanded to hide a rule problem; that makes it harder to tell which rule is responsible.

If only one app fails, check whether it uses HTTP, SOCKS, or its own connection method. The system proxy doesn't automatically cover every program or guarantee that all UDP traffic is handled. First see whether the app lets you enter a proxy explicitly; consider TUN only if needed. If the problem occurs only with TUN enabled, note changes to the virtual adapter, permissions, and routes, then review the TUN mode guide. Don't change DNS and servers at the same time.

Summarize the result in a reproducible sentence, such as “Direct connection works, explicit HTTP proxy works, browser fails.” That narrows the issue to the app's proxy settings. If “direct connection works, the local port accepts connections, but all remote requests fail,” check the server and transport settings next. Once service is restored, save the working configuration and remove temporary test rules so the problem setup isn't selected on the next launch.

Connection timeouts: distinguish port, handshake, and destination failures

A timeout means the expected response didn't arrive in time, but it doesn't tell you where the delay occurred. Connecting to the server port, negotiating encrypted transport, authenticating, and connecting to the destination from the server can all time out independently. Find the first relevant error for the current request in the runtime log, rather than focusing only on the final “failed” line. Note whether a connection was established before the error and whether the issue occurs only for a particular destination or network.

First check that the server endpoint is reachable

Open the settings for the current server and compare its address and port with the details from your provider. When copying an address, remove any leading or trailing spaces. Don't paste a full web URL into the server address field or use a subscription URL as a server address. Enter the hostname and port in their respective fields. If subscription details have changed recently, update the group and select a valid entry again; manual changes to an old entry may not survive the next update.

On Windows, use this command to test the server's TCP endpoint. The example hostname is for syntax only; replace it with the actual address and port of your current server. Don't share the command with your substituted details. A failed test means your computer couldn't establish a connection to that TCP endpoint. A successful test confirms only that the port is reachable—not that the protocol, user ID, or transport settings are correct. This is not a complete test for configurations using other transport methods.

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

If multiple servers fail only on the same network, retest the same configuration on another trusted network. Don't change the network and server at the same time, or you won't know which variable mattered. If one server fails on every network while others work, ask your provider to check its endpoint. Repeating tests at shorter intervals won't make a timeout more informative and may trigger connection limits. Wait a reasonable amount of time, then test once more.

If the port is reachable, check transport and security settings

If the TCP endpoint works but the log shows a handshake error, check the protocol, transport, TLS settings, and server name one by one. The WebSocket path and Host, gRPC service name, and REALITY public key and short ID must match the server. The same port doesn't mean settings are interchangeable. Path capitalization and leading slashes can matter too. If possible, reimport the complete connection details instead of guessing at missing fields.

An incorrect device clock can also affect certificate validity checks and some authentication flows. Enable automatic time synchronization, then check the log for certificate names, validity dates, and trust-chain errors. Don't use “skip certificate verification” as a routine fix: it bypasses checks that should catch problems and won't correct a misconfigured server name. If the server certificate is invalid, its maintainer must fix it; the client needs the correct connection settings.

Use error messages to guide troubleshooting

Log clue	What it may mean	Check first
`connection refused`	Connection actively refused	Destination port, listening service, firewall rules
`i/o timeout`	Read or write operation timed out	Address in the error, stage where it occurred, current network
`certificate`	Certificate validation failed	System clock, server name, certificate chain
`EOF`	Remote end closed the connection early	Transport type, authentication, server logs

These terms don't point to a single cause. A read or write timeout may occur on the destination side; an early disconnect may come from an intermediate network device. Check the surrounding log lines and compare test results. If the server connection succeeds but only one site fails, check that site's routing and access from the server. Don't assume the whole server is down based on one destination error.

Latency checks in the client list may use a different destination and connection method from a real request. If a port test succeeds but a real connection fails, check what happens after the protocol handshake. See node latency and download speed tests for details. When reporting the issue to a maintainer, include the time, protocol type, failure stage, and network comparisons you've made—but not your full credentials. This makes it easier to get a useful answer.

Subscription failures: check the request, parsing, and group display separately

A subscription update has three distinct steps: the client downloads the URL contents, parses them into server entries, and adds them to a subscription group. If the interface says “failed,” first find out which step failed. Request failures often involve the network, URL, or certificate; parsing failures often mean the response was a web page or an unsupported format; a successful update with no visible entries may simply mean the wrong group is selected. Clicking Update repeatedly usually won't change any of these conditions.

Check the URL and network used for the update

In v2rayN, open “Subscription group settings,” edit the group, and check that the full URL was saved. Subscription links may contain access credentials; copy the complete URL from a trusted source. Don't assemble it by hand or show it in a public screenshot. Line breaks inserted by chat apps, a Chinese punctuation mark copied at the end, or expired access parameters can all make the client request a subtly different URL. Save your changes before updating the group.

Check whether the update is set to use the proxy or connect directly, or look for the equivalent option in your version. If the current servers are down and subscription updates are configured to use those same servers, you can end up in a recovery loop. First test whether the subscription URL can be reached directly. If your provider requires a working proxy, keep one known-good connection available for updates; clearing the server list won't solve the problem.

Opening a subscription URL in a browser doesn't prove that the client can read it. The browser may use another proxy, retain a login session, or pass a web-based verification step. Check the response status in the client log: unauthorized or forbidden responses usually require checking your account and URL permissions; a not-found response calls for checking the URL; for a server error, try again later and contact the provider. Don't assume all such responses are caused by the client core.

If the request succeeds, check whether the response can be parsed

A successful network response can still be a login page, notice, or network sign-in page—not server data. If the log says there are no valid servers, parsing failed, or the format is unsupported, ask the subscription provider which GUI clients the URL supports. A web page explaining a subscription is not the same as an endpoint that returns subscription data. Likewise, some specialized configuration formats can't be imported as a general-purpose server list.

Don't paste a full subscription into an online conversion site to troubleshoot it; it may contain all your access credentials. First check the response type locally. If needed, tell the maintainer only that the response is a web page or an unrecognized configuration format. If you also have a single connection link, test it with the client's clipboard import. If that works but the subscription doesn't, focus on how the subscription is fetched and parsed instead of rechecking every network setting.

Update succeeds, but the list is empty or has duplicate entries

Return to the server list and check the selected subscription group, search box, and filters. Updating another group won't necessarily show its contents in the current view; an old search filter may still be active. Confirm that the group contains the URL you just edited, not a similarly named entry. If you've created multiple groups for the same URL, compare them before deleting duplicates so you don't remove the only working source by mistake.

After an update changes server names or order, the previously selected entry may have been replaced. Select a valid entry again and test the connection. Subscription updates can also overwrite manually changed server settings, so keep custom changes in a separate group and note their source. If an automatic update caused the problem, the update time and entry changes are more useful for troubleshooting than simply saying “it stopped working after an update.”

If automatic updates fail but manual updates work, check sleep settings, startup order, and the network available at update time. The client may start before the network is ready or request an update before the proxy core has finished starting. First confirm that a manual update works, then adjust the schedule. On Android, background restrictions may also matter; see the final section of this guide.

For a first-time setup, review the subscription import steps. For general questions, see the FAQ. When reporting a subscription issue, share only the status code, error type, and steps taken in the group settings. Hide the full URL and access parameters. After a fix, verify one update, one server selection, and one real request; all three need to work to confirm the issue is resolved.

Slow speeds: separate latency, throughput, and app delays

“Slow” can describe at least three things: a long wait before a page starts loading, a low transfer rate once data starts moving, or periodic interruptions during calls or playback. The first often involves DNS or connection setup; the second is more about available bandwidth and congestion; the third may point to jitter, packet loss, or app traffic that isn't being routed correctly. Identify which one you're experiencing before testing. Ranking servers by a single latency number can easily steer you to one that's a poor fit for your task.

Make your tests comparable

Use the same device, destination, and proxy mode for each test, and temporarily stop other bandwidth-heavy tasks. Test one server, then switch only the server and test again; don't also change routing or DNS. Large downloads consume real traffic and can affect other users, so there's no need to run them repeatedly for a long time. Compare connection setup time and sustained transfer speed. A page that loads instantly from the browser cache doesn't prove the remote connection is faster.

First check your local Wi-Fi quality and device load. Distance from the access point, a crowded wireless band, or active file syncing can slow every connection. Compare against a service you can access directly on the same network. If direct access is also slow, address the underlying network first. If possible, test once over Ethernet to rule out Wi-Fi; this is a diagnostic comparison, not a requirement for everyday use.

Low latency doesn't guarantee fast downloads

A port connectivity test mainly reflects the time needed to establish a connection. A real connection test also depends on the proxy handshake and test destination, while a download speed test is more likely to reveal bandwidth and congestion. These measure different things, so their results won't necessarily match. A remote route can have higher latency but steady throughput, or connect quickly and slow down during peak hours. For calls and interactive apps, prioritize stability; for sustained downloads, also check transfer performance.

If one server is slow only for a particular site, check the destination, content delivery route, and routing rule that matched. The route from the server to the destination is different from the route between your device and the server. Try another reliable destination or use a different server to reach the same one. Don't reset all your settings based on a single site's response. For more on what these tests measure, see the differences between TCPing, real connection tests, and download speed tests.

Check proxy mode, routing, and resource usage

Check the runtime log to confirm that slow requests use the expected outbound route. A broad rule may send a destination along an unsuitable path, or the browser may use the proxy while its download component connects separately. App updaters, media components, and command-line tools don't always follow the same system proxy settings. First configure a supported proxy directly in the app. Test TUN only if you need traffic interception; expanding interception isn't a general-purpose speed boost.

On desktop, multiple proxy layers, virtual networking, and security scans can add overhead. Temporarily disable duplicate components one at a time to compare results, but don't turn off all system protection. Check CPU and memory use for the client and core. If the processor stays busy during requests, look for repeated connections or excessive logging. When testing is complete, return to the normal log level; detailed connection logs can consume disk space and expose private information.

Consider path MTU or fragmentation only if large requests stall while small ones work, and only on a particular network. First compare system proxy and TUN behavior and confirm you can reproduce the issue, then make a small adjustment supported by the client. An arbitrarily low MTU can reduce efficiency and hide other problems. Don't copy a supposedly universal setting. Record the original value and restore it if the change doesn't help.

Finally, check whether DNS delays are being mistaken for low speed. If the first visit is slow but later requests work normally, focus on DNS resolution and connection setup. If the entire download is slow, look at congestion and route stability. Keep the results of tests run under the same conditions; there's no need to reveal server details. Once things work again, undo temporary changes one by one and keep only settings that have been shown to help. This avoids accumulating unexplained “optimizations.”

DNS issues: find out where names are resolved and which route queries take

DNS problems can make domains fail to load, delay the first visit, or produce different results across apps. Don't replace every DNS address as soon as a browser shows a resolution error. A request may use the operating system cache, the browser's secure DNS, proxy core resolution, or remote server resolution. First find out which layer is handling the request, then decide what to change. Otherwise, the app may not use your new setting at all.

System DNS results don't show the whole proxy connection

First identify the domain named in the error log. It might be the destination website, the server address, or the DNS service itself. If the server uses a hostname, the core must resolve it before connecting to the proxy; a failure at this step can affect every proxy request. A destination lookup failure may affect only some sites, so the troubleshooting order is different. Note what role the domain plays without sharing its actual address.

On Windows, use the following command to check the system's current DNS result. This can show whether system DNS responds and whether it used the expected server, but it can't prove that the browser or proxy core uses the same result. Even if the command returns an address, a failure to connect may involve routing, the destination port, or the transport handshake. Don't attribute every error to DNS.

Resolve-DnsName example.com

To test remote DNS resolution, use SOCKS domain forwarding so the proxy receives the hostname instead of an address resolved locally first. The example assumes the current SOCKS or mixed listener uses port 10808. If the listener supports HTTP only, use a test method appropriate for that listener; a protocol mismatch isn't evidence of a DNS failure.

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

Encrypted DNS still needs a working connection

With DNS over HTTPS, the DNS service itself needs to be reachable, and its hostname may need an initial lookup. Forcing the DNS connection through a proxy that hasn't come up yet can create a dependency loop: the proxy needs to resolve its server, while DNS needs the proxy to connect. First ensure the server hostname can be resolved and there's a working route to the DNS service, then add routing rules. Don't layer several mutually dependent DNS endpoints at once.

In v2rayN, check the DNS settings for the core currently in use and distinguish between regular proxy and TUN mode. DNS fields aren't necessarily compatible across cores; don't paste a DNS section from one configuration into another core. Prefer the settings provided by the interface and confirm that the core reloads after saving. If you edited a configuration file that isn't selected, the interface may show your changes while the active setup still uses the old settings.

Check DNS resolution and routing rules together

Domain rules rely on the request retaining its hostname; IP rules rely on the destination address and the relevant data files. A browser may resolve a domain before connecting, an app may send only an IP, or traffic inspection may not recover the hostname. Any of these can prevent a domain rule from matching. Sniffing can identify destinations for some connections, but it doesn't cover every protocol and isn't a substitute for DNS. Check what information the request contains and which rule matched before assuming the rule syntax is wrong.

This Xray-style routing snippet illustrates domain and IP conditions; it isn't a complete client configuration. It requires working geosite and geoip data and a defined direct outbound. The conditions are on separate rules so you can more easily see how matching works. Don't replace your entire configuration with this snippet. In a graphical client, create the equivalent rules using its routing editor.

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

Missing data files, misspelled tags, and rule order can all lead to unexpected outbound routes. For a more complete rule sequence, see the geosite and geoip routing guide. When troubleshooting, change only the rules related to the destination. Don't delete the entire routing setup for one DNS issue; keep a copy of the original configuration so you can restore it after testing.

After changing settings, close old browser tabs or restart the affected app, then clear the system DNS cache if needed. Clearing the cache makes new requests look up names again; it won't fix an incorrect server address or a dependency loop. If only the browser is affected, check whether its secure DNS bypasses system settings. If the issue occurs only in TUN mode, check DNS routing through the virtual network. Finally, test both a regular domain and the server's domain to confirm that basic connectivity and destination access are back.

System proxy not working: check whether the app reaches the local listener

The system proxy is a set of network settings that apps can read; it doesn't force all system traffic through a proxy. If v2rayN has enabled the system proxy but an app still connects directly, the app may ignore system settings, or another proxy, environment variable, or program may be overriding them. First test the core with an explicit proxy request, then check whether the system settings were applied, and finally inspect the affected app. This order helps distinguish an app routing issue from a server failure.

Match the actual port and listening address

Under “Settings,” check the local listening address and HTTP or mixed port, then confirm the runtime log shows no startup errors. The address configured in the system proxy should point to this listener. On a single device, it usually points to the loopback address. “Allow connections from LAN” controls whether other devices can use this listener; it's not required for proxying apps on the same computer. Don't widen the listening address just to make a browser work, especially on public networks.

If you changed the port, clear the old system proxy first, apply the current settings again, then close and reopen the affected app. Some programs read proxy settings only at startup, and existing connections may keep using the old route. Use Task Manager to confirm the program has fully exited, not just closed its window. If an explicit request to the new port works but the system proxy doesn't, check for leftover settings or app-specific policies instead of changing the server again.

Check where the setting takes effect on each platform

Platform	Where to check	Commonly missed details
Windows	Settings → Network & Internet → Proxy	Apps may use their own settings or a separate network interface
macOS	System Settings → Network → Current network service → Details → Proxies	Settings apply to the currently selected network service
Linux	Network proxy settings for the current desktop environment	Desktop settings and terminal environment variables may be independent

Windows user proxy settings may differ from those used by some system services. So a browser working while a background service fails doesn't necessarily mean the client is broken. Don't change global network settings just for one service; first check whether the app has its own proxy option. On macOS, after switching network services, check the service currently in use rather than the one selected before.

On Linux, graphical apps, desktop sessions, and terminal processes may read different settings. HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY in the terminal environment may also contain outdated addresses; how uppercase and lowercase variables are handled depends on the app. First test with an explicit proxy option, then check the environment inherited by the running process. After cleaning it up, restart the terminal. Don't point all variables at different protocol ports, or it'll be harder to tell which setting the app actually uses.

Check for overrides and proxy loops

Browser proxy extensions, another proxy client, and network management tools can keep rewriting the system proxy. Close duplicate tools and see whether the address still changes automatically. Let just one program manage the system proxy to prevent processes from overwriting each other's settings. If the network still fails after the client exits, check whether the core is still running in the background, then use “Clear system proxy.” If the client won't start, remove settings pointing to a dead local port in the system network settings.

A proxy loop is a separate issue: app requests enter the proxy, then the core's outbound traffic gets sent back to the local listener, causing repeated connections or sustained resource use. Pay particular attention to routing exclusions when enabling TUN alongside other system-level proxy tools. First return to a minimal setup with only the system proxy. Once it works, re-enable traffic interception one feature at a time. Changing ports repeatedly won't fix a loop because the routing cycle is unchanged.

If an app clearly uses its own network stack, follow its instructions to enter an HTTP or SOCKS proxy. The two address formats aren't interchangeable. Some real-time features also use UDP, so a working webpage doesn't mean voice traffic is covered. When testing, check both the app and the client log for its requests. If the log shows no request, that's an important clue: look at traffic routing, not the server.

Once things work again, note which setting handles each app and remove obsolete configuration. To choose a mode for the first time, return to the Getting Started Guide; for routing, see the routing setup steps. Keep an explicit proxy test command as a baseline. After an OS update or network change, it can quickly show whether a new problem is in the app or connection layer.

Client crashes: distinguish the interface from a core failure

“Won't open” can mean two different things: the graphical interface won't run, or it opens but the proxy core exits immediately. The first points more toward program files, the runtime environment, user data, or permissions; the second usually leaves clues in the core error log about configuration, ports, or file paths. Don't delete the entire user directory as soon as startup fails. It may contain subscriptions, routes, and local settings. Back it up before isolating the issue.

Preserve the evidence and narrow down the startup failure

Note exactly what happens after you double-click: no window, a window that closes, a process that stays in the background, or an error in the interface saying the core failed to run. Check Task Manager or Activity Monitor to see whether another instance is already running. An old process may still hold files or ports, and starting the app again can cause new errors. Exit the old process normally before trying again. Don't end a similarly named system service unless you know what it does.

If the interface won't open, check the app's log directory or system application error reports. Look first for unreadable files, missing dependencies, and permission errors. Running from a restricted directory or temporary archive location, or failing to extract files completely, can prevent startup. Choose the package for your platform and processor architecture from the download center, then install or extract it properly and run it from a permanent folder. Don't mix program files from different release packages.

If the core fails to start, read the first error

If the interface opens but the core exits, open the runtime log and find the first error with a specific field or address after startup. Later messages such as “process exited” or “connection failed” are usually just consequences. For a port conflict, identify the exact listening address and port; for a configuration error, find the relevant field; for a missing data file, check its path. See how to troubleshoot Xray core startup failures rather than reinstalling based on the final message alone.

On Windows, use the following command to check whether an example port is in use. Replace it with the port shown in the log, then use the process ID in Task Manager to identify the program. If another process has the port, close the duplicate client or choose an unused port for the current client, then update the system proxy and any apps with manual proxy settings. Don't terminate an unknown process or mistake app connection failures after a port change for a new server issue.

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

If the client won't start after you edited JSON by hand, check for extra commas, missing quotes, mismatched brackets, and incorrect field types. Valid syntax doesn't guarantee a usable configuration: a field may not exist in the current core, an outbound tag may be undefined, or a referenced data file may be missing. Prefer making changes in the graphical interface and using the client's built-in validation. Don't replace a complete configuration with a standalone snippet from the web, especially if it's for a different core.

Isolate user settings with a separate data directory

If the program runs but crashes as soon as it loads the existing user data, back up the data and use the client's supported separate-directory or configuration-isolation feature to create a clean test environment. Rename the original folder to keep it safe; don't delete it. If the clean setup works, restore subscriptions, servers, and routes in batches, testing startup after each batch. This helps identify corrupt data or incompatible settings without copying the whole problem back in.

If the issue appeared after an update, first check whether old and new program files are mixed in the same folder and where the system shortcut actually points. The desktop and WPF editions have different interfaces and runtime dependencies; don't switch between them by swapping executable files. Make sure the processor architecture matches your device. Only install missing runtime dependencies if the log clearly identifies them, and follow the release instructions. Avoid so-called repair packages from unknown sources.

If security software quarantined a program file, check its source and the detection record first, then use the system's restore and exception features as appropriate. Don't disable all protection. When contacting support, include your OS, processor architecture, release package type, and the first error; don't upload your entire user directory. For more log terms, see how to read runtime logs. Finally, verify that the interface starts, the core runs, and a real proxy request succeeds. Fixing the window alone may leave the connection broken.

Android issues: VPN permission, per-app routing, and background activity

On Android, use v2rayNG by default; for configurations using the V2Fly core, choose v2flyNG. Their interfaces and core options aren't identical, so first confirm which app is running instead of looking for the other app's menu labels. See Android client downloads. Before troubleshooting, keep your subscription details and note whether the issue starts as soon as you tap Connect or only after locking the screen, switching networks, or opening a particular app.

Check VPN permission and traffic routing

The first time you connect, Android usually prompts you to allow a VPN connection. The client can route app traffic only after you grant permission and it creates a local VPN interface successfully. A VPN icon in the status bar confirms that the interface exists, not that the remote server is reachable; open a destination to test the connection. If the permission prompt doesn't appear or disappears immediately, check existing VPN settings and device management policies in Android settings.

In most user environments, only one network tool that uses a VPN interface can be active at a time. Another VPN, LAN tool, or filtering app that uses a local VPN may replace the current connection. Disconnect them all and test with only one client running. If Android is set to always-on VPN or to block connections outside the VPN, confirm that the selected app is the client you're using. The wrong combination can block all access when the connection drops.

Check whether per-app rules are reversed

Open the client's per-app or app proxy settings and check whether the list means “proxy only selected apps” or “bypass selected apps.” These do opposite things, so the number of checked apps isn't enough to tell. If the browser works but another app doesn't, check whether that app is actually covered. A newly installed app may not yet be in the list. After changing the selection, disconnect and reconnect so Android applies the VPN routes and app scope again.

Treat the local listener and Android VPN mode as separate options. Enabling a local proxy service alone may not make ordinary Android apps use it automatically. Conversely, if VPN routing is working, you don't need to enter a local proxy separately in every app. Manually setting a proxy for the Wi-Fi network as well can create duplicate routes. First return to the client's default VPN mode, remove unnecessary manual proxy settings, and test the server again.

Troubleshoot disconnects after screen lock or network changes

If the connection works in the foreground but drops after the screen has been locked for a while, check Android's battery restrictions for the client. Allow the background activity it needs, remove excessive battery-saving restrictions for that app, and keep its connection notification enabled. Menu names vary by device; look under the app's battery, background activity, and network permissions. Don't loosen background restrictions for every app—change only the client responsible for the connection.

After switching between Wi-Fi and mobile data, an existing connection may still refer to the old network. Disconnect and reconnect, then check whether access returns. If every network switch reproduces the issue, note the network type and logs before and after. Public Wi-Fi may also require completing a browser sign-in first. Data Saver, roaming restrictions, and permissions that limit an app to certain network types can make it appear to work at home but fail elsewhere. Check these separately from server issues.

If domain resolution fails only on a particular network, check Android Private DNS and the client's own DNS settings. They may use different routes; disabling one doesn't automatically enable the other. Record the original settings, temporarily use the system's automatic option for comparison, then follow the DNS section in this guide to check the server and destination hostnames. Don't keep adding DNS addresses if you can't explain the results; that makes the failure harder to reproduce.

Distinguish web, real-time, and background subscription issues

If webpages work but voice, games, or other real-time features fail, the cause may involve UDP, per-app routing, or server support. First confirm that the app's traffic is being routed, then check the protocol and capabilities supported by your provider. A working webpage doesn't prove that every type of traffic will work. If only one app has a problem, try its built-in network diagnostics. Don't reset all routing and DNS settings for a single feature.

If a subscription updates manually in the foreground but fails in the background, check background network restrictions and update timing before deleting it. If Android says a package isn't compatible, check your device architecture and choose arm64 or universal on the download page. Don't confuse installation compatibility with connection problems. Before switching clients, confirm that your protocol and configuration are compatible with the target core. See the client comparison for how the three apps differ.

If you still can't identify the cause, record when things work, when they fail, and whether reconnecting fixes the issue. Add relevant error logs with sensitive details removed. Look up unfamiliar terms in the glossary or return to the Getting Started Guide for basic setup steps. Clear reproduction steps are more useful than repeated reinstalls and let you start future troubleshooting from a branch you've already tested.