V2Ray Troubleshooting Guide

No internet: Trace the connection path

A client that appears to be running does not necessarily mean browser requests are going through a node. First note the scope: do all apps fail, or only the browser? Are all sites inaccessible, or just one domain? Does regular direct access work after you close the client? These comparisons help distinguish system networking, app routing and the destination service. Use the same HTTPS page that normally works, rather than switching targets and muddying the results with a site-side issue.

Set up a minimal test

Exit other proxy apps, pause browser proxy extensions and turn off TUN. Leave only v2rayN's standard local proxy enabled. Choose a node with known, complete settings and make sure it is the active server. Then check the main window log to confirm the core started normally. If you have not completed the initial setup, do not start with advanced routing; follow the quick start guide first. Closing other apps helps rule out port conflicts and competing traffic interception; it is not a recommendation to change your setup permanently.

Open the settings and note the actual local SOCKS or mixed-listener port. The commands on this page use 10808 only if that port really provides SOCKS service; if you changed it, update the command too. A listener bound to 127.0.0.1 accepts requests only from the local machine, which is normal for local use. Do not enable LAN access or bind to all network interfaces just to fix a browser on this machine; that exposes the listener more widely than necessary.

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

This command explicitly uses the local SOCKS proxy and lets the proxy resolve the destination domain, making it useful for testing the connection path independently of browser proxy settings. On Windows, use curl.exe if the equivalent command is not available by default. An HTTP response means the request reached some responder; a status code other than a success page does not immediately mean the proxy failed. Certificate errors, connection refusals and timeouts point to different layers. Keep the full error instead of noting only that the site will not open.

Choose the next step based on the result

Check the logs at the same time: is there an entry for the target near when you ran the command? If not, make sure the current log level records access requests and that the command points to the running instance. If the target appears but the outbound tag is unexpected, check the routing match and final default outbound. Temporarily routing everything through the proxy can help narrow things down, but restore your usual policy afterward; changing modes is not a universal fix.

If only one site fails, compare other destinations on the same node and the same destination on other nodes. A single site showing access denied, a CAPTCHA or a region notice usually means the application-layer connection was established. Changing the local listening port will not fix a restriction on the destination side. If the browser reports an invalid certificate date, check the system date and time zone first. Do not disable certificate verification to hide the error, and do not assume that any connection returning a page is secure or working correctly.

Node timeouts: Separate probes from real connections

A timeout in the server list can mean several things. Some tests only check whether a TCP port is reachable; others request a specific URL through the node. Results can also depend on the test target, handshake and local DNS. First identify which test you ran, then reproduce the issue by opening a normal webpage. A reachable TCP port only means a service responded at that address; it does not confirm that the protocol settings, credentials or transport are correct. A probe can time out simply because its test target is unavailable, so it does not prove the whole node is down.

Check the address, port and handshake in order

Open the editor for the active node. Check the server address, port and protocol first, then review the transport, TLS, server name and related transport fields. For an imported subscription, compare the settings with the provider's original details instead of guessing from the node label. A label is just a display name and can be anything; it does not identify the actual protocol or route. When copying an address, watch for leading or trailing spaces, non-ASCII punctuation and line breaks. The port field should contain a number, not a protocol prefix or URL path.

If the server address is a domain, the client must resolve it before it can connect to the remote server. If the log reports a DNS failure before attempting that connection, troubleshoot the node's domain resolution rather than changing routing rules for the destination website. You can query the server domain in a system terminal and compare results on your current network and another trusted network. Do not permanently hard-code a returned IP as a general fix: an entry point may use multiple addresses, and a fixed address can bypass later updates.

Test-NetConnection -ComputerName example.com -Port 443

The command above uses Windows PowerShell syntax to check TCP connectivity; the example domain is not a working node. Use the actual node address and server port when troubleshooting. This command does not authenticate with the proxy protocol or test UDP transport. If the TCP test succeeds but the client handshake fails, focus on the TLS server name, transport path, authentication fields and device time. For REALITY settings, compare the server name, public key and short ID against the provider's details. Do not guess by changing fields at random.

Use cross-checks to narrow down the cause

Test two nodes that normally work on your current network, then test the same node on another network. If all nodes fail on only one network, the issue is more likely with the local network, router or network path. If one node keeps failing on multiple networks, the remote service or that node's settings are more likely at fault. When switching networks, leave the destination and client settings unchanged; do not also change the core, protocol or routing. Hotspot tests may use mobile data, so keep requests small—there is no need to download large files.

connection refused in a log often means no service is listening on the destination port, or the connection was explicitly rejected. timeout only means the wait exceeded its limit; it does not tell you which side dropped the traffic. EOF or a connection reset means the connection ended early. Check whether it happened during dialing, the TLS handshake or after authentication. Match the destination address in the error to the active node so you do not mistake subscription updates or background probes for connection failures. Repeated retries add noise; the surrounding log lines for the same request are more useful.

If timeouts started after waking the computer from sleep or switching from wired to wireless, stop the connection and restart the core to clear stale connections and routes. If needed, close and reopen the client rather than deleting all servers. A long-lived connection can retain an invalid path after a network change, and rebuilding it may be enough. If it only helps briefly, note how long it takes to fail and whether the issue follows screen sleep, then check network power-saving and background policies. Do not mistake a short-lived recovery for a remote fix.

Subscription failures: Check retrieval and parsing separately

A subscription update has two stages: the client requests the subscription URL, then parses the response into nodes. A failed download, empty response, unsupported format and duplicate nodes are different problems. If clicking Update adds no nodes, that does not necessarily mean a network failure: the content may be unchanged, a group filter may hide the results, or the subscription may contain fields unsupported by the current core. Save your working configuration first, and note the current group name and node count before updating. Do not clear the list just to test whether the URL works.

Check the subscription entry and URL type

In v2rayN's subscription group settings, check the URL for the relevant group. Make sure you copied the full subscription link, not a login page, purchase page or single-node share link. In v2rayNG, open subscription settings, check the address and whether the entry is enabled, then update it. A single-node share link and a URL that returns multiple nodes serve different purposes. Putting the former into a field that accepts only subscription URLs may produce an unsupported-address or empty-response message. Clicking Update again will not change the URL format.

Query parameters in a link often identify the subscription. Missing the end of the URL can make the server return a login page or an error. Chat and note apps may truncate links around line breaks or punctuation, or when automatically recognizing a URL; copy it again from the original source. Inspect the full value locally and hide its parameters in screenshots. If a browser opens the URL, that only shows that the browser received a response over its own network path. It does not prove the client uses the same proxy or request headers, or that the response contains node data.

Start by checking the HTTP status in the update log. For an authentication failure, check whether the link expired or access changed. If requests are too frequent, stop retrying and wait according to the provider's update limits. For a server error, note the time and try again later. A successful status with a parsing failure may mean the response is a webpage, an access notice or a different configuration format. Do not paste the full response into a public conversion tool; subscription URLs and node credentials may be exposed. Use a conversion method with a clear source that can run locally.

Check which network path the update request uses

Some clients let subscription updates connect directly or through a proxy. The setting location and default behavior may differ, so check the current version's settings and logs. If your existing nodes are no longer working and the update depends on one of them, you can get stuck in a loop: you need an update to restore the connection, but need a connection to update. Try a direct update first. If the URL is reachable only through a proxy, temporarily use a connection you have confirmed works. Change only the update path at a time; do not also change the subscription URL, so you can tell which change helped.

If you see a TLS or certificate error, check the device time, system certificate store and URL spelling first. A corporate network or public Wi-Fi that requires sign-in may return an authentication page; sign in through a browser before updating the subscription. Do not ignore certificate errors to work around a subscription problem. Subscription content determines later remote connections, so verifying the source matters more than getting one download to succeed. If the URL redirects, ask the provider whether the final endpoint has changed rather than replacing it with an unfamiliar relay address.

If content downloads but the node list remains empty, check group filters, search terms, deduplication settings and node types. Some subscriptions target other configuration systems; similar-looking extensions do not guarantee that they can be imported directly. Some fields also require specific core capabilities, and an older core may reject them during parsing or startup. Update the client to a build that matches your system architecture, then reimport the original subscription. Do not remove fields you do not recognize by hand; that can leave a node that saves successfully but cannot authenticate.

After a successful update, check that the active node is still present, that routing rules do not depend on an old group, and that automatic selection has not switched servers. Duplicate names do not necessarily mean duplicate addresses, and a changed name does not necessarily mean the service changed. For detailed steps and format differences, see how to import a subscription link. When asking for help, share the response status, parsing error and client name. Do not share a usable subscription URL.

Slow speeds: Separate latency, throughput and jitter

“Slow” can describe at least three things: a long wait before a page starts responding, low sustained download speeds, or a connection that keeps speeding up and slowing down. One latency number from the server list cannot describe the full experience. First identify whether the bottleneck occurs while establishing a connection or during sustained transfer, then compare results on the same network, to the same destination and at the same time. Rapidly switching through dozens of nodes makes results hard to compare and may trigger rate limits. A few controlled tests are usually more informative than a large automated speed test.

Establish a direct-connection baseline first

Pause system updates, cloud sync and other high-bandwidth tasks. Check that the Wi-Fi signal and local network are working normally. With the client closed, try a service that usually works directly and see whether it is still slow. If the baseline is already poor, investigate local bandwidth use, wireless interference or router load first. This baseline only reflects the access network; it does not predict node speeds. Speed tests also use service traffic. If your subscription has a quota, use a brief test that you can stop and check the billing terms beforehand.

Next, keep the same node and reopen the same page to compare the first visit with subsequent visits. If the first visit is slow but later ones are fine, DNS, the TLS handshake or connection reuse may be involved. If every visit is slow, check for frequent reconnects in the logs and whether the destination address keeps changing. Browser developer tools can help distinguish time to first byte from content download time, but page scripts and ad requests also affect completion time. When testing the proxy path, do not rely solely on how long a complex page takes to finish loading.

Rule out extra network paths and resource contention

Check whether the app is using a browser proxy extension, system proxy and TUN at the same time, or has an additional upstream proxy configured. Multiple layers can add handshake overhead or create a loop. Keep one clear access method and test the same request. If the standard system proxy works but TUN is slow, focus on virtual adapter routing, DNS interception and conflicts with other network software rather than replacing every node. The path from your device to the node and the path from the node to the destination can both limit performance.

Check CPU, memory and network usage by the core process, especially on smaller devices, with many concurrent connections or complex routing rules. If resource use is high, close unnecessary tasks and turn off verbose debug logging before measuring again. Do not treat random multiplexing, disabled encryption checks or unknown parameters as speed boosts. Whether multiplexing helps depends on the protocol, server support and connection pattern. A mismatched setup can increase failures; tune performance only after establishing a stable connection and confirming compatibility.

If a download starts at a normal speed and then steadily slows, compare different destinations and times of day. Check for destination-side throttling, service quota policies or congestion on a shared route. If all destinations slow down at the same time, note the time and test another node. If only one download source is affected, changing nodes may not help. Speed-test sites may choose different servers, so their results do not necessarily reflect everyday app performance. For a controlled comparison, use the same file from the same source for a short test; there is no need to download a large file from an unknown source.

UDP-based apps and webpages using TCP may follow different paths. If webpages work but real-time apps lag, check whether the protocol, node and access method support the required UDP traffic, then look for packet loss or network changes. Do not enable traffic interception for everything just because one feature is slow. An unsuitable MTU can cause some connections to stall, but do not reduce it without evidence. If only large responses over TUN get stuck, keep the original value, test a small change in isolation and restore it immediately if there is no improvement.

If performance drops only after extended use, also check device temperature, power-saving mode, background tasks and log growth. After the computer has been awake for a long time, rebuilding the connection can provide a useful comparison, but treat a restart as a diagnostic step. If the issue reproduces consistently, record the trigger instead of restarting every time. Before asking which core is faster, confirm that both tests used the same node settings, route and destination. Otherwise, changing network conditions—not core performance—may explain the result.

DNS issues: Find out which component resolves the name

Do not start DNS troubleshooting by switching to a public resolver. First find out which component is making the query. The system resolver, browser's encrypted DNS, the client core and TUN interception may all be involved. The node server's domain and the final website's domain are also resolved separately: the first locates the proxy entry point, the second the destination. If the entry point cannot be resolved, correct DNS settings for the destination will not restore connectivity. Mixing up these two lookups leads to more and more setting changes without fixing the problem.

Compare resolution paths with a controlled request

First note the domain in the error and which process made the request. Determine whether it is the subscription URL, node entry point or destination website. A system-terminal lookup tests only the resolver path currently available to the system; it does not represent the browser's or core's actual results. If the browser works but other apps fail, check whether the browser uses its own encrypted DNS. If an explicit proxy works but direct access fails, the issue may be with system DNS or the direct network path. Keep the destination the same during comparisons; success with a different domain does not diagnose the current one.

nslookup example.com

curl --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/

The two proxy commands differ in where the destination domain is resolved: socks5 usually resolves it on the local machine, while socks5h sends the domain to the proxy for resolution. If the latter works and the former fails, check local DNS first. If both fail, continue with the remote connection and core logs. Make sure the local port in the command matches the actual setting. This comparison does not prove that every app behaves the same way; an app may resolve names itself or use a cached address.

Check the DNS route and routing rules

In v2rayN, find the DNS and routing settings. Review the current values, then decide whether DNS requests themselves should go direct or through the proxy. If you configure remote encrypted DNS, the client must also be able to reach that resolver; adding an address alone does not create a working route. If the resolver's domain depends on the same proxy connection that has not yet been established, startup can end up in a dependency loop. Test entry-point resolution, resolver reachability and destination lookups separately instead of replacing every DNS setting at once.

The example above shows common DNS fields in a V2Ray-compatible configuration to illustrate the role of servers and query policies; it is not a complete node configuration you can import. A graphical client may regenerate its config at startup, so make changes through the relevant settings screen rather than editing a temporary file while it is running. Support for additional fields varies between cores and clients. If the log reports an unknown field or invalid policy, stay within the settings supported by your current core instead of copying a full configuration from another system.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

Getting an address does not mean it is usable. Check whether the results include both IPv4 and IPv6, and whether the current network can actually connect over each address family. If failures occur only when an IPv6 address is returned, temporarily try an IPv4-only query policy for comparison, then decide whether to fix the local IPv6 path. Do not make permanently disabling IPv6 the default recommendation, and do not change system-wide settings because of one problematic site. Domain-based routing and routing by the resolved address can produce different results, so check the final outbound too.

Clear caches only after fixing the path; otherwise, the same bad result may be cached again. On Windows, ipconfig /flushdns clears the system DNS cache, but not separate caches in browsers, the core and other apps. After making changes, restart the relevant connection or app and repeat the same test. With TUN virtual-address mapping, an existing connection may still use an earlier mapping. Do not draw conclusions from logs that mix connections from before and after a change. Stop the connection first, then test in a clean session.

System proxy not working: Check how the app connects

A system proxy is a set of proxy settings that the operating system makes available to apps; it does not force all network traffic through a proxy. Some apps read the system settings, some use their own, and some command-line tools only read environment variables. TUN routes traffic through a virtual network adapter instead, so it is a separate mechanism. First find out how the app you need to connect handles proxy settings, then choose the right configuration. One app ignoring the system proxy does not mean the node or core has failed.

Test the port before checking system settings

Turn off TUN and use the explicit proxy command in the first section to test the local listener. If that request also fails, troubleshoot the core and node before changing system settings. Once the explicit proxy works, select Set system proxy automatically from the v2rayN system proxy menu. Then open the operating system's network proxy settings and check that the address and port match the client. Some client listeners support both HTTP and SOCKS, while others listen separately. Do not enter a SOCKS-only port in a field that accepts only HTTP proxies.

After applying the settings, close and reopen the test app so it reads them again. Browser extensions, app-specific proxy settings and organization policies may override the system values; pause those overrides before comparing. If the system fields revert to an old port, check whether another network app is still running in the background. On a managed device, a policy may also restore the values periodically. Do not keep rewriting the registry or fighting to hold the setting. Identify its source first, so a stale proxy is not left behind when the client closes.

Tell routing problems apart from apps that never connect

If the log shows no request for the destination, the app may not be using the proxy. If the request appears but goes direct, check routing rules, bypass lists and the default outbound. System proxy exceptions may also bypass the proxy for local addresses or certain domains; this is separate from the client's own routing rules. For a test, temporarily remove the relevant custom exception, but keep system defaults. For LAN devices, printers and internal domains, decide the intended path first so fixing web access does not break local services.

If a command-line tool ignores the system proxy, test it with a one-off command-line option. If that works, decide whether proxy environment variables are appropriate. Environment variables may affect only the current terminal and child processes launched afterward; already-running apps may not pick them up. Some tools also distinguish variable names by case and protocol. Remove temporary variables when done so the terminal does not keep pointing at a local port after the client closes. Do not put proxy URLs containing credentials in public scripts or command-history examples.

Enable and verify TUN separately

Test TUN only when you need to route apps that do not read proxy settings. Save your current routes first, grant the permissions requested by the client and confirm that the virtual adapter is created successfully. Missing permissions, leftover adapters, other tunnel apps and network-filtering software can all interfere with traffic capture. The client's own outbound connection to the node must bypass the virtual adapter correctly; an incorrect auto-route can send it back into the tunnel and create a loop. Verify using a default policy supported by the client rather than adding broad static routes.

If enabling TUN also breaks local network access, turn it off immediately and check the default route, DNS and LAN bypass settings. After changing networks or resuming from sleep, a stale adapter index or route may no longer work; rebuilding the connection can help confirm this. Do not manually remove every virtual adapter while traffic capture is active. Stop the client normally first, then check for leftovers. If you need to restore system networking, record the original settings and undo only the changes made during this troubleshooting session, so other working network services are not affected.

Client crashes: Separate the UI from the core

A UI that will not open, a UI that crashes, and a UI that stays open while the core stops are different problems. The graphical client manages settings and starts processes; the core handles connections. One working does not prove that the other is healthy. Note whether the failure happens when the app starts, you select a node, update a subscription or enable TUN, and whether it reproduces every time. Do not delete the entire user directory as a first step: it may contain logs, subscriptions and configuration. Removing it loses evidence and makes recovery harder.

Check installation and runtime requirements first

Recheck your operating system and processor architecture on the download page. On macOS, distinguish Apple Silicon from Intel; on Linux, check the architecture and package format. For Windows, choose between the v2rayN desktop and classic WPF editions based on your system. Do not copy a program directory from one platform to another. If the program is distributed as an archive, extract it fully to a writable location before running it. Launching it from the archive browser may leave dependencies or the working directory unavailable.

Installed packages and portable builds may have different runtime requirements; follow the installer prompt and the current package notes. Do not download individual dependency files from unknown sources. If security software quarantines a file, review the detection record, file source and reason instead of disabling all protection as a general fix. The program may also be unable to save settings if it is in a protected directory, read-only media or a folder controlled by sync software. You can create a separate test environment in a user-writable directory and leave the original untouched.

For core startup failures, find the first relevant error

Check the core log in the v2rayN main window and look for the first error at startup, not just the final “process exited” line. Common causes include a port conflict, invalid configuration, missing core file, incompatible arguments or insufficient permissions. Access logs and startup logs serve different purposes: the former describe requests, while the latter explain why the process did not reach a working state. For more detail, see how to diagnose core startup failures from logs, but use the actual fields in your current log as the source of truth.

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

The command above uses Windows PowerShell to find the process listening on a specified TCP port; replace the port with the actual value. Some environments require appropriate permissions. After finding a process ID, use Task Manager to identify the program before taking action. Do not terminate an unknown system process. If it is another instance of the client, close the duplicate normally. If another service needs that port, change the client's listener and update the system proxy and app settings to match. Changing only the listener creates a new connection failure.

Use the field path in the log to troubleshoot a configuration error. Extra commas, incorrect quotation marks, wrong field types or unsupported options in custom JSON can prevent the core from starting. For a configuration generated by a graphical client, make the correction in the relevant settings screen first. Temporary configuration files are often overwritten at the next startup, so editing one is not a lasting solution. To understand how the fields relate, see a guide to configuration file structure. Do not replace your entire existing configuration with a snippet from an article.

Restore gradually instead of overwriting everything

If the UI keeps crashing, back up the configuration and logs first, then launch using a separate user directory or a new configuration environment supported by the client. If a clean environment starts, the cause is more likely to be an existing setting, window state or imported content. If it still fails, check the installation, dependencies and system events. During recovery, add one node and test it before restoring subscriptions, routing and other settings. Importing the entire backup at once may restore the setting that triggered the crash.

Exit the UI and core normally before updating; do not overwrite files while the process is running. If an update causes problems, keep the old directory as a fallback, but do not assume configurations are compatible across builds. Copy the data before trying to read it. Do not switch repeatedly between Xray and V2Fly to fix a startup error. First confirm that the features required by the node are supported by the current core. When reporting an issue, include the system, architecture, steps to reproduce and a redacted error. Hide node credentials, subscription URLs and personal directory names.

Mobile troubleshooting: Permissions, background activity and network changes

On Android, v2rayNG is the preferred client; v2flyNG is an alternative when you need a V2Fly core compatibility path. Their interfaces and supported settings are not necessarily identical, so check the client you are actually using. Mobile connections are more susceptible to battery policies, app-level routing and network changes than desktop connections. First distinguish between never connecting, disconnecting only when the screen locks, and failing on mobile data while Wi-Fi works. Follow the relevant path instead of attributing every issue to an unstable node.

VPN permission and active configuration

The first time you connect, the system usually asks for permission to establish a VPN connection. If you deny it or a device policy blocks it, the client may appear to start without actually capturing traffic. Start the connection again, read the system prompt and confirm that the app is authorized. A VPN icon only shows that the connection service is in some active state; it does not prove the remote server is reachable. Check that the intended server is selected and that the core reports a successful startup. Then verify with the built-in connection test or the same webpage in a browser, rather than relying on the notification text.

Android's VPN service generally cannot let multiple similar apps capture traffic independently at the same time. If another network filter, tunnel or proxy app is using it, stop that app normally before starting the current client. A system setting that keeps an older app always on or blocks connections outside the VPN can also cause problems after switching. Check which app is bound in the system VPN settings. Do not blindly clear data for other apps; restore any settings you change after testing so the device's network policy stays as intended.

If only some apps fail, check app scope

In the client's app-proxy or per-app settings, check whether it is set to proxy only selected apps or bypass selected apps. The two lists mean opposite things, so selecting an app icon does not necessarily mean its traffic goes through the proxy. Choose one clearly identifiable test app, stop and restart the connection so the app scope takes effect, and fully reopen the app if needed. If it uses its own DNS, a fixed address or a custom network component, use the logs to check whether its requests reach the client. A working browser does not prove that every app is routed through it.

If the connection drops when the screen locks, check system battery management, background activity and auto-start permissions first. Settings names vary by device; the goal is to let the current client keep running in the background, not to turn off power saving across the whole system. Leave the client's running notification enabled and watch whether the system stops the service. A missing notification, process restart and remote timeout are different kinds of evidence. On the same network and node, compare behavior with the screen on and locked. Record how long it takes to fail before deciding whether to add a battery optimization exception.

Test network changes and mobile data separately

When switching from Wi-Fi to mobile data, existing connections may fail, and DNS or the entry-point address may change. Stop the connection, confirm that the phone itself has working network access, then reconnect. If public Wi-Fi requires a sign-in page, complete its login first. An unauthenticated network may redirect subscription and connection requests to the login page. If only mobile data fails, check the active SIM's data access, usage limits and whether the client is allowed to use mobile data. Do not change the node protocol first.

Some mobile networks primarily provide IPv6 or use address translation, so a desktop IPv4 test alone cannot tell you how the phone's path behaves. Note the address family and resolution errors in the client log, and compare the same node on Wi-Fi and mobile data. Android Private DNS settings may also affect entry-point resolution. Temporarily restore automatic system DNS as a comparison, then restore the original setting afterward. Do not change the APN, DNS and node fields all at once; even if the issue clears, you will not know why, and you may break a data connection that was working.

For installation failures, check the package architecture and system prompt first. Most recent devices can use an arm64 build. If you are unsure, follow the Android download instructions to choose the right option. A universal package may be larger, but that does not make it more capable. When updating, keep a backup of the same client configuration; do not overwrite a v2rayNG backup with a full v2flyNG backup or vice versa. For transfers between devices, use a compatible subscription or node-sharing method. See how to migrate settings between desktop and Android for limitations.

Verify each layer in order: the app is included in traffic capture, the core receives the request, the node connects, and the destination responds. If a desktop and phone use the same node on the same Wi-Fi but behave differently, compare permissions, per-app scope and DNS. If both fail, return to the node and network path. When asking for help, include the OS version, client name, network type, whether the issue follows screen lock and a redacted error. A reproducible minimal setup is more useful than switching between several clients.