Sneaker proxies are the IP addresses a sneaker or retail bot sends its traffic through, so tasks do not all come from one home connection. The best sneaker proxies depend on the job the task does, not on one proxy type for everything. This is the rule that holds up across retailers as of October 2026.
Use ISP proxies for drops on sites that block datacenter ranges but accept ISP-registered IPs. Use rotating residential proxies for monitors that load public product pages. Use sticky residential sessions for checkout, accounts, raffles, and queues on sites that favor consumer IPs. Test every list against the retailer before the drop.
| Job | Use | Why |
|---|---|---|
| Fast checkout on a site that accepts ISP IPs | ISP proxy, one per task | Static IP, steady latency, not a hosting range |
| Monitors on public product pages | Rotating residential, or ISP sized by delay | Each check stands alone, so the exit can change |
| Checkout, accounts, raffles, queues on residential-friendly sites | Sticky residential, one session per task | One identity from cart to payment |
| Any protected retailer | Not datacenter | Hosting ranges are the easiest traffic to classify |
Quick setup:
- Split your tasks by stage: account, monitor, queue, cart, and checkout.
- Give each account task its own sticky residential session. Do not share a session between accounts.
- Put monitors on rotating sessions or on ISP proxies, and size them with the delay calculator.
- Check the retailer against the site list before you buy any plan.
- Run the pre-drop test below at least one day before the release.
A proxy does not guarantee a checkout. Drops are competitive, retailers enforce limits, and a bad task setup fails even on clean IPs. Proxies let you run more tasks without stacking them on one IP, and they keep each session on a consistent identity. The same rules apply whether you run Refract, Cybersole, Wrath, Nike Shoe Bot (NSB), or Kodai, because the limits come from the retailer, not the bot.

ISP vs residential proxies for sneaker bots
This is the main decision. Compare the two on the points that matter during a release:
| Factor | ISP proxies | Residential proxies | Datacenter proxies |
|---|---|---|---|
| What the IP is | Static IP registered to an ISP, hosted on servers | Exit IP from a pool of consumer connections | IP from a hosting or cloud network |
| Speed | Fast and consistent | Varies by exit | Fast |
| Session | Fixed IP for the whole plan | Sticky (time window) or rotating | Usually fixed |
| Billing | Per IP, per month | Per GB of traffic | Per IP |
| Ban risk | A range ban can hit the whole list | Spread across many networks | Hosting ranges are easy to classify |
| Best bot stages | Monitors, account sessions, checkout | Account creation, raffles, queues, strict sites | Tested, low-security sites only |
| Main weak spot | A flagged IP stays flagged until replaced | Bandwidth cost and shared exits | Blocked on most protected sites |
ISP proxies are the default for speed-sensitive work. They are static, so one proxy can stay with one account or task for weeks, and latency stays predictable. They are also easy to count: you know exactly how many IPs you have.
Residential proxies are the default when IP diversity matters more than speed. Each exit comes from a consumer network, and sticky sessions keep one exit per task for a time window. Many strong setups use both types, one per bot stage.

Best sneaker proxies by bot stage
A sneaker bot does several different jobs during one release. Each job puts different pressure on the proxy, so one proxy type for everything is rarely the best setup.
| Bot stage | Best starting proxy | Session | Ratio to start with | Why |
|---|---|---|---|---|
| Account creation | Residential | Sticky | 1 session per account | New accounts from many unrelated consumer IPs look less linked |
| Account login and warming | Residential or ISP | Sticky | 1 session per account | The account, cookies, and IP must stay together |
| Raffle or draw entries | Residential | Sticky | 1 session per entry account | Many entries from one IP or one subnet are easy to link |
| Product monitoring (public pages) | Rotating residential or ISP | Rotating/static | Size with the delay calculator | Each check stands alone, but request rate per IP still counts |
| Queue or waiting room | Residential or ISP | Sticky | 1 session per task | A new IP in the queue can lose your place or reset the session |
| Cart and checkout | ISP or sticky residential | Sticky/static | 1 proxy per task | Checkout is the most session-sensitive step |
| Cookie or anti-bot harvesting | Depends on the bot and site | Sticky | Follow the bot's guide | The tasks often present the harvester's IP to the anti-bot system |
Two rules cover most of the table. If the next request depends on the previous one, keep the proxy sticky. If the request stands alone, rotation can spread the load. Our sticky vs rotating proxies guide covers the same rule outside of retail.
Sticky vs rotating sneaker proxies
Residential sneaker proxies usually come from a backconnect gateway. You connect to one host and port, and the gateway picks a residential exit IP for you. How long you keep that exit depends on the session mode. Our guide to backconnect rotating proxies explains the gateway in detail, and how to use residential proxies without breaking sessions covers session handling.
With Unknown Proxies residential plans:
- A sticky line holds one exit IP for up to 2 hours. Each line you generate in the dashboard gets its own session ID at the end of the password. Two lines with different session IDs are two separate sessions.
- A rotating line has no session ID. The gateway can assign a new exit IP on every request.
Rotating sneaker proxies are good for monitors and bad for checkout. A monitor that loads a product page does not care which IP loaded the last page. A checkout does. If the cart was built on one IP and the payment step arrives from another, the site can ask for extra verification, drop the cart, or fail the order without a clear error.
Two details catch people out:
- Rotation happens per connection. For HTTPS, the gateway picks the exit when your bot opens the tunnel. Requests that reuse an open connection keep that exit. A bot with keep-alive connections can send several requests from one "rotating" IP.
- Sticky sessions end. A sticky exit can change when the session window ends or when the exit goes offline. Generate fresh sticky lines close to the release and test them, so a session does not expire in the middle of a queue or checkout.
Which sites favor residential or ISP proxies
There is no permanent answer per site. Anti-bot systems change, and what passes this month can fail next month. Bot developers publish the best current guidance.
Refract's proxy documentation gives a useful starting point. It says sites with aggressive anti-bot systems (Walmart, and Target when Shape security is high) tend to favor residential proxies. It says sites where speed matters more than rotation (Amazon, Apple, Best Buy, and Target most of the time) tend to run fine on ISP proxies.
Provider support also differs per site. This is what our proxy site list shows for common retail sites as of October 2026:
| Site | Residential plan | Signature ISP | Event ISP |
|---|---|---|---|
| Nike.com | Yes | Yes | Yes |
| Supreme.com | Yes | No | No |
| Walmart.com checkout | Yes | Yes | Yes |
| PokemonCenter.com | Yes | Yes | Yes |
| BestBuy.com | Yes | Yes | Yes |
| Costco.com | Yes | Yes | Yes |
| Target.com checkout | No | Yes | Yes |
| Amazon.com | No | Yes | Yes |
| Apple.com | No | Yes | Yes |
Check the live list before you buy, because it changes as retailers change their protection.
Nike and SNKRS
Our site list shows Nike.com on the residential plan and both ISP tiers. Support is not the same as a guaranteed order. Nike's terms of sale, updated in October 2022, let it cancel orders placed with automated ordering software, and an Underpriced analysis (updated February 2026) notes that orders can be cancelled after checkout. Proxies keep tasks apart. They do not protect an order from review.
Footsites
Foot Locker, Champs Sports, and the other Foot Locker brands are now part of Dick's Sporting Goods. Dick's completed the roughly $2.4 billion acquisition on September 8, 2025 and kept the brands. The same Underpriced analysis says account age and loyalty history matter more than raw speed on Foot Locker family releases. Warm accounts on sticky sessions, one per account, and confirm Footsite support on the site list before you buy.
Shopify boutiques and Adidas Confirmed
The Underpriced analysis (February 2026) describes Shopify drops that use random password-page timing and Queue-it waiting rooms, and Adidas draws that randomize queue position. Both punish a session that changes IP midway. Keep one sticky session or one ISP proxy per task from queue to payment, and run the pre-drop test on the exact store.
Target, Walmart, Best Buy, Amazon, and Apple
Target is the most complex retail site for proxies, because tasks need anti-bot cookies from a harvester. Refract's current Target guide puts ISP proxies on monitors and uses your home IP or residential proxies for tasks and harvesters as you scale. The Refract Bot guide walks through monitors, tasks, and the in-bot harvester.
Proxies for AIO Bot, NSB, and other sneaker bots
The best proxies for AIO Bot, Nike Shoe Bot (NSB), Refract, Cybersole, Wrath, and Kodai follow the stage rules above. The bot does not change what the retailer accepts. Use the bot's own guide for the import steps, and use this guide to pick the proxy type.
Most sneaker bots import proxies as one line per proxy:
host:port:username:password
IP-authenticated plans use host:port only. The AIO Bot proxy guide shows both formats. Some bots also accept username:password@host:port. If a whole list fails with 407 errors, the line format is the first thing to check.
Keep monitor lists and checkout lists apart in every bot. A monitor list can rotate. A checkout list must keep one IP from cart to payment. For Target tasks in Refract, follow the Refract Bot guide.
How many sneaker proxies do I need?
Count task proxies and monitor proxies separately.
Task proxies
Start with one task per proxy. Refract's proxy setup page gives the same advice: ideally one task per proxy, with two or three tasks per proxy possible on some sites after testing.
With residential sticky sessions, "one proxy" means one generated line with its own session ID. So the practical rule is simple: generate at least as many sticky lines as you run account, queue, and checkout tasks.
This matters because of how bots assign proxies. Many bots shuffle the list and hand out the next line to each task. When the list runs out, they start again at the top. Refract documents exactly this behavior. If you paste 20 sticky lines for 40 tasks, every session carries two tasks, and the bot does not warn you.
Monitor proxies
On rotating residential lines, one line can serve several monitor tasks, because each new connection can get a new exit. Bandwidth becomes the limit, not the line count.
On ISP proxies, the per-IP request rate is the limit. Monitor proxy count depends on SKU count, monitor delay, and how many requests per minute the site tolerates per IP. The delay calculator does this math:
- Requests per SKU per minute = 60,000 ÷ delay in ms.
- Total load = requests per SKU × number of SKUs.
- Proxies = total load ÷ requests per proxy per minute that the site allows.
Worked example with the calculator's Target preset, which rests each proxy 9 seconds between requests (about 6.7 requests per minute per proxy): 5 SKUs at a 3,500 ms delay is about 86 requests per minute. 86 ÷ 6.7 is about 13, which the calculator rounds up to 15 monitor proxies.
Add 10 to 20 percent extra sticky lines as spares. When a session gets challenged or banned, swap in a spare instead of putting two tasks on one session.
Account and profile mapping
Treat proxy assignment as part of the account's state:
- One account maps to one browser profile.
- One browser profile maps to one proxy or sticky session.
- Cookies stay with the same proxy.
- Checkout tasks do not rotate mid-flow.
- If you change the proxy, start a fresh session.

Subnet and ASN bans, and why residential spreads risk
Retailers and anti-bot vendors do not only ban single IPs. They can ban or challenge a whole subnet (for example, a /24 block of 256 addresses) or a whole autonomous system number (ASN), which is the network that announces the IP range.
This changes how you plan:
- ISP lists are concentrated. A list of ISP proxies usually comes from a small number of IP ranges. Our 254-proxy ISP plans are a full /24 subnet. If a site bans that range, every proxy in it fails at the same moment.
- Residential exits are spread out. A residential pool draws exits from many consumer ISPs and many ranges. One range ban hits only the tasks that happened to use exits in that range.
- Residential exits are shared. The tradeoff is that an exit may already carry a bad history from someone else's traffic. That is why you retire a session after repeated challenges instead of retrying on it.
If a site returns Cloudflare's ASN block page, read our guide to Cloudflare Error 1005 (ASN banned). For ISP-heavy setups, splitting tasks across more than one subnet or region lowers the chance that one ban stops everything.
How to test sneaker proxies before a drop
Do not find out that a list is banned when the drop goes live. Test the day before, then again an hour before.
First, convert one line from host:port:user:pass to a URL. The proxy formatter does this for a whole list. Then run these checks from the same machine that runs your bot:
# 1. Exit IP and location. Run it twice on a rotating line: the IP should change.
curl -s -x "http://USER:PASS@HOST:PORT" https://ipinfo.io/json
# 2. Sticky hold. A sticky line should print the same IP five times.
for i in 1 2 3 4 5; do
curl -s -x "http://USER:PASS@HOST:PORT" https://api.ipify.org; echo
sleep 30
done
# 3. Status code and timing against the retailer.
curl -s -o /dev/null -x "http://USER:PASS@HOST:PORT" \
-w "%{http_code} connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
https://www.nike.com/
If the password contains characters such as @, :, or #, percent-encode them in the URL or curl will read the line wrong.
Read the results with care:
- A
407means the proxy rejected your credentials. Fix the format before you test anything else. - A
403or429from the retailer on a single request is a warning sign for that exit or range. - A
200does not prove the proxy passes the anti-bot check. Challenge pages can return200too.
The final test is a real one. Run a few tasks on an in-stock, low-cost product with the same proxies, profiles, and accounts you plan to use. Refract's documentation calls this the easiest way to check for flagged proxies: if test tasks check out, you are in good shape. Log the session ID, account, status code, and timestamp for every failure.
Delays, jitter, and backoff
A proxy cannot make an unsafe request rate safe. Set these values before you add tasks:
| Setting | What it controls |
|---|---|
| Monitor delay | How often each SKU or product page is checked |
| Retry delay | How long a task waits after an error before retrying |
| Jitter | Stops tasks from firing in perfect sync |
| Backoff | Slows traffic after repeated errors |
| Cooldown | Rests a struggling session before reuse |
| Stop condition | Stops a task that burns bandwidth on a broken flow |
Start from your bot's defaults. Refract, for example, defaults to 3,500 ms monitor and retry delays for Target and 4,500 ms for Walmart. If you lower delays and the error rate climbs, you are hitting rate limits. Our guide to HTTP 429 Too Many Requests explains how rate limits work and why instant retries make them worse.

Bandwidth planning for residential sneaker proxies
Residential plans are billed per GB, so your task design sets your cost.
Browser-based tasks load images, scripts, and fonts. Request-based tasks that hit lean endpoints use much less data. Retries and challenge pages add more. Do not guess: record one full task flow in your browser, export a HAR file, and check the total transfer size with the HAR analyzer. Then multiply by tasks, attempts, and runtime in the data usage calculator.
To cut wasted bandwidth:
- Separate monitor tasks from checkout tasks.
- Turn off image and media loading if your bot supports it.
- Cap retries and stop tasks that keep getting challenged.
- Remove SKUs that never restock from your monitors.
When ISP proxies beat residential for sneaker bots
Residential is not always the best choice. Pick ISP proxies when:
- The site is not on the residential list, as with Target, Amazon, and Apple on our site list.
- Latency matters more than IP diversity, such as fast monitors and first-come checkouts.
- You want one fixed IP per account for weeks, longer than a sticky window.
- Browser-heavy tasks would use too much residential bandwidth.
Many strong setups use both. ISP proxies handle monitors and fast checkout, and residential sessions handle account creation, raffles, and sites that favor residential traffic. The ISP proxies vs residential proxies guide compares the two categories outside of retail.
Private and dedicated sneaker proxies
Private sneaker proxies and dedicated sneaker proxies mean the same thing in most listings: only one customer uses the IP. Shared proxies put other users' tasks on the same IP, so one user's ban can hit your tasks too.
- ISP proxies are sold per IP. Ask the provider if each IP is dedicated. Our ISP proxies are dedicated, one customer per IP.
- Residential proxies come from a shared pool of consumer connections. A sticky session gives your task one exit for a time window. It does not make that exit private forever.
- "Private" does not mean "clean on every site". A dedicated IP can still be in a range that a retailer flags, so test it before the drop.
For checkout on sites that accept ISP traffic, dedicated ISP proxies are the closest match to what most people mean by private sneaker proxies.
Datacenter and mobile proxies for sneakers
Datacenter proxies are a poor fit for most protected sneaker sites. Hosting-network IPs are the easiest traffic for anti-bot systems to classify, and sneaker retailers are the kind of site that blocks those ranges. Use them only on sites you have tested and know accept them. The datacenter vs residential proxies guide explains why ISP proxies sit between the two.
Mobile proxies show up in many sneaker roundups. Refract's proxy documentation covers residential and ISP only, and we sell ISP and residential, so this guide does too. If a bot's own guide asks for mobile IPs on a specific site, follow the bot.
How to choose a sneaker proxy provider
Before you buy sneaker proxies, check each sneaker proxy provider against this list:
| Check | What to look for |
|---|---|
| Site support | A published list of the retailers the plan is tested on |
| Dedicated IPs | ISP IPs that nobody else uses |
| Subnet spread | IPs from more than one subnet, so one range ban does not stop all tasks |
| Region | Hosting near the retailer's servers |
| Replacement policy | A clear rule for replacing IPs that a retailer flags |
| Billing | Per IP for ISP, per GB for residential, and no forced long terms |
| Proxy format | host:port:username:password lines that your bot can import |
Do not pick a provider from a "best sneaker proxies" list alone. Run the pre-drop test on the retailer you plan to run, with a small plan first.
Choosing an ISP plan and region for sneaker bots
Unknown Proxies sells three ISP tiers. The plan features on our pricing page define what each tier is for:
| Plan | Built for | Regions |
|---|---|---|
| Utility ISP | Monitoring, accounts, and web scraping | US East Coast, US West Coast |
| Signature ISP | Adds retail purchases to the Utility use cases | US East and West Coast, UK, NL, DE, IT, FR, Asia, AU |
| Event ISP | Retail purchases, event tickets, and accounts | US East Coast, US West Coast |
A common split is Utility for monitors and Signature for checkout tasks. The site list shows which tier supports each retailer. New to the category? What are ISP proxies explains how a static IP can be registered to an ISP.
For region, pick the one closest to the retailer you run. Our US ISP proxies are hosted in Ashburn (Virginia), New York City, and San Francisco. Refract's server notes point out that many retailer backends are hosted in Virginia, which is one reason East Coast IPs are popular for US releases. For EU retailers, use a Signature region in the same country or nearby.
Troubleshooting sneaker proxy errors
Not every failure is a bad proxy. Check the cause first. Most drop problems need logs, not guesses: record the proxy, account, profile, SKU, task, status code, and timestamp.
| Symptom | Likely cause | First check |
|---|---|---|
| 407 on every task | Wrong credentials or format | Line format, username, password, session suffix |
| Everything fails at once on ISP | One subnet range banned | Split tasks across subnets or add residential |
| 429 or rate limit | Delay too low, retries too fast | Increase delay and add backoff |
| 403 or access denied | Exit or range flagged, or a fingerprint problem | Retest with fresh sessions and a clean profile |
| Logged out mid-flow | Rotating line on an account task, or session expired | Use a sticky line and regenerate before the drop |
| Cart disappears | IP or session changed between cart and checkout | Keep account, cookies, proxy, and region together |
| Many tasks fail together | Subnet or ASN ban, or two tasks per session | Count lines vs tasks and check the failing ranges |
| Bandwidth drains fast | Browser-heavy tasks or retry loops | Block media and cap retries |
FAQ
What are sneaker proxies?
Sneaker proxies are proxies used by sneaker and retail bots for monitoring, account sessions, raffles, queues, carts, and checkout. They let each task use its own IP instead of your home connection. "Private" sneaker proxies usually means dedicated, so only you use the IP.
Are residential or ISP proxies better for sneaker bots?
It depends on the site and the stage. ISP proxies are fast and fixed, so they fit monitors and checkout on sites that accept them. Residential proxies spread risk across many networks, so they fit accounts, raffles, queues, and sites that favor consumer IPs. Many setups use both.
Are rotating sneaker proxies good for checkout?
No. Rotating proxies are good for monitors, because each product check stands alone. Checkout needs one IP from cart to payment, so use a sticky residential session or an ISP proxy.
How many proxies do I need per task?
Start with one proxy or sticky line per task, plus 10 to 20 percent spares. Some sites tolerate two or three tasks per proxy, but test that before a release. Monitors on rotating lines are limited by bandwidth, not line count.
Do datacenter proxies work for sneakers?
Rarely on protected sites. Datacenter IPs belong to hosting networks that anti-bot systems classify quickly. Use them only on sites where your own tests show they pass.
Do you need proxies for sneaker bots?
Yes, if you run more than a few tasks. Retailers limit requests and orders per IP, so many tasks on one home IP get blocked or cancelled. Proxies give each task or account its own IP. For one or two manual tasks, your home connection can be enough.
Are free sneaker proxies worth using?
No. Free proxies are shared by many users, are often already flagged by retailers, and give the operator a view of your traffic. A dropped session mid-checkout costs more than a small paid plan.
Do sneaker proxies guarantee a checkout?
No. Stock, competition, account health, profiles, delays, and the retailer's rules all affect the result. Retailers can also cancel orders they flag as automated, so read the terms of each store you run.
Final thoughts
Set up sneaker proxies per stage, not per brand name. Use ISP proxies for checkout on sites that accept them, rotating residential for monitors, and sticky residential for accounts, raffles, queues, and sites that favor consumer IPs. Size monitors from SKU count and delay, keep one task per proxy or session, and test lists the day before the drop. When you are ready to buy, compare ISP proxy plans for monitors and fast checkout, and residential plans for sticky and rotating sessions.
Technical references: MDN Proxy servers and tunneling, MDN HTTP cookies, curl write-out variables, and RFC 6585 section 4 for HTTP 429.
