VPN Troubleshooting Guide

Can't connect at all: check the basics

“Can't connect” can mean several different things: the client won't launch, the system won't create a network interface, a route won't connect, or the destination doesn't respond after connection. These are different layers of the problem. Note whether the button works, whether the system asks for permission, and whether the error appears during import or connection. “It doesn't work” is too vague to distinguish an account issue from a route issue, and can lead to repeated changes that have nothing to do with the problem.

Pause the proxy and check your internet connection

Disconnect in the client, then open a website you normally visit without a proxy. If it still won't load, check that your device is online, that the Wi-Fi network doesn't require a sign-in page, and that your router has an internet connection. On public Wi-Fi, complete its sign-in process first. Changing your subscription or exit region won't help until the basic connection between your device and the route is working.

Once basic websites load, check that your device's date, time zone and clock are correct. A significant time mismatch can cause certificate checks to fail, resulting in handshake errors or problems with multiple secure connections. Turn automatic time setting back on rather than disabling certificate checks. If other apps also report certificate errors, treat that as a clue about the system or network environment—not proof that your subscription has expired.

Tell an authorization issue from a route issue

The first time you connect, the system must allow the client to create a proxy or VPN interface. If permission was denied, return to the client and follow its prompt to request it again. Check system network settings for an inactive configuration left behind. Avoid running multiple tools that take over system traffic at once: security software, remote-work clients and other proxies can compete for routes or interfaces. Pause only programs whose purpose you recognize. On a managed device, check with your administrator first.

Next, sign in to the user dashboard to check your plan and remaining traffic, then make sure the client has selected an actual route—not an empty group or an outdated configuration. Being able to sign in to the dashboard doesn't mean the client has the latest subscription. If your account is in good standing but the route list is empty, see the subscription update section. If the list is complete and only one route fails, compare routes instead.

Compare routes and network connections

Keep the same client and mode, select another route from the list, and test the same website. If possible, switch to a different network while keeping everything else unchanged. If just one route fails, note its name. If every route fails on one network but works on another, the local network path is more likely the issue. Don't change DNS, rules and protocols at the same time; the results would be hard to interpret.

Route type can be useful for comparison, but the name alone doesn't guarantee a result. IEPL dedicated lines, relay routes and direct connections take different paths; performance also depends on your network and the destination. See global nodes and route types for more context, and don't judge by distance alone. If your client offers automatic selection, temporarily pin a route manually while troubleshooting so automatic switching doesn't skew the results.

When to stop changing local settings

If system permission is granted, your internet connection and account are working, but no route connects across different networks, keep your current configuration and submit a support ticket. Include your operating system, client name, when it happened, which stage failed and the results of your comparisons. Don't layer on fixes from unknown sources or delete every network adapter. A clear, reproducible state is more useful for diagnosis than a problem that disappeared after many unrelated changes.

Connected but can't load websites: trace the path

A connected status in the client usually means an interface was created or one part of the connection completed. Browsing also depends on domain name resolution, traffic rules, a connection to the destination and app-level checks. A failure at any layer can look like a blank page, endless loading or a timeout. First work out whether all websites fail, only some domains fail, or only features that require sign-in fail. Then follow the relevant steps; reinstalling the client needn't be the first move.

First, narrow down what's affected

Compare a website you normally access directly with one that requires a proxy, ideally in the same browser. If the first works and the second doesn't, check whether its traffic matches a proxy rule. If neither works, check whether the system proxy points to a client that's no longer running and whether traffic capture mode is working. After you exit the client, a leftover system proxy setting may still send browser requests to a local address where nothing is listening.

If just one site fails, try a browser window without the site's existing sign-in session. A private window can help isolate cache and extension issues, but it doesn't prove that browsing is anonymous or change your exit route. If the site works there, check browser extensions, site cache and the old session first. Save anything you need before clearing data. Don't erase data for every site just to troubleshoot one domain.

Check where the request is going

Search the client's connection log for the destination domain. Check whether the request was sent directly or through a proxy, and which route was selected. If the request doesn't appear, the browser may have its own proxy settings, the app may bypass the system proxy, or client logging may be disabled. A missing log entry is only a clue, not proof that no traffic was sent; check the current mode and app settings too.

You can briefly switch to a global proxy mode explicitly supported by the client to compare results, then restore your usual rules when done. If the site works in global mode but not in rule mode, the issue is likely with rule matching, domain detection or group selection. If it still fails in global mode, check DNS resolution, the route's exit and the destination service. Global mode isn't a universal fix: it also changes the path for traffic that would normally connect directly.

Distinguish a network error from a rejection by the service

If the page shows a region notice, access restriction or account verification prompt, the request may have reached the destination service. Changing your local port is unlikely to help at this point. Check which regions the platform supports, your account eligibility and the current exit region; if appropriate, switch regions and start a new session. For streaming, see streaming availability. Platform detection can change, so one successful visit isn't a guarantee of ongoing support.

If the main page loads but images, verification checks or interactive buttons keep loading, related domains may be following different rules, or an extension may be blocking them. Use your browser's developer tools to check the failed request's domain and error type. Note what you find without publicly sharing a full request that may contain account data. Adjust an extension's permissions for that site only after confirming it's the cause; don't leave all protections turned off.

Include a reproducible example in your support ticket

If the problem affects a specific domain, include its public URL, the exact error, route name, mode and whether the issue also occurs in another browser. If it only happens after sign-in, describe the steps to reproduce it; don't share your password. Support needs to know which layer failed, not access to your account on the destination site. For DNS errors, see the DNS section. For an issue in one app, see the app routing section.

Slow speeds and peak-hour lag

“Slow” could mean a website takes a long time to open, a video buffers, downloads are slow or a long-lived connection keeps stalling. These symptoms don't all depend on the same part of the network. Before troubleshooting, describe what you can observe: is it slow to connect or does it slow down during transfer? Are all sites slow or just one app? Does it happen at certain times or all day? That will help you choose a useful comparison.

Rule out device and local network congestion first

Keep the same route, pause large downloads, cloud sync and system updates, then repeat the task. A weak Wi-Fi signal, a busy router or other devices using the upload connection can all slow interactive requests. If moving closer to the access point or switching to a wired connection helps, focus on your local network first. VPNPart supports unlimited devices, but devices sharing a network still compete for its local resources.

Check whether the device is also sluggish, the processor is busy or storage is running low. The client, browser and apps all use device resources. Waiting for a download to unpack isn't a measure of route speed. If closing background tasks helps, note which type of task was involved instead of changing routes right away. Security checks on managed devices can also affect transfers; confirm with your administrator rather than bypassing them.

Compare routes using the same task

Keep the destination, client mode and network the same. Change only the route and compare the same loading or transfer task. Don't compare downloads from different websites: content source, cache, account permissions and server load can all differ. A route that performs well in a connection test may not be faster for every destination. A test measures only the part of the path it covers and can't replace a real-world task.

After reviewing route types to understand IEPL dedicated lines, relay routes and direct connections, compare different paths. This can help distinguish local network issues from issues between the exit and destination, but the route type alone can't guarantee peak-hour performance. If one route in a region is slow and others work, note its name and when the issue occurs. If every route is slow, check whether direct connections are also affected.

Compare times when troubleshooting peak-hour issues

To investigate peak-hour slowdowns, compare the same device, network and destination during busy and quieter hours. If performance drops only during busy periods, possible causes include shared network congestion, routing between networks or load on the destination platform. A timing match alone doesn't identify the cause; compare results on another network and route too. Reinstalling the client usually won't change congestion elsewhere and may erase useful configuration evidence.

For video apps, note whether playback starts slowly, buffers after a quality change or suddenly stops. For AI tools, distinguish a failed request from a long wait for the first response or a connection that drops mid-output. The last may point to long-lived connection stability rather than download speed. For development workflows, see choosing a route for AI coding tools and test your editor, browser and command line separately.

Separate traffic limits from performance issues

Sign in to the dashboard to check your remaining traffic and plan status. Monthly subscription traffic resets each month on your activation date, not on a calendar-month schedule. Data add-ons don't expire and remain available until used. If anything looks unclear, check the plan details before contacting support. Switching routes doesn't restore traffic already used. If you upgrade mid-cycle, the price difference is converted into remaining days; don't treat that as a fixed traffic credit.

If multiple routes show repeatable slowdowns during the same task and time window, include the time period, network type, destination category and comparison results in your ticket. Don't send only a one-off speed test screenshot, and don't attribute all the destination platform's response time to the network. A clear description of when it slows down and what change brings it back is usually more useful than a pile of test screenshots.

Frequent disconnects and mobile background drops

First, distinguish a system tunnel disconnect, a client process stopping, a route reconnecting and a session in the destination app ending. If the system still shows a connection and only the webpage needs refreshing, the whole connection may not have dropped. If the client disappears in the background, check system resource management first. Note whether it happens when the screen locks, the network changes, the device sleeps or while you're actively using it.

Network changes and automatic reconnection

When switching between Wi-Fi and another network, your device's address and default route may change, so existing connections might not survive. Start by testing on one network and see whether the disconnects continue. If they happen only while switching networks, check whether the client supports automatic reconnection, and keep in mind that some apps need to start a new session. A download that doesn't resume after the network comes back doesn't mean the client is still disconnected.

Automatic route selection can also disrupt a destination session. While troubleshooting long editing sessions, remote work or AI output, pin a route manually to reduce variables. If that helps, check what triggers automatic selection and which groups are available rather than turning off every health check. Restore the setting after testing as needed; a route that doesn't suit your current network may be a poor choice for everyday use.

Mobile screen lock and background management

On Android, check the app's battery management, background activity and autostart settings; names vary by system. Adjust the client specifically rather than disabling power saving for the whole device. If the system offers an always-on VPN setting, read its guidance and make sure it works with your client. Some options affect local network access. Note their original values before changing anything so you don't introduce a new access issue while fixing background behavior.

On iOS, first check that the system VPN configuration matches the current client, and that no old configuration or other network tool is taking over. If one app pauses its sync after the screen locks, that may be its own background policy; delayed notifications alone don't prove the VPN disconnected. After unlocking, check that the client is still running and the system still shows a connection, then test a website. Keep app background restrictions separate from route failures.

Can't reconnect after desktop sleep

After a desktop wakes from sleep, its network interface may have changed, leaving the client's old connection active while its route is no longer valid. Disconnect and reconnect in the client, then check that the system proxy and traffic capture mode have also recovered. If it happens after every wake, note the network and client status before and after sleep, then check the software settings. Restarting the router repeatedly isn't a substitute for diagnosis; it changes several external conditions at once.

If disconnects keep happening during active use, check whether the log shows the same error repeatedly. A timeout, a remote host closing the connection and a local process stopping mean different things; read them in context. If it only happens on one route, test another. If it happens on every route, test another network. Don't infer a server policy from one line in the log or add unverified settings to a subscription in use.

Share context from before and after the disconnect

In your ticket, say whether things work in the foreground, whether the issue starts after screen lock, whether it coincides with a network change and whether reconnecting fixes it. Include relevant log excerpts from before and after the disconnect, with subscription and authentication fields hidden. If the device is managed by an organization, include any policy restrictions you can share. If only one app loses its session while other sites keep working, see the app section instead of investigating a system connection that hasn't dropped.

Subscription update failures and configuration issues

Updating a subscription and connecting to a route are separate actions. An update fetches and parses the configuration associated with your account; connecting uses a route from a configuration already downloaded. So an old route can still connect even when an update fails, and a successful update doesn't verify every route. First identify whether the error is a fetch failure, an unexpected response or a parsing error, then follow the relevant steps.

Verify the subscription source in your own dashboard

Sign in to the dashboard and copy your subscription again from its subscription section. Don't rely on a link from a chat, text extracted from a screenshot or an old note. Check for extra spaces, line breaks or punctuation when pasting. A subscription is account information; don't give it to an online conversion site or public checker. VPNPart doesn't require an email address. Create an account with a username and password, and keep both your login and subscription details secure.

If your client can import directly from the dashboard, use the provided option. For manual import, make sure you select remote subscription rather than a local file. Don't mistake a sample link in a guide for your actual subscription. After importing, check that route groups or configuration names appear, then verify the update time and parsing result. See the subscription link guide for the full process, or return to the setup guide if you're getting started.

Tell a fetch failure from a parsing failure

For a fetch failure, check whether the current network can reach the dashboard, whether the client sends update requests directly or through a proxy, and whether an old configuration affects the update path. Some clients let you choose how updates are fetched, but the option's name and location vary. Note the current setting, then try another method explicitly supported by the client. Don't add an external proxy just to update a configuration, and never include your real subscription in a command-line screenshot or public log.

If the response is a webpage, sign-in prompt or network error page, the client may try to parse it as a configuration and report a format error. The key question is why the request didn't return a configuration—not how to adjust its indentation. Don't edit the response to “fix” the format. If the dashboard works but copying the subscription again still fails, note the error type and time, then ask support to check the update endpoint.

Configuration format must match the client

Clients accept different configuration structures; similar file extensions don't make them interchangeable. Use the method provided in the dashboard for your platform and client. Don't write protocol parameters by hand or overwrite your existing subscription with a configuration exported from another tool. If the client reports an unsupported field, check whether you chose the wrong import option, whether a local override is in place and whether you got the current client from the dashboard's download page.

Get a client from the user dashboard. Except on iOS, sign in to access the download; iOS availability depends on the plan status shown in the dashboard. This static guide doesn't provide direct installer links or list version numbers that may be out of date. Before updating a client, save any custom rules and settings you need. Use the system's normal update process; don't install an unknown tool claiming to repair subscriptions.

After an update, verify the selected route

After a configuration update, the selected route may have a new name, moved groups or no longer be referenced by the current configuration. Check the active configuration and groups rather than relying on the update success message alone. If you've imported several subscriptions with similar names, make sure the one enabled is your current subscription. Before removing duplicates, verify their source and any custom changes, and keep a copy you can restore.

In your support ticket, include the client name, import method, stage where it failed and exact error message. Don't include the full subscription link. If only one device fails while others update successfully, describe the platform differences and any local overrides. If every device fails, say whether the account is in good standing and whether you can access the dashboard. Clear details help support tell an account access issue from a network fetch or client parsing issue.

One app won't use the proxy: check routing

If your browser works but one app doesn't, first check how that app sends requests. The system proxy only affects apps that follow its settings; some use their own network stack, built-in proxy or DNS resolution. A running client doesn't mean every process automatically takes the same route. Compare how the app, browser and command line behave before deciding whether to change traffic capture mode.

Make sure the current mode covers the app

System proxy mode works with apps that follow system settings. A virtual adapter or tunnel can capture more traffic, but also involves permissions, routing and local network compatibility. Names vary between clients, so follow the client documentation. Don't turn on every mode by default, and don't overlook conflicts with other network tools. Note the original settings before enabling a new mode and make sure you can restore them.

Fully quit the app, then reopen it so it doesn't keep using an old connection path. Next, check the client's connection log for the domain, process and matched rule. If the request is going direct, check whether a local override rule or specific group was matched. If it already went through a proxy but still failed, check the route and platform requirements instead. Separating “didn't use the proxy” from “the destination rejected the request” helps avoid unnecessary changes.

Adjust rules narrowly; don't broaden them blindly

An app may use different domains for sign-in, resources, syncing and updates. A rule for its main domain alone may miss the request that's actually failing. Use the connection log to identify related domains, then make changes using the rule syntax supported by your client. Don't copy broad direct or proxy rules from unknown sources. They can change unrelated traffic paths and make the results harder to explain.

If switching temporarily to global proxy mode fixes the issue, use that result to review your rules; you don't need to stay in global mode. Keep appropriate local access for devices, printers and organization resources. Managed office networks may have specific requirements for internal DNS and proxy settings; coordinate with your administrator. Don't include internal addresses, resource names or organization settings in a public report.

Check command-line and desktop apps separately

Command-line tools may read proxy environment variables, while desktop apps may not inherit them—and vice versa. The commands below check whether variables are set without printing their values, which is a safer first check for an old proxy setting. Don't screenshot your full environment variable list; it may contain credentials for other services. A variable being present doesn't mean its value is correct or that the request actually uses it.

# Check whether proxy variables are set in a macOS or Linux shell
for name in http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY; do
  if printenv "$name" >/dev/null 2>&1; then
    printf '%s is set\n' "$name"
  fi
done

If you find an old variable, check whether it belongs to the current session or a startup file. A temporary session change and an edit to a persistent startup file have different effects; don't delete lines you don't understand. Check the client's local endpoint in its current settings rather than guessing a port. If a command-line tool has its own proxy options, consult its documentation to avoid unclear precedence when they overlap with environment variables.

AI tools, streaming and gaming

An AI app's sign-in window, editor extension and command-line process may use different paths, so test them separately. If the web version works but the editor doesn't, that doesn't prove the route is generally broken. See AI tool access to check platform availability by region and account requirements. If output stops mid-response, distinguish a network disconnect from a tool timeout or a restriction returned by the platform.

Streaming and games also have their own session and protocol requirements. A good result in a browser speed test doesn't guarantee smooth real-time interactions, and a network proxy isn't the same as a gaming service optimized for specific games. See when to use a game booster or VPN for more context. If only one app fails, include its entry point, mode, matched rule and exact error in your ticket. Don't share the destination account password.

DNS issues: check the resolution path

DNS translates domain names into addresses a device can connect to. A lookup failure can make the browser report that it can't find a server, but similar messages can also come from proxy rules or an app's network stack. First note the exact error, affected domains and what happens on another network; then decide whether to clear the cache. Don't replace your system resolver with an unfamiliar address just because a website won't load. It may not help and changes which resolver your device trusts.

Check the results before changing settings

On Windows, you can run the query below in Command Prompt. On macOS and Linux, it can also be used for comparison if the relevant tool is installed. The example domain is for demonstrating the command; it isn't a VPNPart route or subscription endpoint. Results may depend on cached data and the current network. A system query may not match what a browser using secure DNS actually sees.

nslookup example.com

Note whether you got a response, whether it timed out and what mode the client was in when the error occurred. If one domain fails while others work, the issue may be specific to that domain or its resolution path. If all domains time out, check whether your local resolver is reachable. Don't assume different returned addresses mean something is wrong; content delivery services may return different addresses based on region and network.

The browser, system and client may use different paths

A browser's secure DNS, system resolver settings and the client's built-in resolver can all be active at once. If the browser works but the command line doesn't, they may be using different resolution paths. First identify which layers have independent resolution enabled, then make temporary comparisons one layer at a time. Restore the original settings after testing. If you change all the layers at once, you won't know what fixed the problem.

When the client uses proxy-based DNS, also consider how the lookup request reaches the resolver and whether the result is routed directly or through a proxy. If an address returned by DNS is sent along the wrong path, the domain may resolve while the connection times out. Don't write forwarding rules you don't understand. Start with settings explicitly supported by the client, then use the connection log to compare domains, addresses and matched rules.

Cache, host mappings and dual-stack differences

Old cache entries can make a setting change appear not to work. Reopen the app first; clear the DNS cache only if needed and follow your operating system's instructions. Clearing the cache isn't a universal fix, and shouldn't be combined with changing routes and rules. A custom hosts entry can also keep a domain pointed at an old address. Before changing one, check where it came from and keep a copy of the original file.

Some networks support multiple address families, and the system and apps may choose different paths. If the browser, client and operating system handle those paths differently, some requests may bypass the expected route or fail. Permanently disabling an address family shouldn't be the default fix. First check what the client supports and which mode is active. Then make a reversible comparison and note which combination triggers the issue.

Know what a DNS check can prove

Information about a resolver's operator can suggest which infrastructure handled a particular lookup, but it can't prove the full traffic path or establish an absolute state for your account or browsing history. To check your current exit, compare My IP with the client's connection log. If the tool can't return a result, keep the failure as the current status rather than treating an older result as current.

VPNPart's no-logs policy describes the service; it doesn't mean your browser, destination websites or local network keep no data of their own. DNS checks should confirm whether resolution follows the expected path, not chase a supposedly ideal test label. In a support ticket, include the failed domain, lookup error, traffic capture mode, whether the browser uses its own resolver and what happened on another network. Hide local organization network details and account information in screenshots.

Device alerts, account status and support

VPNPart allows unlimited simultaneous devices. If you see a “device limit exceeded” or similar alert, don't assume the service has an undisclosed device cap or upgrade just to clear the warning. First identify where the alert came from: the VPN client, the destination website, the operating system or another subscription. Different sources have different limits and support contacts; identify the source before troubleshooting.

Check where the alert came from and which configuration is active

With multiple subscriptions in a client, similar names can make it easy to select the wrong one. Check which configuration is active and whether it matches your dashboard, without publicly sharing the full subscription to prove its source. If the alert comes from a streaming service or another destination app, it may be about that app's own device or session limit—unrelated to VPNPart's unlimited devices. Manage those sessions under the platform's rules rather than changing your network configuration.

If the alert appears in the VPNPart dashboard or during a client action linked to your current subscription, keep the complete error text and steps that led to it, then submit a support ticket. Don't guess at hidden limits or repeatedly sign out of every device to see what happens. Unlimited devices doesn't mean traffic is unmetered: check usage in the dashboard. Account status and local network resources still affect availability.

Check your account, traffic and order separately

Monthly subscription traffic resets each month on your activation date. If you upgrade mid-cycle, the price difference is converted into remaining days. Data add-ons don't expire and remain available until used. Check status in the dashboard: a successful sign-in doesn't prove the plan is active, and a return from the payment page doesn't prove an order is complete. If your status hasn't updated after payment, keep the order details and submit a ticket. Don't make another payment just to refresh the status.

For full pricing and billing details, see the plans page. Payment methods: Alipay / WeChat Pay / USDT. See the Terms of Service for details of the 30-day refund policy. You don't need to share payment credentials during troubleshooting. If support needs order information, submit only the necessary details through a ticket in your dashboard, and hide transaction information unrelated to the issue.

Structure your ticket around “setup, steps and results”

A useful ticket first explains what you were trying to do, then the step where it failed. For setup, include your operating system, client name, network type and current mode. For steps, say which route you selected, which service you were accessing and whether you had just changed any settings. For results, include the exact error, when it occurred, whether you can reproduce it consistently and what changed on another route or network. Get version details from your device rather than guessing.

Use the outline below to organize your report. Don't include subscription links or authentication details. If you haven't run a particular test, say so; that way support won't mistake a guess for a verified result. Screenshots can supplement your description but don't replace the steps you took. Include only relevant log excerpts, not your full browsing history.

When to contact support

Submit a ticket through the user dashboard if your account status doesn't match what's been delivered, the subscription fails to fetch on multiple devices, the same route issue occurs across networks, or you see an unexplained device limit warning. For organization network policies or system administration permissions, contact your administrator. For destination platform account eligibility, contact that platform's support; the route support team can't change an external account for you.

After things work again, clean up: restore global mode, temporary DNS settings and proxy variables used only for testing, then confirm your usual apps and local resources still work. Keep only changes that helped and a brief record; delete log copies you no longer need. For common questions, visit the Help Center. For unfamiliar terms, see the quick guide to subscriptions, nodes and routing so you can start next time from the layer you already know.