Wi-Fi Says Connected, Nothing Loads: Stale Mac Resolvers

Ping a literal address and it answers. Open a site by name and nothing happens, while the network icon insists the connection is fine. On a Mac that has just joined a VPN, that combination almost always means lookups are aimed at a server which is no longer reachable, not that the network is down. The addresses were pinned to the Wi-Fi service at some earlier point and nothing has removed them since. Diagnose by elimination, then delete the pinned entries.

The repair is a deletion rather than a flush, and the difference matters because the commands most people try first do something else entirely.

Connected is a statement about the link

macOS keeps a resolver configuration per network service. Values from DHCP are one source, values typed in are another, and values pushed by a profile or written by a client are a third. The pinned ones outrank what the network offers, and nothing in the stack revalidates them. A server that has gone away therefore stays in the list until a human removes it or the service is rebuilt from scratch.

That is why a tunnel completing its handshake changes nothing about a lookup that was already misdirected. The VPN added a resolver; it did not audit the one that was failing.

Separate names from packets

Reach a host by literal address first. When that loads, packets are fine and the resolver owns the fault. When it does not load, stop right there and treat the problem as a routing one, because DNS changes will only add a variable to an already confusing picture.

A name failing while the matching address succeeds is the fingerprint. Note the scope as well: everything failing points at a broken global entry, while only hosts inside the tunnel failing points at a different owner and a narrower fix.

Delete the pinned servers

In Network settings, open the Wi-Fi service's details and switch to the DNS tab. Remove each server row, confirm the change, then look through search domains for values you never added. Leave the list empty, reconnect the service, and confirm that the address supplied by DHCP reappears on its own. An empty list is the temporary state that proves the pinned values were the problem.

Older releases hide the same panel one level deeper, behind an Advanced button, with identical behaviour and the same result.

Read the state rather than the panel

scutil --dns | head -40 prints the resolvers macOS is actually using, grouped by scope, and a quick nslookup of a known internal name shows whether an answer arrives at all. Compare the two outputs: a clean panel with a stale server still listed means another writer owns that setting. That is a different bug with a different fix.

When both look clean and names still fail, the fault has moved elsewhere and you are no longer debugging DNS configuration.

Who keeps putting the entries back

Servers that return after deletion have a source. Check Device Management for a configuration profile, since profiles can carry DNS and are re-evaluated on their own schedule. Check the client's preferences for a set-DNS-on-connect option, and decide whether it still earns its place on this machine. If the VPN genuinely needs a private resolver, scope it to the domains it owns instead of writing into the global list that every future network inherits.

Record the intended resolver and the domains it should answer. After the next client update, verify one public name and one private name, which is faster than repeating the settings walk and catches the regression while the machine is still in your hands.

Anything else is maintenance theatre: commands that look deliberate, change nothing measurable, and leave the same broken lookup for the next person.