VPN Troubleshooting Guide

Can’t connect at all? Start with the connection basics

Break the problem down into observable symptoms

“Can’t connect” could mean the app won’t start, or that a selected route times out. First note where the failure occurs: Does the app open normally? Is the route list visible? Does clicking Connect trigger a system permission request? Does the connection status change? Separating these symptoms helps determine whether to check the installation, permissions, subscription or network. The connection icon only shows the app’s current status; it doesn’t prove that web traffic is using the selected route.

Before you begin, note your current network, route name and exact error message, and keep your existing settings unchanged. Don’t change the mode, DNS settings and route all at once; even if things start working, you won’t know which change helped. Disconnect the client and check whether your local network can reach the websites you normally use. If those sites are also unavailable, first check Wi-Fi sign-in, your router connection or your internet provider. A device connected to Wi-Fi but not yet authenticated may also leave the client waiting indefinitely.

Check the local network, permissions and route in order

Once you’ve confirmed the local network is working, quit other tools that manage network traffic, then reopen the VPNFile client. Different network tools may configure the system proxy, virtual adapters or DNS rules at the same time, overriding each other and making a connection appear successful even though requests can’t get through. Security software on a managed work device may enforce organization-wide policies. Don’t remove drivers or disable managed protection yourself; check any warnings and, if needed, ask your device administrator whether this type of connection is allowed.

1. Open the user dashboard to check that your subscription is active and has traffic available, then update the subscription in your client.
2. Check whether the system is waiting for permission to configure the network. Only approve a request if its source is clear and it matches what you’re doing.
3. Select a different route from your subscription, leave the other settings unchanged, and see whether it fails at the same stage.
4. If possible, switch to a different local network and compare results using the same client and route.

If every route fails on one local network but works after you switch networks, the issue is more likely related to that network’s egress policy, authentication or connection. If one route fails across different networks while others work, note its name and ask support to investigate. These comparisons can help narrow down the cause, but aren’t a definitive diagnosis. One successful test doesn’t prove the entire network will always work, and a single failed route doesn’t mean your subscription is invalid.

Understand the error instead of repeatedly clicking Connect

A “timeout” usually means a request didn’t complete within the client’s wait period. The failure could occur during DNS resolution, connection setup or later communication. For an “invalid configuration” error, first check how the subscription was imported and whether the client is compatible. For a “permission denied” error, revisit the system authorization prompt. Keep a record of the screen and action that triggered the error; a screenshot of the red text alone is less useful. If the same step fails after restarting the client, stop retrying so the useful log entries don’t get buried under repeated duplicates.

If you haven’t finished the initial setup, return to the Guides. If you’ve imported the subscription but several routes keep failing, note what happened when you switched networks, then contact support through the user dashboard.

Don’t install certificates, drivers or so-called repair tools from unverified sources just to troubleshoot. If your system clock is clearly wrong, enable automatic time setting before trying again; an incorrect clock can interfere with secure connection checks. When contacting support, include the stage where it failed, any permission prompts and your results on different networks, and say whether it worked before. This helps support distinguish an initial setup issue from a change that occurred during use, without repeating the installation steps.

Connected but websites won’t load? Check DNS and egress

First determine whether one site or many are affected

If the client says Connected but websites won’t load, test different sites and apps. If only one site fails, the site itself may be down, subject to regional rules or affected by your browser settings. If the browser fails but other apps work, check the browser’s proxy, extensions and encrypted DNS settings. If nothing can connect, check whether system traffic is reaching the client and whether DNS requests are getting a response. Don’t assume every access error is a route failure.

When testing, use familiar websites with a clear source. Note whether the browser says “server not found,” “connection timed out” or “certificate error,” or whether the platform denied access. Each points to a different issue: a DNS failure isn’t the same as slow data transfer, and you shouldn’t bypass a security warning to get around a certificate error. First check your device’s date, the spelling of the domain and whether a network sign-in page is waiting, then decide whether to investigate the client.

Trace the DNS resolution path

DNS translates domain names into addresses that devices can connect to. Requests may be handled by the system resolver, a browser’s encrypted DNS feature or client rules, so it’s not unusual for a browser and command line to show different results. Check the client for DNS-related errors, then see whether an old manual DNS setting remains on your system. If you don’t have a specific reason for custom DNS, note the current value and restore the system default, then reconnect as described by the client. Don’t copy public DNS addresses from random online guides.

If the domain resolves but the page still times out, check whether traffic is matching the expected rule. In rule-based mode, different domains may use different egress routes; browser extensions can also set their own proxy. Temporarily pause network-related extensions and test with a temporary browser profile rather than clearing all your everyday browsing data. If the temporary profile works, your usual browser environment differs; re-enable extensions one at a time to find the cause.

Treat cache, certificate and regional messages as separate issues

DNS cache can retain results from before you switched networks. Try closing the affected app, reconnecting the client and reopening the app; if necessary, use a platform-supported method to flush the system DNS cache. Flushing the cache isn’t a general fix: it won’t resolve incorrect routing, an invalid subscription or a website outage. Before changing encrypted DNS settings in your browser, save the original value and check whether the change matches the client’s recommended setup.

If a page displays a message such as “This region isn’t supported,” at least one request has reached the platform. Check the platform’s regional requirements and your actual egress location instead of repeatedly clearing the DNS cache.

Don’t use direct access to an IP address to decide whether an HTTPS site should work. A website may require the correct domain, certificate and virtual host settings, so an error when accessing an IP directly doesn’t prove the route is failing. Also, a successful DNS lookup in the command line doesn’t mean the browser took the same path. The browser’s own DNS method, cache and proxy settings can all change the result.

If several unrelated sites still fail after restoring default DNS, updating the subscription and switching routes, send support the affected domains, error messages, system DNS results and relevant excerpts from the client log. The domain alone is enough; don’t send a full URL that includes your sign-in status. Remove query parameters from links that contain private information. Support needs to know which domain and step are affected, not your personal browsing history.

Slow speeds and peak-hour slowdowns: compare routes, not just speed tests

Start by defining what feels slow

Slow page loads, slow file transfers, video buffering and choppy calls aren’t the same problem. A webpage may be affected by DNS and connection setup; file transfers also depend on the source server and local storage; real-time calls are more likely to reveal packet loss and jitter. Pick a routine action that reliably reproduces the issue and note when it happens and what you see. Don’t use a speed-test result as a substitute for real-world experience, or infer download speeds from the connection time shown in the client.

Before testing, pause cloud sync, system updates and other high-bandwidth tasks, then check your local Wi-Fi signal. Being far from the router or dealing with nearby wireless interference can make international access feel slow. If possible, compare over a wired connection or repeat the same task closer to the router. If local services you normally use also slow down when the client is off, address your local connection first instead of changing your subscription or repeatedly switching clients.

Compare routes under the same conditions

VPNFile offers subscription routes organized by region, covering 90+ countries / 240+ routes. This describes the available regions and routes; it doesn’t mean every route will perform the same on every local network. Choose with the destination service’s regional requirements, your local connection and route type in mind. A geographically closer route can be a good starting point, but routing detours, peering quality and the destination’s location can make a farther route a better fit for a particular task.

Route type helps explain the path; it isn’t a fixed speed ranking. Keep the destination, test file and local network the same, and change only the route. If you change the destination or mode at the same time, the results are hard to interpret. For a full explanation of route selection, see the Nodes & Routes page. For meetings and collaboration, read the remote work route selection guide to focus on the metrics that matter for your task.

For peak-hour slowdowns, look for timing patterns and scope

Slowdowns that happen only during busy periods may be related to your local connection, entry route, egress peering or load on the destination platform. Keep a baseline from a quieter time, then repeat the same comparison when the problem occurs. If local services slow down too, focus on your home network and internet connection. If one route is affected, try another path. If the same platform is slow on multiple routes while other services work normally, also consider platform-side restrictions or changes to content delivery.

For video, distinguish buffering from regional availability messages. If playback starts but keeps waiting, check the connection and local bandwidth. If the platform says content isn’t available in your region, check its rules instead of repeatedly refreshing at higher quality. For calls, note whether audio, video and screen sharing are all affected, and avoid transferring large files during the test. Switching routes may interrupt a meeting, so save your work and make the change at a suitable time.

Upgrading your plan to meet traffic needs isn’t a guaranteed fix for a route problem. Check the Plans page for prices, traffic and reset details; identify the bottleneck before deciding whether to change plans.

If the issue follows a consistent time pattern, include your local network, route name, destination service and approximate time when submitting a ticket, along with results from tests under the same conditions. Don’t combine screenshots from different servers, networks and devices into one conclusion. Support needs a reproducible path and symptom, not a pile of speed-test images taken under different conditions. This information also helps determine whether to try another route or check your local device.

Frequent disconnects and background drops: check session changes

First check whether the tunnel disconnected or the app session expired

A website asking you to sign in again doesn’t necessarily mean the client disconnected; a paused video may simply be due to a failed app request. When the issue occurs, check the client status, system network icon and other apps. If the client remains connected and only the affected app loses its session, check the app, platform security checks or changes to your egress location first. If the client also disconnects, investigate local network changes, system sleep and background restrictions. A timeline of symptoms is more useful than saying it “keeps dropping.”

Note whether the issue happens after locking the screen, switching apps, putting the device to sleep or moving out of Wi-Fi range. When a device switches from Wi-Fi to mobile data, the original connection path may change and the client may need to reconnect. Even after the network is back, an app may retain an old session, so the client reconnecting doesn’t always restore the app at the same time. Confirm the network is available, then reopen the affected app; don’t clear its data.

On mobile, check system background restrictions first

Android battery and background management varies by device settings. Check whether the system restricts the client’s background activity, background data or battery use, and allow background operation using the options available on your device. Setting names vary, so look for the corresponding feature rather than copying screenshots from another model. Some devices also stop apps when clearing recent tasks. While testing, avoid task-cleaner features and see whether the same log entries appear before and after locking the screen.

On iOS, check that the system VPN configuration matches the current client, and whether another network tool is managing the connection. Don’t keep adding duplicate configurations or remove managed settings if you’re unsure what they do. Organization-managed devices may be subject to shared policies. If background issues occur, note whether the app works in the foreground, when the issue starts after locking the screen, and whether it recovers after unlocking. That’s more specific than saying “background mode is unstable.”

On desktop, check sleep, roaming and conflicting tools

After Windows, macOS or Linux resumes from sleep, network interfaces may initialize again while the client retains its previous connection status. First confirm the system is online, then disconnect and reconnect the client normally. If the issue recurs after every wake, keep the logs from before and after resuming instead of reinstalling the software each time. Roaming between Wi-Fi access points can also cause brief interruptions, so check for changes to your local network.

1. Test without switching networks or putting the device to sleep, and see whether it still disconnects.
2. Keep the same route and compare foreground use with the screen locked to narrow down background restrictions.
3. Retry after closing other network management tools and check for configuration conflicts.
4. Try another route and record the result to distinguish a route-specific issue from a device-wide one.

If the connection drops without any action, check logs for clues such as lost permissions, a network interface being disabled, a connection being rebuilt or a configuration update. Subscription auto-updates, system network changes and app crashes each need a different response. Note whether the client fully exited, whether the system displayed a crash message and whether reconnecting restores service. Don’t infer device restrictions or intentional interruption from the time between disconnects alone.

VPNFile allows unlimited devices online at the same time. Frequent disconnects don’t automatically mean you’ve reached a device limit; first check network changes, background permissions and client conflicts.

If you still can’t access the internet after closing the client, the system proxy or network management settings may not have been restored. Use the client’s normal disconnect, exit or network restore feature first, then check the system proxy. Don’t delete virtual adapters. On a work device, check your organization’s requirements before changing network settings. If the issue persists, attach a redacted screenshot of your current proxy settings to a support ticket and say whether the device slept or switched networks before the problem began. This helps support suggest the right next step.

Subscription update failures and device warnings: check your account status

Check subscription retrieval, parsing and connection separately

Subscription updates have several stages: the client retrieves the subscription, parses it into route configurations, and then connects. If the download fails, check the retrieval path and access status. If the download succeeds but parsing fails, check the import method and compatibility. If the routes appear but won’t connect, return to the connection section. Don’t lump all of these issues together as “a broken subscription,” and don’t delete your existing configuration; it may contain useful clues.

First sign in to the user dashboard overview and check your account, subscription status and traffic. Being able to open the dashboard doesn’t prove that the imported subscription belongs to that account. If you’ve used more than one account, verify the source, but don’t share the full subscription link in a chat group. Subscription links can grant access, so protect them like account credentials. Hide the full link, QR code and its parameters in screenshots.

Keep the existing configuration when troubleshooting update errors

If the client reports a retrieval timeout, first confirm that your local network is working, then check whether the update request relies on a proxy path that’s no longer available. Some clients let you choose whether to retrieve the subscription through the current connection or directly; check the dashboard and client documentation for details. Don’t change several download settings at once. Change one condition at a time and note whether the timeout changes to another error. A different error may mean the failure has moved to another stage; it doesn’t necessarily mean the problem is worse.

If the client says the format isn’t supported, return to the dashboard and choose an import method that matches your client. Don’t import a webpage, sign-in page or subscription management page as subscription content, and don’t manually add unknown parameters. Keep the existing configuration and create a separate one for testing. If the new configuration works, the old one may contain local changes or leftover entries. Once the new one is confirmed, use the client’s controls to tidy up the old configuration.

Use the dashboard to check traffic and billing status

Monthly subscription traffic resets each month on the activation date; don’t calculate the reset based on the start of the calendar month. When you upgrade partway through a billing period, the price difference is prorated by the remaining days; check the dashboard for your account’s exact result. Traffic bundles remain available until used and never expire, but that doesn’t mean you can keep using the service after the traffic is exhausted. If the remaining balance differs from what you expected, first check your account history and billing type before contacting support. Don’t make another payment just to try to restore service.

VPNFile monthly plans: ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Traffic bundles: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. See Plans & Traffic Bundles for details. These prices help identify your billing type; switching plans isn’t a fix for an import error. If your payment is complete but the status doesn’t look right, keep the order details and ask support to check.

There’s no device limit for simultaneous connections. If your client says “device limit exceeded,” take a screenshot and check where the message came from. It may refer to another configuration, service or client feature; it doesn’t prove that VPNFile has a device limit.

When checking a device warning, first confirm that the current configuration is from VPNFile and that you haven’t selected another subscription by mistake. Different apps may use different wording for sign-in authorization, account sessions and network connections; an app’s own sign-in limit is not the same as a subscription device limit. Don’t send personal information about all your devices in response to the warning. The app name, exact message and action that triggered it are enough for support to identify the type of issue.

If the dashboard can’t retrieve the subscription, the matching import method keeps failing, or your order and subscription statuses don’t match, submit a support ticket. Include a redacted order reference, client platform, error from the retrieval or parsing stage, and the result of testing a new configuration. You can create an account with a username and password; no email address is required. Keep your username and password secure—support doesn’t need your password to understand the issue.

Can’t access a specific app? Check routing and platform rules

A working browser doesn’t mean every app takes the same route

The system proxy usually affects only apps that follow that setting. Some programs have their own proxy options; others may need a tunnel method supported by the client to route their traffic. If your browser works but an app doesn’t, first check whether the client logged a request from that app. If no request appears, check the app’s own proxy and how the system is routing traffic. If a request does appear, check the matching rule, selected egress and error instead of repeatedly switching routes.

First identify the action that fails: launch, sign-in, loading a list, sending content or downloading an attachment. Different features in the same app may use different domains, so a successful sign-in doesn’t mean later requests use the same rule. Once you’ve noted the action, look for the matching request in the client’s connection log, if available. Don’t route every unfamiliar domain through the proxy or delete default rules; you could disrupt other apps that work normally.

Use temporary mode changes to diagnose, not as a permanent configuration

If your client offers rule-based and global modes, you can compare them temporarily once you understand what each one does. If switching to global mode restores access, that usually means you should investigate the routing rules further—but it isn’t a definitive diagnosis, as the app may have rebuilt its session during the switch. After testing, restore the mode you normally use and fix the issue with a specific rule. Check the client documentation for the meaning and scope of each mode.

Even global mode may not route every program: an app could bypass the system proxy or be limited by system permissions. If the app has its own proxy settings, check that they match the client’s local listener. Don’t enter an outdated port or a leftover address. Never copy local settings from someone else’s screenshot or use a local proxy listener address as a subscription link. If you’re unsure about a setting, save its current value and ask support to review your actual screen.

AI and streaming services also follow their own platform requirements

Services such as ChatGPT, Claude and Gemini apply their own rules for region, account eligibility and access risk. A working network connection doesn’t guarantee that a platform will allow sign-in or use. If you see a regional message, check the platform’s current supported regions and your selected region. If it’s an account verification, usage limit or eligibility message, follow the platform’s process. VPNFile route selection can’t replace account authorization from a third-party platform and shouldn’t be treated as a way to avoid its terms of use.

For services such as Claude that are sensitive to the access environment, keep your usage environment reasonably consistent and avoid repeatedly switching regions and signing in during troubleshooting. First check whether the network can reach the service, then determine whether the platform is denying access. See Claude regional checks and route selection for more context, or visit the AI Tools guide for an overview of AI access. These suggestions help narrow down the issue; they don’t guarantee platform availability.

Content available on streaming services such as Netflix and Disney+ may also depend on account region, licensing and device environment. If the site opens but a title won’t play, note the platform error code and title, then distinguish a playback connection failure from a content licensing restriction. A region name isn’t a promise that every title will be available. For more guidance, see Streaming support; for Japan-region services, see Japan routes and streaming platforms.

When reporting an app issue, include the service, failed action, routing mode and egress region. Remove conversation contents, private file names and URL parameters that reveal your sign-in status. Don’t send your full browsing history.

If only a work app is affected, check whether your organization requires a specific corporate network or compliant device configuration. Personal network acceleration can’t replace enterprise access authorization. If the problem began after an app update, describe what changed without guessing that the update introduced a defect. Support can help check the request path and route; account bans, platform eligibility and organization access permissions need to be handled by the relevant platform or administrator.

Platform checks: use system information to verify your findings

Check the status first; use diagnostic commands only if needed

Command-line tools can provide additional evidence, but they aren’t required to use the service. Start by checking your network, proxy and permissions in system settings and the client. If the issue is still unclear, collect DNS and request results. The commands below test basic behavior against an example domain and don’t include a subscription address. They’re for observing status, not fixing routes. A successful result doesn’t prove every app uses the same path or that a third-party account is eligible for access.

Basic checks on Windows and macOS

On Windows, first check that the system proxy matches the client’s current status, then use PowerShell to inspect DNS resolution and web responses. The request below retrieves only response headers. If the site responds, that means this command’s access path got a response; interpret the status code in context. Whether a command-line tool follows the system proxy depends on the tool and your local settings, so compare its results with the browser and client logs.

Resolve-DnsName example.com
curl.exe -I https://example.com

On macOS, check the current proxy and DNS settings, then test a response from an example domain. The output may contain internal network details, so remove unrelated addresses and search domains before sharing it. Don’t delete multiple network services or DNS entries; they may belong to Wi-Fi, Ethernet, an organization network or the current client. If you’re unsure about permissions or importing a subscription, see the macOS setup guide for beginners and follow the steps on screen.

scutil --proxy
scutil --dns
curl -I https://example.com

Linux and mobile platforms have different limitations

On Linux, desktop proxy settings and terminal environment variables may differ, so a working browser and a failing terminal don’t necessarily indicate a route issue. Check DNS and request results, and see whether any relevant proxy variables still point to an old configuration. On systems using systemd-resolved, you can check its status, but not every distribution includes the same tools. If a command isn’t available, note the message; don’t install unfamiliar system services just to troubleshoot.

getent hosts example.com
curl -I https://example.com

Terminal variables may contain authentication details, so don’t paste them publicly in full. Take extra care when managing a remote device: don’t reset the router, flush all network rules or stop network services, as that could interrupt the management connection you’re using. If the device is doing other work, save your tasks and ask someone familiar with the system to confirm what’s safe to change. Gathering observations is usually more useful than running a network reset script blindly.

On iOS and Android, start with system settings, client connection logs and app errors; there’s no need to install extra tools just to diagnose the issue. After checking VPN permissions, background activity and network switching, compare the same website in the foreground and after unlocking the screen. Download clients from the user dashboard download area, then sign in to get your subscription. Follow the dashboard’s instructions for iOS and avoid unverified installation sources.

Diagnostic output reflects the path taken when the command ran. DNS resolution, a website response and app access are different results; record them separately instead of treating any one as a complete diagnosis.

If tool results disagree with the client interface, note whether the client was connected, which mode it was using and the terminal environment where you ran the command. For unfamiliar terms, see the subscription, node and routing glossary. For a support ticket, include the key error lines and enough surrounding context; you don’t need to upload a full system report. This makes the issue easier to review and avoids exposing unrelated information.

When to contact support: prepare your ticket and recovery notes

The goal of self-checks is to narrow down the cause, not to try everything indefinitely

Submit a ticket when your local network is confirmed to be working, you’ve checked your subscription, and updating or switching routes hasn’t helped—or when you can reliably reproduce the issue. Contact support promptly for payment and account status mismatches, subscriptions that can’t be retrieved or persistent permission errors. You don’t have to change every system setting before asking for help. A clear account of what you’ve already compared is often more useful than trying still more things.

If the issue affects work in progress, save your files and drafts before switching routes or restarting apps. You can keep a working backup path available, but don’t delete original records while support is investigating. Keep the conversation in one ticket where possible, and add the time and conditions whenever something changes. This avoids splitting details across multiple tickets and helps support see the full sequence rather than conflicting fragments.

Share reproducible facts while keeping credentials secure

Include your platform and system, client name, network type, route name, failed action and exact error message. If the version is visible in the app, report it as shown; if you can’t confirm it, say so rather than guessing. Include the time and your time zone so support can compare logs. If it worked before, say roughly what changed before the issue began, such as switching networks, a system update, waking the device or reimporting the subscription.

Issue: The client shows Connected, but the target app won’t load
Device platform: Enter the platform you’re using
System and client: Enter the details shown in the app
Local network: Enter your current network type
Time and time zone: Enter the actual time and zone
Selected route: Enter the name shown in the client
Failed action: Say what you clicked or did and where it failed
Exact error: Include the complete error message
Checks completed: Note the results of changing routes, networks and modes
Attachments: Redacted screenshots and relevant log excerpts

Screenshots should retain the error context while hiding unnecessary personal information, the full subscription link, QR codes, authentication fields and private content. Logs may contain destination URLs and network addresses; review them before uploading. Never send your account password, and don’t share sensitive verification or payment details with unrelated people. For order issues, support usually needs the relevant order reference, status and a redacted payment result—not your complete account information.

Know which issues support can handle

VPNFile support can help check subscriptions, client connectivity and route behavior. Your local router, organization device policies and third-party platform accounts may need attention from the relevant administrator or platform. For example, switching regions can’t replace corporate identity verification required by a work app, and updating a subscription won’t fix a website message saying your account isn’t eligible. Separating network issues from account issues helps get the problem to the right people.

If the issue is limited to one route, provide its name and your comparison results. If it occurs only on one local network, say whether other networks work. If it happens only in the background, note how it relates to locking and waking the device. If only one app is affected, include results from the browser and other apps. These comparisons are useful even without technical logs. If you can’t complete a check, just say so; don’t risk changing system settings to fill in every detail.

Submit a ticket through the user dashboard. VPNFile offers a 60-day refund policy; see the Terms of Service for details. Check refund and troubleshooting status through the dashboard, and don’t make duplicate payments to unfamiliar recipients.

Verify the fix, then tidy up your configuration

Once the issue is resolved, don’t stop at seeing the connection icon return to normal. Repeat the action that originally failed, then check your usual websites, target app and any necessary background use to confirm the service meets your needs. Restore temporary global mode, test rules or browser settings to your usual setup. If a change did fix the problem, note what you changed and why, so you have a reference next time instead of trying things at random.

Finally, remove duplicate configurations and test screenshots, keep a useful summary of the issue, and store your subscription information securely. If the same issue happens again, add whether it recurred on the same route, network and time of day to your existing notes. If the issue hasn’t been diagnosed but service is working again for now, describe it as “temporarily resolved” rather than claiming the cause is known. These notes help support track the issue and let you start the next round of troubleshooting with the facts already in hand.