VPN Server Unreachable: Troubleshooting

"Server unreachable", "server not responding" and "connection timed out" are three ways of saying the same thing: your device asked, and nobody answered. The frustrating part is that the error does not say where on the road the question got lost. Between your phone and a VPN server sit your own device, your Wi-Fi, your router, your internet provider, the wider internet and finally the server. A fault in any of those can produce the same sentence on your screen.

This article treats the error as a tracing exercise. Instead of changing random settings, you will test one layer at a time, starting at your own device and moving outward. Each test gives a yes or no answer and tells you whether to keep going or stop and act. If you want the general fixes for a VPN that will not start, VPN not connecting? Step-by-step fixes is the companion guide. This piece goes deeper on the particular case where the server seems to be silent.

First, confirm it really is "no answer"

Before you test anything, check that you are looking at the right error. Three messages get confused all the time.

Message	What happened	Where the fix lives
Server unreachable, timed out, no response	Your request got no reply	Network path (this article)
Authentication failed, invalid credentials	The server replied and refused you	Login details and pass validity
Connected, but no websites open	The tunnel is up, traffic does not flow	DNS, routing, or the site itself

If the app says authentication failed, stop here and fix the login, not the network. If it says connected but pages do not load, the tunnel exists and VPN connected but no internet is the relevant guide. Only continue with this article when the app waits and then reports a timeout or an unreachable server.

Also note how long the wait was. An instant failure, within a second, usually means the device refused to even send the request, for example because of a missing permission, no network at all or a very basic local block. A failure after thirty seconds or more means the request left your device and nothing returned. That difference decides where you start.

Tracing the path in six layers

Layer 1: your own device

Start closest to home. The question is whether your device has a working internet connection at all, independent of the VPN.

1. Turn the VPN off or leave it disconnected.
2. Open a plain website in a browser, and a second one from a different company.
3. Open an app that needs the internet, such as a map or a messenger.

If nothing loads, your problem is not the VPN. Look at airplane mode, mobile data being off, Wi-Fi joined but with no internet, or a data plan that has run out. If ordinary pages load, your device is online and you can move on.

Next, check the less obvious device-side causes:

• Date and time. A wrong clock can break the encrypted handshake and look like a timeout in some apps. Set time to automatic.
• Battery saver and background limits. Some phones freeze apps that run in the background. Allow the VPN app to run without restrictions in the battery settings.
• Another VPN or security app. Two apps cannot both own the VPN slot on a phone. Turn off any other VPN, DNS-changing or "secure connection" app, then try again.
• Stale app state. Close the app fully and reopen it. If that fails, restart the device. A restart is boring but resets half-open network sockets.

Layer 2: your local network

Now test the network you are on, still without caring about the VPN server. The key comparison is whether the same device works on a different network.

1. Switch from Wi-Fi to mobile data, or from mobile data to Wi-Fi.
2. Try the VPN again.

Interpret the result:

• Works on one network, fails on the other. The failing network is the cause. Continue with the router and network checks below.
• Fails on both. The local network is probably not the cause. Skip to the DNS and port layers, then the server layer.
• Works on neither, even for ordinary websites. Return to layer 1.

For a home or small-office Wi-Fi network, the usual repairs are in this order: move closer to the router, restart the router by unplugging it for thirty seconds, check whether other devices can reach websites, and look for a firmware update or a recently changed setting. Routers that have been up for many weeks sometimes run out of working connection slots, which shows up as new connections timing out while old ones stay alive.

For public and shared Wi-Fi, check for a captive portal: the page that asks you to accept terms or enter a room number. Until you finish it, the network blocks most traffic, including your VPN. Open any plain http page, such as a simple news site without encryption, to trigger the login page, complete it, then connect the VPN. Hotels, airports and campuses may also limit which kinds of traffic are allowed. In that case try mobile data for the VPN connection, or ask the network operator what is permitted. The guide on using a VPN on hotel Wi-Fi covers this situation in more detail.

Layer 3: DNS and name lookup

Many VPN apps do not connect to a number. They connect to a name, and that name must be turned into an address first. If that lookup fails, the app has no address to call and reports that the server cannot be reached. The signs are specific: ordinary websites may still load from cache or other lookups, but the VPN fails immediately or after a short wait, and it fails on one network but works on another.

How to test it:

1. On a computer, open a terminal or command prompt and run a lookup of any well-known site. If it prints an address, name lookup is basically alive on that network.
2. Try changing the network's DNS to a public resolver temporarily in your device's Wi-Fi settings, then retry the VPN app.
3. Restart the router, since many routers act as the DNS forwarder for the whole home.
4. Turn off any ad-blocking or filtering DNS on the router or device for one test, since a filter may block the name the app needs.

If you want to know why a single name lookup can fail while others work, how DNS works explains the chain from your device to the answer, and Cloudflare's learning pages on DNS give a good second view. This is also the point where the DNS leak article is not relevant. A leak is about where your lookups go once the VPN is up. This layer is about the lookup needed to bring the VPN up.

Layer 4: ports and the type of traffic

VPN traffic travels over particular ports and uses particular kinds of packets. Networks sometimes allow web browsing and block or throttle other traffic. Home networks rarely do. Offices, schools, hotels and some public hotspots sometimes do, usually for ordinary management reasons.

The telltale pattern is this: websites load without trouble, the VPN times out, and the same device connects on mobile data. Then the network, not your device or the VPN server, is making the difference.

What you can do on your own side:

1. Make sure your device does not run another firewall or security suite that is filtering the VPN app. A temporary pause for one test shows whether it is involved. Turn it back on afterwards.
2. Look for a router feature that filters outbound traffic or "blocks unknown applications" and review it. Home routers sometimes include parental or security filtering.
3. If the app offers a different connection method in its settings, try one. Otherwise leave the app defaults unchanged. We do not recommend adjusting protocol settings without a reason, since the default is usually the one that fits best.
4. Use mobile data when the shared network does not permit the connection, and respect the network operator's rules. If you rely on the VPN for work, ask the network administrator whether VPN traffic is permitted.

Do not try to get around restrictions that a school, employer or network owner has set deliberately. If a network does not allow VPN traffic, the practical answers are to use another connection you are entitled to use, or to ask the owner. A deeper article on firewalls is a better place for a firewall you control yourself.

Layer 5: path quality, MTU and flaky connections

Sometimes the server is reachable in principle, but your packets get lost on the way, so the handshake keeps timing out. This is common on weak mobile signal, crowded Wi-Fi, and links with large delay. High latency and packet loss do not always show up as slow browsing, because web pages tolerate retries, while a handshake with a strict timer does not.

Symptoms and quick checks:

• Signal. Walk closer to the router or move to a spot with a better mobile signal. Retry in the new place.
• Congestion. Evenings in shared buildings are busy. Try again at a quieter time to see whether the error follows the clock.
• Large packets dropped. Some networks cannot carry the full packet size of a VPN, because the tunnel adds its own header. The result can be a connection that starts, then stalls. The idea behind it is path MTU, described in RFC 1191. Most users never need to touch this, and if you suspect it, a support contact with details is better than guessing numbers.
• Weak upstream. An upload that is saturated by a cloud backup or a big upload makes the VPN request wait in line. Pause heavy transfers and test again.

For a better understanding of the delays involved, Cloudflare's explainer on latency is a plain introduction, and why internet speed changes with a VPN covers what extra distance does to throughput. Our guide on improving VPN connection stability lists adjustments for unreliable networks.

Layer 6: the server or the account

If you have passed the first five layers, you are left with the part you do not control. Two things are possible: the particular server you chose is overloaded or offline, or something about the account stops the request.

Use these tests:

1. Try a second location. Select another place in the app and connect. If it works, the first server was the problem. Use the other one for now.
2. Try a different time. Wait ten minutes and retry the original location.
3. Check the pass. Open My Pass and confirm that the pass is active. An ended pass usually produces a login refusal rather than a timeout, but it costs ten seconds to check. See how your VPN pass expires.
4. Check the app version. Install the current version from the official links on the download page.
5. Compare two networks. If every location fails on two different networks, and the pass is active, it is time to contact support.

When you write to support, include what the app said word for word, the time you tried including your time zone, the network type (home Wi-Fi, mobile data, hotel), the device and the app version, and which locations you tested. That information lets support check the server side quickly. Do not include your password in a message.

A worked example

Pim is working from a serviced apartment. At noon her VPN app reports that the server cannot be reached. She follows the layers.

• Layer 1. With the VPN off, ordinary sites load, so the device is online. Time is automatic.
• Layer 2. On mobile data the VPN connects after about ten seconds. On the apartment Wi-Fi it times out. The Wi-Fi is the difference.
• Layer 3. Name lookups for popular sites work on the Wi-Fi, so DNS is probably fine.
• Layer 4. Reading the building's welcome sheet, she notes that guests share one network managed by the building. She asks the front desk whether VPN apps are allowed. The answer is that a port is restricted on the guest network, and they offer a second network for residents.
• Resolution. She joins the resident network, and the VPN connects. She did not touch the pass, the app or the server location.

Notice that it took four tests and no reinstalling. Tracing the path was faster than guessing.

A short decision list

• Instant error, nothing else works either: check airplane mode, data and Wi-Fi.
• Slow timeout, works on mobile data but not on Wi-Fi: router, captive portal or network rules.
• Timeout on every network, one location: try another location, then wait and retry.
• Timeout on every network and every location: update the app, check the pass, contact support.
• Connected but nothing loads: that is another problem; use the guide for it.

Common mistakes

• Reinstalling the app first, which resets the information that would help you.
• Changing many settings at once, so you cannot tell what helped.
• Assuming the server is down because one location failed.
• Forgetting the captive portal on a hotel, cafe or airport network.
• Leaving a firewall or filter switched off after a test.
• Trying to defeat a network's rules instead of using another connection or asking the owner.

Summary

Server unreachable means a request got no answer, so the useful move is to trace the path: device, local network, name lookup, ports, path quality and finally the server or account. Compare the same device on two networks and two locations, change one thing at a time, and keep a note of the times for support. Most cases end at layer 2, a router, a captive portal or a network rule.

When you need a fresh pass to test with another connection, you can see the options on the pricing page.