VPN Troubleshooting Guide

First, tell a network outage from a connection failure

“Can't connect at all” could mean the client won't open, the server list is empty, or the connection hangs after you tap Connect. Each calls for a different fix. Note which screen you're stuck on, the exact error, and when it happened. Don't clear the client's data yet. Disconnect from the acceleration service, then use a browser to visit a site that normally works. If the internet itself is down, check whether Wi-Fi requires a sign-in page, whether the router is working, and whether your device is offline. Changing servers won't help until the basic connection is back.

On hotel, campus, or public Wi-Fi, your device may be connected to the network but still need to complete its sign-in process. Open the system's network sign-in prompt and complete the network's usual authentication before connecting. Never enter your VPNHey password on an unfamiliar sign-in page. If an old proxy setting is interfering with your browser, quit the proxy client and check whether the system proxy still points to a local address. Record the original setting before changing it so you can restore it later.

Check your account status and subscription

Open the dashboard overview and check your current plan status, available data, and whether the subscription in your client matches. Being able to sign in to the dashboard only confirms that your account is accessible; it doesn't confirm that your connection is authorized. Monthly subscription data resets each month on your activation date, not at the start of the calendar month. Data add-ons never expire, but they can't be used after the included data runs out.

If the server list is empty, go to the subscription update section instead of repeatedly tapping Connect. If servers appear but all show authentication errors, check whether you're using an old subscription, imported a configuration from another account, or have a significantly incorrect system date or time zone. A clock that's off can affect certificate checks. Don't disable certificate validation to force a connection: that hides the real issue and makes it harder to diagnose.

Check permissions, conflicts, and handshake logs

The first time a client creates a system network tunnel, your operating system will usually ask for permission. If you denied it, check the system settings or the prompt in the client again. A system proxy, virtual network adapter, and in-app proxy are different connection methods; enabling one doesn't mean the others are active. Other proxy tools, security software's network filters, or organization-managed policies can also interfere. Only pause features you're authorized to manage, and note how to restore them. Don't remove management settings from a work device.

Keep the other settings unchanged, switch to another server in the list, and note whether the error is the same. If only one server fails, the issue may be with that server or the route to it. If every server fails at the same step, check local permissions, subscription authorization, and your current network. If possible, test on another available network. A connection working after a network switch is useful diagnostic evidence, but it doesn't prove the original network has a permanent restriction.

Change one thing at a time. If you switch networks, change configurations, and reinstall the client all at once, you may get connected without knowing why. If the issue returns, you'll have to start troubleshooting again.

A “timeout” in the logs means no expected response arrived in time; by itself, it doesn't prove the server is unavailable. “Connection refused” and “authentication failed” are different errors and should be handled separately. Keep the relevant logs from the time of the failure; there's no need to enable detailed logging for an extended period. Before submitting, check for subscription links, credentials, or complete request data. If the same subscription can't complete a handshake across different networks and supported devices while the dashboard shows a normal status, submit the comparison in a support ticket so customer service can check authorization or server status.

Once connected, reopen the website you're troubleshooting and check that the app works too. A “connected” message in the client is only the first check, not the final one. For ways to verify your IP and apps, see How to check whether your VPN is working. For your first import, return to the Getting Started Guide so you don't mistake a missed setup step for a server issue.

Check whether all websites fail or just one

If the client says you're connected but websites won't load, test a familiar site and the specific site you need. If only one site fails, note the browser error: DNS lookup failure, connection timeout, certificate warning, or an access-denied page. An access-denied page means the request reached a server that returned a response; restarting the tunnel may not help. If no websites load, check whether the system still points to a local proxy that has been closed and whether the client is actually handling browser traffic.

Try an incognito window to reduce interference from extensions, cached data, and old sign-in sessions. This won't rule out system proxy or network issues. If incognito works, check extensions and site data one at a time in your regular window instead of immediately clearing all browsing history. If the name on a certificate warning doesn't match the site's domain, stop entering sensitive information. Check the device clock, network sign-in page, and any organization certificate policies; don't automatically click through the warning.

DNS results and actual requests aren't the same thing

DNS translates domain names into network addresses. The system resolver, a browser's Secure DNS, and a client's built-in resolver may use different paths. A successful command-line lookup doesn't mean the browser used the same result, and a failed lookup doesn't prove the tunnel is down. First note which layers have custom DNS enabled, then follow the client documentation to use a consistent configuration. Don't stack random DNS addresses you found online; overlapping settings make issues harder to reproduce.

Use the command below to check how your system resolves an example domain. Windows typically includes nslookup; availability on other systems depends on your environment. This basic lookup doesn't change settings. To troubleshoot a specific site, replace the example with its domain—don't include the protocol, path, or sign-in parameters. The resolver address and results only describe this lookup; they don't prove how all traffic from your device is routed.

nslookup example.com

If the system lookup fails but the client log shows successful internal DNS resolution, check whether the browser or app is bypassing the client. If the system lookup works but the client's internal lookup fails, check its DNS rules and whether the upstream resolver is reachable. Some tunnel configurations return mapped addresses that the relevant client must handle. Don't add these addresses to the system's static hosts file or assume from their appearance that DNS has been tampered with.

Use request results to narrow it down further

On a device with curl, run the request below and check for response headers or a connection error. Whether the request uses a proxy depends on your system and connection mode. If only the system proxy is enabled, terminal tools may not automatically use the browser's settings. Check the client's connection log too to confirm whether it handled the request. An access-denied response may mean the site doesn't accept that type of request; it doesn't necessarily mean the network is down.

curl -I https://example.com

Save the original settings before changing DNS. Afterward, reconnect and close any existing connection in the affected app. Existing connections may keep using the old address, so refreshing the page may not be enough. If the issue persists, submit the DNS and request errors along with when they occurred instead of simply saying “the page is blank.” Don't upload your full browsing history for diagnosis; the domain and minimal steps to reproduce the issue are usually more useful.

Contact dashboard support if multiple domains show the same DNS error on different networks, or if a configuration update consistently reproduces a resolution failure. If just one service denies access, check that service's status and account rules too. A server can change your network exit point, but it can't control an external platform's account permissions, content licensing, or service availability.

Pinpoint which part feels slow

A slow page load, video buffering, a slow download, and sluggish interactive apps aren't the same problem. Page load time depends on DNS, connection setup, and the site's server. Large downloads are more likely to reveal sustained throughput limits, while calls and games are more sensitive to latency changes and packet loss. Describing what you were doing in a support ticket is more useful than sending only a speed-test screenshot. A result from one testing site doesn't represent how every website will perform.

First, check whether the internet is slow with the acceleration service disconnected. Weak Wi-Fi, router congestion, or file syncing on other devices can make your local connection the bottleneck. If possible, compare with a wired connection; otherwise, move closer to the router and pause large transfers you control. Keep the destination, device, and test method the same so you can identify what changed.

Choose a server by more than geographic distance

The server entry point, international route, and distance from the exit to the destination all affect performance. A geographically closer location isn't necessarily faster for every destination, and a displayed ping doesn't reflect the full time an app request takes. VPNHey covers 110+ countries / 170+ routes. Choose based on your destination and current network rather than assuming a location will always perform a certain way. Check the dashboard for available locations and routes; see the Servers and routes page for details.

For a comparison, select your current server, then another available server in the list. Repeat the same task and note the time. Don't also change the video quality, browser, or download source. If just one download source is slow, it may be throttling downloads or the route to it may be the issue. If several destinations are slow, check device load and your local connection. Cloud backups running in the background also compete for bandwidth and can make test results inconsistent.

These are common meanings, not a promise that every location offers every type or a way to infer bandwidth. Check the labels in the dashboard and the service information for specifics. If performance to the same destination differs by route type, note the server names and times. That comparison helps support investigate the route more than a general claim that “the dedicated line is slow.”

Check apps, devices, and transfer methods

Your device's processing capacity can also limit data transfer. Check CPU usage, memory pressure, and whether power-saving mode is enabled, especially when many connections or background sync tasks are running. Pause unrelated tasks and try again before changing advanced protocol settings. If the device is unusually hot, system performance throttling may be the cause; check that separately from server congestion.

For video buffering, check the player's buffer, the platform's content delivery route, and the current playback quality. After switching exits, an existing playback session may keep using the old media address. Reopen the video before comparing. If a specific title or regional catalog won't play, licensing may be the issue; lowering the quality won't fix that. Don't present streaming access as a guarantee for every platform or title.

If small web requests work but large transfers—or certain connections—keep stalling, it may be worth checking technical factors such as path MTU, transport method, or connection reuse. Adjust these only according to the client documentation or customer support guidance; don't copy unfamiliar settings. A bad setting can affect other apps too. In a support ticket, describing “small requests work, large transfers stall” is more useful than just saying “it's too slow.”

Judge performance by whether your actual task completes reliably; speed tests are only a guide. For the difference between latency and packet loss in interactive apps, read Latency and packet loss in gaming. If data usage is a key factor in choosing a plan, compare the plan details rather than assuming an upgrade will fix every network bottleneck.

Tell lag, failed requests, and tunnel reconnects apart

A frozen video doesn't necessarily mean the client disconnected. Check the client's connection log for a new handshake, whether the system network icon changed, and whether other apps failed too. If only the video pauses while websites work, check the media source and playback session first. If every app briefly loses access and the log shows the tunnel reconnecting, investigate network changes, device sleep, or the server connection. Don't diagnose the scope of an issue from the status icon color alone.

Peak time tells you when the issue happens, not why. Other people streaming at home, Wi-Fi interference, congestion on your local carrier network, or a busy international route can all cause lag at the same time of day. Note the start and end time, network, server, and app. If the same pattern occurs on different days, these records can help distinguish an isolated incident from reproducible conditions.

Keep a useful record for comparison

Use the same device, network, and destination to compare the problem period with a normal period. First check whether your basic internet connection is affected, then try another available server. If changing servers helps while the local connection stays the same, the route difference is worth investigating; it doesn't prove that one route type is always more reliable. See How to test connection reliability and disconnects for more ways to compare.

Running lots of speed tests isn't a good way to simulate everyday use. The tests use bandwidth and may add load to your router. It's more useful to note whether your actual task completed, whether the tunnel reconnected, and whether only one destination was affected. If you need a screenshot, include the current server and error, not account details, the full subscription, or your entire desktop.

Comparing different servers at the same time and for the same destination helps check route differences. Comparing the same server across different networks helps check the local connection. Don't mix the two comparisons when drawing conclusions.

Check local causes of frequent reconnects

If disconnects happen after closing your laptop, locking the screen, moving out of Wi-Fi range, or switching networks, check system power and network-switching settings first. When a device sleeps, app connections may pause. After it wakes, the client may still show its old state even if the connection hasn't recovered. Reopen the app and make a new request; that's more reliable than checking the connection icon from before sleep. See the mobile background section for related settings.

If the device stays awake and the network doesn't change, check whether another network tool is periodically changing the system proxy or virtual network routes. Multiple clients may leave background services running even when only one interface shows a connection. Quit them one at a time using their normal exit options, then reconnect. Don't delete network adapters or system networking components; that can have a broad impact and destroy useful diagnostic evidence.

A router reconnect, Wi-Fi roaming, or a change in your network address can also interrupt existing sessions. Check whether the system reconnects just before the disconnect and whether other devices are affected too. If every device briefly loses internet access, troubleshoot the local network first. If only one server keeps disconnecting, save its logs and use another available server to finish your task. That's a temporary workaround, not a replacement for reporting the issue.

When to ask customer support for help

Submit a support ticket if the issue persists while the device is awake and the basic connection is stable, and it affects multiple destinations. Note whether it happens only at peak times, whether other servers work, whether another network behaves the same way, and the last error before the reconnect in the logs. Support needs a reproducible scenario with a start and end time, not a full day's logs without timestamps.

Keep your original notes after service is restored, then test again under similar conditions. An occasional success doesn't prove the cause is gone, and an occasional failure doesn't establish long-term performance. VPNHey offers a 30-day no-questions-asked refund. For billing matters, follow the Terms of Service and the dashboard process. Diagnostic records help narrow down the issue; they aren't a basis for unlimited guarantees about connection quality.

Updating a subscription and connecting to a server are separate requests

A subscription provides the configuration a client needs. An update can fail while fetching the URL, downloading the content, or parsing the configuration. A connection failure occurs later, when the client uses that configuration to connect. Your existing configuration may still connect while an update is temporarily failing; an update may also succeed while authorization prevents you from using a server. Record update and connection errors separately. “Update complete” doesn't confirm that your plan or connection is active.

First, check your account and plan in the dashboard, then get the subscription link for your current client from there. Don't rely on an old chat message or browser bookmark as your only source. If the client type doesn't match, it may not be able to parse the downloaded content. If you're unsure how to import it, follow the Getting Started Guide and the dashboard's download and subscription instructions. There's no need to look for public configurations.

Fix the error type instead of repeatedly importing

If the error is a network timeout, check whether an old proxy mode is affecting the update request. Some clients fetch subscriptions through the current connection; if that connection is already down, this can create a dependency loop. Check whether the client offers a setting for how update requests connect, then choose an available route as documented. Don't leave system security features disabled just to update a subscription, and don't assume all clients work the same way.

If you see an unauthorized, forbidden, or expired-link error, get a fresh link from the dashboard and check your account and plan status. If the configuration format is invalid, check that you selected the right client type, that a network sign-in page hasn't replaced the content, and that the client supports the format. A successful download only means a response arrived; it doesn't mean the response is a valid configuration. Don't post the raw content to a public forum.

The example address below is fake and only illustrates the format; it's not a VPNHey subscription. Get your actual address from the dashboard. A subscription link may contain access credentials and should be treated like a password. Don't give it to an unfamiliar conversion site, public speed test, or unknown script. Support usually needs the error type and client details, not the full link in a ticket.

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

Protect your existing configuration and check the updated one

Before updating, note your current configuration name, active policy groups, and any manual changes. An update may overwrite local changes or import a new configuration as a separate file. After a successful update, check that the updated configuration is active and that you're not still using the old one. If you need to delete the old configuration, first confirm the new one works and save any settings you need using the client's backup feature.

Avoid combining node snippets from different sources. Fields, rule references, and policy names need to match; configurations that look similar aren't necessarily compatible. For everyday use, prefer the compatible subscription entry in the dashboard. If you maintain custom overrides, disable them temporarily to test the base subscription. If the base configuration works but the override doesn't, check the override logic instead of changing accounts.

If the server list gets shorter or names change after an update, use the current dashboard and service announcements as your reference; an old screenshot doesn't prove something is missing. If the dashboard and client clearly don't match, note the update time, configuration name, and differences for customer support. Don't add unknown server addresses yourself or assume a specific location must always appear just because the service covers a certain number of countries.

Tell subscription issues from data-plan rules

Running out of data, a change in plan status, and a failed configuration download are different issues. Monthly subscription data resets each month on your activation date, and mid-cycle upgrades are prorated based on the remaining days. Data add-ons never expire, but they stop working once used up. See the plans page for details and How to choose between a data add-on and a monthly plan for a comparison. Repeated imports won't restore used data.

Submit a support ticket if the dashboard is accessible, the link is from your current account, your basic connection works, but the compatible subscription entry keeps returning the same error. Include your client, operating system, how you fetched the subscription, the exact error, and whether you use custom overrides. If you suspect a subscription link has been exposed, use the management options in the dashboard. If you can't find them, contact dashboard support; don't repost the link publicly to see if it still works.

A working browser doesn't mean every app is using the connection

System proxy settings are used only by apps that read them; they don't automatically cover every network request. Some apps use their own network stack, a built-in proxy, or direct connections, so a working browser and a failing app can make sense. First, check whether the client uses a system proxy or a system network tunnel, then see if the app has its own network settings. Don't enable multiple connection methods and stop troubleshooting as soon as one works. Identify which route the request actually takes.

A virtual network adapter or system tunnel can usually handle more traffic, but is still subject to system permissions, route exclusions, organization policies, and client capabilities. Read the current client documentation before enabling it, then grant permission and reconnect. If your work device is organization-managed, confirm what's allowed instead of removing management policies. After changing modes, fully quit and reopen the app so existing connections don't keep using the old route.

Check the client's connection log

If your client supports connection logs, open them and use only the app that's having trouble. Check for its process or destination domain, the matched rule, and the selected policy group. If nothing appears, the app may not be routed through the client—or the current log view may not show that type of request. A blank log alone doesn't settle the question. Test a browser request that you know works to confirm the logs are capturing traffic.

If the request appears but is set to direct, check which rule matched before adding a broad rule. An app may contact separate domains for sign-in, content, resources, and updates; routing only its main domain may not be enough. Start with app categories already provided by the client and subscription. If you need to change a rule, note its original settings and scope. When routing by process, remember that background helper processes may differ from the main app process.

Get the in-app proxy address and port from your current client; don't copy examples from the web. The proxy type must match too—choosing the wrong protocol can cause an immediate disconnect. If the app doesn't support the type you need, use another connection method documented by the app. Don't expose a local proxy listener to more of your network than necessary. For local use, widening its listening scope isn't a general fix for speed or connectivity problems.

Distinguish a failed connection from a service denial

AI tools, streaming services, and work apps may decide whether to provide access based on account status, exit region, content licensing, or their own risk controls. If the client logs the proxy request but the app returns a specific account or region message, save the exact text and check the platform's rules. Changing servers may change some network conditions, but it can't change your account eligibility or guarantee that the platform offers every feature from that exit location.

Apps may also cache exit-related status. After switching regions, close the old session and reopen the app. If you need to sign in, follow the platform's normal process. Repeatedly changing regions and retrying sign-in can trigger extra account checks and mix an account issue with a network issue. If the website works in a browser but the desktop app doesn't, compare the domains and network routes each one uses.

Some apps rely on different transport methods or connect to fixed addresses after DNS resolution. If only certain features fail, describe the specific action—for example, sign-in works but voice calls don't—instead of saying the whole app won't open. Check the client and current configuration for supported transport methods; don't enable unknown options at random. After making a change, test both the affected feature and features that already worked so one fix doesn't break other traffic.

If the issue still occurs consistently with the basic configuration, send customer support the app name, failed action, connection mode, matched rule, and a redacted error. Don't share the platform password, sign-in credentials, or full chat content. For an account restriction explicitly reported by the service, check the platform's help resources. If the traffic isn't being routed through the client or a rule is wrong, continue troubleshooting the client and subscription.

First, reproduce the change around screen lock

A mobile background disconnect can mean the system stopped the client process, the system tunnel disconnected, or the target app paused its connection. First, keep the screen on and repeat the same task, then lock the device and check again when you return. Note whether the client is still running, whether the system connection indicator changed, and whether reopening the app restores service. If the client stays connected but only the app stops receiving content, check the app's background policy before blaming the server.

Power-saving mode, background activity limits, and automatic cleanup can all change how apps run. Check whether the system allows the client to perform required background activity and whether a battery restriction is enabled for it. Setting names vary by device and operating system; follow the descriptions in your current interface, not screenshots from another device. Change only settings relevant to the issue and note their original values. Don't permanently relax background restrictions for every app just to troubleshoot.

What to check on Android and iOS

On Android, start with the app's battery settings, background permissions, and system network tunnel settings. Some devices also have manufacturer-specific auto-start or background cleanup controls; check the options on your device. Keeping an app card in the recent apps list doesn't guarantee the system won't stop it, and closing the screen doesn't necessarily stop the tunnel. Use system settings and client logs rather than guessing from the recent apps list.

On iOS, check the VPN configuration in system settings, which connection is enabled, and whether another network extension may conflict. Don't delete work configurations you don't recognize. After a network change or system recovery, an old app session may not reconnect immediately; make a new request before judging. If the system doesn't offer a background control, don't install an unknown configuration profile as a substitute. That adds more variables you can't control.

Network changes can interrupt existing sessions

When you switch from Wi-Fi to mobile data, or move between Wi-Fi access points, your device's network address and default route may change. Existing connections might not be able to use the old route, so the client and apps may each need to reconnect. First verify that the connection works on a fixed network, then compare after switching networks. If it's stable on the fixed network but fails after moving, note the network types before and after the switch and how you restored service. There's no need to change the subscription first.

System options such as always-on, auto-connect, or block connections without VPN can affect how a disconnect appears. With a blocking option enabled, other requests may fail while the tunnel is reconnecting; that doesn't necessarily mean the basic internet connection is broken. Read the option description and distinguish “requests are blocked for protection” from “the client can't connect.” Don't repeatedly toggle settings if you're unsure what they do. If you temporarily change one, note its original state and restore it after troubleshooting.

The same checks apply after desktop sleep

Windows, macOS, and Linux may also keep old sessions after sleep, waking, or changing networks. First check whether the client background process has recovered, then verify the system proxy or tunnel is still working. On Linux, if the client runs as a system service, follow the service management instructions for your installation method instead of guessing the service name and stopping it. A visible desktop icon and a healthy background service are separate things; check both.

Download the client from the dashboard download page. Sign in to get your subscription. On platforms other than iOS, signing in is enough to download the client; on iOS, you also need an active plan to access the download. Don't use installers from unfamiliar sources instead of troubleshooting background settings, and don't modify system components based on another brand's guide. Before reinstalling, make sure you can retrieve your subscription again and save any local settings you need.

If the issue happens consistently only in the background and you've checked the system settings, tell customer support your device platform, system version, client details, whether the screen was locked or the network changed, and what you saw after returning. Include only relevant log excerpts, not notifications from other apps. If your system doesn't allow an app to run in the background long-term, work within that limitation instead of treating an uncontrollable condition as a guarantee of continuous connectivity.

First, identify the source of a device limit alert

VPNHey allows unlimited simultaneous devices. If you see a device limit alert, don't assume that VPNHey requires you to remove devices or upgrade your plan. First check whether the message is from the VPNHey dashboard, your current client, or the platform you're trying to access. The client may still have another subscription configured, and the destination service may have its own session rules. Record the exact message and where it appears before deciding what to do.

Check that the active configuration matches your account, and make sure you haven't selected a different configuration file, work account, or old subscription by mistake. If the alert appears in an interface related to this service, submit a support ticket for a check; don't create multiple accounts or pay again to try to fix it. No email address is required: create an account with a username and password. Keep your account details secure; no diagnostic process requires you to display your password publicly.

Unlimited devices describes the simultaneous connection policy, not unlimited processing power on your devices or a lack of session limits on other platforms. When several apps transfer data at once, they still share your local bandwidth and router resources. If all devices slow down when used together, return to the speed section and check the local connection. If only one service shows a device-limit message, check that platform's account rules.

Write a support ticket that others can reproduce

Before submitting, organize what worked, what failed, and what comparisons you've already tried. Start with a short description of the expected and actual results, then list the steps and where the error appears. For example: “The dashboard opens and the subscription update succeeds, but connecting to one server times out; the same error occurs on another network.” That's more useful than “it doesn't work.” There's no need to attach unrelated logs just to make the ticket look detailed. The goal is to give support a path they can follow.

Include the time and time zone, especially for intermittent or peak-time issues. Use the server name shown in the current dashboard and specify the app and platform. Read the client version from your own interface rather than substituting another user's version. If the issue is hard to reproduce, describe the last known conditions and whether reconnecting, switching networks, or waking the device restored service.

Redact sensitive details instead of uploading everything

Logs and screenshots may contain usernames, subscription credentials, URLs, filenames, or other personal information. Before submitting, hide passwords, full subscription links, authentication fields, and anything unrelated. Make sure a screenshot doesn't expose a configuration URL in the address bar, and don't paste complete requests from browser developer tools into a ticket. If support needs more information, provide only the necessary details through the dashboard ticket and for the stated purpose.

This page doesn't list a separate email address or social account for support. Use dashboard support tickets for after-sales help, or start with the Customer Support Guide. Don't trust unfamiliar contact details from search results. For billing questions, state the plan and order status shown in your dashboard; never share your payment account login or full payment credentials.

Compare prices and data rules when choosing a plan. Monthly subscriptions and data add-ons address billing and usage; they aren't a universal fix for authorization, DNS, or app configuration issues. Payment methods include Alipay / WeChat Pay / USDT. The refund policy is a 30-day no-questions-asked refund; follow the Terms of Service and dashboard process. Don't assume there are other discounts or compensation terms when submitting a troubleshooting ticket.

Verify the fix before closing the issue

After receiving troubleshooting steps, try one at a time and record the result. If you're asked to switch configurations, save your original settings first. Then test the connection, destination website, actual app, and background recovery—not just the client's Connect button. If the issue disappears temporarily but the conditions that trigger it haven't occurred again, note in the ticket: “Working for now; original conditions not yet retested.” That avoids treating a temporary improvement as a confirmed fix.

Once everything works again, turn off temporary verbose logging, test rules, and system changes made for comparison, keeping only the settings you need. Note the final working steps for next time. If you still have questions about your first setup, return to the Getting Started Guide; for general rules, see the FAQ. Troubleshooting should narrow down the possibilities so each change has a reason—not lead to repeated reinstalls or payments.