V2Ray Troubleshooting
Connections, subscriptions and client settings

No internet access: Find where the connection fails

“The client says it’s connected, but webpages won’t load” only means the client is running; it doesn’t confirm a successful connection to the remote server. The full path includes the app, system proxy or virtual network interface, local inbound connection, outbound configuration, remote server and destination website. Identify where the request stops before changing configurations. Choose a destination that reliably reproduces the issue, and have a website that normally opens on your current network as a control.

Disable the proxy and check your basic connection

On desktop, turn off the system proxy and disconnect the client. On Android, disconnect the VPN created by the client. Check that Wi-Fi is connected and the gateway is reachable; complete any captive portal sign-in if needed. If the control website still won't load without the proxy, check network sign-in, device time, router and ISP before blaming the protocol. Captive portals usually need to be completed without a proxy.

If direct access works, start the client again and use only one traffic-routing method for now. Close other proxies, VPNs and network-acceleration tools that may change network settings. On desktop, start by testing the local proxy; enable modes that require extra permissions only after confirming the outbound connection works. This separates a failed remote connection from traffic that never reaches the client.

Check the selected configuration and local listener

In v2rayN, make sure the active server is the one you intend to test; a different row may be highlighted in the list. The active configuration can change after a subscription update, so check the address, port and transport settings before connecting. Then check the logs for a successful local inbound startup. If the port is already in use, find the process using it or change the client port and update the app settings accordingly—restarting repeatedly won't fix the conflict.

Use the local SOCKS port shown by your client. The example below applies only if that port is actually 10808. On Windows, run curl.exe in a terminal; on macOS and Linux, use curl. Specifying the proxy explicitly removes browser system-proxy settings as a variable. Distinguish an HTTP error response from a failed connection.

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

Receiving HTTP response headers means this request reached the local proxy and remote destination, but it doesn't mean every website will work. If the local address is unreachable, check that the client is running and the proxy protocol matches. If the local connection succeeds but the remote request fails, check the outbound logs. Don't enter a SOCKS port in a field that accepts only HTTP proxies; the protocols aren't interchangeable just because the port number is.

Use routing comparisons to see where requests go

If an explicit local-proxy test works but the browser doesn't, check browser proxy extensions, custom DNS settings and cache first. If only some websites fail, briefly switch to a proxy-first routing policy as a comparison, then restore your original settings. “Proxy-first” changes outbound selection; it doesn't automatically route every app through the client. Traffic still depends on the system proxy, app settings or virtual network interface.

If changing the routing policy fixes the issue, check whether the original rules sent the destination directly, matched a blocking outbound or failed to load a rule set. Rules are usually evaluated in order, so a broad rule earlier in the list can override a more specific one. Don't clear all rules: back up the configuration, then test with a single destination domain. Corporate networks, local devices and public websites may need different access paths, so global mode is rarely a lasting fix.

Confirm the fix with a final round of tests

At minimum, retest direct access, access through an explicitly specified proxy and access from your usual app. If the explicit proxy works but the app doesn't, see the system proxy section. If all outbound requests time out, see connection timeouts. If only domain-based requests fail, see the DNS section. Save a working copy of the configuration, remove temporary test rules and restore any features you still need one at a time.

Connection timeouts: Separate connection, handshake and response failures

A timeout tells you that a request didn't finish in time; it doesn't explain why. The same “connection failed” message can mean the remote port is unreachable, a TLS handshake didn't complete, the transport is misconfigured or the destination website is slow to respond. Open the client logs, reproduce the failure once and find the earliest error at that time. Later connection-closed messages are often a consequence, not the root cause.

Use the log sequence to pinpoint the failure stage

A dial tcp error with a timeout usually calls for checking the address, remote port and network reachability. connection refused may mean there's no service on that port or the connection was actively rejected. If the connection reached the TLS stage, check the server name, certificate validation and device time. Logs narrow down the possibilities, but one message alone doesn't prove the remote service is offline; compare results across networks too.

If the client's built-in test fails but a webpage works, check whether the test destination is reachable and whether the test uses the same outbound route. A TCP connection test, proxy handshake and webpage request measure different things, so don't treat their results as interchangeable. Conversely, a basic connectivity test can succeed even when authentication, encryption or application-level access is broken.

Check protocol and transport settings one by one

Compare the configuration with the original information from a trusted source. Check the protocol, address, port, user ID, encryption options and transport type. WebSocket requires the correct path and the Host expected by the server; gRPC requires the right service name. The TLS server name may differ from the connection address, so don't assume they are interchangeable. A website opening at an address doesn't mean its proxy service uses the same endpoint.

For combinations such as VLESS and REALITY, the public key, short ID, server name and flow-control settings must match the server requirements and the client's capabilities. Don't copy parameters into another transport just because the names look similar, and don't expect a different core to fill in missing settings. If a field is missing after importing a subscription, first check that the client supports its format, then ask the configuration provider for the complete details.

An incorrect device clock can cause certificate validation to fail or disrupt some authentication flows. Turn on automatic system time, check the time zone and try again. Don't disable certificate validation permanently to get past an error; that weakens connection security and often hides an incorrect server name. Investigate the setting only in a controlled test, and restore normal validation before using the connection again.

Compare networks and configurations systematically

Keep the same configuration and test it on your current network and another trusted network. Then keep the current network and test a known-working configuration. The first comparison helps identify network-specific issues; the second points to the remote server or a particular configuration. Record any DNS changes, other active VPNs and whether failures occur only over IPv6 so you don't mistake several changes for one result.

When a domain resolves to both IPv4 and IPv6 addresses, a problem with either route can cause delays. Check the logs to see which address the client actually connected to, then compare address families temporarily; don't permanently disable IPv6 system-wide. If the server address is a domain, confirm its resolved address matches what the provider expects. Handle an incorrect resolution as a DNS issue rather than raising every timeout limit.

Check remote availability and avoid excessive retries

If the same configuration fails across multiple independent networks and its settings and validity have been confirmed, the issue is likely with the remote service or your access permissions. Send the first error with sensitive details removed, the time it occurred and results from the network comparisons. Never send the full subscription. Repeated retries won't fix a server-side listener or account restriction and may trigger further limits. While waiting for confirmation, use a verified backup configuration and keep the original for comparison.

Subscription failures: Separate fetching, parsing and using configurations

A subscription update has three separate stages: fetching content from the URL, converting it into client configurations and selecting a configuration to connect. A successful update confirms only that the first two stages completed; it doesn't mean every configuration can connect. A connection failure doesn't mean you need to add the subscription again. First identify whether the client reports a network error, a format error or an empty list, then follow the relevant steps without deleting entries that may still work.

Check the link type and access credentials

An HTTP or HTTPS subscription URL usually returns a set of configurations that can be updated. Links such as vmess:// and vless:// usually describe a single node. Pasting a single-node link into a subscription URL field may cause a fetch error; copying subscription text as an ordinary webpage URL can also drop query parameters. Check the source's instructions and choose the right option, such as “subscription group” or “import from clipboard.”

Check for extra spaces, line breaks, punctuation added by a messaging app or a truncated query string. Treat the access token in a subscription URL like a password: don't paste it into public testing sites or open it on a shared device. If the URL has been exposed, ask the provider to reset its access credentials. Deleting the saved URL from your client doesn't revoke a copy someone else already has.

For the difference between share links and subscription URLs, see Share Links vs. Subscriptions. Importing a single node manually is useful for a quick test, but it won't receive subscription updates. For ongoing use, give groups clear names and keep manually added entries separate from subscription entries so an update doesn't look like an unexpected configuration change.

Find where the subscription fetch fails

Check the update log for HTTP status codes and network errors. For authentication or access errors, verify the account, URL and expiration date. For rate-limit responses, stop refreshing repeatedly and wait. If the server returns success but the content can't be parsed, you may have received a login page, maintenance page or captive portal instead of configuration data. Consider the status code and content type together; don't assume every failure is caused by the client version.

If a direct connection can't fetch the subscription but an existing proxy still works, try updating through that proxy if the client offers the option. If the proxy itself is broken, forcing updates through it creates a dependency: fetching a new configuration requires the old one, which may itself need updating. Confirm which route the update uses. If needed, switch to a working direct connection or use a verified temporary connection.

Check content format and compatibility

If fetching succeeds but importing fails, make sure the subscription contains share links the client can recognize, rather than a format intended for another client. Arbitrary YAML, webpage source and wrapped text aren't universal subscription formats. Supported share-link parameters vary between clients and cores; seeing an entry name doesn't guarantee that all transport settings were imported correctly.

Import one share link from the same source into a separate test group, then check that its address, protocol and transport settings are complete. If the single link works but the full group doesn't, check the subscription content and conversion method. If fields are missing even for one imported link, check format support first. Don't use an unfamiliar online converter for a private subscription; the conversion service will have access to the URL and credentials.

Restore the active configuration after updating

After a subscription update, the previously selected entry may have been renamed, replaced or removed. Recheck the active server and group, reconnect and watch the logs. If an entry worked before the update but fails now, compare its protocol and transport settings—not just its displayed name. Server changes may require fields an older client can't parse. If you need to update the client, choose an installer for your platform in the Downloads section and read the migration notes first.

Once the issue is resolved, keep only the update frequency you need, make sure manual entries won't be overwritten and note which route you used to fetch the subscription. If only a few entries in a group are affected, continue with the connection-timeout section instead of rebuilding the whole group. A useful issue report includes the redacted status code, parsing error and client name—not the full URL, user ID or unredacted subscription content.

Slow speeds: Check DNS, connection setup and data transfer separately

A webpage that takes a long time to appear, a video that buffers and a large download that crawls are usually different problems. The delay may come from DNS or the connection handshake; slow ongoing transfers point more toward throughput, packet loss or server load. Choose a fixed destination and retest with the same app at similar times. Note whether the delay is before the connection starts or continues after it connects. Don't compare results from different sites, files or networks.

Set up a repeatable test

Close bandwidth-heavy background tasks and check that your Wi-Fi signal and local network are stable. Then test with a known-working configuration. If possible, compare a laptop's wired and wireless connections, or a phone's Wi-Fi and mobile data. Change one thing at a time and run the test long enough to reproduce the issue. A client connection test isn't a bandwidth guarantee and can't tell you on its own whether long transfers will stay stable.

If only one website is slow while other destinations work, consider the site's load, content delivery route and account restrictions. A change in proxy exit can make a website choose a different content server, so performance may vary widely between sites with the same configuration. Don't change every local setting because one page is slow. Try another browser or a different resource on the same site to narrow down the issue before changing the outbound route.

Tell a slow first response from a slow transfer

If the first visit is slow but the second is much faster, check the DNS cache, TLS session setup and browser connection reuse. If every request stalls during name resolution, changing routing or transport concurrency may not help. If DNS is fast but the handshake repeatedly fails, revisit the connection-timeout section and check the transport settings. If transfers slow down over time, look at packet loss, remote load and local resource use instead of blindly reducing DNS timeouts.

Use a terminal to see the cumulative time spent at each stage of a request. This example still requires the local SOCKS port to be 10808; it's for observing request stages, not measuring speed. With a proxy, some DNS and handshake timings may include setting up the proxy tunnel. Don't treat a single field as the time taken by remote DNS alone, or use one result to rank configurations.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o /dev/null -sS -w "connect=%{time_connect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" https://example.com/

This command works on macOS and Linux systems that normally include these terminal tools. On Windows, run curl.exe and change the output file to NUL. For a useful comparison, use the same destination and proxy route. A longer wait for the first byte only tells you to investigate the request path further; it doesn't prove that your device, proxy server or destination website is at fault.

Check local resource use and extra processing

Use the system task manager to check CPU, memory and disk usage for the client, core process and other apps. Sustained high usage may come from verbose logging, heavy rule processing or competition from other apps. For troubleshooting, return logging to its normal level, pause unnecessary tasks and test again. Don't disable every system security feature; if there's evidence of a specific block, address that program and message directly.

Multiplexing, concurrent connections and transport settings aren't automatically faster when set higher. They change how connections are reused and may be limited by the server's implementation. If you don't know what the provider requires, start with the defaults. To test a setting, save its original value and change only that one option. If the change causes stalls or disconnects, undo it instead of piling on more “optimizations” and losing a reliable baseline.

Routing, address families and network changes

Incorrect routing may send traffic through a proxy when it could connect directly, or repeatedly retry a connection that should use the proxy. Check which outbound route the destination actually matched, then adjust the rule. Differences between IPv4 and IPv6 paths or an MTU mismatch on a virtual network interface can also make small requests work while larger responses stall. Test these only when the evidence points that way; don't jump from “slow speeds” to changing the system MTU.

If the problem disappears on another network, keep the same configuration and check the original network's Wi-Fi quality, gateway load and access restrictions. If one outbound route is slow across multiple networks, send the provider the destination, time and redacted logs. A fix should mean the same task completes reliably, not just that one test score improves. Restore temporarily disabled features and remove any special routes added for testing.

DNS issues: Check how names are resolved and routed

DNS translates domain names into addresses, but a client can have several ways to resolve them. The system resolver, encrypted DNS in a browser, domains carried by a proxy protocol and lookups made by the core for routing rules may all come into play. One website loading doesn't prove every DNS request follows the intended path. Before troubleshooting, define the goal: fix lookup failures, avoid incorrect addresses or control where a type of request goes.

Confirm that the problem is actually DNS

Check the logs for DNS timeouts, empty results or errors reaching the DNS server. A domain resolving in a system command only shows that the system's resolver works; the proxy core may use a different one. Don't test DNS by opening the bare IP of an HTTPS website: its certificate and server name usually still depend on the domain. Failure to open the IP doesn't prove the address is unreachable.

In an explicit SOCKS test, socks5h usually sends the domain to the proxy for resolution, while a standard SOCKS setup may resolve it locally first. The different results can help identify the lookup path, but check the client's outbound logs too. If the browser uses its own encrypted DNS, system lookup tests may not match what happens in the browser. Note the browser setting before comparing results.

Know what domainStrategy does—and doesn't do

In routing, domainStrategy controls whether names are resolved when matching domain and IP rules. It isn't a switch for routing DNS traffic, nor does it guarantee that DNS requests go through a proxy. The example below is a valid routing-object fragment to illustrate the field; it doesn't define inbounds, outbounds or DNS servers, so it isn't a complete runnable configuration. Don't use it to replace all the settings generated by a graphical client.

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

AsIs generally matches the domain information already available without resolving it for IP rules. IPIfNonMatch attempts a lookup if no domain rule matches, then continues matching; IPOnDemand may resolve a name when an IP rule requires it. Check support in your core. The example also depends on usable geodata and an outbound named direct; field names must match your actual configuration.

So when DNS fails, don't just switch to an option that sounds more aggressive. Check whether a domain rule matches the destination, whether the resolver is reachable and which outbound route its connections use. More lookups can increase delays or change which rule matches. After each change, verify both the resolved address and the actual outbound route; don't rely on a webpage happening to load once.

Avoid dependency loops when setting up DNS servers

With DNS over HTTPS, the service's hostname may itself need to be resolved. If that lookup depends on the proxy, while the proxy server's address depends on the same DNS service, startup can get stuck in a dependency loop. Define the bootstrap lookup path and access rules, then configure bootstrap resolution as supported by your core. Don't point every resolver at the same address without checking that the network can reach the selected service.

Split DNS for domains in mainland China and outside China should keep resolver selection, routing rules and the destination's outbound route aligned. Sending a domain to the wrong resolver may return an unusable address or one that leads to a poor route; sending DNS requests directly when they should use a proxy can also produce unexpected results. For configuration details, see Split DNS Configuration. Understand the dependencies before applying the settings in your client.

Check caches, leak tests and the final result

After changing DNS settings, your browser, operating system or core may still have old results cached. Reconnect the client and close existing tabs, then refresh the cache using your system's supported method. Don't delete the configuration directory just to clear DNS. Local domains may rely on a resolver provided by your workplace or home network; sending everything to a public resolver can restore public websites while breaking access to local resources.

The resolver shown on a DNS test page is only one test result; it doesn't prove that every app follows the same path. A server's location alone doesn't determine whether DNS is leaking. Check browser DNS settings, client logs and results from different apps. For system-level checks, see DNS Leak Testing and Configuration. After making changes, test public domains, local domains and IPv6 separately, and keep a clear record of how each is resolved.

System proxy not working: Check whether the app is actually using it

A system proxy is a set of settings that apps can choose to follow, not a forced tunnel for every system connection. Enabling automatic configuration in v2rayN usually writes the local proxy address to the relevant system setting. The core still needs to be listening, the app must respect the setting, and routing must select the right outbound. Verify with an observable request instead of assuming that “enabled” means traffic is going through the proxy.

Test the local proxy before checking system settings

Run the explicit-proxy command from the no-internet section. If it succeeds, the local inbound and that outbound route are probably working; don't switch nodes yet. Check the system proxy address and port, then see how the app handles proxy settings. Confirm that the host is a local loopback address, the port matches the client's current setting and the app expects the proxy protocol you're using—HTTP and SOCKS settings aren't interchangeable.

If you changed the client port, update the system proxy and any app-specific settings too. Some programs read proxy settings only at startup, so quit them fully and reopen them after a change; closing a window may leave a background process running. First test with a browser profile that has no separate proxy extensions. Once it works, re-enable extensions and individual settings one at a time to find conflicts.

Check where proxy settings come from on each desktop platform

On Windows, the proxy settings in the user interface aren't necessarily used by every background component. If a browser works but a service doesn't, check that program's documentation instead of changing other proxy subsystems system-wide. On macOS, make sure you're changing the active network service; settings for an old connection may not apply after switching. On Linux, desktop proxy settings and terminal environment variables are often separate.

In a terminal, HTTP_PROXY, HTTPS_PROXY, ALL_PROXY and NO_PROXY may override or supplement an app's settings, depending on the tool. Check whether the exclusion list includes the domain you're testing. A one-off command with an explicit proxy is easier to undo than changing global environment variables. Don't edit every shell startup file before verifying the setting works.

System proxy versus virtual network interface routing

Some apps ignore the system proxy or use connection types it doesn't cover. That's when to consider the client's virtual network interface mode—not to assume that switching to global routing has fixed the issue. This mode may require administrator permissions, interface components and correct routes. It can also conflict with other VPNs, virtual machine networks and workplace policies, so first make sure the basic proxy works.

In traffic-capture mode, prevent proxy outbound traffic from being sent back through the proxy, creating a loop. The client usually creates the necessary exclusions and interface rules, but manual gateway or route changes can break them. If all network access stops as soon as you enable the mode, turn it off, restore the original connection and check interface startup and route logs. Don't keep adding static routes at random; they can cause separate network problems after the client exits.

Sharing access with devices on your local network is a separate use case. A loopback address points to the local device; other devices can't use their own loopback address to reach your computer. If you need to share access, set the listening address, device address and firewall scope carefully. Don't expose the proxy port to every reachable network just to make it work. For troubleshooting on this computer alone, keep the listening scope as limited as possible.

Remove stale settings and restore a clear working state

If the client exits unexpectedly, the system may still point to a local port that's no longer listening, leaving you without internet even after closing the app. Turn off the stale proxy in system settings, then restart the client and reapply it. If the setting keeps changing back, check whether another proxy, browser extension or managed policy is writing it. On a managed work device, follow the organization's policy instead of trying to override it.

Test with three apps or methods: one that follows the system proxy, one command that specifies a proxy explicitly and one program with its own proxy settings. Each result should be explained by the corresponding settings—not just the tray icon. For setup steps, see v2rayN First Install and Setup Checklist. Note the working port so an app integration issue isn't mistaken for a failed node after a configuration change.

Client crashes: Separate the interface, core and configuration

A client that exits at startup, a frozen window and a core that stops after connecting can involve different processes and logs. First check whether the interface is still open, whether a tray process is running and whether the error occurs when opening the app, reading the configuration or starting a connection. Don't immediately delete the data directory or reinstall over the existing files; you could lose a working configuration and evidence of the issue. Back up first, then create a minimal way to reproduce the problem.

Check the installer and runtime environment

For desktop, v2rayN is the recommended choice. Use the Downloads section to check the platform and processor architecture. The Windows desktop edition and classic WPF edition are separate interfaces; don't mix their data files just because one has a problem. For macOS, choose Apple Silicon or Intel; for Linux, match both the architecture and the distribution's package format. Being able to extract a package doesn't guarantee the system can run its programs.

If the system reports a missing runtime component, install what's required according to the current setup instructions. Don't download a supposed repair tool from an unknown pop-up. On macOS, verify the file source and use the system's security settings to address source or permission warnings; don't routinely disable protections system-wide. On Linux, use package manager dependency information to troubleshoot rather than treating every startup issue as a file-permission problem.

If you run the client from an extracted archive, extract all files to a fixed directory that the current user can write to. Don't launch it from the archive preview. Sync tools, controlled folders or other processes may prevent the client from saving settings. Test from a local directory with clear permissions, then check the security software's specific logs. If a file is quarantined, verify what it is; don't disable all protection to bypass an unexplained warning.

Tell an interface problem from a core crash

If the interface works but the connection stops immediately, check the first startup error in the core log. Common causes include a port conflict, a field unsupported by the current core, a missing referenced file or failed geodata loading. If the log reports a configuration parsing error, changing the system proxy won't help—the inbound connection may never have started. Undo recently changed fields and test with a configuration that worked before.

If the interface itself won't open, check system event records or client startup logs for issues reading a data file, restoring window state or writing to a directory. Keep the original data directory and start a minimal environment from a separate test directory. If the clean environment runs, the issue is more likely related to old data or settings; it doesn't prove that every existing configuration is corrupted.

Narrow down configuration problems safely

Close the client and confirm that its background process has exited. Then copy the configuration, subscription records and relevant logs to a secure backup location. In the test environment, import one verified configuration without complex custom routing or external rules. If it runs reliably, restore subscriptions, routing and other settings in stages until the problem returns. This isolates the trigger instead of rebuilding everything without knowing what went wrong.

Choose a core based on configuration support. Xray and V2Fly are different core implementations; don't assume they support every field in the same way. A transport or security setting may need different handling in another core. If switching cores immediately produces an unsupported-field error, return to the original core or rebuild the configuration to match the new core's capabilities. The same option label in a graphical interface doesn't prove full compatibility.

Check for resource exhaustion and migration issues

If the client crashes only after running for a while, check memory use, disk space and log growth—not just startup settings. A full disk can prevent configurations from being saved, and verbose logging can quickly use up storage. If the problem is linked to a large import or a particular rule, test with a reduced set and keep the smallest sample that reproduces the issue. Logs may contain addresses and user IDs; remove each sensitive detail before sharing them.

If a problem starts after an update, save a backup of the old data and the migration error. Don't overwrite data between different programs or formats. To roll back, use a backup made for the original environment; an older program may not be able to read migrated data. After fixing the issue, test a full cycle: launch, import, connect, exit and launch again. Confirm the client can save settings and resume normal use, not just open once.

Mobile troubleshooting: VPN permissions, per-app routing and background use

On Android, use v2rayNG by default; consider v2flyNG when you need the V2Fly core. Similar-looking interfaces don't mean the clients share the same settings or core capabilities. Mobile troubleshooting also involves system VPN permission, per-app rules, background restrictions and network changes—not just the remote connection. Start by keeping the app in the foreground with the screen on and verifying a connection. Then check for disconnects after the screen locks; this reduces the number of variables.

Check the install package and VPN permission

If installation fails, check the device architecture, system requirements, storage space and conflicts with existing apps. Most recent phones use arm64; if you can't confirm the architecture, consider a universal package. Package types don't imply different account permissions. If the system reports a signature conflict, don't uninstall the old app immediately: export any needed settings and confirm the backup works, since uninstalling usually removes private app data. Find all options on the Android downloads page.

The first connection usually requires system VPN permission. If you previously denied the prompt, connect again in the client and complete the permission flow. Devices managed with a work profile or organization policy may have additional restrictions. Android generally allows only one active VPN service per user profile. Other VPNs, some local filtering apps or network-acceleration tools may already be using it, so check which service is active before connecting.

A VPN icon in the status bar means the service is running; it doesn't confirm that the remote proxy handshake succeeded. Check the client log and try loading a webpage. If Always-on VPN or Block connections without VPN is enabled, stopping the client may prevent direct access to the internet. That's the effect of a system policy, not necessarily a network outage. Check these settings before troubleshooting the basic connection.

Per-app rules and app-specific failures

If only one app can't connect, check whether it's included in the per-app rules. Depending on the client, the app list may mean “proxy only selected apps” or “bypass selected apps”; the same checkbox can have opposite effects. Confirm the current mode and its description, reconnect after making a change, and fully close and reopen the app. An app appearing in the list doesn't prove it uses the proxy—verify with results and logs.

Some apps use their own DNS, persistent connections or specialized transports, so they may behave differently from a browser. Compare other apps on the same network, then check whether the relevant outbound supports traffic such as UDP. Don't clear all app data just because a browser works; you could lose sign-in sessions and local files. Reconnect first, check the app's network permissions and clear its cache only when there's a specific reason.

Connection drops when the screen locks

If the connection works in the foreground but fails after the screen locks, check battery optimization, background activity permissions and the device manufacturer's power-saving settings. Allow the client to run in the background if needed, then test again with the screen locked. Don't remove restrictions from every app; adjust only the client and monitor battery use and stability. Some devices also have separate auto-start or background task controls. Names vary, but the goal is to prevent the VPN service from being stopped unexpectedly.

Distinguish a stopped service from a running connection that can't carry traffic. If the service stopped, the VPN icon may disappear or the process may restart. If it's still running, check logs for reconnections, DNS errors or remote timeouts. System memory pressure can also end a process, especially when many apps are open. Record when the issue occurs and the system state, then test with fewer background apps; this is more useful than repeatedly changing nodes.

Reconnect after network changes and document the issue

After switching between Wi-Fi and mobile data, the existing connection or DNS cache may stop working temporarily. Wait for the client to reconnect before making a new request. If it still fails, disconnect and reconnect once, then check whether it uses the new network path. If only one Wi-Fi network fails, check captive portal sign-in and access restrictions. If only mobile data fails, compare address family, DNS and server reachability instead of copying every desktop setting.

If small pages load but larger responses stall, investigate the route and MTU while keeping the default values and recording the conditions that reproduce the issue. Arbitrarily lowering a setting may hide the problem temporarily or add overhead. When transferring a configuration between devices, import it manually and check protocol support, routing, ports and platform differences one by one. Don't copy desktop file paths, system proxy settings or permission choices directly to a phone.

A useful issue report includes the client name, device and OS, network, foreground or screen-locked state, per-app mode and the first error with sensitive details removed. For connection issues, see connection timeouts; for name-resolution problems, see DNS issues. To rebuild your setup from a clear baseline, return to Getting Started. After a fix, verify foreground access, recovery after locking the screen and reconnection after a network change before restoring your usual settings.