VPN84 ConnectionTroubleshooting

Can’t connect at all? Start with your local network

“Can’t connect at all” can describe several different issues: the client won’t start, the server list is empty, an error appears on startup, or the client stays on “Connecting” without completing. Each calls for a different first check. Note the exact error, the network you’re on and the route you selected. Don’t uninstall the client yet: that can erase both its configuration and useful clues. Even if reinstalling seems to help, you won’t know what caused the issue.

First, test without the VPN

Disconnect normally in the client, then visit a website you can usually access directly. If local websites won’t load either, check your Wi-Fi, router or internet connection first. Public networks may require you to sign in through a browser. Being connected to Wi-Fi only means your device has joined the network; it doesn’t mean you have full internet access. Once you’ve completed any sign-in, test the client again.

If you still can’t browse after disconnecting, check whether the system proxy was left enabled. If the client exits unexpectedly, your device may keep sending requests to a local proxy that is no longer running. Reopen the client and use its disconnect or restore-proxy option first. Manually disable a proxy setting only after confirming that the client set it. Don’t remove a work proxy from a managed device.

Check subscription status separately from connectivity

Being able to open the client doesn’t mean you have an active route. Check your plan status, remaining traffic and subscription in the user panel. Monthly plan traffic resets each month on the activation date; data packages never expire and remain available until used. If the panel shows an active plan but the client list is empty, see the subscription section. If routes are listed but startup returns a parsing error, check the import format and client compatibility first.

Check that your device’s date, time and time zone are correct. A time mismatch can cause certificate validation to fail, resulting in a secure connection error or rejected subscription request. Restore automatic time sync and try again; don’t disable certificate validation. If the error specifically mentions permissions, a network extension or a virtual interface, grant the requested permission instead of repeatedly clicking Connect.

Next, leave the client settings unchanged and try a route in a different region. If only the original route fails, you’ve narrowed the issue to a particular exit or link. If all routes fail, switch to another local network on the same device. If that fixes the issue, the network you were using is worth checking, but the result alone doesn’t prove which party is at fault.

Choose the next step based on where the failure occurs

A connection timeout, a name resolution failure and an identity verification error in the logs are different issues. A timeout means the request didn’t complete within the allowed time; the problem may be with the local connection, forwarding or target response. For a resolution failure, check the domain and DNS path. For a verification failure, check your subscription and account status. A red icon in the client alone can’t tell you which layer failed.

Don’t run multiple VPNs, proxy tools or traffic interception features at the same time. They can compete over system routes, proxy ports and DNS settings. Keep only the tool needed for your current test, then restore any other network software afterward.

If another device connects on the same network, check the original device’s permissions, leftover proxy settings and client configuration. If the same account can’t connect on different devices and networks while the panel shows everything is in order, submit a support ticket. Include the exact error and the comparisons you’ve already made; that’s more useful than saying “all servers are down.” For initial setup, see the guide.

Connected but can’t load websites? Check DNS and the request path

When the client says it’s connected, that usually means its local service has started or a connection check has passed. It doesn’t prove that every website is reachable. First work out whether all websites fail, only international sites fail, or just one domain fails. Then check whether the error is a DNS issue, timeout, certificate warning or response from the website. The type of error is more useful than a browser that just keeps loading.

Check whether the request reaches the client

Leave the client running, open a target website and check the connection log. If there’s no matching request, check whether the system proxy is enabled, whether your browser has its own proxy settings, and whether the current mode excludes the app. If the request appears but a rule sends it direct, check the route selection. If it uses the selected route, look at the DNS result and the target’s response next.

Your browser’s secure DNS, the operating system’s encrypted DNS and the client’s DNS module may all be active at once. They don’t necessarily conflict, but they can send the same domain through different DNS paths in different apps. Note your current settings, then temporarily turn off the browser’s secure DNS as a comparison. If the problem goes away, check how that feature works with the client rather than treating DNS protection as something to leave disabled.

Check DNS results, not just whether an address appears

Run the query below in your system terminal to check whether the domain returns a result. The example domain illustrates the command format; it doesn’t measure VPN84 route quality. A successful query only shows that the system’s DNS path returned a result. Your browser and client may use their own resolvers, so compare the command output with the client log. You don’t need to install extra software just for this check if the tool isn’t already available.

nslookup example.com

If the query says the domain can’t be found, check the spelling and whether the site is still available. If the DNS server doesn’t respond, check whether your local network allows the DNS method in use. If the browser fails but the system query succeeds, try a temporary new browser profile to rule out extensions, cached data or a separate proxy. Don’t start by clearing all browsing history; a login session isn’t a substitute for DNS evidence.

A returned address doesn’t mean you should add it permanently to your configuration. Large websites may assign different endpoints based on region, network and service status. Pinning an old address can break certificates, content delivery or sign-in. And don’t use a direct-IP test instead of testing the domain: secure sites often require the correct domain and matching certificate, so a direct-IP failure doesn’t mean the route is unusable.

Tell certificate issues apart from restrictions imposed by the site

For a certificate error, first check your device’s clock, whether you need to sign in to a public network, and whether a network filtering component managed by your organization is installed. Don’t ignore the browser’s security warning and sign in anyway. If only one site says your region isn’t supported, your account is restricted or verification is required, the request may already have reached the platform. Check your account region, the platform’s rules and the route’s exit region instead of continuing to change local DNS settings.

If text loads but images, sign-in buttons or media don’t, different resource domains may be taking different routes. Check the client log for the page’s main domain and the failing resource domain. Temporarily test with a more comprehensive proxy mode, then restore your original mode. If the test works, adjust the relevant rules rather than leaving every app on an unverified rule set.

When retesting, send the request again before considering whether to clear the relevant cache. If you change DNS, switch routes and clear the cache all at once, you won’t know which change fixed the issue.

If the problem persists, include the target domain, error type, whether the client logged a request, the DNS method and the results on different networks in your support ticket. The domain is enough; don’t include a full page URL that contains sign-in credentials. For regional and account restrictions on specific streaming services, see Streaming. If only one app fails, continue to the app routing section.

Slow speeds and peak-hour lag: check for bottlenecks

One download speed number can’t explain every speed issue. A slow first page load may be related to DNS or connection setup; repeated video buffering may point to throughput or instability; choppy calls call for a closer look at packet loss and jitter. Describe the activity that’s affected before choosing a test. Using a download test to judge call quality, or page-load times to judge every route, can lead you in the wrong direction.

First rule out local congestion and Wi-Fi issues

Pause cloud sync, system updates and other heavy transfers on the same device, then try the original task again. Other devices on your home network may also be using bandwidth. Power-saving settings, storage writes and file extraction can affect download performance too. If possible, compare wired and Wi-Fi connections. If only Wi-Fi is slow, check signal strength, interference and router placement first.

Don’t run several speed tests at once while troubleshooting. Speed tests use bandwidth, can make a call or video less stable, and consume more traffic. Check the actual task first, then track changes using the same tool, target and similar test conditions. A trend is more useful than a peak; a brief speed spike doesn’t show that a connection is stable over time.

Compare route types and destination regions

VPN84’s route information covers IEPL dedicated lines, relayed routes and direct routes. These describe how traffic is routed, not how fast each option will be at every moment. A direct route may depend more on your current network’s international path; a relay adds a forwarding step; and dedicated lines are still affected by local access, the exit and the destination service. Choose based on your needs and the network page, not just the route label.

Compare routes in nearby regions first, then try different regions. A shorter geographic distance doesn’t guarantee a shorter end-to-end path, and the target platform may serve resources from another region. When changing regions, consider account sign-in and regional requirements; frequently switching exits to chase a better speed test can trigger repeated verification. For work, a stable session is usually more valuable than chasing a higher momentary speed.

Track peak-hour slowdowns by time

If the connection works during the day but slows down in the evening, note when it happens using the same device and network, including your local time zone. Keep the task the same and switch the route or local network. An issue with one route points to a different scope than an issue with all routes. If another network works, check your local connection or the path between networks first.

Automatic speed tests in a client usually cover specific test destinations, not the actual paths to streaming, meeting or file services. If a test looks good but the real task is still slow, include the service domain and what you were doing instead of sending only a screenshot of the route list. If the target service is congested, switching routes may change what you experience without fixing the bottleneck on the service itself.

Don’t change connection or virtual interface settings you don’t understand. Some settings can help on specific networks, but changing them incorrectly can turn a speed issue into a total connection failure. Save your original configuration, confirm the client supports the setting, and make changes only in response to a specific error or support advice. VPN84 allows unlimited simultaneous devices, but devices sharing a local network still share its bandwidth.

To review your results, use the speed testing guide and key metrics to record tests under comparable conditions. Include your network, target service, affected times, route name and what changed after switching routes in your support ticket. There’s no need to attach a full recording of a speed test running continuously. Consider changing plans only if your price or traffic needs have changed; a higher tier isn’t the first step for troubleshooting connection issues.

Frequent disconnects and background drops: check the session and system power settings

A disconnect can happen in the client process, system tunnel, route session or target app. When it happens, check whether the client is still running, whether the VPN status disappeared from the system, and whether other apps also lost access. If only a meeting or website signs out while the client continues to carry other traffic, that doesn’t necessarily mean the whole VPN disconnected. The target app may have ended its own session.

Identify what happened just before the disconnect

Think about whether the problem started right after the screen locked, you switched Wi-Fi, left network coverage, enabled power saving or put your computer to sleep. Switching networks changes the device’s local route, and existing connections may not move over seamlessly. Apps may also stop running during sleep. Match these events to the error time to tell an idle disconnect from one that happens during active use; they require different checks.

First reproduce the original task with the screen on and network unchanged, then test with the screen locked or after switching networks. If it’s stable in the foreground but fails after locking, check the system’s background restrictions first. If it also disconnects during active use, compare routes and local networks. Don’t run another VPN tool during the test; it could replace the system tunnel and make the original client appear to have dropped.

Check mobile background permissions and battery settings

Battery optimization, auto-start controls and background activity settings vary across Android devices. Find the settings for the client you’re using, check that background activity isn’t restricted, and look for system cleanup tasks. Menu names may differ, so they don’t need to match this wording exactly. Change only the permissions the client needs; don’t disable your device’s security features across the board just to troubleshoot.

On iOS, first check that the VPN status in Settings matches the status in the app, then see whether the issue occurs after switching networks. Don’t assume the tunnel stopped just because the app’s screen doesn’t update in the background; test the target service. If another app replaced the configuration, return to the VPN84 client and reconnect. Check whether configurations you no longer use are still installed.

Before enabling a system-provided always-on or on-demand connection feature, check how it works with your client. These features can’t restore every connection automatically; public network sign-in, sleep and permission changes may still interrupt access. If you can’t reach a public network sign-in page after enabling the feature, restore your original settings temporarily, complete sign-in and test again instead of repeatedly reconnecting.

Check sleep, network adapters and traffic interception on desktop

After waking from sleep, Windows, macOS and Linux may need to reinitialize a network adapter, restore a network extension or reapply system proxy settings. If the connection fails every time the device wakes but works after a normal disconnect and reconnect, note that consistent trigger. Check permission prompts and client startup after system updates. Don’t delete every virtual adapter; other work software may rely on them.

If your network is still connected but a download or call drops while newly opened websites work, an existing connection may have failed while new ones can still get through. Reopening the target app is more useful for diagnosis than repeatedly changing routes. If new requests fail too, check whether the client is still receiving traffic. Keep the relevant log excerpts from before and after the disconnect; the last line alone often doesn’t show what triggered it.

Auto-reconnect can try to restore a connection, but it can’t guarantee that an existing meeting, upload or sign-in session will continue. Before an important task, check that the network is stable and whether the target app supports resuming uploads or sessions.

In your support ticket, include the device OS, whether the app was in the foreground or background, screen lock and wake events, any network switches, and whether the issue persists on another route. If it only happens on one Wi-Fi network, include results from other networks too. “It fails after I lock the screen, then reconnects when I reopen the app” is more useful than “the client won’t stay connected.”

Subscription update failed? Check the source, format and local cache

Updating a subscription and connecting to a route are separate requests. A subscription provides routes and configuration; a successful update doesn’t guarantee that every route is currently reachable. Likewise, a working route doesn’t guarantee that the update endpoint is accessible over your current network. First determine whether the update returns an error, the list is empty afterward, route names stay the same, or the client rejects the content on import. Then decide whether to check the network or the format.

Confirm the subscription source in the user panel

Sign in to the user panel and check the account and plan status before retrieving your subscription there. VPN84 doesn’t require an email address; accounts use a username and password. Make sure you haven’t accidentally signed in to a different account. Don’t look for subscription details in chat history, old screenshots or search results, and don’t use sample addresses from public guides as your actual subscription link.

After copying the subscription, check that it hasn’t been altered by line breaks, spaces, rich text or other content. Don’t paste the complete link into a public testing site: anyone who has it may be able to retrieve your configuration. Use an obvious sample only when demonstrating a format. For actual setup, use the import button in the panel or the copied value; don’t guess or edit URL parameters.

Handle the specific error instead of repeatedly resetting

If the update times out, first check whether you can open the user panel, then compare using another local network. Some clients use the current proxy when updating subscriptions, so an update request may follow a failed route if the selected route is down. Check whether the client lets you choose a subscription update route. Note the original setting before testing direct or another working route, and don’t change app routing rules at the same time.

If the content can’t be parsed, check that the import method matches your client. Text appearing in a browser doesn’t mean it’s the configuration format your client needs; the client may have downloaded a sign-in or error page instead. Don’t append parameters based on a generic online guide. Select the matching option in the user panel, and if it still fails, submit the exact error.

If the update succeeds but the list is empty, check both the panel status and the client’s update log. Confirm that the plan is active and traffic is available, then check whether the client has hidden routes using a filter or placed them in a different configuration group. Data packages never expire and remain available until used; they don’t retain traffic after it has been used up. A payment record alone doesn’t confirm your current service status.

Keep a recoverable configuration when clearing cached data

Unchanged route names don’t necessarily mean an update failed. If the service configuration hasn’t changed, fetching it again may return the same content. Check the client’s update time and result message rather than expecting new routes each time. If you have several similar subscriptions, confirm that the one you’re editing is the one currently enabled. Otherwise, you might update a backup and keep using the old configuration.

Before deleting an old subscription, note the active configuration name, routing mode and any important local settings. If the client allows it, add the new subscription temporarily for comparison, but don’t let multiple duplicate configurations control the network at once. Remove the old entry only after you’ve confirmed the new one works. Clearing every configuration also removes a useful fallback.

If you think your subscription has been exposed, reset it in the panel if that option is available, then update each device. If there’s no reset option, contact support through a ticket. The old link may stop working after a reset, so devices that haven’t been updated will return errors. Don’t treat that expected failure as a device issue, and don’t expose the newly generated full subscription link in your ticket attachments.

Keep subscriptions, account passwords and client logs separate. Support usually needs the error type and a redacted excerpt, not your password, full subscription or sensitive payment credentials.

If the panel status doesn’t match what the client shows, note when you retrieved the subscription, the client name, import method and error. When upgrading a monthly subscription, the price difference is converted into remaining days; don’t try to calculate a new traffic reset date yourself. See the plans page and panel for billing details. For the complete initial import process, check the getting started guide.

Only one app fails? Check routing and app-specific proxies

If your browser works but one app doesn’t, at least one route is working, but that doesn’t mean the app uses the same route. It may ignore the system proxy, have its own proxy settings, use a separate DNS resolver or send sign-in and content requests through different processes. First identify whether the failure happens at startup, sign-in, sync, media playback or upload; don’t lump different stages together.

Check the requests before deciding whether a rule matched

Open the client connection log, note your original mode, then launch the target app and reproduce the issue. If you don’t see related connections, check whether the app supports the system proxy or needs the client’s traffic interception feature. If you do see a connection, check the matched rule, actual route and error status. A request sent direct needs different troubleshooting from one that uses a route but is rejected by the destination.

An app’s name doesn’t always match the domains it requests. Sign-in pages, verification codes, content delivery and update services may all use different domains, so a rule for the main site alone may not be enough. Look for missing entries in the actual failed requests; don’t import large rule sets from unknown sources. Keep a record of any rules you add, and check that local services that worked before aren’t now being routed through the proxy by mistake.

Use a temporary mode for comparison instead of permanently widening coverage

If the client supports a more comprehensive proxy mode, note your original settings and test that mode temporarily. Keep the account, route and network unchanged for comparison. If access works in that mode but not in rule-based mode, check the routing or DNS path. If both fail, don’t keep changing rules; check the target platform, account region or route exit instead.

The system proxy affects apps that choose to use it. A virtual network adapter or system tunnel may cover more traffic, depending on the platform and client. Don’t treat any one mode as a universal fix. When enabling traffic interception, check for permission issues and conflicts with other security software. On managed work devices, follow your organization’s policies and don’t change its network configuration without approval.

Command-line tools, development environments and desktop apps may each use their own proxy environment variables. They might keep using an old value even after the browser works again. Check whether the variables point to the local proxy that’s currently running, and whether the app needs to restart to pick up the change. Don’t copy port numbers from an online guide; use the value in your client settings.

Separate network access from platform eligibility

For an issue like “ChatGPT won’t open,” note exactly where the process stops. A page that can’t establish a connection and a page that loads but won’t let you use your account are different problems. The exit region, platform availability, account status and browser environment can all affect the result. VPN84 routes can be used to access AI tools, but that doesn’t guarantee the target platform will accept every account or exit region.

Use the same approach for streaming: opening the homepage doesn’t prove that the catalog, playback authorization and media resources are available. If you see a region message, check the selected exit and account region against the platform’s requirements. Frequent region changes may trigger extra verification, so keep your test conditions stable. See Streaming access for more details, and don’t judge availability from a homepage screenshot alone.

If the app has a web version, test it on the same device and route. If the web version works but the app doesn’t, the issue is more likely to be the app’s configuration, cache or network behavior. If both fail, check the domains and exit they share. Before clearing app data, check whether that will delete offline content or sign you out. Use a temporary, reversible configuration for comparison where possible.

Don’t troubleshoot access by disabling certificate checks, installing unknown certificates or using modified apps from untrusted sources. These steps change your security protections without showing whether the route or routing rules are correct.

Include the app name, where the failure occurs, whether its web version works, your current mode and whether the client logged related requests in your support ticket. You can attach redacted rule-match logs, but don’t include private conversations. For remote work and collaboration apps, see how to choose a route for work, and check connectivity separately from call quality.

Device-limit messages and platform differences: check where the message comes from

VPN84 allows unlimited simultaneous devices. If you see “device limit exceeded” or a similar message, first check whether it came from the user panel, client, operating system or target website. A client’s own license restriction, a streaming service’s device limit and a network configuration conflict aren’t the same as VPN84’s device policy. Keep the exact message and note where it appeared before deciding who can help.

First check the account and client configuration

Check that the account signed in on this device is the one you expect, that the subscription came from that account, and that you’re using the intended configuration. Some devices keep an old client or a configuration with a similar name. The route name may look the same even when it uses a different subscription. Verify where the configuration came from; don’t create accounts or pay again just to clear a warning.

Unlimited simultaneous devices describes the device policy; it doesn’t mean every device can share the same local settings or that your home connection has unlimited bandwidth. Each device still needs a properly configured client, permissions and subscription. When several devices transfer data at once, they share the local connection and Wi-Fi resources. If other devices slow down when you add one, check for bandwidth contention in the speed section rather than assuming a device limit.

Check how each platform handles network traffic

On Windows, if your browser works but other programs don’t, check whether those programs use the system proxy and whether another network filter is enabled. On macOS, if a network extension permission prompt appears after an app update, follow the system instructions and test again; don’t assume an old authorization is still valid. On managed devices, settings may be controlled by your organization, so check whether you’re allowed to change them first.

On Linux, desktop proxy settings, terminal environment variables and system routes may all be managed separately. A command-line tool working doesn’t mean a graphical app uses the same proxy; a graphical app working doesn’t mean a service process has the same environment. Check the configuration source for the process that’s actually failing. Don’t assume a temporary terminal setting applies to the whole device.

Handle downloads separately from connection issues

Download clients from the downloads section of the user panel. After signing in, you can access clients for Windows, macOS, Android and Linux. The iOS download option is available with an active plan. If you can’t see the right option, check your sign-in and plan status. Don’t download installers from search results or treat clients from other sites as software provided by this service.

If the system asks for VPN or network extension permission after installation, review what it does before approving. Without permission, the client may open and show routes but fail to establish a system connection. If you previously denied access, check the relevant permission in system settings and retry using the client’s instructions. Repeatedly uninstalling the client won’t bypass the permission process and may make the original configuration harder to track.

If a video service says you’ve reached its simultaneous playback device limit, check the rules for that platform’s account. If the client says its own license has expired, check where you got the client and its licensing terms. Don’t upgrade your data allowance because of either message. See the plans page for VPN84 traffic and billing details; an “extra device slot” isn’t an explanation for an issue when no such option exists.

If only one device has the issue, compare it with another device using the same account, route and network. If the other device works, focus on permissions, leftover proxy settings and app behavior on the original device. If the same device-limit message appears on different devices, submit the exact error and a redacted screenshot, and say where it came from. Support needs this evidence to check the configuration or service status, not personal files from your device.

Submit a support ticket and verify recovery: make the results reproducible

If the issue persists after basic comparisons, submit it through the user panel support ticket system. Contact support if the panel shows an active plan but you can’t connect across different devices and networks, subscription updates keep returning invalid content, startup repeatedly fails despite correct permissions, or the same route keeps failing under consistent conditions. Don’t spend extra time or traffic on tests just to cover every possibility.

Describe the symptoms, conditions and results separately

Describe what you actually see. For example: “The app’s sign-in page loads, but submitting the form returns a connection timeout”—not just “it doesn’t work.” Include the device OS, client, local network, route name and time of day, and say whether it happens consistently. Then list what you’ve tried, such as switching networks fixing the issue or switching routes making no difference. Separate what you know from what you suspect so support can follow the evidence.

Include your local time zone and use the route name as it appears in the client. If you don’t remember the exact time, give an approximate period rather than inventing a precise timestamp. Copy the error exactly. If it’s in another language, keep the original and describe the steps that caused it instead of translating it into a potentially inaccurate conclusion. List errors from different parts of the process separately.

Share only the diagnostic information needed

Include only the log excerpts around the issue, and check them for subscriptions, account identifiers, full URLs or other sensitive content first. A browser URL may contain temporary credentials, so redact it in screenshots. Don’t send your password, full subscription link or sensitive payment details. If support needs more information, confirm the purpose and what to redact before sending it in a ticket.

VPN84’s privacy policy emphasizes anonymous, no-logs service. Keep any device details, error excerpts and screenshots you submit for troubleshooting limited to what’s necessary. You don’t need to provide your full browsing history or private content as proof of connectivity.

When possible, add results to the original ticket instead of splitting one issue across several conversations. If you fixed it yourself, say what you changed and whether the fix is stable. For intermittent issues, keep a brief record of the conditions, symptoms, temporary fix and what triggered the issue again. That’s more useful than sending screenshots without context.

After applying a suggestion, retest the original task

When you receive a suggested change, save your original settings and apply one change at a time. After each change, test the task that originally failed; don’t just check whether the client says it’s connected. For a website, verify the page and key resources. For a call, check the actual audio and video. For a subscription, confirm that it updates and the routes work. Fixing one test destination doesn’t necessarily fix the original task.

After recovery, remove temporary settings added during troubleshooting, such as a broader proxy mode, temporarily disabled browser DNS or a backup configuration. Keep only changes you’ve confirmed are necessary. If restoring your original settings brings the problem back, note that link and make the relevant setting the focus of the next check. There’s no need to start over and repeat every step.

For account, order or traffic questions, rely on the status shown in the user panel. Monthly plan traffic resets each month on the activation date, and the price difference for an upgrade is converted into remaining days. Data packages never expire and remain available until used. Don’t estimate remaining traffic from a cached status on another device, or assume that a brief return to normal browsing means a billing issue is resolved. Check the plans page for prices and billing periods.

If the service still doesn’t meet your needs, VPN84 offers a 60-day money-back guarantee. See the refund policy for how to apply and the terms; submit account-related requests through a support ticket. Keep refund requests separate from troubleshooting details; there’s no need to exaggerate losses or include unverified speed test results. See the terms of service and privacy policy for more information.

The final outcome should be a repeatable conclusion: where the problem occurs, what triggers it, what restores service and which settings need to stay in place. If you can only work around the issue without confirming its cause, mark the fix as temporary. If the same symptoms return, you can pick up at the layer you identified instead of deleting configurations, reinstalling or switching routes at random.