What Are Sneaker Proxies and How They Work

A sneaker proxy is an ordinary forward proxy sold against a specific workload. The underlying IP is one of four types that already exist: datacenter, ISP (static residential), rotating residential, or mobile. The label promises four variables tuned for a high-demand drop.

• Latency to the target's edge. Retail sites concentrate in a few cloud and CDN regions, so release proxies sit milliseconds away from them, most often US East (Northern Virginia), London, and Frankfurt.
• A registration that does not scream server. An IP whose owning organization is a hosting company is trivially identifiable. A consumer ISP or mobile carrier registration is not.
• Address spread. Enough distinct network blocks that one block-level rule does not take the whole pool offline. This is the variable buyers underweight, and the one this article spends most time on.
• A clean history. An address not used for abuse recently and absent from shared reputation feeds.

Two terms get confused constantly. A sneaker server is a virtual machine rented close to the retailer's infrastructure so automation runs with minimal round-trip time. A sneaker proxy is the exit IP the request leaves from. One does nothing for the other.

The category is older than most of the anti-bot systems it now meets. When it was coined, cheap datacenter IPs still worked on major footwear sites. They generally do not now, and why is the rest of this article.

Using automation to buy limited releases violates the terms of service of every major retailer that sells them. Nike, adidas, Foot Locker, and effectively every Shopify merchant running a drop prohibit bots, scripts, and automated ordering, and reserve the right to cancel any order placed that way. Those cancellations are not theoretical. Retailers void orders after the fact by clustering them on payment instrument, shipping address, device fingerprint, and network prefix, sometimes days after the card was charged. The money comes back, the shoes do not, and the account usually closes with it.

In several jurisdictions, bulk automated purchasing is a legal matter and not only a contractual one. Event tickets are the clearest case. The US Better Online Ticket Sales Act of 2016 (the BOTS Act, codified at 15 U.S.C. section 45c) makes it unlawful to circumvent a security measure or access control system an online ticket seller uses to enforce purchase limits, and to knowingly resell tickets acquired that way. The Federal Trade Commission announced its first BOTS Act cases on 22 January 2021 against three New York ticket brokers, with judgments totalling more than $31 million, most of it suspended on inability to pay. The UK made the same conduct a criminal offence under section 106 of the Digital Economy Act 2017, reinforced by the Breaching Limits on Ticket Sales Regulations 2018. Ontario's Ticket Sales Act 2017 covers similar ground.

Footwear has no equivalent dedicated statute in most places, so it is governed by contract, by fraud law where deception is involved, and by the retailer's own enforcement. Legislators have repeatedly proposed extending bot bans to general consumer goods, so read the ticket statutes as the direction of travel rather than the boundary.

This article therefore contains no checkout playbook. It will not tell you how to defeat a queue token, a purchase limit, or a bot manager challenge. It explains how the network layer works, which is what people building release monitors, restock alerts, resale pricing datasets, and bot detection on the other side of the fence need.

A drop is a load-shedding problem before it is a security problem. A site that normally serves a few hundred requests per second may see fifty to five hundred times that inside a sixty second window, nearly all aimed at one product URL and one add-to-cart endpoint. Retailers respond in stacked layers:

1. CDN edge rate limiting, applied per IP and per prefix before the request reaches an origin server.
2. A virtual waiting room that issues a signed queue position and refuses anything without a valid token. How Queue-it virtual waiting rooms work walks through that token model.
3. A bot manager running JavaScript and TLS fingerprint checks.
4. Inventory reservation and per-account purchase limits at the application layer.
5. Post-order review, which is where most bot orders actually die.

Notice how little of that stack a proxy touches. It changes exactly one thing: the source address the request appears to come from.

Most of the money spent on sneaker proxies buys rows one and two of an eight row problem. That is the most useful thing to know before spending any of it.

The defender can evaluate an arriving address in well under a millisecond. Four checks do nearly all the work.

1. Registration class. Every IP belongs to a block registered to an organization with an Autonomous System Number. Resolving an address to its ASN is a table lookup, and the answer sorts cleanly into hosting, consumer ISP, mobile carrier, business, or education. A hosting ASN during a consumer product release is anomalous by definition, because nobody buys shoes from an AWS instance. What a datacenter ASN is covers the lookup and the block lists built on it.

2. Prefix history. Reputation attaches to the network block, not the individual address. Shared feeds track which prefixes recently produced credential stuffing, card testing, scraping bursts, or spam. An address inherits its neighbours' sins whether or not you sent a single bad request.

3. Velocity per prefix. Defenders count concurrent sessions, requests per second, and add-to-cart attempts grouped by block. A prefix producing 400 checkout attempts in ninety seconds does not look like a neighbourhood, it looks like a rack.

4. Coherence with everything else. An IP in Ohio, a browser reporting Europe/Kyiv as its timezone, a shipping address in California, and a card issued in a fifth country is a pile of contradictions any post-order review catches. The proxy fixes one field and can actively create the mismatch in the others.

Here is the mechanism that decides whether a pool survives a release.

Defenders do not block individual addresses at scale. They block prefixes, and in IPv4 the prefix they reach for first is the /24, a block of 256 addresses. That is not an arbitrary choice. Three independent facts land on the same boundary:

1. It is the smallest routable unit. RFC 7454 (BCP 194, BGP Operations and Security, February 2015) tells operators to discard IPv4 prefixes longer than /24 learned from peers, and most of the internet does. Anything more specific will not reliably propagate.
2. It is the smallest tradeable unit. Regional registry transfer policy sets a /24 minimum block size, and since the RIPE NCC exhausted its free IPv4 pool on 25 November 2019 it has issued only /24s from the waiting list. Address space is bought and allocated in /24 increments.
3. So it maps to one operator. The smallest thing you can route and the smallest thing you can buy is also the smallest chunk that reliably belongs to one organization. Banning a /24 bans one entity, not 256 unrelated households, so the false-positive risk that makes address-level bans awkward disappears.

Now put that next to how proxy inventory is sourced. Providers do not buy addresses one at a time; they lease contiguous blocks, because that is the unit the IPv4 market sells in. A listing that says "5,000 datacenter IPs" is very often 20 contiguous /24s: 5,000 addresses and 20 independent identities.

The arithmetic is brutal and easy to check.

Three consequences fall out of that table.

A ban is cheap for the defender and expensive for you. Twenty firewall rules against the bottom row removes an entire five thousand address pool, written in the time it took to sort a log file.

Discovery is automatic. Once one address is flagged, the neighbours are numerically adjacent. A defender that flags 203.0.113.47 bulk-checks the other 255 addresses in that /24, sees one owning organization, and bans the block before your remaining IPs have sent a request.

Buying more from the same vendor usually does not help. Extra addresses tend to come from prefixes the vendor already owns, so your invoice doubles while the effective identity count barely moves. That is the trap behind every "I bought 500 more proxies and it got worse" support ticket.

IPv6 has the same structure with different numbers. The single subnet is the /64, end sites are meant to receive a /48 or /56 (RFC 6177), and RFC 7454 names the /48 as the IPv6 counterpart of the /24 filter. Defenders aggregate accordingly. Ten million addresses inside one /64 is still one identity.

For how blocks get allocated and why some prefixes stay clean, see what subnet proxies are.

You do not have to take a vendor's word for this. Take a trial list and compute the metrics yourself.

• Distinct /24 count. Treat this as the real pool size.
• Largest prefix share. The share of your addresses in the single most crowded /24. Above roughly 20 percent, one rule takes a serious bite.
• Top-five share. How much of the pool five firewall rules would remove. Five rules is inside any analyst's patience, so this is the number that predicts a bad release night.
• Distinct ASN count. Two ASNs are not diversity if both belong to the same reseller.

This script gives you all of them from a plain list of proxy endpoints:

import ipaddress
from collections import Counter

def audit(proxy_lines):
    """proxy_lines: list of 'ip:port' or 'ip:port:user:pass' strings."""
    ips = [ipaddress.ip_address(line.split(":")[0]) for line in proxy_lines]
    v4 = [ip for ip in ips if ip.version == 4]

    slash24 = Counter(str(ipaddress.ip_network(f"{ip}/24", strict=False)) for ip in v4)
    slash16 = Counter(str(ipaddress.ip_network(f"{ip}/16", strict=False)) for ip in v4)

    total = len(v4)
    biggest, biggest_n = slash24.most_common(1)[0]
    top5 = sum(n for _, n in slash24.most_common(5))

    print(f"addresses:            {total}")
    print(f"distinct /24 blocks:  {len(slash24)}   <- effective pool size")
    print(f"distinct /16 blocks:  {len(slash16)}")
    print(f"ips per /24 (avg):    {total / len(slash24):.1f}")
    print(f"largest /24:          {biggest} holds {biggest_n} ({biggest_n / total:.1%})")
    print(f"top 5 blocks hold:    {top5 / total:.1%}   <- 5 rules remove this much")
    print(f"worst case: {len(slash24)} firewall rules remove 100% of this pool")

    for block, n in slash24.most_common(5):
        print(f"  {block:<20} {n}")

audit(open("proxies.txt").read().split())

If 1,000 addresses collapse into 12 /24s, you are buying twelve identities at a thousand-address price. Price the pool per prefix, not per IP.

Prefix-level reputation inheritance is also the argument for dedicated allocation over shared. On a shared block, another customer's card-testing run poisons addresses you pay for, and you find out during the sixty seconds you cared about. It is why "fresh" or "virgin" IP claims need verifying: an address can be new to you and still sit in a prefix with two years of history.

No proxy type is fast, trusted, cheap, and diverse at once. Each family trades a different pair.

The pattern in that table is one relationship, not four. Latency predictability and address diversity pull against each other, because diversity comes from being spread across real consumer connections, and consumer connections are what make a path slow and variable.

Datacenter proxies stay useful for the monitoring workloads below, where 200 milliseconds does not matter and the target is a public product page; the use-case treatment lives in datacenter proxies for sneaker botting and retail automation. ISP proxies are the compromise most people reach for, and what ISP proxies are explains how that consumer registration is obtained and why the pools stay small. For the breakdown across every workload, see the comparison of residential, datacenter, and mobile proxy types.

The trust an IP carries is a function of how expensive it is for the defender to block it, not of how residential it looks.

Blocking cost is close to a countable quantity: how many real customers sit behind that address.

That ladder explains every number on every proxy pricing page. Two things follow.

Trust is rented, not bought. Once a prefix carries mostly automated traffic, the cost of blocking it falls toward zero and the trust evaporates with it. Pools are consumed by use: a prefix that worked last season may sit on three reputation feeds now.

ISP proxies occupy an awkward middle. A consumer ISP registration plus datacenter routing sounds like winning both sides. But vendors lease that space in blocks, so the blocking cost sits closer to the datacenter case, and larger defenders now track which consumer-registered prefixes are commercially resold. Fast and ISP-registered is not the same as indistinguishable.

Most technical demand around releases has nothing to do with buying anything. These workloads read public pages, never touch checkout, and are the ones worth building.

Release monitoring and restock alerts. Retailers and communities alike want to know the moment a product page flips to in stock. That is a read of a public page on a polling interval. Here it is on the SparkProxy Scraping API using extract_rules, which returns structured fields instead of raw HTML so you are not re-parsing markup on every poll:

import json, requests

rules = {
    "title":        "h1.product-title",
    "price":        "span.price",
    "availability": {"selector": "button.add-to-cart", "output": "text"},
}

resp = requests.get(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": "YOUR_API_KEY"},
    params={
        "url": "https://example.com/products/limited-runner",
        "render_js": "true",
        "extract_rules": json.dumps(rules),
        "country_code": "US",
        "tag": "restock-monitor",
    },
    timeout=90,
)
resp.raise_for_status()
data = resp.json()

if "add to cart" in str(data.get("availability", "")).lower():
    print("IN STOCK:", data["title"], data["price"])

The tag parameter labels the request so you can group these calls in your usage logs, which matters once dozens of monitors run.

Regional availability and price checks. Allocations differ by market, and so does pricing. One parameter gives you the page as a shopper elsewhere sees it:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://example.com/products/limited-runner" \
  --data-urlencode "country_code=DE" \
  --data-urlencode "render_js=true" \
  --data-urlencode "format=md"

format=md returns clean Markdown instead of HTML, far cheaper to diff between polls. country_code adds 5 credits on top of the base cost, so poll geo-variants on a slower interval than your primary market.

Resale price analytics. Public secondary-market listings support real research: premium over retail by colourway, how a size curve prices, how fast a premium decays after week one. The obstacle there is client-side JavaScript, not any purchasing restriction.

Retailer-side testing. If you run the store, proxies let you load your own release page from twenty regions at once to check the CDN, the waiting room, and localised pricing under synthetic surge.

For all of these: honour robots.txt, keep rates modest, cache aggressively, and never point them at authenticated or checkout endpoints. Polling a public product page every few seconds during a release window is reasonable. Fifty requests per second is a denial of service with extra steps.

If you are the retailer, everything above inverts into a detection strategy. Group your access log by prefix rather than by address:

awk '{print $1}' access.log \
  | awk -F. '{print $1"."$2"."$3".0/24"}' \
  | sort | uniq -c | sort -rn | head -25

The shape of that output tells you most of what you need. Organic release traffic produces a very long tail: thousands of /24s with one to three requests each, because real shoppers scatter across every consumer ISP in the country. Automated traffic produces a short head: a handful of /24s with hundreds of requests each, often numerically adjacent, often resolving to one owning organization.

Three follow-up signals separate a busy corporate NAT from a proxy pool:

• Add-to-cart to product-view ratio. Humans browse before they commit. A prefix converting nearly every page view into a cart attempt is not browsing.
• Timing entropy. Real users arrive on a ragged distribution. Requests on regular intervals, or all inside a 200 millisecond window at drop time, are scheduled.
• Fingerprint reuse across prefixes. Identical TLS fingerprints and header orderings across supposedly unrelated /24s is the strongest single tell, because it shows one client behind many addresses.

Then rate limit at prefix granularity rather than per IP, enforce purchase limits at the account and payment-instrument layer where proxies cannot reach, and run the post-order clustering review that catches whatever got through. The economics only run one way: the defender pays one rule per /24, the buyer pays for every address inside it.

Five questions predict pool performance better than a pricing page does, and most vendors are not used to being asked them.

Then measure latency yourself, from the actual exits, at the hour you will run. Do the diversity audit first: a pool that fails on prefix count cannot be rescued by low latency.