VPN issue troubleshooting guide

Separate account, subscription, and route issues

After opening the client, do not immediately switch through many routes. First check whether the route list loads normally, whether the subscription has a name, whether traffic information can be read, and whether the client explicitly says the subscription is invalid. A completely empty route list usually points to subscription import or update issues. If routes are present but none connect, investigate network permissions and connection protocols. If only a few routes fail, narrow the issue to route selection rather than resetting the entire client.

Sign in to the user panel to check the current service status and confirm that the imported subscription is the latest one provided there. Do not copy subscription content manually from chat history or between old devices, as older text may lack subsequently adjusted route information. After changing plans, update the subscription manually in the client and select a route again. EQVPN monthly subscription traffic resets each month on the activation date, and an upgrade price difference is prorated across the remaining days. Plan status and the client’s local cache are separate; a normal panel does not mean the client has synced the latest content.

Check system permissions and the local network

When establishing a connection, the client may need to create a system network interface or write proxy settings. Windows and macOS may ask for system permission; mobile devices show a network configuration authorization prompt. If permission was previously denied, repeatedly pressing Connect usually will not restore it. Open system settings to check the relevant permission, then fully quit and reopen the client. Linux users should also confirm that the current account has the permissions required for network configuration and check client logs for interface creation failures, route write failures, or permission-denied messages.

Next, confirm that the underlying network is working. Temporarily disconnect the accelerated connection and open a website that normally works directly. If ordinary websites also fail, restore the current Wi-Fi, wired, or mobile connection before changing the subscription. Public networks may require browser authentication; if the sign-in page does not appear, disconnect and rejoin the network, then open a normal website to trigger it. Corporate, campus, and hotel networks may restrict certain connection methods. Testing on another known-working access network is more informative than continuing to change client parameters.

Expand testing beyond a single route

When choosing a route, start with one that matches the use case and is reasonably close geographically; do not rely on its name alone. Wait for the client to clearly report success or failure before trying the next one. Once connected, test an ordinary website first rather than a high-volume app or HD video. After ordinary browsing works, gradually test the real task. This separates “cannot connect” from “connected but a particular service is unavailable.”

If every route fails on one device across different access networks, while another device using the same account connects, the issue is likely concentrated in the original device’s client permissions, leftover proxy settings, or security software rules. First exit other network tools, restore the system proxy to automatic mode, and restart the client. Re-import the subscription only when the configuration is clearly damaged, the route list cannot load, or logs repeatedly show local file errors. Uninstalling and reinstalling should be a later step because it removes logs and configuration evidence that could help identify the problem.

If you still cannot connect after completing the comparisons above, record the client’s original error, platform, access network type, route names tried, and whether other devices work normally. Do not write only “it won’t connect”; without the failure stage, support cannot distinguish subscription, permission, network restriction, and route issues.

First determine whether every website is affected or just one destination

After connecting, test an ordinary website, a different site on another domain, and then the original destination. If no websites open, check the system proxy, DNS, and client operating mode first. If only one site fails, the more likely causes are the target service’s status, regional requirements, browser cache, or an unsuitable route. Do not delete the subscription because one site fails, and do not treat a browser certificate error as a speed issue.

Test the same website in a private browser window as well. A regular window may retain an old sign-in region, site cache, service worker, or extension rule; a private window can quickly rule out some browser state. If the private window works, clear that site’s data and disable extensions that may alter requests. If every browser fails, return to the system network layer. Different browser results usually mean the accelerated connection is established, so the route itself may not be at fault.

Check whether the system proxy has been overridden

Some clients work through the system proxy, while others take over traffic through a virtual network interface. If another network tool, browser extension, or enterprise management app changes proxy settings at the same time, the client may show connected while requests still go to an old port. Fully exit other proxy tools and check whether the current client manages the system proxy. Do not manually enter an unknown local address or enable multiple automatic configuration scripts at once.

On Windows, check proxy status in the system network settings. On macOS, inspect proxy entries in the detailed settings for the current network service. Linux desktop environments may also have both desktop proxy variables and terminal environment variables. If terminal programs can connect but graphical apps cannot, or vice versa, the two proxy entry points are often inconsistent. Identify whether the client uses the system proxy, a virtual interface, or an in-app proxy, then configure the target program to use the same method.

Use a minimal request to distinguish resolution from transport

Command-line tools temporarily remove many browser-specific factors. The commands below access an example domain and contain no account information or real subscription URL. If the domain cannot be resolved, go to the DNS section. If it resolves but the connection times out, continue checking the route, system proxy, and access network. If the command line works but the browser fails, focus on browser cache, extensions, and security policies.

nslookup example.com
curl -I https://example.com

Keep the connection state consistent before and after running a command. Do not switch routes while repeating commands, or you will not know which conditions produced each result. The returned address may vary by network; focus on whether resolution completes, whether the connection times out, and whether certificate or proxy errors appear. If the terminal inherited an old proxy environment variable, reopen it and test again so the old session does not keep using a closed local port.

How connection mode and routing rules affect access

Rule mode normally sends only matching requests through international routes while leaving the rest on their original path. Global mode helps determine whether rules are missing a match. If a site fails in rule mode but works in global mode, the basic connection is probably fine; check the rules, domain matching, and the app’s connection method. Use global mode only briefly for diagnosis, not as a long-term setting without understanding its scope. Restore the original mode afterward and verify the required destination again.

If a page stays blank, images fail to load, or sign-in loops after the page opens, its resources may come from several domains while only some take the correct path. Browser developer tools can show failed-request domains, but you do not need to modify website code. Record the failed domains and error types, then confirm that related domains are handled consistently in the rules. For Streaming, use the routes page to choose a suitable region. For long-lived connections in AI coding tools, read Cursor route selection notes.

If ordinary websites, different browsers, and command-line requests all fail after these steps while client logs still show an established connection, preserve the logs and submit a support ticket. Include the connection mode, affected scope, route, and original error so support can determine whether local requests are not entering the proxy, DNS is returning no result, or the route to the destination is abnormal.

First define what kind of task feels slow

If pages open slowly but large downloads remain stable, common causes include DNS resolution, initial connection setup, or a slow target response. If a download starts quickly and then drops, the access network, target-service throttling, or congestion may be involved. If video loads but repeatedly lowers quality, watch the stability of continuous transfer. For choppy meetings or broken audio, focus on jitter and packet loss rather than peak bandwidth. Define the task first so you can choose a suitable route instead of reducing every experience to “slow.”

During testing, stop other apps that are syncing files, updating the system, or playing video. EQVPN supports unlimited devices, but multiple devices transferring large amounts of data still share the capacity of the home, office, or mobile network connection. Unlimited devices describes the usage condition; it does not mean the access network has unlimited capacity. If performance recovers after stopping other transfers, manage local network usage before changing routes.

Create repeatable comparison conditions

For speed troubleshooting, keep the device, access network, task, and test period fixed; change only the route. Complete the same task on a nearby route suited to the use case, then switch to another route in the same region for comparison. Do not compare results after switching continents, destinations, and devices in succession. Too many variables make every conclusion unreliable. Similar route names do not guarantee identical paths; focus on stable performance for the same task.

If performance is normal during the day but clearly slower in the evening, check the local access network and international route separately. Disconnect the acceleration connection and see whether ordinary browsing also slows at the same time. If the underlying network also degrades, home broadband, wireless conditions, or upstream congestion may be the main cause. If the underlying network is normal but a particular route slows, switch to another route for the same use case and record the time. One isolated slowdown is not enough to judge a route’s long-term condition; submit route feedback when the issue recurs under the same conditions.

Wireless conditions and device state can create misleading symptoms

A full wireless signal does not mean there is little interference. Distance from the access point, walls, dense Bluetooth activity, background power-saving policies, and network-driver status can all affect sustained transfer. Compare from the same location using a wired connection or another device. If another device works normally on the same route, inspect the original device’s wireless conditions, system updates, power-saving mode, and security software instead of repeatedly changing the subscription.

Mobile networks also change with location and cell-site load. Do not directly compare indoor mobile results with fixed broadband, and do not treat a brief handoff while moving as a route failure. If fluctuations continue in a fixed location, test again on another access network. If client logs frequently mention interface recreation or network changes, move to the frequent-disconnects section rather than continuing speed comparisons.

Traffic status and plan selection

When the client behaves unexpectedly, sign in to the panel and check traffic status as well. Monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly on the activation date, and an upgrade price difference is prorated across the remaining days. There are also pay-as-you-go traffic bundles that never expire: ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. Visit the plans page to compare usage conditions; do not infer current status from an old display in the client.

If only a specific use case remains slow while ordinary browsing works, use the route guide to switch routes by region and scenario. For remote meetings and collaboration, see remote-work route selection. When submitting a speed ticket, include a reproducible task, time period, and comparison route instead of saying “everything is slow,” which does not narrow the scope.

Distinguish a real disconnect from an interrupted app session

If the client still shows connected but an app asks you to sign in again, the accelerated connection may not have dropped. An app session can end because of a route change, an exit-region change, its own timeout, or server status. Open an ordinary website first to verify the overall connection, then check whether the client recorded a reconnection. If websites and other apps work, investigate the target app’s sign-in and regional policies. Treat it as a network disconnect only when all requests stop at once and the client status changes.

Do not enable automatic switching and stop observing when disconnects recur. Automatic switching may restore the visible connection quickly while hiding repeated rebuilding of the original route, access network, or system interface. During diagnosis, keep one route fixed and record what happened between connection and interruption: whether the device locked, Wi-Fi changed, the device moved indoors or outdoors, it woke from sleep, or another network tool started. The event sequence is more useful than saying “it always drops.”

Mobile background policies

Both iOS and Android manage background activity, but the exact settings vary by system and device manufacturer. Allow the client to maintain the required network configuration, remove excessive power-saving restrictions for that client, and confirm that the system does not actively clean it up after the screen locks. Do not disable every security and power-saving feature on the device; adjust only items directly related to the client. After changing settings, reopen the client, connect, lock the screen for a realistic period, then return to check the status.

If the connection is stable in the foreground but drops after the screen locks, focus on background policies. If it also drops while the screen is on, continue checking network changes, routes, and the system interface. Switching between mobile data and Wi-Fi changes the underlying address and requires the connection to be rebuilt; a brief interruption is a network event to observe. If the client does not recover automatically, reconnect manually after the switch completes and include this condition in the ticket instead of broadly reporting that mobile use is unavailable.

Desktop sleep, network adapters, and security software

After a desktop wakes from sleep, the network interface may recover later than the client. The client can retain an old state while the actual path has failed. Wait for the system network to recover, then disconnect and reconnect. If it happens after every wake-up, quit and restart the client for comparison. On Windows, check network-adapter power-saving settings. On macOS, confirm that another configuration tool is not repeatedly rewriting the current network service. Linux users can inspect system network-manager logs for interface reconnections at the time of the drop.

Security software may reassess an interface created by the client after the network environment changes. If frequent disconnects began after installing or updating a security tool, check its network rules and event log rather than disabling all protection. Allow the access required by the current client and test again, keeping results from before and after the change. On managed corporate devices, rules may be pushed by an administrator; if you cannot change them, first confirm that the management policy permits the connection.

Rule out access-network changes

At a fixed location, use a stable access network for a real task over an extended period without moving the device or switching networks. If it stays stable under fixed conditions but drops while moving, the issue is mainly related to network handoffs. If it still drops under fixed conditions, test another route in the same region. If multiple routes drop during similar actions, inspect client logs and system events. This sequence separates mobile handoffs, single-route issues, and local client problems layer by layer.

If disconnects occur only while one app is handling calls, livestreams, or long-lived connections, also test an ordinary website and another sustained-connection task. A single-app drop may come from the app’s networking implementation, routing rules, or background restrictions and should not immediately be classified as a route failure. If every app stops at once and logs show a closed connection, missing interface, or network change, submit the relevant text exactly as shown instead of only the final line.

When contacting support, provide the platform, access network, route name, foreground or background state, whether the screen was locked or the device was asleep, whether other routes reproduce the issue, and the complete relevant section of the client log. If logs contain personal subscription information, submit them through a user-panel ticket rather than publishing them. EQVPN’s user panel includes a ticket entry in the signed-in support area.

Confirm the source and account status first

Get the subscription from the user panel. Sign-in requires a username and password, while registration does not require an email address. If the subscription came from an old note, browser history, or another device, return to the panel and copy it again or use the client’s supported import entry. Do not display complete subscription content on public pages, forums, or screenshots, as it may contain account-delivery information.

Confirm that the panel opens normally and check the current plan and traffic status. If the panel itself cannot be accessed, resolve the account issue first. If the panel is normal but the client update fails, focus on local cache, subscription-address retrieval, client network permissions, or the current access network. Monthly subscription traffic resets each month on the activation date, and an upgrade price difference is prorated across the remaining days. Old client cache cannot tell you when the plan changed; use the panel display as the source of truth.

Understand common failure stages

An update can be divided into reading the subscription address, sending the network request, receiving the configuration, parsing it, and writing the local configuration. A network-timeout message points first to the access network and whether the client can access the subscription. A format or parsing error may indicate incomplete copying, an incompatible client type, or damaged local cache. A write failure points to storage permissions, the configuration directory, or available system space. Mapping the original error to its stage is more effective than repeatedly clicking Update.

If existing routes still connect while the update request fails, keep the working route and try updating again. If the request is being mishandled by the current routing rules, briefly switch connection mode for diagnosis, then restore the original setting. If no connection works, test whether the user panel opens on an ordinary network. Do not put a real subscription URL in shell history or a public ticket example; use an obvious dummy value to verify whether the client accepts the URL structure.

https://example.com/sub?token=YOUR_TOKEN

Preserve the evidence before clearing cache

Many clients support overwrite updates, re-importing, and deleting then importing again. Prefer an overwrite update because it preserves the existing configuration and logs. If overwrite updates keep failing during parsing, export an error log without sensitive information, then create a separate configuration for comparison. If the new configuration works, the old one may have a cache or manually added rule conflict. If it also fails, continue checking client compatibility, the access network, and the subscription source.

Do not delete all configurations before recording the error. Although deletion can make the interface look clean, it removes the evidence support needs to distinguish parsing failure, write failure, and conflicts with old rules. If reinstalling the client is truly necessary, first record the platform, client name, import method, and complete error text, and confirm that you can access the user panel again to retrieve the subscription. This site does not provide static subscription URLs or direct installer links on marketing pages; delivery is handled through the user panel.

Update succeeds but the route list does not change

Even after the client reports a successful update, it may continue using an old route list held in memory. Fully quit and reopen the client, then check the subscription update time and route names. If the client supports multiple configurations, confirm that the updated subscription is active rather than another configuration with the same name. Identical names can cause confusion; you may temporarily give a test configuration a distinctive local name, but do not change the route contents.

If only some routes appear after updating, check whether the client has filters enabled, hides unavailable items, or groups entries by keyword. Disable local filtering for comparison, then confirm that the regions described on the routes page are visible. EQVPN covers 90+ countries / 200+ routes; use the current subscription and routes page as the reference, rather than inferring service coverage from a filtered client count.

When submitting a subscription-update ticket, include the platform, client, import method, network environment during the update, complete error text, whether the panel works, whether old routes still connect, and whether re-importing changes the result. If the error occurs only on a particular access network, include the result after switching networks. These details quickly separate panel delivery, local parsing, permissions, and network-access issues.

Confirm whether the app is actually bypassing the current path

On the same device, first open the app’s official website in a browser, then test another service that requires similar network conditions. If the browser works but the app fails, the route is not completely unavailable. Check whether the app has built-in proxy settings, is forced to use a direct connection, or reads the system proxy only at startup. Some desktop apps read the network environment only when launched, so fully quit and reopen the app after establishing the connection; closing the window alone may leave a background process running.

Command-line tools, development environments, game platforms, and download tools often have independent proxy settings. Enabling the system proxy does not mean the terminal will inherit it; setting environment variables in the terminal does not mean graphical apps will use them. Identify whether the target app uses the system proxy, a virtual interface, or an in-app proxy. If the client mode is unclear, briefly compare with global mode: if global mode works but rule mode fails, focus on the rules; if both fail, check the app protocol and route suitability.

Check rule matches and the domain chain

Modern apps often connect to multiple domains for sign-in, APIs, static resources, push messages, and content delivery. Routing only the primary domain can produce a successful sign-in with blank content, working text with missing images, or a usable main screen with upload timeouts. Check the client connection log or rule-match records to see whether failed requests used the proxy, a direct connection, or were rejected. Group rules by domain instead of hard-coding one temporary address.

If an app uses its own DNS, encrypted resolution, or direct address connections, domain rules may not match as expected. A virtual-interface mode is often more comprehensive than system-proxy coverage alone, but the choice depends on client capabilities and system permissions. After changing modes, restart the target app and clear old connections before repeating the same test. Do not change DNS, routes, and rules at the same time, or you will not know which change helped.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

The snippet above only demonstrates rule order and uses example domains. Actual configuration must follow the format supported by the client and subscription; do not paste the example over a complete configuration. Rules usually match from top to bottom. A broad direct-connection rule placed before the target rule can prevent later rules from taking effect. Preserve the original configuration before editing, then confirm that other websites and local services are unaffected.

App protocols and security policies

Some apps use more than standard web requests, including real-time communication, push services, or long-lived connections. The system proxy may cover web requests without covering other traffic. If the app provides network diagnostics, record whether the failure occurs during sign-in, syncing, voice, images, or updates. If only voice or meetings fail, focus on sustained connections and network changes. If only updates fail, check download domains and background services. If only sign-in fails, also consider the app’s cached region and account session.

Managed devices may restrict app networking through policy, and security software may apply different rules to newly created virtual interfaces. If a personal device works but a managed device fails, confirm the policy with the device administrator instead of repeatedly switching routes. If security logs clearly show that the target app was blocked, allow it through the normal authorization process; do not disable all protection for long-term use.

Special cases for development tools and AI apps

Cursor, Copilot, command-line package managers, and other development tools may separately read the system proxy, environment variables, or editor settings. Being signed in through the editor interface does not mean the integrated terminal uses the same path; a working terminal command does not mean the extension host has reread the configuration. Test the editor interface, integrated terminal, and standalone terminal separately, and restart the relevant process after changing the proxy. For long-lived connections and code-completion scenarios, see the route-selection method in Cursor route recommendations.

If only one app fails, include the app name, failed function, browser comparison, connection mode, rule-match records, and route in the ticket. Do not simply say “this app does not work,” and do not submit account passwords or complete subscription content. Support needs to know whether the request entered the route and at which function stage it failed to assess rules, protocol coverage, and target-service status.

Use the symptoms to determine whether resolution is involved

If the browser says the server cannot be found, the domain cannot be resolved, or the command line reports that the domain was not found, check DNS first. If the domain returns an address but the connection times out, the issue has passed the resolution stage and may involve the proxy, route, or target service. A site’s main page may open while its images fail because an image domain has a DNS issue. Test failed domains separately instead of checking only the primary domain in the address bar.

Disconnect and test an ordinary domain, then reconnect and repeat the test. If resolution fails only after connecting, check the client DNS mode and system proxy. If it fails both before and after connecting, check the access network, router, or system DNS. If only one domain fails, possible causes include local cache, the target domain’s status, or routing rules. Use the same device and access network for comparison; do not change Wi-Fi while drawing conclusions.

View and refresh the system cache

Both systems and browsers cache resolution results. After a route or network change, stale cache may continue pointing to an address unsuitable for the current path. Windows can display and flush the system DNS cache. On macOS and Linux, cache management depends on the network service; the safest basic steps are to fully quit the browser, disconnect and reconnect the network, and test again. Avoid installing so-called network repair tools casually, as they may change the proxy, adapter, and DNS at the same time and broaden the problem.

nslookup example.com
ipconfig /flushdns
dig example.com

Available commands depend on the platform. Windows commonly uses nslookup and ipconfig; macOS and Linux commonly use dig or nslookup. The example domain is unrelated to this site’s configuration. Record whether there is “no response,” a response followed by connection failure, or different results on different networks. Different returned addresses are not automatically abnormal; content-delivery services may return different addresses according to network conditions.

Keep client DNS mode and routing rules consistent

Rule mode needs domain information to make routing decisions. If the system resolves the domain to an address first and the client sees only that address, some domain-based rules may not match. Certain clients preserve domain associations through enhanced resolution or a virtual interface, but capabilities depend on the implementation. If rule mode fails while global mode works and logs show the request used a direct connection, check whether DNS and routing rules work together instead of only changing the resolver.

Do not enter public DNS addresses found online without a clear reason. Resolver reachability, privacy policies, and regional responses affect the result; a poor choice may return an address unsuitable for the current route. Prefer the client’s recommendation or automatic system configuration. Make a single change only after confirming a resolution failure, and keep before-and-after comparisons. Restart affected apps afterward so old connections do not continue using cached results.

DNS leaks and regional detection

Some users use web tools to check where DNS requests originate. Results depend on the browser, system, client mode, and access network, so a single region name cannot prove that a route has failed. First confirm that the exit connection matches the selected route, then check whether the client explicitly offers DNS takeover. A browser’s built-in secure resolution may bypass system settings; for comparison, temporarily disable that browser-specific resolution, then decide whether to restore it based on your privacy needs.

If different browsers produce different results, check each browser’s resolution settings and extensions. If every app shows the same issue, inspect the client and system. A DNS ticket should include the failed domain, resolution-command output, differences before and after connecting, client DNS mode, whether the browser uses independent resolution, and whether the problem occurs only on one access network. Do not include complete subscription information or account credentials in screenshots.

When changing DNS could affect multiple apps, read the quick-start guide first to confirm the client’s standard connection method, then make local changes. After troubleshooting, remove temporary rules and restore a configuration that is understandable and maintainable instead of leaving conflicting resolution settings behind.

“Unlimited devices” is not the same as unlimited local resources

Unlimited devices means the service does not impose a fixed device-count condition, but multiple devices sharing one home, office, or mobile network are still affected by access-network quality, wireless conditions, and simultaneous transfers. If performance changes after adding devices, pause syncing, updates, and video on the other devices, then retest on the same route. Do not mistake local egress congestion for an account device restriction.

If a client displays a device-limit message or similar wording, first confirm that it comes from the current subscription client rather than an app-store account, the number of system network configurations, an enterprise policy, or other software. Record the exact message and where it appeared, then sign in to the user panel to check the account status. Do not delete other device configurations as a test; the service facts specify unlimited devices, so an inconsistent message must be assessed in the context of the client source and local environment.

Cross-check across devices

The goal of cross-checking is not to prove which device is faster, but to narrow the fault. With the same account and access network, if one device works and another fails, focus on the failed device’s permissions, client mode, system proxy, and security rules. If every device fails on the same network, compare another access network. If only one route fails on one device, move to route troubleshooting. Replacing one dimension at a time—device, network, or route—shows where the problem stops.

Different platforms do not need identical configuration screens. Windows and macOS are more likely to have system proxies, terminal environment variables, and virtual interfaces at the same time. iOS and Android are more affected by background policies, while Linux requires extra attention to the desktop network manager, permissions, and environment variables. Compare whether the same task can be completed, not whether the settings pages contain buttons with the same names.

Prepare a minimal reproduction before submitting a ticket

An effective ticket starts with the symptom: when it occurs, which destinations are affected, and whether it can be reproduced reliably. Then provide the platform, client, access network type, connection mode, route name, whether the subscription updates, and comparison results from other devices or routes. Finally, include the original error text and relevant logs. Clear, ordered material lets support begin diagnosis instead of repeatedly asking about the basic environment.

Do not upload a single error screenshot cropped away from its context. Keep the error title, location, and current client state visible, but hide the username, complete subscription content, and unrelated personal information. When text logs are easier to search, copy the full section covering the events before and after the failure. Do not edit the error wording or replace the original text with your own interpretation.

Restore the configuration and prevent recurrence

After resolving the issue, remove temporary rules, custom DNS, and global mode added during diagnosis, returning to a standard configuration that can be maintained long term. Record useful findings, such as whether the issue occurred only on one access network or an app had to restart before reading the system proxy. Do not keep multiple subscriptions from unknown sources with identical names, or it will be difficult to tell which one is active during the next update.

Update the subscription regularly from the user panel, and retest ordinary websites, real apps, and DNS after changing plans, reinstalling the client, or replacing a primary device. Subscription and client delivery are handled through the user panel rather than static installer links. To review installation and import, return to the quick-start guide. To compare regions and use cases, see the routes page. To check monthly plans and never-expiring traffic bundles, see the plans page.

EQVPN offers a 30-day no-questions-asked refund. Payment methods are Alipay / WeChat Pay / USDT. See the refund policy for eligibility and instructions. If troubleshooting confirms that the current setup does not meet your needs, follow that policy. For technical issues, submit complete materials through a user-panel ticket first to avoid losing context across multiple channels.

A reproducible incident record with clear variables usually reaches a conclusion faster than repeated reinstalls. First identify whether the issue is with the account and subscription, client, system network, access network, route, or target app, then make the smallest change at that layer. Retest the original task after recovery and confirm that temporary settings have been removed; that completes a proper troubleshooting cycle.