How to flush the DNS cache: Windows, Mac, Android and browsers

You moved your site to new hosting or changed the domain's A record. A colleague's phone already shows the new page, yet your computer stubbornly opens the old site. Usually neither the server nor DNS is at fault: the culprit is the DNS cache on your device. Computers, phones and browsers remember an IP address for a while so they do not have to ask a DNS server every time. Here is where that cache lives and how to clear it on Windows, macOS, Linux, phones and browsers.

Where DNS answers get cached

A lookup result is stored at several levels: in the browser, in the operating system's DNS service, in your home or office router, and in your ISP's resolver. How long each copy lives is set by the record's TTL in the DNS zone; with a TTL of 3600 an answer may be cached for up to an hour. You can only clear the caches on your own devices. The ISP's resolver refreshes on its own when the TTL expires, which is why some people see a change immediately and others hours later.

A typical case: a café in Samarkand moved its menu site and updated the A record. Within an hour the waiters' phones showed the new menu, but the Windows PC at the till kept loading the old page. Running ipconfig /flushdns and clearing Chrome's internal cache fixed it instantly.

Windows

Open Command Prompt (type cmd in the Start menu) and run the command below. Admin rights are usually not required; if you get an error, run it as administrator. ipconfig /displaydns shows what is currently cached, and PowerShell offers equivalents:

ipconfig /flushdns

Clear-DnsClientCache
Get-DnsClientCache | Where-Object Entry -like "*sizningdomen.uz*"

macOS

On current macOS versions the cache is held by mDNSResponder. Run this in Terminal and enter your admin password (characters will not appear as you type). No output is normal. Very old macOS releases used different commands, so check Apple's documentation for your version if needed:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux

It depends on the resolver in use. Many modern distributions, Ubuntu included, run systemd-resolved; older ones use sudo systemd-resolve --flush-caches. With dnsmasq or nscd, restart that service instead, for example sudo systemctl restart dnsmasq:

resolvectl flush-caches
resolvectl statistics

Android and iPhone

Phones have no dedicated flush button, but toggling airplane mode on for 10-15 seconds re-establishes the connection and clears the system cache; a restart works too. On Android, also check Settings for Private DNS: if a third-party provider is configured there, the phone bypasses the Wi-Fi or carrier resolver, which explains why two devices on the same network can see different results.

Browsers

Chromium-based browsers keep their own DNS cache. Open the internal page below and click "Clear host cache", then "Flush socket pools" on the sockets page so old connections are dropped. In Firefox use about:networking#dns and "Clear DNS Cache". These clear DNS answers only; if the new server loads but the design looks old, that is the regular page cache, cleared with Ctrl+F5.

chrome://net-internals/#dns
chrome://net-internals/#sockets
edge://net-internals/#dns

Checking the result

Compare your system resolver with public ones:

nslookup sizningdomen.uz
nslookup sizningdomen.uz 8.8.8.8
nslookup sizningdomen.uz 1.1.1.1

If public resolvers return the new IP and yours returns the old one, the cache sits at your router or ISP; restart the router or wait for the TTL. If every resolver shows the old IP, the problem is the DNS record itself, not caching.

The forgotten hosts file

If nothing helps, check the hosts file, which overrides DNS and is often edited for testing before a migration and then forgotten. It lives at C:\Windows\System32\drivers\etc\hosts on Windows and /etc/hosts on macOS and Linux. Remove or comment out (#) any lines with your domain.

Plan ahead with a short TTL

A day before a migration, lower the TTL of the domain's records to around 300 seconds. Once the old TTL has expired, resolvers keep the record only briefly and the new IP spreads within minutes. The same approach works when editing records in the sayt.uz cabinet; restore the normal TTL once everything is stable.