How to Flush DNS on Android

I moved a site to a new host on a Tuesday night, updated the DNS, watched the checker turn green resolver by resolver — and my phone kept loading the old site until Thursday. A desktop would have taken me thirty seconds: open a prompt, flush the cache, done. The phone just sat there, smug, loading yesterday's internet. That week I learned what Android users eventually all learn: there is no flush button. Not hidden, not buried in a developer menu. It simply isn't there.

That doesn't mean you're helpless. It means Android's DNS cache doesn't work the way a desktop's does, and the things that actually clear it are a bit indirect. Some are worth doing. Some are folklore. And one of them — the famous one — mostly stopped working years ago.

Why there's no button to press

On Windows or macOS, one system service answers lookups for nearly everything, so one command can empty its cache. Android never really had that shape. Apps resolve names through shared system services, browsers keep caches of their own on top, and manufacturers add their own tweaks on top of that. The result is several small stashes of answers rather than one tank you can drain.

How long an answer sticks around also isn't up to your phone. Every record carries a TTL, a lifetime set by the site's owner, and caches are supposed to honour it. That is the quiet reason a DNS change can feel instant for your neighbour and stale for you: your phone asked at an unlucky moment and is still holding an answer that hasn't expired. Our explainer on how DNS propagation works follows that whole chain if you want it.

The things that genuinely help

1. 1

   Toggle Airplane mode (sometimes)

   Turning Airplane mode on for twenty or thirty seconds, then off, forces the phone to rebuild its network connections and re-register with your provider. On many builds that shakes loose cached answers as a side effect; on others it doesn't touch them. It costs nothing and takes half a minute, so it's worth one try — just don't treat a failure as a surprise. Honestly, on recent versions this trick is more hope than mechanism.

2. 2

   Restart the phone

   The blunt instrument, and the one that reliably works. A full restart clears the volatile caches the system keeps in memory, resets the network stack, and starts lookups fresh. If a site is showing you its old address after everything else, reboot the phone before you try anything cleverer. Yes, it's the oldest advice in tech support. It's also, here, the correct one.

3. 3

   Restart the router, if it's your Wi-Fi

   The problem might not be the phone at all. Your home router caches answers too, and your phone will keep receiving its stale copies. Restarting the router clears that cache, and as a bonus you'll find out whether every device in the house sees the old site or only yours does.

What about Chrome's own cache?

Chrome on Android used to have its own internal pages for this — many older guides still send you to chrome://net-internals to press a flush button. That page was retired. On current builds the address no longer offers those DNS tools; the old instructions keep circulating because the internet never deletes anything. If a guide tells you to go there, it's out of date, not your phone.

What still lives in Chrome is its site data. Clearing cached images and files for the one misbehaving site, or force-stopping Chrome from Android's app settings so it restarts cold, can shake loose the browser's own held answers. It won't clear the system-level cache — nothing an app does can — but plenty of "the site won't update" complaints turn out to be the browser, not the network, and this is the honest way to rule that out.

Private DNS: a sidestep, not a flush

Buried in network settings on most Android phones is Private DNS, which routes your lookups over an encrypted connection to a resolver you choose. If your current resolver — usually your provider's or your router's — is holding a stale answer, switching to a different resolver gives you a different cache entirely, one that may already hold the new record.

Notice what that does and doesn't do. It doesn't empty anything; it walks around the full shelf instead of clearing it. That's still useful — if the site loads correctly the moment you switch, you've learned the fault sits in your old resolver's cache, and the cure really is just time. Our guide on changing your DNS server covers choosing one and the privacy trade-offs honestly, including the fact that you're handing your lookups to somebody else.

Work out which stash is holding the answer

Before you restart anything else, spend two minutes narrowing down which cache owns the stale answer. The tests are boring. The certainty is lovely.

1. 1

   Try a second browser

   Open the site in a different browser — Firefox, Samsung Internet, whatever is already installed. If it shows the new site, your network and the phone's system are fine, and your first browser is the one holding an old answer. Clear that browser's site data, or force-stop it, and you are done.

2. 2

   Compare Wi-Fi and mobile data

   Turn Wi-Fi off and reload the page. If the new site appears on mobile data, your home path is convicted — the router's cache, or your provider's resolver behind it. If the old site shows on both, the stale answer is either on the phone itself or still travelling the internet, and the next test decides which.

3. 3

   Ask resolvers that owe you nothing

   Run the domain through an online propagation checker. If resolvers in several countries already show the new address, the world has moved on and only your caches disagree with it. If they show the old address too, stop restarting things: the change itself is still spreading, and no phone setting reaches it.

Developer guides sometimes mention changing DNS behaviour through a computer connection and debugging tools. That road is real, but it exists for testing apps, and for a phone you rely on daily it is disproportionate: anything it can do about a stale answer, a restart does more simply. I mention it only so that when you meet the advice, you recognise a workshop tool rather than the missing settings page.

The app that lies, and the phone that's innocent

One more stash to know about: individual apps. Well-behaved apps use the system's resolver and inherit its answers, but some apps run their own resolution or pin connections and keep using an address long after the system has moved on. The classic pattern is a browser showing the new site while one banking or shopping app still shows the old one — or errors. Force-stopping that app, or clearing its cache in app settings, is the per-app equivalent of a restart.

Vary the test before you blame the phone: if three browsers and five apps all show the old site, the stale answer is upstream of the apps. If exactly one app disagrees with everything else, that app is your culprit.

The answer nobody wants: wait for the TTL

Here's where I have to be straight with you. If a site changed its DNS with a long TTL — a day, say — and your phone or your router's resolver cached the old answer just before the change, there may be nothing you can press that produces the new answer early. Our walkthrough on flushing the DNS cache covers the desktop commands and the same cache logic, and the logic is unbeaten here: caches expire on the record's schedule, not yours.

What you can do is confirm that's really your situation. Load the site on mobile data instead of Wi-Fi. Try the new resolver via Private DNS. If independent networks show the new site and only your usual path shows the old one, you're watching a cache drain, and it will finish. If nobody anywhere sees the new site, the change itself hasn't landed yet — also not your phone's fault.

If you're the one moving the site

Everything so far is written from the waiting side of a DNS change. If you are ever the person making the change, you can spare your visitors most of it. A full day before the move, lower the TTL on the records you are about to change. A record that used to tell the world “keep this answer for a day” now says “keep it for five minutes”, caches everywhere refresh quickly, and on move night the new address spreads in minutes instead of lingering until Thursday — which, the reader may recall, is exactly how this article started.

Once the dust settles, raise the TTL again so caches can do their normal work, and keep the old host running for at least the length of the old TTL after the switch. Somebody's phone, somewhere, is still holding the old answer, and it deserves a working site when it comes knocking.