VPN Troubleshooting Guide

Diagnose / Preserve the evidence

Start with a clear baseline

Describe what “not working” looks like

Before troubleshooting, pinpoint where the failure occurs. A client that won’t start, a connection toggle that won’t turn on, websites that stop loading after the toggle is on, and an error in just one app are different problems. The connection icon usually only means the local proxy process or tunnel has started; it doesn’t confirm that the route, DNS resolution and destination website are all working. Note the last successful action and the next action that failed—for example, the subscription imported and the route appeared, but the browser kept loading the page. This is much more useful than simply saying “the internet is broken.”

Next, narrow down the scope. On your current network, disconnect the client temporarily and check whether websites you normally visit directly still work. Then reconnect and visit the same destination in the same browser. If basic browsing also fails while disconnected, check your internet connection, router or local network sign-in first. If the basic connection works, continue troubleshooting the proxy route. Workplace and public networks may have rules for network use. Follow local requirements, and don’t change security policies on managed devices to run tests.

Narrow it down with cross-checks

For a useful cross-check, keep the conditions the same and change just one factor. Try another available network on the same device, or use another device on the same network to repeat the same action. The first test helps assess the network connection; the second helps identify device-specific issues. When switching networks, check whether a public hotspot requires you to open a sign-in page first. Until you complete that step, the client may appear to connect without being able to send actual requests. Get the basic internet connection working before repeating the original test.

Don’t switch routes, clear browser data, reinstall the client and change DNS all at once. Even if the issue goes away, you won’t know which change helped, and the next time it happens you’ll be guessing again. Note the selected route, connection mode, network and exact error text before making one change. After each change, test the same page or app. If nothing changes, restore the original setting before checking the next one. This helps prevent conflicting configurations from building up during testing.

Try reversible steps before clearing data or reinstalling

Selecting a different route, fully quitting and reopening the app, or reconnecting is usually easier to undo than deleting a configuration. Before clearing anything, make sure you can sign in to the user panel and know where to get your subscription again. VPNDisc doesn’t require an email address; your username and password are enough. Keep these credentials safe, and don’t rely on an already-signed-in browser as your only way to regain access. Keep your subscription link safe too, and redact its authorization details from screenshots and logs.

Setting names in this guide may vary with your system language, client interface and device management policies. Look for the setting by function—for example, system proxy, tunnel, per-app routing or background activity—rather than trying unrelated steps because a button is named differently. Skip steps for settings you don’t have and mention that in your support ticket. Don’t install supposed diagnostic tools from unknown sources or import someone else’s configuration in place of your VPNDisc subscription; that can add more variables than the original issue.

The goal of this first round of checks is to identify a clear branch: all devices fail on the same network, only this device fails, only a particular route fails, or only the destination app fails. Save that result before moving on. If you haven’t confirmed the subscription and import steps for your first connection, return to the Quick Start Guide to check the basics. That’s usually more effective than changing advanced settings right away.

Symptoms / Unable to connect

What to check when you can’t connect

Check your internet connection and account status

If nothing connects, first distinguish between “no routes are available” and “a selected route fails to connect.” The first may mean the subscription hasn’t imported, the configuration isn’t selected or the update failed; see the subscription section. The second calls for checks of your current network, permissions and route. Quit the client temporarily and confirm that your device can access ordinary websites. Then check your plan status and remaining data in the panel. Being able to open the panel only confirms that the panel is reachable; it doesn’t prove the current route is working.

If the panel says your plan has expired or you’re out of data, use the panel’s records to resolve the account issue. Changing DNS or repeatedly importing the subscription won’t fix billing. Monthly subscription data resets each month on the date you activated it, not on the first of the calendar month. Data packs remain available until used and never expire. Check your purchase details before deciding whether you should have data remaining. Review prices and upgrade terms on the Plans page. Don’t pay again just to see whether your connection comes back.

Check permissions and conflicting network tools

When the client requests system permission to create a network connection, confirm that you granted it. If you denied the request earlier, check your system’s network or app permissions rather than repeatedly toggling the connection. Desktop virtual network adapters and tunnel features may require additional permissions. Mobile devices may also retain connection profiles created by older apps. Enable only the connection tool you need, temporarily quit other proxy, network acceleration or tunnel apps, and test again to prevent multiple tools from competing for the same network entry point.

If security software displays a warning, don’t make disabling all protection a routine troubleshooting step. Read what was blocked and confirm whether the client came from the VPNDisc panel and whether the blocked action involved startup, network access or component installation. Ask an administrator to handle managed devices. If the system says a component couldn’t load, save the full message and submit a support ticket. Don’t download replacement drivers from forums or run administrator commands from unknown sources. Pause before making changes if you can’t tell what they might affect.

Compare routes and network connections

Keep all other settings the same, select another available route in the panel and test the same website. If it works, note the names of the failed and working routes, keep using the working one and send support the details. If all routes fail, test on another available network. If the issue occurs on just one network, the network connection may be a factor. If it occurs on different networks but only on this device, check the client configuration, system permissions or local network components rather than assuming every route is affected.

A timeout, a connection refusal and a name resolution failure in a log mean different things. A timeout means no expected response arrived within the wait period; the issue could be on the local network, route or destination service. A connection refusal means an endpoint explicitly declined the request. A name resolution failure points first to DNS. Note what you did before and after the error and when it appeared in the log. There’s no need to guess about protocol internals. Destination addresses and subscription credentials in logs may be sensitive, so review them before sharing.

If your basic connection works, your account is in good standing, system permissions are set and changing both the route and network hasn’t helped, submit a support ticket. Include your operating system, where you got the client, the exact error text and the results of your comparison tests. Save evidence before reinstalling; if you don’t record the error first, a problem that temporarily disappears may be hard to investigate. Once the connection is restored, repeat the original test. Don’t stop troubleshooting just because the toggle shows that it’s on.

Symptoms / Connected, but pages won’t load

Connected, but websites won’t load

Check whether traffic is reaching the client

If the connection is on but websites won’t load, check whether the client logs a corresponding connection when you make a request. No record may mean the browser isn’t following the system proxy, the current mode only handles some traffic, or another app has overridden the proxy settings. If there is a record but the request fails, check the rule, route and error shown there. The connection indicator on the main screen alone can’t tell you which of these cases applies. Test with an ordinary website first, ruling out a cached or offline page in the browser.

System proxy and tunnel modes handle traffic differently. A system proxy is generally used by apps that follow that setting. Tunnel mode uses a virtual network interface to handle a broader range of traffic, but it’s still subject to rules and system limitations. Don’t assume either mode covers every program. First check which mode the client has enabled, then see whether the browser has its own proxy configured. If an extension also manages the proxy, temporarily disable it, reopen the browser and compare the result.

Separate destination website issues from connection-wide issues

If ordinary websites load and only one site fails, check the platform’s service status, account messages and regional requirements. A message stating that your account is restricted, the service isn’t available in your region or access was denied may mean the request reached the platform; reconnecting repeatedly may not help. VPNDisc routes don’t replace platform account eligibility or guarantee that a platform will always accept a particular route. Keep the full message so you don’t mistake every platform response for a connection problem.

A blank browser page, a spinner that never stops and a certificate warning call for different checks. A blank page may involve scripts, extensions, cached content or failed page resources; compare using a temporary browser window without extensions. For a certificate warning, first make sure the device date and time are correct, especially if it has been shut down for a long time. Don’t ignore certificate risks to enter your account password, and don’t install an unknown root certificate to “fix the network.” If the time is correct but the certificate warning persists, save the message and stop sensitive activity.

Choose your next step based on the result

If every website fails in the same browser but other apps still have internet access, restore the browser’s own proxy settings first. Then check whether the system proxy points to a local process that has already exited. A tool that was closed may leave behind proxy settings that keep sending requests to a nonexistent entry point. Before restoring the system network settings, note the current configuration and any requirements for your work network. Work devices may need a specific proxy, so clearing it could disrupt normal work. Contact your device administrator if you’re unsure.

If all apps fail when the client is on but work again when it’s off, check the default route, DNS and routing rules. Reselect the VPNDisc subscription configuration and reconnect. Don’t mix in rules from other sources. Subscription rules and personal overrides can apply at the same time, so check for manually added direct, reject or fixed-route rules. Temporarily disable custom changes to compare results; this makes it easier to identify the cause than deleting the whole client.

If a specific ChatGPT, Claude or Gemini page fails, see AI tools access guidance to assess account and regional factors. For streaming issues, see streaming support details. In your support ticket, say whether the website’s home page won’t load, the problem starts after signing in or a particular feature fails. The domain and error text are enough. Don’t send private conversations, account session details or a full browser profile.

Symptoms / Slow speeds, buffering or lower video quality

Slow speeds and peak-hour buffering

Pinpoint what feels slow

A webpage taking a long time to open, a slow file transfer, interrupted video playback and delayed responses in a live conversation may involve DNS resolution, sustained throughput, buffering or the destination platform. Describe the specific action rather than reporting only a speed test result. A speed test and the app you’re using may take different routes, follow different routing rules or use different content delivery paths. A good speed test doesn’t guarantee that the app will work well, and a slow app doesn’t necessarily mean the entire route is down.

Check for tasks using your local network, such as system updates, cloud sync, backups or media transfers on the same network. Pause anything that’s safe to interrupt, then test the same destination again. An unstable Wi-Fi signal can cause retransmissions and delays even when pages sometimes load; compare from nearer the access point or over a wired connection. Don’t run speed tests continuously while troubleshooting. They use network resources and plan data, which can skew the results.

Route type doesn’t guarantee a fixed speed ranking

IEPL, relay and direct connections describe how a route is set up; they aren’t a fixed ranking that applies to every network. Your internet provider, exit region, cross-region path and destination platform can all affect performance. Keep the destination the same while comparing different route types, and note which combination works best on your network. Don’t judge by geographic distance alone or assume that a route labeled dedicated will always be faster. See the global locations page for examples and route details.

If buffering only occurs during peak hours, keep the device, network and destination the same as during off-peak tests and check whether the time is the only difference. If all devices are slow on the same network, check your home network and internet connection first. If only one exit route is slow, test another route. When logging results, include the network location and time zone so that “evening” isn’t mistaken for the same time everywhere. Repeatedly switching routes during peak hours produces scattered impressions; controlled comparisons are more useful.

How to assess video and AI tools separately

Lower video quality can result from a platform adjusting playback based on buffering, account quality settings, device capabilities or the video itself. First check the selected resolution and the platform’s settings, then see whether buffering continues. Seeking immediately after connecting clears the existing buffer and can make a brief loading delay look like persistent buffering. Compare routes using the same video and playback position so differences in bitrate between videos don’t skew the results. For more detail, see our guide to troubleshooting reduced video quality.

For slow AI tools, distinguish between page resources loading, submitting a request and the model generating a response. If the page loads and the platform accepts the request but takes a long time to respond, the cause may be platform processing or an account queue; wait time alone doesn’t prove there’s a network issue. Repeated network interruption messages, failed submissions or resource loading errors are stronger reasons to check the connection log. Keeping a stable exit route can help avoid additional checks caused by frequent region changes. Don’t switch regions repeatedly during a session.

Your plan’s data allowance determines how much data you can use; it’s not a fix for every buffering issue. Upgrading as soon as things slow down may not address the cause. First check whether you’ve actually reached your current allowance, then investigate the route and internet connection. When you upgrade a VPNDisc monthly subscription mid-cycle, the price difference is converted into remaining days. Check the panel for upgrade terms. If you can consistently reproduce an issue with a specific route, network and time, send those comparison results in a support ticket. That’s more useful than saying only “it’s really slow at peak times.”

Symptoms / Connection drops and background issues

Frequent disconnects and mobile background drops

Check what happens when the connection drops

First note whether the disconnection follows a screen lock, app switch, network change, device sleep or power state change. If it only fails with the screen off and reconnecting after wake restores service, check background activity and battery settings. If it also disconnects while you’re actively using the device, check the route and network. Don’t assume every interruption means the app was “killed in the background”; the app may still be running while the underlying network has changed. Use the sequence of events and system state to narrow it down.

When switching from Wi-Fi to another network, the device’s route and IP address may change, and the existing connection may not continue as before. Check whether the client reconnects, then retry the request in the destination app. Downloads, video sessions and live requests that were interrupted may need to be restarted by the app, even after the tunnel reconnects. Don’t keep restarting the device just because an old page still shows an error. Reopen the destination page and see if the issue persists.

Check settings according to their actual function

Android background restrictions are often controlled by both the system’s battery policies and the device manufacturer’s settings. Check whether the client is allowed to run in the background and use background data, and whether it’s set to restricted. Settings names vary between devices, so search by function. Adjust only the client that needs to keep working; there’s no need to disable battery saving for every app. Whether leaving an app in the recent apps list helps also varies by device, so don’t treat one device’s behavior as a guarantee. After changing settings, lock and unlock the screen and repeat the original test.

On iOS, check the system connection status and client errors rather than looking for a similarly named background permission that doesn’t exist. System network extensions and ordinary app background activity don’t work in exactly the same way; the connection doesn’t necessarily stop just because the app isn’t in the foreground. If an error occurs after switching networks, reconnect and test the destination request again. If there’s a system configuration conflict, identify which app created the old connection profile first. Don’t remove a work or school management profile unless you know what it’s for, and don’t use driver repair steps meant for another platform.

Desktop sleep and disconnects during active use

After a desktop wakes from sleep, the network adapter, routes and client process may not all recover at the same time. First confirm that ordinary internet access is back, then disconnect and reconnect the client. On Windows, check that the network interface is available; on macOS, check the active network service and system proxy; on Linux, check the client process and network manager. There’s no need to reinstall the operating system for an occasional wake-from-sleep issue. If it happens reliably after every sleep, record what changes in the network before and after sleep so support can investigate.

If the connection drops frequently while the device is in active use, leave the app unchanged and test different routes and networks separately. If it only happens on one route, note the route. If it only happens on one network, check the network connection. If it happens only on this device under all conditions, check for software conflicts and local components. Also look for an incorrect system time or low disk space, which can interfere with saved settings or component operation. Don’t send large numbers of meaningless requests to “keep the connection alive”; that uses data and may not address the cause.

Tell support whether the client’s connection toggle stayed on after the interruption, whether the system connection icon disappeared, whether reopening the app restored service and whether retrying the old page worked. These details help distinguish a stopped tunnel, a network change and an expired app session. If the log stops when the background connection drops, save the relevant lines before it stopped. If errors continue, include enough surrounding context. Redact account details and authorization fields before submitting, and don’t attach private notifications from other apps.

Symptoms / Configuration updates and account messages

Subscription update failures and device messages

Determine whether the failure happened while fetching or importing

A subscription update can fail because the request didn’t succeed, the response wasn’t a configuration, the client couldn’t parse the format, or the configuration imported but wasn’t selected. Read the client’s exact message first, then see whether the route list still shows its previous contents. An existing list doesn’t mean the latest update succeeded, and you don’t need to delete it right away. Keep the working configuration and error details. Don’t clear everything before confirming that you can get a new subscription from the panel, or you may lose your temporary way to connect.

Sign in to the user panel to check your account and plan, then use its subscription link. When copying, don’t include extra spaces, line breaks, explanatory text or punctuation added by a chat app. A link wrapping onto multiple lines in the interface doesn’t necessarily contain line breaks; use the panel’s copy button. Your subscription is authorization data. Don’t paste it into public online parsers or send it to strangers for verification. When sharing a screenshot, cover the entire authorization string, not just its last few characters.

Distinguish download errors from format errors

If the client reports a timeout or can’t resolve the subscription domain, check your basic connection and the route used for the update request. Some clients offer a choice between updating directly and updating through the current proxy. If the current route is unavailable and the update depends on it, you may end up in a loop. Use options the client actually supports, switch the update route and test it on its own. Don’t change the subscription content at the same time. If the panel itself won’t open, fix the network connection first rather than guessing at a different address for the link.

If the client reports a format error, check whether it received a sign-in page, an error page or a network authentication page instead of the configuration. Downloading some text doesn’t mean the correct configuration was received. Also make sure you’re using the panel’s subscription link for your client; don’t import a different format by mistake. Don’t delete lines from a configuration just to pass validation if you don’t know what they mean. You could remove rules, DNS settings or route selection. Note the field names in the error; you don’t need to submit the full subscription.

Assess data allowances and device messages separately

VPNDisc supports unlimited devices online at the same time. If a client displays “device limit exceeded” or similar, that doesn’t mean VPNDisc has an undisclosed device limit. First check whether the message comes from the VPNDisc panel, current client, system connection manager or another service. Old accounts, other configurations and local authorization features can use similar wording. Save a screenshot, note where it appeared, check which account and configuration you’re using, then ask support through a ticket. Don’t delete all your devices to try to restore service.

Unlimited simultaneous devices and a plan’s data allowance are separate things. When several devices use the same account, keep an eye on the account’s data records. Monthly subscriptions are ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB. Data resets monthly on the activation date, and the price difference for a mid-cycle upgrade is converted into remaining days. Refreshing a subscription doesn’t reset data. The client’s local usage count may not match the panel’s billing records. If you notice a discrepancy, save the time period and records for support to review.

Data packs cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They remain available until used and never expire. They work differently from monthly subscriptions; read how monthly plans and data packs differ before choosing. After an update succeeds, confirm that the updated configuration is selected, your previous route selection is still valid and a new request works. If you think your subscription has been exposed, reset its authorization using the panel if that option is available. If not, submit a support ticket; simply renaming the local configuration won’t help.

Symptoms / Individual apps and name resolution

App routing and DNS issues

If an app isn’t using the proxy, check what the client handles

If your browser works but one app doesn’t, first check whether that app follows the system proxy. Some apps use their own network stack, individual proxy settings or connections managed by system policies. A working browser doesn’t prove that the app uses the same route. Open the app and trigger a request, then check whether it appears in the client log. If it does, check the matching rule and route. If not, check the traffic handling mode and per-app settings. Don’t switch the whole system to a global configuration unless you’ve confirmed that’s what you need.

App routing can also differ between the main app, helper processes and embedded pages. Setting a proxy for the main app may not cover the components responsible for sign-in or media transfers. Use connection records to identify what’s happening rather than guessing based on the app’s name. If the client offers a temporary mode that covers more traffic, use it as a comparison test and restore your original rules afterward. If the issue only occurs with per-app routing, adjust the specific request rather than affecting resources that need a direct connection.

A DNS error isn’t the same as a website denying access

DNS translates domain names into addresses a device can connect to. The system, browser and client may each handle resolution, and a browser’s secure DNS setting may use a separate route. A successful system lookup only confirms that one query path returned a result; it doesn’t mean the app used the same result. First check the client log for resolution failures, then see whether the browser has a separate DNS setting enabled. For comparison, you can temporarily turn off the browser’s custom DNS and restore it after testing if needed. Don’t blindly add multiple resolvers.

The commands below query a sample domain and contain no subscription or account details. In Windows PowerShell, use Resolve-DnsName. On macOS and Linux systems with the relevant tool installed, use nslookup. If the command isn’t available, there’s no need to install an unknown tool; use the diagnostic interface already on your system. Resolving the sample domain only confirms that a basic lookup works. Check the actual destination against the app’s connection records rather than assuming all DNS behavior is normal.

# Windows PowerShell
Resolve-DnsName example.com

# macOS or Linux with this tool installed
nslookup example.com

If the system lookup fails but the client’s lookup works, check whether the system DNS path still points to an old tool or an unreachable network service. If the system lookup works but the app fails, check the app’s own DNS settings and routing first. Don’t save a resolved address as a permanent setting; platform addresses can change and DNS results are cached for a limited time. Clearing the cache can remove stale results, but it won’t fix an upstream resolver that remains unreachable. Fix the DNS path first, then reopen the app or clear its cache using a method supported by the system.

What connectivity tests can and can’t tell you

You can use the command below to see whether a sample site returns response headers. No local proxy port is specified, so how the request travels depends on your system and environment settings. Some command-line tools don’t automatically follow the system proxy configured in a graphical interface. A failed command doesn’t necessarily mean the browser will fail too. Use the test to identify the type of error—such as name resolution, connection timeout or certificate verification—not just to get a pass-or-fail result. Don’t add account authorization headers or private access credentials.

curl -I https://example.com

Don’t try to hide DNS issues by disabling an address protocol or changing routes at random. A device may have network paths for more than one address family, and the client’s traffic handling scope may differ from the system’s default selection. Keep default settings initially and check which request isn’t using the expected route. Then verify what the client supports using its documentation. Only run a reversible test when there’s evidence pointing to a specific setting. In a support ticket, include the command’s error text, app request records and current mode. Don’t send complete logs that include browsing history from other sites.

Wrap up / Support, verification and data safety

When to contact support and verify a fix

If the issue keeps recurring, stop stacking changes at random

Submit a support ticket if the basic connection works, your account is active, you’ve compared routes and networks, and the problem still happens consistently. Contact support directly about authorization issues, billing records, system components that won’t load or device messages you can’t identify. Don’t keep trying risky steps just to prepare a ticket, and don’t overhaul your system. Preserve a clear example of the failure and explain what you’ve already checked so support doesn’t have to repeat the same steps.

Submit your details through the user panel support ticket form. Use a title in the format “platform + issue + trigger,” such as “Android requests fail after screen lock; reconnecting restores service.” Describe the steps in order: which configuration you connected, which route you selected, what you opened and what message appeared, then what changed after switching. You can mention the general region and type of network. Don’t provide your exact address or personal information unrelated to the diagnosis.

Useful evidence doesn’t mean sharing everything

Useful details include your operating system, the client name shown in its interface, where you got it, the time and time zone, route name, exact error text and whether only one app is affected. If you include system or client versions, check them on the device rather than copying someone else’s. Keep the time consistent with the logs. Screenshots can show the error and relevant settings, but crop out private notifications and unrelated windows. You can submit a ticket without logs; accurate steps to reproduce the issue are still more useful than a large, unfiltered data dump.

• Issue: Can’t connect, connected but no pages load, slow speeds, disconnects or update failures.
• Scope: One app, one device, the current network or a specific route.
• Comparison: Did the result change when you switched routes, networks or apps?
• Evidence: Exact error, relevant time, current mode and necessary log excerpts.
• Privacy check: Passwords, subscription credentials, session details and private content are redacted.

Include a continuous excerpt from around the time the issue occurred. Don’t send only the last word of a log, and don’t upload the entire history. If a destination domain reveals private work information, describe it generally and ask whether the exact domain is necessary. Browser network logs may include session credentials, request content or private file URLs, so don’t attach them by default. Support should never need your account password. If someone outside the panel asks for complete authorization details, verify the request through the official support channel first.

Once it works again, repeat the original test

After receiving troubleshooting advice, make one change at a time and record what you changed and what happened. If the issue is resolved, repeat the action that originally failed instead of checking only whether the home page loads. For a background issue, repeat the lock-and-wake test. For a subscription issue, confirm that the new configuration is active. For app routing, check that the actual request uses the expected route. Then re-enable any security protections you temporarily disabled, restore settings unrelated to the diagnosis and remove test configurations you no longer need. This avoids leaving new risks behind after the fix.

If the problem disappears temporarily but you can’t reproduce it reliably, say “currently working; cause unconfirmed” rather than treating one successful test as a permanent fix. Keep relevant notes and add them to the same ticket if the issue happens again, so support can compare conditions. Describing the same issue across multiple tickets can scatter useful context. If the destination platform explicitly reports an account or regional restriction, follow its appeal and usage policies. VPNDisc support can’t determine platform account eligibility on its behalf.

Service terms and security practices

VPNDisc offers a 14-day refund policy; see the Terms of Service for eligibility and instructions. For billing questions, include the relevant order record, not your full payment account details. Payment methods: Alipay / WeChat Pay / USDT. Get clients and subscriptions through the panel, not installation files from unknown sources shared in chat. For common account and billing questions, start with the Support page to avoid mistaking a service policy for a network problem.

Military-grade encryption is a key security claim for this service, but account details, devices and subscription links still need to be protected. A restored connection doesn’t mean you can ignore system updates, certificate warnings or public network risks. Read how to protect subscription links and stay safe on public Wi-Fi, and keep a record of what worked this time. If the same symptoms come back, start with the checks you’ve already confirmed instead of repeatedly clearing settings or reinstalling.