How to Clear the DNS Cache in Windows, macOS, and Chrome
Clearing your DNS cache forces your operating system or browser to discard locally stored DNS records and fetch fresh mappings from authoritative name servers. This single operation resolves a surprising range of connectivity failures — from ERR_NAME_NOT_RESOLVED errors to stale IP records left behind after a server migration.
What is a DNS cache? It is a temporary, local database maintained by your operating system (and separately by some browsers) that stores the results of previous DNS lookups. Every time you resolve a hostname like example.com, the resulting IP address is stored alongside a TTL (Time To Live) counter. Until that TTL expires, your system skips the upstream resolver entirely and uses the cached record — which is fast, but becomes a liability the moment that record goes stale, gets poisoned, or points to a decommissioned server.
Why the DNS Cache Becomes a Problem
Understanding the failure modes makes it clear why flushing is sometimes the only correct fix:
- Server migration or IP change: When a site moves to new infrastructure, its DNS records are updated with a new A or AAAA record. If your local cache still holds the old IP, every request goes to the wrong host — often resulting in a connection timeout or a TLS certificate mismatch error.
- DNS cache poisoning: Malware and man-in-the-middle attacks can inject fraudulent records into your local cache, silently redirecting traffic to attacker-controlled servers. Flushing the cache removes the poisoned entries immediately.
- Negative caching: A failed DNS lookup (NXDOMAIN response) is also cached. If a domain was temporarily unreachable and the negative result was cached, your system will refuse to resolve it again until the negative TTL expires — even after the domain comes back online.
- Split-horizon DNS conflicts: Developers working with local
/etc/hostsoverrides or VPN-assigned resolvers frequently encounter stale cache entries that override their intended routing. - Post-VPN disconnection artifacts: Residual DNS entries from a VPN session can persist after disconnection, causing DNS leaks or routing failures on the local network.
How to Clear the DNS Cache in Windows
The procedure is identical across Windows 7, 8, 10, and 11. The only meaningful difference is whether you prefer Command Prompt or PowerShell.
Method 1: Command Prompt (ipconfig /flushdns)
- Press
Win + R, typecmd, then pressCtrl + Shift + Enterto launch Command Prompt with administrator privileges. Alternatively, search for Command Prompt in the Start menu, right-click it, and select Run as administrator. - Run the flush command:
ipconfig /flushdns- A successful flush returns:
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.If you see an error instead, ensure you opened the prompt with elevated privileges. Standard user sessions do not have write access to the DNS Client service cache.
Method 2: Windows PowerShell
PowerShell exposes a dedicated cmdlet that interacts directly with the DNS Client service rather than routing through the legacy ipconfig interface.
- Press
Win + Xand select Windows PowerShell (Admin) or Terminal (Admin) on Windows 11. - Run:
Clear-DnsClientCacheThere is no confirmation output on success — the command returns silently. To verify the cache is empty, run Get-DnsClientCache immediately after; it should return no results.
Method 3: Restarting the DNS Client Service
In rare cases where the above commands fail — typically due to a corrupted DNS Client service state — restarting the service itself clears the cache as a side effect:
Stop-Service -Name Dnscache -Force
Start-Service -Name DnscacheImportant caveat: On some Windows configurations, the DNS Client service is set as a dependency for other network services. Stopping it may briefly interrupt network connectivity. Do not run this on a production server without a maintenance window.
Viewing the Current DNS Cache (Windows)
Before flushing, it is often useful to inspect what is cached to confirm whether a stale record is actually the cause of your issue:
Get-DnsClientCacheThis outputs all cached entries with their TTL, record type, and resolved data — far more diagnostic value than blindly flushing.
How to Clear the DNS Cache on macOS
macOS uses mDNSResponder as its DNS service daemon on all modern versions. The flush mechanism has remained consistent since macOS Sierra, but older releases required different commands.
macOS Ventura, Monterey, Big Sur, Catalina, Mojave, High Sierra, Sierra (10.12 and later)
- Open Terminal via
Applications > Utilities > Terminalor pressCmd + Spaceand typeTerminal. - Run:
sudo killall -HUP mDNSResponder- Enter your administrator password when prompted. The password field will not echo characters — this is expected behavior. Press
Enterto confirm.
There is no success message. The -HUP signal instructs mDNSResponder to reload its configuration and purge its cache without a full restart.
macOS El Capitan and Yosemite (10.11 / 10.10)
El Capitan uses the same mDNSResponder command as above. Yosemite briefly replaced mDNSResponder with discoveryd, requiring a different approach:
sudo discoveryutil udnsflushcachesmacOS Mavericks, Mountain Lion, and Lion (10.9 and earlier)
sudo killall -HUP mDNSResponderFlushing the Additional DNS Cache Layers on macOS
macOS maintains more than one DNS cache. For a thorough flush — particularly relevant when debugging split-DNS or mDNS issues — run all three commands in sequence:
sudo killall -HUP mDNSResponder
sudo killall mDNSResponderHelper
sudo dscacheutil -flushcachedscacheutil -flushcache clears the Directory Services cache, which stores additional name resolution data used by system-level processes. Omitting it can leave residual entries that mDNSResponder alone does not touch.
How to Clear the DNS Cache in Google Chrome
Chrome maintains its own internal DNS cache that operates completely independently of the OS-level resolver. This is a deliberate architectural decision — Chrome's network stack (built on Chromium's net:: library) pre-resolves domains it predicts you will visit and caches those results in-process. This means you can flush the OS DNS cache and Chrome will still serve stale records from its own store.
Step-by-Step: Flushing Chrome's DNS Cache
- Open Google Chrome.
- In the address bar, navigate to:
chrome://net-internals/#dns- Click the Clear host cache button. This immediately purges all DNS entries held in Chrome's in-process cache.
Resetting Chrome's Socket Pools
DNS cache entries and open TCP/TLS connections are separate concerns. If you have cleared the DNS cache but Chrome is still routing traffic through an old connection (e.g., after a server IP change), you must also flush the socket pool:
- Navigate to:
chrome://net-internals/#sockets- Click Flush socket pools.
This closes all idle and active keep-alive connections, forcing Chrome to re-establish fresh TCP connections using the newly resolved IP addresses.
Restarting Chrome After Flushing
Close all Chrome windows completely and reopen the browser. On macOS, ensure Chrome is not still running in the background via the Dock — right-click the icon and select Quit rather than just closing the window.
DNS Cache Comparison: OS-Level vs. Browser-Level
| Property | OS DNS Cache | Chrome DNS Cache |
|---|---|---|
| — | — | — |
| Scope | All applications system-wide | Chrome browser only |
| Flush command (Windows) | `ipconfig /flushdns` | `chrome://net-internals/#dns` |
| Flush command (macOS) | `sudo killall -HUP mDNSResponder` | `chrome://net-internals/#dns` |
| Respects OS TTL settings | Yes | Partially (uses its own TTL logic) |
| Affected by VPN DNS changes | Yes | Not immediately |
| Visible to diagnostic tools | `Get-DnsClientCache`, `dscacheutil -cachedump` | Only via Chrome internals |
| Cleared on system reboot | Yes | Yes (in-process memory) |
| Cleared on browser restart | No | Yes |
Platform-Specific Flush Commands at a Glance
| Platform / Version | Command |
|---|---|
| — | — |
| Windows (all versions) | `ipconfig /flushdns` |
| Windows PowerShell | `Clear-DnsClientCache` |
| macOS 10.12 and later | `sudo killall -HUP mDNSResponder` |
| macOS Yosemite (10.10) | `sudo discoveryutil udnsflushcaches` |
| macOS (full flush) | `sudo killall -HUP mDNSResponder && sudo dscacheutil -flushcache` |
| Google Chrome (all OS) | `chrome://net-internals/#dns` > Clear host cache |
| Linux (systemd-resolved) | `sudo systemd-resolve –flush-caches` |
| Linux (nscd) | `sudo service nscd restart` |
Linux is included here because administrators managing VPS Hosting environments frequently need to flush DNS caches on both their local workstation and the remote server simultaneously when propagating DNS changes.
Common Errors That DNS Cache Flushing Resolves
ERR_NAME_NOT_RESOLVED— Chrome cannot resolve the hostname. Almost always a DNS issue; flush both OS and Chrome caches.DNS_PROBE_FINISHED_NXDOMAIN— The resolver returned a non-existent domain response. Can be a stale negative cache entry.ERR_CONNECTION_TIMED_OUTafter a server migration — The old IP is still cached. Flush the OS cache and verify withnslookupordigthat the new IP is being returned.- TLS/SSL certificate mismatch errors — If the cached IP points to a different server than the one holding the correct certificate, you will get a certificate name mismatch. This is common when a domain moves between hosting providers. If you manage SSL infrastructure, ensure your SSL Certificates are provisioned on the correct origin before the DNS TTL expires.
- Intermittent 404 errors after a CMS migration — The site loads, but assets or pages return 404. Often caused by the CDN or reverse proxy still resolving to the old origin. Flush caches at every layer.
DNS Propagation vs. Local Cache: A Critical Distinction
A common misconception is that clearing the local DNS cache will make a newly published DNS record immediately visible. It will not — if the upstream recursive resolver (your ISP's DNS server or a public resolver like 8.8.8.8) has also cached the old record, you will continue to receive the old IP until that resolver's cache expires.
The correct diagnostic workflow is:
- Check the authoritative record directly using
dig @8.8.8.8 example.com Aornslookup example.com 1.1.1.1. - If the authoritative record is correct but your local resolution is wrong, flush the local OS cache.
- If the authoritative record itself is still wrong, the issue is at the DNS registrar or hosting control panel level — not the local cache.
When managing DNS for domains hosted on Dedicated Servers, always set a low TTL (300 seconds) at least 24 hours before a planned migration. This minimizes the propagation window and reduces the blast radius of stale cache entries across the internet.
Security Implications of DNS Cache Management
DNS cache poisoning (also known as DNS spoofing) is a class of attack where an adversary injects malicious A or CNAME records into a resolver's cache, redirecting users to fraudulent servers. While DNSSEC provides cryptographic validation at the protocol level, local cache hygiene remains a practical first-response measure.
If you suspect your DNS cache has been poisoned:
- Flush the local cache immediately using the appropriate command for your OS.
- Switch to a DNSSEC-validating resolver such as Cloudflare (
1.1.1.1) or Google (8.8.8.8). - Inspect running processes for malware that may be modifying the
hostsfile (C:WindowsSystem32driversetchostson Windows,/etc/hostson Unix systems). - Check your router's DNS settings — attackers who compromise a router can redirect all DNS queries on the network regardless of local cache state.
For businesses running their own mail infrastructure, DNS integrity is especially critical. Misconfigured or poisoned DNS records directly affect SPF, DKIM, and DMARC validation. If you rely on Email Hosting services, verify that MX, SPF, and DKIM records resolve correctly after any DNS change.
Automating DNS Cache Flushes
For developers and sysadmins who regularly work with DNS changes — particularly during VPS Control Panels configuration, staging environment switches, or domain migrations — automating the flush removes the manual step entirely.
Windows scheduled task (PowerShell):
$action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-Command Clear-DnsClientCache"
$trigger = New-ScheduledTaskTrigger -Daily -At "03:00AM"
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "FlushDNSCache" -RunLevel HighestmacOS launchd plist (daily flush at 3 AM):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.local.flushdns</string>
<key>ProgramArguments</key>
<array>
<string>/bin/bash</string>
<string>-c</string>
<string>killall -HUP mDNSResponder</string>
</array>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>3</integer>
<key>Minute</key>
<integer>0</integer>
</dict>
</dict>
</plist>Save this file to ~/Library/LaunchAgents/com.local.flushdns.plist and load it with launchctl load ~/Library/LaunchAgents/com.local.flushdns.plist.
Automated flushes are most useful in CI/CD pipelines where DNS records are updated programmatically as part of a deployment workflow, and build agents must resolve the new records immediately after the change is applied.
Technical Decision Matrix: When to Flush and Where
| Symptom | Flush OS Cache | Flush Chrome Cache | Flush Router Cache | Check Upstream Resolver |
|---|---|---|---|---|
| — | — | — | — | — |
| Site loads in Firefox but not Chrome | No | Yes | No | No |
| Site unreachable on all browsers | Yes | Yes | No | Yes |
| Site unreachable on all devices on network | Yes | Yes | Yes | Yes |
| Correct IP shown by `nslookup` but site still fails | No | Yes (sockets) | No | No |
| Site loads for colleagues but not for you | Yes | Yes | No | Yes |
| Just completed a server migration | Yes | Yes | No | Yes |
| Suspected DNS poisoning | Yes | Yes | Yes | Yes |
Practical Checklist Before and After Flushing
- Confirm the DNS change has propagated to authoritative servers using
digor an online tool likewhatsmydns.netbefore flushing locally. - Note the current TTL of the record you are troubleshooting — if it is 86400 seconds (24 hours), flushing locally only helps you; other users will still see the old record for up to 24 hours.
- On Windows, run
ipconfig /displaydnsbefore flushing to capture a snapshot of the current cache state for diagnostic purposes. - After flushing, use
nslookup example.comorping example.comto confirm the new IP is being returned before opening the browser. - If working on a Shared Web Hosting environment, remember that the hosting provider's nameservers also cache records — contact support if propagation appears stuck at the server level.
- For Chrome specifically, after clearing the DNS cache, also clear the socket pool and perform a hard reload (
Ctrl + Shift + Ron Windows/Linux,Cmd + Shift + Ron macOS) to bypass the browser's HTTP cache as well. - Document the flush in a change log if performed in a production environment — DNS changes and cache flushes are frequently overlooked when diagnosing post-deployment issues days later.
FAQ
Does clearing the DNS cache affect browsing speed?
Temporarily, yes. After a flush, your system must perform fresh DNS lookups for every hostname it contacts, which adds a small latency overhead (typically 20–100ms per lookup) until the cache repopulates. For most users this is imperceptible. The cache rebuilds automatically within minutes of normal browsing.
Will flushing the DNS cache log me out of websites?
No. DNS cache entries are entirely separate from browser cookies, session tokens, and authentication state. Flushing DNS does not touch any of those.
How is ipconfig /flushdns different from Clear-DnsClientCache?
Both commands instruct the Windows DNS Client service to purge its cache. ipconfig /flushdns is a legacy interface that communicates with the service via the ipconfig utility; Clear-DnsClientCache is a native PowerShell cmdlet that uses the WMI/CIM interface directly. The end result is identical, but Clear-DnsClientCache is scriptable and returns structured objects, making it preferable in automation contexts.
Why does Chrome still show the old website after I flushed the OS DNS cache?
Chrome maintains its own in-process DNS cache that is not affected by OS-level flushes. You must separately clear Chrome's cache via chrome://net-internals/#dns. Additionally, if the old TCP connection is still alive in Chrome's socket pool, you must also flush socket pools via chrome://net-internals/#sockets.
How often should I clear my DNS cache?
There is no universal schedule. Clear it reactively — when you encounter DNS-related errors, after a server or domain migration, after a suspected security incident, or when switching between VPN and non-VPN network configurations. Routine scheduled flushes are only warranted in development or staging environments where DNS records change frequently.
