VPN Troubleshooting Guide

Break down the connection path

A web request passes through your local network, client routing, remote route, DNS and the destination website. “Connected” in the app usually means only that one connection stage succeeded; it doesn't mean your browser, work apps and downloads all use the same route. Describe exactly what happens: does the connect button spin indefinitely, do all websites fail after connecting, does one site show an error, or does a page load but video keeps buffering? The more specific the symptom, the fewer settings you'll need to change—and the easier it is to tell whether a change helped.

Before troubleshooting, save a restorable copy of your current settings and note the configuration name, route selection method and proxy mode. Keep subscription links and account details out of screenshots. Don't change routes, edit DNS and clear app data all at once; even if things start working again, you won't know why. Instead, change one thing, repeat the same test, record the result, then decide whether to keep or undo the change. Being able to restore the original setup matters more than trying a pile of “optimization” settings.

Check the network without the client first

If your current network allows a direct connection, disconnect the client temporarily and visit a site that normally works without it. Check that the system isn't waiting on a hotel, guest network or public Wi-Fi sign-in page. If authentication is required, open the sign-in page through the system's network prompt and follow the provider's instructions. Don't enter your service account details in an unfamiliar pop-up. If the direct connection also fails, check Wi-Fi signal, your router, cable or ISP connection first; a client can't fix an interrupted local network. Restore your usual protection settings when you're done testing.

Next, compare across devices and networks: try the same device on another available network, then another correctly configured device on the same network. The goal is to narrow down where the failure occurs, not to prove which device is “faster.” If only one device fails, check its system proxy, permissions and security software. If every device on the same network fails, check network access and the router. If multiple devices and networks fail on the same route, check the remote route or account status. No extra software or shared credentials are needed for these tests.

Keep a consistent troubleshooting record

Use the same format for each test: time, local network type, client message, route name, target app, and results before and after the change. “Slower in the evening” can be made more specific: “On the same network, web pages load normally but video buffers often; did switching routes change anything?” You don't need specialist terminology. Copying the exact error text from the screen is often more useful. If there's an error code, include it exactly as shown; don't assume the cause based on a similar screenshot you found online.

The commands and comparison tests on this page are for gathering clues, not universal fixes for every device. Get permission before changing settings on company-managed devices or altering work proxies and security policies.

If a change causes a new problem, undo the most recent change instead of adding more settings. Restart the client and repeat the original test. If needed, restart the device to clear leftover virtual interface or proxy state. Don't factory-reset your router as a first step; that can erase unrelated network settings. Once you've narrowed down the issue, go to the relevant section. If you haven't successfully imported a configuration yet, the quick start guide is a better place to begin.

Pinpoint when the error occurs

Open the client's connection details or diagnostics and note whether the error appears while loading the configuration, creating a virtual network interface or connecting to a route. A configuration parse error and a connection timeout are different problems. For a parse error, check whether the subscription is complete and the client supports the configuration. For a timeout, compare your local network with the selected route. If the only message is “Failed,” note what happens after you tap Connect and save a screenshot of the error. Don't assume every failure means the “server is down.”

Check that the device date, time zone and system clock are correct and syncing. A significant time difference can cause secure connection certificate checks to fail, resulting in a dropped handshake or authentication error. If you see a certificate warning, don't bypass verification or install a certificate from an unknown source just to clear the error. Restore automatic time sync, then reopen the client. If a company policy manages your device's time or certificates, give the original warning to your administrator instead of changing work network trust settings yourself.

Check permissions and other network tools

When a mobile system creates a VPN configuration for the first time, it asks for system permission. If permission was denied, the client may not be able to establish a connection. Open the system VPN settings and check whether the current client's configuration is listed and whether another app is using the connection. On desktop, use the client's supported repair or permission flow if it says the network service can't start. Don't download standalone driver patches from the web or permanently disable system security features for convenience.

Other VPNs, proxy tools, network filters or corporate access software may also control the default route. Quit similar tools that aren't needed for this test, and check that they haven't left a proxy service running at startup. If you can't stop a corporate access app, ask your administrator whether concurrent use is allowed. Closing a window may not stop the process; check the app's status and system network settings to see what currently controls traffic, then try connecting again.

Compare networks and routes

Keep your client settings unchanged, switch to another available network and try the same route again. If it works on the other network, the original network may restrict that connection method or have an access authentication or routing issue. There's no need to keep reinstalling the client; check the network provider's rules or try another permitted network. If it fails on different networks, compare it with another route available in your account rather than repeating the same steps with one endpoint.

Choose routes based on the names and types actually available in your account. VPNGlass covers 110+ countries / 190+ routes, but that doesn't mean every route works the same way on every local network. Visit the server locations page for region and route details, then choose an exit location suited to your target service. Don't try to “fix” a connection by changing the server address, port or authentication fields. These values come from a valid subscription, and changing them arbitrarily usually creates more connection errors.

“Connection timed out” describes the result, not the cause. A failure on one route, all routes or only one local network calls for a different troubleshooting approach.

If it still won't connect, preserve your settings instead of wiping everything

Check that your account plan is active, that data is still available and that the configuration belongs to the right account. If the subscription update failed, follow the subscription troubleshooting section rather than relying on an old screenshot of route names. Save your routing rules and app exceptions before importing again so you can restore them later. Uninstalling the app may also remove local settings. Only consider reinstalling if you know how to access your account and can retrieve the subscription again.

If it won't connect across networks and routes, and you've checked system permission, time and account status, submit a support ticket. Include the exact error, selected route, stage where it failed and comparison results, such as “also failed on another network.” Screenshots for secure connection troubleshooting should not contain authentication details, full subscription links or account passwords. If the client keeps crashing, stop retrying, note what triggers the crash and let support advise whether specific diagnostic information is needed.

First check whether all traffic fails or just one domain

If no websites load after connecting, check whether the client shows actual traffic and whether system proxy or virtual network control is enabled. Some modes set only the system proxy and won't cover apps that ignore it; others rely on a virtual interface and routing permissions. Don't judge by the connect button's color alone. Compare a site that normally works with the one that's failing. If the first works and the second doesn't, focus on routing rules, DNS, destination region or the website itself.

A browser message like “server not found” often points to DNS, but “connection reset,” “invalid certificate” and “access denied” aren't automatically DNS problems. For a certificate warning, check the domain and system time. An access denial may relate to the platform account, exit region or risk controls. Don't test a site by entering an unfamiliar IP address or ignoring certificate warnings; modern websites usually rely on matching domains and certificates. Direct access by IP isn't a reliable test and may lead to an unrelated service.

Use commands to check DNS results

These commands query example domains and do not change network settings. On Windows, use the built-in lookup tool. On macOS, check the system's current resolver and then look up the domain. On Linux, check the status if your system uses the relevant resolver service. Some systems don't have these tools installed; a missing command doesn't mean DNS is broken. If you substitute a public domain where you're seeing problems, enter only the domain name. Don't paste a full URL containing account identifiers, credentials or personal paths.

# Windows: look up an example domain
nslookup example.com

# macOS: view system DNS configuration and look up a domain
scutil --dns
dscacheutil -q host -a name example.com

# Linux with systemd-resolved: look up a domain and check status
resolvectl query example.com
resolvectl status

A DNS timeout means the query didn't get a timely response. A returned address only confirms that DNS resolution completed; it doesn't prove the website is reachable. Different networks may return different addresses because of content delivery and geographic routing. An address mismatch alone doesn't indicate a problem. More useful evidence is whether the same device can resolve the same domain before and after connecting, and whether DNS failures coincide with app access failures. Redact private network names and internal addresses from output as needed before sharing it.

Avoid overlapping DNS settings

Check system-level DNS, browser secure DNS, client DNS and any existing network filtering tools. They may use different resolution paths, so a system lookup can succeed while the browser still fails. Keep the client's recommended defaults, undo any temporary browser DNS overrides and retry the same domain. Don't enter public DNS addresses from unknown sources or enable every related option at once. Setting names vary by platform; the important thing is to find out which resolver handles the query.

If you've changed the hosts file, domain rewrites or routing rules, check for outdated address mappings. After fixing the configuration, a browser or app may keep using cached data or existing connections, so fully quit and reopen it. If needed, use the system's supported cache-clearing method. Don't clear the cache automatically every time something goes wrong: you may lose useful evidence before recording the original error. After clearing it, repeat the same test to confirm whether anything improved.

A successful DNS lookup doesn't mean every app is using the proxy. Confirm that traffic is routed correctly by checking the exit route, matching rules and actual access results—not a single DNS lookup.

Check for issues affecting only part of a connection

If regular web pages load but some resources, login redirects or images fail, check whether client rules send the main domain and resource domains along different routes. Differences in how the system and client handle IPv6 may also route some connections unexpectedly. Check how traffic is being handled using the client's supported tools rather than deleting the network protocol system-wide. For a more detailed check, see the guide to checking your exit IP, DNS and per-app routing. If the destination service itself is down, changing DNS repeatedly won't help.

Describe what “slow” means

Slow page loads, slow downloads, video buffering and choppy calls can have different causes. Note which stage is slow: does nothing happen for a while after you click, or does speed fluctuate once data starts transferring? The first may involve DNS, connection setup or the destination's response. The second calls for checking local bandwidth use, Wi-Fi interference and cross-border routing. A single probe result in the client isn't a complete picture of real-world performance; it may not cover the network path used by your actual task.

First check for background sync, system updates, cloud uploads or other tasks using the network. Upload congestion can slow websites and calls too; downloads aren't the only factor. Pause nonessential tasks, then retry on the same network, in the same place and with the same destination. If Wi-Fi is unstable, move closer to the access point or compare with a wired connection if available. The point is to rule out a local bottleneck, not to suggest buying a new device or network plan.

Compare routes and times during peak hours

If performance drops only at certain times, keep records for the same route across different times and compare other routes at the same time of day. Don't compare a lightweight webpage during the day with a large download in the evening; that won't show whether the difference comes from the network or the task. If direct traffic on the same network slows down too, check for local congestion first. If direct traffic is fine and routes differ noticeably, consider cross-border routing and exit load. A single success or failure isn't enough to establish a pattern.

When switching routes, first choose a region suited to the destination service, then compare the paths available in your account. A nearby location isn't always faster, and a lower probe latency doesn't necessarily mean a steadier transfer. Interpret route types using their actual descriptions; no route type guarantees the same result in every situation. The server and route guide can help narrow down your options. Actual performance still depends on your local network, destination service and current route conditions.

Assess playback quality and service region separately

Streaming platforms may automatically choose video quality based on your account, content, device capabilities and network conditions. Keep the content and playback settings fixed while testing, then see whether buffering improves. Don't mistake an automatic drop in quality for a route that's recovered. If the platform says a region isn't supported, proxy access is restricted or the account can't be used, follow the platform's rules; that's different from a simple speed issue. For more on streaming, see the streaming guide. Avoid repeatedly switching regions in a way that triggers login checks.

Some speed tests and downloads use a lot of data, and their servers may not be close to the services you actually use. Treat test results as supporting evidence, and don't run tests repeatedly until they interfere with everyday tasks. Monthly subscription data resets each month on the activation date. Data add-ons remain available until used and never expire. These are billing rules, not speed guarantees. If you've used all your data, check your account status first rather than blaming peak-time congestion for a connection failure. See available options on the plans page.

When to stop changing settings

If the same task has obvious problems across multiple routes and networks, check whether the destination service is down or the device is overheating or short on resources before submitting a ticket. Don't copy supposedly universal transport settings from an unfamiliar guide, especially if they lower security checks or rewrite broad system network settings. Tell support which tasks work and which don't; that's more useful than a speed-test screenshot alone. Without clear evidence, keep the settings that are working rather than disrupting everything to chase a particular number.

First identify what actually disconnects

Check whether the system VPN status disappears, the client returns to a disconnected state, or only the app you're using stops responding. If the connection remains active but a download stops, the destination service's session may have timed out. If every app loses access, check the connection and local network again. Note what happened just before the issue: did you lock the screen, switch Wi-Fi, enable power saving, close the laptop or move between access points? These triggers can explain more than a screenshot taken after the disconnect.

When a device switches from Wi-Fi to another type of network, its address and available routes change. Existing connections may need to be re-established. First observe with the device and network unchanged, then test the switch on its own. Don't treat a brief reconnection while moving as proof that the entire route is down. If the client has an auto-reconnect or network-change recovery option, enable it as documented. Then verify that apps can access the network again; a restored notification icon alone doesn't confirm recovery.

Android: background limits and app status

Android battery optimization, background activity limits and manufacturer task managers can affect whether the client keeps running. In the system app settings, check the client's background, battery management and network permissions. Use the system's official option to allow background activity. Menu names vary by device, so don't copy paths from a different model. If the system offers an always-on VPN setting, check how it behaves during network interruptions before enabling it, so a protective connection block isn't mistaken for a new fault.

Removing an app from recent tasks, system memory cleanup and some battery-saving tools can change its process state. Pause automatic cleanup, leave the client running normally, then compare access before and after locking the screen. Don't disable every power-saving feature just to keep the connection alive; adjust only the settings relevant to this client. If setup isn't complete yet, see the Android setup, permissions and testing guide to check that you haven't missed a configuration or permission.

iOS and desktop: recovering from sleep is a different issue

On iOS, check that the system VPN configuration is still present, that another network app hasn't replaced the connection and that the system re-establishes the tunnel after a network change. If you use on-demand connection, check that its rules suit your current network. Don't repeatedly delete the system configuration to troubleshoot each screen-lock issue; that changes the conditions you're trying to compare. Describe “fails after the screen turns off” separately from “fails when the app goes into the background”—they may involve different mechanisms.

After a desktop wakes from sleep, the physical network adapter may come back before the virtual interface and system proxy are ready. If something goes wrong after every wake, disconnect and reconnect the client without restarting the device, then check whether access returns. If the network is still affected after you quit the client, check for a leftover system proxy. Don't disable managed network services on a company device. Power and service management differ across Windows, macOS and Linux; follow the system's own prompts.

Record the pattern for support

If the device stays in the foreground, the network remains fixed and you've checked background restrictions, but the connection still drops unpredictably, compare another route and device. If it happens only on one route, include the route and time in your ticket. If it happens only on one device, include its system status and error message. VPNGlass allows unlimited devices to be connected at once, so don't assume that using another device must have disconnected the current one. If the app actually shows a device limit warning, check the subscription and configuration source in the subscriptions and devices section.

After changing background settings, repeat the original trigger—lock the screen or switch networks as before. A connection that stays active in the foreground only confirms that the foreground works; it doesn't prove the background issue is fixed.

A subscription is neither an installer nor a public URL

Installing the client doesn't mean you've retrieved the current connection configuration for your account. Get the subscription from the account dashboard and import it using a method supported by your client. A full subscription URL may contain access credentials, so keep it as private as your account password. Don't post it in public comments, screenshots or online format checkers. If an update fails after copying the URL, check for spaces, line breaks or punctuation added by a chat app. Don't split the URL apart and try to rebuild it by hand.

Check whether the failure happens while downloading the configuration or parsing it. A download timeout usually calls for checking the local network and update route. If the configuration downloads but the client reports a format error, check the import target, client compatibility and whether a sign-in page was returned instead of the configuration. Some public networks redirect requests to an access instructions page, which the client can't parse as a configuration. Complete network authentication, then retrieve the configuration again; don't import webpage content as connection settings.

An inactive connection may also block the update request

Some clients send subscription update requests through the current proxy. If the current configuration no longer works, the update request may fail too, creating a loop: you need an update to connect, but need a connection to update. Check whether the client offers a supported way to choose an update route, and follow its official instructions on an allowed network. Don't turn off all security checks to fix an update issue or ask strangers for a replacement subscription. The configuration available in your account is the source to check.

Before importing again, save custom rules, app exceptions and the current configuration name. Once the new configuration loads, confirm that the client has selected it rather than an older copy. Some apps keep multiple subscription groups, and similar names make it easy to pick the wrong one. A successful update doesn't mean every app immediately uses the new route. Reconnect and test the same destination before deleting the old configuration, so you still have a way back if the issue persists.

Check your plan status and data reset rules

Check in your account that your plan is active, data remains and the order status is up to date. Monthly subscriptions are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on your activation date, not on the first day of the calendar month. When you upgrade mid-cycle, the price difference is prorated by the remaining days; don't use the amount paid to estimate a new full billing period. If account details don't match, save redacted screenshots of the order status and account page for support to review.

Data add-ons cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They remain available until used and never expire. Add-ons follow different rules from monthly subscriptions: monthly reset dates don't apply to add-ons, and add-ons' no-expiry rule doesn't apply to monthly subscriptions. See the full comparison in the plans and data add-ons guide. If your status hasn't updated after payment, check the existing order first to avoid creating another one by tapping Pay again. Reimporting the subscription repeatedly won't resolve an order issue.

“Device limit reached”? Check where the message comes from

VPNGlass allows unlimited devices to be connected at once. If a client, app store account or third-party configuration shows a device limit warning, first identify its source. Don't assume VPNGlass has added a device limit. Check that you're signed in to the right account and that the selected configuration and subscription group belong to VPNGlass, not another service's old configuration. Unlimited devices describes this service's device policy; it doesn't remove session or device management limits set by the platform you're accessing.

If you're sure it's a VPNGlass configuration but still see a device limit error, save the original message and note where it appeared, then submit a ticket. Don't delete other devices in an attempt to guess the limit. You can sign in without an email address; keep your username and password safe, and don't send your password to support. If you think a subscription URL has been exposed, use the credential management option in the dashboard, then update the configuration on each device. Afterwards, check that the old configuration is no longer in use so old and new states don't get mixed up.

Configuration download failures, parse errors, orders that haven't updated and unexpected device warnings each need specific evidence. A ticket that only says “the subscription is broken” usually leads to follow-up questions.

A system proxy is not the same as routing all traffic

Some apps follow the system proxy, others use their own proxy settings, and some connect through separate networking components. If a browser can access a site, that only confirms that the browser's current route works—not that desktop apps, command-line tools or background services do too. Check the client's traffic handling mode, then confirm whether the failing app is covered. If you're using per-app routing, check whether the list means “proxy only selected apps” or “exclude selected apps”; choosing the wrong one has the opposite effect.

Don't switch all traffic to a different mode right away and leave it there. If the client supports temporarily widening proxy coverage, use that as a comparison: if the app works, check your original routing rules; if it still fails, investigate the app's own proxy, DNS, account and platform restrictions. When testing is done, restore the rules you originally needed—especially for work intranets, local network devices and development services—to avoid breaking internal connections while fixing external access.

Check rules against the actual process and domain

An app's main window, sign-in window, updater and media component may use different processes to access the network. If only the main program is on your per-app list, a sign-in redirect may still use another route. If the client provides connection logs, check the relevant process, destination domain and matching rule when you reproduce the failure. Don't post full diagnostic logs publicly; they may contain personal domains, internal service names or paths. Share only redacted excerpts relevant to the issue.

A single service may also use separate domains for sign-in, static resources and core functionality. If the home page loads but sign-in fails, check the connection for the failing stage instead of adding a rule for only the home page domain. Custom rules can override subscription defaults, so check the exceptions you've added most recently first. If removing a rule temporarily fixes things, replace it with a more precise match rather than permanently routing every domain the same way. Recheck the process and domain if an app update changes its behavior.

Check command-line and developer tools separately

Terminal apps don't necessarily read the desktop system proxy. Some tools use environment variables or their own settings, and may read them only on startup, so you may need to open a new terminal or restart the process after changing them. Don't copy proxy ports directly from a different guide; use the listening address and port shown in your client settings. The command below checks whether the current shell has proxy variables set; it doesn't add a proxy. Output may contain credentials, so don't paste it unredacted into a public discussion.

# Windows PowerShell: check common proxy environment variables
Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY,Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS / Linux shell: check proxy-related variables
printenv | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

If you find old variables, check whether they were set by company policy, a development environment or the current project before changing them. Don't delete every variable or change system-level settings without knowing what they do. If environment variables conflict with a tool's own settings, check that tool's documentation to see which takes precedence. Record the terminal and browser results during testing and note how each handles the proxy. That's more useful than saying “the computer can access the internet, but the app can't.”

Separate destination platform rules from connection issues

AI tools, streaming platforms and work services may have their own requirements for account region, sign-in sessions and exit location detection. A successful network connection doesn't guarantee the account is allowed to use the service. If a service reports an unsupported region, account verification or denied access, save the exact message and check the platform's rules. Don't make frequent route changes your default fix. For ChatGPT, see the AI tools access guide and guide to choosing a route and troubleshooting ChatGPT access. For video and audio platforms, see the streaming guide.

If only one app still fails after you've checked routing, app proxy settings, DNS and account status, explain in your ticket which app is affected, what action fails, whether the browser works and what happened when you temporarily widened proxy coverage. Don't share personal conversations, work documents or full session credentials to prove the issue. If the app uses corporate network policies or certificate pinning, ask your administrator which connection methods are allowed. A client can't grant permission for the destination app or guarantee that every service will work through the same route.

When it's time to contact support

If your basic network works, the account is active, and permissions and configuration check out, but tests across networks or routes still fail, ask for help through a ticket in the account dashboard. Persistent configuration parse errors, a network service that won't start or a mismatch between order and account status are also good reasons to submit a ticket. You don't need to take risky steps to prove you've troubleshot the issue, and you don't need to factory-reset your device. A clear summary of what you've tried is more useful than a long list of unrelated changes.

Company-managed devices, work certificates and local network access may fall under your administrator's remit rather than support's. Ask your administrator whether the connection method is allowed, then share the permitted scope and exact error with support. If a destination platform blocks a particular account, support can't lift that platform's restriction. Describe service connection issues, system management issues and third-party account issues separately to avoid troubleshooting the wrong thing.

Structure your ticket as “symptom, scope, comparison results”

Give the ticket a specific title, such as “Connection drops after screen lock, reconnecting works” or “Subscription downloaded but parsing failed.” Start by noting when the issue began, the device operating system and client name. Then include the local network type, route, exact error and affected apps. Provide the client version exactly as shown in the device interface; don't guess based on an online guide. If you don't know a detail yet, say so. An accurate missing detail is better than a complete-looking but unreliable description.

Next, list the comparisons you ran and what you changed each time. For example: did switching networks on the same device help? Did another device work on the same network? Did switching routes change the symptom? Did the browser and app behave the same way? Use short sentences in chronological order. Include the settings currently in place, especially any temporary changes to DNS, the system proxy, background permissions or routing rules. This prevents support from basing its advice on a setup that's already changed.

Share only the logs and screenshots you need

VPNGlass's privacy policy is anonymous and no-logs. Local client diagnostics may still include device information, destination domains or account-related fields, so don't assume they're safe to share publicly. Use the client's supported export and redaction tools, then review the contents. Don't submit account passwords, full subscription links, sign-in credentials, sensitive payment details or unrelated browsing history. If support needs more detail, ask which fields are needed and why rather than uploading the entire configuration folder.

Include the error text and enough context in screenshots, but hide account identifiers, private network names and other sensitive details. For a payment issue, provide the order status from your dashboard and any necessary order reference; don't show the full payment account details. A screen recording may accidentally capture notifications, clipboard contents or background windows, so watch it through before sending. Keep the route name and time of the issue where possible—they help identify its scope. Don't remove every useful diagnostic detail in the name of privacy.

Confirm the fix before cleaning up

After receiving advice, save your original settings and follow the steps one at a time. Once the connection works again, repeat the task that originally failed under the same conditions: lock the screen again for a screen-lock issue, switch networks again for a network-switch issue, or complete the full sign-in flow for an app login issue. Access through temporarily wider proxy coverage doesn't prove the original routing rules are fixed. A different route working doesn't prove the original route issue is gone. Reply to the original ticket with your retest results so support can continue investigating.

Once the connection is stable, remove temporary settings, restore security options unrelated to troubleshooting and keep a note of the final working setup. If the issue persists, continue the discussion in your ticket. VPNGlass offers a 30-day no-questions-asked refund; see the Terms of Service for the application rules. Plans, data add-ons and payment methods are listed on the plans page. Payments are accepted via Alipay / WeChat Pay / USDT. The goal is to explain the issue and restore network access—not to make you repeat the same tests indefinitely.

Write down one final summary: the original symptom, which change helped and which settings have been restored. Next time the same issue comes up, you can build on what you've already learned instead of starting from scratch.