V2Ray Troubleshooting
Connections, subscriptions, and system proxy

No internet access: identify where the connection breaks

If no websites load, don't delete your configuration yet. A connection typically passes through the app, traffic-routing entry point, local core, remote server, and destination site. A running status only shows that the client started; it doesn't prove every link is working. Quit other proxy tools, temporarily turn off TUN, and set the system proxy to “Clear system proxy.” Try a site that normally works directly to confirm that your basic network, Wi-Fi sign-in, and default gateway are working.

Restore direct access, then check the local listener

If direct access still fails after clearing the proxy, check whether the network requires a sign-in page, whether the system clock is correct, and whether other devices work on the same network. Switching servers is unlikely to help at this stage. If direct access works, start v2rayN, select an existing server, choose “Restart service,” and check the logs for a core exit, configuration parsing error, or listener failure. Don't rely on the tray icon alone: if the window is open but the core has exited, the browser may be trying to connect to a local service that no longer exists.

Open “Settings” and select “Parameter settings” to note the “Local mixed listening port.” The commands below use 10808 as an example; adjust them first if your port is different. Check whether a listener exists, then identify its process. Don't assume that any process using the port is the correct core. A successful listener confirms only that the local entry point is active; you still need to test the remote connection.

# Windows PowerShell: Check the listening address, port, and owning process
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Send an explicit request to the local HTTP proxy
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/

The destination in the command is only an example; it may not be reachable from your network. For troubleshooting, use a known, accessible destination and keep it the same for each test. Any HTTP response from the destination—even an access-denied response or redirect—is different from a connection timeout and shows that the request reached an HTTP service. If you encounter a certificate error, check the system clock, destination name, and certificate chain. Don't hide the error by disabling certificate validation.

Use the results to choose your next step; don't guess

If the explicit proxy request succeeds, select “Automatically configure system proxy,” then fully quit and reopen the browser before testing again. If it still fails, compare with another browser that has no proxy extensions. If only one app is affected, check that app's proxy, cache, or network permissions. If all apps are affected, check system routing. Private browsing doesn't necessarily disable every extension, so it can't rule out extension interference.

If only some sites fail, note the affected domains, error types, and times, then check whether a direct-connection rule applies. A temporary routing change can serve as a comparison, but don't send all traffic through the same route long-term just to mask the issue. Restore the original rules, then check domain matching, resolution results, and rule order for the destination. After a routing change, establish a new connection: existing connections may keep using the old route, so an immediate refresh may not reflect the new settings.

At the end of this test, record four results: “Does direct access work? Is the local port listening? Does the explicit proxy work? Does the app follow the proxy?” These details are more useful than simply saying “the internet is down.” For individual questions, see Troubleshooting. If the listener won't start, see How to fix a local port conflict instead of repeatedly reinstalling the client.

Connection timeouts: distinguish transport from protocol handshakes

A timeout in a server test doesn't necessarily mean the server is down. The test may stop at DNS resolution, connection setup, the encrypted handshake, or the test destination's response. First check which destination and method the test uses; an unreachable test site doesn't mean every request is failing. Keep the current server configuration and compare it with another known-working server in the same subscription. Don't refresh the subscription, switch cores, and change transport settings all at once, or you won't know what changed the result.

Follow the logs to the first error

First, check that the server address and port are complete, with no extra spaces, line breaks, or truncated port number. If DNS resolution fails, investigate resolution first. A connection refusal usually means there is no service at the address reached, or an intermediary actively rejected the connection. A timeout only means the connection wasn't established in time; that message alone doesn't identify where the problem lies. Record the first relevant error. Later connection cancellations may simply be a chain reaction from the initial failure.

On Windows, you can check whether a regular TCP connection to the remote port can be established. The commands below prompt PowerShell to read the address and port from your existing configuration without putting real details in command history. Success confirms TCP reachability only; it doesn't verify credentials, transport settings, or TLS parameters. Failure doesn't prove the server is broken. This test doesn't apply to a link that uses UDP only, so limit your conclusion to the protocol tested.

$server = Read-Host "Enter the server address from your existing configuration"
$port = [int](Read-Host "Enter the server port from your existing configuration")
Test-NetConnection -ComputerName $server -Port $port -InformationLevel Detailed

If a regular connection succeeds but the client reports a handshake failure, check the protocol and transport parameters. Authentication fields for VMess, VLESS, and Trojan are not interchangeable. The WebSocket path and Host, as well as the gRPC service name, must match the server. With TLS, the connection address and server name may differ; don't remove the server name just because the address is an IP. The public key, short ID, and related REALITY parameters must also come from the correct configuration—don't combine values from another server entry.

Check the clock, network, and core separately

If you see an error that a certificate is not yet valid, has expired, or involves authentication time, check the system date, time zone, and automatic time synchronization. An incorrect clock can affect certificates and some authentication flows, but changing the time is not a universal fix for timeouts. If the certificate name doesn't match, check the server name and configuration source. Don't disable certificate verification as a permanent workaround. If your company network requires authentication or uses managed security software, confirm its connection policy rather than disabling protection.

When testing another network, keep the client, server, and destination the same. For example, make the same request over an approved mobile hotspot, then repeat it on the original network. If only one network fails, focus on network authentication, egress restrictions, and address-family reachability. If all networks fail but other servers work, check the affected server's status and parameters. On dual-stack networks, a resolved IPv6 address may not have a working route, but that doesn't justify permanently disabling IPv6 on the whole device.

Before switching to Xray or another supported core, confirm that the protocol and transport are supported by the target core. A graphical interface accepting a field doesn't mean every core interprets it the same way. Prefer the combination intended for your subscription and client, and test it separately while keeping the original configuration. If the issue began after importing a configuration, compare it with the last working version. Don't treat revoked or expired credentials as a reliable baseline.

When contacting the configuration provider, include when the issue occurred, the network type, protocol, whether a TCP connection succeeded, and the first error with sensitive details removed. Don't send the full subscription or screenshots containing authentication fields. If a server connects to only some destinations, also check egress routing and DNS. Attribute the issue to the server only after confirming that all destinations fail at the same stage. Once service is restored, turn off temporary verbose logging and restore test routing settings.

Subscription errors: check retrieval, parsing, and application separately

A failed subscription update can mean at least three different things: no content was retrieved, the retrieved content couldn't be parsed, or the list updated but the selected server no longer works. Check which step the log reached, then verify the target group in “Subscription group settings.” Don't create multiple groups with the same name, or delete your last working configuration just to clean up. Before updating, note the group name, node count, and current selection so you don't mistake a changed selection for a broken subscription.

Make sure the URL is valid and returns a configuration

First, check that the URL is complete; query parameters, capitalization, and trailing characters can all affect the request. Subscription URLs often grant access, so protect them like account credentials. Don't post them in public support tickets, screenshots, or online conversion tools. If you copied the link from a webpage, make sure it's the subscription URL—not an account page, QR code image URL, or browser redirect. What you see in a browser can help with diagnosis, but browser access doesn't guarantee the client will receive the same response.

If the response indicates unauthorized access, forbidden access, or a missing resource, check whether the subscription expired, its token was reset, or the URL changed. Trying different DNS servers is unlikely to solve a permissions issue. If the response is a login page, CAPTCHA, or maintenance notice, it isn't a node configuration—even if the status code indicates success. Get the correct URL from the configuration provider; don't manually encode a webpage and import it into the client.

If the request times out, check which update route you're using. If an existing connection works, try updating through the proxy. If no servers are currently available, try the route for “Update subscription (without proxy)” in the menu. Neither option is inherently better; choose based on whether the subscription server is reachable through that route. The update request may use a different route from the browser. Browser extensions, the system proxy, and TUN can combine in ways that make comparisons misleading.

Check the format, then check the selection after updating

Clients don't all support the same subscription formats and extension parameters. A full configuration file with many custom rules may not import as a node subscription, and a successful import doesn't guarantee that every extension field is preserved. Ask for a format explicitly supported by v2rayN or your Android client. If conversion is necessary, understand which fields it changes, use a trusted environment, and check whether transport, TLS, and REALITY parameters were dropped.

If nodes disappear after an update, check the group filters and search box before assuming the subscription returned nothing. A filter with a space or capitalization mismatch can hide every available entry. Clear temporary searches and confirm that you updated the intended group. If the subscription replaced existing nodes, the previously selected entry may no longer exist. Select a server from the list again, restart the service, and verify it with an explicit proxy request instead of relying only on the update notice.

Before setting an automatic update interval, complete a manual update and confirm the route works. Too-frequent updates can send duplicate requests and may trigger server-side limits. If the device is asleep, offline, or pausing background tasks, the timer may not run exactly on schedule. Don't start multiple refresh tasks because one scheduled update was missed. For groups that fail repeatedly, switch back to manual updates for now, record the failure time and response, and investigate the network and permissions.

If manual updates work but automatic ones fail, compare device wake times, network changes, and proxy status during updates. If all clients fail at the same time, check the URL and server status. Record only the error type; don't save the full subscription URL. For more on group updates and intervals, see Subscription update failures and automatic refresh settings. If updating the URL succeeds but connections still time out, return to connection troubleshooting instead of refreshing repeatedly and hoping for a different result.

Slow speeds: separate latency, throughput, and packet loss

A slow first page load, slow file downloads, and video buffering are different symptoms. A long delay before the first request could involve DNS, connection setup, or a handshake. Low sustained download speeds may be affected by the remote egress, destination site, Wi-Fi, and local system load. Start by describing a repeatable symptom—for example, the first visit is slow but a refresh works, or all large downloads are slow. Don't rank servers based on a single latency test and assume that explains the issue; lower round-trip time doesn't guarantee higher throughput.

Fix the test conditions, then compare routes

Use the same destination and file at roughly the same time, and pause cloud sync, system downloads, and other network-heavy tasks. If the direct and proxied tests use different destinations, you can't isolate the route as the cause. Different content delivery nodes can also produce varying results. Repeat the test two or three times on one server before switching servers. Don't run multiple speed tests at once: they compete for bandwidth and can make a usable connection look slow.

The command below discards the response body and reports request timings and average download speed, making it suitable for small repeat tests. Adjust the destination and port to match your environment. Through an HTTP proxy, DNS and connection timing can mean different things depending on the proxy protocol; don't treat each metric as a separate measure of remote DNS or server time. Average speed on a small page is heavily affected by the handshake and can't predict large-file throughput.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n" https://example.com/

If each connection is fast but the wait for the first byte is long, check the destination service and remote egress. If the first byte arrives promptly but transfer repeatedly stalls, check Wi-Fi signal, packet loss, and system resources. A refused ping doesn't mean the application connection failed, and successful continuous pings don't prove encrypted connections are working. Test requests over the protocol you actually use, and treat network diagnostics as supporting evidence rather than letting one number stand in for the real-world result.

Rule out local resource and routing issues

Check Task Manager or System Monitor for CPU and memory use by the core process, as well as disk activity. Older devices, power-saving modes, and thermal throttling can affect encryption and forwarding. Keeping logs at a verbose level can also cause extra disk writes. Restore the normal logging level, close unnecessary background tasks, and try again. Don't disable security software to save resources, and don't automatically blame unusually high usage on the client—check what traffic was running at the time.

Test the explicit proxy, system proxy, and TUN separately, enabling only one clear route at a time. If only TUN is slow, check the virtual adapter, routing conflicts, and other network filtering software. If only large files or a particular connection stall, investigate MTU compatibility while keeping the default value available for comparison. Don't copy a number from the internet and use it permanently. After changing MTU, establish a new connection and test multiple destinations; a working small page alone doesn't prove the issue is fixed.

Video buffering can also be caused by destination rate limits, content delivery location, or the app's own buffering strategy. If one site is slow through a server but others are fine, check routing and egress for that destination before reinstalling anything. Browser secure DNS, extensions, and caches can make its route differ from the command line. Likewise, a TCP test of a regular webpage doesn't cover an app that uses UDP. Record the app, destination, and transport when comparing results.

If speeds are slow at night but normal during the day while local resources and Wi-Fi remain stable, congestion at certain times is worth investigating. If switching networks helps, compare the local access routes next. Don't credit a one-off improvement to the last setting you changed; restore the original setting and run a reverse comparison. Keep a change only if the improvement is repeatable. More rules don't mean more speed. Removing duplicate proxying and unnecessary filters is usually a better path to stability than piling on “speed boost” settings.

DNS issues: find out where the destination is resolved

If a domain fails but some IP addresses connect, that suggests a resolution path worth checking; it doesn't prove DNS is the only cause. HTTPS sites rely on the server name and certificate, so opening an IP directly changes the test conditions. First distinguish between system resolution, browser secure DNS, resolution by the proxy core, and remote resolution: the same domain can return different results at each point. Note which app made the request and which proxy protocol it used before deciding which layer to adjust.

Check resolution results before clearing caches

On Windows, use the commands below to check the system's DNS results and the DNS settings for each network interface. Wired, wireless, and virtual adapters may all be present; the interface you're viewing may not be the one the system actually uses. Multiple returned addresses are not necessarily a problem—content delivery networks and dual-stack services commonly return several. Check for resolution errors, unexpected private IP addresses, and whether the results are reachable over the current network.

# Windows PowerShell: Check system DNS resolution and interface settings
Resolve-DnsName example.com
Get-DnsClientServerAddress

# Clear the system cache after correcting DNS settings, if needed
Clear-DnsClientCache

Clear the cache only after correcting the configuration. If the upstream issue remains, clearing it will just fetch the same bad result again. Browsers, client cores, and apps may also have their own caches that system commands can't clear. If needed, fully quit the affected apps and restart the core, but there's no need to reboot the whole device for every lookup. If the issue happens only after waking from sleep or changing networks, first check whether old DNS settings remain on an inactive interface.

With SOCKS, the destination name can be resolved locally or by the proxy. The key difference between the two commands below is where DNS resolution happens—not that one method is “safe” and the other isn't. Use these tests only if the local mixed port provides the relevant service. If only remote resolution works, investigate local DNS and routing. If both fail, check the connection logs too; changing DNS servers alone may not help.

# Resolve the destination domain locally
curl.exe --socks5 127.0.0.1:10808 -I --connect-timeout 10 --max-time 20 https://example.com/

# Let the SOCKS proxy resolve the destination domain
curl.exe --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 --max-time 20 https://example.com/

Check domain strategy alongside routing rules

The domain strategy in v2rayN routing settings affects when a domain is resolved for IP-based rules. In Xray's terminology, AsIs doesn't proactively resolve the destination for routing; IPIfNonMatch tries matching the resolved IP only when no domain rule matches; and IPOnDemand may trigger resolution when processing IP rules. Available options and behavior depend on the core in use, so don't apply one core's explanation to another.

The snippet below illustrates routing semantics; it isn't a complete file to replace the configuration generated by the client. It explains how domain strategy and rules relate, but does not provide a general-purpose DNS server address or replace settings in the client interface. Make changes in the interface where possible so they aren't overwritten the next time the service starts. Read rules from top to bottom: an earlier direct-connection rule may prevent a later proxy rule from running at all.

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

If you use encrypted DNS, the resolver itself still needs a reachable connection route. The resolver's initial domain lookup, connection route, and proxy startup order can depend on one another and create a loop: without DNS, the proxy can't connect; without the proxy, the DNS server can't be reached. Restore working basic resolution first, then enable advanced settings one at a time. Don't switch the system, browser, and core to the same new resolver all at once, or it will be hard to tell which layer is actually taking effect.

Company intranets, home device names, and public domains may need different DNS scopes. Sending every query to a public resolver can break internal names, while forcing internal addresses through a remote route can disrupt local access. After recovery, test public sites, local network services, and the system's behavior after waking from sleep. For IPv6, check the default route and address reachability before changing address selection for an individual app. Don't disable IPv6 globally instead of identifying the route issue.

System proxy not working: check the app first, then TUN

If an app still connects directly after you select “Automatically configure system proxy,” first confirm that the app reads the system proxy settings. A system proxy provides settings for apps to use; it doesn't force all network requests through a proxy. Some apps have their own configuration, and command-line tools may read only environment variables. TUN routes traffic through a virtual network interface and system routes, covering more traffic. These methods serve different purposes; don't enable every routing method at once when the system proxy fails.

Know the limits of the three system proxy options

“Automatically configure system proxy” typically points the system entry to the client's local listener. “Clear system proxy” removes the relevant proxy settings. “Do not change system proxy” means the client won't actively change existing settings; it doesn't mean traffic necessarily goes direct. After switching options, check the address and port in the operating system's network settings, especially if a manual proxy and automatic configuration script are both set. Other software may rewrite system settings, so a success message in the client doesn't guarantee they stay unchanged.

Browser proxy extensions, managed policies, and app-specific settings can all override the system entry. Temporarily disable relevant extensions, then fully quit and reopen the app. If your browser is managed by an organization, don't change its policies without authorization. On Windows, different network components may also use different proxy settings; some system services don't share the current user's browser settings. So a working browser confirms only the browser's route—not that update services, terminals, and background processes use the same one.

Start by testing a command-line tool with an explicit proxy option. If it works, then check environment variables; this avoids making changes you may forget to undo. The example affects only the current PowerShell session and applies to tools that support these variables. Variable names and precedence vary by program. NO_PROXY can bypass the proxy for specified destinations. An overly broad domain suffix in its value can make some sites always connect directly.

# Current PowerShell session only; adjust the port to match the client
$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

# Remove these settings after testing
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

Test TUN on its own with a minimal setup

Check “Enable Tun mode” only if you need to route traffic from apps that don't use a proxy. First quit other virtual network tools and proxy clients, confirm the core works and an ordinary proxy request succeeds, then follow the client's permission prompts. If permission is denied, the virtual interface fails to start, or routes can't be added, use the logs to identify the cause instead of repeatedly toggling the setting. Before granting elevated permissions, make sure you're launching the intended client. Don't loosen permissions for your entire Downloads folder as a permanent workaround.

If all traffic stops after enabling TUN, first check for a default-route loop and whether the client's traffic to the remote server is being sent back into the virtual interface. When multiple virtual network tools modify routes, the apparent priority may not match the actual traffic path. Quit them one at a time, then test with a single client. To inspect routes, use route print on Windows or ip route on Linux. Record the results first; don't delete a default route based on an unfamiliar command.

If your local network is unreachable only with TUN, check private-address rules, interface selection, and DNS. Don't enable “Allow connections from the LAN” as a workaround: it controls whether other devices can reach your local proxy listener, not whether this device can access the LAN. Opening the listener also requires consideration of firewall rules and trusted networks, so it isn't a universal fix for local network issues. Keep troubleshooting local access separate from sharing a proxy with other devices.

If the internet stops working after you quit the client, first clear the system proxy and check whether the virtual interface and routes were removed. If needed, reconnect the physical network through the normal interface, but don't reset all network settings; that can affect static addresses, corporate networks, and other virtual adapters. After recovery, test both a normal exit and waking from sleep. For browser and terminal differences, see Troubleshooting a system proxy that isn't working instead of mistaking an app-specific issue for a server problem.

Client crashes: distinguish the interface, core, and system environment

A double-click that opens no window, a window that immediately closes, and a core that exits during a connection are different issues. First check Task Manager or System Monitor for a process still running in the system tray; repeated launches can cause port conflicts. If the window remains open but the logs say the service exited, the interface hasn't necessarily crashed. If the window disappears completely, check the app logs and system events. Note whether it happened on startup, during an update, after importing a configuration, or after enabling TUN. The timing narrows the cause better than repeated restarts.

Check the installation type and working directory

Choose an installer on the client downloads page based on your operating system and processor architecture. The Windows desktop and classic WPF editions use different interface technologies, so don't assume one edition's runtime requirements apply to the other. On macOS, distinguish Apple Silicon from Intel. On Linux, check both the distribution's package format and processor architecture. An architecture mismatch may prevent execution without a clear client error. Don't change a file extension to bypass the intended installation method.

For a portable archive, extract all files first and run the client from a fixed directory. Don't launch it from an archive preview or copy only the executable while leaving out its resources. For an installed version, use the operating system's supported repair or reinstall method. Check that the user data directory is writable, the disk has enough space, and cloud sync isn't locking configuration files. Don't install the client in a temporary location that needs frequent elevation, then run it as administrator indefinitely to hide a directory issue.

If security software blocks the client, check the event record for the specific file and reason, confirm its source and installation process, and follow your organization's or device manager's requirements. Don't disable protection globally or exclude an entire drive as a first step. If the system reports a missing runtime component, follow the requirements for the selected client build. Don't download an unknown standalone library to fill the gap. Missing resources, permission errors, and architecture mismatches are different problems; installing more components may not help.

Back up first, then test with a clean configuration

If the crashes began after importing or updating a configuration, exit the process normally and back up the current user data before creating a separate test environment using a method supported by the client. Don't delete files in bulk without knowing where the data directory is. In the test environment, leave autostart, TUN, and automatic updates off; launch the interface and add only the minimum required configuration. If the clean environment works, restore groups, rules, and other settings gradually. If it crashes the same way, investigate the system environment and installation resources instead of continuing to delete servers.

On Windows, use the Application entries in Event Viewer to find the faulting module by time. On macOS, check the system crash reports. On Linux, launch the graphical program from a terminal to observe standard error and check the current user's system logs. Log locations vary by distribution and launch method, so don't assume every system uses the same file. The command below shows only recent user logs, but they may still contain personal paths and details about other programs. Filter them before sharing.

# Linux: Show the current user's logs from the last ten minutes
journalctl --user --since "10 minutes ago" --no-pager

If the log clearly reports a local port conflict, identify the owning process instead of randomly terminating network processes. On Windows, pass the process ID from the listener query to Get-Process -Id to check its name, then exit the corresponding program normally. If you need to change the “Local mixed listening port,” record the new value and update any browser, terminal, or other apps configured manually. Reapply the system proxy; existing environment variables won't update automatically when the client changes ports.

If the Linux desktop launcher doesn't respond but the program starts from a terminal, check the launcher's executable path, working directory, and environment variables. Autostart failures may also mean the network wasn't ready or a permission prompt couldn't be displayed; they don't necessarily mean the program can't run. See Linux desktop installation and autostart for related setup details. After fixing the issue, verify manual startup first, restore autostart, then test a reboot and normal exit.

If the issue started only after switching cores, restore the previous combination and check whether the target core can read the configuration. When reporting a crash, include the system architecture, installation type, action that triggered it, and a sanitized error excerpt. Don't guess at version-related causes or simply say “it stopped working after an update.” A short, repeatable sequence is easier to analyze than a full screen recording. Restore automatic tasks only after confirming the fix, so updates or subscription refreshes don't change test conditions.

Android troubleshooting: check VPN permission, background access, and app scope

If an Android client says it's connected but apps have no traffic, distinguish a successfully started VPN service from a successful remote connection. When v2rayNG's connect button shows that it's running, that only confirms the local service started; verify actual requests and logs too. Check v2flyNG as a V2Fly-core alternative using its supported configurations and menu options. Don't assume a node behaves identically after importing it into both clients; extension fields and core capabilities can affect how the connection works.

Check system authorization and VPN conflicts first

When connecting for the first time, confirm the system VPN permission prompt was accepted. A denied permission, device management policy, or background interruption can prevent the service from starting. Android typically allows only one regular VPN service to route traffic at a time. Check for a work VPN, network filter, or other proxy app using the connection. Stop it normally before starting the client you're testing. Avoid repeatedly tapping Connect; rapid start-stop cycles make service state harder to interpret in the logs.

If “Always-on VPN” or “Block connections without VPN” is enabled in system settings, direct connections may also be blocked when the client stops. That doesn't necessarily mean a proxy is stuck. Check the system VPN settings and note their original state. If you have permission to change them, adjust as needed for the test. On managed devices, follow your organization's policy; don't remove management components to troubleshoot. After testing, restore any protection settings you need and check normal disconnect behavior.

Open the client log and make one request to a known destination. Check whether a corresponding entry appears. If there's no request entry, check the app scope and routing entry point. For a resolution error, go to the DNS section; for a handshake error, return to the connection timeout section. Don't rely only on connection duration or icon color. When comparing mobile data and Wi-Fi, keep the same server and make sure Wi-Fi sign-in is complete—captive portal authentication can affect both proxy connections and ordinary browsing.

Troubleshoot disconnects on screen lock and app routing

If the connection works at first but drops after the screen has been locked for a while, check battery optimization and background restrictions. Menu names vary by manufacturer; review battery use, background activity, and autostart in the app's settings instead of following instructions for another brand. Adjust only the settings needed for this client, keep its notification visible, then test locking and waking the screen. Don't loosen restrictions for every app: that uses more battery and doesn't prove the server is at fault.

If only some apps fail, check whether the app routing list means “proxy only selected apps” or the opposite, “bypass selected apps.” The same checkbox can include or exclude an app depending on the mode. After changing it, stop and restart the VPN, then fully quit and reopen the affected app; existing connections may keep their old route. Also check whether the app is in a work profile with a different management scope. Don't assume settings in your personal profile apply to every app.

Devices connected to your phone's hotspot don't necessarily use the phone's VPN automatically. Hotspot forwarding, requests from the phone itself, and sharing a local proxy listener with the LAN are different routes. A working webpage on the phone doesn't prove that hotspot sharing works. When troubleshooting the phone's own connection, turn off hotspot sharing first. If you need to provide a proxy to trusted devices, separately check the listening address, authentication, and network access scope. Don't expose the proxy to an untrusted network just for testing.

Check subscriptions, network changes, and installation separately

In v2rayNG, open “Subscription group settings,” confirm the group URL and enabled status, then choose “Update subscription.” If no connection is currently available, the update request may need to use a direct route. Confirm the choice in the menu and logs; browser access doesn't prove the client uses a working route. After a successful update, select a server again before connecting. Subscription URLs grant access: don't store them long-term in public clipboard history or send the full QR code to someone for troubleshooting.

If the connection drops when switching from Wi-Fi to mobile data, stop and reconnect once to establish a connection over the new network. If that works, check whether the system restricts background network access, whether DNS is using stale state, and whether the remote address is reachable on both networks. Don't reset all network settings as a first step. Dual-stack networks and carrier-grade address translation can change connection conditions. A working webpage doesn't fully test apps that use UDP, so compare using the actual app.

Finish with a full verification: connect and visit a destination, lock and wake the screen, switch networks and reconnect, then disconnect normally and confirm direct access. Passing every step covers the main mobile scenarios. If the issue persists, record the system version, client, network type, whether it relates to screen locking, and the first error with sensitive details removed, then see Frequently Asked Questions. To rebuild the basic configuration, return to the getting started guide. Don't keep temporary test settings as your everyday defaults.