VPN Troubleshooting Guide

Can't connect at all: checks before connecting

Start by separating “can't connect at all” into distinct cases: the client won't launch, the subscription shows no routes, an error appears when you connect, or the connection stays on “waiting.” Each points to a different layer. Write down the exact error before doing anything else; don’t immediately uninstall the app or repeatedly reimport the subscription. Uninstalling may erase useful logs and change permissions, settings or cached data, making the original cause hard to reproduce. Note the current configuration and selected route before you investigate.

Check that your basic internet connection works

Disconnect the client temporarily and use a browser to open a site you can normally access directly. If that also fails, troubleshoot your local network first. Check whether the system reports an active connection, whether hotel or public Wi-Fi requires you to confirm access in a browser, and whether your router is working. Until you complete any required sign-in or access confirmation, the client may keep waiting; switching international routes won’t fix that. Get ordinary web access working before testing the proxy, so a local outage isn’t mistaken for a route problem.

Once ordinary websites load, keep the device and configuration unchanged and try a different network for comparison. If the same configuration only fails on one network, note the network type and whether it uses a corporate gateway, guest network or router filtering. Managed networks may have access policies. Don’t disable management software or change security settings on a work device without permission. Retest on a network you’re authorized to use, then share the differences with the network administrator or support team.

Check the configuration and system permissions

Open the client’s configuration list and make sure you’re using a valid subscription from the user panel—not an empty configuration, an old backup or a file from another source. Seeing route names doesn’t mean the subscription is still valid; check the plan status and remaining data in the panel as well. If an error appeared during import, go to subscription update troubleshooting first. Don’t keep trying to connect without a valid configuration. If the client reports a configuration syntax error, note where it occurs, but don’t share the complete configuration publicly.

When a VPN or network extension is set up for the first time, the system may ask you to grant permission. Check whether the relevant app is allowed to create a connection and whether another proxy, VPN or network-filter extension is active. Keep only the connection method needed for this test, and note its original state so you can restore it. This is a temporary troubleshooting step, not a recommendation to permanently disable security tools. On managed devices, follow administrator policies; don’t try to bypass authorization restrictions.

Use comparison results to pinpoint a route issue

After checking the configuration and permissions, manually connect to one route, then compare it with another route that uses a different exit. Keep all other conditions unchanged. If just one route fails while others can reach the same site, the issue is more likely specific to that route. If every route fails on one device but works on another, the local device environment is a more likely cause. Broad coverage doesn’t mean every local network uses the same access path; choose based on what works in practice.

A status icon isn’t a complete test

“Connected” usually means the client has established one part of the connection. Next, check whether websites load, whether requests follow the selected rule and whether the destination service returns a specific error.

If all routes keep failing, check the first meaningful error in the logs. A timeout, authentication rejection, name resolution failure and local permission error are different issues. Note when it happened, your operating system and client, the selected route, and whether you tested on another network. In a support ticket, “Ordinary websites load, but the connection stays on waiting” is more useful than “It doesn’t work.” Don’t share your password or full subscription link; support doesn’t need those account credentials to troubleshoot a connection.

After making one change, disconnect and reconnect, then reopen the test page. If the issue is fixed, note what worked and stop changing things. If it isn’t, revert the last setting before trying the next branch. Changing proxy mode, DNS handling and routes all at once makes the outcome impossible to interpret. For route categories, see the route list; this guide doesn’t rank routes by reliability.

Connected but pages won't load: DNS & access paths

If pages still won’t load after connecting, note the exact stage shown in the browser: server not found, connection timed out, certificate error, or an access restriction returned by the site. If the page displays an error from the destination site, the request has usually reached some part of the service; that’s different from a complete local name resolution failure. Don’t label every symptom a DNS problem or reset all your network settings after one failed refresh.

Separate widespread issues from single-site issues

Stay on the same route and try sites for different purposes. If only one site fails, check the domain spelling, the site’s status, your account login and any regional requirements. Then compare in a separate browser session to see whether cache or extensions are involved. If every site fails in the browser but other apps work, check the browser’s proxy extensions and secure DNS settings first. If all apps fail, check the system proxy, tunnel status and client logs.

DNS translates domain names into addresses. The client, operating system, browser and router may all handle resolution; which one does so depends on your settings. A browser using its own encrypted DNS may not follow the system’s resolution path. Similarly, a client using a different domain handling mode may return special addresses to apps. A single system lookup only tells you what happened along that lookup’s path—it doesn’t prove that the browser or tunnel resolves names the same way.

Use system tools to gather clues

The commands below use an example domain and contain no subscription details. On Windows, run a domain lookup in Command Prompt; on macOS and Linux, use the same-named tool in Terminal. If the command isn’t installed, skip it—there’s no need to install unfamiliar software just to troubleshoot. If the lookup succeeds, still check the browser error. A returned address doesn’t prove the website is reachable.

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

nslookup output can show whether you got a response or a DNS timeout; curl can help inspect the request stage and response headers. Command-line tools may not use the desktop system proxy automatically, and may not take the same path as your browser. If a command fails while the browser works, the difference may simply be how the request was sent. When sharing output, keep the error text but hide local network identifiers and unnecessary addresses. Don’t include commands containing authentication details.

Check for cache, certificate and DNS conflicts

If you recently switched networks or changed DNS settings, close the affected pages, reconnect the client and open a new browser session. Clear the DNS cache only if you have reason to think it contains outdated results, and follow your operating system’s official instructions. Don’t change DNS servers, edit rules, disable browser extensions and reset your router all at once. After each change, revisit the same domain and record what happens to tell a cache issue from an ongoing DNS path conflict.

Handle certificate errors separately. Check that your system date and time zone are correct, confirm the domain is the one you intended to visit, and make sure public Wi-Fi hasn’t redirected you to an access confirmation page. Don’t ignore certificate warnings or install an untrusted root certificate to “fix” access. If a managed device uses an organization’s network inspection tools, check with the administrator. A certificate error doesn’t automatically mean you need a different subscription, and disabling certificate validation is not a safe fix.

A DNS issue doesn’t mean your data has been exposed

This guide uses observable errors to locate the DNS resolution step; a single lookup isn’t enough to draw a security conclusion. Don’t upload account passwords or complete diagnostic files to unfamiliar testing sites.

If a particular domain keeps failing, compare it with a working domain using the same route and browser, and record the error type instead of capturing only a blank page. If another route works, the issue may involve the exit path or the destination site’s policies. If all routes return the same account restriction, check the destination service’s account and regional rules. If you contact support, provide the domain only; remove private parameters and session details from the URL.

Slow speeds & peak hours: how to compare routes

A “slow” connection can mean different things at different stages. A long wait before a page opens, images loading slowly after text appears, video buffering and file transfers stalling may involve different parts of the connection. Choose one everyday task you can repeat, then observe it on the same device, network and route. Don’t run a large download, stream video and sync multiple background tasks at once and use the mixed results to judge route performance.

Separate local bottlenecks from the exit path

Pause cloud sync, system updates and other ongoing transfers, and check whether other devices are using the same network. On a desktop, compare wired and Wi-Fi connections if possible. On a mobile device, stay in one place while testing. If ordinary websites are slow even without the VPN, troubleshoot the local connection first. A strong Wi-Fi icon doesn’t rule out interference, router load or upstream connection problems; the client can’t fix local bottlenecks.

Next, switch routes while performing the same task. Choose an exit suitable for the destination service’s regional requirements, then compare other paths. A nearby location is a reasonable starting point, but distance alone doesn’t determine performance: the path from your provider to the entry point, current route conditions and the connection from the exit to the destination site all matter. A city name, route label or single latency reading can’t guarantee throughput. Test with the website or app you actually use.

Understand route types

This table is a troubleshooting guide, not a performance guarantee. For available routes, check the route list and user panel. If one type performs poorly on your current network, compare it with another available type—but keep the task the same each time. Switching between sites, video quality settings and exits at once produces mixed results, so you can’t tell which change helped.

Retest at peak hours under the same conditions

Compare peak-hour slowdowns with results from another time under similar conditions. Check that you’re using the same network, device and destination service, and note whether other devices at home are transferring data. If the issue only occurs during busy periods and an alternate route helps, keep a working route and report what happened on the original one. If all routes and ordinary websites slow down, check for local network congestion instead of reinstalling the client.

For video buffering, distinguish transmission problems from service restrictions. If you can browse the catalog but can’t play content, the cause may involve region, account status, content rights or how the destination service evaluates the exit. If playback starts but buffers as the resolution increases, available throughput is more likely an issue. Compare at a fixed resolution first, then see whether changing routes helps. For regional and content availability limits, see supported service information. Switching exits doesn’t guarantee lasting access.

Slow responses from AI tools don’t necessarily point to a network problem. First check whether the page loads and login works consistently, then note whether a request disconnects, returns a clear rate limit or is still processing on the service. Different task complexity makes for an unreliable route comparison. For Claude’s regional requirements, see Claude route selection and account checks to distinguish account eligibility and service policies from connection issues.

When reporting a speed issue, describe the task and what happened—for example, “Page text loads, but images keep waiting”—and compare a working route with the affected one. You don’t need to repeatedly download large files to prove a problem, and other users’ experiences don’t establish what’s happening on your device. Support needs reproducible conditions, not just “It’s really slow” without context about your device, network or destination service.

Frequent disconnects and mobile background issues

First distinguish an actual disconnect from an app that only appears disconnected. The client showing a stopped connection, the system VPN indicator disappearing, a brief wait in a browser and an app asking you to log in again after returning to it may have different causes. Note whether the issue happens when the screen locks, the network changes, you leave the app or you’re actively using it. If the connection stays active but one app reloads, check that app’s session rather than assuming the tunnel dropped.

Watch for the trigger and system behavior

Keep the client in the foreground while completing a normal browsing task. Then lock the screen or switch apps, and check the connection status and logs when you return. Don’t change routes during this test. If the issue only appears after leaving the app, check how the system manages background activity and battery use. If it also happens while the app is in the foreground, focus on network changes, route connectivity, other VPN conflicts and client errors. The same symptom can have different triggers on different devices.

When a mobile device switches between Wi-Fi and mobile data, the existing connection may need to be re-established. Some apps keep an old connection open for a while, so they may still show a wait even after the client reconnects. First confirm that the current network can load ordinary websites, then reopen the affected app. Don’t disable necessary system features just to avoid switching networks. More useful evidence is “Works on a fixed network, fails after switching,” which narrows the problem to reconnection.

Check background activity and sleep settings by platform

On Android, check the app settings for background activity and battery management. Follow the system’s guidance to allow the client to perform necessary background tasks. Options with the same name may behave differently on different devices; don’t blindly copy instructions from a screenshot of another model. Don’t turn off battery protection globally—adjust only the app involved and note its original state. On organization-managed devices, an administrator may control background policies; ask them to check the trigger if you can’t change those settings yourself.

On iOS, first check the system VPN status and client logs, then see whether another app has installed a configuration that takes over network traffic. Don’t treat Android’s “autostart” setting as a universal iOS fix or repeatedly delete system configurations. If a desktop only fails after waking from sleep, verify the network connection first, then disconnect and reconnect the client. If the system proxy still points to a stopped local service after quitting the client, use the client’s normal exit and proxy reset procedure.

Keep context from before and after a disconnect

A useful disconnect log includes context from before and after the event, not just the final error line. Note whether the screen was locked, the network changed, the system closed the client and whether reconnecting fixed it. If opening the client restores the connection every time, mention that pattern in your ticket. If only one route disconnects while an alternate works, include the route name. If different routes all disconnect after the same action, focus your report on device behavior and the system environment.

Don’t mask the problem by keeping the device awake

Keeping the screen on can be useful as a comparison, but it isn’t a long-term fix. Identify the actual trigger in background management, network switching or wake-from-sleep behavior, then keep only settings that are genuinely necessary.

After the connection recovers, repeat the original trigger—for example, lock the screen again or switch networks normally—to make sure it wasn’t a one-off. Don’t stop troubleshooting just because a webpage loads while the app is open. If it still fails, list the system checks you’ve done and attach redacted logs. This helps support distinguish a client exit from a lower-level network change or route interruption, and avoids repeating steps that haven’t helped.

Subscription update failed: source, format & import

Updating a subscription and connecting to a route are separate operations. To update, the client retrieves configuration from the subscription link; to connect, it uses configuration already retrieved. An old route may still work even when an update fails, or an update may succeed while access still fails for another reason. First note whether the problem occurs while fetching the subscription, parsing its contents or enabling the configuration. An “import successful” message doesn’t prove the route has been tested.

Verify the source in your user panel

Go to Account Overview and check your plan status and subscription link. Use the panel’s copy button to avoid missing the last characters or copying the page URL instead of the subscription URL. If you’ve forwarded the link through a chat app, it may have added line breaks, spaces or punctuation. Don’t paste the link into a search engine to test it, and don’t post it in a public group for someone else to check.

A full subscription link works like an account key and usually contains parameters that identify your account. When troubleshooting, describe the source and error without exposing parameter values. The example below is a fake address for demonstration only; it won’t connect and should never be replaced with your real address in a screenshot. If you need to check whether a link was truncated, do so locally; there’s no need to send the entire link to support.

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

If a link was shared publicly, check the panel for an option to reset it. If you’re unsure which option to use, open a support ticket for instructions. After a reset, saved subscriptions on other devices may no longer update; import them again using the new link. Don’t keep using an exposed link just to restore access, and don’t assume changing your password automatically invalidates a subscription link. Check the panel and support guidance for the actual status.

Tell a retrieval failure from an incompatible format

For errors such as a connection timeout or failure to resolve the subscription domain, first check that you can access the user panel on your current network. If your client lets you update over the current network or proxy path, note the original option and change only the update path for comparison. If an old configuration is no longer working, forcing updates to rely on the old connection can create a loop: the connection is unavailable, but the subscription update also requires that connection. Don’t repeatedly delete the account; first check whether the retrieval request reached its destination.

If the content was retrieved but the client reports an unsupported format, missing fields or a syntax error, the client may not support that subscription type. Use the entry provided for your client in the panel. Don’t save a webpage response as a configuration file or fill in authentication fields using random snippets from the internet. Import methods vary by client; downloads are available in the user panel downloads section. Don’t use an unfamiliar conversion service to process a private subscription.

Don’t delete every working configuration just because an update failed. Keep the old one and import a separate configuration with a clear name for comparison. Once the new configuration works, you can tidy things up. Updates can also be affected by system time, public Wi-Fi access confirmation, certificate checks and network filtering. If the error involves a certificate, return to the web and DNS section; don’t disable certificate validation just to make an update appear successful.

Check whether the updated configuration actually works

After a successful update, check that the enabled configuration contains the new content and that your manually selected route is still available. Some clients retain the previous selection, which may now be empty or point to an outdated group. Choose an available route again, then test an ordinary website and the destination service. If only a particular app has issues after the update, check the app routing rules instead of repeatedly importing the same subscription.

In a support ticket, include the client name, exact error, whether you can access the panel, whether the old configuration connects and which import option you used. Screenshots should show only the error area; hide QR codes, links, account balance details and unrelated personal information. For a step-by-step guide to copying and importing your first subscription, see Your First-Day Setup Guide. For tips on protecting your account and subscription link, see Account and Subscription Link Security.

An app isn’t using the proxy: rules & routing

If your browser works but one app can’t connect, check whether it uses the same network path. A system proxy isn’t a requirement that every program follows. Some apps use their own network settings, some requests come from separate services, and browser extensions affect only the browser. First confirm that the issue is consistently limited to one app. Then check the client’s connection records to see whether its requests appear and where they go.

Understand how traffic is being routed

System proxy mode provides a proxy entry point mainly for apps that support the setting. Tunnel mode handles eligible traffic at the system network layer, but can still be affected by routes, exclusion rules and permissions. Neither mode is simply “incomplete” or guaranteed to work. Tunnel mode may require additional system authorization; get permission first on managed devices. Don’t change your organization’s network policy just to make one app work.

Open the client’s connection or request log, then perform a specific action in the target app, such as refreshing its home page. If no related requests appear, check the app’s own proxy settings, background services, browser shell or separate network process. If requests do appear, focus on matching rules, the actual exit and any error instead of assuming the app never reached the client. Logged domains may belong to content delivery or login services, so don’t look only for the brand name shown in the app.

Use a temporary comparison to test your routing rules

If your client supports rule modes, temporarily route the test app’s traffic through the same proxy exit, and note the original mode. If the app works, a rule match is a more likely cause. If it still fails, check DNS, exit region, app account status and protocol support. Restore your usual rules after testing so local services, internal resources and traffic that doesn’t need a proxy aren’t rerouted. Global mode is a diagnostic tool, not a long-term solution for every issue.

Rules have an order and matching scope. Domain, process and fallback rules can override one another, and existing connections may not use a changed rule immediately. Read the current configuration and identify which rule matched before making changes. Don’t overwrite a subscription configuration with a complete ruleset from the internet or delete rules you don’t understand to “simplify” it. An update may also undo local changes, so keep subscription content and local overrides clearly separate.

App sessions, protocols and regional requirements

After changing the route, fully quit and reopen the app, then repeat the same action. An app may cache old DNS results or keep an existing connection open; returning to its home screen doesn’t necessarily create a new connection. If the issue involves a login session, note the error before deciding whether to sign in again. Don’t repeatedly try passwords across different exits. Frequent region changes can make a destination service see an inconsistent session environment, so take extra care with AI, payment and streaming apps.

Some apps use transport methods that differ from web browsing. A working webpage doesn’t prove that all real-time communication, media or background connections will use the same path successfully. If logs clearly show that a particular transport was rejected, check the client’s capabilities and current configuration rather than guessing at protocol settings. Tell support which feature fails—for example, “The home page works, but voice calls don’t”—instead of only naming the app. Route coverage doesn’t override the destination app’s own regional and account requirements.

Connection logs can contain sensitive information

Logs may include visited domains, app processes and request parameters. Share only what’s needed around the action that reproduces the issue, and remove authentication fields, private addresses and unrelated browsing details.

If an app explicitly says a region isn’t supported, your account isn’t eligible or content is unavailable, check the destination service’s policies first. Switching routes can change the network path, but not your account’s registered region, content rights or payment eligibility. For streaming service limitations, see supported services. For AI region issues, consult the relevant guides on this site. Don’t report an account restriction you can’t change as a client fault.

If you need help, include the app name, affected feature, routing method, rule mode, whether a connection record appeared and what happened when you temporarily used a single proxy exit. If work software is involved, hide internal domains and business data, and check with your administrator first. This helps distinguish an app that didn’t use the proxy, a rule that sent a request direct, and a proxied request rejected by the destination—without resorting to repeated reinstalls.

Check device-limit messages and account status

VPNLong has no limit on the number of devices that can be online simultaneously. It supports Windows / macOS / iOS / Android / Linux. If a client shows “device limit exceeded,” don’t assume there’s an undisclosed plan limit or switch plans just to dismiss the message. First identify where the message came from: the local client, another service’s configuration, a router plugin or a specific response from the user panel. The source matters more than the wording.

Check that the account and configuration match

Check the current account in the user panel, then verify the source of the configuration in your client. A device may contain subscriptions for other services, test files or old backups with similar names that don’t belong to the same account. Give each configuration a clear local name, but don’t include the full subscription URL. If a new device works and an older one doesn’t, compare their configurations and update status first. Device count isn’t the only possible cause, and you shouldn’t share your account for someone else to test.

Unlimited devices means there’s no cap on how many devices can be online at once; it doesn’t mean each device gets a separate data allowance. When several devices use the same account, check the panel to understand total usage. During troubleshooting, note whether other devices are transferring data, especially cloud backups, system updates and video playback. A connection issue and exhausted data can look similar, but they require different fixes. Check the actual status in the panel first.

Use the plan details to understand account status

Monthly plans: ¥9.9/month includes 60GB, ¥18/month includes 250GB, and ¥28/month includes 500GB. Data resets monthly on the activation date. Mid-cycle upgrades are prorated for the remaining days. Don’t assume the reset happens at the start of the calendar month, or that the client’s local usage counter means the panel has already updated. Local statistics may cover only one device or session; use the panel as the starting point for checking account status.

Data add-ons: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They remain valid until used and never expire. “Never expire” describes the add-on’s validity period; it doesn’t mean unlimited data or guarantee that a route or destination service will always behave the same way. To compare billing options, see the plans page. Don’t upgrade on a hunch while troubleshooting a network issue—an upgrade won’t fix local permissions, DNS conflicts or restrictions on a destination website account.

If the panel doesn’t show the expected status after payment, first check the order section to see whether the order is marked complete, then confirm you’re signed in to the account used for payment. Payment methods: Alipay / WeChat Pay / USDT. The status shown on a payment page doesn’t replace the final order status in the panel. If something looks wrong, keep the order ID and redacted proof of payment, then ask support to check. Don’t repeat the same action to try to “refresh” the status.

Isolate the affected device; avoid broad changes

If other devices work and only one shows a restriction or authentication error, recheck the configuration on that device and try importing the corresponding entry from the panel. Leave other working devices unchanged so you can use them as a reference. If all devices fail at once, check the account, data and subscription status before investigating routes. Don’t clear the configuration from every device at once; you’ll lose the evidence needed to tell a local issue from an account-wide one.

For a device warning, include a screenshot showing the exact message and client name, but hide account identifiers, subscription QR codes and links. Say whether you use the client and configuration from this site’s panel, and whether another network interception tool is installed. Support may need to determine whether the message comes from a local component, third-party plugin or account response. The full error is more accurate than summarizing it as “not enough devices.” Don’t change authentication parameters or copy an unfamiliar configuration to dismiss the warning.

Handle refunds separately from troubleshooting

This service offers a 7-day no-questions-asked refund. See the Terms of Service for details. Troubleshooting advice doesn’t add refund conditions, and you don’t need to share your password to prove there’s a problem.

Once you’ve confirmed the account status, decide what to do next. If the panel looks normal and other devices work, return to the local connection and app routing sections. If the panel or order status is unclear, ask support through an account ticket. If you chose the wrong billing option, read the plan details before taking action. Separating network issues, account status and plan selection helps avoid changing your bill without fixing the original problem.

Submit a support ticket: organize evidence and verify the fix

Consider opening a support ticket if a valid subscription won’t update on different networks, the panel and order show different statuses, multiple routes can’t establish a connection, or a client permission or runtime error keeps recurring. If a website clearly reports an account restriction, check that site’s policies too. Support can help assess network issues but can’t decide whether you qualify for a third-party service. Before reporting the issue, separate verified facts from your own theories.

Describe the issue in reproducible steps

Open a ticket in the user panel. Start with your device platform, client name, network type and selected route. Then explain what you did, what appeared and what you expected to happen. Include the time zone so support can compare timestamps. Avoid vague reports like “It didn’t work yesterday” or “It keeps disconnecting,” and don’t describe an occasional issue from memory as a constant failure. If you can’t reliably reproduce it, say that the trigger is still unclear.

Use the outline below to organize details; you don’t need to provide extra identity information beyond what this page asks for. If you haven’t tested something, write “Not tested” rather than guessing to make the ticket look complete. You can check the client name and version in the app itself. This guide doesn’t assume a version number or ask you to install an unofficial build for troubleshooting.

• Symptom: connection failure, web access failure, update failure or a problem with an app feature.
• Environment: operating system, client, network type, and whether the screen was locked or the network changed.
• Steps to reproduce: the actions from opening the app to the error, including the exact error text.
• Comparisons: whether the same issue occurs on another route, network or device.
• Changes made: proxy mode, permissions and DNS settings changed, and whether they’ve been restored.
• Attachments: redacted error screenshots and logs from around the time of reproduction; no account credentials.

Keep only the necessary log context

Use the client’s own log viewer or export feature when possible, and collect the entries around the time you reproduced the issue. A full historical log may contain a lot of unrelated browsing information and make the problem harder to diagnose. Keep the error text, stage and relevant context in your screenshot; don’t crop it to a red icon alone. If logs contain a password, authentication field, full subscription URL, private request parameter or internal address, redact it locally before sending.

When redacting, replace sensitive values with a clear note instead of removing so much that the log becomes unreadable. For example, keep “subscription domain resolution failed” but hide parameter values; keep the route name but remove full connection credentials. Don’t upload binary diagnostic bundles or complete configurations to public file-sharing sites. If support asks for more material, confirm what it’s for and how much is needed, then send it through the official channel in the panel. Avoid scattering account information across multiple services.

Test one suggestion at a time after support replies

Follow the suggested steps in order, recording what changed each time. If a suggestion involves clearing configurations, resetting the network or changing system permissions, first check whether it could affect other apps and keep a local copy of settings you can restore. Have an administrator approve changes on managed devices. Don’t apply a support suggestion and a complete set of changes from another guide at the same time; even if the issue is fixed, you won’t know what worked.

Verify the original failing action, not a simpler webpage. If the problem was a disconnect while the screen was locked, test the lock-and-wake behavior. For a subscription update issue, run the update again and check the active configuration. If an app’s media feature failed, test that same feature. If only part of the issue is fixed, say so in the ticket—for example, “The connection is back, but the app still shows an error.” Don’t mark the whole issue as resolved too soon.

When to stop troubleshooting on your own

If you see a certificate warning, suspect someone else has used your account, find an inconsistent order status or can’t perform an action because of managed-device security policies, preserve the evidence and contact the appropriate support channel. Don’t disable validation, share credentials or repeatedly pay to test what happens.

After the issue is resolved, undo diagnostic-only settings such as global proxy mode, temporary DNS changes and extra test configurations. Keep only permissions and rules you actually need. Check that ordinary websites, the target app and local resources all work as expected. Note what fixed the issue for your own records, but don’t save a real subscription link in a public document. If a similar symptom returns, compare its trigger with this incident instead of resetting everything.

Use this page for systematic troubleshooting. For quick answers, visit the Help Center; for setup from the beginning, return to the getting started guide. Before using the service across networks, read Network Access and Plan Choices for Business Travel to understand differences in public Wi-Fi access, work software and data estimates. The goal isn’t to accumulate settings, but to restore the original task with the fewest changes—each one clear and reversible.