Two Jobs Wearing One Name
Somebody says "route users to their nearest region". Somebody else says "keep European customers' data in Europe". Both are described as geolocation routing, both appear on the same configuration screen, and they are not the same problem.
Routing for speed is an optimisation, so being wrong occasionally is acceptable. Routing for data residency is a constraint, so being wrong once is the whole problem.
Decide which one you are doing before you configure anything. If the answer is both, they are two mechanisms and not one setting, which the second half of this lesson comes back to.
The first half is about the thing they share: the location is not known. It is inferred.
Nobody Knows Where Anybody Is
Every step after the address is a guess made by somebody else's database, updated on somebody else's schedule.
The address itself is a fact, and it is the network's address, not the person's. That gap is not a rare edge case.
Nothing here is unusual and nothing here is an attack. It is a normal day for anybody with a job and a phone.
A geographic rule is therefore not a property of a person. It is a property of one connection at one moment. Anything you store about a user based on it, such as their pricing region or their default language, will eventually be set from the wrong day.
Every one of these is a normal way to use the internet, and every one produces an address that is not where the person is.
For performance this is fine. The wrong site is slower and everything still works. For anything you have to be able to defend, it is not fine, and the answer is not a better database.