How Many Proxies Do You Need for a Sneaker Bot?

The rule of thumb

The traditional sneaker rule is one proxy per task. It's a good default because it keeps each task's traffic separate, avoids per-IP rate limits, and reduces the chance of orders being linked by IP. But it isn't always necessary, and sometimes it isn't enough.

This guide gives practical ratios by site type and shows how to calculate the number you actually need. For the bigger picture, see sneaker proxies.

Recommended task-to-proxy ratios

How to calculate your proxy count

checkout proxies = tasks per site ÷ tasks per proxy × (1 + buffer)

Use a 20 to 30% buffer to replace slow or banned proxies on release morning.

Example: you plan 40 tasks on a footsite release and 30 tasks on a Shopify release at the same time.

• Footsite: 40 ÷ 1 × 1.25 = 50 ISP proxies.
• Shopify: 30 ÷ 1 × 1.25 ≈ 38 ISP proxies (or fewer if the store is lenient).
• If the releases are at different times, you can reuse proxies across them, but rest heavily used ones.

When more proxies stop helping

More proxies only help if you have the accounts, payment methods and profiles to match. If a retailer limits one pair per customer and links orders by card and address, 200 proxies with 5 profiles still means at most 5 successful orders, and probably fewer after cancellations. Scale profiles and proxies together.

More tasks also mean more load on your server. Make sure your bot server can handle the task count. See sneaker bot server location.

Splitting proxies by role

Never use monitor proxies for checkout tasks. See sneaker monitor proxies.

Residential: count sessions, not proxies

With rotating residential, you buy bandwidth, not IPs. Generate as many sticky-session lines as you have tasks. The number of "proxies" is effectively unlimited; the cost is the data your tasks use. See residential proxies for sneakers.

Budget planning

If budget is tight, run fewer tasks with better proxies rather than many tasks on poor proxies. Ten tasks on clean ISP proxies usually beat 50 tasks on burned ones. See cheap sneaker proxies.

Worked example: a weekend with three releases

If the Saturday releases don't overlap, some ISP proxies can serve both, but rest the heaviest-used ones and keep them separate from monitors.

Matching proxies to profiles

More tasks than profiles can make sense on some sites (multiple attempts per profile), but past a point you're just multiplying load and risk.

When to add more proxies

• Many tasks failing with rate-limit errors.
• Long waits caused by per-IP throttling.
• Expanding to more sites at the same time.

When to add fewer

• Most failures are from profiles or payment, not IPs.
• You're seeing post-checkout cancellations.
• Budget is better spent on better-quality proxies.

See cheap sneaker proxies and best proxies for sneaker bots.

A calculator you can copy

If you plan several releases a month, put the arithmetic in a few lines of code so you can change the inputs quickly:

def proxies_needed(tasks, tasks_per_proxy, monitors=0, backup_share=0.2):
    checkout = -(-tasks // tasks_per_proxy)      # round up
    backups = round(checkout * backup_share)
    return {"checkout": checkout, "monitors": monitors,
            "backups": backups, "total": checkout + monitors + backups}

print(proxies_needed(tasks=60, tasks_per_proxy=2, monitors=10))
# {'checkout': 30, 'monitors': 10, 'backups': 6, 'total': 46}

Use the ratios from the table above for tasks_per_proxy, set monitors to zero if you rely on a shared monitor, and adjust backup_share to how often your seller's IPs fail on the target. Multiply the total by the per-IP price for a quick budget.

A few rules of thumb keep the output realistic:

• Count concurrent tasks, not total tasks across a weekend; IPs can be reused between releases.
• Round up for checkouts and down for monitors.
• Plan backups as a separate group, so they're fresh when you need them.

For pricing the result, see cheap sneaker proxies; for which type to buy, best proxies for sneaker bots; and for residential plans, where you count sessions rather than IPs, residential proxies for sneakers.

Key takeaways

• One proxy per task is the safe default; lenient Shopify stores may tolerate two.
• Add a 20 to 30% buffer for replacements on release morning.
• Scale proxies with profiles and accounts, not on their own.
• Residential raffles need bandwidth rather than a fixed IP count.
• Monitors need their own separate pool. See sneaker proxy setup guide.

FAQ

Can I run 100 tasks on 10 proxies?

On strict sites, you'll likely be rate-limited or banned. On lenient sites, it may work for some tasks, but success per task drops.

Do I need different proxies for each release?

Not necessarily. Reuse good proxies, but rest ones that were heavily used and replace ones that got banned.

How many proxies for raffles?

One unique IP per entry, which rotating residential proxies handle automatically.