Clear the DNS cache on a Mac

Published 17 September 2026

Here are the two commands. Then the part most guides skip: your Mac is one of at least four caches between you and the answer, and flushing it cannot possibly help when the stale record is sitting in one of the other three. That is why people flush, see no change, and flush again.

The commands

If you arrived looking for how to flush DNS on a Mac, this is it. Clear DNS cache Mac and flush DNS Mac are the same operation under two names, and nothing else is required:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Run both. They do different jobs: the first clears the Directory Service cache. The second tells mDNSResponder, the process that actually resolves names on macOS, to drop what it is holding. Neither prints anything on success, which is unnerving the first time.

These are current for macOS Sequoia, Sonoma, Ventura, Monterey and back to El Capitan. If you have landed on an older guide telling you to use lookupd -flushcache, discoveryutil, or mDNSResponder -HUP on its own, those were for macOS versions that are long gone and the binaries no longer exist.

Check it actually did something

dscacheutil -statistics

The cache entry counts drop to nothing after a successful flush. It is worth one look the first time, because a mistyped command fails silently and looks exactly like a successful one.

Why flushing often changes nothing

A DNS answer is cached in several places on its way to you, and dscacheutil reaches exactly one of them:

Cache	Can you clear it?	How long it holds
Your Mac (mDNSResponder)	Yes: the commands above	Until flushed or TTL expires
Your browser	Separately, see below	Minutes
Your router	Only by rebooting it	Varies wildly
Your resolver (ISP, Cloudflare, Google)	No	The record's TTL

That last row is the one that matters. If you changed a DNS record ten minutes ago and its TTL is an hour, the public resolvers are still serving the old value and will keep doing so until the hour is up. Nothing you type on your Mac reaches them. You are not failing to flush: you are waiting, and the only question is how long.

Which cache is actually stale

This takes thirty seconds and saves the flush-and-hope cycle. Ask a public resolver directly, bypassing every local cache, and compare what it says with what your Mac believes:

dig @1.1.1.1 example.com +short     # Cloudflare, ignoring your Mac entirely
dig example.com +short              # what your Mac resolves through its own path

They differ, and Cloudflare has the new value: the stale copy is local. Flushing will fix it.
They agree, and both are wrong: the stale copy is upstream. Flushing is pointless; you are waiting on the TTL. Check what the TTL is and come back then.
Cloudflare is right but your ISP's resolver is wrong: you can route around it by switching your Mac to a public resolver.

Or check without the terminal. The DNS propagation checker queries Cloudflare and Google side by side from your browser and tells you whether they agree, and what TTL each is holding. If they show your new record and your Mac does not, the problem is local and flushing fixes it. If they still show the old one, no amount of flushing will help, which is the answer worth having before you start.

Open the DNS lookup

Your browser keeps its own cache

Frequently missed, and the reason a site still resolves wrongly in Chrome after a perfect system flush. Chrome, Edge and Brave maintain an internal DNS cache independent of macOS:

chrome://net-internals/#dns    →  Clear host cache
chrome://net-internals/#sockets → Flush socket pools

Flush the sockets as well. A pooled connection to the old address survives a DNS change, so the browser keeps talking to the previous server even once the name resolves correctly. Safari has no equivalent page and follows the system cache, so the commands above are enough for it.

What your Mac is actually using

scutil --dns | grep nameserver

Lists the resolvers in use, in order. Worth a look when flushing has not helped: a VPN client, a corporate profile or a "security" app may have inserted its own resolver, in which case you are being answered by something you did not choose and would not think to check.

When the answer is missing rather than stale

Flushing is for a wrong answer. If the name does not resolve at all, that is a different fault and a cache flush will not touch it. NXDOMAIN means the domain genuinely has no such record, which is not the same as a lookup failing, and the distinction decides where you look next.

If the name resolves but you still cannot reach the host, the problem is below DNS entirely: see no route to host for telling a routing failure apart from a refused connection and a timeout.

On Windows the commands differ and there is one extra trap: the resolver caches failures as well as answers. See ipconfig /flushdns, or the flush DNS command for every OS including Linux.