VPN Connection Troubleshooting Guide

Can’t connect at all: narrow down the cause

If you can’t connect at all, your local network may be down, the client may have failed to connect, or the connection may be up while the destination remains unreachable. First note the exact status shown in the client: connecting, connection failed, authentication failed, timed out or connected. Don’t lump these together as “not working.” Each points to a different stage and calls for different next steps. If there’s an error, save a screenshot with sensitive details obscured before dismissing it.

Confirm that your basic internet connection works

Disconnect the client and open a website in your browser that normally loads directly. If that fails too, check your local connection first: make sure Wi-Fi is actually connected, the router can reach the internet, and any public Wi-Fi sign-in page has been completed in your browser. A signal indicator doesn’t necessarily mean you have internet access. Repeatedly updating your subscription or switching routes is unlikely to help, since the client also needs this basic connection to reach its server.

If only this device can’t access websites directly while other devices on the same network work, check for a leftover manual proxy setting. Some clients may leave the system pointing to a local proxy process that has stopped after an abnormal exit. Turn off the system proxy properly from the client, then check your system’s network proxy settings. Remove only settings you can confirm belong to an old client. Work devices may be centrally managed; don’t remove managed proxies or certificates without permission.

Cross-check your account, route and network

Once your basic network is working, open the user panel overview and check your account, plan status and remaining data. Being able to sign in to the panel doesn’t necessarily mean your subscription is active, and a route name saved in the client doesn’t mean it has the latest configuration. If the panel status doesn’t match your payment record, keep the order status and contact support—don’t pay again just to check. If the panel won’t load, first try a network you’ve confirmed is working.

Next, try a different route—ideally one with a different connection type, not just a different name in the same group. If the original route fails but another works, the problem is likely limited to a particular route or access path. If all routes fail, leave the client configuration unchanged and try another available network. If that fixes it, focus on restrictions, router settings or connection quality on the original network. Don’t assume the account is at fault.

Pinpoint the stage where the error occurs

For authentication errors, check that the subscription belongs to the current account, isn’t outdated, and the device date is correct. For connection timeouts, check the access network and route. For certificate errors, check the system time, client source and any managed network settings. Don’t disable certificate validation to hide the problem. If the client hasn’t prompted for network extension permission, check its status in system settings; without approval, the connection action shown in the app may not actually take effect.

If the device time is clearly wrong, enable automatic date and time zone in system settings, then reopen the client. The encrypted handshake checks certificate validity, and an incorrect local time can cause failures that look like route issues. Don’t import unfamiliar certificates, disable system security checks or run repair scripts from unknown sources. For organization-managed devices, ask the administrator which network access methods are allowed.

If you’ve completed these checks and your basic network and plan are working, but changing both route and network still doesn’t establish a connection, open a support ticket. Include the exact error, client name, operating system, routes tried and results from comparing networks. If only one route fails, mention which other routes work. If the issue occurs only on one network, say so clearly. This helps support check the right stage without asking you to repeat every step.

Connected, but websites won’t load: check DNS and the access path

“Connected” usually means the client completed a connection step; it doesn’t guarantee that every website request will succeed. First determine whether all websites fail, only international sites, a particular domain, or whether the page loads but images or sign-in requests fail. Websites often request resources from multiple domains, so seeing a page title doesn’t mean everything loaded. The exact browser error is more useful than simply saying the page keeps spinning.

Check name resolution separately from the website connection

DNS resolution translates a website name into a network address. The connection and data transfer happen afterward. If resolution fails, the browser may say it can’t find the server. If resolution succeeds but the connection fails, the cause could be the route, routing, destination site or proxy rules. Don’t draw conclusions from an error label alone. Browser, system and client DNS caches or resolvers may work at different layers, so compare results for the same domain.

You can use a built-in system lookup tool to check whether DNS returns a result. The command below queries a public example domain to confirm that the command runs and the current DNS path responds. For troubleshooting, replace it with the public domain that’s failing. Don’t enter a full URL containing account information. If the command isn’t available, there’s no need to install unfamiliar tools for this check. Also, a local DNS result doesn’t necessarily show how the domain resolves through the proxy.

nslookup example.com

If the lookup times out, first check whether the system uses manual DNS, whether the client handles DNS, and whether that DNS path depends on a connection that hasn’t been established. If the lookup succeeds but the website fails, check the client connection log for the domain, the matching rule and the selected route. Successful DNS resolution rules out only some causes; it doesn’t prove the route is working or that your browser used the same DNS settings.

Check whether your browser and system use different settings

Secure DNS in the browser, standalone proxy extensions and the system proxy can overlap. Keep a record of the original settings, then temporarily disable proxy extensions you installed so the browser follows the current client. If you want to test whether Secure DNS is involved, change only that setting and decide afterward whether to keep the change. Don’t disable DNS handling, switch to global mode and change routes all at once, or you won’t know which combination works.

Refresh caches and check proxy handling

Once you’ve checked the settings, fully quit and reopen the affected app to clear old connections. If needed, use your operating system’s network diagnostics or cache refresh tools, but don’t start by resetting all network settings. A reset can erase saved connection details and organization settings, which is a much bigger step than reconnecting an app. If only one browser is affected, compare it with a fresh browser session instead of deleting all your personal data.

If the client uses a virtual network adapter or DNS mapping mode, testing a website by its network address isn’t reliable. Encrypted websites may require the domain to match the certificate, and mapped addresses may only make sense within the client. Don’t assume the site is offline just because its address won’t open. Instead, keep the domain unchanged and check the matched rule, selected route and exact browser error.

If the same domain keeps failing across different routes and networks while other websites work, check the destination service’s status, regional availability and account requirements. In a support ticket, include the public domain, time of failure, whether DNS returned a result, the browser error and the client’s rule log. Don’t include sign-in callback parameters or access credentials. If unfamiliar DNS settings came from unknown software, investigate that software rather than adding more DNS tools.

Slow speeds and peak-hour slowdowns: find the bottleneck

Break “slow” down into something you can observe: does a page take a long time to open, does video keep buffering after playback starts, are downloads consistently slow, or do interactive tools lose their responses? These symptoms can involve different parts of the connection. A slow first load may involve DNS or the handshake; slow transfers over time may be caused by Wi-Fi, the access network, route congestion or the destination service. Note what you were doing and where it stalled. A client speed test doesn’t capture the whole experience.

Compare using the same task

Choose the task that’s actually affected and keep the device, app and content the same. Change only the route and compare the results. Then switch back to the original route and try another available network. Download speeds on different sites, video quality on different videos and results from different accounts aren’t directly comparable. Cache effects can make a second visit seem faster, so check whether it stays usable instead of judging by a single page load.

First pause large transfers on your device and other devices on the same local network, such as system updates, cloud syncing and downloads. A normal-looking Wi-Fi indicator doesn’t rule out interference or router load. Move closer to the access point or, if possible, compare with a wired connection. If regular websites and local network tasks are also much slower with the client off, troubleshoot the basic network first. Switching to a more distant exit may not help.

Is it slow only at peak times, or all day?

If the issue occurs at peak times, note when it happens and which network you’re using, then compare the same task outside peak hours. If only one route slows down at certain times, trying a different access path gives you more useful information. If all routes slow down together but switching networks fixes it, the original access network may be the common bottleneck. Don’t treat peak-hour performance as fixed: routes in the same region can take different paths, so choose based on the task at hand.

The region in a route name usually describes the exit location, not the full path from your device to that exit. A shorter distance can reduce some transmission time, but doesn’t guarantee less congestion. A farther exit may avoid a particular routing issue, but can add latency. See the locations page for the differences between IEPL dedicated lines, transit and direct connections, then compare routes for your needs. Don’t choose one route for every app based only on the region or connection type in its name.

Continue with checks for your specific use case

If video starts but then buffers, first rule out other downloads using your connection. Then let the app choose video quality automatically and see whether buffering continues. If only a particular platform or title fails, content delivery or regional availability may be involved; see the streaming guide for more checks. Don’t change your account region, browser settings and exit location all at once. That adds variables and may trigger the service’s own account checks.

If an AI tool loads but generation stops, note whether the browser reports a connection error, the service shows a restriction, or the long-lived connection stops responding. Waiting for the service to process a request isn’t always a network issue. If the same account message appears after switching routes, more plan data won’t fix it. Use the AI tools guide to check the access path. In a support request, say whether the issue occurs during sign-in, upload or generation.

Before adjusting a virtual network adapter, packet size or transport settings, confirm that the client supports the option and save the original value. Bigger settings aren’t always faster, and someone else’s settings may not suit your network. Use the client defaults unless you have clear evidence to change them. If only one app is affected, check its connection path first instead of changing the whole network and disrupting other tasks that work.

A plan’s data allowance describes how much data you can use; it doesn’t mean a particular plan guarantees higher speeds. VPNTape monthly subscription data resets monthly on the activation date; if you upgrade mid-cycle, the price difference is prorated for the remaining days. See the plans page to compare allowances, and don’t upgrade just because of one slowdown. If a peak-hour issue persists after ruling out local network use, send support the task, time, route and network comparison results for further investigation.

Frequent disconnects and background drops: check the connection lifecycle

First determine whether the client actually disconnected or an app’s existing session expired. If the client still says connected and other websites work, but one page asks you to sign in again, the issue may be the destination service’s session or a change in exit location. If the client explicitly shows disconnected, check the process, network changes and system permissions. Note whether the drop followed a screen lock, network switch, sleep, wake or the launch of another network tool. These details often explain more than the route name.

Works in the foreground, fails after locking the screen

Mobile devices may limit background app activity to save power. First check whether the connection stays stable with the screen awake and the client in the foreground, then try to reproduce the issue with the screen locked. If it happens only in the background, check battery optimization, background activity permissions and network extension status in system settings. Menu names vary by device, so look for the relevant function rather than an exact label. Change only the permissions the client needs; don’t disable power management across the whole system.

On Android, the system may stop the connection service if it clears the app, restricts background activity or switches networks. Check whether the client is allowed to run in the background and whether a cleanup tool is repeatedly stopping it. A persistent system notification can help indicate that the app is running, but doesn’t guarantee access to a website. Once the app returns to the foreground, check the actual connection and test the original app. Don’t mistake a cached page for a restored connection.

On iOS, check the system VPN status and network extension permission, and note whether the issue began right after switching Wi-Fi networks. The client interface and system status may briefly be out of sync, so check the app again before testing access. Don’t repeatedly delete and recreate system configurations in the hope that it helps. If you see a configuration conflict or permission prompt, make sure the configuration belongs to the client you’re using. On managed devices, follow your administrator’s requirements.

Sleep, wake and network changes

After a desktop device wakes from sleep, its previous network connection may no longer work even if the app still shows the old session. Wait for the basic network connection to return, reconnect the client, then reopen the affected app. If the device switches between Wi-Fi and Ethernet, check that the default route was updated. Older downloads or long-lived connections may not resume seamlessly. The app may need to retry after the client reconnects, so don’t judge the route only by whether an old task resumes.

If switching networks changes your exit location, some websites may ask you to confirm your account again. That isn’t the same as a client disconnect. Check whether other websites still work, then follow the destination service’s instructions. Avoid repeatedly changing regions during a sign-in check, as that can make account verification less predictable. For tasks that need a longer uninterrupted session, pick a route that works and stick with it to avoid unnecessary changes.

Check for conflicts with other network tools

Running multiple proxies, virtual network adapters, work network access tools or packet capture apps can cause routes and DNS settings to keep changing. Properly quit tools you don’t need for this test before starting the current client. Closing a window may not stop its background service, so check the tool’s own exit status. Don’t force-quit system processes to stop a tool. If you’re unsure what a process does, keep the details and ask your device administrator or support.

Automatic route selection or failover may also change the active exit. First check whether the client has these features enabled, then decide whether to temporarily pin a route for comparison. Don’t assume every client works the same way or import an unfamiliar configuration if you can’t find the option. If pinning a route fixes the issue, note the automatic mode’s rules and switching behavior. If the disconnects continue, compare networks instead of repeatedly changing the same setting.

If disconnects continue in both foreground and background, and changing the network or route doesn’t help, provide the operating system, client name, power state, action that triggered the issue and relevant logs with sensitive details obscured. If it happens only after locking one device, say that other devices work. After reconnecting, reproduce the original trigger—lock the screen, wake the device or switch networks—and test actual app access. Reconnecting successfully in the foreground alone doesn’t confirm that the background issue is fixed.

Subscription update failed: distinguish fetching, parsing and account status

A subscription update isn’t the same as a connection to a route. The client typically fetches subscription data, then parses it and loads the configuration. An update can fail during the network request, account authorization, content parsing or local save. Note whether the error says the request timed out, content couldn’t be fetched, the format isn’t supported, or no routes appeared after loading. Don’t delete the existing configuration just because an update failed. If it still works, keep it as a fallback while you check the update path.

Verify the source in your panel

Open the user panel for the current account and check the plan status and subscription entry. Don’t guess the current address from chat history, an old screenshot or browser history. Use the panel’s copy or import function to avoid extra spaces, line breaks, missing characters or escaped text. If the client shows a subscription name preview, check only that the source and account match. Don’t include the full address in a public screenshot as proof that you copied it correctly.

A subscription URL usually contains account access details and should be treated as sensitive information. It isn’t an ordinary tutorial link to share publicly, and you shouldn’t paste it into an unfamiliar website for conversion. For the basics of finding and importing a subscription, read the VPN subscription link guide. This page focuses on identifying the stage where something failed, not providing real subscription examples. To retrieve your details, always use the user panel.

Handle fetch errors and parsing errors separately

If the request times out, first check that the panel and basic network are working. Depending on the client’s settings, subscription update requests may use a direct connection or follow the current proxy mode. If the current route has stopped working and the update depends on it, the client may not be able to recover on its own. On a network you’ve confirmed is available, adjust the update request path using an option supported by the client. Don’t assume the request always uses the current exit.

If the format isn’t supported, check whether you’re using an import option intended for this client and whether you’ve entered a webpage URL instead of subscription content. The client may also report a parsing error if it fetched a sign-in page, error page or network access confirmation page. Switching route names won’t help; check the content source first. Don’t edit the subscription text to work around the error, as this can remove rules, certificate settings or other required fields.

Some clients keep using the previously selected configuration after an update, or require you to select the newly imported one before it takes effect. Check that the active configuration name and route list match the update result. If both old and new configurations are present, keep the working one until you’ve confirmed the new one connects. Don’t assume the newest item is at the top of the list, and don’t mix subscriptions from different accounts or repeatedly overwrite them.

Keep data allowance and subscription validity separate

A client fetching routes doesn’t mean the account has usable data. Conversely, an active plan doesn’t guarantee that a subscription URL saved locally is still valid. Check the panel status and the client’s update result separately. Monthly subscription data resets monthly on the activation date; don’t assume it follows the calendar month. Data packs don’t expire and remain usable until depleted, but you still need the correct account details and a working client configuration. These facts don’t replace checking which stage failed.

If a subscription may have been exposed, don’t assume the issue is resolved by changing its display name or deleting a chat message. Whether copied details stop working depends on completing the relevant change on the account. After a reset, older devices may still use outdated configurations and show errors, so check the imported status on each one. When sharing screenshots, obscure both the QR code and URL parameters. The code and text may contain the same sensitive details, so hiding only one isn’t enough.

Open a support ticket if fetch errors persist or content from the correct source still can’t be parsed using an import method the client supports. Include the exact error, client name, import method, panel status and whether an older configuration still works. Don’t send the full subscription URL, password or original configuration file. If support needs additional material, confirm the secure submission method and share only the minimum necessary after taking appropriate precautions.

An app isn’t using the proxy: trace its rules and process

If your browser works but one app doesn’t, the problem is already more narrowly defined. On the same device and route, test the service’s website and compare it with the app. A working website only confirms that its web access path works; the app may request different domains, use a different transport or ignore the system proxy. Don’t immediately reinstall the entire client or assume the service blocks all access.

System proxy and virtual network adapters cover different traffic

An app must follow the system settings to use the system proxy. Some programs use their own network stack or separate proxy settings. Virtual network adapter mode handles traffic at a different layer, but still depends on permissions, routes and exclusion rules. It doesn’t mean every problem will disappear once it’s enabled. First check which mode the client is using, then confirm that the target app supports it. If the menu labels differ, follow the feature description rather than searching for a specific wording.

Developer tools may also read environment variables at startup, while browsers may simply follow the system proxy. A running process may not pick up settings changed afterward, so properly quit and reopen the target app before checking its connection log. Terminals, editors and their child processes may inherit different environments. Don’t put proxy settings in public project files or commit them to a repository, where they could leave other users with incorrect configuration.

Check which rule matched in the connection log

Open the target app and reproduce the issue while checking the client’s connection log. If no related request appears, the app may not be routed through the client, the request may still be in an old session, or it may use a path the client doesn’t cover. If the request appears, check the matched rule, selected policy and actual exit. The app’s displayed name may differ from its process name, so don’t search only for the brand shown in its interface or mistake an updater for the main app.

If the request matches a direct-connection rule, save the original configuration and temporarily use the client’s existing global proxy mode for comparison. If it works in global mode, the split-tunneling rules are worth checking, but that doesn’t automatically make global mode the right long-term fix. Find the specific domain or process and adjust the rules using a method supported by the client. Restore the original mode after testing so apps that should connect directly don’t get a different route and develop new sign-in or access issues.

An app may use different domains for sign-in, resources, uploads and real-time communication. Adding only its homepage domain to a rule may not cover the entire workflow. Check the connections at the stage where the issue occurs instead of adding broad rules based on a guess. Rule order matters too: an earlier exclusion may prevent later rules from running. Save the original rules before making changes, then retest only the relevant action and confirm the result makes sense before continuing.

Service restrictions after a successful connection

If the client confirms that a request used the expected exit but the app shows a region, account or permissions notice, keep the exact wording. A working network path doesn’t mean the destination service allows every account to use every feature. An AI tool’s editor, browser and API may each have their own requirements, so success in one doesn’t guarantee success in another. Check the destination service’s guidance instead of continually adding proxy rules.

For streaming issues, distinguish connection failures from messages shown by the service. Exit location, account region and content delivery may all affect the result. Switching routes changes only some of these factors and can’t guarantee that every title will play. If a route that worked before now returns a clear service error, share the region, content type and error text with support for investigation. Don’t submit your full account page or playback history containing personal details.

If only one app keeps failing, note in your ticket whether its website works, which routing mode is enabled, whether the request appears in the connection log and what happened when you temporarily changed modes. For developer tools, share only the necessary configuration key names and error details with sensitive information obscured. This helps support distinguish an app that isn’t being routed, a rule issue and a destination service restriction, instead of resetting the entire network for a local problem.

Device warnings and system conflicts: verify where the message comes from

VPNTape supports unlimited simultaneous devices. If you see a “device limit exceeded” warning or similar message, don’t assume you need to pay for more device slots. First find out whether it came from the user panel, network client, operating system or destination service. Limits at different layers mean different things: the destination service may restrict its own sessions, while a client may have separate authorization requirements. Neither should automatically be attributed to VPNTape’s simultaneous device policy.

Separate account mix-ups from device limits

First check that the account in the panel matches the subscription imported on the device. A family device, old computer or migrated system may retain a different configuration with a similar display name. Seeing the same route list doesn’t prove the configurations belong to the same account. Verify the source in the panel and check which configuration is active in the current client. Don’t share your account password with anyone to troubleshoot, and you don’t need to sign out of every device before you start.

Unlimited devices doesn’t mean each device has its own separate data allowance. Check the account data status shown in the panel, and see whether other devices are downloading or syncing continuously. If this device slows down only while other tasks are running, look at shared network capacity and data usage rather than looking for a device-limit upgrade that isn’t needed. For official details on allowances, billing and refunds, see the plans page and support page.

Check separately where the system handles the connection

On Windows, check that the client is running, the system proxy points to the current process and the virtual network adapter has the required permissions. On macOS, check network extension permissions as well as the system proxy, particularly after switching configurations. Repeatedly clicking connect won’t replace a denied system permission. If an organization-managed device restricts network extensions, ask the administrator instead of removing management settings to force them on.

On Linux, desktop proxy settings, terminal environments and background services may be separate. A desktop browser working doesn’t mean terminal programs use the same settings, and a service may run in a different startup environment. First confirm how the program actually connects, then check the corresponding settings. Don’t add proxy environment variables indiscriminately to every system service just to get one terminal tool working; that makes future troubleshooting harder.

For iOS and Android, start with system VPN status, network permissions and background behavior. Don’t follow desktop proxy port instructions on mobile. VPNTape supports Windows / macOS / iOS / Android / Linux. Get the client from the downloads section of the user panel. For a first-time installation and import, return to Quick Start. This page doesn’t provide static installers or alternate download sources.

Old configurations, port conflicts and security software

Multiple network tools may compete for a local listener, virtual network adapter, default route or DNS settings. If you see a port conflict warning, first check whether the port is held by an old client that’s still running rather than changing the port at random. If you change one side without updating the system proxy or an app’s separate settings, you may create another connection failure. Properly exit the old tool, check the current tool’s status and test an actual request. That’s usually easier to understand than changing several settings at once.

If security software reports a block, check the file’s source, the specific action and the required system permission. Don’t treat turning off all protection as a general fix or add broad exceptions for unfamiliar files. Get the client through the link in the panel. If you can’t confirm a file’s source, stop running it and verify it first. For company networks, work certificates or managed device policies, ask the administrator whether the relevant network feature is allowed.

If one device has a problem while others work, keep a working device as a comparison instead of reinstalling everything. Compare the operating system, client, routing mode and network environment, then narrow down the differences one at a time. If the warning really comes from the VPNTape panel and conflicts with the unlimited-device policy, send support the warning page, account status and steps that led to it. Don’t pay again or buy another plan before confirming the source.

Support tickets and verification: provide information others can reproduce

If the basic checks don’t identify the cause, contact support. You don’t need to try every advanced setting first. Explaining the conditions under which it fails and what you changed is more useful than sending lots of unrelated screenshots. Open a ticket through the user panel. This page doesn’t promise a specific response time. Check for replies in the panel and add details to the same issue to keep the context together.

Describe the symptom first, then what you tried

Use a clear, specific subject, such as “Client disconnects after screen lock, works in foreground” or “Subscription fetched successfully but parsing fails.” In the message, describe what you expected to happen, what actually happened, when it occurred and your time zone. If you don’t know when the issue began, give the first time you noticed it rather than guessing. Say whether it happens consistently or intermittently and whether you recently changed networks, devices or client settings.

For device details, give the operating system and client name. If the system shows the exact version, include it in your actual ticket; don’t guess based on a guide. Describe whether you’re on a home, work or public network and whether you’ve tried another type of connection. Use the route name and type shown in the client, and say whether other routes work. Don’t combine results from different times or devices as if they were one test.

List the steps you tried in order and include the result of each. For example: direct access on the basic network works; the original route fails; another route also fails; changing networks fixes it. That’s enough to narrow down the problem. “Tried everything” doesn’t say which steps you actually completed, and “reinstalled” doesn’t tell support whether the original configuration was the same. If you don’t understand a step or can’t safely try it, say so rather than risking changes to a work device just to fill out a checklist.

Share only the relevant parts of your logs

Reproduce the issue first, then export only the necessary logs from around that time. Full logs may contain domains, network addresses, account identifiers and local file paths, so review and obscure sensitive details first. Keep the error category, event order and necessary context. Don’t hide every useful field or upload the raw logs publicly for convenience. Check the address bar, sidebar, pop-up notices and QR codes in screenshots too; sensitive information may appear outside the main area.

For payment issues, explain the difference between the status shown on the order page and what happened. Don’t use a payment screenshot as a network troubleshooting log. For a refund request, mention it in your ticket and review the refund policy and Terms of Service. VPNTape offers a 60-day money-back guarantee. Refunds and technical troubleshooting are separate matters; you don’t need to pay again or change your plan to submit a technical issue.

How to verify a support fix

After receiving a suggested fix, change one thing at a time. Save the original configuration, make the recommended change and retest the task that failed originally. If the suggestion involves updating a subscription, confirm that you actually switched to the new configuration. If it involves network permissions, check that the system shows them as active. Don’t just open a homepage and call it fixed. Return to the stage where the issue occurred—upload, playback, screen lock or a long-lived connection—and test again.

After the issue appears fixed, check the edge cases that are easy to miss: does it still work after restarting the app or waking the device? Can you access the original failing domain? Have other apps been affected by the new settings? Review temporary global mode changes, paused proxy extensions and test settings one by one, keeping only changes that are genuinely needed. Restore anything that hasn’t been shown to help so it won’t add more unknowns next time.

If it still fails, reply with what actually happened rather than repeating your original description. Say which step you reached, what new message appeared and whether anything that previously worked has changed. If the issue went away on its own, you can share when it recovered and which route you last used, but don’t assume a particular change caused the fix. Intermittent issues need multiple observations that can be explained; one successful attempt doesn’t establish the cause.

Keep your own troubleshooting notes

Save a local note without sensitive information: the symptoms, what was affected, useful comparisons, the final fix and anything still unconfirmed. If a similar issue comes up again, check whether it had the same trigger instead of blindly repeating the old fix. For first-time setup, return to Quick Start. For common account questions, see VPN FAQs for beginners. Keep settings and observations separate so each troubleshooting session eliminates genuine unknowns.