Connection Troubleshooting

A step-by-step guide to connection issues

Start by pinning down what “can’t connect” means: the client won’t open, the configuration won’t load, the Connect button shows an error, or it stays on “Connecting” indefinitely. These symptoms point to different parts of the setup, so don’t assume it’s a server issue. Note the step where the problem occurs, what the screen shows, and whether the same error appears every time. Keep the current configuration and server names, then disconnect and check whether your usual websites load over your regular network. If the basic connection isn’t working, switching servers usually won’t tell you much.

Check your local network first, then your account

Hotel, office, and public Wi-Fi networks may require you to sign in through a web page first. Disconnect the VPN and open a browser to see if a network access page appears. Only complete the sign-in after verifying that the network is legitimate, and never enter your VPNShort password there. If the network itself isn’t working, check your Wi-Fi connection, gateway, and any network maintenance notices. You can compare with another trusted network, but keep the client, configuration, and server the same so you don’t change everything at once and lose useful clues.

Once your local network is working, open the account overview in the user panel and check that your subscription is active, you have data remaining, and the client has loaded the configuration for the correct account. Monthly plan data resets each month on the activation date, not at the start of the calendar month. Data add-ons don’t expire, but they can still run out. If the panel shows an active subscription but the client has no configuration, follow the subscription troubleshooting steps rather than repeatedly trying to connect with an empty configuration.

Tell permission issues apart from remote connection failures

The first time you enable a network feature, your system may ask permission to add a VPN configuration, network extension, or virtual network interface. If you dismiss the prompt, the client may still open even though the connection hasn’t been established. Check your system settings to see whether the required permission was blocked, then return to the client and try again. On a managed device, access may be controlled by an administrator. Don’t remove management settings just to connect; ask your network administrator which connection methods are allowed.

Once permissions are granted, try another server in the same region. If that still fails, compare it with a server in another region. VPNShort covers 120+ countries / 240+ servers, but coverage doesn’t mean every server will connect on every network. If only certain servers fail, note their names and the errors. If all servers fail while creating the local interface, check permissions or the client’s status. Don’t infer a server’s type from its region; use the options shown in the current list.

When to restore settings—and when to escalate

Devices previously used with other network tools may have leftover system proxy settings or virtual interfaces. Exit other tools normally, then check whether a system proxy still points to a local service that’s no longer running. Don’t delete every network interface at once or run an unfamiliar script to reset the entire network. If you need to restart, save your work and disconnect the client normally first. After restarting, open only the tool you’re testing and check whether the error occurs at the same step. This makes the issue easier to isolate than running multiple tools at once.

Submit a support ticket if your local network works, the panel shows an active account, the configuration is up to date, permissions are granted, and servers in different regions still fail in the same way. Include your operating system, client name, date and time with time zone, network type, server name, and the error text with sensitive details redacted. Say whether the issue also occurs on another network, and whether it happens after clicking Connect or after the interface is created. For device management permissions, contact your administrator first. Support can’t grant system permissions and shouldn’t ask for your full account password.

Connected, but websites won't load

When the client says “Connected,” it usually means the local connection process or tunnel status has changed. It doesn’t guarantee that browser requests are going through or that the destination website accepts your current exit location. First work out whether no websites load, only international services fail, or one specific site returns an error. Keep the full error text: DNS failures, connection timeouts, certificate warnings, and access denials point to different issues. A screenshot of a blank page alone rarely shows where the request stopped.

Compare requests to narrow down the issue

Keep the client connected. Visit a website that normally works and the destination service that’s having trouble, then try the same addresses in another browser. If only one browser fails, check its proxy extensions, secure DNS, and cache first. If all browsers fail but the client log shows no matching requests, check whether the system proxy is actually enabled. If the log shows the destination request and a successful outbound connection, the issue may be with the destination service, your account, or the app itself—not necessarily the server.

A system proxy and a virtual network interface handle traffic in different ways. Some apps use the system proxy; others connect directly. Some clients can also proxy only selected apps. If the right traffic-handling mode isn’t enabled, your browser may keep using the regular network even when the VPN connects. Check the client’s instructions for the current mode, and don’t guess at a proxy port in system settings. Use the port shown in the running client; an old configuration may contain a port that’s no longer active.

Distinguish a website denial from a network failure

If the page shows a specific region notice, account verification prompt, or access restriction, the request may have reached the service. Check the service’s regional rules, the region associated with your account, and your existing browser sign-in. ChatGPT, Claude, Gemini, and streaming services each have their own requirements; changing your exit location doesn’t replace account eligibility. You can compare in a browser without extensions, but don’t try to bypass the service’s identity or eligibility checks.

A certificate error doesn’t automatically mean the server is unreachable. Check your system date, time, and time zone, and see whether the error affects only one website. Public Wi-Fi sign-in pages, corporate network inspection, browser extensions, and device security software can all affect certificate checks. Don’t ignore certificate warnings and enter your password, and don’t install root certificates from unknown sources. On a managed device, save the warning and ask your administrator to check it. If the site works on a trusted network, focus on the original network.

Verify the fix—don’t rely on the connection icon

After each settings change, reload the same test page and see whether the error changes. If needed, close and reopen the browser to end existing connections before testing a new request. A private browsing window doesn’t automatically clear the system DNS cache or bypass every browser network setting. The goal is to reduce variables, not treat private browsing as a universal fix. Once the issue is resolved, undo temporary changes that weren’t related to it so your setup stays manageable.

If all requests reach the client but one domain keeps failing, include the domain, error text, selected server, and whether other websites work in your ticket. Don’t send full URLs containing login credentials, session cookies, or a complete browser network export. If the destination service clearly reports an account eligibility issue, contact that service. For questions about server coverage, check the available options in the server list and say which servers work and which don’t.

Slow speeds and peak-hour lag

Make “slow” specific and reproducible: is the browser taking too long to render, is video buffering, are downloads stalling, or is an AI response taking a long time to start? Different activities depend on different factors. Video can be affected by content delivery servers and resolution, websites may stall at DNS lookup, and AI requests include server-side queues and generation time. Don’t treat one app’s wait time as a measure of the entire connection, or judge network quality by the connection icon alone.

Set up a fair comparison

Pause large file syncs, system updates, and other downloads on your device, then check whether other devices on the same network are using significant bandwidth. Weak Wi-Fi, distance from the access point, and local network congestion can all make a remote server seem slow. Compare wired and wireless connections from the same location, or different devices on the same Wi-Fi. Change one thing at a time, and note the service, activity, and time of day instead of relying on memory.

Keep the destination service and client unchanged, then compare your current server with another available option. Don’t switch browsers, regions, network modes, and video quality all at once; even if things improve, you won’t know why. If only one service is slow, check its status notices and account restrictions first. If several services slow down at once, look at the server or local network. A single download may be throttled by its source and isn’t a reliable measure of overall service performance.

Compare peak-hour performance across times and routes

Peak-hour lag can happen on the access network, along the cross-border route, or at the destination platform. The fact that it happens at night doesn’t identify the cause. Compare the same server at different times, then compare servers in other regions during the same time period. If switching local networks helps, investigate the original network path first. If only one region has issues, try another exit location suited to the destination service. Choose servers based on actual availability and consistent performance, not a fixed ranking by distance.

IEPL, transit, and direct connections describe different ways traffic is routed; none is inherently better in every environment. A dedicated line doesn’t guarantee that the destination will always be reachable, and transit isn’t necessarily slower than a direct connection. Results also depend on whether the entry point is reachable, the route from the exit to the destination, and current network conditions. Check the current options in the server list. Don’t treat a route label as a speed guarantee or assume every region offers every type.

Test according to the app; don’t change settings blindly

When video buffers, play the same content at a fixed resolution and check whether playback is slow to start or keeps stalling. For AI tools, distinguish page loading, sending the request, and server-side generation. For API calls, separate connection setup, response wait time, and streamed output. Don’t hide network problems by setting unlimited timeouts or retrying the same request endlessly. Developers can refer to Choosing a route for AI APIs and keep app logs separate from network logs.

Avoid changing MTU, concurrent connections, or transport settings before you’ve isolated the problem. Settings with the same name may behave differently across clients, and an unsuitable change can break some websites. Start with the default configuration, confirm that the issue is reproducible, then change one setting at a time using clear instructions and save the original value. If several servers keep failing on the same task at the same time, submit the date and time with time zone, server names, task type, and local network comparison. Stick to observable facts; there’s no need to exaggerate speed test results.

Frequent disconnects and mobile background dropouts

First determine whether the tunnel itself stopped or only the app’s connection was interrupted. Check the client status, system VPN indicator, and the destination app’s error message. Note what happened just before the issue: screen lock, network switch, closing a laptop lid, returning to the app, or entering power-saving mode. If it always happens after the same action, check system lifecycle behavior and network switching before blaming the remote server. An app spinning doesn’t necessarily mean the client has disconnected.

Check network switches and wake-from-sleep behavior first

When a device switches from Wi-Fi to another network, its local address and route may change, and existing connections may not survive. Apps with long-lived connections need to establish a new session, and the client may need to select another reachable entry point. After the network switch completes, check whether the connection recovers automatically. If not, disconnect normally, reconnect, and reopen the destination app. Don’t repeatedly press Connect while the device is still searching for a network; overlapping actions make the logs harder to interpret.

After a desktop wakes from sleep, the virtual network interface and system proxy may not recover in the same order. First make sure the regular network is back, then check whether the client still shows as connected. If the system proxy remains enabled but the client service hasn’t resumed, the browser may send requests to a local address that isn’t listening. Exiting and restarting the client normally is usually safer than clearing all network settings. If the problem always happens after waking, note the state before and after sleep.

Check mobile background permissions by platform

On Android, battery optimization, background activity limits, and manufacturer policies can affect network services. Check system settings to see whether the client is allowed to run in the background as needed, and review how your device handles power-saving mode. Menu names differ across devices, so don’t follow another manufacturer’s steps blindly. Allowing background activity doesn’t mean granting unrelated permissions; adjust only options relevant to keeping the network service active, then compare behavior with the screen locked and after returning to the device.

On iOS, the system manages network connections, and an app going into the background doesn’t necessarily mean the tunnel has stopped. Check the system VPN status and test an actual request rather than relying on whether the app is in the foreground. Other VPN configurations, device management settings, or on-demand connection rules may cause another configuration to take over. Don’t delete every profile indiscriminately. On managed devices, check the management policy before changing how the connection works.

Keep evidence from before and after the event

If the connection drops randomly during use, keep the device and network steady and check whether another server has the same issue. If only one server is affected, note its name and the errors before and after disconnection. If several servers disconnect when the screen locks, focus on system background policies. An app session expiring can also look like a disconnect, especially when it asks you to sign in again. Check the app session, and don’t enter your password into an unfamiliar pop-up.

In your ticket, say whether the disconnect happens in the foreground, in the background, or after waking from sleep; whether you need to reconnect manually; and whether the regular network also dropped. Include log excerpts from before and after the event, not just the final error. Redact subscription links and access credentials if they appear in the logs. For restrictions on a managed device, contact your administrator. For repeated disconnects on a particular server and network, support can investigate using the server details.

Subscription import and update failures

A subscription link gives your client access to the server configurations available to your account. It isn’t an ordinary website address or something to share publicly. When an update fails, first check whether the client couldn’t retrieve the content or retrieved it but couldn’t parse it. The first may involve the network route, link status, or account permissions; the second may involve the content format or client compatibility. Deleting the existing configuration and importing it again could remove servers that still work, so keep its name and the error message first.

Check the subscription source in the panel

Open the user panel, confirm the current account and subscription status, then use the panel’s import or copy option. Don’t look for subscription links in chat history, public posts, or unfamiliar conversion sites. When copying, check for extra spaces, line breaks, or punctuation, and don’t paste explanatory text with the link. If the panel offers different options for different clients, choose the one that matches your client rather than assuming similar-looking links are interchangeable.

If the panel opens but the client times out while updating, it may be using a different network route to fetch the subscription. Some clients let you choose whether to update through the current proxy or your regular network; check the client’s instructions. Don’t rely on a configuration that’s completely unusable to fetch its own update, creating a recovery loop. Try again on a trusted network without changing other settings. The exact update option depends on the client; don’t guess at proxy addresses in system settings.

Identify the returned content and parsing error

A parsing error doesn’t necessarily mean the subscription content is damaged. Sometimes the client retrieves a sign-in page, network authentication page, or error page instead of a configuration. Check whether the error mentions a format, field, or authentication issue, and confirm that any network access sign-in is complete. Don’t post the full response on a public forum or submit your subscription to an unfamiliar online parser. If you need a screenshot, capture only the error and redact private parts of the link.

If your client supports importing the subscription but can’t recognize certain fields, check that the client is maintained and view the options for your platform in the client section of the user panel. Don’t force the configuration to parse by editing unknown fields; successful parsing doesn’t guarantee that routing, DNS, or outbound behavior is correct. If you’ve edited the configuration manually, separate the service-provided content from your own override rules so you don’t mistake a local customization for a subscription issue.

Check which configuration is active after an update

“Update successful” only confirms that the client completed the update. Check that the newly updated configuration is selected. Devices may keep multiple configurations with similar names; if the old one is still active, the server list may not change as expected. Confirm the selected configuration, server, and connection status, then test a website. If a manually selected server no longer appears in the current list, choose from the available options rather than copying an old entry to keep an outdated name.

Monthly plan data resets each month on the activation date. Mid-cycle upgrades are prorated based on the remaining days. If you have questions about your balance or billing period, check your status in the panel and refer to the plan details. Don’t rely on outdated text cached in the client to determine your current benefits. Data add-ons don’t expire, but they can still run out. Updating a subscription doesn’t change your plan or restore data that’s already been used.

If you think your link has been exposed, reset it in the panel if that option is available, then update your own clients on each device. If you can’t find a reset option, contact support. Don’t assume a reset will immediately end every existing connection; follow the panel’s instructions. For more about getting, importing, updating, and protecting links, read the complete guide to subscription links. When asking for help, provide the client name, how you retrieved the link, the error type, and whether you can access the panel. Don’t send full credentials.

One app isn’t using the proxy

If a browser works on the same device but one app doesn’t, check whether its traffic is being routed before changing the subscription. The app may ignore the system proxy or use its own network settings, background process, or transport method. Note the app name, the feature you’re using, and the error. Say whether the whole app fails to load or only sign-in, images, voice, or syncing. Different features may use different domains; a working home page doesn’t prove that every request follows the same route.

Check routing in the request logs

Open the connection log or request history in your client, then repeat the action that fails. Check whether a request from the app appears, which rule matched, and which outbound server was used. If there’s no record, check the traffic-handling mode and the app’s own proxy settings. If the request follows the regular network, review the routing rules. If it uses the expected outbound server but still fails, check the server and destination service. Don’t infer the exit location from the app’s displayed region or language; those may come from account preferences.

Rule order can determine where a request goes. A broad direct-connection rule may match before a later rule for a specific domain, preventing it from taking effect. Read the current configuration’s rule descriptions, then use a supported override method instead of editing the subscription itself and losing your changes on the next update. Add rules only for confirmed domains or processes. Don’t permanently send every unknown request through one outbound server just to fix a single app without considering the impact.

Check the system proxy and virtual interface separately

A system proxy works for apps that follow proxy settings. A virtual network interface can handle a broader range of traffic, but may require extra permissions and can interact with a corporate VPN, local network services, or other virtual interfaces. Whether to enable it depends on the client and device; it isn’t required in every setup. Save the current mode before testing a change, then check the app and confirm that resources which should connect directly—such as local printers or work services—are still reachable.

Some apps send requests through separate helper processes, so a rule for the main program alone may not be enough. Others read proxy settings at launch and don’t refresh them. After a change, quit and reopen the app rather than just closing its window. Terminal programs may use environment variables or their own configuration, unlike desktop browsers. In a managed development environment, check the project documentation before changing global settings that could affect other projects. Don’t mistake a terminal variable for a system-wide proxy.

Separate service restrictions from routing issues

AI tools and streaming apps may also check account region, access rights, or exit location. Routing a request through a proxy doesn’t guarantee that every feature will be available, and results may differ between web and app versions. Compare with the web version using the same account and check for a clear service notice, but don’t repeatedly switch regions instead of diagnosing the issue. For AI, see the ChatGPT guide. For streaming, see Disney+ regions and streaming reliability, and follow the destination service’s current rules.

To get help from support, provide the app feature that fails, its platform, the current traffic-routing mode, redacted rule match details, and the result in a browser. You can mention the domain, but don’t send a full request URL containing access tokens or upload the app’s entire session export. If the issue comes from the app’s own proxy settings, restore a known-good configuration first. Ask your administrator about routes to work resources. After fixing the issue, undo temporary global routing and test your usual apps again.

DNS issues and resolution paths

DNS resolves domain names to addresses used for connections. Websites may fail to load if name resolution fails, uses an unsuitable route, or differs between the browser and client. DNS is only one layer of a connection: resolving a domain doesn’t mean the destination port is reachable, and a change in the returned address doesn’t automatically indicate a problem. Consider the error, request logs, and behavior across apps rather than replacing all DNS settings as soon as you see an unfamiliar address.

Check which component handles DNS

DNS resolution may happen in the operating system, browser, client, or app. A browser using secure DNS may not follow system settings, and with remote DNS enabled in the client, a system lookup may not show the route used for the final request. Check the current settings and note which layers use separate DNS. Compare them one at a time. Don’t set different DNS policies in the system, browser, and client simultaneously; it makes results hard to interpret and can leave conflicting caches.

On Windows, use Command Prompt to look up a public example domain and check for resolution errors and which resolver was used. On macOS and Linux, use a system-provided terminal lookup tool if available. These commands don’t include account information or change network settings. They confirm whether a system lookup returns a result, but don’t fully test remote DNS in the client. If the tool isn’t available, don’t download an executable from an unfamiliar site; use software from a trusted source or the system’s graphical interface.

nslookup example.com

If a local terminal lookup works but the browser fails, check the browser’s own DNS settings and extensions. If the browser works but one app fails, check its cache and network settings. If the client log shows that a request didn’t get a usable address, check whether the configuration’s DNS policy matches the current traffic-routing mode. Don’t publish results after replacing the test domain with an internal address containing private identifiers. Company domains and resolver details can reveal information about your work network.

Clear the cache only after you identify the DNS path

After changing DNS settings, old cached results may remain for a while. First restart the app normally so it can create a new connection. If needed, clear the DNS cache as described in your operating system’s official documentation. Clearing the cache won’t fix a failed server or change the destination service’s regional policies. Don’t combine cache clearing, network resets, interface removal, and client reinstallation; this can affect other apps and make it impossible to tell where the problem started.

Some configurations use synthetic address mappings, where the client associates a domain with an internal address. The address returned by a system lookup may not be the destination website’s actual public address. Don’t copy such a result to another device or save it permanently in the hosts file. Manually pinning an address can bypass required domain rules and break certificates, content delivery, or site updates. If you’ve edited the hosts file, back it up, review the relevant entries, and undo only the changes that apply.

Resolve conflicts between local domains and encrypted DNS

Company intranets, home devices, and local network services may rely on a local resolver. Switching everything to remote DNS can make these resources unreachable. Keep local domains on the correct path and configure exceptions using options supported by the client. For managed networks, follow your administrator’s policy. More layers of encrypted DNS aren’t always better. Check whether DNS relies on a proxy connection that hasn’t been established yet, which could create a loop where DNS needs the proxy and the proxy entry point needs DNS.

For a DNS support ticket, include the public domain, exact error, operating system, current traffic-routing mode, and whether system and browser lookups match. Share only the relevant lookup output, redacting internal resolvers, personal paths, and subscription credentials. If the issue occurs only on a work network, check its policies with your administrator first. If it happens on a trusted network in multiple apps and is associated with a particular server, share those comparisons with support. Never disable certificate checks or install unknown certificates to troubleshoot DNS.

Device notices and useful support tickets

VPNShort allows unlimited simultaneous devices and supports Windows / macOS / iOS / Android / Linux. If the client says “device limit exceeded” or shows a similar message, don’t assume your plan has a device limit or remove other devices right away. The message may come from an old configuration, another account, a client feature, or a third-party integration. Save the exact wording and where it appeared: the user panel, a system prompt, or the client itself.

Check the account and configuration first

Multiple devices can end up with configurations that have similar names. Check the configuration name, source, and account status on each device to confirm they all use the same active subscription, not an old configuration from a previous test. You don’t need to send the full link to a group chat to compare it; retrieve it from your own panel and check each device locally. If only one client shows the message while other platforms work, save that client’s exact error rather than repeatedly resetting the account.

Unlimited devices refers to the simultaneous device policy; it doesn’t mean each device gets a separate data allowance. Check data usage and balance in the panel, and don’t add together cached balances from multiple clients using the same subscription. If all devices stop working, check your plan status and data first. If only one device fails, follow the permissions, subscription, or routing steps. Check the rules for monthly plans and data add-ons on the plans page. Details on the 30-day no-questions-asked refund are in the Terms of Service.

When to stop troubleshooting and submit a ticket

If you’ve checked your network, account status, configuration updates, and an alternative server but the issue still occurs consistently, further random changes are unlikely to help. Save the current state and contact support, or open a ticket in the user panel. Billing status, subscription access, and server-side issues are also good reasons to submit a ticket. For managed devices, organization-installed certificates, or failed local network sign-in, check with the relevant administrator first so separate responsibilities don’t get mixed together.

Make the ticket title describe the symptom and scope, such as “Browser can’t connect after desktop wakes from sleep,” rather than “It doesn’t work.” In the message, state the expected and actual results, then list the steps to reproduce, date and time with time zone, operating system, client name, server name, and network type. End with what you’ve already tried and the result of each test. If the issue is intermittent, explain how it relates to screen locking, network switches, or a particular time of day. If it’s already resolved, note the last change you made before it recovered.

Redacting logs and screenshots

Capture only the relevant window. Hide account passwords, full subscription links, access tokens, private payment details, and unrelated app content. Include only the log excerpts needed from before and after the issue; don’t send an entire browser profile or unchecked configuration. Domains can help with diagnosis, but full URLs with query parameters may contain credentials, so remove private parameters first. Don’t post support materials in public comments. If credentials have already been exposed, reset them through the panel if possible before continuing to troubleshoot.

While waiting for a reply, keep the configuration that reproduces the issue and avoid making a series of major changes. If you need to restore your workflow temporarily, save a separate test configuration and note what changed. When support suggests a test, report the result of each step rather than just saying “it’s still the same.” Changes to the error or affected scope can guide the next steps. Don’t give remote access to someone you don’t trust or enter your account credentials on an unfamiliar page without clear authorization. For safer account and subscription link handling, see the account and subscription link security guide.

After the issue is fixed

Once the connection works again, test your usual browser, destination apps, local network resources, and background use. Undo temporary global routing and unrelated DNS changes. Confirm that your active configuration still updates, then remove old configurations only when you’re sure you no longer need them. Keep a brief note of what fixed the issue and under what conditions, but don’t save passwords or subscription credentials. If the problem returns, check whether the same conditions apply instead of copying every previous change. For a new setup, follow the Quick Start Guide.