V2Ray Troubleshooting Guide

No Internet Access: Identify the Failing Layer

“Connected” usually means only that the proxy service has started; it does not mean every website is reachable. A request passes through the app’s proxy entry point, local listener, routing rules, DNS resolution, server connection and destination site. A failure at any step can leave your browser spinning. First narrow down the scope: do all apps fail, only the browser, or just one website? The answer determines what to check first. Avoid reinstalling or switching servers repeatedly without evidence.

Compare with the Client Off and On

In v2rayN, clear the system proxy setting and stop the proxy service. If virtual network adapter mode is enabled, turn it off separately. On Android, disconnect the VPN. Then try a website that normally works without a proxy and check whether the network requires sign-in. Campus, hotel and public Wi-Fi networks may require authentication before use; starting a proxy does not replace network login. If access still fails with the client off, fix the Wi-Fi connection, gateway or network account before troubleshooting the client.

Once the basic connection works, start the client and select a server with a complete configuration. Check the logs for configuration load failures, listener errors or process exits. An open v2rayN window does not mean its core process is still running; an Android service notification does not prove that requests work. If the log reports an error immediately after you start the service, troubleshoot the local service first instead of testing more websites. Access tests are meaningful only while the service is running reliably.

Check Whether Traffic Reaches the Proxy

On desktop, enable the system proxy, open a fixed page in a browser that follows system proxy settings and watch the access log. If no new request appears, check the browser settings, proxy extensions or the app’s own connection method. If a request appears but the connection fails, the entry point is likely working; check the outbound connection next. On Android, check per-app settings as well: excluded apps do not use the VPN, so they may connect directly even when other apps are proxied.

To isolate routing, briefly switch to a rule mode that sends the test traffic through the proxy outbound and open the same page again. In some clients, “Global” only changes routing; it does not enable system-wide traffic capture. Changing routes has no effect if traffic never reaches the client. If the test mode works but your usual mode does not, check domain rules, rule order and the default outbound. Restore your normal rules after testing rather than leaving a temporary diagnostic setup in place.

Keep a minimal working configuration

If the connection worked before, undo the most recent change first instead of resetting everything at once. Disable new routing rules, DNS settings, virtual network adapters and browser extensions one at a time, testing after each change. Note which step restores access, then rebuild only that configuration. After importing a new subscription, keep the old group for comparison until the issue is resolved. It can help distinguish changes to shared client settings from changes to the new server parameters.

Confirm recovery by checking that the page loads fully, remains accessible after reopening the browser, and that stopping the client returns the network to its expected state. One successful connection test is not enough to confirm everything is back to normal. To re-establish a clean baseline, return to the subscription import and first connection guide. For conceptual differences, see the FAQ to distinguish system proxy settings, routing modes and core startup.

Server Timeouts: Separate Connection from Handshake

A timeout means a step did not complete within the allotted time; it does not prove that the server is offline. A client’s test may measure a TCP connection or send a request through the proxy to a test URL, and those results mean different things. A port may accept a connection while authentication or transport fails afterward. A temporarily unavailable test URL can also make a working configuration appear to time out. Check real access alongside the log’s failure stage, and do not delete a configuration based on a single test result.

Check the Server Entry and Device Time

Open the server’s edit screen and verify that the address, port, protocol, transport and security settings all come from the same configuration. Copying and pasting can introduce spaces, and it is easy to enter a subscription URL in the server address field by mistake. The address field should not normally include a web path or protocol prefix unless it explicitly asks for a full URL. Use the port, user ID and password provided with the configuration; do not guess based on other entries. After updating a subscription, confirm that the selected entry is still valid.

Next, check your operating system’s date, time and time zone. A significantly incorrect clock can affect certificate validation and some protocol authentication. Enable automatic time synchronization, restart the proxy service and repeat the same request. If the log says a certificate is not yet valid or has expired, determine whether the cause is the device clock or the server certificate. Do not hide the error by skipping certificate verification: that changes the security boundary and cannot fix an incorrect server name or address.

Troubleshoot Based on the Failure Stage

A connection refused error usually means the destination rejected the connection or no service is listening on that port. A network unreachable error points to the local network, address family or routing. A timeout after waiting may involve packet loss, an unresponsive server or local security software. If the log reaches the TLS handshake, focus on the server name, security type and transport settings. Error wording varies by core, so keep the full context rather than copying only the last English word.

For VLESS and REALITY, also verify the public key, short ID, server name and any other fields required by the entry. For WebSocket, check the path and Host; for gRPC, check the service name. These values are not interchangeable extras, and a matching address and port do not mean two configurations are equivalent. Some subscription converters can drop fields. If that happens, retrieve a complete configuration rather than trying parameter combinations found online.

Cross-check the Network and Configuration

Keep the same server, destination page and client settings, then test on two available networks. If only one network fails, check its DNS, address family, authentication and access path. If all networks fail but other entries work, the current server or its settings deserve closer attention. Conversely, if every entry fails on one device but works on another, first check the local proxy entry point, clock, core status and security software rather than assuming all servers failed at once.

Protocol support also depends on the active core and how the client generates its configuration. A successful import only means the client recognized the link; it does not guarantee that the selected core supports every field. Before switching cores, confirm support for the entry’s protocol and transport, keep the original settings and test with the same request. For core families and configuration compatibility, see Xray Core vs. V2Fly Core. If the switch fails, revert it rather than layering more changes onto an unknown state.

If you need help from your configuration provider, explain whether the failure occurs during connection or handshake, whether it happens on only one network and whether other entries work. Share a redacted error message, not your full subscription or account details. After recovery, test a real page and reconnect once to rule out a one-off success. Treat the client’s list test as supporting evidence, not the final verdict.

Subscription Failures: Separate Fetching from Parsing

A subscription update involves at least three steps: fetching the content, parsing it and writing it to a group. A download failure usually points to the URL or network. If the fetch succeeds but no entries appear, the response may not be in a format the client accepts. If entries appear after the update but cannot connect, troubleshoot the server configuration instead. Separating these cases helps avoid deleting groups and losing useful information. Before you start, note the group name, update method and error time, and keep any working entries.

Check That the URL Is Still a Subscription Endpoint

When copying the subscription URL again, make sure the trailing parameters are intact and that no spaces, line breaks or punctuation were added by a messaging app. A subscription endpoint is not an account sign-in page; a page that opens in a browser is not necessarily subscription content the client can import. Some endpoints require an active account or authorization parameters, so an expired account, reset URL or changed data allowance can affect the response. Check the account through its original management channel. Do not submit the URL to an unfamiliar online converter.

Error codes can narrow down the cause, but avoid reading too much into them. Unauthorized or forbidden responses often involve permissions or endpoint restrictions; a not-found response may indicate that the URL changed; a server error may warrant trying again later. Even a successful status does not guarantee that the response contains configuration data: it could be a sign-in page, authentication prompt or maintenance page. If the client log reports an HTML parsing error, first check what the request returned. The core is not involved at this stage, so changing it is unlikely to help.

Check Which Network Path the Update Uses

Subscription downloads may connect directly or use an existing proxy, depending on the client’s update options. If the endpoint is reachable on your current network, try a direct update first. If it requires a proxy, you need at least one working configuration. If every entry is broken and the subscription also has to be fetched through one of those entries, you are stuck in a loop. Try a network that can reach the endpoint or obtain a valid configuration through the original management channel; repeatedly clicking Update will not resolve the loop.

For proxy-based updates, make sure the selected server can load an ordinary web page and that the local listening port has not changed. Some networks return an authentication page for subscription requests, so access to other websites in a browser does not rule out a problem. Use the same endpoint to compare a direct update with one through the proxy, and keep the path that works. If both fail, check the account status and server response rather than assuming the subscription format is corrupted.

Check Groups and Filters After Parsing

If the list looks empty after an update, clear the search box and type filters, then select the right group. Some clients remember the previously selected group, so new entries may have been added elsewhere without appearing in the current view. If the entry count changed, compare aliases, addresses and protocols rather than relying on sort order. A provider may replace old entries, and the client may reorder the list. Reconfirm which server is selected.

Resolve format compatibility at the source. A link that can be copied does not guarantee that the current client recognizes all of its protocols and transport fields. If import shows an unsupported-format message, check the client’s support range or request a compatible subscription format. Do not remove security fields just to dismiss an error; an entry may appear in the list but still be unable to connect without its required parameters. For Android import steps, see the subscription import guide.

After recovery, check automatic update settings for each group to avoid duplicate groups overwriting content at different times. Complete one manual update, connect using an entry and open a fixed page, then decide whether the old group is still useful. Frequent refreshes are not a substitute for troubleshooting; too many requests may trigger endpoint restrictions and make the error timeline harder to follow. If the subscription now fetches correctly but connections still time out, continue to the server timeout section. There is no need to keep changing the update method.

Slow Speeds: Measure the Bottleneck by Stage

Slow access can occur during DNS lookup, the initial connection, page resource loading or sustained transfers. A long blank screen before a site opens is different from a low transfer rate after a download starts. A latency test in the server list measures the response time of a particular request; it does not directly represent bandwidth, stability or performance across all sites. Use the same real-world task each time, such as opening one page or downloading the same public file, and identify which stage is slow.

Rule Out Local Network Issues and Background Traffic

Keep the device in the same location, pause system updates, cloud sync and other high-bandwidth tasks, then check the Wi-Fi signal and whether it keeps reconnecting. Other devices on a shared network may also be using the connection. If direct access is already slow, a proxy cannot fix wireless interference or congestion at your local network’s exit. If possible, compare a wired connection on desktop. On Android, compare Wi-Fi and mobile data, keeping an eye on data usage; there is no need to run large downloads continuously.

Change one condition per test. Use the same server at different times to check for changing load; compare two servers at the same time to check for route differences; use the same server with two websites to isolate a destination-specific issue. Do not switch servers, cores, routing and DNS all at once and then attribute the speed change to one setting. Record results for the same task and network conditions to avoid being misled by browser cache, background updates or one-off retries.

Use Logs and Resource Usage to Find the Cost

If a page loads quickly but images or video keep stalling, focus on packet loss, server load and the destination’s content delivery path. If the first visit is slow but refreshes are much faster, check DNS, the handshake and connection reuse. If only one site is slow while other sites work through the same server, the bottleneck may lie between the server’s exit and that site. Changing local protocol settings may not help; cross-check the site and server first.

On desktop, check CPU, memory and network usage in the system task manager. Low device resources, multiple proxy processes or overlapping virtual network adapters can add processing overhead. Debug logging also generates extra disk writes; return to the normal log level when you have finished troubleshooting. On Android, watch for heat and battery-saving behavior: sustained high load can change system scheduling, while issues that appear only with the screen off are better handled in the Android background section.

Measure Before Adding Complex Settings

Multiplexing, concurrency and transport settings are not universal speed boosters. Their effect depends on the protocol, server support, link quality and request pattern; mismatched settings can also break connections. Keep the subscription’s original parameters, change one setting only when you can explain what the test is meant to measure, and record how to revert it. In particular, do not copy configuration snippets that do not match your core: unsupported fields may be ignored or prevent startup.

Routing can affect performance, too. A website’s page and resources may use different domains, and sending them through different outbounds can make the site behave inconsistently. Temporarily use the same outbound for the domains under test, then refine the rules instead of sending all traffic the same way indefinitely. For the difference between system proxy settings and routing, see System Proxy Modes Explained. Identify where traffic enters before comparing the cost of each route.

Judge recovery against the original task, not a single test number. If your usual pages load reliably and sustained transfers no longer stall, there is no need to keep adding parameters. If one server or time of day remains consistently slow, record the reproducible conditions and ask your configuration provider to check the exit and load. Local client settings cannot guarantee more capacity on a remote link; a valid troubleshooting outcome may be confirming that the bottleneck is not on your device.

DNS Issues: Find Where Resolution Happens

DNS translates domain names into addresses, but in a proxy setup, the operating system may not be the only place resolution happens. A browser may use Secure DNS, the client may have its own DNS settings, or the remote server may receive the domain and resolve it itself. If changing system DNS makes no difference, the setting may have saved correctly while the request bypasses system resolution. Before troubleshooting, note the affected domain, time and app, then identify which layer handles its DNS lookup.

Tell DNS Failures Apart from Connection Failures

If the browser says it cannot find the server or the log reports a resolution error, DNS is a good place to start. If the log has already resolved an address but the connection to it times out, check the connection path instead. Not every domain access failure is a DNS issue. Replacing a website’s domain with its IP address is not a reliable test either: many sites rely on HTTPS server names and virtual hosting, so an IP request may show a certificate error or another site. That does not prove the original domain failed to resolve.

Use the same domain in two apps to see whether only the browser fails. Browser Secure DNS, proxy extensions and separate network settings may bypass the system path; temporarily restore settings that follow the system and test again. Then compare direct access with access through the proxy. If only the proxy path fails, check whether the client can reach its DNS server and which outbound it uses. If both paths fail, confirm that the domain is valid and the network has completed authentication.

Check for Dependency Loops and Address-Family Issues

One common dependency loop occurs when connecting to the proxy server requires resolving its hostname, but DNS requests are also set to use the proxy that has not connected yet. Another occurs when an encrypted DNS server uses a hostname but no bootstrap path is available to resolve it. If resolution keeps failing immediately after startup, check for these circular dependencies. Provide a reachable path for the initial lookup instead of adding DNS servers indefinitely. Configure the relevant fields and bootstrap mechanism according to the active core’s support.

Check IPv4 and IPv6 separately, too. A network returning an IPv6 address does not mean that the device has a reliable IPv6 route to the destination. If delays followed by fallback happen on only one network, temporarily adjust the address-family preference if the client supports it, then retest the same domain. Keep the change only if the results clearly point to the address family. Do not permanently disable IPv4 or IPv6 system-wide based on a single failure; that can affect other apps and local network services.

Match DNS Strategy to Routing Strategy

Domain-based and IP-based rules match different conditions. The following routing object snippet illustrates how to match domains and private addresses for direct access; it is not a complete client configuration and should not replace your existing setup. The example assumes that the configuration has an outbound named direct and that the core can read the relevant rule data. If the client generates its configuration automatically, edit the equivalent rules in its interface to avoid having your changes overwritten on the next start.

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

AsIs means routing matches the destination information already available; it does not resolve every domain into an address just to apply IP rules. It also does not mean DNS is never needed during a connection. If a rule uses IP conditions but the inbound request provides a domain, whether resolution occurs depends on the routing strategy. Before changing anything, decide whether you need to fix domain resolution or make a particular IP rule match. These are different needs and cannot be summarized by one “remote DNS” switch.

After making changes, restart the proxy service and reopen the test app. If needed, refresh the DNS cache using the method provided by your system. Browsers, operating systems and clients may all cache results, and one refresh may not clear every existing connection. Test the same domain again and see whether the error moves from resolution to connection. If resolution works but the destination remains unreachable, investigate the next layer instead of changing DNS again. For terminology, see the Glossary to distinguish DNS servers, query paths and routing outbounds.

System Proxy Not Working: Check the Capture Boundaries

A system proxy sets a proxy address in the operating system for apps to use, but not every program follows it. Routing rules handle only traffic that has already entered the client. Virtual network adapter mode is a separate capture path that needs its own permissions, routes and DNS settings. Choose one entry point to troubleshoot at a time instead of enabling several mechanisms together. Whether an app follows the chosen entry point determines what to check next. A routing mode shown in the client does not mean the system proxy is correctly configured.

Check the Listening Address and Port

In v2rayN, check the active local inbound type, listening address and port, then compare them with the operating system’s proxy settings. HTTP, SOCKS and mixed inbounds are not interchangeable just because their ports look similar; use the proxy type the app requires. A loopback listening address is accessible only from the local device. Do not change it to listen on all network interfaces just to fix a browser on the same device; that broadens who can connect.

If the log says the port is already in use, close an old client instance or another proxy program and start again. You can also change the local port in the interface, but update any apps configured manually to use it. The client may update the system proxy automatically; browser extensions, download tools and developer software with their own proxy settings will not follow automatically. Changing the client port without updating those apps is a common reason some programs work while others fail.

Understand Overrides Between the System, Browser and Apps

A browser may follow system settings, use a proxy set by an extension or load an automatic configuration script. Temporarily disable proxy extensions, check that the browser has no separate network override, then test again. Some apps do not read the system proxy and need an HTTP or SOCKS endpoint configured in the app itself; others connect through a separate network service. Browser access does not prove that every app will use the proxy, and one app connecting directly does not prove that the system setting is broken.

On Windows, different network components may read different proxy settings. On macOS, proxy settings are tied to the active network service, so check again after switching between wired and wireless connections. Linux desktop proxy settings also do not guarantee that every app will use them. If the problem occurs only after login, check that the client has started its core and that the system proxy points to a port that is still listening. For autostart, see Linux installation and desktop login autostart.

Test the Proxy Entry Point and Routing Separately

Make a request to a fixed website and check whether the corresponding destination appears in the access log. If there is no record, start by checking the entry point. If a record appears and is routed direct, check the rules. If it appears with a proxy outbound error, check the server. Logging may be disabled, or an app may reuse an old connection, so a new record may not appear immediately. Close the test page and reopen the app before trying again. Combine evidence rather than concluding traffic never entered based on one missing log line.

If you also use a virtual network adapter, turn it off first and test with only the system proxy. When testing the adapter instead, be explicit about whether the system proxy should remain enabled. Using both capture methods can cause duplicate forwarding, inconsistent exceptions or a different DNS path. Adapter startup failures can involve system permissions and driver status; switching routing modes repeatedly will not fix them. Grant only the permissions the client actually needs, and do not run all related programs with elevated privileges indefinitely.

After fixing the issue, test three states separately: enabled, disabled and after logging in again. With the client enabled, confirm that the test app uses the proxy. With it disabled, confirm that the app returns to the expected direct connection. After logging in again, verify that the port and startup state are correct. If other devices on your LAN need to use this proxy, plan the listening scope, access permissions and firewall rules separately; do not mix that requirement into troubleshooting on the local device. For the difference between system proxy settings and Global or bypass-mainland-China rules, see System Proxy Modes Explained.

Startup Failures and Crashes: Preserve the Error Context

A window that will not open, a core that exits while the window stays open, and an app that closes after running for a while are different problems. For startup failures, check the installer, runtime and permissions. If the core exits, check the configuration and ports. For crashes during use, also look at resource usage and what action triggered the crash. Note what happened between the last normal session and the first error, including updates, moving the app folder, changing settings and security alerts. Do not delete all data immediately and lose the clues.

Check the Platform, Architecture and Install Location

For desktop use, start with v2rayN and choose an installer on the client downloads page that matches your operating system and processor architecture. On macOS, distinguish Apple Silicon from Intel. On Linux, check both the package format for your distribution and the processor architecture. The Windows desktop and classic WPF versions are separate interface branches; check the requirements for the one you use. Matching package formats do not imply matching architectures. Whether the installer launches is unrelated to proxy settings, so get the program running first.

Install or fully extract the package as directed. Do not launch the app from a compressed archive preview or copy only the executable and leave out its associated resources. Store data in a writable location and check available disk space and folder permissions. If security software blocks or removes a file, review the system record to see which file was affected and why, then follow your organization’s or device’s security policy. Do not disable all system protection just to launch a proxy client, or download missing files from an unknown source.

Separate Interface Problems from Core Configuration Errors

If the interface opens but the client stops immediately after you connect, check the core log first. Common causes include invalid JSON, unsupported fields, a missing outbound tag, unavailable rule data and a port conflict. The error may identify the configuration location or relevant field; first revert the most recent addition. If the problem began after a subscription update, compare with an entry that worked before to see whether one entry fails to generate or all configurations fail.

The following log object snippet illustrates common log-level syntax in Xray and V2Fly configurations; it is not a complete startup configuration. If the client offers a graphical log-level setting, change it there. To capture more detail, temporarily enable debug logging, reproduce the issue once, save the relevant lines and return to the normal level. Leaving detailed logging enabled can increase disk writes and record more of your accessed destinations, so do not leave it on as a default troubleshooting setting.

{
  "log": {
    "loglevel": "warning"
  }
}

When editing configuration by hand, check quotes, commas and brackets. Standard JSON does not allow comments or trailing commas, and an explanatory snippet from a document may not be a complete configuration you can paste in directly. Temporary edits to client-generated files may be overwritten at the next startup, so look for the corresponding setting in the interface first. If you do not recognize a field, do not delete it just to make the client start; doing so may change authentication, security or routing behavior.

Isolate Corrupted Settings in a Reversible Way

If you suspect corrupted user settings, fully exit the client and confirm that its background process has stopped, then back up the configuration directory. Its location varies by platform, installation method and data mode. Find it in the client documentation or interface instead of deleting files based on a path found online. After backing up, test with a separate clean data environment. If the client starts, restore subscriptions, routing rules and interface preferences gradually to identify which type of setting triggers the problem.

A problem after an upgrade does not always mean you should downgrade immediately. First confirm that the package was deployed completely, no old process is still running and the new interface supports the configuration items you used before. If you need to roll back, keep backups of data from before and after the upgrade, and avoid having different branches write repeatedly to the same configuration. Reinstalling may not clear user data, so reinstalling the same program without checking settings can reproduce the same error. For client and branch differences, see Client Comparison.

After recovery, repeat the action that triggered the issue, such as updating a subscription, switching servers, opening routing settings or logging in again. When reporting the problem, include your operating system, architecture, installation method and redacted logs; do not expose your user data directory. If a specific configuration reliably triggers the error, describe its protocol and transport. If the app also crashes with an empty configuration, focus on the runtime environment and the program itself rather than conflating the two issues.

Android-Specific Issues: Permissions, Background Activity and Network Changes

For Android, start with v2rayNG, which uses the Xray core; v2flyNG, which uses the V2Fly core, is an alternative. In addition to servers and subscriptions, mobile troubleshooting involves VPN authorization, per-app rules, background restrictions and switching between Wi-Fi and mobile data. The VPN icon only indicates that a VPN connection exists; it does not prove that the proxy server can reach the destination. First confirm which client is actually running, then follow the steps in this section to compare results without mixing states from multiple apps.

Check VPN Authorization and Connection Conflicts

When you first connect, confirm the VPN authorization prompt from Android. If authorization was not completed, was canceled by mistake or is restricted by device management, the service may not start. Android’s standard app VPN channel generally cannot be controlled by multiple VPN apps at the same time. Stop other VPN tools first, including apps that use a local VPN for filtering, then start the client you are troubleshooting. Work profiles and managed devices may have additional restrictions; do not try to bypass device management by switching servers.

If Always-on VPN or Block connections without VPN is enabled, understand what happens when the proxy stops: Android may block other network access according to those settings. In that case, losing access after disconnecting does not necessarily mean the network is broken. Note the original policy, temporarily adjust it for comparison and restore the settings you need when finished. Check the system’s VPN settings to confirm which app owns the connection and which restrictions are enabled; do not rely only on the client’s button state.

Troubleshoot Disconnects After the Screen Turns Off

If access works while the screen is on but fails after the device has been idle, first check battery optimization and background activity restrictions. The names of settings such as “Allow background activity,” “Autostart” and “Battery optimization” vary by device; look for the equivalent controls in your system settings. Grant suitable permissions only to clients that need to stay connected instead of disabling power saving for every app. After changing settings, test with the screen on, with it off and after reopening the app. Check whether the service notification disappears or is recreated by the system.

Data Saver and background mobile data restrictions can also leave the service running while stopping transfers. Confirm that the client is allowed to use the network you are testing, especially after switching from Wi-Fi to mobile data. If each switch requires a reconnect, first check for an old connection that was not re-established or a changed DNS path rather than deleting the subscription. Toggling Airplane mode can serve as a comparison to refresh the network, but it is not a lasting fix.

Check Per-App Rules and Local Network Behavior

Per-app proxy settings may use an allowlist or a blocklist, which work in opposite ways. After changing the list, reconnect the VPN to apply the new selection, then test one app on the list and one off it. If the browser works but another app does not, check whether that app is included in the VPN and whether it has its own proxy or network settings. An individual app’s cache, account connection or destination service can also fail; changing routing for all traffic will not reliably identify the cause.

If LAN devices are unreachable, check whether local addresses are being sent through the proxy and whether the client has an option to bypass the LAN. Printers, network storage and router admin pages rely on the local network path; a remote proxy cannot replace it. Private-address rules, system VPN routes and app discovery can all play a part, so first test once with the VPN off and then re-enable settings one at a time. Broadening LAN listening permissions is not a universal fix for a phone’s local network access.

Validation Steps After Installation and Recovery

Choose an installer for your device architecture from the Android download page. If installation fails, check storage space, system installation prompts, processor compatibility and where the existing app came from. Do not uninstall immediately; this may delete subscriptions and custom rules. Before reinstalling, save the settings you need using a method supported by the client and protect any account details they contain. Choose a universal or architecture-specific package based on what your device actually supports.

After recovery, test ordinary web access, per-app behavior, background operation with the screen off and network switching in that order, using the same valid server at each step. If only mobile data fails, return to the DNS and timeout sections to compare network paths. If the problem occurs only in the background, continue checking system restrictions. For differences between clients, see v2rayN, v2rayNG and v2flyNG Compared. Once everyday use is stable, restore automatic updates and other custom settings, keeping a working configuration as a baseline for future troubleshooting.