VPN Troubleshooting Guide

Can’t connect at all: identify the connection layer

“Can’t connect” can mean the client won’t open, the subscription has no routes, a route fails to connect, or the destination website simply isn’t responding. These symptoms point to different stages and need different solutions. Note where the process stops: Does the app launch? Can you see route names? Does a permission prompt appear when you tap Connect? Does the process end with an error or keep waiting? “It doesn’t work” leaves out details needed to diagnose the issue.

Check your network and account first

Disconnect the client and check whether you can still access regular websites and your local network. Hotel, campus and public Wi-Fi may require network authentication first; switching to an international route usually won’t help until you complete the sign-in process. If websites still won’t load with the client disconnected, check your Wi-Fi or Ethernet connection, router and network authentication before deleting the subscription. If you test another network, use a connection you’re authorized to access and note what changes.

Once your basic network is working, open the account overview in the user panel. Check that your subscription is active, data is available and the subscription in your client belongs to this account. Successfully signing in to the panel only confirms that you can access your account; it doesn’t confirm that a route has connected. If the account is in good standing but the client shows no routes, see Subscription updates. If routes appear but won’t connect, continue with permissions and route selection.

Separate permission issues from route errors

The first time a client establishes a network connection, your system may ask you to allow a VPN connection, install a network component or grant a permission. Don’t rely only on whether the client’s Connect button changes color; check whether a system prompt is hidden behind another window. If you denied permission, confirm it in system settings instead of repeatedly tapping Connect. Organization-managed devices may restrict network component installation. Ask your device administrator rather than trying to bypass those restrictions by disabling management policies.

If permissions are granted, test a route that actually appears in the client. Try another route in the same region first, then try a different region. Keep the destination website and network unchanged. If only one route fails, the issue is more narrowly scoped. If routes in different regions all show the same error, check local components, account status and your network environment. A route name isn’t an error diagnosis; timeouts, resolution failures and authentication errors in the connection record are more useful clues.

Keep your original configuration, then troubleshoot client components

Before restarting the client, save the current route name and mode. Quit using the app’s own quit function; closing the window alone may leave its background process running. Reopen it, check that the network component starts normally, then repeat the same test. If other proxies, a corporate VPN or network-filtering tools are installed, check whether they’re handling network traffic. If permitted, pause one for comparison. Don’t run several tools that take over the entire device at once.

Don’t start by reinstalling. Reinstallation may remove rules and imported settings without changing public network restrictions, account status or system permissions. If reinstalling is necessary, save any custom settings you need, get the client from the client section of the user panel, then import your subscription again using Quick Start. Subscription details grant access to your account. Don’t post them in public forums or show them during screen sharing.

Submit a support ticket if your basic network works, your account is active, permissions are confirmed and routes in different regions all fail at the same stage. Include the client name, operating system, exact error message, network type and routes you’ve tried. Don’t include your account password or full subscription URL.

Connected but websites won’t load: check proxy settings and DNS

A successful connection status usually means only that one part of the connection process completed. You still need to check whether browser requests are going through the proxy, whether domain names resolve correctly and whether the destination service accepts your current exit route. Compare several websites to see whether none load, only international sites fail or just one service returns an error. Don’t conflate certificate errors, DNS resolution failures and access-denied messages. Save the exact wording of the error page.

Check whether requests reach the client

If your client provides connection logs, open the destination website and check whether a request for its domain or app appears. If there’s no record, first check system proxy settings, browser-specific proxy settings and the client’s operating mode. If a request appears but is marked as direct, check whether a rule is routing the domain to a direct-connection group. If the request uses your selected route, identify whether the error occurs during resolution, connection or the destination service’s response. Don’t assume every failure is a DNS issue.

Browser extensions, separate proxy settings and the system proxy can override one another. For testing, disable unnecessary browser proxy extensions, keep the settings the client needs and note the original configuration. If the client supports global proxy mode, you can use it temporarily to check for a rules issue. If the site loads in global mode, return to your usual mode and fix the rules rather than leaving the temporary mode enabled. If it still fails, routing rules aren’t the only possible cause.

Understand DNS results before changing DNS

DNS translates domain names into connection destinations. Resolution failures can result from an unreachable DNS service, incomplete network authentication, stale cache or a mismatch between the client’s DNS and traffic routes. Your browser may also use its own secure DNS and get different results from the system. First identify which DNS path is being used, then assess the result. Getting an IP address doesn’t prove that the website is reachable, and it isn’t enough to conclude that information is leaking.

The commands below query an example domain and contain no account details. Run them in a terminal on Windows, macOS or Linux if the relevant command is available. Check whether you get a response or a timeout, and whether the DNS server shown matches your current network settings. The example domain tests name resolution; it doesn’t confirm that a streaming or AI service works. Test the target service separately using its domain and an actual page.

nslookup example.com

If the query fails, first check for an old proxy setting or manual DNS configuration, then see whether the client has its own DNS feature enabled. Don’t copy DNS addresses from random posts or change every DNS option at once. Save the original values, change one setting, then run the query and load the page again. Clearing the cache can remove stale results, but it won’t fix an unreachable DNS service. Repeatedly clearing the cache without checking the DNS path usually adds no useful information.

Check certificates, browsers and service restrictions separately

If you see a certificate warning, first check that your device’s date and time are correct and that you’re visiting the expected domain. Don’t ignore the warning and enter account details, or install an untrusted root certificate just to open the page. If only one browser has the problem, compare with another and temporarily disable extensions that may rewrite web requests. Private browsing can reduce interference from some cookies, cache and extensions, but it won’t necessarily bypass system proxy settings or account restrictions imposed by the service.

If regular websites load but a service reports that it’s unavailable in your region, flags an account issue or denies access, save the service’s message and check whether your selected exit region meets its requirements. Switching regions can change the network path, but it won’t change account eligibility, content licensing or the service’s own rules. Comparing an alternative route in the same region is more useful than jumping between unrelated regions, and helps distinguish network issues from account security checks.

If you need help, provide the destination domain, exact page error, whether the client logged a request and whether the DNS query succeeded. Redact personal account details in screenshots. Don’t share full connection logs; they may contain visited domains and app requests.

Slow speeds and peak-hour slowdowns: compare routes

Slow speed isn’t a single metric. Slow initial page loads, consistently slow downloads, frequent video buffering and lag during live streams can have different causes. Describe the task, then compare: Is DNS resolution slow, or are page assets taking a long time to load? Is the video slow to start, or does playback keep stopping? Is one site slow, or is all international access slow? Don’t judge performance solely by the latency shown in the client. Latency and sustained throughput aren’t the same thing.

Set up a fair comparison

Test the same service on the same device and network, using the same video quality. Pause background downloads, cloud sync and system updates so they don’t use your local bandwidth. If your Wi-Fi signal is unstable, move closer to the router or use a wired connection for comparison if possible. If local websites also slow down noticeably when the client is disconnected, troubleshoot your basic network first. Don’t mistake router congestion or wireless interference for an international route issue.

When comparing routes, keep the exit region the same first, then try a different route type. IEPL, relay and direct connections shown in the client describe how traffic is routed; they don’t guarantee a particular speed every time. An exit closer to the content service may suit the task, but geographic distance doesn’t account for local access, content delivery or changing network paths. See the Routes page for selection tips. The client’s current route list is the source of truth for availability.

Keep track of when peak-hour issues occur

If the issue mainly occurs in the evening, note when it happens, the route name, the task and how it performs at other times under the same conditions. Try an alternative route in the same region first, then another route type. Check whether the whole connection slows down or only one content source responds slowly. Don’t change the region, browser, mode and video quality all at once. Even if performance is normal in one test, that doesn’t prove the peak-hour issue is gone for good.

Increasing video quality changes both data usage and transmission requirements. For troubleshooting, temporarily lower the quality and see whether buffering improves, then restore the original setting to verify. This can help assess sustained throughput; it doesn’t guarantee that a route supports a particular video quality. Streaming services may adjust quality automatically, switch content delivery servers or use a player cache. Reload the content after switching routes so you’re not comparing the old connection.

Separate task requirements from subscription data

Check your account’s data balance too, but don’t equate data allowance with speed tier. Monthly subscription data resets each month on the activation date, not at the start of the calendar month. Check the actual status in the panel if you’re low on data. See the Plans page for package details. There are no facts here establishing separate speed caps for each plan, so don’t assume a higher price will fix slow speeds or make an upgrade your default troubleshooting step.

A download site or content source may limit individual transfers, require a login or provide different resources by region. Comparing with other regular websites can help narrow down the issue, but don’t enter subscription details on untrusted speed-test sites. For live sports, buffering and congestion at the source also matter. The sports streaming route guide explains how to assess the task without treating player delay as a direct measure of route latency.

Submit a support ticket if your basic network is stable, background tasks are paused and different routes in the same region keep slowing down at certain times. Describe the difference between normal and affected periods, and include the service, exit region, route type and whether lowering video quality helped. If you attach a speed-test screenshot, explain the test conditions rather than sending only the result. This information helps support identify whether the issue is tied to a particular route, content source or local connection.

Frequent disconnects: distinguish network changes from app exits

First work out what’s actually disconnecting. The client may still be running while the route drops, the client process may exit, the system VPN indicator may disappear, or a website session may expire even though the network is fine. When the problem occurs, check the client status and system network icon. Note whether the device was locked, asleep, switched Wi-Fi networks or just resumed from sleep. Don’t restart right away or you may lose the most useful clues.

Check for changes to your basic network

Switching between Wi-Fi and mobile data changes the underlying connection, so existing sessions may need to reconnect. After a laptop wakes from sleep, Wi-Fi may come back before the client reconnects. If disconnects consistently happen at these times, test with the network unchanged and the device awake. If the connection stays stable, check whether the client offers an option to recover after network changes instead of assuming the route is persistently faulty.

If regular websites on the same network also stop working, check the Wi-Fi signal, router and network authentication status. Public networks may require you to sign in again after being idle. Reconnecting to Wi-Fi doesn’t mean you’re still authenticated. Don’t rely only on the signal icon; disconnect the client and try to browse normally to see whether a sign-in page appears. Record router restarts, upstream connection problems and local network changes as possible events instead of assuming the client configuration is the only cause.

Check processes, network components and other tools separately

If the client window disappears or its background process exits, the issue may involve app operation, system resource management or security software. Check for an app crash alert and save its exact wording. After reopening the client, check whether your subscription and route selection are still there. If the app starts but its network component won’t work, record the component error. That differs from a route dropping after connecting; describe them separately in your ticket instead of simply writing “disconnects automatically.”

Running other VPNs, proxy tools, network filters or corporate security software at the same time can cause routing or network components to conflict. Check which tools take over all device traffic, then pause unnecessary tools one at a time for comparison if permitted. Don’t disable security policies required by your organization or remove multiple network components at once. On a managed device, ask your administrator about the system prompt and keep management policies separate from client functionality.

Some apps automatically retry after a connection failure, making it look like they’re repeatedly connecting and disconnecting. Look for the first error, not the status of the last retry. A connection timeout, DNS failure, authorization error and component exit each point in a different direction. Include the full error and context in screenshots where possible. If the client provides local diagnostic logs, save only the section covering the affected period and redact account details and the full subscription URL before sharing.

Reproduce the issue with a short test instead of repeatedly resetting

Choose one route, keep the device awake and the network unchanged, then perform the task that normally triggers the issue. Next, test locking the screen, waking the device or changing networks one at a time. If only one route disconnects during continuous use, repeat the same task on an alternative route in the same region. Don’t change auto-connect, routing mode and DNS settings all at once. Repeated resets can turn a reproducible issue into an unexplained intermittent problem.

If only one website or app is affected and the client’s connection status hasn’t changed, check the app session and routing rules. An expired login, a change in the player’s content source or a failed response from the destination service can all look like a network disconnect. Check another regular website to confirm the connection still works, then review the destination request. Record both the client status and the page result when they don’t match; neither alone is enough to draw a conclusion.

After testing recovery, keep changes that worked and undo temporary settings that didn’t help. If you disabled auto-connect for a test, restore your usual setup afterward. Test settings shouldn’t unknowingly change the network path for your whole device long term.

Submit a support ticket if processes exit, components report errors or reconnections continue across different networks and routes. Include what you were doing beforehand, your operating system, client status, whether regular network access also stopped and whether restarting the app restores the connection. If a mobile device disconnects only when its screen is locked, see Mobile background operation. These issues often involve system battery settings, and repeatedly changing routes may not provide useful information.

Subscription update failed: check the source and import status

A failed subscription update isn’t the same as a failed route connection. Updating retrieves routes and related settings; connecting uses the information already retrieved. If an old route still works but updates fail, the existing configuration is still active. That doesn’t mean you should ignore the update error. If the route list suddenly becomes empty, import format, account status or the update result could be at fault. First record the error shown by the client, then decide whether to import again.

First check that the account and subscription are from the same source

Open the user panel to check your subscription status, data and validity, then use the subscription link provided there. Don’t use an old URL from a chat unless you can confirm its source, and don’t mix subscriptions from different accounts in the same configuration. You can create an account without an email address using a username and password. When troubleshooting account access, check your username and current sign-in status; you don’t need to give support your password to prove account ownership.

When copying subscription details, check for spaces, line breaks or punctuation added by a chat app. Every part of the full URL matters; don’t remove parameters or guess how to complete it. If the panel offers direct import, use that option. For a manual import, make sure the client is set to import a subscription rather than a local file or another configuration type. After importing, check that routes actually appear instead of relying on the dialog closing.

Choose the next step based on where the error occurs

For a retrieval timeout, first check whether your current network can reach the panel and which route the client uses for update requests. Some clients can update a subscription through an existing proxy, but if that connection is no longer working, the setting may prevent retrieval. Conversely, direct retrieval may fail if your basic network can’t reach the subscription link. Don’t assume you must use a proxy or connect directly. Compare what’s reachable, note which path works and keep the setting that does.

If the client reports an unsupported format or a parsing error, check that the import method matches a configuration type supported by the client. Opening the returned content as a webpage doesn’t mean it can be imported correctly. Likewise, accessing the panel in a browser doesn’t prove that the client received the expected format. Don’t upload your subscription to an untrusted conversion site. To get help checking the format, provide the client’s error message and your import method. Keep the full subscription URL on your own device.

If import succeeds but the route list is empty, check whether the selected configuration is the one you just updated. Some clients store several configurations, and updating one doesn’t automatically enable it. Check the configuration name, update time and route list to make sure you’re not still using an old configuration. Custom rules or manual changes may also affect what appears. Keep your original configuration and import into a separate new one for troubleshooting, rather than overwriting settings you can’t restore.

Understand data resets to avoid mistaking them for update failures

Monthly subscription data resets each month on the activation date, not at the start of the calendar month. When you upgrade mid-cycle, the price difference is converted into remaining days. Data packages don’t expire and remain available until used. Different plan types may appear differently in the panel and require different checks. If your allowance changes, check your account status and order history instead of expecting a subscription refresh to change it. Updates retrieve configuration; they don’t replace billing checks or restore used-up data.

See the Plans page and user panel for plan details and prices. You don’t need to create multiple accounts to test an import or submit the same order repeatedly while troubleshooting. If a completed payment isn’t reflected in the panel, save the relevant order status and describe what you see in a support ticket. Keep payment evidence separate from network diagnostics, and redact unrelated transaction and account details in screenshots so they don’t distract from the issue.

A subscription link grants access to your account. Don’t share it publicly as if it were an ordinary webpage URL. Check ticket attachments, recordings, screenshots and terminal output for the full link. To identify where an update failed, support will generally first need the exact error and the steps you took.

Submit a support ticket if the panel shows a normal account status, the subscription source is correct and updates fail across different networks. Specify whether the problem is a retrieval timeout, parsing failure, empty route list after import or a new configuration that won’t activate. Say whether the old configuration still connects. If you need to repeat the import, see Quick Start. Repeatedly deleting the client won’t help pinpoint an update error.

One app won’t use the proxy: check its request path

Accessing international websites in your browser doesn’t mean other apps use the same route. An app may read the system proxy, use its own proxy settings, connect directly or send only some requests through the system network component. First check whether the issue affects only one app or whether the same domain also fails in your browser. If the browser fails too, return to Websites & DNS. If only the app is affected, check whether its requests reach the client.

Distinguish the system proxy from full-device routing

The system proxy tells apps that use the setting how to send requests; it doesn’t force all network traffic through the proxy. Some desktop tools, terminal programs and in-app components may ignore system proxy settings. If the client offers a virtual network adapter or similar full-device mode, you can use it to check the route, but it usually requires system permissions and changes routing. Save your original settings first and confirm that your device management policy allows the mode. Don’t enable multiple tools that take over traffic for a single app.

Settings are named differently across platforms, so identify the function rather than following screenshots literally. On Windows and macOS, start with system proxy settings and the client mode. On Linux, check whether your desktop environment and the app use the same settings. On iOS and Android, check the system VPN status and which apps are covered by the client. The exact controls depend on your device and client. This guide doesn’t invent fixed menu paths or assume one mode works for every app.

Check the actual domains, not just the app name

Apps often connect to more than one domain. Sign-in, downloads, images, live messages and content APIs may use different requests. Reproduce the issue and review the relevant requests and routing results in the client’s connection log, if available. If the main page loads but its content doesn’t, adding a rule for the main domain may not be enough; check the failing requests. Avoid broad matching rules that reroute unrelated traffic, as they make future issues harder to diagnose.

If the client supports global proxy mode, use it temporarily to see whether the app starts working. If it does, check the rules or app coverage. If it still fails, consider DNS, connection type and the destination service’s response. Restore your usual mode afterward. Some apps need to be closed and reopened to use a new connection, and may keep an old session even after you switch routes. Save any work in progress before closing the app.

Separate app restrictions from network errors

If an app reports a regional restriction, insufficient account permissions or a sign-in verification failure, follow the service’s instructions first. Changing the network path won’t change your account eligibility, subscription benefits or the service’s terms. AI tools may handle web sign-in and app APIs separately, so a working website doesn’t confirm that every API is working. Record the error type and action that triggered it, such as “home page loads, request fails.” This is more useful than saying “AI doesn’t work.”

Don’t set a terminal app to use a proxy port you found online. Use the port and listening address in your own client’s actual settings; they may change after a restart or configuration update. If an app asks for a proxy type, check that it supports the type provided by your client. Incorrect settings may point the app to a local endpoint that doesn’t exist. Switching international routes won’t fix that. If you’re unsure about the settings, restore the original values and check the client’s help documentation.

An app’s cache, separate DNS settings, account session and network permissions can also affect the result. If you need to test, use the app’s own sign-out, reconnect or diagnostic features without deleting your data. Clearing all app data may remove local content without changing the network path. For work apps on organization-managed devices, follow your administrator’s network requirements rather than imposing personal proxy rules on managed apps.

When submitting a support ticket, include the app name, platform, action that caused the issue, browser comparison, client mode and whether the relevant request appeared in the log. Share only the necessary part of the connection record, with personal content, access details and account identifiers redacted. If a destination service returns a restriction message, include its exact wording. Support can help assess the route, but can’t resolve account permissions with the service itself.

Mobile disconnects in the background: check battery settings and network recovery

If the client works in the foreground but disconnects when the screen is locked, check background operation separately from the route connection. Confirm that it works before locking, check whether the system VPN indicator remains after unlocking, and see whether the client still shows the original connection. If the indicator disappears, the app or system network connection may have ended. If it remains but content won’t load, check network recovery, DNS and old sessions. Don’t assume the route itself is unstable just because reopening the app restores access.

Android: check background settings one at a time

Android devices may restrict background activity for idle apps, and the setting location varies by system and device. In system app settings, check the client’s battery use, background activity and network permissions to see whether it’s restricted. If the system offers an unrestricted or similar option, adjust it to suit your needs and note the original value. Allowing background operation doesn’t mean you need to disable battery saving for the whole device. Check only settings that directly affect the client.

Some devices also offer auto-start management, background cleanup or protection for recent apps. If the client closes when background apps are cleared, check whether those settings affect it. Don’t change permissions for every app or assume every device needs the same steps. Keep the network unchanged, lock the screen and unlock to test. If changing one setting helps, repeat your usual routine to confirm the result rather than assuming one successful test solved it permanently.

Also check whether the client includes the target app in its proxy coverage. Background notifications and content you open manually may use different network paths, so working notifications don’t prove that all app requests work. If the client looks normal after unlocking but an app needs to be reopened, see App proxy settings for more troubleshooting. For setup, see the Android VPN beginner’s guide. This section covers background issues after importing a subscription.

iOS: distinguish the system connection from the app interface

On iOS, leaving the client screen doesn’t necessarily end the VPN connection. Check the system VPN status along with actual access. The screen shown when you reopen the app may need to refresh, so don’t rely on a button’s outdated state. Check for other VPN configurations and features that can change the network path. Don’t remove organization profiles if you don’t know where they came from; ask your administrator what they’re for on a managed device.

If the issue always occurs after switching between Wi-Fi and mobile data, test each network separately while it’s stable. As mobile data comes back, the client and apps may need to reconnect, while old sessions may temporarily stop working. Record the order of the network switch, system status changes and page behavior. Don’t keep switching routes before the network is restored; changing the network and route at the same time makes the actual trigger harder to identify.

Use a lock-and-wake test to pinpoint the issue

Use a simple reproduction test: connect, open a page you normally use and confirm it loads; lock the screen, then unlock it. Check the system status before testing the page, without reopening the client right away. This shows whether the connection stayed active in the background. Then open the client and see whether it reconnects or only refreshes its screen. If access returns only after reopening the client, note that and include the system background settings. Don’t send only a screenshot of the working state.

Downloads, live streams and interactive apps have different background requirements. A mobile system may pause an app’s task while the system VPN remains connected. In that case, check the target app’s background settings. Don’t remove battery restrictions for every app or keep the screen on indefinitely as a workaround. You can keep the device awake temporarily for comparison, but your usual setup should balance battery life with necessary background tasks.

If the device is in low-power mode, overheating or experiencing major signal changes, note those conditions and retest in a normal environment. Restoring access after charging, keeping the app in the foreground or switching networks are clues, not proof of the cause. Change one condition at a time while keeping the client, route and task the same. After testing, undo temporary changes that didn’t help so other apps aren’t affected.

For a background disconnect support ticket, include the platform, operating system, whether it happened after locking the screen or changing networks, whether the system VPN indicator disappeared and whether reopening the client restored access. Include separate screenshots of the problem and recovered states; don’t attach only a normal screen.

If the client also disconnects in the foreground, return to Frequent disconnects and check your basic network and components. If only one app’s background task pauses, check that app’s permissions too. Support can assess the client’s recovery behavior once these factors have been checked separately. The key step is to distinguish the system connection, client process and target app behavior instead of grouping everything under “doesn’t work in the background.”

Device alerts and support tickets: collect reproducible details

Troubleshooting doesn’t mean trying every setting. Once the issue is resolved, record the change that worked and undo other test settings. If it persists, summarize what you’ve confirmed and submit a ticket through the user panel. VPNUI doesn’t publish an external contact address on this page; don’t get a purported private support link from an unverified account. A clear description of the symptoms and test results is more helpful than repeatedly saying “it still doesn’t work.”

Don’t assume a “device limit exceeded” alert means your plan has a device limit

VPNUI allows unlimited simultaneous devices and supports Windows / macOS / iOS / Android / Linux. If an interface says you’ve exceeded a device, session or authorization limit, don’t assume this service has an unpublished device cap or delete other devices to satisfy the message. First identify whether the alert comes from the user panel, client, operating system or destination website. Each source applies different limits, and a destination service’s account restrictions aren’t VPNUI device rules.

Check that the client imported the subscription for the correct account and isn’t using an old or another service’s configuration. If the alert comes from a client’s own feature authorization, save the full message and steps to reproduce it for support. If it comes from a streaming or work service, check that service’s device and session policies. Don’t share your username, password or full subscription with anyone to investigate; sharing account details increases risk and makes it harder to check the account status.

Describe the symptoms, conditions and changes in your ticket

Include the task you were performing, platform, client name, network type, selected route and exact error message. Then list the comparisons you’ve tried, such as basic network access working, an alternative route in the same region failing too, another browser loading the site, or the system indicator disappearing after locking the screen. Include only details relevant to the issue. If you changed a setting, describe what happened before and after so support doesn’t mistake a temporary test configuration for your usual setup.

Use the text format below to organize the details. You don’t need to include an account password or full subscription URL. Write “not yet confirmed” for anything you’re unsure about rather than guessing. If your client doesn’t have connection logs, just say so; don’t install unknown diagnostic tools. For a payment or refund issue, describe the order status separately from the connection problem so each can be handled appropriately.

Symptom: Connection shows as successful, but the destination website returns a DNS resolution error
Environment: Windows, home Wi-Fi
Scope: Regular websites work; the destination website fails
Route: Enter the route name shown in the client
Tests performed: Same result after switching to another route in the same region
To confirm: Does the browser use separate DNS settings?
Attachment: Screenshot of the error with account details redacted

Keep relevant details in attachments; redact access credentials

Screenshots should show the error, relevant status and necessary parts of the interface. Redact personal account details, unrelated order information and the full subscription URL. Don’t include your password manager, private messages or unrelated webpages. Connection logs may contain visited domains and app requests, so review them before sharing and keep only the section around the issue. The service’s no-logs policy doesn’t mean there are no local diagnostic records on your device; they serve different purposes and are stored in different places.

Don’t paste a full configuration file into a ticket instead of describing the issue. It may contain access details, private rules and unrelated information, making the issue harder to investigate. If support asks for more information, confirm which fields are needed and how to redact sensitive data. Public forums are for general questions, not personal account diagnostics. If you accidentally share access details, check the available options in the panel and contact support rather than sharing the screenshot again.

When to keep troubleshooting and when to contact support

Submit a support ticket if the issue is reproducible, you’ve compared different networks or routes, and the error still points to your account, configuration source or client components. If your basic network is down, contact the relevant network administrator first. If the destination service reports an account permissions issue, check its rules too. For orders, data or refunds, start with the information in the user panel. VPNUI offers a 30-day money-back guarantee. See the Refund Policy; don’t treat a network troubleshooting result as a substitute for reviewing the policy.

If possible, add new test results to the same ticket and say what action preceded each change. Don’t keep resetting the configuration while reporting only the original error; support needs to know which conditions still apply. If the issue is resolved, say what helped, such as restoring the system proxy, reimporting the correct configuration or allowing background activity. If you’re not sure what fixed it, say it’s temporarily working rather than treating one successful visit as a long-term performance guarantee.

If a similar issue comes up again, review the layer you identified and the changes that helped last time, then run the necessary comparisons. Quick Start helps set up a working configuration; this guide helps explain problems. Keeping those roles separate avoids repeated installations and aimless route switching.