your vpn says connected. nothing loads.

vpn connected but no internet: which half is broken

almost every case is one of two: names are not resolving, or packets are going nowhere. in a browser they look identical — a page that never loads — and underneath they have nothing in common. run these two lines in Terminal before touching any settings.

1. ping 1.1.1.1 — this skips names entirely and talks to an address.
2. ping apple.com — this needs a name resolved first.
3. read the result: both fail → routing or the server. the first works and the second does not → dns.

if the address answers and the name does not, stop reading about routing tables: it is dns, and the fix is three settings down this page. if neither answers, the tunnel is not carrying traffic, and no amount of dns fiddling will change that.

is the tunnel actually carrying anything?

«connected» is not a measurement. run scutil --nc status "name" (the name is the one from System Settings) and you get Status : 2 and the word Connected for a tunnel moving thirty megabytes a minute and for one that died an hour ago. there is no field in that output for whether anything is moving at all.

the only built-in way to answer it is to measure twice: scutil --nc statistics "name", wait five seconds, run it again. on a live tunnel the counters climb — here BytesIn went 33,943,820 → 35,077,020 across those five seconds. on a dead one they sit still.

ifconfig sets the same trap. a Mac keeps several utun interfaces whether or not a vpn is running; Handoff and AirDrop hold their own. eight of them listed is not eight tunnels. the real one has an IPv4 address, and route -n get default names it.

if neither ping answers and the counters do not move, rule out the connection underneath before blaming the tunnel: test your internet speed without installing anything

the built-in fixes for a vpn with no internet, in order

all of this is macOS's own and needs no app. work down the list — it is ordered by how often each turns out to be the answer, not by how clever it is.

1. disconnect and reconnect the vpn once. a tunnel that died with the laptop lid is the most common case by a distance, and the only reason «turn it off and on again» earns its reputation here.
2. check the dns the tunnel handed you: System Settings → Network → your connection → Details → DNS. a vpn usually pushes its own resolvers, and an empty list there — or one pointing inside the tunnel that just died — is the whole fault.
3. flush the resolver cache in Terminal: sudo killall -HUP mDNSResponder. answers cached from before the tunnel came up survive a reconnect and keep pointing at the wrong place. the sudo dscacheutil -flushcache half that every guide pairs with it is a 10.6 leftover — harmless, and not what Apple documents now.

the commands per macOS version, from Apple: reset the dns cache in os x

why the names stop resolving first

run scutil --dns and look at the top. with a tunnel up, resolver #1 is the vpn's own: nameserver[0] : 198.18.0.2, with if_index : 25 (utun7) under it. the binding is the point: that resolver is reachable only through the interface the vpn made.

so when the tunnel stops carrying traffic, the first resolver is still first and now unreachable. names stop resolving while the Wi-Fi icon, the router and every address on your own network look as healthy as they did a minute ago. that is why this reads as a browser problem.

if the tunnel dies when the Mac sleeps rather than at random, that is a different fault with a different fix: reconnect a vpn that drops after sleep

1. check whether everything is meant to go through the tunnel at all: in a built-in configuration that is «send all traffic over the VPN connection» under Options. with it off, half your traffic uses the tunnel and half does not, and what broke is the half you cannot see.
2. look at the order of your non-vpn services: System Settings → Network → the ⋯ menu → Set Service Order. it does not move the vpn and cannot: Apple documents that vpn connections are not reorderable, because they already outrank everything else. what it does set is which connection carries the tunnel. a Mac on Wi-Fi and Ethernet at once, or tethered to an iPhone, may be tunnelling over the link you are not thinking about.
3. make a fresh network location: same ⋯ menu → Locations → Edit Locations → +. it drops accumulated dns, proxy and route settings without touching anything else — the fastest way to rule out «something a vpn client left behind three installs ago».

on service order and why the vpn is not in it: change the order of the network services your Mac uses

read this first: hop does not fix this

hop does not repair dns, does not edit routes and does not talk to your vpn provider. if you came for a repair tool, the list above is the repair, and it is free.

what hop changes is how long you spend not knowing. every case above starts the same way — you assume the tunnel is fine because the client says «connected», and you spend twenty minutes on the browser, the Wi-Fi and the router. the tunnel was dead the whole time.

how hop spots a connected vpn with no internet

hop lists every vpn your Mac knows about — the list comes from System Settings, so whatever brand you use is already there. while a tunnel is up, a small dot sits on the menu bar icon.

• green — the tunnel is up and traffic is going through it.
• orange — the tunnel is on, and nothing is coming back through it. this is the state that costs people twenty minutes, and it is visible with the panel closed.
• the panel marks the row it means, so with several configurations you know which one died.

that is the one thing the free route does not give you. the two measurements above answer the same question — but only once you already suspect the tunnel and know the command exists. the dot answers it while you are reading something else.

the tunnel is held by the system, not by hop, so quitting the app does not drop your connection. clicking a name opens that vpn's own window when you need it. the dot can be turned off in settings; the switches keep working without it.

the switch itself, and what else it does with the list of tunnels: vpn switcher

why a dot on a menu bar icon is the whole interface here: what macOS 26 changed for menu bar apps

no internet after you disconnect the vpn

close to half the threads about this are not about a connected vpn at all — they are about the minute after you turned one off. the tunnel is gone, Wi-Fi says connected, nothing loads. three things cause it.

the ordinary one is dns that never got put back: the client pushed its own resolvers on the way in and did not restore yours on the way out, so scutil --dns still lists a resolver that existed only inside a tunnel that is gone. flushing the cache and toggling Wi-Fi off and on rebuilds the list from the interface itself. if it happens every time, the client is not cleaning up after itself.

how people describe this in their own words, on Apple's developer forums: cfnetwork no internet after vpn connection

the kill switch that outlived the tunnel

most clients ship a kill switch: a rule that blocks traffic outside the tunnel so nothing leaks if it drops. it does exactly that, including when the tunnel dropped because you wanted it to. the tell is specific: the internet returns when you quit the client entirely, but not when you press disconnect.

there is no macOS setting for this, and looking for one is where the evening goes. the rule belongs to the client, and so does the switch — filed under «network lock», «firewall» or «block traffic if the vpn disconnects».

why network drives vanish on a work vpn

a corporate tunnel carries only what it was told to carry, and what stays outside it is written down rather than guessed at. scutil --nc status prints an ExcludedRoutes block — here it names 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 against en0, and route -n get 192.168.1.1 confirms it: that traffic leaves over Wi-Fi and never enters the tunnel.

read your own dump before deciding a share is broken. if the range your file server lives in is excluded there, the tunnel is not carrying it by design, and no reconnect will change that — the answer is your admin.

when the vpn still has no internet

• the server is the problem, not your Mac. pick another server or another country in the provider's own window — if a different one works instantly, nothing on your machine was ever broken.
• two vpn clients installed at once fight over the routing table. remove the one you no longer use — properly, with what it left behind, not by dragging it to the trash.

what a vpn client leaves behind, and how to take it out: uninstall an app with its leftovers

the tool that does it: app uninstaller

frequently asked questions

why does the vpn say connected when there is no connection?

«connected» describes the moment the tunnel was established, not its current state. once it is up, most clients stop checking: if the server stops answering or the route breaks, the client goes on showing the same word until you make it reconnect.

how do i tell a dns problem from a routing problem?

ping 1.1.1.1 and then ping apple.com. the first skips names entirely. if the address answers and the name does not, it is dns. if neither answers, packets are not leaving through the tunnel at all.

how do i know if the tunnel is actually passing traffic?

scutil --nc status has no field for it — it says Connected either way. run scutil --nc statistics "name" twice with a few seconds between the two, and compare BytesIn. if it has not moved, nothing is coming back through the tunnel.

why is there no internet after i disconnect the vpn?

usually the client left its own dns resolvers behind instead of restoring yours: flush the cache and toggle Wi-Fi off and on. if the connection returns only when you quit the client entirely rather than when you press disconnect, it is the kill switch still blocking traffic, and it is turned off inside the client.

will restarting the Mac fix it?

usually yes, and that is the problem: it destroys the evidence, so the same thing happens again next week. a reconnect and the two pings take less time and tell you what broke.

does hop work with my vpn provider?

hop reads the list from System Settings, so any vpn your Mac knows about appears on its own — a client installed yesterday shows up without an update, one you removed disappears. there is no list of supported brands because there is nothing brand-specific to support.

does hop keep the tunnel open?

no, the system does. hop switches it and shows its state; quitting hop does not drop the connection.

the tool behind this

done with vpn

other things people do

• the Mac woke up. the tunnel did not.vpn switcher
• your vpn says connected. is anything actually going through it?vpn switcher
• you copied over the thing you neededclipboard history