IP Address Not Found? Read the Exact Message Before You Fix Anything

No Windows dialog, no macOS alert and no major browser error page prints the bare phrase IP address not found. It does turn up elsewhere — on captive-portal sign-in screens, and in network tooling logs — but the message in front of you is almost certainly one of five longer ones. That is worth knowing first, because it explains why the fixes you already tried did not work.

A browser saying it cannot find a server's address, Windows warning that another computer has taken yours, an adapter that came up on 169.254, a diagnostic reporting no valid configuration, and a connection that simply timed out are five separate problems. Flushing DNS reaches two of them and does nothing at all for the other three. Restarting the router is the right first move for three of them, and no use whatever to the many readers who have no router to restart.

So this page does the step every other guide skips. It reads the exact wording in front of you, tells you which of the five you actually have, gives you the fix that belongs to it, and sends you to the full repair for that one fault instead of a list of ten repairs for five different problems.

Author: Robert Harrison OSINT & Network Utility Expert

My position on this topic is that the standard advice fails for a structural reason, not a technical one. Every guide picks one error, assumes you already know which one you have, and opens with the same ten repairs. Readers who arrive with a different fault run all ten, get nowhere, and conclude their machine is broken. The diagnosis is the missing step, so it goes first here.

The honest limit is worth naming as well. I cannot tell you which fault you have without the exact string, and no page can. What I can do is give you the wording each fault produces, sourced to Microsoft and Google where they document it, and say plainly where they do not document it. Each of the five branches ends at a page written specifically for that one fault.

Why IP Address Not Found Is Not One Error

Search for this phrase and you will notice something odd in the results: almost every article is actually about a different, longer message. Google substitutes the phrasing people type for the longer phrasing a browser or Windows actually prints. That substitution is why the advice so often misses: you searched for what you remembered, and you were handed an article about a message you never saw.

The five faults below share a symptom — something could not be located — and share almost nothing else.

One is a name that did not resolve; one is two devices claiming the same address; one is a device that gave up and numbered itself. The remaining two are a configuration the operating system judged unusable, and a name that resolved perfectly before nothing answered at the other end.

Treating them as one problem is what produces the experience of running every fix on the internet and staying broken. Flushing a DNS cache does nothing for an address conflict. Restarting a router does nothing when there is no router to restart.

Renewing a lease does nothing when the name you typed does not exist. The repair has to match the fault, and the fault is written on your screen.

One of those five sits on the name-resolution path. Three sit below it, at the point where your own machine gets an address. The fifth sits past both: the name resolved, the route was there, and nothing answered. That grouping is what the next section sorts you into, so go and read the wording on your screen.

Start Here: Match the Exact Message You Are Seeing

Read the message again and find it below. Match on the distinctive words, not on the general sense, because the general sense is identical across all five and that is precisely the trap. If you have more than one of these, work the address-level faults first: a machine without a usable address of its own cannot resolve a name reliably either.

One caution on the browser branch. If you administer the site that will not load, rather than merely visiting it, your problem is almost certainly the domain's own records rather than anything on your computer, and none of the local repairs below applies to you.

Chrome does document the nearest code, and the wording repays reading closely. For ERR_NAME_NOT_RESOLVED it says the hostname doesn't exist or now has a different IP address. Note whose address that is: the site's, not yours. Every other branch below is about your own.

The Fastest Question: Does Another Device on the Same Wi-Fi Work?

Before any command, answer one question. Pick up a phone on the same network and open the same page. That single comparison splits the five faults into two groups and takes ten seconds, and it is the question the troubleshooting guides leave out.

If the phone loads the page, the network is delivering addresses and reaching the internet, so the fault is on the one machine. That points at the address-level branches: a conflict, a 169.254 address, or a rejected configuration. If the phone fails on the same page too, the fault is shared, which points at name resolution or at the route out.

There is a third outcome people misread. If the phone fails on every page and not just this one, the line itself is down and nothing in this article is the problem. Check the router's own status lights before you spend an evening on commands.

Three lines of ipconfig output carry the whole address-level diagnosis, and it prints a block for every adapter including virtual ones, so read the block for the connection you are actually using. The IPv4 Address line tells you whether you were given a real address. The Subnet Mask tells you how the machine understands the network it is on. The Default Gateway is the router, and a blank one there is a diagnosis on its own.

You can run the same ladder from outside your own connection to separate a local fault from a site that is genuinely unreachable. Our ping any host from our servers page answers from outside your line, so a host that responds there and not for you is a local fault with certainty rather than as a guess.

Branch One: The Server's IP Address Could Not Be Found

This is the branch the search results are actually written for, and it is the one where the remembered phrase is closest to what a browser really prints. The browser asked for a name, the answer came back with no address attached, and the page stopped there. Your own address is fine; the name is the problem.

The distinction that matters is who produced that answer. If a server that is responsible for the domain replied that the name does not exist, then nothing on your computer can overrule it, and clearing caches is wasted effort. If your own resolver produced the answer from something stale it was holding, clearing a cache is exactly right. Those two cases look identical on screen and need opposite responses.

The quickest separation is to ask a different resolver the same question. If a second resolver returns an address and yours does not, the fault is yours. If both return nothing, the name genuinely is not resolving and the domain itself is where to look.

To ask a resolver directly rather than through a browser, a DNS lookup for any domain returns the records that exist for a name, which tells you whether an address is being published at all. An empty result for a name you know is live is a strong signal that the fault is between you and the answer rather than at the destination.

This branch has a diagnostic code behind it, and the code is more precise than the sentence. If you can see DNS_PROBE_FINISHED_NXDOMAIN anywhere on the page, what DNS_PROBE_FINISHED_NXDOMAIN really means works through who answered, what the response code signifies, and which repairs can and cannot reach each case. Next, the branch that has nothing to do with names at all.

Branch Two: Another Computer Has the Same Address

Windows states this one plainly, and the full wording matters because most articles quote only the first sentence of it. The place the complete text is easiest to find is a Microsoft support bulletin — one about Network Load Balancing nodes rather than home networks, so treat the surrounding article as out of scope, but the message text it reproduces is the same one your PC shows.

All four sentences of it: "Windows has detected an IP address conflict. Another computer on this network has the same IP address as this computer. Contact your network administrator for help resolving this issue. More details are available in the Windows System event log."

That second sentence is the diagnosis. Two devices on your network are both claiming one address, so replies intended for you may arrive at the other device instead. Pages half-load, connections drop and recover, and the symptom is intermittent rather than absolute — which is why it gets misread as a slow connection rather than a conflict.

The usual origin is a device given a fixed address by hand inside the range the router hands out automatically. The router does not know that address is taken, gives it to something else, and both devices are then convinced it is theirs. Nothing about DNS is involved, which is why every DNS-related fix fails on this branch.

That last sentence is the one to act on, and it is why confirming a conflict beats assuming one. The message itself tells you where the record is, so a conflict that has happened more than once leaves a trail in the System event log even after the pop-up has gone. If you saw the message once and everything has behaved since, you may simply be watching a device that has now been given a different address, and there is nothing left to repair.

Finding the other device is the part people skip. Your router's client list shows what holds each address, and the manufacturer prefix of a hardware address is often enough to identify it — a printer, a camera, a set-top box. A MAC address vendor lookup turns that prefix into a manufacturer name, which usually tells you which piece of equipment to go and re-address.

For the full repair, including how to move a fixed address safely outside the automatic range so the conflict cannot recur, how to fix an IP address conflict takes it device by device. The next branch is the one where no address arrived at all.

Branch Three: Your Address Begins 169.254

If ipconfig shows an address starting 169.254, you have the clearest diagnosis available anywhere in this article. Nothing assigned you an address, so your own machine invented one. Microsoft documents the behavior directly: a computer configured to use DHCP "can automatically assign itself an Internet Protocol (IP) address if a DHCP server is not available."

The range is reserved for exactly this. Microsoft's documentation records that IANA "has reserved 169.254.0.0-169.254.255.255 for Automatic Private IP Addressing", and that such an address comes with a subnet mask of 255.255.0.0. Seeing that mask alongside a 169.254 address, with the Default Gateway line blank, confirms it in one glance.

An address like this reaches other machines on the same cable or the same Wi-Fi and nothing beyond them. There is no gateway, so there is no route off your own segment. Every DNS repair, every browser setting and every hosts-file edit is irrelevant here, because none of them can conjure a route that does not exist.

Windows calls this behavior APIPA, and the reason a DHCP server failed to answer is a separate investigation with its own sequence. Our guide to APIPA and the 169.254 range carries that repair. The branch after this one looks similar and is not the same thing.

Branch Four: The Adapter Has No Valid IP Configuration

This wording comes from Windows Network Diagnostics rather than from a browser, and it names either the Ethernet or the Wi-Fi adapter. It sounds like the previous branch, and in the common case it is the previous branch wearing the diagnostic's label.

The distinction is what the diagnostic found. A 169.254 address means nothing answered and the machine numbered itself. This message means Windows looked at the configuration the adapter ended up with and judged it unusable — which can happen with a self-assigned address, but also with a stale lease, a corrupted adapter state, or a fixed address that does not belong on the network it is plugged into.

So reading your actual address is what separates them. If the address is 169.254, work the previous section, because that is the fault and this is only its label. This branch earns its own treatment in the other case: the address looks like an ordinary private one, Windows still calls the configuration invalid, and the adapter state rather than the address is the thing to repair.

The full sequence for this branch, including the ghost-adapter case where a second numbered adapter is holding the configuration, is in no valid IP configuration on Windows. The last branch is the one where everything was found and nothing replied.

Branch Five: Everything Was Found and Nothing Answered

The final branch is the one most often mistaken for the first, and the tell is time. A name that does not resolve usually fails almost instantly. A connection that times out makes you wait, sometimes for half a minute, before it gives up. The exception worth knowing is that if your resolver itself is unreachable, even a name failure makes you wait, which is why that case is filed down here rather than in branch one.

Chrome describes its timeout code as meaning the page took too long to connect, and offers that the connection might be too slow or the page too busy. That is accurate and it is also incomplete as a diagnosis, because the same code appears when a firewall silently discards your traffic, when a route is broken midway, and when the destination is up but refusing to answer your particular address.

There is a near neighbour with its own message. If the complaint names your DNS server as unresponsive rather than the website, then the thing that did not answer was the resolver itself, not the destination. That is a different fault with a different repair, and mixing the two is the reason people change DNS servers to fix timeouts that had nothing to do with DNS.

If the wait is the thing you noticed, ERR_CONNECTION_TIMED_OUT, step by step separates those causes in the order worth testing them. One more situation deserves its own section, because every guide's first instruction is useless for it.

If You Have No Router to Restart

Nearly every article on this subject opens by telling you to unplug your router for a minute. That instruction assumes a household with its own equipment. A great many people reading this have no router they control: a socket in a dormitory wall, a hotel or campus network, a phone hotspot, a mobile dongle, or an office connection somebody else administers.

If that is you, the diagnosis changes shape rather than disappearing. You cannot restart the thing handing out addresses, so the address-level branches need a different approach: disable and re-enable your own adapter, which forces a fresh request without touching anything upstream, and watch whether the address you get is a real one or another 169.254.

A managed network also introduces a cause that never appears in consumer guides. Some networks only hand an address to devices they recognize, and some require you to accept a sign-in page before any traffic passes. In both cases your machine can hold a perfectly valid address and still reach nothing, and no amount of local repair will change it until the network admits you.

The same applies on a hotspot or a tethered phone, with one addition: the device sharing the connection is doing the job your router would do, so restarting that device is the equivalent step. If the branch you matched was the browser one, the network around you is probably fine and the name is the problem regardless of whose equipment you are on.

The Short Version

There is no single error called IP address not found, and that is the reason the standard repair lists disappoint so many people. The wording on your screen is what decides everything: a browser failing to resolve a name, Windows reporting a duplicate address, a self-assigned 169.254 address, a configuration judged invalid, or a connection that waited and got nothing.

Read the message before you change anything. Then run the ten-second test — the same page on another device on the same network — because that single comparison separates the faults on your machine from the faults you share with everyone around you. Only then start repairing, and only the branch you actually matched.

If your branch turned out to be the resolver rather than the destination, DNS server not responding is the one to work through next, and how DNS resolves domain names explains the lookup path the first branch depends on. The cost of guessing here is an evening; the cost of reading the message first is about a minute.