macOS 26 Tahoe: Flush DNS Cache Command (2026)

Need the macOS Tahoe flush DNS command? Open Terminal and run:

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

This clears the local DNS cache and nudges mDNSResponder, the resolver service macOS uses for name resolution. Use it after changing /etc/hosts, switching DNS servers, testing a migration, or fixing a local domain that still points to an old IP.

How to flush DNS cache on macOS Tahoe

To flush the DNS cache on macOS Tahoe 26, open Terminal and run one command as administrator:

1. Open Terminal (Cmd + Space, type Terminal, press Enter).
2. Run sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.
3. Type your administrator password when prompted (nothing appears as you type) and press Enter.
4. Returning to the prompt with no error means the DNS cache was cleared.
5. Verify with dscacheutil -q host -a name myproject.test.

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

For older macOS versions, see the complete Mac flush DNS command by version guide. On macOS 15 Sequoia, see Sequoia flush DNS. On macOS 14 Sonoma, see Sonoma flush DNS.

When to flush DNS on Tahoe

Flush DNS when your Mac keeps resolving a hostname to the wrong address. The common developer cases are:

• You edited /etc/hosts and the browser still opens the production site.
• You changed a local domain from one project to another.
• You moved a staging site to a new server before DNS propagation.
• You changed DNS resolvers from your ISP to Cloudflare, Google DNS, NextDNS or a VPN resolver.
• You fixed a typo in the hosts file but the old result still appears.

If the hostname was loaded in a browser recently, the system flush may not be enough. Browsers keep their own host cache.

Verify the resolved IP

After flushing DNS, verify what your Mac resolves:

dscacheutil -q host -a name myproject.test
ping myproject.test
dig myproject.test

Use dscacheutil to inspect macOS resolution, ping for a quick sanity check, and dig when you need DNS-server-level detail. If dig and dscacheutil disagree, check whether the hosts file or browser cache is overriding your expectation.

Tahoe hosts file checklist

If flushing DNS did not fix the problem, check the hosts file itself:

• The file path is /etc/hosts.
• Each active line starts with an IP address, then at least one space or tab, then the hostname.
• Do not include https://, paths, ports or comments before the hostname.
• Use .test for local development domains when possible.
• Avoid .local unless you understand Bonjour and mDNS behavior.

Example:

127.0.0.1 myproject.test
127.0.0.1 api.myproject.test
::1       myproject.test

If you need a refresher on syntax, read the /etc/hosts syntax guide.

Tahoe-specific notes for developers

macOS Tahoe keeps the same practical DNS flushing workflow used by recent macOS releases, but developers still hit problems because the stack has several caches.

System DNS cache

This is what dscacheutil and mDNSResponder handle. Flush it after hosts changes, DNS server changes and migration tests.

Browser DNS cache

Chrome and Firefox can keep their own host cache. If Terminal resolves the right IP but the browser does not, clear the browser layer.

Application cache

Some apps keep long-lived HTTP connections or internal resolver state. Restart Electron apps, database clients, API tools or browser dev servers if they keep hitting the old host.

VPN DNS

Corporate VPNs often push custom resolvers. If a local domain works off VPN and fails on VPN, check split DNS rules and proxy settings.

Test matrix

Use this matrix to isolate the problem:

• dscacheutil -q host -a name myproject.test: macOS resolver.
• ping myproject.test: quick IP check.
• curl -I http://myproject.test: HTTP layer.
• Chrome private window: browser state.
• Another browser: browser-specific cache.
• Phone hotspot: network-specific DNS.

If all command-line tests pass but Chrome fails, Chrome is stale. If command-line tests fail too, fix the hosts or DNS layer.

Common local-domain setups

Single app

127.0.0.1 myproject.test
::1       myproject.test

API and frontend

127.0.0.1 app.myproject.test
127.0.0.1 api.myproject.test
::1       app.myproject.test
::1       api.myproject.test

Migration preview

203.0.113.50 example.com
203.0.113.50 www.example.com

Remove migration entries after the DNS change is complete.

Automation for frequent switching

If you change hosts entries every day, create a repeatable command:

alias flushdns="sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder && echo 'DNS cache flushed'"
alias checkhost="dscacheutil -q host -a name"

Then:

flushdns
checkhost myproject.test

For project-heavy workflows, a visual hosts manager avoids two common mistakes: saving malformed lines and forgetting to flush DNS. ToggleHosts also makes it easier to keep temporary migration entries separate from permanent local domains.

What to document in project READMEs

Every local project should document:

• Required local domains.
• Required ports.
• Whether HTTPS is mandatory.
• mkcert command for certificates.
• Whether Chrome DNS cache must be cleared after switching.
• Any VPN or proxy requirement.

Example:

Local app: https://app.myproject.test
Local API: https://api.myproject.test
Hosts: 127.0.0.1 app.myproject.test api.myproject.test
Certificate: mkcert app.myproject.test api.myproject.test
After hosts change: flushdns

Clear browser DNS cache too

Chrome:

• Open chrome://net-internals/#dns.
• Click "Clear host cache".
• Restart Chrome if the error persists.

Firefox:

• Open about:networking#dns.
• Click "Clear DNS Cache".

Safari:

• Enable the Develop menu.
• Use Develop > Empty Caches.
• Quit and reopen Safari if the stale result stays.

For a dedicated browser walkthrough, use the Chrome DNS cache guide for Mac.

Automate it

If you switch local projects often, add an alias:

alias flushdns="sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder && echo 'DNS cache flushed'"

Reload your shell:

source ~/.zshrc

Now you can type:

flushdns

ToggleHosts automates this flow for hosts file changes: edit the mapping visually, save it, and the DNS flush happens as part of the workflow.

Troubleshooting

Password does not show while typing

That is normal Terminal behavior. Type your administrator password and press Enter.

"No matching processes were found"

Restart the resolver service:

sudo launchctl kickstart -k system/com.apple.mDNSResponder

Then run the flush command again.

The wrong site still opens

Work through this order:

• Re-check /etc/hosts syntax.
• Flush system DNS.
• Clear browser DNS cache.
• Disable VPN or proxy DNS temporarily.
• Test in a private browser window.
• Verify the server accepts the hostname.

Conclusion

On macOS Tahoe, DNS cache problems usually come from one of three places: stale system cache, stale browser cache, or a hosts file syntax issue. Start with the flush command, verify with dscacheutil, then clear browser DNS if needed.

Sources and further reading

• How DNS works (Cloudflare Learning)
• Terminal User Guide (Apple Support)
• The hosts file explained (Wikipedia)