Static IP Databases vs. Continuously Refreshed Proxy Datasets

One disambiguation first: this post is about static IP databases — classification snapshots compiled and published on a refresh cycle — versus continuously refreshed proxy datasets. It is not about "static proxies," the seller-side term for a session IP you keep. If you came for that, this is the other meaning. The thesis here is simple: proxy infrastructure moves, so data describing it has to move too, and the difference between a static IP database and real-time proxy data is whether the data model admits that.

What is a static IP database?

A static IP database is a point-in-time compilation of IP classifications — geolocation, ownership, proxy status — published on a refresh cycle, whether monthly, weekly, or otherwise. Between refreshes the file does not change, which means every record in it ages silently: the database asserts today what it verified at compile time. That is a perfectly sound model for slow-moving attributes. Who owns a range, which country an allocation sits in — these change rarely enough that a periodic snapshot stays approximately true between editions. The question that decides everything is whether the attribute you care about is slow-moving. Proxy status is not.

What is a continuously refreshed proxy dataset?

A continuously refreshed proxy dataset is produced by ongoing measurement rather than periodic compilation. Measurement infrastructure — continuous active network testing — interacts with proxy networks around the clock and records which exit IPs are actually relaying traffic, when, and how. Each record carries its own observation history: when the address was first seen behaving as a proxy, when it was last seen doing so, and how strong the accumulated evidence is. The deliverable is then regenerated from current observations on a recurring schedule — weekly CSV or JSONL files, in Solarflare's case. The structural difference from a snapshot is not just cadence: in a snapshot, the publication date is the only freshness information you have, and it applies to the whole file. In an observation-based dataset, freshness is a per-record property you can read, filter on, and decay — the data tells you how current each individual claim is.

Why do IP-to-proxy assignments rotate?

Because proxy pools are built on addresses the operator does not permanently own: ISPs reassign home connections, consumer devices join and leave residential pools, carriers share and recycle mobile addresses behind CGNAT, and datacenter ranges get re-leased.

Each mechanism churns on its own clock. Residential pool membership is the fastest: devices participate through bandwidth-sharing apps and SDKs, so an address relays proxy traffic only while that app is installed and running — uninstall it, and yesterday's proxy exit is just a home connection again. ISP reassignment moves addresses between households on lease renewal, transferring any lingering reputation to a stranger. Mobile ranges barely have stable assignment at all: behind carrier-grade NAT one public address fronts thousands of devices, and its composition shifts continuously. Datacenter ranges are slowest but still move — hosting customers churn and providers re-lease address blocks. The sum is a population where the mapping between address and proxy role is temporary at every layer, which is also why network type classification has to be re-observed rather than looked up once.

Where does a periodically refreshed database fall behind?

Lag is structural, not a quality defect: it is the gap between when reality changes and when the published record changes. A database refreshed on a cycle carries that gap by design, and it fails in both directions at once.

Direction one: lag on listing. An address joins a residential pool the day after the snapshot ships; for the rest of the cycle it relays abuse while the database says nothing. Every fresh exit is a false negative until the next edition. Direction two: lag on delisting, the quieter failure. An address leaves a proxy pool — the device owner uninstalled the app, the ISP reassigned the lease — but its listing survives until the next compile. Whoever holds the address now inherits the flag, and a legitimate customer gets challenged or blocked on evidence about a tenant who left. (Both scenarios are illustrations of the mechanism, not measurements.) A model built on per-record observation timestamps shrinks both failure modes: new exits appear when observed, and aging records visibly decay instead of asserting stale certainty.

What does freshness look like in the data itself?

The schema is the receipt. A dataset that claims recency should let you verify it per record:

{"ip":"203.0.113.10","first_seen":"2026-06-28","last_seen":"2026-07-05","network_type":"residential_proxy","confidence":"high"}
{"ip":"198.51.100.24","first_seen":"2026-07-01","last_seen":"2026-07-06","network_type":"mobile_proxy","confidence":"medium"}

first_seen establishes how long the address has been part of observed proxy infrastructure; last_seen tells you the age of the newest evidence — the field your rules should decay on. Recency also feeds the confidence value itself, alongside observation count and behavioral match, so a record that hasn't been observed recently cannot keep asserting maximum certainty. How those inputs combine is covered in confidence score explained. The point of exposing the timestamps is auditability: "real-time" stops being a marketing adjective when you can check the dates yourself.

Snapshot or feed: how should you consume proxy data?

Recurring file delivery — weekly CSV or JSONL loaded into your warehouse, fraud platform, or SIEM — is the operable middle ground between a yearly database and building a per-request API dependency into your hot path. Three consumption habits do most of the work:

• Treat records as evidence with a TTL, not permanent truth: weight recent last_seen values at full strength and decay or expire old ones instead of letting them act forever.
• Reload on every delivery rather than accumulating — an observation-based dataset is regenerated from current evidence, so each delivery supersedes the last.
• Run it as a complement to your existing signals, not a replacement: fresh observed-behavior data adds the dimension static databases lag on, while geolocation and ownership context remain useful. Enrichment patterns for this are on our threat intelligence use case page.

How do you evaluate any IP data source for staleness?

A vendor-neutral checklist — apply it to any provider, including us:

1. Does each record carry observation timestamps, or does the whole file share one publication date?
2. Is classification re-verified by testing — observing the address actually relaying — or compiled from registries and third-party lists?
3. Is delisting tracked? Do records ever leave, or does the list only grow?
4. Does the provider state its refresh cadence plainly, so you can reason about worst-case lag?
5. Can you sample recent records and check last_seen distribution yourself before buying?

Any source that passes all five gives you data you can decay intelligently; the broader question of what to do with the resulting signal is the subject of the full proxy detection guide.

Data about moving infrastructure has to move

Proxy status is a temporary property of an address, so the data model that describes it needs timestamps, re-observation, and delisting — not just periodic recompilation. Our changelog is the public record of how the dataset is maintained over time, and a sample delivery is the direct way to audit the freshness claims in this post against real records.