Fresh Datacenter Proxies: Are Never-Used IPs Worth Paying For

None of these labels has a standard definition, and no public registry records whether an IP address has previously carried proxy traffic. So the claim is always made from the vendor's own records. Here is what each label can honestly mean, and what you can check yourself.

The last row is worth separating out. "Dedicated" is about exclusivity during your term. "Fresh" is about history before it. A dedicated IP can have a long history, and a fresh one can be shared. If you are still deciding between the two access models, shared vs dedicated datacenter proxies covers that decision first.

The regional internet registries ran out of freely allocatable IPv4 space years ago. ARIN, the North American registry, announced that its free pool reached zero on 24 September 2015. RIPE NCC, which serves Europe, the Middle East and parts of Central Asia, made its final /22 allocation from its remaining pool on 25 November 2019. Since then, new IPv4 space in those regions comes mainly through waiting lists of recovered addresses and the transfer market.

That has two consequences for a "virgin IPv4" listing:

1. Most datacenter IPv4 blocks in commercial use have had previous holders. Blocks are bought, sold and leased between organisations, and a block's previous tenant might have run anything from a corporate VPN to a mail server to another proxy service.
2. A recent registration date proves little. When a block is transferred, the registry record often shows the new holder and a recent date. That is a record of the paperwork, not evidence that the addresses were never used.

What you can learn is who has announced the prefix over time. If a block has been routed by several different hosting networks in the past few years, "never used" is a strong claim to accept on trust. The mechanics of allocation, transfer and announcement are covered in BGP and RIR IP allocations.

This is the section that decides whether a premium is worth paying. Sites block traffic for different reasons, and freshness only addresses some of them.

The first row is the easiest to miss. If a target refuses datacenter traffic, it refuses a never-used datacenter IP on the first request. Freshness cannot change the ASN. If that is your situation, the question is proxy type, not proxy age, and what is a datacenter ASN explains how that classification works.

The last row matters for batch buying. Some anti-bot systems score reputation at the subnet level, so ten fresh IPs from one /24 can behave more like one identity than ten. Spread across subnets is often worth more than freshness, as what are subnet proxies explains.

IPv6 changes the arithmetic completely. A single /64, the standard subnet size handed to one server or one customer, contains 18,446,744,073,709,551,616 addresses. Offering "millions of fresh IPv6 proxies" is trivial, and every one of them can truthfully be unused.

It is also mostly meaningless. Sites that handle IPv6 abuse sensibly rate-limit and ban by prefix, often the /64 and sometimes wider, rather than by individual address. A million fresh addresses from one /64 can look like one visitor. And many targets still do not serve over IPv6 at all, so the connection falls back to IPv4 or fails.

If a fresh-IP offer is IPv6, ask how many distinct /64 and /48 prefixes the batch spans, and check that your targets actually accept IPv6 connections before buying.

Freshness is consumed by use. The moment your first request reaches a target, that IP has a history there, and it is your history.

That has practical implications:

• Freshness is a one-time benefit per target. If you rotate a fresh batch across aggressive scraping, the addresses acquire exactly the reputation a used batch would have had. The premium bought you a clean start, not lasting protection.
• Per-target history is invisible to the vendor. A vendor can check public blocklists. It cannot know whether a previous tenant got the address banned from the one retailer you care about.
• Your own behaviour matters more after day one. Request pacing, session handling and fingerprint consistency decide how long the addresses stay usable.

So the fair way to value a fresh-IP premium is: how much is a clean first impression on this target worth, given how fast your workload will use it up? For account work on dedicated IPs, where each address carries low, human-paced traffic to a few sites, the answer can be a lot. For high-volume collection, it is usually close to nothing.

You cannot verify "never used". You can verify most of what matters, and you should do it within the vendor's replacement or refund window. The general proxy test methods are in how to test proxies; the checks below are specific to judging a fresh batch.

Step 1: count subnet spread

import ipaddress
from collections import Counter

def subnet_spread(ips, prefix=24):
    nets = Counter(str(ipaddress.ip_network(f"{ip}/{prefix}", strict=False)) for ip in ips)
    return len(nets), nets.most_common(3)

batch = [line.strip().split(":")[0] for line in open("delivered.txt") if line.strip()]
count, top = subnet_spread(batch)
print(f"{len(batch)} IPs across {count} /24s; most concentrated: {top}")

Fifty IPs in two /24s is a very different product from fifty IPs in forty. If spread matters for your target and the listing did not state it, raise it now.

Step 2: read registry and routing history

RDAP is the structured successor to WHOIS, and the rdap.org bootstrap service redirects each query to the right regional registry. RIPEstat's routing-history data call shows which networks have originated a prefix over time.

import requests

def rdap(ip):
    r = requests.get(f"https://rdap.org/ip/{ip}", timeout=20)
    r.raise_for_status()
    d = r.json()
    events = {e["eventAction"]: e["eventDate"] for e in d.get("events", [])}
    return d.get("name"), d.get("startAddress"), d.get("endAddress"), events

def origin_history(prefix):
    url = "https://stat.ripe.net/data/routing-history/data.json"
    r = requests.get(url, params={"resource": prefix}, timeout=30)
    r.raise_for_status()
    return [o["origin"] for o in r.json()["data"].get("by_origin", [])]

print(rdap("192.0.2.10"))
print(origin_history("192.0.2.0/24"))

Swap in addresses from your batch; the documentation range shown will not return useful data. Treat a recent registration event as a paperwork date, per the section above. A public example shows why: queried in September 2026, the RDAP record for RIPE NCC's own 193.0.0.0 to 193.0.7.255 range lists a registration event in March 2003, while RIPEstat shows 193.0.0.0/21 routed by AS3333 from October 2000. The address block was in use for more than two years before the date on its current record. Dates on a registry record describe the record, not the addresses. Several past origin networks for the prefix is a reason to weight the "never used" claim lightly.

Step 3: check blocklists correctly

DNS-based blocklists are queried by reversing the IP's octets and looking them up under the list's zone. Two cautions apply to Spamhaus specifically, per its own guidance: its free public mirrors do not answer queries sent through public resolvers such as Google or Cloudflare DNS, returning the error code 127.255.255.254 instead, and free use is limited to low-volume, non-commercial querying. Commercial checks need its paid Data Query Service. Treat any 127.255.255.x answer as an error, never as a listing.

import socket

def dnsbl(ip, zone="zen.spamhaus.org"):
    q = ".".join(reversed(ip.split("."))) + "." + zone
    try:
        answer = socket.gethostbyname(q)
    except socket.gaierror:
        return "not listed"
    if answer.startswith("127.255.255."):
        return f"query error {answer}: check resolver and usage terms"
    return f"listed ({answer})"

Run it from a machine using your own recursive resolver, and check reputation databases as well as blocklists. What is IP blacklisting covers the wider set of lists.

Step 4: run a canary against your real target

The only history that matters is the target's. Send a small number of human-paced requests from each IP to the target you bought them for, record status codes and whether any challenge appears, and replace any address that is challenged on its first visit. Keep this to a handful of requests per IP, or the test itself consumes the freshness you paid for.

Because freshness cannot be proven, the terms around failure are where a fresh-IP product really differs.

• Replacement allowance. How many IPs can you swap per month, and how fast? As one published example, Webshare's help center describes 10 manual replacements per month on paid plans plus an automatic replacement feature for proxies that stop working. Compare allowances in numbers, not adjectives.
• Replacement quality. Does a replacement come from a different subnet, or the same one?
• Test window. Can you run the acceptance test above before the refund or replacement window closes?
• Subnet disclosure. Will the vendor state how many /24s the batch spans before you pay?
• Exclusivity term. For dedicated IPs, is the address reserved for you across renewals, or returned to inventory and reissued?

A vendor that commits to a replacement allowance and subnet spread in writing is giving you something measurable. "100% fresh" on its own gives you nothing to hold it to.

The same logic runs through every row: freshness is valuable where the target remembers individual addresses and your usage of each address is light. Everywhere else, pool depth, subnet spread or proxy type decides the outcome. For the ISP route mentioned in the table, see ISP proxies vs datacenter proxies.

SparkProxy does not sell fresh, virgin or dedicated IPs, so it is not the vendor for the first three rows of that table. It sells rotating datacenter capacity: a pool of 1M+ datacenter IPs across 80+ countries, including 50,000+ US IPs, shared across customers, with rotation per request or every 5 minutes. A shared rotating pool is, by definition, not fresh. What it offers instead is breadth: each request can exit from a different address, so no single IP carries much of your traffic.

That suits the "high-volume public data collection" row, where freshness is rarely worth paying for anyway. Plans are sized by concurrent threads with unlimited bandwidth, from Starter at $75 a month for 100 threads to Plus at $440 for 1000, and there is a 24-hour trial with 250 threads so you can run the canary step against your own target before paying. If your target blocks datacenter networks outright, no datacenter provider, SparkProxy included, will fix that, and the table above points to the alternatives.