How to set up proxies in a sneaker bot, the right way

Every major bot speaks the same proxy language, so setup is the same five steps everywhere — and so are the mistakes. This is the whole process, from pasted list to drop-ready tasks.

1. Get the list in the right format

The universal format is one proxy per line: ip:port:username:password. Porter’s dashboard outputs exactly that for ISP plans, and the residential generator produces lists in whatever format your tool ingests. If a bot rejects a list, the cause is almost always formatting — a stray space, a missing field, Windows line endings — not the proxies.

2. Create separate proxy groups

Make at least two groups and keep them apart for the life of the setup: a checkout group of static ISP IPs, and a monitor group on rotating residential. Bots assign groups to tasks, so this split — the single highest-leverage choice in the whole setup — is one dropdown once you have made the groups. Why it matters so much is covered in why proxies get banned on release day.

3. Pick an auth mode

Username:password is the default: credentials ride along in the list and work from any machine. IP whitelist authorises your server’s IP instead, so the proxies accept its connections with no credentials — marginally less setup friction on a dedicated server, useless on a connection whose IP changes. Porter plans switch between the two from the dashboard; residential access is username:password. If unsure, use username:password.

4. Assign one proxy per task

The rule from the sizing guide applies at assignment time: every checkout task gets its own IP, and account-bound tasks keep the same IP permanently. Most bots do 1:1 assignment automatically when the group size matches the task count — which is itself the sizing rule in action. Never set a checkout task group to rotate.

5. Test before the queue, gently

Run your bot’s proxy tester once to catch auth typos and dead entries — that is what it is for. What it is not for is hammering: speed-test loops against the target site are monitor traffic on your checkout IPs, the exact pattern step 2 exists to prevent. One clean pass, then let the list sit quiet until the drop. On residential, remember tests spend GB like any other traffic.

The mistakes that burn lists

• Monitoring on checkout IPs — walks your cleanest identities into the store pre-flagged.
• Rotation enabled on checkout tasks — an IP change mid-purchase reads as session hijacking.
• Reusing last season’s burned list — a range that limped through its last release starts the next one already scored. Swap subnets instead; on Porter plans that is self-serve.
• One list across two bots at once — doubles the apparent activity of every IP without doubling your entries.

That is the entire setup. Buy during the queue if you have to — delivery is instant — but the list that wins is the one that was grouped, assigned and tested the night before.