VPN Connection Troubleshooting

Can't connect at all: check the prerequisites for connecting

“Can't connect” can describe several different problems: the client won't start, the connection toggle won't stay on, the route fails to handshake, or the interface says connected but websites don't respond. Note the exact message and whether the symptom occurs before or after you tap Connect. Don't assume a website that won't load means the route is down, and don't rely on a status icon alone to confirm that the connection is working. Start with one clearly defined symptom; otherwise, reinstalling the client, switching routes and changing system settings all at once makes it impossible to tell what helped.

Check your local network first

Disconnect the client and open a website you can normally access to confirm the device is online. If it still won't load, check Wi-Fi, Ethernet, your router and whether the network requires a sign-in page. Hotels, offices and public networks may require authentication before granting access; a proxy connection can interfere with that page. Connect to the network with the client disconnected, close the sign-in page, then try connecting. You can test another available network for comparison, but just record the result—don't change client settings at the same time.

If other devices on the same network also have trouble, the issue is more likely with local network access than with the subscription on this device. If other devices work, check whether you recently installed security software, changed system network settings or resumed from sleep. A significantly incorrect system date or time can interfere with certificate verification; restore automatic time settings and reopen the client. Never bypass a browser certificate warning or install an untrusted root certificate just to make the connection appear successful.

Verify your account, subscription and routes are ready

Open your account overview to check your plan status and remaining data, then make sure the client has imported the subscription for your current account. Being able to sign in doesn't necessarily mean your plan is active, and route names still appearing in the client doesn't mean their configurations are valid. Monthly subscription data resets each month on the activation date, not necessarily on the first of the month. If the status doesn't match your order, keep a screenshot of the account page and the order ID, then contact support. Don't pay for the same order again.

Open the client's route list, select a specific route and try to connect. If the list is empty, go to the subscription update section instead of repeatedly tapping the connection toggle. If routes are listed but all fail, first check whether the client has the network permissions it needs and whether another proxy app is still running. Multiple apps managing the system proxy or virtual network interface can override one another. Temporarily quit other similar apps and test again in the current client. On a managed device, first confirm which changes are allowed.

Pinpoint the issue with reversible changes

Keep the original route name for reference, then try another route in the same client and on the same network. If only the original route fails, you've narrowed the issue to that route. If routes in different regions all fail, compare results on another network. Change just one condition at a time, wait for a clear result and record whether it connected or what error appeared. Switching too quickly can mix cleanup from the previous connection with the next handshake, making logs harder to interpret. See the routes page for route type details. There's no need to change the protocol, port and routing mode all at once.

If you see a permission-denied error, virtual interface creation failure or error writing the system proxy, investigate the client-to-system interaction. On desktop, check network permission prompts and security software logs. On mobile, check whether the system allows the client to create a VPN configuration. Don't disable all security protections or delete system network components. Managed devices may prevent users from changing these settings; contact the device administrator, as a service route cannot replace system authorization.

Once the connection works again, retest on the original network and in the original situation where the problem occurred. If switching networks fixed it, the cause isn't fully identified yet. If quitting another proxy app fixed it, decide which app should manage the network going forward. Keep the last known working settings and avoid leaving every attempted change in place. Reinstall only after confirming you can restore your configuration, and save your account sign-in details and relevant troubleshooting evidence first.

Connected but websites won't load: distinguish DNS resolution from access

A successful connection usually means only that the client established a connection state; it doesn't guarantee access to every app, domain or destination service. Loading a webpage involves DNS resolution, establishing a transport connection, certificate verification and a server response. A failure at any step can produce a similar “can't be reached” message. Note the exact browser error: “server address not found” points toward a resolution issue, a connection timeout toward the route or destination response, and a certificate error toward the system clock, certificate chain or network sign-in page. The error category is more useful for troubleshooting than repeatedly refreshing.

Check whether the issue affects one website or many

Keep the current route and try both websites you can normally access and the one that's failing. If only the target website fails, check for account, region, maintenance or access-policy messages from that service. Don't change the device's DNS settings yet. If several unrelated websites fail, check whether apps outside the browser are affected too. A browser-only problem may involve an extension, browser proxy setting or secure DNS. If all apps are affected, check the system proxy, tunnel routing and local network.

Disconnect and try a regular website as a comparison. If it still fails, investigate your local network or leftover system settings first. If browsing works when disconnected but generally fails when connected, check whether the client has a block-direct-connection protection option enabled, whether you've selected an unavailable outbound route, and whether DNS queries are being sent through a broken path. Don't leave a protection option disabled as a permanent fix. Use a temporary change only to test a hypothesis, then restore the intended settings.

Know what DNS checks can and can't tell you

DNS translates domain names into addresses. The system, browser and client may each cache results or use different resolution paths, so a successful command-line lookup doesn't mean the browser used the same result. Secure DNS in the browser may make its own queries, and the client may route domain lookups according to its rules. Before testing, note the current settings for these features, then use the client's recommended method to test consistently. Entering a DNS address found online may only move the problem elsewhere and could conflict with the client's domain routing rules.

The commands below only show how DNS resolution is behaving on this device; they don't change network settings. The example domain is not a subscription endpoint or a VPNHL route test address. A response only confirms that this particular query received an answer. It doesn't prove the destination website is accessible, that your exit region is correct or that all traffic is going through the client. If a command isn't available, skip it; there's no need to install unfamiliar tools for troubleshooting.

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

When running a command, note whether it reports a resolution failure, connection timeout or certificate error, and compare it with the browser result. Desktop terminal commands may not use the same proxy settings as your browser. On Windows, command names may also be interpreted differently by the terminal. A failed terminal request alone doesn't prove the route is at fault. If you need to share output, include only the error type and necessary timing details. Remove session data, authentication fields and anything that could reveal your personal browsing paths from response headers.

Check caches, browsers and certificates

After switching routes or DNS settings, an old cache may cause a webpage to keep using a previous address. Fully quit and reopen the affected browser or app, then refresh the DNS cache using your system's recommended method. Clear only data relevant to the issue; there's no need to delete all browsing history and sign-in details. A private window can help test the effect of extensions and site data, but it doesn't isolate the system proxy or DNS. If the private window works, check browser extensions, site data and browser settings first.

Handle certificate errors separately. Confirm the system clock is correct, check that the domain is spelled correctly and see whether the current network is showing a sign-in page. If only one website has a certificate error, don't submit account or payment information. Wait for the service to recover or verify the address. Never ignore a certificate warning or add an unknown certificate to your trusted list. A client connection can't guarantee that a destination website is trustworthy; establishing a connection and verifying a website's identity are separate checks.

After fixing the issue, test the original destination website, not just a regular webpage. Then quit and reopen the browser to make sure the result isn't due to a stale cache. For streaming or AI tools, also check the region and account messages shown by the service. See the streaming access guide and the AI tools access guide. If the destination service explicitly reports an account or region restriction, follow that service's rules rather than continuing to label the issue a DNS problem.

Slow speeds and peak-hour lag: compare like for like

Slow performance isn't a single metric. A webpage that takes too long to open, video buffering, an unstable download and choppy voice calls can point to different parts of the network. Webpages may be affected by DNS and handshakes; video and downloads rely more on sustained transfer, while real-time interactions are more sensitive to latency changes and packet loss. Describe the task and what happens rather than just saying “the speed test is slow.” The same route can perform differently with different services. Speed-test results are for comparison, not a substitute for testing how you actually use the service.

Rule out local network usage and testing errors first

Pause system updates, cloud sync and other bandwidth-heavy tasks on the device. Check whether anyone else is continuously downloading or uploading on the same network. A saturated upload in particular can delay webpage requests and interactive messages. Weak Wi-Fi, distance from the router or frequent network switching can all look like route congestion. Keep the device in the same location; if needed, compare with a wired connection. If regular browsing is still slow with the client disconnected, record the local network issue rather than switching plans right away.

Test on the same device and network, using the same content and app settings. When switching routes, don't also change video quality or download source, or you won't know what caused the difference. Browser cache, video preloading and download server limits can also affect results. Note whether the content is already cached before testing. If possible, repeat the action that caused the problem, such as reopening the affected page or playing the same video. Don't run multiple speed tests at once; they compete for bandwidth and distort one another's results.

Compare route types and destination paths

VPNHL's route list includes types such as IEPL dedicated lines, relay and direct routes. These labels describe how a path is organized; they don't guarantee a particular speed on every visit. Choose a route by testing it with your target region, current network and specific service. A shorter distance often means a shorter path, but doesn't guarantee higher speed. Detours, peering quality and the destination server's location can all affect results. Review the route types and regions guide, then compare routes under consistent conditions instead of ranking them by flag or name.

If webpages load normally but one download source is slow, try other content from the same service or check the source server before changing your entire network mode. If all long transfers stall but short webpage loads work, check local Wi-Fi stability, device sleep, client reconnections and whether the destination connection stays open. If only interactive tasks are sluggish, describe the delay between your input and the response instead of using a large download as a proxy. Compare each type of task on its own to turn “slow” into useful troubleshooting evidence.

Look for recurring issues during peak hours

To investigate peak-hour lag, compare the same task at other times of day. Record the local time and time zone, and keep the route and network the same for your next test. If only one route acts up during peak hours, compare it with another route in the same region. If every route slows down at those times and regular browsing is also affected when disconnected, investigate local access or your ISP's path. One bad night doesn't prove that all international routes lack capacity.

Apps may also behave differently during busy periods. A video platform may lower quality automatically, a cloud service may limit certain requests, or an AI tool may respond more slowly because the service is busy. Check the service's messages and task status, then see whether data is still transferring. If you repeatedly see server-busy or account-limit messages, follow the service's guidance. If you turn off automatic video quality for a test, note the original setting so you can restore your usual preference afterward.

For help organizing a speed test, see the VPN speed test comparison guide. In a support ticket, describe the task, time of day, route comparison and local network comparison; that's more useful than sending a speed-test screenshot alone. Once service is restored, retest the original task and check whether performance is consistent. Keep a route that works for your needs; there's no need to make every test look the same or present one personal test result as a general service guarantee.

Frequent disconnects and mobile background disconnects

First, distinguish between the client switching off, the connection staying on while traffic stops, and an app needing to reconnect after a network change. These problems need different fixes. Note what the device was doing just before it disconnected: was the screen locked, did you switch apps, did power-saving mode start, did the device switch networks, or did it just wake from sleep? If the problem only happens after one of these events, check system background behavior and network switching first. If it also occurs while the device is in active use, look at the route and local connection.

Disconnects continue during active use

Check whether the local network icon changes at the same time and whether regular websites briefly stop responding. Wi-Fi renegotiation, router reconnection and a loose Ethernet cable can all make the client look disconnected. Keep the route the same and test on another stable network. If the problem only occurs on the original network, investigate that connection. If one route disconnects across multiple networks, compare it with another route in the same region and note whether the client reconnects automatically. An automatic reconnection doesn't explain why the interruption happened.

Check the client's recent event log for network changes, handshake failures, interface closures and process exits. Automatic retries can produce many entries; focus on events around the first interruption. Don't upload the entire log history, which may include subscription parameters and domains you visited. Save the time range and exact error first, then work out whether the app exited, the system stopped it or the route failed. “Timeout” in a log is an outcome, not enough by itself to identify whether the service or local network is at fault.

Disconnects after locking the screen or switching apps

Mobile operating systems manage apps based on battery use, background activity and network permissions. On Android, check whether battery optimization, background activity or background data restrictions affect the client. Settings names vary by device, so look for the relevant function. Grant only the necessary permissions to a client you trust; don't allow unrestricted background activity for every app. After changing a setting, test while the app is open, while using another app and with the screen locked. Check the system connection icon and the events logged when you return to the client so you don't mistake a new connection for an uninterrupted one.

iOS manages VPN connections at the system level. The Background App Refresh setting for a regular app doesn't grant permission to keep a tunnel running. Check that the system VPN configuration points to the intended client, that another app hasn't created a conflicting profile and whether the network recently changed. Don't delete enterprise or device-management profiles without approval. If the client offers auto-connect or on-demand connection, read its instructions and confirm the trigger conditions. Similar feature names don't guarantee identical behavior, and they don't ensure every app will keep transferring data in the background when the screen is locked.

Network switching and waking a desktop from sleep

When the network changes, existing connections may need to be reestablished. Even if the client reconnects, the destination app may still have a stale session. Retry the request in the app, or fully quit and reopen it if needed. For meetings, uploads and remote tasks, check whether the task itself supports recovery; a client reconnection doesn't guarantee that work continued uninterrupted. If every network switch causes a failure, record the network types before and after, connection status and whether reconnecting manually helps, so the issue can be reproduced.

After a desktop wakes from sleep, make sure the network is ready before connecting. Some apps may resume before the network adapter, causing their first requests to fail. If the client is still running but the virtual interface hasn't recovered, disconnect and reconnect using the client's normal controls; a full device restart may not be necessary. On Linux, check the status of the desktop app and background service separately—a visible window doesn't mean the service is still running. Preserve existing settings when changing system service configuration so you don't affect other network apps.

After recovery, repeat the action that originally triggered the issue and confirm both the connection status and actual access return. If it only recovers after opening the client, continue checking background management. If a device restart is the only fix, save evidence from before restarting so you can investigate next time. Keep necessary permissions and the last known working settings, but don't enable multiple auto-connect apps at once. For ongoing tasks, a stable network and the app's own recovery features matter too.

Subscription update failed: check the retrieval and import path

Updating a subscription and connecting to a route are separate operations. An update requires the client to reach the subscription endpoint, receive the content and parse the configuration. A connection uses a route that's already been imported. Existing routes may still connect even if the subscription endpoint is unavailable; a successful update doesn't mean the selected route suits your destination service. First identify whether the error occurred while retrieving, parsing or saving the content. Keep the last working configuration. Don't clear the route list after one failed update, or you'll lose a basis for recovery and comparison.

Verify the source in your account panel

Sign in to your account overview and confirm your account and plan status, then get the subscription from the link provided in the panel. The subscription requires you to be signed in. Don't substitute a marketing page URL or use a link forwarded by someone else. When copying the link, check for extra spaces, line breaks or symbols added by a chat app. Never test your subscription URL on a public website; it functions as an access credential and an external testing service may retain it. If the panel won't open, check the connection path using the Websites & DNS section first.

If you reset your subscription from the account panel, the old URL may no longer work. Replace the subscription source in the client instead of keeping both old and new sources and repeatedly retrying. Before updating, note any custom rules, manually selected routes and other local settings; clients differ in what they preserve during an update. If the panel status and subscription contents don't match, record the status and error and contact support. Don't assume data is lost or pay again to try to restore it.

Choose your next step based on the error

A connection timeout or DNS resolution error usually means retrieval didn't complete. Check the local network and the network path the client uses for updates. For authentication or access-denied errors, first check whether the account and subscription URL are still valid. For an unsupported format or parsing error, confirm the client supports the export format selected in the panel. Error messages vary between clients, so keep the exact wording in your ticket instead of summarizing it as “the link is broken.” Adjust settings only after you've identified the stage where the error occurred.

Some clients let you choose whether to retrieve a subscription through the current proxy or directly. If the current route is down and the update requires that route, you can end up with a loop where you need a broken connection to update the connection. Check the update methods available in the client and compare them on a working network; don't change the system proxy address directly. Conversely, if direct retrieval fails but an existing working connection succeeds, note that difference. Use update-path options for diagnosis, and follow the panel and client instructions for the final configuration. Don't leave an unverified routing workaround in place.

Format issues and local save failures

If the client receives webpage content instead of configuration, it may report a parsing error. The response could be a sign-in page, network access page or error message; editing a few configuration fields won't fix it. Don't post the full response publicly. First confirm the content came from the current account-panel link. If the export format is incompatible, select a format supported by the client and import again. Don't send a private subscription through an online converter unless you can assess how the data will be handled; this guide doesn't require any external conversion service.

If saving fails, check whether the app has the required storage permissions, whether the device has space available and whether system management restricts the import location. Desktop clients may save to a user configuration folder, while mobile clients may receive content through the system document picker. Choose the right app and configuration location, then confirm that the new list actually appears. A “download complete” message without any new routes doesn't confirm that import succeeded. Don't edit program files unless you know what they're for, and don't solve a local permission issue by granting broad access to every folder.

After the update, check the route list and selected route, then test the connection. An update may change route names or groups, causing issues if local rules refer to an old name. For more on retrieving and importing subscriptions and handling exposed links, see the complete subscription link guide. If standard import still fails to parse, give support the client name, platform, panel export format and a redacted error message so they can check compatibility. Don't send your password or full configuration.

An app won't use the proxy: check routing and traffic capture

If your browser works but one app doesn't, “nothing can connect” isn't an accurate description. The app may not use the system proxy, may use its own network components or may be set to connect directly by a routing rule. The destination service may also return an account, region or security restriction. Note the app name, the feature that's failing and the exact message: a sign-in error, content that won't load, a failed file transfer and an account restriction are different symptoms. Don't assume every app error comes from the exit IP or route quality.

Understand the difference between a system proxy and tunnel routing

A system proxy provides a proxy endpoint to apps that follow the system settings, but not every app will use it. A tunnel or virtual interface works at a lower network level and may capture more traffic, but requires the right system permissions. Clients may use different names for these modes; read the explanation in the current interface. Before switching modes, note the original setting and make sure no other app is creating a virtual interface. Don't permanently enable full traffic capture just for one app, especially on a work device where internal services need to remain accessible.

If the client provides connection logs, check for requests related to the app while you reproduce the issue. No request may mean the app isn't using the current traffic path, or that the log doesn't include that traffic; it isn't conclusive by itself. If you see a request, check which rule matched and which outbound route was selected. Focus only on the current issue and don't collect unrelated browsing activity. Crop screenshots to remove other domains and account details so troubleshooting doesn't expose private browsing records.

Check whether the intended routing rule matched

Routing may direct traffic based on domains, addresses, processes or rule sets. Sign-in, content loading and uploads may use different domains, so a working homepage doesn't prove every feature matches the same rule. First check the client's rule-matching information to see whether the failed request went direct, through a proxy or was blocked. If needed, temporarily switch to the client's unified outbound mode for comparison, then restore the original mode. If unified outbound works but rule-based routing doesn't, you've narrowed the problem to the routing rules; there's no need to keep switching regions.

Don't replace your configuration with a large block of unfamiliar rules. Rule order and matching priority affect results, and new entries can change how other apps connect. Before adding a rule for a specific domain, back up your configuration and verify the rule's source. If you're unsure which domains an app needs, give support its name, the feature that failed and redacted rule-match details. An app may update its backend endpoints, so recheck rules that used to work instead of assuming every route suddenly stopped working.

Distinguish destination service restrictions from network failures

If an AI tool or streaming service says a region isn't supported, asks you to verify your account or restricts a request, it has usually received and responded to the request. That's different from a connection timeout. Check the regions and account requirements the service allows, then test a suitable route. VPNHL's coverage doesn't mean every destination service is available in every region, or that a route will always qualify for access. See the AI tools guide and the streaming page; the destination service's response is what matters.

Frequently changing regions after signing in may prompt a service to recheck your session. Keep the account, app and route consistent while troubleshooting instead of switching regions every time you see an error. If the website works but the app doesn't, check the app's network permissions, region settings and cache, then compare traffic-capture modes. Don't give a third party account recovery details to “fix your connection.” A network issue can't be solved by exposing your sign-in credentials. For account restrictions, use the destination service's official support channel.

The app may cache an old connection or region. After switching routes, retry the request first, then fully quit and reopen the app if needed. Before clearing app or site data, check whether doing so could remove local content or sign you out. Don't use uninstalling as your first troubleshooting step. Uploads, live calls and persistent connections may need a stable network, so test again under reliable conditions. If only background transfers fail, also check the system restrictions in the background disconnects section rather than changing routing rules alone.

Include the app name, feature that failed, exact error, traffic-capture mode, rule match and whether the website or other apps work. For ChatGPT route selection, see ChatGPT access and route troubleshooting. After recovery, retest the original feature and your usual internal websites. Make sure a temporary full-traffic mode isn't left as the final configuration; fixing one app shouldn't change the intended route for others.

Device limit alerts and account status: verify the source of your entitlement

VPNHL allows unlimited simultaneous devices. If the client or system says you've reached a device limit, don't assume you need to remove devices or upgrade your plan. First check whether the message comes from the VPNHL panel, the current client, the device's operating system or the destination app. Third-party app licenses, operating system connection limits and destination-service sign-in limits can all use similar wording. Until you know where the message came from, don't treat it as a device limit imposed by this service or pay again based on it.

Find out exactly where the message appeared

Record what you were doing and the full message. If you take a screenshot, include the app title and relevant context, but hide account and device identifiers. A message before the client starts is more likely related to software licensing or system permissions. If it appears in a video app, check that platform's account rules. If it comes from the account panel, preserve the page status and submit a support ticket. A crop showing only “limit reached” isn't useful without the source. Don't uninstall the client from other devices as an unverified fix.

Unlimited devices doesn't mean all devices have identical settings. Each one may use a different subscription source, route, network or traffic-capture mode. If one device works and another doesn't, compare those details and confirm both use the current account's valid subscription. Sharing an account doesn't automatically sync every device's configuration. After changing the subscription source or local rules, check each device in use. A device still using an old configuration may show a different error from the others.

Separate account sign-in from plan availability

VPNHL accounts don't require an email address; sign in with a username and password. A successful sign-in confirms authentication only. Check your plan status and data allowance in the overview. If you forget your account details, use the recovery options actually provided in the panel; don't assume an email recovery method is available. Never give your password to support for testing. For an account-related ticket, you can provide an account identifier and order ID supported by the panel, but not your password, session credentials or subscription URL.

Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date. If your allowance seems depleted, check the panel's records and your plan's activation cycle rather than assuming it should reset at the start of the calendar month. Upgrade price differences are prorated by the remaining days; don't use an invented formula to estimate additional data or time. Use the panel status as the reference. If it doesn't match, keep a screenshot and the relevant order details and contact support.

Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They last until used and never expire. They work differently from monthly subscriptions, so don't use the monthly reset schedule to judge changes in a data pack balance. See the full plan details when choosing a billing option. You don't need to buy another tier just to test device permissions while troubleshooting. Check data allowance, billing period and device entitlements separately so you don't mistake an empty allowance for a simultaneous-device limit.

Payment status, configuration permissions and privacy

VPNHL accepts Alipay, WeChat Pay and USDT. After completing payment, return to the panel to check your order and account overview. The client may still show an old configuration, so update it normally before testing. If the order status doesn't match the payment result, don't repeatedly create the same order. Save the panel order ID and payment confirmation, hide unrelated transaction and personal details, then contact support. You don't need to publish your full payment history or send an unfamiliar account an extra “unlock fee.”

Handle system permission prompts according to your platform. On desktop, make sure the client can create the required network interface. On mobile, check that the system VPN configuration is managed by the intended app. Managed work devices may have restrictions; contact the device administrator rather than bypassing them. On a shared device, confirm the current system user and where the configuration is saved. If the client works for one user account but not another, check local permissions and configuration scope instead of assuming the subscription entitlements differ.

For account and subscription security, see the beginner's security guide. If you think your subscription has been exposed, reset it through the panel and update the source on each device. If you think your password has been exposed, change it using the panel's available options and check your sessions. After recovery, review every device, not just the one you're currently using. Anonymous, no-logs claims are privacy statements; they don't replace your responsibility to protect account details, screenshots and subscription credentials.

Submit a support ticket and verify the fix: make the result reproducible

Troubleshooting isn't finished when a page opens once. You should know where the problem came from, keep the effective settings and restore the original use case. If your local network works, your account is active and the standard subscription is imported, but you can still reliably reproduce the issue, ask for help through a support ticket in the account panel. Reinstalling or switching things blindly may destroy useful evidence. For certificate errors, account and order mismatches or suspected credential exposure, stop making changes, preserve the necessary information and use the appropriate support channel.

Describe the issue so support can diagnose it

Start your ticket with the specific symptom and its impact, such as “The client connects and the browser works, but sign-in to the target app times out,” rather than “The service doesn't work.” Include your platform, client name, network type, route name and when the issue occurred. Include your time zone so support doesn't confuse records from different regions. Use the client details shown in the app; there's no need to guess the version. If the interface shows one, provide it as displayed, but don't invent or infer an update date.

Summarize completed comparisons as findings: whether regular websites work while disconnected, whether switching networks or routes helped, and whether the issue differs between foreground and background. For each comparison, say what you kept constant. “It worked after I changed the device, network and route” doesn't prove that a particular route was at fault. Say “not checked” for tests you haven't done; don't invent results to make a ticket look complete. Support needs a reproducible scope, not as many screenshots as possible.

Share only the necessary screenshots and log details

Keep the error message, app source and relevant status visible in screenshots. Hide usernames, full subscription URLs, access credentials, unrelated order details and personal content. A subscription URL can be copied or read even in a screenshot; tiny text isn't redaction. Include only the log entries around the issue, and remove authentication fields, full request URLs and unrelated domains. If you're not sure whether something is sensitive, describe the error category first and wait for support to specify what they need.

Don't upload your full browsing history, an entire configuration directory or an unchecked system diagnostic archive. These may contain account information unrelated to the issue. Never post test subscriptions, credentials or configurations publicly to ask for help. If you need to show a configuration format, replace real values with clearly fake examples; hiding only part of a URL isn't enough. Connection troubleshooting usually starts with the environment and error details, not your account password. Verify the source of any request for your password or to move the conversation off-platform.

Keep the test conditions stable while you work with support

Whenever possible, add new findings to the same ticket so the history stays together. When following a suggested step, test one change at a time and say whether the original symptom went away or a new error appeared. Don't reset the subscription, switch between clients and change system network settings repeatedly while waiting for a reply; the original advice may no longer match your setup. If you have to change devices or networks, say what changed and whether you can still reproduce the original issue.

If support suggests a temporary change, note why you're making it and how to undo it. Temporarily disabling an extension, switching traffic-capture modes or changing the update path tests a hypothesis; it isn't necessarily the final setup. If the test works, identify the smallest change needed instead of leaving all network traffic under a temporary rule. For managed devices, destination-service account restrictions and local router problems, contact the relevant administrator or service provider. VPNHL route troubleshooting can't replace handling permissions or accounts for other products.

Keep your findings, not unrelated changes

Retest with the original app, content and network to confirm the fix isn't limited to an easier-to-access page. Reopen the client and destination app and make sure the configuration is still saved. If the problem involved locking the screen or switching networks, repeat the same trigger. If the issue seems temporarily resolved but you can't reproduce the fix, say “currently working; cause not confirmed” in the ticket instead of presenting a guess as fact. Keep the relevant error details and last known working configuration so you can compare if the issue returns.

Finally, remove temporary settings, exported logs and screenshots containing sensitive information that you no longer need. Resume any sync tasks paused during testing and restore necessary security settings. For common questions, visit the Help Center. To set up the service again, return to the quick-start guide. The process remains the same: observe, compare, then adjust. Knowing the conditions that cause a problem is more useful for restoring reliable everyday access than repeatedly trying more settings.