Webshare Bandwidth and Threads: How Plan Limits Affect Your Proxies

Two limits on most plans

Webshare's per-proxy plans (datacenter and static residential) are shaped by two settings besides the number of IPs:

• Bandwidth: how much data the plan can move in a billing period.
• Threads: how many connections you can run at the same time.

Residential plans are simpler: the plan size is the bandwidth. Getting these settings right is the difference between a cheap plan that works and one that mysteriously fails under load.

Bandwidth

At the time of writing, Webshare proxy list plans start with an allowance in the hundreds of GB and can be raised up to "unlimited", subject to a fair usage policy. Higher allowances cost more.

How to estimate what you need:

1. Run a sample of your real job on a small plan or the free plan.
2. Check bandwidth used in the dashboard and divide by the number of pages or requests.
3. Multiply by your expected monthly volume and add 30% for retries and growth.

Typical figures: HTML-only scraping often uses 50 to 300 KB per page; full browser loads use 1 to 5 MB per page or more. Our guide to proxy bandwidth pricing has more examples.

Unlimited isn't infinite. Fair usage policies exist to stop a few users from overloading shared infrastructure. If you plan to move very large volumes on an unlimited plan, read the policy first. See unlimited bandwidth proxies.

Threads

Threads are concurrent connections. Webshare plans range from hundreds to a few thousand threads at the time of writing. If your scraper opens more connections than the plan allows, extra connections are refused or queued.

How to estimate threads:

• Requests per second times average response time = concurrent connections. For example, 50 requests per second at 2 seconds each needs about 100 threads.
• Browsers open several connections per page, so a headless browser fleet needs more threads than the same number of plain HTTP workers.
• Leave headroom of 20 to 30% for slow responses.

Signs you're hitting a limit

Cutting bandwidth use

• Fetch HTML or JSON, not full pages, whenever the data is in the source or an API.
• Block heavy resources in headless browsers: images, fonts, media and third-party scripts you don't need.
• Use compression. Send Accept-Encoding: gzip, br (most clients do by default).
• Cache pages that don't change between runs.
• Avoid needless retries. Back off on blocks instead of hammering.
• Check for conditional requests (ETag, Last-Modified) on sites that support them.

Choosing settings for common jobs

Worked sizing example

A team plans to monitor 20,000 product pages four times a day through a datacenter list, using HTML-only requests averaging 200 KB and two seconds each.

• Requests per day: 20,000 x 4 = 80,000.
• Bandwidth per month: 80,000 x 30 x 200 KB = about 480 GB.
• Requests per second (spread over 16 hours): about 1.4.
• Concurrent connections: 1.4 x 2 s = about 3, so even the lowest thread tier is plenty.

Here bandwidth, not threads, drives the plan choice. A headless browser job would flip that: fewer pages, but many more connections and far more data per page.

Tuning concurrency

1. Start at a modest concurrency, for example 20.
2. Double it and watch success rate, latency and errors.
3. Stop when errors rise or latency jumps.
4. Settle about 20% below that point.

If the limit you hit is the plan's thread count, raising threads helps. If it's the target's rate limit, more threads make things worse.

Bandwidth alerts

Set an alert when monthly usage passes 70 to 80% of your allowance. It gives you time to optimise or upgrade before requests start failing near the end of the cycle.

Unlimited plans in practice

Unlimited bandwidth on proxy lists is great for heavy datacenter jobs, but fair usage still applies. If you plan to move many terabytes, ask Webshare what's acceptable for your use case before you build a pipeline around it.

A real-world example

A team running 30 headless browsers sees timeouts every afternoon. Bandwidth usage is well within the plan, so they test concurrency: errors start at about 450 simultaneous connections, which matches their plan's thread limit, because each browser opens 15 or more connections per page. They raise the thread tier and block images and fonts, which cuts both connections per page and bandwidth. The timeouts stop, and the bandwidth saving offsets most of the extra cost.

Not sure this is the right proxy type for the job? The best proxies in 2026 guide compares residential, ISP, datacenter and mobile options, and our cheap proxies guide covers budget picks that still work.

Key takeaways

• Per-IP plans are shaped by bandwidth (data per period) and threads (simultaneous connections).
• Estimate bandwidth from a sample run, and threads from requests per second times response time.
• Errors that appear only at high concurrency usually mean a thread limit, not a block.
• Unlimited bandwidth is subject to fair use.
• HTML-only fetching, resource blocking and caching cut bandwidth substantially.

FAQ

What happens if I run out of Webshare bandwidth?

Requests stop working until the next billing period or until you upgrade the plan. Watch usage in the dashboard to avoid surprises.

Is unlimited bandwidth worth it?

If you move a lot of data through a per-proxy plan, often yes. For residential traffic, bandwidth is the plan itself.

Do threads limit the number of proxies I can use?

No. Threads limit simultaneous connections, not how many IPs you rotate through.

Do residential plans have thread limits?

Residential plans are sized by bandwidth. Practical concurrency limits still apply, so ramp up gradually.

Can I change bandwidth mid-cycle?

You can upgrade your plan from the dashboard; check how changes are billed for your plan.

Does compression reduce bandwidth usage?

Yes. Most clients request compressed responses by default, which can cut transfer sizes substantially.