Clear DNS Cache on Mac: The Command, and Why It Usually Is Not the Problem

On any macOS release from Big Sur onward, the command is sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. It clears the operating system’s resolver cache — and if your site is still resolving to the old address afterwards, the cache you needed to clear was somewhere else.

This command has been passed around for so long, across so many macOS versions, that most people run it as a ritual rather than a diagnosis. It does one specific thing. Knowing what that thing is turns a five-minute superstition into a thirty-second answer.

Table of contents

• The command, and what each half does
• Verify before you flush, or you are guessing
• The four other caches between you and the record
• A 301 redirect will outlive your DNS fix
• A short decision path
• How this fits the rest of the stack
• FAQ

The command, and what each half does

Open Terminal and run it as one line:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

It produces no output. That is expected — silence means it worked. You will be asked for your password, once, because both halves need root.

The two halves are not redundant:

• dscacheutil -flushcache clears the Directory Service cache, which holds more than DNS — user and group lookups live there too.
• killall -HUP mDNSResponder sends a hangup signal to the multicast DNS responder, the daemon that actually performs and caches DNS resolution on macOS. This is the half that matters for DNS.

The semicolon rather than && is deliberate: run the second command whether or not the first succeeds, since they address different caches.

Older macOS releases used different daemon names — mDNSResponderHelper and discoveryd had their moments — which is why searching this turns up half a dozen variants. On anything current, the line above is the one.

Verify before you flush, or you are guessing

Flushing is cheap, so people flush first and check second. Reverse that order and you often skip the flush entirely, because you find out the record itself has not propagated yet.

The important trick is to ask a public resolver directly, bypassing every cache on your machine and your network:

# What does your machine currently believe?
dig example.com +short

# What does the authoritative source say, right now?
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short

# Ask the domain's own nameservers, skipping all resolvers
dig example.com NS +short
dig @ns1.yourprovider.com example.com +short

If the public resolvers still return the old address, flushing your Mac achieves nothing. The record has not propagated, and the only cure is the one nobody likes: waiting out the TTL.

Check the TTL you are actually waiting on, because it is knowable rather than mysterious:

dig example.com | grep -A1 'ANSWER SECTION'

The number before the record type is the remaining lifetime in seconds. A TTL of 3600 means some resolvers will keep serving the old answer for up to an hour after you changed it, and there is no command on your laptop that reaches into them.

The practical lesson lands before the change, not after: drop the TTL to 300 a day before you plan to move a record, make the change, then put the TTL back. Nobody does this the first time. Most people do it the second time.

The four other caches between you and the record

The OS resolver is one layer in a stack, and it is rarely the stubborn one.

1. The browser. Chrome keeps its own DNS cache independent of the operating system. Visit chrome://net-internals/#dns and clear it there. Safari and Firefox lean on the system resolver more, but all three cache HTTP responses and redirects aggressively — a cached 301 will send you to the old host long after DNS is correct.
2. The application. Long-running processes resolve once at startup and hold the result. Java is notorious for this: the JVM historically cached successful lookups forever unless told otherwise. A restart of the process is the fix, not a flush of the OS.
3. The router. Consumer routers run their own forwarding resolver with its own cache and its own opinions about TTL. Rebooting it is crude and effective.
4. The upstream resolver. Your ISP’s resolver, or whatever public resolver you point at. This is the one that honours the TTL you set, and the one you cannot flush.

There is a fast test that separates local from upstream. Load the site on a phone over mobile data, with wifi off. Different network, different resolver, different router. If it works there and not on your Mac, the problem is local and flushing is worth trying. If it fails in both places, stop flushing and go look at your DNS records.

A 301 redirect will outlive your DNS fix

This deserves its own section because it wastes so much time. If a site ever served a permanent redirect — HTTP 301 — browsers cache it, sometimes indefinitely, and they apply it before making any request at all. You can have perfect DNS, a healthy server, and a browser that never contacts either.

The symptom is distinctive: the site works in a private window, works in a different browser, works on your phone, and fails only in your normal browser. That is not DNS. No amount of flushing touches it.

Test with curl, which caches nothing:

curl -sI https://example.com | head -n 5

# Follow the whole redirect chain and see each hop
curl -sIL https://example.com | grep -E 'HTTP/|[Ll]ocation:'

If curl gets a 200 and your browser does not, clear that site’s data specifically rather than nuking your entire history. In Chrome, the site information panel in the address bar has a per-site clear option.

The general lesson: send a 302 while you are still deciding, and only send a 301 when the move is genuinely permanent. A 301 is a promise made to every browser that has ever visited you, and it is very hard to take back.

A short decision path

When a domain is not resolving the way you expect, in order, stopping at the first one that explains it:

1. dig @1.1.1.1 yourdomain.com +short — if this is wrong, the record is wrong or has not propagated. Nothing local will help.
2. Check the TTL. If it is high and you changed the record recently, you are waiting, not debugging.
3. dig yourdomain.com +short locally. If this differs from step one, flush: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
4. Still wrong in the browser only? Clear the browser’s DNS cache and that site’s data. Suspect a cached 301.
5. Still wrong for one application only? Restart it. It resolved at startup and never looked again.

Five steps, and the flush is the third one. It is a real tool with a narrow job, which is a fair description of most commands people run as rituals.

How this fits the rest of the stack

Most of this pain shows up at exactly one moment: pointing a domain at a new host. That is when TTLs are wrong, records are half-updated, and the certificate has not been issued yet — and it is when a flush feels like it should help and does not.

RunxBuild handles the domain side of that: attach a custom domain to a static site or a service, and the certificate is issued and renewed for you, with redirects, rewrites and response headers as configuration rather than as a server you keep in shape. The move still costs you a TTL wait — nothing changes physics — but it costs you one thing instead of four. If you are working out what a site plus its API, database and bandwidth come to, the RunxBuild hosting calculator puts them side by side as separate line items.

Useful related references:

• Clear the DNS Cache on macOS: The One Command, and Why You Rarely Need It
• Flush DNS Cache on macOS: The Command, and Why It Usually Is Not the Problem
• Delete the DNS Cache on Mac: The Two-Part Command People Get Wrong
• Custom domains and certificates on RunxBuild

FAQ

What is the command to clear the DNS cache on a Mac?

Run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder in Terminal. It works on all current macOS releases and prints nothing on success. Older versions of macOS used different daemon names, which is why several variants of this command circulate.

Why does flushing DNS on my Mac not fix the problem?

Because the stale answer is usually cached somewhere else — a public resolver still inside its TTL, your browser’s own DNS cache, a long-running application that resolved at startup, or your router. Check with dig @1.1.1.1 yourdomain.com +short first. If a public resolver is also wrong, nothing on your Mac can help.

How long does DNS propagation actually take?

As long as the record’s TTL, which you set. Query it with dig yourdomain.com and read the number before the record type. A TTL of 3600 means some resolvers serve the old answer for up to an hour. Lower the TTL to around 300 a day before a planned change, then restore it afterwards.

Do I need to restart my Mac to clear the DNS cache?

No. The flush command restarts the resolver daemon, which is the only part a reboot would have reset. If the problem survives the flush, a reboot will not help either — the stale record is upstream, in your browser, or in an application that has not re-resolved.

Why does the site load in a private window but not a normal one?

That pattern points at a cached HTTP redirect rather than DNS. A permanent 301 is stored by the browser and applied before any request goes out, so DNS never gets consulted. Confirm with curl -sIL https://example.com — curl caches nothing — then clear that specific site’s data in the browser.