A locator that shows nothing is usually not broken. Most of the time the address it wants was never on the page to begin with, and that is a property of how the call was set up rather than a fault in the tool. This walks through the four things that actually cause it, roughly in the order they happen, so you can tell which one you are looking at instead of reinstalling things at random.
Cause 1: the connection never carried a public address
This is the big one, and it is the reason most "not working" reports are not bugs. Every Ome.tv locator reads the same thing: the ICE candidates a WebRTC call exchanges while it connects. Those candidates are the routes the two browsers offer each other, and only some of them contain a real public address.
- Host candidates are the local addresses. Modern browsers deliberately hide these behind a random
.localname, so they carry nothing useful. That change landed years ago and is not coming back. - Server reflexive candidates are the public address as seen from outside. This is the one every locator is actually after.
- Relay candidates are a middleman server. When the call routes through one, the address on offer belongs to that server, not to the person you are talking to.
If the call falls back to a relay, which happens whenever one side is behind a network that refuses a direct connection, then there is no peer address anywhere in the exchange. No tool can read a value that was never sent. A locator that says nothing here is telling you the truth.
Cause 2: you got an address, but it points at the wrong place
A result that looks wrong is usually a real address being described accurately. An IP address resolves to the network it is registered to, and that is not always where the person is sitting.
- They are on a VPN or proxy. The location you see is the exit server. This is extremely common on random video chat and it is not something a locator can see through, only flag.
- Mobile networks. One address can cover an entire region, and carriers often route traffic through a gateway in a different city than the user.
- Carrier-grade NAT. Whole neighbourhoods share one public address, so the reading is the operator’s aggregation point.
- Stale allocation records. A block gets reassigned to a different city and the databases take months to catch up.
Country is reliable. City is an estimate, and it is a worse estimate on mobile than on a home connection. Any tool that presents a city as certain is overselling it. We wrote the long version of this in who decides where an IP address is, and you can test any address yourself with the free IP lookup.
Cause 3: something changed in your browser
Locators sit on top of browser internals that move. A tool that worked last month and does nothing today has usually been overtaken by one of these:
- A browser update changed WebRTC handling. This is the most common single cause of a working tool going quiet, and it is why the release date of whatever you installed matters more than its feature list.
- Privacy hardening. Brave in particular randomises browser characteristics per site and per session by design. That is a deliberate feature, not a fault, and tools that assume a stable browser identity break against it until they are written to expect it.
- A blocker is cancelling the requests. Some filter lists cancel any request whose path looks like analytics, including first-party ones. The extension looks installed and simply never gets an answer back.
- Too many connections held open. Chromium caps how many peer connections a page may hold, and a session that never releases them will eventually wedge while connecting. Reloading the tab clears it.
If you are using a different Ome.tv locator
The causes above are not specific to any one product, because every tool in this category reads the same candidates from the same browser API. That includes the Chrome Web Store extensions, the Greasy Fork userscripts and this one. If a locator shows nothing on a relayed call, all of them will.
What does differ between tools is how quickly a browser change gets fixed. Two of the most widely used Ome.tv userscripts have been sitting on the same version for years, which means every browser change since then is still unfixed in them. Before you conclude a tool is broken, check when it was last updated. If the answer is a long time ago, it is not going to start working again on its own.
That check is the first of the five in how to judge an Ome.tv IP locator, which goes through what separates a maintained tool from an abandoned one.
The one minute checklist
- Does it fail on every connection, or only some? Only some means cause 1, and nothing is wrong.
- Is the result missing, or present but implausible? Present but implausible is cause 2, and usually a VPN.
- Did it work before? Then check for a browser update and disable your blocker on the page.
- When was your tool last updated? An abandoned tool fails permanently, not intermittently.
- Test in a clean browser profile. If it works there, the problem is local.
If you have worked through that and still have nothing, the failure is worth reporting rather than guessing at. Ours is a Manifest V3 extension on a desktop Chromium browser, documented down to the permissions it declares.