VPNStay Troubleshooting Guide

Can't Connect at All: Start with Your Local Network

First, distinguish between a client that won't start and one that starts but can't connect. Startup problems may show up as repeated permission prompts, an unresponsive connect button or an app that closes right away. Connection failures usually mean the client shows a list of routes but stays on “Connecting,” with a timeout or handshake error in the log. Note the exact message before continuing. “The network is broken” alone isn't enough to tell whether the problem is on your device, with your subscription or on the remote route.

Preserve the Current State, Then Check Basic Connectivity

Disconnect the client temporarily, quit other proxy tools and open a website you can normally access directly. If it won't load either, check whether the network requires a sign-in page, whether your device has a valid IP address and whether the router is working. Existing proxy settings can block a public network's sign-in page, so complete sign-in before reconnecting. Switching international routes is unlikely to help until basic connectivity is back.

For each test, use the same device and website, changing only the network you're connected to. If you can connect on another trusted network, the issue is more likely with the original network than with your account. If it fails on every network, check the client and account. Don't change networks, reinstall the app and edit DNS settings all at once. If the problem goes away, you won't know which change fixed it.

Check Your Subscription, Permissions and Current Route

Check your plan status and remaining data in the user panel, then make sure the client is using the subscription you just updated. A route name remaining in the list doesn't mean your account is active or the configuration updated successfully. If you have multiple profiles with the same name, check their source and update time, then select the correct one before connecting. Trying old files alongside your current subscription only makes the symptoms harder to interpret.

The first time you connect, your operating system may ask to allow a network configuration, start a background service or authorize a virtual network interface. These permissions let traffic pass through the client; they're separate from whether a route is available. If you denied a permission, revisit it in system settings or follow the client's prompt. On a managed work device, check with your administrator before changing anything. Don't disable management policies to force a connection.

Try a route in another region or of another type and see whether the error changes. If only one route fails, keep using a working one and note the failed route and time. If every route produces the same local permission error, check the client service. If all routes time out only on one network, check that network. The scope of the failure is usually more informative than a single term in the error message.

Read the Logs Before Making Bigger Changes

A timeout means a step didn't get a response in time; it could happen during DNS lookup, a connection to the remote server or a request to the destination website. A handshake failure can involve a configuration mismatch, an incorrect system clock or a network interruption. An authentication failure calls for checking the account and subscription source. None of these labels identifies the cause on its own. Review the surrounding log entries, check whether the error refers to the route address or the destination, then decide what to investigate next.

Don't start by disabling security software, deleting every network interface or resetting all network settings. Begin with reversible checks and note the original settings before changing them. That way, if the connection comes back, you can restore your previous setup too.

If websites you normally access directly stop loading after you quit the client, check whether the system proxy still points to a local service that has stopped. Turn off the system proxy through the client first, then confirm in system settings. Don't guess at an address or port. Contact support if basic connectivity and your plan are both fine, the subscription updated successfully, but multiple routes still produce the same error on different networks. A continuous, redacted log is more useful than repeated reinstalls.

Connected but Websites Won't Load: Check DNS and Requests

A “Connected” status means one part of the connection process completed; it doesn't guarantee every website will load. Browser traffic also depends on DNS lookup, connection setup, certificate validation and the content request. Start by noting what happens: are all pages blank or just one domain? Does the browser say it can't find the address, time out, show a certificate warning or display an access restriction? Each symptom points to a different part of the connection. Don't treat them all as a dropped route.

Use the Scope of the Problem to Find the Fault

Keep the client connected and try both a website you can normally access directly and the site that's failing. If the first works but the second doesn't, check whether the destination request matches a proxy rule. If both fail, check the system proxy, virtual network routing and DNS settings. If only the browser fails while other apps work, test in a private window to rule out cached data and extensions. A private window may still use system network settings, so this doesn't rule out every proxy issue.

If the domain can't be resolved, DNS probably didn't return a usable result. If it resolves but the connection times out, check the route and network path. For a certificate warning, first verify the system date and time and the domain name. Don't ignore certificate warnings just to continue, and never install a certificate from an unknown source. Some networks that require sign-in redirect requests to a login page; return to the basic connectivity checks instead of changing settings for the destination site.

Check for Conflicting DNS Settings

The operating system, browser and client may each handle DNS. If the browser has its own secure DNS setting, its results may differ from a system lookup. The client may also intercept DNS and apply its own rules. Note the original settings, then follow the client's instructions and use a consistent configuration. Don't enable multiple DNS paths that override one another. A successful system lookup and a failed browser lookup aren't necessarily contradictory; they may use different resolution paths.

On Windows, use a terminal to check your current network settings and look up a public example domain. These commands are for observation and don't include account details. A successful lookup only confirms that system DNS worked for that query; it doesn't prove the target app is using the proxy. Before sharing output with support, redact local addresses, network names and other details that aren't needed to diagnose the issue. Keep the error message and note which interface you queried.

ipconfig /all
nslookup example.com

If you've corrected the DNS settings but the system is still using an old result, run ipconfig /flushdns on Windows to clear the system DNS cache, then reopen the browser. Browsers may have their own cache, so a successful command won't necessarily affect every app right away. On Linux with systemd-resolved, use resolvectl status to check the status. For distributions without this component, use the relevant network management tool instead of copying commands that change settings.

Once DNS Works, Check the Request Route

Open the client's connection log and revisit the page that's failing. Check which rule matched the request and which route it used. If it matched a direct-connection rule, review the routing configuration. If it went through the proxy and you received an error page from the destination, the request reached a server; try another route or check your account with that website. A region notice or login error from a website isn't the same as a local DNS failure, and each needs to be handled in a different place.

Don't use a site's IP address as a substitute for a full connection check. Many sites rely on their domain for certificate validation and content delivery, so a failed IP address alone doesn't prove the route is broken.

If a change leaves you unable to access any websites, undo the DNS change first, then restore the client's previous settings. Keep other variables unchanged while you check whether basic and target websites work. If you contact support, include the destination domain, type of error, system DNS result, client rule match and whether other sites work on the same network. A screenshot that only says “This site can't be reached” usually isn't enough to distinguish a DNS failure from a later connection problem.

Slow Speeds and Peak Hours: Tell Congestion from App Issues

Start by describing what “slow” means. A page that takes a long time to start loading, an interrupted download, a video that keeps buffering and a sluggish interactive app can each point to a different issue. Keep the destination and activity consistent while comparing routes. A speed test can't replace the real-world experience, and one test can't establish how a route performs at peak hours. Look for a repeatable difference rather than a particular impressive number.

Set Up a Fair Comparison

Pause large file syncs, system updates and other downloads on your device, then check whether other devices on your home network are using the connection. Weak Wi-Fi, power-saving settings or a busy router can make international access look like a route problem. If possible, compare a wired connection with your usual Wi-Fi, keeping the route and destination the same. If changing the local network makes a clear difference, fix the connection first instead of repeatedly testing remote routes.

Next, compare routes using the same device, app and content. A geographically closer route isn't always faster; the actual path, your network and the destination's location all matter. If one route loads websites smoothly but another stutters only on a particular video service, note the difference instead of saying “everything is slow.” Include the route name and time of the issue so support can investigate.

Look for a Repeatable Pattern in Peak-Hour Slowdowns

If speeds drop noticeably only during busy evening hours, compare how the same destination performs at different times under similar conditions, including the results of switching routes. Don't run a large number of speed tests at once; they use bandwidth and can make congestion worse. If multiple routes are slow on your usual network but improve on another trusted connection, the bottleneck may be on the local network. If one route repeatedly stalls, share the comparison with support instead of reconnecting to it over and over.

Different route types call for different comparisons, but the label alone doesn't guarantee performance. Test IEPL, relay and direct routes against your current network and destination. Read Global Locations and Route Guide for tips on choosing a route, then test it with the activity you care about. Don't assume a route will be faster everywhere or at every time just because of its label, or treat a change in route type as a reason to edit every client setting.

Check App Settings and Plan Status Too

Video apps may automatically increase playback quality, so if buffering continues after switching routes, check whether the quality changed too. Cloud sync apps may limit background transfers, and browser downloads may be capped by the destination server. Interactive apps depend more on consistent response times, while file transfers need sustained throughput. Comparing different activities can lead to conflicting conclusions. Use the task you actually need to complete rather than relying on an unfamiliar test site to represent every use case.

Check your data and plan status in the user panel so you don't mistake an exhausted allowance for peak-hour congestion. Monthly subscription data resets each month on the activation date; mid-cycle upgrades are prorated by the remaining days. See the Plans page for exact allowances and prices. More data solves a data availability issue; it doesn't speed up every destination. You don't need to upgrade first to test a network route.

If one route consistently performs much worse than a working comparison under the same conditions—time, destination and network—you have useful information to share. Note the task, time, whether background transfers were paused and what changed after switching routes. A single speed test screenshot isn't enough, and an occasional improvement isn't proof of long-term performance. Support needs reproducible conditions to assess whether you should switch routes or investigate your local network.

Frequent Disconnects and Background Drops: Find When the Connection Breaks

A connection may drop when you switch networks, the device goes to sleep, an app moves to the background or while you're actively using it. Note what you were doing just before the interruption, whether the client icon was still visible and whether the connection recovered automatically or needed to be restarted when you returned to the app. If it happens only after the screen locks, check background management first. If it also happens with the screen on, look at the route and network. Checking only the “Connected” status after recovery can hide when the drop occurred.

Distinguish a Tunnel Drop from an Expired App Session

A video stopping or a remote work session disconnecting doesn't necessarily mean the proxy connection dropped. Try another website and check the client status and nearby log entries. If other sites work, the target app's session may have expired or the service may have closed the connection. If all access fails at once and the log shows a reconnect, the tunnel or underlying network is more likely to have dropped. Keeping these cases separate helps avoid rebuilding the entire configuration unnecessarily.

When you switch from Wi-Fi to a mobile network or move between wireless access points, your route and network path may change. Existing long-lived connections may not carry over, and an app may need to refresh its session after the client reconnects. Test on a single network first to see if the connection still drops while stationary. If it happens only during a network switch, note the direction of the switch and how the connection recovers; don't mix a moving-device test with a stationary-network test.

On Mobile, Check Background Activity and Battery Settings First

On Android, battery optimization, background activity limits and manufacturer task managers may stop the client when the screen locks. In the system's app settings, check that the client is allowed to run in the background as needed and has the required notification permission. Menu names vary across devices, so look for the relevant function rather than matching an unfamiliar screenshot word for word. Don't turn off every power-saving feature at once. Change settings for the client first, then lock the screen again to see whether it helped.

On iOS, the connection usually runs through a network extension managed by the operating system. In Settings, check which configuration is enabled and whether another network tool has replaced it. A connection icon doesn't mean the target app's session has recovered; return to the app and request the content again. If configuration permission prompts keep appearing, check for duplicate or outdated profiles. Before deleting one, make sure you can get the current configuration again so you don't remove the only working profile.

Force-quitting an app from the task switcher isn't the same as letting it run in the background. Some systems treat a force-quit as an instruction to stop background activity. When investigating background drops, compare what happens after the screen locks normally with what happens after you force-quit the app. Also note whether the device is in low-power mode. Keeping the screen on can help isolate a background-management issue, but it isn't a lasting fix.

On Desktop, Check Sleep, Network Interfaces and Services

After waking from sleep, Windows and macOS may bring the network interface back after the app, temporarily invalidating the existing connection. Wait for basic connectivity to return, then see whether the client reconnects. If the problem occurs only after waking, check the client log for interface changes and service status before changing subscriptions. On Linux, check whether the network manager recreated the interface and whether the background service is still running. The exact steps depend on how the client was installed.

If disconnects continue on a stable network while the device stays awake, compare another route and then another network. If only one route drops, keep a working alternative and report the route. If it happens on every route but only one network, check the router and local connection. If multiple proxy or security tools manage network traffic, preserve the work setup you need and test one tool at a time as permitted by your administrator to avoid conflicts.

Military-grade encryption protects the connection; it doesn't prevent drops caused by a locked device, network changes or an expired app session. To restore a stable connection, check both system background management and the app's reconnect behavior.

When reporting a disconnect, say whether it happened in the foreground, after the screen locked or after switching networks, and whether other websites failed at the same time. Include continuous logs from before and after the interruption, with the local time and time zone. Logs that begin only after a successful reconnect may miss the cause. Keep a working route and recovery method available; there's no need to keep changing network settings during an important session.

Subscription Update Failed: Separate Fetching, Parsing and Activation

Updating a subscription involves several steps: the client fetches the configuration, parses it and then sets it as the active profile. A fetch failure may be a network or account issue. A parsing error may mean the import method doesn't match the format. If the update succeeds but you're still using an old route, the new profile may not be active. Find out which step failed before deciding whether to fetch the subscription again from the panel or fix the current profile in the client.

Check the Subscription Source and Account in the Panel

Check your current plan and data status in Account Overview, then get the subscription from the panel. Don't use an old link forwarded in a chat or treat someone else's configuration as your own. VPNStay accounts don't require an email address; you can create one with a username and password. When troubleshooting, make sure you're signed in to the account you actually use so you don't check the wrong plan status.

Treat your subscription URL like a credential. Don't paste it into public forums, search boxes, online format checkers or unfamiliar tools. Hide the full URL and import QR code in screenshots, and redact request URLs in logs. Support generally needs the error type, client environment and steps that triggered it—not your full subscription credentials. If you think the URL has been exposed, use the account panel's available management options and ask support what to do next.

If Fetching Fails, Check the Network and Copied URL

After copying the subscription again from the panel, check for spaces, line breaks or extra text. Some fields accept only a subscription URL, not a full block of shared content; other import options accept only a local configuration file. Follow the prompt for the import method you're using. Don't save the URL as file contents and repeatedly try to import it as a file. If the panel opens but the client can't fetch the subscription, check whether the update request is still going through a stale proxy setting or failed route.

Some clients let subscription updates use the current proxy or connect directly; the exact setting name depends on the client. If the current route is down and updates depend on it, you can get stuck in a loop. First check whether your basic network can reach the panel, then adjust the update route using a method supported by the client. Don't send your subscription to a third-party conversion service for testing; that increases the risk of exposure and makes the configuration source harder to track.

Handle Parsing Errors Separately from Old Profiles

If the content was fetched but parsing failed, check that you selected the import method intended for your client in the panel. Clients may use different formats and support different features; similar names don't mean they're interchangeable. If the error mentions an unknown field or unsupported type, save the exact message and verify where the client came from. Don't delete unfamiliar fields just to force the configuration to parse. The connection might appear to work while losing essential routing or DNS rules.

After a successful update, check that the new profile is active, then review the route list and connection log. Some clients preserve manual selections, temporary rules or old route groups, so an update may not remove personal settings. Check that the selected route still exists and look for manual overrides. Don't judge success only by changes in the number of routes; a configuration can update its settings without changing the count.

Before importing again, note the current profile's source name and any custom rules you need. Keep backups somewhere trusted. Don't send a file containing subscription credentials as an ordinary screenshot or attachment.

Don't Reinstall to Fix Data or Billing Questions

Monthly subscription data resets on the activation date, not at the start of each calendar month. Data packages stay valid until used and never expire; that refers to their validity period, not continued access after the data is used up. If the status in the panel doesn't match what you expect, check the order and account, then contact support. Reinstalling the client won't change your account allowance or combine different billing options into a new one.

If the basic network works and the panel is accessible, but a freshly fetched subscription still fails consistently, include the import method, failed step, client platform and redacted error text in your support request. Say whether the old profile still connects and whether the failure occurs during fetching, parsing or activation. For the initial import steps, see Quick Start. If you're stuck getting the client on iOS, see Set Up Your iPhone from Scratch. Download access and subscription parsing are separate issues.

An App Isn't Using the Proxy: Check Traffic Capture and Routing

If a browser can open a site but one app consistently fails, first check whether the app's requests reach the client. System proxy settings, virtual network routing and an app's own proxy are different mechanisms; enabling one doesn't cover every program. Check the connection log before deciding whether to inspect routing rules or app settings. If no request appears, check traffic capture. If the request appears but uses the wrong route, check routing. If it uses the right route and still fails, check the destination service.

System Proxy Settings Don't Cover Every App

System proxy settings provide a proxy to apps that read those settings. Some desktop apps use their own networking libraries, some command-line tools rely on environment variables and some apps have separate proxy settings. So a working browser doesn't prove that every app is using the proxy. Check the app's official network settings to see which method it supports. Don't copy a fixed address and port from an unfamiliar guide; use the values shown in your local client.

If the client offers virtual network routing, it may handle more traffic through a virtual interface, but this can also involve system permissions, routes and DNS. After enabling it, test both basic connectivity and the target app rather than assuming the switch means it's working. On a managed device or one using a work tunnel, check compatibility requirements first. Don't change your organization's network routes just to get one app working.

Use the Connection Log to Find the Matching Rule

Fully quit the target app and reopen it. Trigger a specific action, such as refreshing a page or loading content, while watching the connection log. Check the destination domain, process details, matched rule and outbound route. If nothing changes, the app may be using cached content or an existing long-lived connection; don't assume traffic bypassed the client. First make sure the action generated a new request, then compare it with the log for the same service in a browser.

If the request matched a direct-connection rule, look for custom domain, process or region rules. Rules often have an order, and an earlier match may override later choices. Back up your custom settings, change only the rule relevant to the destination and then start a new app session. Don't delete the entire rule set for one domain or route every unfamiliar domain through the proxy; that broadens the impact and makes future maintenance harder.

Temporarily switching to a broader proxy mode can help determine whether routing is the issue, but treat it only as a diagnostic comparison. If the app works afterward, switch back to rule-based routing and find the difference. If it still fails, check the app's own proxy settings, connection method and server-side restrictions. Restore your preferred everyday mode when testing is done, especially if you use local devices, work resources or LAN services.

Test AI, Video and Gaming Apps Separately

AI tools may use different domains for sign-in, content requests and real-time responses, so loading the home page doesn't prove every feature works. Streaming can also depend on account region, content rights and the exit location; start a new playback session after switching routes. Games and real-time communication may use different transport methods than ordinary websites, so working web access doesn't prove an app is compatible. Note the specific action that fails rather than just naming the product.

If an app is using the proxy but the service returns a clear account or region message, keep the exact text and check the account status and the destination service's rules. Repeatedly clearing local network settings usually won't change a server-side decision. For streaming, see Streaming and Regional Access Guide and test the specific content. A connected route doesn't guarantee that every title will play, and a page returned by a website isn't the same as a connection timeout.

For differences between global proxy mode and routing in Windows desktop apps, see the Windows Client Checklist. Use your local connection log—not the mode's name—to diagnose the issue.

When contacting support, include the app name, platform, action you took, exact error text and matched rule. Say whether the same service works in a browser. Redact private session titles, paths and account identifiers from logs. Don't send passwords, login credentials or full browsing history. Clearly stating “the request never appeared,” “it appeared but matched the wrong rule” or “the destination refused it on the correct route” can narrow down the issue considerably.

Platforms and Multiple Devices: Identify Local Conflicts and Limit Messages

VPNStay supports Windows / macOS / iOS / Android / Linux, with no limit on the number of devices that can be online at once. A message such as “device limit reached” doesn't mean VPNStay has an undisclosed device cap. It may come from the client, system network settings, a third-party app or the destination website. Check which window showed the message and what you were doing before deciding where it came from. Don't delete other devices just to dismiss it.

First Find Out Who Set the Device Limit

Check the panel, client and destination app separately to find out which one returned the limit. Video and workplace services may have their own session rules; those don't apply to VPNStay's simultaneous connection policy. If you confirm the message is related to a VPNStay feature, save the full text, where it appeared and your account status at the time, then ask support to verify it. Don't assume you need to upgrade to connect more devices or switch to an unrelated plan.

Problems across several devices provide a useful comparison. If they use the same router and route and fail around the same time, check the shared network and route first. If only one device fails while others work under the same conditions, check that device's permissions, configuration and background settings. Keep the destination and route consistent when comparing; don't compare video playback on one device with a web page loading on another.

Platform-Specific Checks That Are Easy to Miss

On Windows, seeing the client open doesn't prove its background service is working, and quitting the app doesn't mean the system proxy was restored automatically. Check service messages in the client, then verify the current system proxy settings. On macOS, network extension authorization is separate from ordinary app permissions and may need to be confirmed again after a system upgrade or migration. Address explicit system permission prompts before blaming a remote route.

On mobile, distinguish the network configuration managed by the operating system from the status shown in the app. Enabling another network tool may replace the active configuration; check battery management too if the client drops in the background. On Linux, desktop proxy settings, terminal environment variables and background services may be separate. It's not unusual for a browser to work while a command-line tool fails. Note your desktop environment and installation method rather than simply reporting “Linux isn't supported.”

Check Duplicate Clients and Leftover Settings One at a Time

Running several tools that manage network traffic can cause system proxy settings to be repeatedly overwritten, virtual interfaces to compete or DNS paths to conflict. Quit nonessential tools and check whether their background components are still running before testing the current client. Ask your administrator before closing software required for work. If quitting one tool fixes the problem, note the conflicting combination and startup order to help configure them to work together.

If you need to download the client again, use the download link in the user panel. Sign in to download for Android, Windows, macOS and Linux; an active plan is required for the iOS link. Download access and network issues are separate, so check the requirement shown in the panel. Don't look for unofficial static installers or assume an older client is compatible just because it still launches; check whether its configuration method matches the current panel.

Reinstall only after confirming that the app files or local state are the problem; it isn't a universal first step. Before reinstalling, note the subscription source, current rules and original system proxy settings, and make sure you can get the configuration again. After uninstalling, check basic connectivity before importing the current subscription. If the same configuration works on another device but fails on this one after permissions are granted again, tell support the platform, error text and conflicting tools you've already ruled out.

Support and Recovery: Explain How to Reproduce the Problem

You don't have to keep troubleshooting indefinitely. Once you've confirmed that basic connectivity and your account are fine and completed a repeatable route or device comparison, ask for help through the support ticket system in the user panel. Stop making broad changes and contact support if your account status doesn't match your order, a subscription consistently fails to parse, you see a clear server-side error or you receive an unexpected certificate warning. Further blind changes can make a clear issue harder to reproduce.

Describe the Symptom First, Then List What You've Checked

Start your ticket with a plain-language description of what happened, such as “The client says connected, but the target page keeps loading while other sites work.” Include the approximate time and time zone, platform, network type, route name and exact error. Avoid vague phrases like “it's slow” or “it doesn't work,” and don't assume the server is at fault. Separate what you observed from what you suspect so support can follow the evidence instead of investigating the wrong assumption.

Then share the comparison results: whether switching routes or networks changed anything, whether other devices on the same account work, and whether basic websites load with the client off. For each item, say what you actually tested; if you haven't tested something, say so. If the device is managed by your organization, mention that too to avoid receiving unsuitable network reset instructions. Clear conditions matter more than the number of steps you've tried.

Share Only the Log and Screenshot Details Needed to Diagnose the Issue

Logs should cover the failed action and the surrounding events, with the relevant section marked. A screenshot of the last error line may miss an earlier DNS or interface change; a complete long-term log may contain irrelevant details. Keep the original locally and make a redacted copy. Hide subscription URLs, import QR codes, account credentials, private destination paths and unnecessary local network identifiers, but keep the error type, route name and time so support can follow the clues.

If support asks for more diagnostic information, confirm how it will be used and share only what's relevant to the issue. Never send your password, full subscription credentials or anything that can be used to sign in to your account. Don't run remote scripts from unknown sources. Before changing system proxy, routing or DNS settings, record the original values and confirm how to undo the change. Follow your organization's device management requirements on work devices.

Before submitting, check: Can you reproduce the issue with the same steps? What happens to other websites when it fails? Which changes helped, and which made no difference? These details are often more useful than additional screenshots.

After Recovery, Verify the Full Connection

Once connected again, don't stop at the status indicator. Check a basic website, then the destination that originally failed, and finally repeat the task in the app you actually use. For video, play the same content; for work, reconnect to the session; for background issues, lock the screen and check again. If switching routes only fixed things temporarily, keep a record of the original route issue. If undoing a setting helped, note the change and avoid piling on other tweaks right away.

Restore any temporary diagnostic mode to your preferred everyday setup and make sure the system proxy, DNS and virtual network settings aren't conflicting. Review terminal environment variables and browser-specific DNS settings if needed. Before deleting a test profile, make sure you can get the active one again and keep notes on any custom rules. If the problem comes back, you can start with recent changes instead of testing every setting from scratch.

Handle Billing, Refunds and Technical Issues Separately

If the issue turns out to be related to your plan or data, check the plan details instead of continuing to change network settings. VPNStay supports Alipay / WeChat Pay / USDT and offers a 60-day no-questions-asked refund policy. See the Refund Policy for application details. You can describe a support issue and refund request separately; you don't need to share private browsing details to prove a network problem. The refund policy doesn't guarantee access to every destination service.

Keep routine maintenance simple: get the current subscription from the panel, use a trusted client source, avoid running multiple tools that manage network traffic, and note original settings before making changes. For initial setup, follow Quick Start; for short answers to common questions, visit the Help Center. This guide breaks complex symptoms into small, testable questions. Once you have enough evidence, share it with support instead of continuing to troubleshoot without a clear direction.