A geolocation database answers "where is this IP?" — proxy detection answers "is this IP currently acting as a proxy exit?" They are different data planes: different questions, different sources, different rates of change. Neither subsumes the other, and mature risk pipelines run both. This explainer covers what each plane actually contains, where each fails without the other, and the ordering rule for combining them — with the deeper proxy detection mechanics linked throughout.
What does a geolocation database tell you?
A geolocation database maps IP addresses to location and network context: country, region, city, timezone, the operating ISP, and network-ownership information such as the ASN — the last of which is registry-derived data with its own fraud applications, covered in ASN lookup for fraud prevention. The data is compiled from allocation records, routing information, and location measurement, then published as a lookup table your systems join against. Its legitimate jobs are everywhere in production: enforcing compliance and licensing boundaries, localizing content and currency, routing traffic to nearby infrastructure, and powering coarse geographic rules. Two properties define the plane. First, it describes attributes — facts about where an address sits in the network's structure, which change on infrastructure timescales. Second, it is compiled rather than observed: the facts can be read out of registries and measurements because they are properties of the address itself, not of what the address happens to be doing this week.
What does proxy detection tell you?
Proxy detection reports whether an IP address has recently been observed operating as a proxy exit — relaying other people's traffic — and qualifies that observation: on what kind of network (residential, datacenter, or mobile), with what strength of evidence, and when. In Solarflare's dataset each record carries first_seen and last_seen timestamps plus a confidence level built from observation count, recency, and behavioral match — the semantics unpacked in IP confidence score. The defining property of this plane is provenance: proxy status cannot be read out of a registry, because it is a behavior, not an attribute. No allocation record says a home broadband address started relaying traffic for a proxy pool on Tuesday. The only way to know is to observe it — continuous active network testing that interacts with proxy networks and records which exits are actually relaying — and observation is why the data carries evidence metadata that compiled databases have no equivalent for.
Why can't a geolocation database detect proxies?
Because location is an attribute of where an address sits, while proxy status is a behavior that starts and stops — and a lookup table of attributes has no way to see behavior.
The failure is quieter than most teams expect: a geolocation lookup on a proxied connection doesn't error, it succeeds. It returns the exit server's location, accurately. The user is in one country; the proxy exit is in another; the database truthfully reports the exit. Geolocation on a proxied connection is accurate about the wrong machine — every field is correct, and the conclusion drawn from it is not, because the address being described is not the user's. This is not a defect of geolocation databases; describing user location was never in scope for a data plane built from address attributes. It does mean the two planes have a dependency: geographic conclusions about a user are only trustworthy after the connection's proxy status is known.
Where does each data plane fail without the other?
| Geo-only pipeline | Proxy-only pipeline | |
|---|---|---|
| What slips through | Proxied traffic that "looks local" — the exit is in the right country, so geo rules pass it | Nothing extra is caught by dropping geo — but compliance boundaries go unenforced |
| What's missing | Any signal that the location describes a relay rather than the user | Location context for licensing, tax, localization, and lawful-service boundaries |
| What becomes unexplainable | Why "local" traffic behaves like coordinated infrastructure | Why a flagged session was in scope for a geo-bound obligation at all |
Both columns describe real pipelines: geo-only stacks are how proxied fraud passes country rules in fraud and risk workflows, and proxy-only stacks strand every decision that legally depends on where the user is.
How do the two combine in practice?
They join on the IP address, and the combination follows one ordering rule: check proxy status before treating geolocation as a user attribute. Geolocation supplies the where; proxy detection supplies whether the where can be trusted as a statement about the user. A location-mismatch rule — declared country versus IP country — only means something once proxy exits are identified, because a proxied session can match or mismatch any geography its operator chooses. In practice both records travel with the event: location fields from the geo plane, and the observed-behavior fields from the proxy plane, so downstream rules can branch on the combination — trust the geography when the address shows no proxy evidence, and treat it as the exit's geography, not the user's, when it does. The two planes are complements, not competitors; each is authoritative for its own question and silent on the other's.
{
"ip": "203.0.113.77",
"geo": { "country": "DE", "city": "Frankfurt", "asn": "AS64500" },
"proxy": {
"observed_proxy": true,
"network_type": "residential_proxy",
"confidence": "high",
"first_seen": "2026-07-01",
"last_seen": "2026-07-20"
}
}Interpretation, in two sentences: the connection genuinely exits in Frankfurt, so geo-bound rules about the exit hold — but the recent high-confidence proxy observation says Frankfurt describes the relay, not the user, so no user-level geographic conclusion survives. (Illustrative values; the proxy-plane fields are documented on the dataset schema page.)
How do update cadences differ?
On the geo plane, assignments move on infrastructure timescales — allocations transfer and ranges move rarely enough that periodic editions stay serviceable. On the proxy plane, status churns week to week as pools recruit and shed addresses, so the data must be re-observed continuously and consumed on a recurring cadence — weekly CSV/JSONL deliveries, in Solarflare's case, with per-record timestamps so you can verify recency yourself rather than trusting a label (the changelog is the public record of that maintenance). The full argument about why edition-based data structurally lags a churning population is in static vs continuously updated proxy data.
Two questions, one join
Where is this address, and is it currently relaying someone else's traffic — every IP-keyed risk decision eventually needs both answers, from the plane built to give each one. To see what the observed plane looks like joined against your own logs, request a sample.
Frequently asked questions
- Can a geolocation database flag VPNs or proxies?
- The location plane itself cannot — proxy status is observed behavior, not a registry attribute. Some providers bundle a separate detection layer alongside their geolocation product, but that layer is doing observation work, not geolocation work.
- Do I need both geolocation and proxy data?
- If you make both kinds of decisions, yes. Compliance, licensing, and localization need location; fraud and abuse screening needs observed proxy status. Most risk pipelines join both planes on the IP and let each answer its own question.
- Does a proxy change an IP's geolocation?
- No — that's the trick. The proxy substitutes a different address entirely, and that address's geolocation is reported accurately. The user inherits the exit's geography, which is why proxy status must be checked before geography is trusted.