Proxies for Sneaker Bots: Which Type for Each Stage
Which proxy type fits each sneaker bot stage: residential for account and checkout tasks, datacenter for stock monitors, one exit per task.
A sneaker bot does three jobs, and each one wants a different proxy. The checkout and the account it runs on need residential exits in the release region, one per task. The stock monitor that watches for a restock or a page going live can run on datacenter exits, which are faster and cheaper. Account warm-up sits with checkout, on residential. Getting this split right matters more than any single proxy setting. Node4 sells each type compared here, so this is a guide to choosing types for each stage, not a ranking of providers. Check each store's terms before you run tasks against it; many restrict automated purchases.
Plan the drop before you buy proxies
Write down the tasks first, then match proxies to them. For example, a plan for a small US drop on a Shopify store might look like this (the data figures are rough estimates; measure your own bot):
| Stage | Tasks | Proxy | Session | Rough data |
|---|---|---|---|---|
| Monitor product page | 2 | Rotating Datacenter, US | none; exit picked per tunnel or request | a few hundred MB a day of polling |
| Account warm-up (days before) | 10 accounts | Residential, -country-us-state-ny | one session ID per account, reused each sitting | small; normal browsing |
| Checkout on release | 10 tasks | Residential, -country-us-state-ny | same region and session ID as its account | about 5 to 20 MB per attempt |
Two rules come out of the table. Each account keeps one region and its own session ID from warm-up through checkout, so the store sees one shopper in one place move from browsing to buying, not ten accounts sharing one address. A session ID holds an exit for 30 minutes at most, so a warm-up days earlier and the drop will normally run on different addresses; the fixed region is what keeps the account's history consistent. And the monitor never touches an account, so its datacenter exits cannot drag an account's history down.
Residential is billed per gigabyte, but checkout traffic is small. On those estimates, ten tasks at 20 MB each, across three retries, is about 600 MB for the drop. The number that grows is warm-up browsing over several days, so keep it to the pages a shopper would actually open.
Proxy types for sneaker bots, compared
| Proxy type | Stage | Exit locations | Billed by | Main limit |
|---|---|---|---|---|
| Residential | Accounts, warm-up, checkout | 170+ countries; country, state and city targeting | Gigabyte | Partner-network devices; sessions best effort, up to 30 min |
| Rotating Datacenter | Stock monitors | US, Italy, Spain (Node4-owned blocks) | Gigabyte | Hosting-network addresses; many stores block them at checkout |
| Rotating Unmetered | Many monitors polling all day | US, Italy, Spain (Node4-owned blocks) | Concurrent connections | Same exits as Rotating Datacenter |
| Dedicated datacenter | A monitor on a fixed address | US, Italy, Spain (Node4-owned blocks) | Proxy per month, no data cap | Hosting-network address |
| Shared datacenter | Testing the bot's flow before a drop | US, Italy, Spain (Node4-owned blocks) | Proxy per month, pooled data | Up to five customers per address |
Checkout and accounts: residential, one session per task
Residential exits come from a partner network of consumer devices, not Node4's own blocks, which is why a store sees a home connection rather than a hosting company. Put the release region in the username, and add a session ID per task:
USERNAME-country-us-state-ny-session-acct07Residential sessions are best effort, with a 30-minute ceiling, and can end sooner if the device behind the exit goes offline, so a long queue page can outlast one. Have the bot check its exit when it enters the queue and again before submitting payment, and if it changed, restart that task on a new session ID in the same region rather than submitting from a different address mid-checkout. The segment grammar is in country and city targeting, and session behavior on every product is in sticky vs rotating sessions.
Plan sizes are on residential pricing.
Monitors: datacenter, fast and cheap
A monitor polls a product page or a store's product feed every few seconds and fires when stock appears. It needs speed and steady exits, not a shopper's address. Node4's datacenter exits come from blocks it owns in the US, Italy and Spain.
- Rotating Datacenter picks an exit from the pool for each new proxy connection, which spreads polling across many addresses so no single one hits the store thousands of times. The pick is independent each time, so two connections in a row can share an exit. Billed per gigabyte; polling a product feed rather than the full page keeps that small. See rotating plan prices.
- Rotating Unmetered uses the same exits billed by concurrent connections. If you run monitors for dozens of products across several stores all day, connection pricing is easier to predict. See connection-based pricing.
- Dedicated datacenter gives one fixed address with no data cap; fine for one monitor, but a single address polling every second gets rate limited quickly.
- Shared datacenter is for dry runs: confirm your bot parses the product page and reaches the cart on a test store before release day.
For drops outside the US, Italy and Spain, the monitor needs residential exits as well, because the store may show a different product page per country.
Which types to buy
Buy residential for everything that touches an account: warm-up, queue and checkout, with one session ID per account in the release region. Buy Rotating Datacenter for monitors, and switch to Rotating Unmetered once you run enough monitors that connection pricing beats per-gigabyte pricing. Keep shared proxies for testing the flow before a drop. For how rotation and retries behave under load, see rotating proxies for web scraping; for choosing between rotating residential and datacenter in general, see rotating residential or datacenter; for the same decision generalized across bot workloads beyond sneaker drops, see the best proxy for bot automation.