V2Ray Troubleshooting

No Internet: Trace the Request Path

A client showing as connected doesn’t mean app traffic is going through the proxy. A typical request passes through the app, local listener, core routing, remote connection and destination service. If any handoff fails, later stages won’t receive the request, even when configured correctly. First note whether all apps are affected, only the browser, or just certain sites. Record what changes when you connect, too, so you don’t mistake an existing network problem for a client issue.

Compare direct and proxied connections

First, clear the system proxy or disconnect on Android, then visit a site that normally works without a proxy. If direct access also fails, check Wi-Fi sign-in, the router connection, system time and the network itself. Don’t rely on a tab that was already open; the page may be cached. Open or refresh a page to confirm a real request is being made, then connect the client and repeat the test.

On desktop, start troubleshooting with v2rayN. Open the settings and check the actual local listening address, port and protocol, then compare them with the system proxy settings. The 10808 and 10809 shown in our examples aren’t guaranteed defaults across versions: some interfaces use a mixed listener, while others provide separate SOCKS and HTTP listeners. Trust the current client settings and startup logs, not an old screenshot.

Next, open the client log, clear old entries or note the current time, then make one failed request. If no new connection appears, first check whether the app uses the system proxy and whether the browser’s own proxy settings override it. An error after a local inbound entry means the request reached the core; check the node, routing and DNS. If the log level is too low to show individual connections, raise it by one level temporarily and restore it after testing.

Isolate system settings with an explicit proxy

The commands below apply only if you’ve confirmed that 127.0.0.1:10808 provides a SOCKS service; replace the port if yours differs. On Windows, use curl.exe in PowerShell. On macOS and Linux, use curl. The example domain is for checking the request path, not measuring speed. If the tool isn’t installed, use the app’s built-in proxy settings instead; there’s no need to install another network tool.

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

If the explicit proxy gets a response but the browser doesn’t, the node is unlikely to be the first thing to suspect. See the System Proxy section. If the local address can’t be reached, check the core process, listening port and port conflicts. If a local connection is established but the handshake then fails or times out, see Node Timeouts. An HTTP error can still indicate that the connection was established; not every unsuccessful status means the proxy disconnected.

Verify recovery; don’t just check the connection button

To verify recovery, check these in reverse order: the core starts without errors, the local listener is available, the app request appears in the log, and the destination responds. Change one variable at a time, then retry the original failed request. If you switch nodes while also changing DNS, routing and browser settings, you won’t know what fixed the issue or how to restore your original setup. Once it works, note what resolved the problem and keep only the logs you need.

Node Timeouts: Check the Port and Transport Settings

A timeout means an operation didn’t finish before its deadline; it doesn’t identify where the problem is. Node latency tests, transport connections and page loads may use different targets and paths. First identify which operation failed, then check the core log from the same time. One failed test doesn’t prove a node is permanently down. If failures continue, first rule out local network changes and settings that haven’t taken effect.

Tell connection refusals, handshake failures and timeouts apart

A connection refused entry usually means the address didn’t accept the connection. The port may be wrong, the service may not be listening, or an intermediary may have actively rejected it. An i/o timeout means the wait expired; check whether it occurred during DNS resolution, dialing or waiting for a response. An EOF only means the connection ended early. On its own, it doesn’t prove the credentials are wrong; review the surrounding protocol and handshake entries.

Check the system date, time and time zone, and enable automatic time synchronization. Certificate validity checks and some authentication methods depend on the correct time. A computer waking from sleep, coming back online or having its clock changed manually can suddenly fail to connect. Then confirm the active node is the one you’re troubleshooting. Stop the old connection and reconnect; selecting a row in the list doesn’t necessarily make it the active server.

Compare the entry field by field with the configuration from your service provider: server address, server port, user ID or password, transport and security settings. The server port is the remote service’s entry point; the local listening port is where apps connect to the client. They aren’t interchangeable. A subscription entry may also differ from the current server configuration due to stale cache, a failed group update or manual edits.

Check only fields used by the current node

For WebSocket entries, check the path and Host. Case, leading slashes and extra spaces can all affect matching. For gRPC entries, check the service name. For TLS, verify that the server name matches the certificate; it may differ from the connection address. Don’t disable certificate verification just to clear an error. That hides configuration issues and changes the security of the connection.

VLESS is a proxy protocol; REALITY is a security mechanism tied to a specific implementation. They aren’t interchangeable settings. For a REALITY entry, check the server name, public key, short ID, fingerprint and other parameters required by the server, and confirm that the current core supports that combination. v2rayNG and v2flyNG use different core families. Being able to import a share link doesn’t mean every field will work as-is.

For entries with complex transport settings, import a fresh copy of the original configuration for comparison instead of repeatedly changing options on the existing entry. Keep the original and add a recognizable note to the test entry so you don’t overwrite the wrong one. Don’t copy paths, server names or security settings from another node; these fields are usually a matched set, and changing one on its own can introduce a new error.

Use controlled tests to confirm a remote issue

Keep the client settings unchanged and switch to a node you’ve confirmed works. If the new node connects, the issue is more likely with the original entry’s parameters or remote status. If all nodes fail on the same network, try another working network and temporarily stop other proxy or tunnel apps. Reconnect after switching networks; an existing connection doesn’t become a valid comparison just because the network changed.

Contact your service provider about server listeners, firewalls or account status only after confirming the address and port, checking client compatibility and reproducing the failure on different networks. Include the time of failure, the core in use, a redacted error line and whether all nodes are affected. Don’t share a full subscription URL, user ID, password or share link; these may grant access to your account.

Subscription Failures: Check Fetching and Parsing Separately

Updating a subscription involves fetching the content, identifying its format, parsing nodes and writing them to a group. An update failure doesn’t necessarily mean the URL has expired. The network may be unreachable, the response may be a login page, the format may be unsupported, or the wrong group may be selected. Note the full error and distinguish “request failed” from “parse failed” before deciding whether to check the network or the content. Don’t delete all nodes first; you’ll lose working configurations to compare against.

Protect existing groups and working nodes first

In v2rayN, open the subscription groups and confirm that the group name matches the address being updated. Check for duplicate groups or similar labels. If the client supports configuration export, save a local backup and keep it secure; it may contain account information. Test a new URL in a separate group rather than overwriting an existing one. That makes rollback and before-and-after comparisons easier.

When pasting a URL, check that it doesn’t include leading or trailing spaces, line breaks, quotation marks or extra text from a chat app. Don’t remove query parameters after the question mark; they may contain authentication or format options. A URL with an expiry may need to be renewed, but its length alone doesn’t indicate a problem. If your provider issues a new URL, follow their guidance on whether the old one remains valid.

Next, confirm whether this update uses a direct connection or the proxy. Menu names vary between clients and versions, so check the instructions for the actual update action. If the active proxy node is down, trying to update through it can become a loop; where direct access is allowed, try a regular update. Conversely, if the subscription URL is only reachable through a working proxy, connect through a verified node first.

Inspect the response instead of repeatedly clicking Update

If the log shows an HTTP status, check the URL and account permissions first for authentication errors. If the request limit has been reached, stop retrying and follow the server’s guidance. A successful status doesn’t guarantee that the response contains node data: a network sign-in portal, login page or reverse-proxy error page may return an ordinary webpage. When the client tries to parse that page as a subscription, it may show an empty list or a format error without explaining what the response contained.

If you need to inspect the response, do so only in a trusted local environment. Don’t paste your subscription URL into an online decoder or testing tool. Confirm that the response contains supported share links or a subscription format, not an informational page. A large block of text in a browser proves only that content was fetched; it doesn’t prove that the protocols, fields and encoding are supported by your client.

If only some nodes from a subscription are imported, check the protocols and transports used by the skipped entries. Fields may be missing, format extensions may be unsupported, or the server may be returning content for a different configuration system. Ask the provider for an output format compatible with your client. Don’t paste an entire configuration intended for another use into a single-node import field. Check protocol support before switching cores, too.

Check filters, groups and update results

If an update reports success but the list is still empty, clear the search term, switch to all groups and check for node-name filters or hidden-item settings. Then compare the number of imported entries in the log with the current list instead of relying only on the status message. Some clients replace old entries in a group with the new subscription content. If the server returns nothing, repeated updates may remove existing nodes; a backup makes rollback easier.

A successful update doesn’t mean the connection has been verified. Select one newly imported entry as the active node, reconnect, then follow the subscription import steps to verify access. If all new nodes fail but the old ones work, focus on their settings and output format. If only the update fails while existing nodes still work, don’t change routing, DNS and transport settings at the same time.

For format compatibility issues, visit the Client Downloads page and choose a client that matches your operating system and architecture. Follow the upgrade instructions to preserve your configuration. Updating the client won’t fix every subscription issue: expired URLs, account permissions and server-side errors need to be handled separately. Record how the content was fetched, which stage failed and what was ultimately imported so you can pick up next time from what’s already been confirmed.

Slow Speeds: Separate Latency, Throughput and Stalls

“Slow” can mean at least three different things: a long wait before a page opens, low sustained download speeds, or frequent pauses after the connection has been up for a while. A latency test measures response time for a particular request; it doesn’t directly measure large-file throughput or performance across all sites. First describe the symptom specifically, such as “the page is slow to open the first time, but loads normally after a refresh,” then choose a test that can reproduce it.

Keep test conditions consistent for a fair comparison

Keep the device, network, client routing and destination service the same, and change only the node. Pause system updates, cloud sync and other high-bandwidth tasks, and check that your local connection isn’t saturated. A weak Wi-Fi signal, a busy router or too many connected devices can all look like slow proxy speeds. If services that work directly are also slow, fix the local network before repeatedly changing cores.

Test each node several times and record occasional failures separately from consistent problems. The destination service may limit speed per connection or use different content delivery paths based on your exit IP. It’s normal for the same node to perform differently across services. Don’t use a single speed test on one site to judge every use case. When testing pages, files or video, keep the content and quality consistent where possible.

If a node test shows low latency but pages still load slowly, check whether the log shows a long DNS wait or many repeated connections. A page often requests several domains at once, so a fast main document doesn’t mean images, scripts and APIs are taking the right path. Browser developer tools can help distinguish DNS lookup, connection setup and response wait times. Be aware that request URLs may contain personal information.

Check the actual outbound route and device resources

Temporarily select a clearly defined proxy route for comparison and confirm that slow requests aren’t being sent by a rule through an unsuitable direct connection. If a temporary routing change helps, restore the original mode and identify the specific rule; don’t mask the issue by proxying more traffic indefinitely. For services that require sign-in, changing exit IPs may trigger extra verification. Separate that wait from normal transfer time in your test results.

For persistently slow downloads, check network, CPU and memory use in your system’s task manager. Low-power devices may hit resource limits under high throughput, heavy encryption or many connections. If the CPU is continuously busy, switching to a lower-latency node may not improve speed. Very verbose logging can also increase disk writes and UI refresh load; restore your usual log settings after troubleshooting.

Multiplexing isn’t a universal speed boost. It changes how connections are organized, and performance depends on the protocol, transport, server support and link quality. Test it as a single change only if your provider says it’s supported, and record the before-and-after results. Don’t change multiplexing, congestion settings and DNS all at once; if performance changes, you won’t know why.

Check for network changes if connections stall intermittently

If a large transfer stalls after starting but small pages still load, check for packet loss, connection resets, path differences and server limits. Being able to connect doesn’t mean long-lived connections are stable. First test the same node on another working network, then decide whether to investigate path MTU. Don’t blindly copy a lower MTU value: it may restore some connections, but it can also reduce efficiency or introduce compatibility issues.

If speeds drop only after the connection has been up for a while, check device temperature, power mode, Android background restrictions and network-change history. After sleep or a Wi-Fi reconnect, an old connection may still be waiting to time out even though a new one would work. Reconnect the client for comparison. If only long-lived connections fail, note when it happens and whether the network changed instead of declaring the entire node unusable.

If several devices using the same node show lower throughput at the same time and improve after switching nodes, remote load or an issue with the exit link is more likely. Send your provider reproducible results from consistent test conditions. “The speed test is slow” isn’t enough to diagnose the issue. Include the destination service, duration, whether direct access works and whether latency is low despite low throughput.

DNS Issues: Find Out Where the Domain Is Resolved

DNS issues often affect only some domains, cause long waits on the first visit, or produce different results after a routing change. A request may use the system resolver, browser Secure DNS, the core’s built-in DNS or remote domain resolution. First determine whether the app gives the client a domain name or an already-resolved address, then check the corresponding resolution path. Changing system DNS may not affect queries made independently by the browser or core.

Check the resolution stage using the same domain

First, record the failing domain and exact error. “Host not found” is a different failure from a connection timeout after successful resolution. The system commands below can check whether the system resolver returns a result. They can’t prove that the proxy core got the same result or that the destination is reachable. To rule out cache effects, reconnect after changing settings and retest the same domain rather than trying a different site that happens to work.

nslookup example.com

If system resolution fails but an explicit SOCKS proxy works, the proxy may be resolving the domain through another path. The socks5h option in the earlier command sends the domain to the SOCKS server for resolution; with socks5, curl usually resolves it locally first. These options are useful for comparison, but how the local proxy resolves a domain ultimately depends on the core’s routing and DNS settings.

If only one browser has the problem, check whether it has its own Secure DNS setting enabled. The browser may bypass the system resolver or fail to resolve a domain before sending any request to the local proxy. Temporarily switching back to the system resolver can help isolate the issue; decide which option to keep after testing. Don’t change browser settings and replace the core’s DNS at the same time, or you’ll mix up two separate layers.

Check how core DNS interacts with routing

Core DNS settings cover more than server addresses: they also involve query types, which outbound handles requests, and whether routing needs a domain resolved to an address. This partial JSON shows the field structure. It keeps domains available for initial routing decisions and doesn’t resolve them just to match IP-based rules. It isn’t a complete working configuration and must not replace the full file generated by the client.

{
  "routing": {
    "domainStrategy": "AsIs"
  }
}

In Xray and V2Fly configurations that support this field, AsIs doesn’t mean domains will never be resolved. The actual connection or another component may still need an address. If you choose a strategy that resolves a domain only after it fails to match, IP-based rules can take part in later routing, but DNS becomes another dependency. Decide on your routing goals first; don’t switch every option at random just because you saw a DNS error.

With encrypted DNS, consider how the resolver’s own hostname gets resolved and whether requests to it go direct or through the proxy. If the proxy needs the node address resolved before it can connect, but the DNS request itself depends on that proxy, startup can get stuck in a loop. Keep a reachable resolution path for startup and follow the client’s instructions for the relevant setting; simply adding more DNS servers won’t solve the dependency.

Handle IPv6, caches and FakeDNS separately

Some networks return IPv6 addresses without a complete IPv6 path to the destination. This can cause long waits before fallback or intermittent timeouts. First confirm that the device has stable IPv6 connectivity, then compare address-family settings where supported. Temporarily using IPv4 can help confirm the cause, but it doesn’t mean disabling IPv6 is the fix for every problem; results can differ completely across networks.

After changing DNS settings, existing connections and app or system caches may keep using old addresses. Close the relevant pages and connections, then clear the cache using the method provided by your system. Don’t repeatedly reboot the whole device to hide the conditions that reproduce the issue. With FakeDNS, the corresponding core must map the virtual address back to its domain. After changing how traffic is intercepted, leftover virtual addresses may no longer route; make the app resolve the domain again.

Start troubleshooting with a simple, understandable resolution path. Once it works, add complex features back one at a time. Check both query errors and the final outbound in the logs; a successful DNS entry doesn’t rule out a later dialing failure. For how virtual-address handling works and where it applies, see FakeDNS Explained. You can also look up related terms in the Glossary.

System Proxy Not Working: Check Traffic Capture and Routing

System proxies, core routing and transparent traffic capture are three different layers. A system proxy tells apps that support the setting where to send requests. Routing decides which outbound the core uses after receiving a request. Transparent capture attempts to bring traffic in at another layer. Switching routing to global won’t make an app that ignores the system proxy connect to the client. First verify that the request reaches the core, then check which rule it should follow.

Check the address, port and app behavior

In v2rayN, select the option to configure the system proxy automatically, then open your system network settings and confirm that the proxy address matches the client’s actual listener. On the same device, it usually points to the loopback address, but use the port shown in your current settings. Don’t enter the remote node address as the system proxy, or use a SOCKS-only port as an HTTP proxy. If you use a mixed listener, confirm it supports the protocol the app needs.

On Windows, different apps may read different proxy settings, and command-line tools don’t necessarily use the browser’s settings. macOS proxy settings are tied to the current network service, so recheck them after switching between Ethernet and Wi-Fi. Linux desktop settings, app-specific settings and terminal environment variables may also be independent. A working browser proves only that the browser’s path works, not that every other app does.

Some apps have their own HTTP or SOCKS settings, which may override the system proxy. Browser extensions, developer tools and download apps can all retain old addresses. Terminal tools may also read proxy environment variables and exclusions; a matching exclusion sends the request around the proxy. Check where the settings for the specific process come from instead of relying on a single toggle in the system settings.

Check rule order and outbounds with a targeted rule

Once you’ve confirmed that the request reaches the core, check which routing rule matches it. Most rules are evaluated in order; a broad rule near the top may prevent a more specific rule later from ever running. This partial example sends the sample domain and its subdomains to an outbound named direct. Use it only if that outbound tag is defined in the full configuration. Don’t import the snippet as a standalone configuration.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

A rule’s display name may not match its actual outbound tag, so inspect the generated configuration before changing custom rules. If the app resolves a domain to an IP first, the inbound request may contain only the address, leaving domain rules unable to match. Traffic sniffing can restore domain information in some cases, but protocol and configuration limits mean it can’t recover the original domain for every request. Use the logs to confirm that the rule has the information it needs.

If switching temporarily to global routing fixes the issue, the original rules, DNS results or default outbound likely differ. Restore the original mode, add a precise comparison rule for one failing domain and check whether it works when matched. Don’t clear all rules or broaden the match indefinitely; that may also affect local network services, work networks and nearby devices that should connect directly.

Rule out conflicts between multiple proxies

When multiple proxy apps are running, they may compete for system proxy settings or local ports. Closing one doesn’t guarantee that the other will take over automatically. For testing, leave only one client running, reapply the system proxy and check its actual address. If transparent capture or virtual network mode is enabled, identify which layer handles incoming traffic to avoid request loops or duplicate capture.

Consider another client mode only if the app doesn’t read the system proxy and you genuinely need to capture its traffic. Grant permissions required by the mode according to the platform’s instructions; running as administrator all the time isn’t a substitute for diagnosing the issue. On managed devices, an organization policy may set the system proxy and override local changes. Follow the device management requirements rather than repeatedly forcing a change.

To verify recovery, test the app that originally failed and a service that normally connects directly. Also confirm that the network still works after the client exits. If only local network access is affected, check exclusions, listener scope and rule order; don’t expose every inbound interface. If the terminology is unclear, review Routing and DNS Terms, then return to this section and check which layer each setting belongs to.

Startup Failures and Crashes: Separate the UI from the Core

First classify startup issues as one of three types: the interface won’t open, the interface works but the core exits, or the entire app closes after running for a while. These more commonly involve the runtime environment, configuration or ports, and system events or resources, respectively. Note the last screen you can see and the full error message; don’t delete the configuration directory straight away. If the client UI is still running, a tray icon doesn’t prove the core started successfully.

Check the installer and system architecture

Start at the Client Downloads page and confirm that you chose the right platform and processor architecture. The Windows desktop and classic WPF editions may have different interfaces and runtime requirements; follow the instructions for the specific download. On macOS, distinguish Apple Silicon from Intel. On Linux, check both processor architecture and package format for your distribution; a similar file extension doesn’t mean a package will install.

If the system reports a missing runtime component, identify the component in the error and the client branch you’re using. Don’t copy dynamic libraries from an unknown source. Linux GUI apps also depend on a desktop session and compatible graphics environment; in a command-line-only environment, a missing UI doesn’t mean the core’s network functions are broken. Follow the system’s supported process for package permissions and security warnings instead of disabling protection altogether.

If a problem starts after an upgrade, fully exit the old instance and check that no background process remains before launching the new program. Multiple instances may compete for configuration files and listening ports. Keep a backup of the original configuration and test in a separate directory or with a new configuration method supported by the client. Don’t mix the old program’s core with the new interface at random; this can introduce hard-to-identify compatibility issues.

Check whether the listening port is already in use

If the log says the address is already in use or can’t be bound, first identify which process is using it. The 10808 below is only an example for checking; it isn’t a default listener port for every version. Run the Windows command in PowerShell. Tool availability on macOS and Linux depends on what’s installed. No results only means no matching listener was found at that time; restart the core and check the log again.

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

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :10808'

After finding the process ID, check its name and path in the system process manager. Don’t end an unfamiliar process. If it’s an old client instance, exit it normally and try again. If another service needs to keep running, choose an unused port in the client settings. Then update the system proxy and any app-specific proxy settings too; otherwise the core may start successfully while requests still go to the old address.

If the log reports a configuration parse error, start with the first syntax or field error. Common issues in custom JSON include extra commas, incorrect quotation marks, misplaced fields and outbound tags that don’t exist. Undo the most recent change, then generate the configuration again. Don’t guess at and fix several things at once, and don’t treat the final exit message as the root cause; the actual error usually appears earlier.

Diagnose runtime exits and resource issues

If a crash occurs only after the app has been running for a while, note whether you just updated a subscription, changed networks, woke the system or enabled verbose logging. Check free disk space, memory pressure and whether the configuration directory is writable. Sync software changing configuration files at the same time, permission changes or failed disk writes can also cause problems. Avoid storing the active configuration where multiple programs may edit it.

If the interface exits but the core remains, close the relevant instances normally first, then clear any system proxy settings that point to the old listener. Deleting a desktop shortcut won’t stop a background process. If the system records crash events, look up the event around the failure time and note the exception module and error type. Before sharing the report, hide usernames, personal paths and command-line arguments that may contain node settings.

If a clean test configuration starts normally but the problem returns with the old configuration, restore subscription groups, custom routing, DNS and other advanced settings in batches. This helps identify the trigger instead of bringing everything back at once. For port conflicts, see Find the Conflicting Process and Change the Listening Port.

Android Troubleshooting: Permissions, Background Activity and Per-App Routing

On Android, v2rayNG and v2flyNG usually use VpnService to capture app traffic. System connection permission, background restrictions and per-app rules can all affect the result. A running connection button only means startup has reached that stage; also check the system VPN indicator, notification and client log. First distinguish a failure immediately on startup from a disconnect after locking the screen, or an issue affecting only some apps.

Verify VpnService permission and connection ownership

When you connect for the first time, the system asks whether to allow the app to establish a VPN connection. Confirm that the requested app is the client you’re using. If the prompt doesn’t appear or closes immediately, check whether another system dialog is covering it or device management policy is blocking the connection. Don’t rapidly tap Start repeatedly; permission, stop and restart actions may overlap and make the logs hard to interpret.

Usually, only one app per Android user can own the active VPN connection at a time. Other networking tools that use the same system interface may replace the current connection; starting v2rayNG may also stop another VPN. Stop other similar tools first, then start the client you’re troubleshooting and confirm which app the system shows as connected. Don’t run v2rayNG and v2flyNG together to compare nodes; test them separately.

If Always-on VPN or blocking connections without a VPN is enabled, stopping the client may prevent even direct access. That doesn’t mean the subscription has suddenly broken; a system policy is still restricting traffic. Check the current app and related options in the system VPN settings, and adjust them to suit your needs. Work and personal profiles may have different management rules, so check the profile where the issue occurs.

For disconnects after locking the screen, check power and data restrictions first

If the client works in the foreground but fails after the screen has been locked for a while, first check whether its process is still running, whether the notification disappeared and whether the log stopped. Battery-saving policies may restrict background networking or terminate the process. Allow background activity or choose an appropriate battery setting for the client, and check the manufacturer’s autostart and background management options. Menu names vary by device; follow what’s shown on your screen.

Allowing background activity doesn’t override every network restriction. Also check background data and Data Saver settings. If the client works on Wi-Fi but fails on mobile data, confirm that both the client and target app are allowed to use that network. After changing settings, reconnect and retest the same app after locking the screen for the same amount of time. One successful unlock doesn’t prove the issue is fixed; the app may reconnect only after returning to the foreground.

If the notification remains but the network has changed, an old connection may not have recovered. Note when Wi-Fi and mobile data switched, then stop and restart the connection for comparison. If reconnecting restores access immediately, investigate network handoff recovery instead of repeatedly changing DNS. Deep battery saver, brief signal loss and switching access points can all affect existing long-lived connections.

Check what the per-app list means

With per-app proxying enabled, first check whether the mode proxies only selected apps or bypasses the proxy for selected apps. The same checked list has the opposite effect in each mode, so don’t judge by checkmarks alone. After changing the setting, reconnect the client and fully close and reopen the target app so it doesn’t reuse an existing connection. Whether newly installed apps are included automatically also depends on the selected mode.

Some services call system components, download services or separate sign-in processes, so not every request necessarily comes from the app you see on screen. Temporarily disable per-app restrictions to test whether full traffic capture works; if that fixes the problem, narrow the scope one step at a time. Don’t assume every feature works just because the main app can open its home page. Sign-in, attachment downloads and media playback may use different request paths.

When switching from v2rayNG to v2flyNG, verify system permission, per-app settings and protocol compatibility again. They use different core families—Xray and V2Fly—so not every extended parameter is interchangeable. Choose the client that matches the node requirements, verify one entry known to be supported, then restore custom settings. See Android Client Downloads for installers and architecture options.