First, establish what is actually broken
Disconnect the VPN and load any website. If nothing loads, the VPN is not your problem — you have no internet, or a kill switch is still blocking traffic from a previous session. A stranded kill switch looks identical to a dead connection and is the single most common false alarm.
If the internet works with the VPN off, you have a genuine connection failure and the rest of this page applies. Note the exact error the client shows before you change anything; "authentication failed" and "connection timed out" have entirely different causes and the client usually distinguishes them.
Change the server, then the protocol
Try a different city, then a different country. Individual servers go down, get overloaded, or have their addresses blocked by the network you are on. If one server works and another does not, nothing is wrong with your setup.
If every server fails, change protocol. WireGuard uses UDP, and plenty of networks — hotels, schools, corporate guest Wi-Fi, some mobile carriers — block or throttle UDP on non-standard ports. Switching to OpenVPN over TCP port 443 gets past filtering that works by port number, because blocking 443 outright would break the web. It does not get past deep packet inspection, which fingerprints OpenVPN regardless of port - that needs the provider’s obfuscated mode.
If TCP 443 connects and WireGuard does not, that is the answer: the network is filtering, not your client. Leave it on TCP while you are on that network and switch back for speed elsewhere.
- Different city, then different country
- WireGuard → OpenVPN over TCP 443, which survives port-based filtering but not deep packet inspection
- If the provider offers an obfuscated or stealth mode, that is the next escalation
The four causes that account for most of it
A captive portal you never signed into. Hotel, airport and café networks intercept traffic until you accept their terms, and a VPN connecting before you have done so will fail with a timeout. Disconnect, load any plain HTTP page to trigger the portal, sign in, then reconnect.
A stale credential. Changing your account password invalidates the client’s stored token on several providers, and the resulting error often says "connection failed" rather than anything about authentication. Signing out of the app and back in fixes it.
Another network tool holding the adapter. A second VPN, some antivirus suites with their own "secure connection" feature, and certain corporate endpoint agents all install network filters that conflict. Only one can own the tunnel.
A firewall or security suite blocking the client outright. This is more common after the security software updates than after the VPN does, because the update resets its rules.
Avoid
- Reinstalling the client as a first step — it rarely helps and loses your settings
- Turning off the kill switch to "make it work"; that removes the protection, not the fault
- Changing DNS settings manually before you have established the tunnel connects at all
When it connects but nothing loads
This is a different fault and it usually means DNS. The tunnel is up, but name resolution is failing, so nothing resolves and everything looks dead. Try loading a site by its raw address rather than its name — if that works, DNS is the problem.
The usual fixes are switching protocol, toggling the provider’s own DNS or ad-blocking DNS feature off, or flushing the local resolver cache. On Windows, IPv6 is a frequent culprit: if the tunnel carries only IPv4 and the client does not block IPv6, some lookups go nowhere.
If small pages load but large transfers or particular sites hang, suspect MTU. Tunnelled packets carry extra overhead, and when the result exceeds what the path allows they are dropped silently - which is size-dependent, not time-dependent. Drop the client’s MTU to 1280, the IPv6 minimum that always passes, to confirm the cause, then raise it back toward 1420 to find the usable maximum. A connection that works for minutes and then dies is a different fault: an idle timeout, a NAT table expiring, or a DHCP lease renewing.
Is the provider down, or is it you?
Before spending an hour on your own configuration, check the provider’s status page and whether other people are reporting the same thing. Outages happen, and no amount of local troubleshooting fixes somebody else’s infrastructure.
A useful signal: if the client cannot even fetch the server list, the problem is more likely at their end or with your DNS than with the tunnel itself, because that request happens before any tunnel exists.