The other day, I bought sneaker proxies by mistake.
I know, I know, how do you accidentally buy sneaker proxies? Well, I needed residential proxies for <redacted> purposes and thought, hey, why not treat myself to the premium stuff? Instead of a basic sedan, I’ll get the proxy equivalent of a Ferrari. At least, that’s what I assumed I was buying.
Roughly two minutes after checkout, I realized the “sneaker” proxy plan came with... features. Specifically, sticky sessions, where all requests for ~5 minutes go through the same IP. Great if you’re trying to cart the latest Travis Scotts without triggering bot protection. Not so great if your use case requires IP rotation for every request. (Which mine did.)
To be fair, there are ways to manually switch between IPs in the proxy pool — but it’s not exactly ergonomic. Like trying to drive your Ferrari with a joystick.
Anyway, I wasn’t about to waste 5GB of proxy bandwidth (sustainability first, fraud research second), so I figured I’d study them. Were they actually special? Are sneaker proxies just regular proxies with better branding and limited-edition buzzwords? Do they sip data from the cleanest residential ISP springs?

In the next sections, I’ll quickly cover some background on sneaker bots and scalpers, and explain why, in theory, they might need “better” proxies. Then, I’ll walk through how I collected data on one provider and what I found. This isn’t meant to be a definitive industry study; it’s more of a case study / unboxing of a single provider.
TL;DR / disclaimer / spoiler alert:
- This analysis was easier than expected. Like, “did I forget a step?” easy.
- I expected pristine, ISP-grade IPs. I got... 80% datacenter IPs from a very familiar provider (spoiler: starts with “bright” and ends with “data”).
- The remaining 20%? Also, datacenter IPs, just not clearly linked to a known proxy vendor.
What are scalpers?
Sneaker bots are just scalpers with a foot fetish. More precisely, they’re bots built to buy limited-edition sneakers the moment they drop, only to flip them for a profit on marketplaces like StockX or Goat.
Scalping in general isn’t exclusive to sneakers. The same playbook gets used for:
- Concert tickets
- Trading cards
- GPUs (hello, 2021)
- Luxury drops
- ...and briefly, NFTs (RIP)
Scalpers are opportunistic, and sneaker bots are their performance-tuned specialists. There’s real money in it, which means:
- Competition is brutal
- Bots are expensive (often subscription-based)
- Speed is everything
Miss by a few milliseconds, and instead of a $300 flip, you get a “Better luck next time” banner and a bruised ego.
Proxies for sneaker bots
If you’re building bots, especially sneaker bots, proxies are essential. Why?
Because sites don’t like being botted. They track IPs. They rate-limit. They ban. And if you send too many requests from the same IP, they’ll throttle you or worse.
Enter proxies.
They let bots make requests that appear to come from a wide set of devices and locations. Instead of your server making 10,000 requests from a single IP, you make 10,000 requests from 10,000 different IPs.
Sneaker drops typically limit purchases to one pair per user. To get around that, bots create dozens (sometimes thousands) of accounts and use proxies to make each account look like a unique customer.
Here’s a quick breakdown of proxy types used in this world:
Type | Latency | Detection Risk | Cost | Notes |
---|---|---|---|---|
Datacenter | Low | High | Low | Fast, cheap butvery detectable |
Residential | Medium | Low | High | Harder to detect, real ISP IPs |
Mobile | High | Very low | Very high | Slower, but harder to detect, with real mobile IPs |
ISP | Low | Low | High | Best of both worlds (datacenter speed, ISP legitimacy) |
Sneaker bots typically aim for residential, mobile, or ISP proxies to avoid detection. Datacenter proxies are often flagged, unless you're targeting a site that doesn’t care (or you’re okay getting banned in under 5 seconds).
So… what are these ‘sneaker proxies’ really?
Now that we’ve set the stage with sneaker bots and their proxy-hungry ways, let’s talk about what I actually did with my accidental proxy purchase.
I subscribed to a provider selling “sneaker proxies.” I bought 5GB of bandwidth at roughly $2/GB. At that price point, I wasn’t expecting miracles, but I wasn’t expecting this either.
For context: Oxylabs sells residential proxies at $4/GB (pay-as-you-go), and Bright Data charges around $5/GB. So getting “sneaker” proxies at less than half the price felt... suspiciously generous.
That’s because “sneaker proxies” isn’t a real technical category. It’s not like there’s a clean IETF spec that defines them. It’s just a marketing term. Sometimes they’re residential. Sometimes ISP. Sometimes... creative. But given how cutthroat sneaker botting is, you'd expect something higher-quality than generic, easily burned IPs.
Enumerating IPs like it’s 2013
To find out what I really got, I set up a data collection endpoint and routed traffic through the proxies to log the IP addresses, ASN (autonomous system number), and country of origin.
Because these proxies use sticky sessions (~5-minute windows on a fixed IP), I couldn’t just hammer them with requests and enumerate thousands of IPs at once. So I spread the probing over several days.
Also, as is common in the proxy world, I didn’t get a fixed IP list. Instead, I was given a proxy gateway in the usual format:
proxy.name-of-proxy-provider.com:<port_number>:<username>:<password>
The provider lets you generate “different” proxy endpoints by tweaking parameters related to the country or the session. In theory, this gives you access to different IPs. In practice? Many of them overlap, and cycling through fresh ones takes effort and patience (two things scalpers are famously known for, obviously).
About halfway through the experiment, I noticed the proxies looked suspiciously like low-end datacenter IPs. So I threw in a twist: I randomly returned HTTP 403s to the provider. My hope was that this would cause their routing logic to serve “higher quality” IPs, maybe residential, under the assumption that my client was being blocked. Spoiler: that didn’t happen. It just kept serving the same low-rent datacenter junk.
Visualizing proxy sadness
So, what did we find?
Across the 4,287 unique IPs we collected, over 99% were clearly datacenter IPs.
More interestingly when I compared them with my proxy database, 804 of them mapped directly to Bright Data’s known datacenter proxy pool.
But it doesn’t stop there. If we include IPs in the same /24
blocks (i.e., same subnet, likely owned by the same entity), we end up with 3,343 IPs either confirmed as or highly likely to be Bright Data datacenter IPs.
Here’s the breakdown:
Description | Count | Percentage |
---|---|---|
Total proxy IPs enumerated | 4,287 | 100% |
Directly tied to Bright Data DC proxies | 804 | 18.8% |
Same /24 as Bright Data DC proxies | 3,343 | 78% |
The rest? Still datacenter IPs, just not obviously linked to Bright Data. They belonged to well-known hosting ASNs like:
- Vultr
- HostRoyale Technologies Pvt
- M247 Europe
- Geekyworks IT Solutions Pvt
- ColoCrossing
To double-check, we manually tested the proxies on other domains, including IP testing endpoints used in the proxy provider’s own documentation, just to rule out any weird treatment of our test domain. Same result.
Could the provider be giving out better proxies to known sneaker sites? Sure, maybe. But let’s just say we didn’t exactly catch them putting their best foot forward.
Final thoughts, mostly regret
That’s it. I was expecting premium-grade residential or ISP proxies, you know, the kind you’d actually want in a sneaker bot war. Instead, I got low-quality datacenter IPs that Bright Data itself sells at $0.60/GB, a third of what I paid.

To be clear, I’m not saying all sneaker proxy providers are just lazy resellers of Bright Data’s datacenter pool. But the proxy ecosystem has a well-earned reputation for being opaque. Resellers of resellers. Mystery routing logic. Claims of “premium residential” masking reality. It’s a mess.
This write-up doesn’t end with a grand takeaway or urgent call to action. If anything, the most reassuring part is: if attackers are using proxies like these, your bot defenses are probably doing just fine. These IPs are likely already flagged by most commercial proxy detection engines.
But if attackers are smarter (and they often are), the usual rules apply:
- Don’t rely solely on legacy controls like rate limiting or geoblocking. Here’s why.
- Collect all the signals — device fingerprinting, behavioral patterns, proxy classification. This guide helps.
- Assume bots are reverse-engineering your site. They often don’t use full browsers, and when they do, it’s not the real thing. CAPTCHA solvers show us how far they’ll go.
- Obfuscate client-side code to protect the integrity of the signals you collect. Otherwise, they’ll just forge them. See how TikTok does it.
Because it’s a security blog, here are the IoCs
Because it wouldn’t be a proper security blog post without IoCs, we are sharing 2 files related to the IP addresses we encountered during the experiment. Feel free to correlate them with your logs to verify if you see traffic from these data center proxies:
- Raw IPs observed along with information about the IP: proxy IP list (total = 4287 IPs)
- A second list constituted of /24 IP ranges in which we saw > 5 proxy IPs from the same range. Indeed, for data center proxies, it’s relatively safe to assume that if there are enough (here > 5) proxy IPs from the same /24, then the whole /24 is used as proxy (total = 82 /24 IP ranges, equivalent to 20992 IPs)