Clear the DNS Cache on macOS: The One Command, and Why You Rarely Need It

On any modern macOS the command to flush the DNS cache is sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Run those two together, enter your password, and the local resolver cache is cleared. That is the answer. The more useful thing to know is that a stale DNS cache is blamed for a lot of problems it did not cause - the record you changed has a TTL, your browser has its own cache, and the resolver you actually query might be your router, not your Mac.

The command is thirty seconds of work. Knowing whether the cache is even your problem saves you from flushing it five times and concluding DNS is haunted.

Table of contents

• The command, for every recent macOS
• How to tell if the cache is really the problem
• The other caches in the way
• When flushing is genuinely the fix
• How this fits the rest of the stack
• FAQ

The command, for every recent macOS

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Both halves matter. dscacheutil -flushcache clears the Directory Service cache; killall -HUP mDNSResponder restarts the multicast DNS responder that does the actual lookups. Running only one leaves half the cache intact, which is why single-command answers sometimes ‘do not work’. This pairing has been the correct one across Ventura, Sonoma, and later - Apple stopped changing it years ago.

How to tell if the cache is really the problem

Before you flush, ask what you actually changed. If you just repointed a domain’s A record, the old value can persist for up to its TTL regardless of your cache:

dig example.com +short          # what your resolver returns now
dig @8.8.8.8 example.com +short  # what a public resolver returns
dig example.com | grep -A1 "ANSWER SECTION"   # includes the TTL

If dig @8.8.8.8 already shows the new value but your normal dig shows the old one, your local resolver is caching and a flush helps. If both still show the old value, the change has not propagated yet and flushing your Mac does nothing - you are waiting on the TTL, not on your cache.

The other caches in the way

• The browser. Chrome keeps its own DNS cache. Clear it at chrome://net-internals/#dns. A flushed OS cache does not touch it.
• The router. Many home routers run a caching resolver. If your Mac queries the router and the router caches, you flush the wrong machine. Reboot the router or point your Mac at 8.8.8.8 / 1.1.1.1 to bypass it.
• The authoritative TTL. The record’s own TTL controls how long every resolver on the path may cache it. Nothing you do locally shortens someone else’s cache.

When flushing is genuinely the fix

There is a real case for it: you moved a site to a new server, updated DNS, and your Mac is still hitting the old IP while everyone else sees the new one. That is a local cache holding a stale record past its usefulness, and the flush command clears it immediately. It is also worth doing after switching VPNs or networks, when half-resolved names can linger.

Outside those cases, if a flush ‘fixes’ things intermittently, be suspicious - intermittent DNS problems are more often a flaky resolver or a propagation delay than a cache that needs clearing on a schedule.

How this fits the rest of the stack

DNS confusion is almost always about which layer holds the stale answer - your Mac, the browser, the router, or the record’s own TTL - and flushing the wrong one wastes an afternoon. The same clarity helps when you point a domain at a deployed app: you want to see the record, the TTL, and the target in one place. The RunxBuild hosting calculator shows what the app and its bandwidth cost as line items, and the RunxBuild dashboard is where you attach a domain and watch it go live without guessing which cache is lying.

Useful related references:

• What does flushing DNS actually do
• Mac: delete the DNS cache
• How to fix slow DNS lookups
• Static sites and domains on RunxBuild

FAQ

How do I clear the DNS cache on a Mac?

Open Terminal and run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, then enter your password. The first command clears the Directory Service cache and the second restarts mDNSResponder, which handles lookups. Run both together; running only one leaves part of the cache in place. This command works on Ventura, Sonoma, and later macOS versions.

Why does flushing the DNS cache not fix my problem?

Usually because the stale answer is somewhere else. The DNS record has a TTL that controls how long every resolver caches it, your browser keeps its own cache, and your router may cache too. Check with dig @8.8.8.8 example.com: if a public resolver still returns the old value, the change simply has not propagated and no local flush will help.

How do I know if DNS has propagated?

Compare your resolver against a public one: dig example.com +short versus dig @8.8.8.8 example.com +short. If the public resolver shows the new value but yours shows the old one, flush your local cache. If both still show the old value, propagation is incomplete and you are waiting on the record’s TTL, not on your Mac’s cache.

Does clearing the macOS DNS cache clear the browser cache?

No. Chrome and some other browsers keep a separate internal DNS cache that an OS flush does not touch. Clear Chrome’s at chrome://net-internals/#dns. If a name resolves correctly in Terminal after a flush but still fails in the browser, the browser’s own cache is the layer holding the stale entry.

How often should I flush the DNS cache?

Almost never on a schedule. Flush it after you change a DNS record and your Mac is still hitting the old IP, or after switching VPNs or networks. If you find yourself flushing repeatedly to fix an intermittent issue, the real cause is more likely a flaky resolver or propagation delay, and routine flushing is treating a symptom.