Setup

VPN Connected But No Internet: A Five-Minute Diagnosis for Any Device (2026)

8 min read

“Connected” is a claim about one thing only: that the client finished negotiating a tunnel. It says nothing about whether traffic can use that tunnel, whether anything is routed into it, or whether the answers coming back fit through it. That gap is where this entire problem lives, and it is why the usual advice — switch server, restart, reinstall — sometimes works and never explains anything.

There are three causes, they need different fixes, and five minutes separates them. Do not skip to the fix.

Step one: address before name

Every diagnosis starts by asking whether packets move at all, using an address so that name resolution cannot confuse the answer.

  • Windows: ping 8.8.8.8 then nslookup example.com
  • macOS and Linux: ping -c4 8.8.8.8 then dig example.com (or resolvectl query example.com on Ubuntu)
  • Android and iOS: no terminal, so use the equivalent — open https://1.1.1.1 in a browser, which is an address, then open any ordinary site, which is a name
Address fails → routing. Address works, name fails → DNS. Both work, pages still stall → MTU. Three branches, and the rest of this article is one section each.

Branch one: the address does not answer

Nothing is reaching the far side. Either no route points into the tunnel, or the tunnel exists but the far side is not listening any more.

  1. 1Check where the default route points. Windows: Get-NetRoute -DestinationPrefix 0.0.0.0/0. macOS: netstat -rn | grep default. Linux: ip route get 1.1.1.1.
  2. 2If it still points at your ordinary adapter, the client built a tunnel and never claimed the traffic. Reconnect; if it repeats, the client's routing is broken rather than the network.
  3. 3If it points at the tunnel and nothing answers, the server address may have changed. Re-import your configuration or subscription link before assuming anything else — see how subscription links work.
  4. 4Test from a phone hotspot. If it connects there, the network you were on is filtering the protocol, and that is a different article: why QUIC and UDP get blocked.

Branch two: addresses work, names do not

The most common branch by a wide margin, and the one people almost never diagnose correctly, because the tunnel is genuinely fine. Queries are going to a resolver that is unreachable from inside it, or to one that is reachable and should not be used.

  1. 1Windows: ipconfig /flushdns, then Get-DnsClientServerAddress to see which resolver each adapter holds.
  2. 2macOS: scutil --dns | head -30 — the first resolver should belong to the utun interface.
  3. 3Linux: resolvectl status — the tunnel interface needs DNS Domain: ~. to own the whole namespace.
  4. 4Android: Settings → Network & internet → Private DNS → Automatic. A fixed DNS-over-TLS hostname competes with the tunnel and fails on networks that block it.
  5. 5iOS: turn off iCloud Private Relay while testing, then reconnect.

If names resolve but the answers are wrong for your apparent location, the tunnel is carrying packets while your queries escape around it. That is a DNS leak — same symptom family, different consequence, and worth understanding once.

Branch three: everything resolves and pages still stall

Recognise it by its shape rather than by testing: small pages load, large ones stop halfway, downloads die at a random percentage, terminal sessions freeze the moment output gets long. Nothing is broken. Packets that fit before the tunnel added its headers no longer fit after, and the network is not reporting it back.

  1. 1Find the ceiling. Windows: ping -f -l 1400 8.8.8.8. Linux: ping -M do -s 1400 8.8.8.8. macOS: ping -D -s 1400 8.8.8.8. Lower the number until the errors stop, then add 28.
  2. 2Set it on the tunnel interface, or better, in the VPN client's own MTU setting so it survives reconnects.
  3. 31380 is a sensible starting value for most tunnels on most home connections.

Full explanation, including why the symptom is “some sites” rather than “all sites”, is in MTU and fragmentation.

Three things that produce this symptom without being a fault

  • A kill switch doing its job. The tunnel dropped, the switch blocked everything, and the interface still shows the last state it knew. It looks identical to a dead network. What a kill switch actually protects.
  • A captive portal. Hotel and airport Wi-Fi holds you at a sign-in page. Connect the VPN before accepting it and neither the portal nor the internet can load. Disconnect, sign in, reconnect.
  • Split tunnelling you configured and forgot. One app fails while everything else works because that app was excluded — or included — on purpose. Split tunnelling.

Then go to your platform

The branches above are the same everywhere. What differs is which command shows you the state and which platform-specific fault is common this year — and in 2026 there are three big ones worth knowing about before you start guessing.

  • Windows 11 — error codes, WAN Miniport after a feature update, WireGuard handshakes.
  • Android — the always-on fault in Android 16 that Google has not fixed, plus Private DNS and battery optimisation.
  • iPhone and iPad — the legacy algorithms iOS 26 removed, and on-demand reconnect loops.
  • macOS — unapproved system extensions and a Tahoe interface-ranking bug that leaks DNS.
  • Linux — systemd-resolved, split DNS and resolvers left behind after a crash.

Frequently asked

Why does my VPN say connected but there is no internet?

Because connected only means a tunnel was negotiated. Three things can still stop traffic: nothing is routed into the tunnel, name resolution is pointed at a server the tunnel cannot reach, or packets are too large to pass once tunnel headers are added. Ping an address first, then resolve a name — those two results tell you which of the three you have.

Does switching VPN servers actually fix this?

Sometimes, and that is the problem with it as advice. Switching servers changes the address, the route and often the protocol all at once, so when it works you learn nothing about which of them mattered. It is worth trying after the two diagnostic commands, not instead of them.

Why do only some websites fail while others load fine?

Almost always MTU. Small responses fit within the reduced packet size a tunnel leaves available; large ones do not, and when the path cannot report that back, the connection stalls rather than failing. Sites that load are the ones whose responses happen to be small.

Should I disable IPv6 to fix VPN connectivity?

It often works and it hides the real fault, which is a tunnel that carries IPv4 while leaving IPv6 outside it. That gap is a leak whether or not it also breaks your browsing. Prefer a client that handles IPv6 — by routing it or blocking it — over switching the protocol off across the whole system.

Is it my VPN, my device or my network?

Two tests answer it in a minute. Tether to a phone: if the tunnel works there, the network you were on is the problem. Then try the same account on a second device on the original network: if that also fails, it is the network or the server rather than the device you started with.

Did this help?

Nothing follows from the answer; only we see it.

Send this to someone

Useful to anyone with the same problem.

TelegramWhatsAppVK