VPN Troubleshooting Guide

Can't connect at all: check the connection first

“Can't connect” can mean the client won't start, a route fails to connect, or just one website won't load. Note the full error message and check whether the client explicitly shows that it's connected. Endless spinning, an immediate disconnect, and a request to authorize again are different issues. Don't rely on the status bar icon alone or assume every problem is a route failure.

First, check whether the device can access the internet without the client

Temporarily disconnect the client and open a website that normally works. If regular websites also fail, check whether the Wi-Fi network requires a sign-in page, whether the router has internet access and whether your system still has an invalid proxy setting. Proxy settings can block public Wi-Fi sign-in pages, so authenticate to the network before connecting to the service. Check your workplace or school's network policies too.

Once the regular connection works, leave other settings unchanged, reopen the client and check for system authorization prompts. If tunnel, network extension or system proxy permissions are denied, the route list may still appear normal, but no connection will be established. Allow the permissions required by the client when prompted. If the device is managed by an organization, ask its administrator rather than trying to remove management policies.

Check the account, configuration and route separately

Open the account dashboard and check the current account, plan status and remaining data. A successful browser login only confirms that the dashboard is accessible; it doesn't mean the client configuration is still valid. The client may also have an older subscription saved for another account. Check the configuration name and where it came from, confirm they match, then update it. Don't repeatedly import configurations from unknown sources.

If every route fails, check the logs for permission denied, name resolution failure, connection timeout or authentication failure. Fix local permissions first, follow the next section for resolution errors, and check the subscription source for authentication errors. Only investigate the network and route further for timeouts. Error messages are clues, not proof that an account has expired or a service is down.

Test another route listed in your current subscription, preferably one with a different route type rather than just a different name in the same city. VPNFJ offers IEPL dedicated routes, relay routes and direct routes. These names describe how traffic is routed, not a fixed ranking of quality. Check the route list for regions and types, but use the dashboard and client subscription to confirm what's actually available to you.

Use cross-checks to narrow down the issue

Keep the same device and configuration, but switch to another available network. If switching networks fixes the issue, the cause is more likely the original network, router policy or local network route. If it fails on multiple networks, check the device configuration and permissions. You can also test the same account on another device you own, but don't share your subscription link with anyone you don't trust.

If another device works, check for other proxies, security software or leftover network extensions on the affected device. Don't run multiple clients that change system routes at the same time. Quit the other tools normally, then reconnect with the current client. Don't delete system network components or leave protection disabled for testing. If a temporary change is necessary, record it and restore it after the test.

An incorrect system date can also cause encrypted connection checks to fail. Make sure the system time and time zone are correct, allow automatic time synchronization, then quit and reopen the client. Don't try to “fix” certificate errors by ignoring verification. If the time is correct but errors persist, save the exact message and contact support rather than importing a certificate from an unknown source.

Connected but websites won't load: check the resolution path

A connected status means the connection process reached a certain point; it doesn't mean every app is using the proxy correctly. Website access also depends on DNS resolution, app proxy settings, the exit route and the destination's response. First check whether all websites fail or just one. If all fail, start with local proxy and DNS settings. If only one fails, look at routing rules, region and the service itself.

Use a browser to narrow down the problem

Keep the current route and try unrelated websites, noting the exact error. “Server IP address could not be found” points to a resolution issue. “Proxy server is refusing connections” suggests a local proxy port or process problem. If the page loads but says the service isn't available in your region, you're dealing with the destination service's regional checks; changing DNS at random won't help.

Try another browser or a private window to check whether cache, extensions or site data are involved. A private window may still use extensions and doesn't necessarily use the same resolution method, so check that browser's proxy extensions and secure DNS settings too. If only one browser is affected, troubleshoot its settings rather than resetting the entire system network.

Keep the original domain when visiting a website; don't paste the resolved IP address into the browser and treat that as a definitive test. Many websites share servers and rely on domain names for certificate checks and site selection. Visiting an IP directly may show a certificate error, a blank page or a different site. That neither proves DNS is working nor shows that the route has failed.

Check system DNS resolution before changing servers

On Windows, macOS and many Linux systems, you can use the command below to check how a domain resolves. The example domain only demonstrates the command format; a successful lookup doesn't mean the service you're trying to reach is working. For troubleshooting, replace it with the affected site's public domain. Don't paste a full URL containing subscription credentials or private parameters.

nslookup example.com

If the command returns a result but the browser still reports a resolution error, the browser may use its own secure DNS or the client may handle DNS inside the tunnel. Conversely, a failed system lookup doesn't mean all proxy traffic will fail. Check the client's domain lookup logs too; a system lookup alone doesn't show what happened across the entire connection path.

In your settings, check whether browser secure DNS, encrypted system DNS, client DNS interception and custom router DNS are all enabled. These layers don't always conflict, but they make troubleshooting harder. Note the current values, then test the client's default settings one at a time. Don't copy server addresses from forum posts or assemble rules yourself.

Tell cache, routing and destination issues apart

If you recently switched routes or updated the configuration, reconnect and fully quit and reopen the affected app. Some apps reuse old connections or cached DNS results, so refreshing a page may not create a new request. Clear cache only for the affected app. Without evidence, there's no need to delete all browsing history—especially account or local data you haven't backed up.

If the page loads but its images, sign-in or video fail, other domains used by the page may be taking a different route. Check the client's connection log and compare the rules matched by successful and failed requests. Share only the necessary public domains with support. Don't permanently route all traffic the same way just to fix one image.

If you see a certificate warning, get redirected to an unfamiliar sign-in page or are asked to install an extra certificate, stop before entering account details. Disconnect the proxy and check whether the page belongs to the current network's sign-in process, then verify the website address. DNS troubleshooting never requires your password or a root certificate from an unknown source. For more information, see the guide to account, subscription link and public Wi-Fi safety.

Slow speeds and peak-hour lag: compare the route

Slow-loading pages, video buffering, slow downloads and sluggish app responses can have different causes. Use the same destination and device to distinguish delays in establishing a connection, loading page resources, sustained transfers and server processing. Don't compare experiences across different websites or use one speed test to sum up the whole network. Time spent generating a model's response shouldn't all be attributed to route latency either.

First rule out problems with your local connection

Check whether your device is syncing photos, updating its system or downloading large files. Other devices on your home network may also be using bandwidth, especially for backups that aren't visible in the current window. Pause background transfers you control and test the same destination again. If the local connection itself is slow, improve that first; switching routes can't restore bandwidth that's already congested.

On Wi-Fi, retest on the same device closer to the access point, or use a wired connection if possible. If lag only occurs farther from the router, poor coverage or interference is more likely. Don't move the device, change routes and switch video quality all at once. Changing several variables together makes it impossible to tell which one helped.

Compare the same task during a regular period and at peak hours. Describe what happens—for example, “websites load normally, but video keeps buffering”—rather than jotting down a speed figure. If all routes slow down at the same time, check the local network and shared links. If only one route is slow, compare it with other available route types using a similar exit region.

Switch routes based on type, with a clear test in mind

IEPL dedicated, relay and direct routes differ mainly in how traffic is carried. A dedicated route doesn't guarantee that a destination won't throttle you; a relay isn't automatically slower, and a direct route isn't always shorter. The exit region, local network and destination service all affect performance. Choose an exit region supported by the destination, then compare available routes. Don't pick a route based only on map distance.

After switching routes, reopen the affected task so it creates a new connection. A video that's already playing, a persistent session or an active download may continue using the old route. If you only select another route without making a new request, it may look as though the switch did nothing. Save your work before testing anything that depends on a persistent session.

For video buffering, also check the playback quality, streaming service and account region. If one streaming service is having trouble but other transfers work, that doesn't prove you lack overall bandwidth. Try lowering the playback quality to see if it helps, then check the streaming guide for regional requirements. For AI services, see the AI access guide to check supported regions and account messages.

Check data usage, but don't treat an upgrade as troubleshooting

Check your remaining data and plan status in the dashboard so you don't mistake a data limit for network congestion. Monthly subscription data resets each month on the activation date, not at the start of each calendar month. Data add-ons don't expire and remain available until used. See the plan details to compare data allowances. Moving to a larger data plan won't fix local Wi-Fi interference or a problem with the destination website.

If peak-hour lag is reproducible and you've recorded the results of switching networks and routes, submit a support ticket. Say whether the lag occurs while connecting or during sustained transfers, which apps are affected and whether it happens only with one exit. Keeping a working route as a point of comparison is more useful than repeatedly running speed tests, and helps distinguish a recurring issue from a brief fluctuation.

Frequent disconnects and background dropouts: check session continuity

First check what happens in the client when the connection drops: does the connection switch turn off, does the process disappear, does the route reconnect, or does the client stay connected while the app stops responding? These point to different causes. Note what happened just before the drop, such as locking the screen, switching networks, closing a laptop or starting another proxy. A reproducible trigger is much more useful than “it disconnects sometimes.”

Separate network changes from route failures

When a device switches networks, its source address and route may change, so existing sessions may need to reconnect. Even after the client shows that it's connected again, some apps may retain old sessions and stop updating or keep waiting. Make a new request in the affected app before deciding that it can't recover. Don't rely on the status bar icon alone.

If the connection still drops repeatedly on the same network with the screen on, check the client log for events just before each drop. A deliberate disconnect, process exit, lost network access and remote closure aren't the same cause. Keep the relevant log lines around the event; there's no need to upload a full log covering a long period. If the log only says “connection timed out,” compare the results from switching routes and networks before concluding the remote service is at fault.

If one Wi-Fi network repeatedly drops, see whether other apps lose internet access at the same time. Router reconnections, weak wireless signals and roaming between access points can all affect a tunnel. If every device loses internet, troubleshoot the local network first. If the local connection is stable but only one route reconnects, test another route and note whether it uses the same exit region.

On mobile, check background and battery settings

Background restrictions vary across Android devices. Open the client's app settings and check battery management, background activity and data access. Use the system's own options to let the connection run in the background. Don't expect settings to have the same name on every device, and don't grant permissions unrelated to network connectivity just to keep the app running.

If disconnects only happen after the screen locks, keep the network and route the same and compare what happens with the screen on and while locked. Then change only the background restriction and test again. Some systems close the client when you clear it from recent apps, so swiping it away isn't the same as returning to the home screen. Describe exactly what you do instead of calling both actions “closing the app.”

On iOS, first check whether the system VPN status matches the client. Keeping the app in the foreground won't necessarily fix every background issue; the system-managed network extension and app interface aren't the same process. If other VPN configurations, device management policies or network filtering tools are present, check whether they take over the connection. Test them one at a time, where permitted.

Note whether Low Power Mode, Low Data Mode or a network switch is involved, but don't turn off all power-saving features indefinitely to troubleshoot. First confirm that a setting has a reproducible link to the disconnect before changing it. If the issue began after a system update, check whether permissions need to be granted again and whether the client configuration is still present. Don't reset the entire device as a first step.

Test desktop sleep and persistent app connections separately

A computer's network adapter may pause during sleep or when the lid is closed. When it wakes, network access and app sessions may not recover at the same time. Wait for the system network to come back, reconnect the client manually, then reopen the affected task. If the issue only happens after waking, note the before-and-after states rather than grouping it with disconnects during regular use.

Video calls, remote sessions and ongoing uploads are more sensitive to brief interruptions. Even if websites work again afterward, the original task may need to reconnect. Save your work before troubleshooting and avoid testing during a critical transfer. If different routes all disconnect after the same action, check the device and system first. If only one route is affected, include comparisons with other routes in your ticket.

Subscription update failed: verify the configuration source

Updating a subscription and connecting through a route are separate processes. The client first needs to retrieve configuration data; it then uses that configuration to connect. An old configuration may still connect even if it can't be updated, so that doesn't mean every current route has failed. Conversely, a successful update doesn't prove the returned configuration is compatible with your client. Keep any configuration that still works, then use the error message to identify where the update failed.

Check the dashboard account and current configuration first

Check the account and plan status in the account dashboard. VPNFJ doesn't require an email address; accounts can be created with a username and password. Check the actual username and dashboard status. If your browser has multiple saved accounts, the one currently signed in may not be the account linked to the subscription in your client.

Subscriptions and client downloads are managed through the dashboard. Sign in to get your subscription; the dashboard determines whether client downloads are available. Open the client download page and follow the instructions for your platform. Don't keep copying old links from chat history or import a marketing page URL as a subscription.

Check whether the update error is a network timeout, access denied, unparseable content or an unsupported configuration field. For a timeout, check the network path used by the update request. For access denied, check whether the subscription is still valid. For a parsing failure, make sure the response is in the right format. Treating different errors as the same problem can overwrite an older configuration that still works.

Tell a failed request from an incompatible format

Some clients let update requests use the current proxy or go directly through the local network. If the current proxy has failed and updates are set to use it, you can get stuck in a loop where the client can't retrieve a new configuration. Use the client's options to test a different update route and note the original setting. Options vary by client; don't guess configuration fields or enter unverified parameters manually.

When copying a link, check for spaces, line breaks or extra punctuation. Some chat apps separate clickable text from the actual destination, so copying the displayed text may not capture the full address. The safest option is to retrieve it again from the dashboard and import it using the guide. Don't paste a full subscription link into a public format checker; it usually contains access credentials.

If the update returns content but the client can't parse it, you may have received a sign-in page, network authentication page or incompatible configuration format. Tell support the error type, client name and import method; don't paste the full response. Before sharing even the beginning of the content, check that it contains no credentials or private data. If in doubt, stop and ask support what can be shared safely.

After a client update, some options in an older configuration may no longer apply. An outdated client may also be unable to read a current configuration. Check compatibility using the client instructions in the dashboard instead of searching for a so-called universal configuration. Marketing pages don't offer direct installer downloads. Don't replace your client with an installer from an unknown source to fix a parsing error.

Keep a rollback option before importing again

Before importing again, note the current configuration name, rule mode, custom routing rules and update path. Back up the configuration locally if you can do so safely, remembering that the backup may contain credentials. Don't put a complete backup in a public cloud share or attach it to a support ticket. If only the update failed and the old routes still work, keep them and test the new configuration as a separate item.

After importing the new configuration, make sure it's selected and its route list has loaded before connecting. “Import successful” doesn't mean the new configuration is in use; multiple items with the same name can also be confusing. Remove old items only after testing, and check that scheduled updates point to the right configuration so the client doesn't revert to an outdated one.

If you think your subscription link has been exposed, stop sharing it and use the subscription management options available in the dashboard. Contact support if you can't find them. Your other devices may need to retrieve the configuration again after a reset. Treat your subscription link like a password. See the security guide for beginners for more tips.

An app isn't using the proxy: check its routing rules

If a browser works but one app doesn't, check how that app connects to the internet before replacing the subscription. System proxy settings, in-app proxy settings and a system tunnel cover different traffic. Some apps follow the system proxy, some use their own network settings, and others need the client's system tunnel to handle their connections. Turning on the connection doesn't mean every app will take the same route.

Compare app behavior with the connection log

Fully quit the affected app, connect the client, then reopen the app. Check whether the client logs a connection for it, including the matched rule, exit and result. If there's no entry, the request may not have been intercepted, the app may not have made a network request, or the log view may have a filter enabled. Don't assume the app bypassed the proxy just because its name isn't listed.

If the log shows a connection matched to a direct rule, check the current routing mode and the destination domain. Some services use separate domains for sign-in, content delivery, images and APIs. The homepage working doesn't mean every request uses the same route. A failed feature and its public domains are more useful than the app's brand name alone. Don't include private account parameters in your report.

An app's own proxy setting may override the system setting or point to a local port that's no longer running. Note the current setting, check whether the app needs its own proxy, then choose whether to use the app's proxy or system routing. Don't point an app to an address the client isn't listening on, and don't copy a port number from someone else's computer. Use the settings shown by your own client.

Test system proxy and tunnel modes separately

A system proxy is generally used only by apps configured to follow it; it doesn't force all network traffic through a proxy. A system tunnel requires the appropriate permissions and may also handle routes and DNS. If the client recommended in the dashboard supports this feature, follow its instructions and check the permission prompts. Similar names don't mean you should enable tunnel or network interception in multiple tools at once.

You can temporarily switch to the client's global proxy mode as a comparison, but it's a diagnostic step, not necessarily the right permanent setting. If the app works, check the rules or interception scope. If it still fails, look at the app settings, exit region and destination response. Restore a suitable everyday mode after testing so local devices and intranet resources aren't affected.

For workplace intranets, printers or other local network devices, keep the access needed for your local network. Routing all addresses through a remote exit may make local resources inaccessible. Test local network access and the affected app separately; don't solve one issue by creating another. Changes to routes on managed devices must follow your organization's policies. Ask an administrator if needed.

Separate regional restrictions and account issues from connection problems

If an app loads and displays a regional restriction, the issue usually isn't simply that traffic isn't using the proxy. Check the regions supported by the service, your current exit and whether the account's region matches. An exit route can't change your account details, payment eligibility or the service's rules, and can't guarantee an account will pass its checks. Choose a region deliberately rather than switching between regions repeatedly.

For tools such as ChatGPT, Claude and Gemini, distinguish sign-in on the website from sign-in in the app and from individual feature requests. If the connection works but the account shows a restriction, read the service's own guidance first. See the Claude access guide and regional availability and route selection tips. An account review isn't a route problem that the service must fix.

Streaming apps may also retain a cached region or an existing playback session. After switching, start playback again and check the message; clearing cache isn't guaranteed to change the available catalog. If other websites work but playback doesn't, note the platform, client environment, exit region and exact error. See the streaming guide to distinguish regional, licensing and connection issues.

Some features use UDP or other transport methods. If the web version works but voice, calls or games don't, describe the specific feature instead of saying only that the app won't open. Check the current client configuration and dashboard guidance for supported transports. Don't open unknown ports or change protocol parameters yourself; ask support to check anything you're unsure about.

Platform permissions and device prompts: check your system

VPNFJ supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. If the client displays a message such as “device limit exceeded,” don't assume VPNFJ imposes a device limit. First check whether the message comes from the client, operating system, another service or the destination app. Then confirm the account and subscription source to avoid confusing limits from different products.

Identify where the prompt came from before checking the account

When taking a screenshot, include the window title and exact error message so support can identify its source. The client login, subscription account and destination website login may be separate. A login-session limit in an app doesn't mean the network subscription limits simultaneous devices. Don't sign out other people's devices just to dismiss a prompt or enter extra details that the current service hasn't requested.

If the message clearly appears while connecting through your current subscription, note the dashboard status, client configuration name and whether your other devices can connect. Don't assume you need a plan upgrade. Exhausted data, an expired subscription, a mismatched configuration or an error mapped to the wrong message all require different checks. Support can locate the issue only when the source and context are clear.

On desktop, check for leftover proxies and missing permissions

If a website still reports a proxy error after you quit the client on Windows, check for a leftover manual system proxy setting. Note the original value before changing it; some workplace networks require a proxy. Quit and reopen the client normally, then check whether it sets and clears the proxy as expected. Don't uninstall every network adapter or run network repair scripts from unknown sources.

On macOS, check whether the system has allowed the network extension and whether the system proxy belongs to the currently running client. Installing the app doesn't mean every permission has been approved. If the issue started after migrating to another device or restoring a backup, review any old extensions or configurations. Confirm what an item is before removing it so you don't delete another network service you still use.

On Linux, desktop apps, terminal programs and background services may not inherit the same proxy environment variables. A working terminal connection doesn't prove the browser is configured correctly, and a working browser doesn't prove that a service process is working. Check how the affected process starts and what configuration it reads, then follow that program's documentation. Before changing system services, save the configuration and confirm how to restore it.

On mobile, check system routing and background restrictions

If there are multiple VPN configurations on iOS, check which one is connected and whether enabling another configuration replaces it. Device management policies may restrict network extensions; ask the device administrator to confirm. Don't install an unknown configuration profile to fix a routine connection issue or change unrelated system security settings while troubleshooting.

On Android, confirm that the client has system VPN permission and check whether another VPN app is taking over. Background controls vary by device; comparing behavior before and after locking the screen is more reliable than copying a settings screenshot from another model. If the system still shows a connection after the app closes, reopen the client to check its status rather than assuming the notification icon means data is flowing normally.

System updates, client migrations and device restores can all change permissions or configurations. Recheck permissions and the selected subscription on the current device, then test on another network. Don't copy every network setting from an old device to a new one; local ports, process paths and permission menus may differ. Checking each item separately makes the results easier to understand.

Before reinstalling the client, confirm the download page is available and safely save any custom rules you need. Reinstallation changes the setup and may delete local configuration, so consider it only after checking permissions, account status and the network. If you need to repeat the import steps, return to the quick start guide and follow the instructions for your platform.

Contact support: prepare your ticket and recovery notes

You don't have to try every setting before contacting support about a persistent issue. After checking basic connectivity, account status and another route, contact support if the error is still reproducible or involves a certificate warning, exposed subscription link or unexpected authorization prompt. Stop making further changes and preserve the current setup. That's more useful than another reinstall, and avoids turning one clear issue into a confusing mix of changes to configuration, permissions and network settings.

Describe the scope of the problem in plain facts

Start your ticket with the clearest symptom, such as “The client says connected, but the browser can't find the server address,” rather than just “it doesn't work.” Then say when it started, whether it worked before and whether anything changed in the system or configuration. Use the device's local time and include the time zone so support can tell separate tests apart.

Include the device platform, client name, network type, route name and route type. Provide the client version as shown on your device, but don't guess or update just to fill in the details. Use the route name displayed in the client. If you renamed it, include the original item or leave enough identifying information in a redacted screenshot to match it to the configuration.

Describe tests as comparisons with clear results, such as “Switching networks fixed it on the same device; the original network still failed on another device.” A list like “restarted, changed routes, cleared cache” doesn't rule anything out without the results. Say “not tested” for anything you haven't tried. Don't invent a result for completeness or describe a brief recovery as a permanent fix.

Share only what's needed and protect your credentials

Submit your issue through the support ticket page in the dashboard, or read the support information first. Don't post full logs in public comments. Redact your account password, full subscription link, QR codes, authorization headers and private details in payment records. Anonymous, no-logs service policies don't remove your responsibility to protect sensitive information on your own device.

Include only the relevant log entries around the error and keep the exact error message intact. Decide whether domains, addresses and local paths are needed to diagnose the issue. If you aren't sure, describe the problem and ask support what to include. Don't upload your entire browsing history, conversations or unrelated app records by default.

Check the background windows, notification previews and address bar in screenshots too. An error dialog may look harmless while the dashboard behind it shows a full subscription link or personal information. QR codes can contain credentials even when no text is visible, so redact those as well. Before sending, reopen the processed attachment and confirm the redactions are permanent; don't upload the original after only marking it up in a screenshot tool.

Test each recommendation and keep a way to roll back

After receiving advice, change one specific setting at a time, test the same destination and record the result. If the instructions don't match what you see on your device, share the differences rather than guessing at a similar option. Before deleting a configuration, resetting the network or reinstalling, check what custom settings you need to keep. Don't combine conflicting instructions from multiple network guides.

Once service is restored, retest the feature that originally failed, including its original trigger—locking the screen, reconnecting to the network or reopening the app. Opening a homepage doesn't verify video playback, sign-in or background sessions. Also undo temporary global modes, extra permissions and test rules used only for diagnosis. Keep any changes that are genuinely needed and note why, so the configuration remains understandable later.

If your issue relates to data usage, compare your usage with data add-ons and monthly subscriptions. For billing or refunds, VPNFJ offers a 7-day no-questions-asked refund; see the refund policy in the terms of service for details. Payment methods include Alipay / WeChat Pay / USDT. Keep refund questions separate from route diagnostics so each ticket has the context it needs.

Keep a brief personal record of the original issue, what fixed it, how you verified the result and which settings need to be restored. If it happens again, check whether the trigger is the same; there's no need to repeat every step from scratch. This system troubleshooting guide helps locate issues. For a fresh setup, follow the quick start guide; to compare routes, see the route list.