Clear Chrome DNS Cache on Mac Fast

Chrome can keep using a stale DNS result even after you flush macOS DNS. To clear Chrome DNS cache on Mac, open:

chrome://net-internals/#dns

Then click "Clear host cache". If the affected domain still loads the old IP, flush macOS DNS and restart Chrome sockets too.

Quick fix

Use this order:

• Open chrome://net-internals/#dns.
• Click "Clear host cache".
• Open chrome://net-internals/#sockets.
• Click "Close idle sockets" and "Flush socket pools".
• Run the macOS DNS flush command:

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Then reload the site without using an old tab. For local development domains, test in a new tab or an Incognito window.

Why Chrome has a separate DNS cache

macOS keeps a system DNS cache, but Chrome also optimizes network requests internally. That means you can have two stale layers:

• macOS resolver cache.
• Chrome host and socket cache.

This is why developers often flush system DNS and still see the old server in Chrome. The system cache may be clean, but Chrome can reuse an old connection or cached hostname result.

Best workflow after editing /etc/hosts

When you change the hosts file on Mac:

• Save /etc/hosts.
• Run the macOS flush command.
• Clear Chrome host cache.
• Flush Chrome socket pools.
• Reload the local domain in a fresh tab.
• Verify with dscacheutil or ping.

This is especially important when you switch myproject.test between two local apps or between local and staging.

Verify Chrome is not the only problem

Run:

dscacheutil -q host -a name myproject.test
ping myproject.test
curl -I http://myproject.test

If these commands resolve the expected IP but Chrome still does not, the issue is probably inside Chrome. If these commands also show the old address, fix the system layer first with the Mac flush DNS guide.

Common mistakes

Reusing an old tab

Old tabs can keep state. Open a new tab after clearing the cache.

Forgetting socket pools

DNS cache and sockets are different. If Chrome keeps a live connection to the old host, flushing sockets can be necessary.

Testing a .local domain

.local can interact with Bonjour/mDNS. Prefer .test for local development domains.

Missing IPv6 mapping

Some tools try IPv6 first. If you map a local domain to 127.0.0.1, consider adding ::1 too:

127.0.0.1 myproject.test
::1       myproject.test

Troubleshooting by symptom

Chrome shows ERR_NAME_NOT_RESOLVED

This usually means Chrome cannot resolve the hostname at all. Start with Chrome host cache, then verify macOS:

dscacheutil -q host -a name myproject.test
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

If dscacheutil does not return the expected IP, Chrome is not the root cause. Fix /etc/hosts first.

Chrome shows ERR_CONNECTION_REFUSED

DNS resolved, but no server answered. Check the port:

lsof -i :3000
curl -I http://127.0.0.1:3000
curl -I http://myproject.test:3000

If direct IP works but the custom domain fails, return to DNS. If both fail, restart the local server.

Chrome shows a certificate warning

The DNS cache may be fine, but the HTTPS certificate may not cover the hostname. Regenerate the mkcert certificate for the exact domain:

mkcert myproject.test "*.myproject.test"

Then restart Chrome completely.

Developer workflow

For local development, use this repeatable workflow after changing a domain:

1. Save the hosts file or Locahl profile. 2. Flush macOS DNS. 3. Clear Chrome host cache. 4. Flush Chrome socket pools. 5. Open a fresh tab. 6. Verify with curl -I.

This is faster than randomly restarting the browser, server and Wi-Fi. It also tells you which layer failed.

When not to blame Chrome

Chrome is not responsible if:

• Safari and Firefox also fail.
• dscacheutil returns the wrong IP.
• ping points to the old server.
• curl cannot connect to 127.0.0.1.
• The local server is not listening on the expected port.

In those cases, fix system DNS, the hosts file or the server process first.

Checklist for recurring issues

If Chrome DNS cache keeps coming back as a recurring problem, standardize your project setup:

• Use .test domains instead of .local.
• Keep one hostname per project instead of reusing the same hostname for many apps.
• Add both IPv4 and IPv6 hosts entries.
• Use a stable port per project.
• Keep HTTPS certificates in a predictable certs/ folder.
• Document the local URL in the project README.

Example:

Project URL: https://app.myproject.test
API URL: https://api.myproject.test
Frontend port: 3000
API port: 4000
DNS reset: flushdns + Chrome host cache

This makes onboarding easier and prevents the common "works on my machine, but not in Chrome" loop.

Team workflow

For teams, share the same local domain convention. If one developer uses myproject.local, another uses localhost:3000, and CI uses app.test, debugging auth cookies and CORS becomes messy.

Use Locahl export/import to share hosts profiles, then each developer can enable the same mappings locally. Pair that with a short troubleshooting note:

• Flush macOS DNS after enabling the profile.
• Clear Chrome DNS if the old app opens.
• Regenerate mkcert certificates if HTTPS warnings appear.
• Restart the dev server after changing hostnames.

Use Locahl to avoid repeat work

Locahl helps by combining hosts file edits with automatic DNS flushing. You still may need to clear Chrome's internal cache when Chrome itself is stale, but the system side of the workflow becomes one click instead of a Terminal routine.

Conclusion

If Chrome ignores a hosts file change on Mac, clear Chrome host cache, flush socket pools, then flush macOS DNS. Most "hosts file not working" problems disappear when both cache layers are handled.