Network Troubleshooting Guide

Connected but can't browse: websites, resolution & DNS

Break website errors down by stage

A website not loading doesn't always mean the connection failed. The browser may stop while resolving the domain, establishing a connection, checking a certificate or waiting for the site to respond. Copy the exact error and distinguish “server not found,” “connection timed out,” “invalid certificate” and a message shown by the website itself. Then try other public sites to see whether all domains fail or only one. If the target site shows an account, region or verification page, the request may have reached its service. Check the platform's access rules rather than assuming DNS is at fault. Record a website's refusal page separately from a browser error that indicates no connection could be established.

DNS translates domain names into network addresses. If the basic network works but name resolution takes an unexpected path after the client takes over traffic, the tunnel may appear connected while websites still fail to resolve. Check whether the client uses the DNS settings supplied with the subscription, whether you've manually overridden the resolver and whether another tool is changing DNS at the same time. Save the current settings, then restore the client's recommended defaults. Don't combine DNS, routing and traffic-capture settings from unrelated tutorials without understanding their paths. They may apply to different modes, and mixing them can create loops or send DNS requests through the wrong route.

Command output is only one piece of evidence

On desktop, you can query a known test domain to see whether it returns an address or a resolution error. The command below queries a public example domain and does not reveal subscription details. Whether the command is available on Windows, macOS or Linux depends on the tools installed. A successful query means the resolver path used by that command responded; it doesn't prove the browser uses the same resolver or that the target site is reachable. Some clients return addresses used for internal mapping. That alone doesn't prove poisoning or a leak; interpret the result in light of the client's mode and the actual request.

nslookup example.com

A browser's secure DNS, the system's encrypted resolver and a client's built-in resolver may all be active at once. If only one browser fails, note its secure DNS settings, temporarily restore the system default path for comparison, then revisit the same page. If the client captures traffic through a virtual network adapter, check that DNS requests are handled as required by that mode. “The domain resolves” doesn't rule out every DNS issue: the command line, browser and app may cache different results or prefer different address families. Change one layer at a time and record what changes.

Cache, address families and security boundaries

After changing DNS settings, old cache entries and existing connections may still affect the result. Exit and reopen the browser normally. If needed, follow your operating system's official steps to flush the DNS cache, then reconnect the client. Don't reset the network, uninstall adapters and erase all browser data at once. The issue may disappear temporarily, but you'll lose clues about the cause. If only certain domains repeatedly fail, record whether they return different address families and whether the client can capture that traffic. Don't leave system-wide address-family support disabled as a troubleshooting measure. Restore reasonable original network settings when testing is done.

If the cause is still unclear, include the affected domains, browser error, redacted output from DNS commands and the differences you observed with the client off or after switching routes. Query results may reveal local resolver addresses, internal organization domains or device names, so review them before submitting. Don't send your entire browsing history or give an unknown person remote access. If several websites show the same DNS error only when the client is active, even with its default settings, ask support to check the traffic-capture path. If only one site is affected, also check its service status and access requirements so an account restriction isn't mistaken for a network issue.

Slow speeds and peak-hour slowdowns

First, identify what feels slow

Describe the specific speed issue. A page that takes a long time to appear, a consistently slow download, video that drops to lower quality and delayed voice interactions are different symptoms. Choose a destination you can revisit and keep the file, page or content the same while comparing. A slow first page load may involve DNS, the handshake or the destination server. Slow sustained transfers point more toward throughput, while choppy interactions may involve jitter or packet loss. Latency shown in the client doesn't explain the whole experience. A low-latency route isn't necessarily best for sustained transfers, and a successful connection doesn't guarantee the same performance under congestion.

Before testing routes, check your local connection. A weak Wi-Fi signal, distance from the access point, heavy downloads on the same network or a router running a demanding task can all skew results. Pause nonessential syncing and downloads, keep the device's power state stable, and compare from a similar location. If possible, compare wired and wireless connections, but you don't need to buy equipment for the test. Check that the device isn't overheating or in a low-power mode. If ordinary websites are also slow with the client off, investigate local bottlenecks before blaming international routes.

Compare peak hours and routes over time

Repeatability matters when diagnosing peak-hour slowdowns. Record how the same destination performs at different times, along with the route name and network. If one route gets noticeably worse during busy periods and another region or available path restores performance, the difference in routes is worth investigating. If every route and ordinary internet access slow down at the same time, shared local bandwidth or the access link may also be involved. Don't draw lasting conclusions from one failed test or treat a single site's download cap as a plan speed limit. A useful comparison lets someone else reproduce the conditions; a speed-test screenshot alone doesn't.

When choosing a route, you can start with a geographically closer region, then compare how the destination service responds. Distance is only a guide: routing detours, congestion at the other end and the platform's distribution strategy all affect results. VPNPack covers 100+ countries / 230+ routes, but those figures don't promise the same speed on every route and network. Check the dashboard for currently available routes; don't infer a dedicated connection type or streaming support from a region name. For route details, see the server page. To keep your own test records, see how to compare VPN speed tests.

Handle traffic rules separately from speed issues

Check account availability separately from network performance. First confirm in the dashboard that the subscription is active and traffic is available, then run a speed test. Testing itself uses traffic, so avoid repeated large downloads when your remaining usage is low. Monthly subscription traffic resets each month on the activation date, not on the first day of the calendar month. Mid-cycle upgrades are prorated into the remaining days. Traffic packages never expire. See plans and pricing for the full terms. Don't upgrade first to troubleshoot Wi-Fi interference, a destination's speed limit or a configuration error. Identify the bottleneck before deciding how to manage usage.

When reporting slow speeds to support, include the task, destination domain, time of day, network type and differences between the original and alternative routes. If you used a speed-test tool, include its name and test conditions rather than sending only the best or worst screenshot. For video issues, say whether startup is slow, playback keeps buffering or quality changes; there's no need to share private viewing history. If only one service is slow while other tasks work, check that service's status too. A consistent link to a particular time or route gives support a better starting point for investigating the network path. If the issue has cleared, note what conditions restored access so a brief fluctuation isn't mistaken for a permanent fix.

Frequent disconnects and mobile background disconnects

Tell a tunnel disconnect from an app reconnect

First, identify what actually stopped. The client's connection switch turning off, the system VPN indicator disappearing and an app reloading while the client remains connected are different symptoms. Note whether it happened while the screen was locked, switching Wi-Fi networks, entering an elevator, waking from sleep or opening another network tool. If the system tunnel is still up but an app session drops, the service may have reconnected, the app may have a background policy or the network may have changed briefly. If the client process exits, check system resources and crash details. Don't rely on the status-bar icon alone to decide whether the full proxy path is working.

Switching networks changes the path used by existing connections. When a device moves from Wi-Fi to mobile data, existing connections may not carry over, and the client and apps may reconnect separately. Test on one network first and see whether disconnects also happen without switching. Then switch networks deliberately and check whether the client recovers. If the issue occurs only during a switch, record how recovery happens instead of importing a new subscription repeatedly. Also check for client rules that connect or pause automatically based on network conditions; these can look like unexpected failures. Restore the settings that suit your normal use when testing is finished.

Android: background activity and battery management

Android battery optimization, background activity limits and manufacturer task cleaners can interfere with a client's connection. Open the app's system settings and check battery use and background permissions. Allow necessary background activity using the options available on your device. Some devices also offer auto-start or task-retention controls, but names vary. Note the original settings and adjust the client only; don't exempt every app. Notifications can make connection status easier to observe, but a visible notification doesn't guarantee a working connection. Check permissions against the Android setup and connection guide, then compare access before and after locking the screen.

If the connection recovers as soon as you unlock the device but keeps dropping while the screen is locked, check background policies first. If it also disconnects frequently with the screen on, battery saving alone doesn't explain it. Compare routes and networks, and check whether another VPN app starts in the background. Options such as always-on VPN or blocking connections outside the VPN change what happens when a connection drops; understand them before changing anything. Don't install unknown system-modification tools to keep the client running in the background, and don't assume menus match across devices. On managed devices, organization policies may control these options.

iOS and desktop: record how the connection recovers

On iOS, check that the VPN configuration in system settings belongs to the current client and look for on-demand rules or another app taking over. App refresh behavior after the screen locks doesn't necessarily mean the system tunnel ended. After unlocking, check the client status and revisit the same destination. Don't assume a background setting can keep every app session alive indefinitely. On desktop, check sleep and wake, network-adapter power saving and network service restarts. If the connection fails after every wake but recovers when you disconnect and reconnect normally, record what changed before and after waking. For macOS permissions and setup, see the Mac setup guide.

If you suspect the client crashed, save the system's error summary and check whether it came from the download page in the dashboard before considering a normal reinstall. Don't delete all app data first; you could lose usable settings and troubleshooting records. If the connection is stable in the foreground but fails in the background, include the steps for locking and unlocking the screen. If it disconnects in both cases, note the route, network switches and other apps that may be taking over. Reproduction steps are more useful than a long screen recording, which may expose notifications or account details. Capture only what's needed and redact private information before sending it so support can investigate the connection lifecycle.

Subscription update failures and configuration issues

Check your account first, then how you imported the subscription

A failed subscription update and a failed route connection happen at different stages. An update failure means the client couldn't retrieve or read the configuration. A connection failure means a route in an existing configuration isn't working. Sign in to the dashboard to confirm that your account is accessible and the subscription is active; check for any traffic or order status that needs attention. VPNPack requires no email address; you can create an account with a username and password. Troubleshoot using your original account rather than creating new accounts to avoid checking it. If the dashboard works but the client reports an update failure, save the exact error and confirm that you're updating the current account's subscription, not an old source left in the profile.

Use the import option in the dashboard that matches your current client. Clients may support different subscription formats and fields; a link that works in one tool may not work in another. If copying manually, check for spaces, line breaks, quotation marks or punctuation added by a chat app. Don't use the dashboard login URL as a subscription URL. Example addresses explain the format only; they aren't real service links and won't provide VPNPack routes. Get your actual subscription from the dashboard after signing in. Don't pass it through public posts or unknown conversion sites.

https://example.com/sub?token=xxxx

Choose a fix based on where the update failed

“Download failed” usually means the request for the configuration didn't complete. Check basic connectivity, network sign-in and proxy settings. “Parse error” means the response couldn't be read in the expected format; check format compatibility. For an “authorization expired” message, return to the dashboard and check subscription status and the source currently in use. Error names vary by client, so don't rely on a translated summary alone. If the response contains a web page instead of configuration data, you may have reached a login page, error page or sign-in portal. Don't post the full response publicly; it may include account identifiers. Save the error summary and send only the necessary redacted excerpt in a support ticket.

Also check which network path the update uses. If the old profile no longer works and the client insists on using it to retrieve a new configuration, updates can get stuck in a loop. Keep the old profile, then use an available basic network connection to update it if the client allows, or import the configuration again through the dashboard. Don't delete every route without a backup or keep tapping Update; repeated requests won't fix an incompatible format and can make troubleshooting harder. If route names change after an update, use the new profile to check your selection again. Old manual groups may still point to entries that no longer exist.

Configuration changes and subscription privacy

Automatic updates may overwrite manual rules, while manual edits can break the configuration structure. If the issue started after an edit, compare against an unchanged profile from the dashboard, then add local overrides using a method supported by the client. Don't combine configuration files in different formats or disable security checks to fix a syntax error. Check indentation, field names and file type, but note that this guide doesn't provide a universal settings template. If the app says a feature isn't supported, use a compatible import option or client rather than deleting fields at random until the error disappears.

Subscription URLs often contain access credentials and should be treated as account details. Redact the full URL, QR code and its parameters in screenshots, and don't paste the complete URL into a support ticket by default. If you've shared it publicly, use the dashboard's reset or regenerate option if available. If you can't find one, ask support how to proceed before updating your devices. For an update issue, the client name, import method, exact error, dashboard status and whether the basic network works are usually enough. If your account status differs from what you expect, check the plan terms. Send payment and order issues to support rather than making another payment to try to fix the subscription.

One app won't connect: routing and traffic capture

A working browser doesn't mean every app uses the same route

If the browser works but an app doesn't, first check whether they really use the same network path. Apps decide whether to follow the system proxy: some use system settings, while others connect independently. A virtual adapter or system VPN mode captures traffic at a different layer, but may still have exclusion rules. Don't assume that enabling the client sends every process through the same exit. Note the client's current mode, the affected app and what happens when the browser visits the same service. Then check whether the client has a direct-connect or bypass rule for that app.

Rule-based routing sends traffic according to conditions such as domain, address or process; available options depend on the client. An app may connect to separate domains for login, resources, messaging and updates. Reaching its main domain doesn't mean every request is routed correctly. If the client has connection logs, check which rule matched the failed request and which route it selected. Logs can reveal domains visited and app activity, so keep only the relevant excerpts for local troubleshooting. “No logs” is VPNPack's service privacy statement; it doesn't mean the client on your device won't create local diagnostic data. These are separate things.

Use temporary modes for comparison, not as a permanent fix

If the client offers a clear mode switch, save the current settings and temporarily compare rule-based routing with broader traffic capture. Keep the route and target app the same. After switching, fully close and reopen the app so existing connections don't keep using the old path. If broader capture fixes the issue, check rule matching, exclusion lists and the app's own proxy settings. If not, investigate the destination's response, DNS and route differences. Restore the mode that suits your everyday use when testing is done. Don't route organization intranet traffic, printers or local devices through an unsuitable path just to fix one app.

On desktop, proxy settings may also differ between environment variables, terminal tools and browser extensions. A graphical app working while a command-line tool fails doesn't necessarily mean the route is down. Check the tool's official proxy instructions and confirm it supports the current mode. Don't enter a subscription URL in a field that asks for a local proxy server. Conversely, a successful command-line request doesn't prove that a graphical app has the right session, certificate or DNS settings. Use the local address and port shown by the client; don't copy parameters from another guide or expose a proxy port intended only for local use to the public internet.

Distinguish platform restrictions from network issues

If an AI tool shows a region message, loops during login or asks for account verification, save the exact message first. A network route can affect how you connect, but it can't grant account eligibility, override regional policies or provide service authorization. The behavior of tools such as ChatGPT and Claude may also change as their platforms are updated; one successful connection isn't a promise of permanent availability. Try the relevant public page in a browser, then compare it with the app and check the service's status information if needed. For background, see the AI guide. Troubleshooting here should be based on the current error and actual request, not assumptions based on the service name.

For streaming apps, distinguish network connectivity from content availability. Opening the app, signing in and playing a particular title are separate stages. A title being unavailable doesn't necessarily mean the proxy isn't working. When contacting support, say whether the problem occurs at launch, sign-in, loading or playback, and whether the web version works or a temporary mode changes the result. Don't send account passwords, session cookies or downloaded paid content. If only one app is affected, share its error summary and relevant rule match instead of a full device traffic log. This helps narrow down the issue while limiting unrelated personal data.

Platform differences and device alerts

Windows and macOS: check permissions and leftover settings

On Windows, first confirm that the client has the permissions required for its current mode. A system proxy and virtual-adapter traffic capture have different requirements; getting one mode to start doesn't mean the other is ready. If the browser stops working after you exit the client, check whether the system proxy still points to a local endpoint that has stopped. Use the client's normal shutdown process or restore the settings you recorded earlier. Don't run network-repair scripts from unknown sources or permanently disable security software to troubleshoot. Save the exact text of any driver or permission alert, then check that the installer came from the client download link in the dashboard.

On macOS, creating a VPN configuration or enabling related network features may require system approval. An incomplete approval, removed configuration or changed network-service order can affect traffic capture. In system settings, check the network configuration associated with the current client, taking care not to remove one required for work. If you've installed another proxy tool, exit it normally and check for leftover proxy settings. Review browser extensions and the system proxy separately. If macOS blocks an app from opening, verify its source and follow Apple's official guidance. Don't weaken security settings across the device just to connect. For setup steps, refer to the getting started guide.

Linux and mobile: service status and traffic capture

On Linux, distinguish desktop proxy settings, terminal environment variables, background services and virtual-adapter routes. A desktop app working doesn't mean the terminal inherits the same settings, and a terminal tool working doesn't mean the desktop session has a proxy configured. If the client runs as a background service, use its official documentation to check service status before reviewing permissions and port conflicts. Service management varies across distributions; this guide doesn't provide a restart command that applies to every system. Record custom routes and DNS settings before troubleshooting so you don't overwrite a working organization network configuration.

On Android and iOS, check system VPN authorization and which app owns the configuration, especially if other network apps are installed. If you dismiss the authorization prompt, the client may still show the subscription without establishing a tunnel. Mobile background disconnects are covered above; don't confuse missing authorization with battery management. VPNPack supports Windows / macOS / iOS / Android / Linux. Get the client and subscription from the dashboard. On non-iOS platforms, sign in to access the client. On iOS, availability depends on an eligible plan shown in the dashboard. If a download fails, check the dashboard link rather than looking for an installer from an unknown source.

If you see a device limit warning, don't assume your plan has a device cap

VPNPack allows unlimited simultaneous devices. If a client shows “device limit exceeded” or a similar message, first confirm whether it came from the VPNPack dashboard, the client itself or the destination website. Session limits on another service, client license limits and local connection-pool warnings are different from VPNPack's simultaneous-use policy. Keep the page title, app name and exact message; don't crop it down to just “limit exceeded.” Check that the client is using the current account's profile, not an old service or a subscription shared by someone else. Don't try to fix it by repeatedly removing devices or paying extra.

Unlimited devices doesn't mean they can't affect one another's resources. Multiple devices on the same subscription share its available traffic. Home internet upload, download and Wi-Fi capacity are shared too. If other devices slow down when one starts syncing, check the shared network before assuming there's a device limit. If the dashboard shows a limit that conflicts with the unlimited-device policy, or all devices develop the same issue, submit the exact message and account status in a support ticket. If only one device fails, check its permissions, profile and traffic-capture settings first. Keep a working device for comparison instead of reinstalling every client at once.

Verify recovery, submit a support ticket and protect your data

A green connection switch doesn't prove the issue is fixed

After making a change, retest the original task instead of relying only on the client's connected status. If a website wouldn't load, revisit the same domain. If the connection dropped after locking the screen, repeat the same lock-and-unlock steps. If a subscription update failed, confirm that the configuration loaded and the current route works. Also check that ordinary websites, local devices and organization resources still work. If a mode restores the target page but blocks local resources, you've only fixed part of the problem. Refine the rules rather than treating broader traffic capture as the only long-term answer.

Write down the changes that worked and undo temporary steps that didn't help. Check extensions you paused, DNS settings you changed, background permissions you relaxed and modes you switched. If you can't identify which change restored access, return to the saved state where possible without disrupting essential work, then reproduce the issue one change at a time. Don't risk the only working connection just to get a definitive answer. A short, clear record is more useful than lots of unexplained screenshots, especially for intermittent issues. Next time, you can compare whether the network, route and task were the same.

When to submit a support ticket

Submit a ticket if the issue still reproduces after checking the basic network, comparing the default configuration and trying another route. Contact support if account or order status looks wrong, dashboard messages conflict with published terms, or one route keeps failing. If organization policies block a system permission, contact your administrator. If the destination platform says your account isn't eligible, check its help center too. A support ticket gives someone who can investigate the evidence you've gathered; it doesn't mean every network change has the same cause. If access has returned but the cause is unclear, say “currently resolved” and include what happened before recovery.

Keep ticket details to what's needed: operating system, client name, time and time zone, network type, displayed route name, destination domain, exact error and comparisons you've tried. You can find system and client versions in their settings; don't guess from memory. “Still fails after switching routes, works after changing networks” is more useful than “tried everything.” If only one app is affected, specify the stage where it fails and how the web version behaves. For sleep or lock-screen issues, include the steps that trigger them. The template below can be copied into a ticket and filled in with your details.

Issue:
Operating system and client:
Time and time zone:
Network type:
Displayed route name:
Affected destination domain or app:
Exact error message:
What happened with the client off:
What happened after switching routes:
What happened after changing networks:
Settings changed:
Is the issue resolved now:

Redact attachments and protect account details

Before sending, review screenshots, logs and configuration files. Redact unnecessary account details, full subscription URLs, QR codes, access credentials, sensitive payment information and private notifications. Never send passwords, session cookies or configuration files that can be imported directly. Client logs may contain visited domains, local paths and device names; include only the relevant lines near the error. If support needs more information, confirm how it will be used and provide it through the ticket system after signing in. Don't share credentials in public comments or treat a request for remote access from an unknown person as routine troubleshooting. If credentials have been exposed publicly, take action through the dashboard as soon as possible.

Keep billing questions separate from technical issues. VPNPack supports Alipay / WeChat / USDT and offers a 7-day no-questions-asked refund policy. See the refund policy for the process. Monthly subscription traffic resets on the activation date; mid-cycle upgrades are prorated into the remaining days, and traffic packages never expire. Reinstalling the client won't restore traffic. For an order dispute, include the relevant order details from the dashboard and redact sensitive payment information. Avoid making another payment. To send troubleshooting details, open a support ticket. For common account questions, see the FAQ. Your final notes should state what you did, how the symptoms changed and what remains unresolved.