How to Test Webshare Proxies Before You Scale: A Simple Test Plan

Why test on your own targets

Proxy performance depends far more on your targets than on a provider's marketing. A datacenter list that works perfectly on one site can be blocked on the next. The only way to know is to test with your real code against your real targets. Webshare's free plan and small paid plans make that cheap. General principles are in how to test proxies before buying.

What to measure

Step 1: pick a fair sample

• Choose 3 to 5 representative targets, including your hardest one.
• Use 200 to 500 requests per target per product. Fewer gives noisy results.
• Spread tests over a few hours, not one burst, because block rates rise with speed.
• Use the same code, headers and concurrency for every product you test.

Step 2: test datacenter first

Start with the free plan or a small shared datacenter list. Datacenter IPs are by far the cheapest, so if they work on a target, you're done for that target.

Step 3: test residential on the targets that failed

Buy the smallest rotating residential plan and run the same test on the targets where datacenter failed. If the job involves logins or long sessions, also test a few static residential IPs.

Step 4: a minimal test script

import time, statistics, requests

def run(url, proxy, n=200, check=lambda r: r.status_code == 200):
    ok, times, bytes_ = 0, [], 0
    for _ in range(n):
        t = time.time()
        try:
            r = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=30,
                             headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"})
            if check(r):
                ok += 1
                bytes_ += len(r.content)
        except requests.RequestException:
            pass
        times.append(time.time() - t)
        time.sleep(1)
    return {"success": ok / n, "median_s": statistics.median(times),
            "p95_s": sorted(times)[int(n * 0.95) - 1], "mb_per_1k": bytes_ / max(ok, 1) / 1e3}

Replace the check function with something that confirms the data is really there (for example, that a price element exists), because many blocks return a 200 with a challenge page.

Step 5: turn results into cost

• Datacenter and static residential: monthly plan cost divided by successful requests per month at your measured rate.
• Residential: (MB per 1,000 successes x price per MB) / success rate.

A product with a higher sticker price but a much higher success rate is often cheaper per result.

Reading the results

Comparing with a second provider

Run the same script with another provider's credentials for a true comparison. Many buyers test Geonode alongside Webshare, since Geonode's residential pricing and non-expiring bandwidth suit different usage patterns. See Webshare vs Geonode speed and reliability.

A test log template

Record each test run in a simple table so results are comparable:

Keep the log; re-tests in later months are much more useful when you can compare against a baseline.

Testing at realistic concurrency

A test at one request per second can pass while production at 50 per second fails. After a basic pass, run a short test at your planned concurrency, and watch for rising errors as you ramp up. Stay within your plan's thread limit.

Avoiding misleading results

• Don't test only at night; residential availability and site defences vary by time.
• Don't test only one URL; use a sample of real pages.
• Don't count 200s as success without checking content.
• Don't compare products with different code or headers.

When to re-test

Re-test monthly, after any major change to your scraper, and whenever success rates drop. Sites update their defences regularly, so a target that worked on datacenter IPs last quarter may need residential now, or the reverse.

A real-world example

A team choosing proxies for a new monitoring product tests five retailers. Webshare's free plan passes on three retailers with 99% success. On the other two, datacenter success is 35% and 50%. A small residential plan on those two gives 92% and 95%. Converting to cost per 1,000 successes shows datacenter costing a fraction of a cent and residential well under a dollar, so they launch with datacenter for three retailers and residential for two, and schedule a monthly re-test.

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

• Test on your own targets with your real code; marketing claims don't predict your results.
• Measure content-verified success, latency, bandwidth per success and cost per 1,000 successes.
• Test datacenter first, then residential only on the targets that fail.
• Use enough requests, spread over time, at realistic concurrency.
• Keep a test log and re-test monthly.

FAQ

How long should a proxy test take?

A few hours spread over a day is enough for a first decision. Re-test monthly, since sites change their defences.

Can I test Webshare residential for free?

The free plan covers datacenter proxies only. Use the smallest residential plan to test residential traffic.

What success rate is good?

It depends on the target. Above 95% is excellent for most scraping. Heavily protected sites may justify accepting lower rates with retries.

What sample size should I use?

At least 200 to 500 requests per target per product, spread over several hours.

Should I test with my production code?

Yes. Different clients and headers produce different results, so test what you'll actually run.

How do I compare Webshare with another provider fairly?

Use identical code, targets, locations, concurrency and time windows, and compare cost per successful result.