v2rayN Troubleshooting Guide

No internet access: find where the connection is failing

“No internet access” could mean your local network is down, the app isn’t using the proxy, the core failed to start, or the remote connection is unavailable. First, note how widespread the problem is: do all apps fail, or just the browser? Do all sites fail, or only one domain? The scope determines what to check. Don’t update subscriptions, switch cores, and enable TUN all at once. Even if that fixes things, you won’t know which change helped.

Test your direct connection first

In v2rayN, select “Clear system proxy” and turn off “Enable Tun mode.” Then check that your system network settings don’t still have a manual proxy configured. Quit other proxy tools and reopen your browser to visit a site that normally works without a proxy. If it still won’t load, check your Wi-Fi or Ethernet connection, gateway, and network sign-in page first; the client is unlikely to be the cause. Public Wi-Fi may require web-based sign-in, which proxy settings can prevent from loading.

Once your direct connection works, start the client with TUN still off and test the system proxy on its own. If your entire internet connection drops when you quit the client, check whether a leftover proxy address still points to a local listening port that is no longer running. Clear the proxy and reopen the app so it doesn’t reuse an old connection. A cached browser page doesn’t prove your connection is back—refresh a page that actually needs internet access.

Check the active configuration and local listener

Make sure the list contains a usable configuration and select the one you want to test. A subscription group can exist without any nodes in it, and adding an address doesn’t mean it has been updated. Next, check the logs to confirm the core doesn’t exit immediately on startup. If configuration parsing fails, a port can’t be bound, or a resource file can’t be read, fix the local startup issue first. Repeatedly switching remote nodes won’t fix these errors.

Open the client’s basic settings and note the actual listening address, port, and protocol. The proxy port in your app settings must match—don’t guess based on a tutorial. Listening on a loopback address makes the proxy available to this computer only; that’s expected. If the logs say the address is already in use, identify the conflicting program or change the listening port, then update the app settings to match. Don’t change just one side.

Use a minimal test to separate the local entry point from the remote connection

Start with one browser, one test destination, and one active configuration. Set the system proxy to “Set system proxy automatically” and temporarily disable browser extensions that handle proxying. If the client logs a request to the test destination, traffic has at least reached the local entry point; next, check the routing rule and any remote errors. If no request appears, first check the browser’s own settings, whether the system proxy was applied, and whether the app bypasses the proxy.

Check whether the failed request was routed directly or through the proxy. If a rule sends the test domain DIRECT, a failure doesn’t prove the proxy node is unavailable. You can temporarily use an explicit proxy test route provided by the client, then restore the original routing. Don’t permanently send all traffic through the proxy or delete existing rules just to test. Reversible changes help prevent problems with local network access, work resources, or other apps.

Choose the next section based on what you find

If the local entry point works but the remote handshake fails, go to Node timeouts. If one domain fails while others work, see DNS issues. If the browser works but the terminal doesn’t, see System proxy. After each change, retest the same destination and note whether the error changed. For example, a connection refusal changing to a handshake failure means the problem has moved to a different stage—it’s not simply “still broken.”

Node timeouts: distinguish connection, handshake, and response failures

A timeout means a wait exceeded its limit; it doesn’t automatically mean the server is down. The connection, protocol handshake, DNS lookup, or destination response could each time out. Open the logs and find the first error near the time of your test, rather than looking only at the last line. An earlier DNS failure or connection refusal is often more useful than the timeouts that follow. Keep other network activity to a minimum so it’s easier to identify the relevant requests.

Know what your test actually measures

A TCP connectivity test usually checks whether a connection can be made to a specific address and port. It doesn’t verify authentication parameters, the transport path, or the destination website. A real request is closer to normal use, but depends on the test URL, DNS, and routing. If a test returns no result, don’t delete the configuration. Try a known destination in your browser and check whether the client logs that same request.

If every configuration fails at once, check what they have in common: the local network, system time, subscription parameters, and test destination. If just one fails, compare it with other configurations in the same subscription. Keep the network and test method the same; don’t mix results from different times or destinations. Running many concurrent tests may also trigger connection limits, so test configurations one at a time for clearer results.

Troubleshoot based on the stage shown in the logs

“Connection refused” usually means the destination address is reachable, but the port isn’t accepting connections or an intermediate device actively rejected the connection. Check the address and port, then ask the service provider to confirm the server is running. “Network unreachable” more often points to local routing, address family, or network egress. For a timeout, determine whether it happened before the connection was established or after the handshake began. Error wording varies between cores, so read it in context with the surrounding log entries.

For certificate, server name, or handshake errors, check the transport security settings, server name, transport type, and path. Some configurations intentionally use different connection addresses and server names; don’t change them just to make them match. For REALITY configurations, also verify that the public key, short ID, and fingerprint are complete. When possible, reimport the original link from the provider instead of guessing at individual settings.

Check the clock, address family, and network

Enable automatic date and time in your operating system, then verify the actual time is correct. A clock that’s off can affect certificate validation and some protocol authentication. Changing the time zone without correcting the clock won’t help. If the device just woke from sleep, wait for the network and clock to sync before restarting the client. Don’t disable certificate verification to hide a clock or server name problem; that weakens the connection’s security.

A node hostname may resolve to both IPv4 and IPv6 addresses. Having IPv6 connectivity doesn’t guarantee that the route to the remote server works, but IPv6 isn’t automatically the problem either. If the client supports address selection policies, temporarily restrict it to one address family and compare results, then restore the setting. Testing on another network you’re authorized to use can also help: if the results differ, investigate network egress routing instead of rebuilding every configuration.

Keep configuration details intact and send useful feedback to the provider

Refresh the subscription and test again to see whether the provider changed the address, port, or transport settings. If the same configuration keeps failing across different networks, send the provider its displayed node name, test time, failure stage, and a redacted log, and ask them to check the server. Don’t share authentication details or try combining passwords or identifiers from other configurations. Being able to select a core doesn’t mean every core supports the same extended parameters.

Once the node is working again, retest the actual service that failed—not just a connectivity test. If the handshake succeeds but one site still times out, check its routing, DNS, and server-side restrictions. See the glossary for protocol terms, and read the VMess vs. VLESS guide to learn how to identify each protocol. Understanding what a setting does before changing it is more effective than repeatedly switching options.

Subscription update failed: check the URL, request, and parsing separately

A subscription update has three stages: the client requests the subscription URL, the server returns content, and the client converts that content into a configuration list. A failure at any stage may show as “Update failed,” but each requires a different fix. First determine whether the request failed or succeeded but the content couldn’t be parsed. A group name alone doesn’t confirm the update worked, and don’t clear configurations that still work just to import them again.

Save the URL, then run the update

In “Subscription Group Settings,” make sure the URL is saved in full, then select “Update all subscriptions.” Adding a group doesn’t automatically add nodes. When copying, watch for spaces or line breaks at either end and punctuation added by chat apps. Don’t truncate URLs with query parameters. The example URL https://example.com/sub?token=xxxx shows the format only; use the unique URL provided by your service.

A subscription URL and a single-node share link are different things. An ordinary webpage URL or a logged-in account dashboard isn’t necessarily a subscription endpoint. Copy the URL from the provider’s explicitly labeled subscription page; don’t judge it by how it looks. If the URL has been reset, the old one may return an access denied error or no content. Replace it with the new URL instead of repeatedly changing the client’s parsing options.

Determine whether the request failed or the response was invalid

Check the status and error in the update log. For a hostname resolution failure, check DNS. For a connection timeout, check the network path to the subscription service. For a certificate error, verify the system clock and service domain. An access denied response usually means you should check subscription eligibility, expiration, or access restrictions. If the server is busy, repeated update attempts may worsen rate limiting. Wait, then try again, and keep the first error message.

A successful request doesn’t necessarily mean the server returned a configuration. It may return a login page, maintenance notice, or network sign-in page, none of which the client can parse. If you need to inspect the response, do so in a controlled local environment and don’t expose the full URL in public records. Opening a page in your browser only proves the browser got a response; it may use a different proxy, login session, or DNS path than the client.

Choose a working route for updates

If you can reach the subscription service directly, try a direct update first. If not, and the client already has a working configuration, use the update-through-proxy option in the interface; menu names may vary, so check your actual settings. If all existing configurations are broken, updating through the proxy creates a dependency loop: you need to connect to update, but you need to update to connect. In that case, get a new valid URL or a single-node configuration.

Note which route you used before updating, then check the logs afterward. Don’t assume that enabling the system proxy forces the client’s own subscription requests through it; the update module may have a separate network setting. Don’t submit an inaccessible subscription URL to an unknown online converter either. Subscriptions often contain credentials, which the converter can read. If format conversion is necessary, confirm who receives the data, how it’s handled, and which credentials may be exposed.

Check format compatibility and changes to the list after updating

If the response isn’t empty but the client says it contains no valid configurations, first confirm that the provider’s format is supported by your client. The client and core have different roles: the client parses the subscription, while the core runs the resulting configuration. Switching cores usually won’t fix a subscription format parsing issue. Choose a client for your system from the downloads page and test it separately with a backup; there’s no need to overwrite your working setup.

If the list shrinks after an update, the provider may have removed configurations, or a group filter may be hiding some. Clear the list filter first, then check the update result for that subscription group. Once you’ve confirmed the new entries work, you can clean up old ones. If you still need to compare results, keep only minimal, redacted protocol details and error messages. Don’t save or forward complete authentication fields.

Slow speeds: test throughput, response time, and app-specific issues separately

Slow page loads, video buffering, and slow large downloads aren’t necessarily the same problem. Page loads depend on DNS, handshakes, and many individual requests; sustained downloads depend more on throughput and congestion; real-time communication is also sensitive to jitter and packet loss. First pinpoint what’s slow, then choose an appropriate test. A response-time figure is only a result under specific test conditions—not a speed ranking for every use or a complete measure of service quality.

Compare results under consistent conditions

Choose a stable destination and compare direct and proxied connections on the same device and network, around the same time. Pause system updates, cloud sync, and other high-traffic tasks so background activity doesn’t saturate your upload bandwidth. On Wi-Fi, check signal strength, band, and router load; being close to the router doesn’t rule out interference. If possible, use Ethernet as a baseline to rule out local wireless issues first.

Compare only two configurations at a time, keeping routing and DNS the same. Don’t run multiple speed tests at once or draw conclusions from a single outlier. Speed tests use real data, so keep them small if your service has a data cap. If everything slows down at certain times and recovers later, tracking when it happens is more useful than reinstalling repeatedly. The cause may be network congestion or server load.

Check the actual route and destination service

First confirm that the slow request is actually using the intended proxy. Routing rules may send a page and its resources through different routes, so the text loads while images hang. Find the specific domain that failed in the logs and check for repeated retries or resources that always go DIRECT. A page eventually loading doesn’t rule out timeouts—the browser may wait for several resources before it finishes.

If only one website is slow, consider the site itself, its content delivery network, and account restrictions. Changing the proxy exit may change which server handles your request, but there’s no guarantee it will help. If normal pages are fast but one download source is slow, compare with another legitimate download source or a different file on the same site. Adjusting the local listening port won’t fix a destination-side speed cap, and client settings can’t exceed the actual network bandwidth.

Check connection reuse, UDP, and network path issues

Multiplexing changes how connections are organized; more isn’t always faster. Results depend on server support, packet loss, and the type of app. For diagnosis, keep the default or provider-recommended setting. If you suspect multiplexing, disable it by itself and compare. Don’t copy parameters from a different core: implementations and supported fields can vary even when the names match, and an invalid setting may prevent the core from starting.

A browser may try a UDP-based transport that behaves differently from TCP on your current route. If only certain apps have issues, temporarily test another transport if the app supports it; don’t disable UDP system-wide straight away. If large downloads stall with TUN enabled while ordinary pages work, path MTU may be involved. Test it in your own network environment instead of applying one fixed value to every device.

Make changes only when the results are repeatable

If reducing concurrency makes things noticeably more stable, investigate connection limits and congestion. If the first request is slow but later ones are fast, check DNS and the initial handshake. If things slow down after the screen locks or the device wakes from sleep, check the network adapter and client reconnection. Each symptom points in a different direction. A brief record of the destination, time, route, transport, and result is more useful than a single speed-test screenshot.

Keep changes that produce repeatable improvements and restore everything else. There’s no universal set of network optimization settings; changing many at once makes comparisons impossible. To investigate DNS routing, continue to the next section.

DNS issues: find out which resolver is used and how queries are routed

DNS translates domain names into addresses, but a proxy setup can involve more than one resolver. Your operating system, browser, client core, and remote proxy may all play a role. A browser error saying the domain can’t be found only tells you that one stage failed to return a usable result. First determine whether the node server’s hostname or the destination website’s hostname failed to resolve. The former prevents the proxy from connecting; the latter usually occurs after the proxy is running. They need different fixes.

Compare system DNS with DNS handled by the proxy

In a Windows terminal, you can use the system command below to check whether the destination hostname gets a response. The example domain is for illustration; replace it with the one that’s failing. Record the responding server, address family, and error. Don’t assume the DNS path is correct just because you see an address: different resolvers may return different content delivery addresses.

nslookup example.com

A successful system lookup doesn’t mean remote DNS in the core is working. A failed system lookup doesn’t mean the proxy can’t work either; some requests send the domain to the remote end for resolution. Next, check DNS requests and the resulting connection address in the client logs. If the browser has its own secure DNS setting, note that too. For a comparison, temporarily use one clearly defined DNS path, then decide whether to restore the browser’s original setting.

Avoid circular DNS dependencies

With encrypted DNS, the resolver may need to resolve a hostname and connect before it can send a query. If the resolver is only reachable through the proxy, but the proxy server’s hostname also depends on that resolver, the connection can get stuck in a dependency loop. Make sure the node hostname has a bootstrap resolution path that can work before the proxy is connected. Setting names and configuration structures vary by core; don’t mix fields from different ones.

Check that the client’s local DNS, remote DNS, and routing settings work together. Sending a DIRECT destination to a resolver you can’t reach directly, or using a system DNS response that doesn’t suit the current network for a proxied destination, can cause problems. Reconnect after making changes so old cache entries don’t skew the result. Clearing the browser cache won’t clear DNS results at every level; restart the client and affected apps if needed.

Understand TUN routing and local network names

TUN can capture more traffic, but that doesn’t mean all DNS requests follow the same policy. Check whether DNS interception, the virtual adapter, app exclusions, and routing rules are working. If an app uses its own encrypted DNS, ordinary DNS interception may not catch it. Don’t rely only on the TUN toggle—check the logs to confirm the request entered the core and which resolver handled it.

Printers, file servers, and workplace networks may rely on local DNS or specific search domains. Forcing every query to an external resolver can break these names. Preserve the DNS path for your local network and organization’s internal domains, and follow your network administrator’s settings. A DIRECT rule for private IP addresses isn’t enough: if an internal hostname fails to resolve, the request never reaches address-based routing.

Check both resolution and privacy boundaries

Loading a website successfully and resolving DNS as intended are two separate goals. An online test page shows only some of the queries triggered by that page, not every app on your device. The resolver’s location also doesn’t necessarily match your network’s actual exit location. Check browser settings, core logs, and app behavior together. A single region label on a test page doesn’t prove either a leak or a fix.

After fixing the issue, test an ordinary domain, the one that originally failed, and any local network names you need. Check whether IPv4 and IPv6 behave differently. Record the resolver and route before and after changes so you can reproduce the result if you switch networks. For more detailed steps, see DNS leak testing and configuration. Choose settings based on your current core and interface.

System proxy not working: troubleshoot browsers and terminals separately

A system proxy is a network setting that apps can choose to use; it doesn’t force all traffic through a proxy. An app may follow it, use its own proxy, or connect directly. So it’s entirely possible for a browser to work while a terminal doesn’t. First find out which proxy method the affected app uses, then check the local proxy address and port. Routing and node settings matter only after the request reaches the client.

Check the three system proxy modes

“Set system proxy automatically” lets the client configure the system proxy according to its settings. “Clear system proxy” removes the relevant proxy settings. “Do not change system proxy” means the client leaves the current state alone; it doesn’t clear the proxy. If another program has set one, it may still be there. Open your operating system’s network settings to verify the actual value instead of relying only on the client menu.

After changing settings, reopen the app you want to test; some apps read the proxy only at startup. If the interface says the setting changed but the system value didn’t, check permissions, organization policies, and whether another proxy app immediately overwrote it. Follow organizational requirements on managed devices instead of forcing a change. Don’t let two clients continuously write to the system proxy; that can cause seemingly random changes and connection failures.

Check browser-specific settings and extensions

Disable browser extensions that handle proxying, then check the browser’s own network settings. Some browsers can use the system proxy or specify a separate one. An old PAC URL, manual proxy, or bypass list can redirect traffic. Comparing with a fresh browser profile is more reliable than using a private window, since some extensions and policies can still apply in private mode.

Look for bypass rules such as “Don’t use proxy for local addresses”; they can send some destinations directly. That’s usually appropriate for local network resources, so an absent log entry doesn’t automatically mean the system proxy is broken. To test the proxy entry point, choose a destination that isn’t on the bypass list. Note the browser’s own DNS setting too, or you may see different results with the same proxy settings.

Make the terminal use the correct protocol explicitly

Command-line tools vary in their support for the system proxy. You can use an explicit proxy option for a one-off test. The example assumes the local HTTP listener is actually set to 127.0.0.1:10809; before running it, replace this with the actual HTTP or mixed listener port shown in the client. This is an example, not a default port. In Windows PowerShell, use curl.exe to invoke the intended program explicitly.

curl --proxy http://127.0.0.1:10809 --head https://example.com

For a SOCKS listener, use the SOCKS proxy option supported by your tool. socks5h usually sends domain resolution to the proxy, while local resolution behavior for socks5 depends on the tool—check its documentation. Don’t enter an HTTP proxy address in an option that accepts only SOCKS. Also check for stale values in http_proxy, https_proxy, ALL_PROXY, and NO_PROXY.

Understand TUN and local network sharing

For apps that truly ignore proxy settings, you can test TUN after understanding its effects. Desktop clients usually need administrator privileges or equivalent authorization; also check the virtual adapter and default route. Turn off other VPN or traffic interception tools to avoid routing conflicts, but don’t disable connections required by your organization. TUN won’t fix incorrect node parameters and isn’t a guaranteed replacement when the system proxy doesn’t work.

To share a computer’s proxy with a phone, don’t enter the phone’s own loopback address. Allow LAN connections on the computer, then enter the computer’s local network address and the correct port on the phone. Allow firewall access only on the trusted networks that need it. See the LAN proxy sharing guide for details. For a complete browser and terminal comparison, see How to troubleshoot a system proxy that isn’t working. Remove any test environment variables you no longer need afterward.

Client crash: distinguish the app closing from the core stopping

A disappearing window, an exited process, and a stopped core are different problems. First check the taskbar notification area and system process list: closing a window may simply hide the app in the tray. If the interface is still open but the proxy has stopped, the core may have failed to start. Note whether the issue occurs at startup, while importing a configuration, when switching nodes, or after waking from sleep. The triggering action is more useful than simply calling it a “crash,” and points to whether you should check the runtime environment, configuration, or permissions.

Back up your data before testing in a separate environment

If the interface opens, use the client’s export or backup feature to save subscription groups and essential settings. If it won’t open, copy the existing user data before troubleshooting; don’t delete the entire folder. Configurations may contain credentials, so keep backups somewhere secure. When migrating or testing, don’t let two instances use the same data directory at the same time. They may be writing to it simultaneously, causing locks or data conflicts.

Choose a package that matches your operating system and processor architecture from the downloads page. The Windows desktop version uses a cross-platform interface, while the WPF version retains the classic interface. You can compare them to check for interface compatibility, but that doesn’t mean node parameters have changed. For a separate test environment, start without importing all your old settings. Add one known-working configuration, confirm the client starts, then restore other settings gradually.

Check system requirements and file permissions

Before starting, make sure you have enough disk space, your user directory is writable, and any required runtime dependencies have been installed. Being able to read the installation directory doesn’t mean the log, cache, and user configuration directories are writable too. If the logs show a permission error, identify the specific path instead of loosening permissions across the whole drive. If security software quarantines a file, check why it was flagged and where it came from. Disabling all protection isn’t a long-term fix.

If a Linux desktop app won’t start, run its installed launch command from a terminal to check for missing libraries, graphical session issues, or permission errors. Use the actual launcher for your installation; don’t guess the binary path. On macOS, follow the normal system authorization flow for app launch warnings instead of disabling system protection entirely. See the Linux installation and autostart guide for platform-specific details. Get manual startup working before setting up autostart.

Use the first error to diagnose core failures

If the interface opens but the core exits immediately, start by checking for configuration parsing errors. The message often includes a field name or nearby location. The cause may be an unsupported parameter, incomplete import, or invalid custom setting. Revert the most recent change first, then restart the core. Project V, V2Fly, and Xray are related projects, but their configuration structures and capabilities aren’t identical. Don’t assume any configuration snippet will work across cores without changes.

A port conflict, unreadable resource file, or insufficient permissions can also stop the core. For a port conflict, close the duplicate instance or change the listening port. For a resource file error, check that the app is fully installed, the path is readable, and any built-in update completed successfully. Don’t assemble core files from untrusted sources. For TUN errors, turn TUN off first and confirm the regular proxy works, then troubleshoot authorization and the virtual adapter separately.

Restore settings one at a time to avoid reintroducing the problem

Once the separate environment works, restore subscriptions, routing, custom DNS, and TUN one at a time, restarting and testing after each change. If the issue returns after importing a group of settings, compare that group with the clean setup instead of reinstalling over it. If you see a database lock or configuration corruption warning, keep the original backup and use a recovery method supported by the app. Don’t edit data files directly unless you understand their structure.

If the problem occurs only at startup, check whether the app launches before the network is ready, uses a different working directory, or runs with different permissions. If it happens only after sleep, wait for the network to recover before restarting the core. When reporting the issue, include the system architecture, package type, steps to reproduce, and redacted error excerpts; don’t publish the entire configuration. After the client recovers, check that the system proxy still points to an active listener so apps aren’t left connecting to a local endpoint that no longer exists.

Android troubleshooting: permissions, app routing, and background disconnects

On Android, v2rayNG is the primary option and uses the Xray core; v2flyNG is an alternative client using the V2Fly core. Their interfaces and supported parameters may differ, so switching apps won’t automatically fix a configuration. First note the device’s Android version, client name, connection method, and when the problem occurs. Then determine whether you can’t connect at all, one app fails, or the connection drops when the screen turns off. Each symptom needs a different troubleshooting path.

Check system permissions and make sure only one app is handling traffic

When connecting for the first time, grant permission to establish a VPN connection when prompted by Android. If the prompt doesn’t appear or you denied it, check the relevant system settings and try connecting again. Android generally doesn’t allow ordinary apps to take over the same user’s connection at the same time, so check whether another traffic-routing tool is running. Work profiles and device management policies may also restrict availability; follow your organization’s requirements.

A connection icon in the system status bar only confirms that the network service is active; it doesn’t prove the remote node is working. Open the client logs and visit a known destination to check whether a request arrives and the remote handshake succeeds. If all apps fail, test the local network and active configuration first. If just one app fails, check app routing, its own DNS, or its proxy settings before resetting all your data.

Troubleshoot screen-off, background, and network switching issues

If the connection works in the foreground but drops when the screen turns off, check battery optimization, background activity limits, and your device manufacturer’s app management rules. Use the system’s settings to allow the client the background activity it needs, then check whether its notification and process remain active. Menu names vary between devices, so don’t rely on one fixed set of steps. Disabling background restrictions can increase battery use; only change them for apps that need a persistent connection.

When switching from Wi-Fi to mobile data, the existing connection may need to be re-established. Wait for the new network to get an address, then stop and restart the client connection and see if it recovers. If it fails only on one network, compare DNS, address family, and network sign-in requirements instead of immediately changing protocols. With “Always-on VPN” or blocking connections without a VPN enabled, an unavailable node may make the entire device appear offline. Understand what the setting does before changing it for diagnosis.

Check app routing and DNS settings

App routing may offer options to proxy only selected apps or bypass selected apps. The same app list can produce opposite results depending on the mode. Confirm the current mode, check whether the target app is selected, save the change, and reconnect if needed. An app update, work-profile copy, or different installation source may have a different app identifier. Matching icons alone don’t prove the rule applies to both apps.

If websites work but one app consistently fails, check whether it relies on UDP, uses its own encrypted DNS, or is restricted by the destination service. Android Private DNS and the client’s DNS settings may both affect resolution, so change one at a time and compare. If local network device discovery fails, check the DIRECT rule for private subnets and local name resolution. Bypassing the proxy doesn’t automatically restore every broadcast-based discovery feature.

Install packages, update subscriptions, and verify recovery

Choose the package for your device architecture from the Android downloads. Most newer devices use arm64, but check your device architecture to be sure. If you’re not sure, check the system information or use the universal version offered on the page. Install failures can also result from OS compatibility, insufficient storage, a different app signature, or downgrade restrictions. Don’t keep downloading the same file without checking. Back up your settings before replacing an existing app so you don’t lose subscriptions and app routing rules.

For a failed subscription update, use the three checks on this page—URL, request, and parsing—and don’t confuse clipboard permission issues with a server response error. After recovery, test in the foreground, after waking the screen, and across Wi-Fi and mobile data. Confirm that apps requiring the proxy and those that should connect directly both behave as expected. Keep only settings that work and remove temporary test rules. For everyday setup, return to the quick start guide; for general questions, see the FAQ.