How to Run a Proxy Trial That Tells You Something

A trial answers four questions well and three questions badly. Knowing which is which keeps you from spending a limited byte budget on things you will not learn.

It answers well: does this provider reach my targets at all, at what success rate, at what latency under my concurrency, and does the pool behave the way the marketing describes.

It answers badly: long-run stability, how the pool degrades under sustained load over weeks, how support responds to a real incident at 3am, and whether the addresses you were given during a trial resemble the addresses you get as a paying customer. The last one is structural and gets its own section below.

So the trial is a filter, not a verdict. Its job is to eliminate providers that fail on your targets and rank the survivors on measured numbers rather than published ones. The verdict comes from a short first paid month, which is why the refund window on a trial matters at least as much as the trial itself.

Write the script first. Point it at your targets through your current provider or through no proxy at all, confirm it runs, then sign up. This single reordering is worth more than any other advice here, because it converts a three-day trial into three days of measurement rather than one day of measurement and two days of setup.

The harness needs to do four things: issue requests at a configurable concurrency, record status code, response bytes and elapsed time for every request, survive exceptions without stopping, and write results somewhere you can aggregate. Fifty lines of Python covers it.

import collections, concurrent.futures, statistics, time
import requests

GATEWAY = "http://USER:PASS@gateway.sparkproxy.io:11000"
PROXIES = {"http": GATEWAY, "https": GATEWAY}

def probe(url):
    started = time.perf_counter()
    try:
        r = requests.get(url, proxies=PROXIES, timeout=20)
        return r.status_code, len(r.content), time.perf_counter() - started
    except requests.RequestException as exc:
        return type(exc).__name__, 0, time.perf_counter() - started

def run(urls, concurrency):
    rows = []
    with concurrent.futures.ThreadPoolExecutor(max_workers=concurrency) as pool:
        rows.extend(pool.map(probe, urls))
    return rows

rows = run(TARGET_URLS, concurrency=50)
codes = collections.Counter(status for status, _, _ in rows)
ok = codes.get(200, 0)
latencies = sorted(seconds for _, _, seconds in rows)
p50 = latencies[len(latencies) // 2]
p95 = latencies[int(len(latencies) * 0.95)]
total_mb = sum(size for _, size, _ in rows) / 1_048_576

print(f"n={len(rows)}  success={ok / len(rows):.1%}  p50={p50:.2f}s  p95={p95:.2f}s")
print(f"bytes used={total_mb:.1f} MB  mean={total_mb / len(rows) * 1024:.0f} KB/request")
print(codes.most_common())

TARGET_URLS must be your own targets. Testing a proxy against an IP checker measures the IP checker. The byte counter in that output is not decoration: on a metered trial it is the meter, and you want to see it before you burn the allowance.

Ten minutes, almost no bytes, and it eliminates providers before you spend the rest of the budget.

Test every access path you intend to use in production, not just the easy one:

• Username and password auth on the HTTP port. The common case.
• IP whitelisting, if your runners have stable egress addresses. Check how many whitelist slots the plan carries and how fast a change takes effect. SparkProxy's plans, for example, carry 5 slots on Starter through 25 on Plus.
• SOCKS5, if anything other than a browser or an HTTP client goes through the proxy. On SparkProxy's gateway that is port 13000, against 11000 for HTTP and HTTPS and 11002 for sticky sessions.
• Sticky sessions, if any workload needs to hold one exit across several requests. Confirm the session actually holds by fetching your egress address twice and comparing.
• HTTPS through a CONNECT tunnel, which is what almost all real traffic uses and which occasionally behaves differently from plain HTTP.

Record what fails. A provider that supports only whitelist auth is unusable from cloud runners with dynamic egress, and that is a hard disqualification rather than a mark against them.

Three quick checks that catch misconfiguration and misrepresentation.

Where do you actually egress? Fetch your apparent address through the proxy and confirm it is not yours. Obvious, and people skip it, and then find out their scraper has been hitting a target directly for a week.

Does DNS resolve through the proxy? A SOCKS5 client resolving names locally leaks your resolver and, on geo-sensitive targets, your real region. Our proxy DNS leak testing guide has the procedure and the fix.

Is the geography real? Request a US exit and check where the address actually geolocates, in more than one database. Geolocation records disagree with each other routinely, and a provider selling city targeting should survive being checked against the databases their targets use. Validating IP geolocation accuracy covers how to do this without trusting a single source.

Budget: perhaps 2 MB. Value: high, because a failure here invalidates every other measurement you take afterwards.

This is the measurement everyone runs and almost nobody sizes. Success rate is a proportion estimated from a sample, so it carries a confidence interval, and a difference smaller than that interval is not a difference.

For a proportion around 90 percent, the 95 percent confidence margin is approximately 1.96 × sqrt(0.9 × 0.1 / n):

Read that table against your trial allowance and something useful falls out. A 100 MB trial on 150 KB pages buys about 680 requests, which resolves success rate to roughly plus or minus 2.2 points. That is enough to tell a 95 percent provider from an 80 percent one, and not enough to tell 93 percent from 95 percent.

Which produces the most actionable tip in this article: spend trial bytes on your lightest target page. If your target serves a small JSON endpoint or a compact listing page, point the harness there. Dropping average response size from 400 KB to 40 KB multiplies your sample size by ten on the same allowance, and success rate is a property of the route, not of the page weight.

Two rules for counting honestly. A 200 that returns a challenge page is a failure, so check content length and a known string, not just the status code. And count timeouts and connection errors as failures, because in production they cost you a retry exactly like a 403 does. Our explainer on measuring proxy success rate covers the classification edge cases.

Average latency is the least useful number in proxy evaluation. Report percentiles, and measure them under load.

Why percentiles. A pool with a 400 ms median and a 9 second p99 will look identical on an average to a pool with a 900 ms median and a 1.5 second p99, and the second one is far better for a scraper. Throughput is governed by the slow tail, because a request stuck at the timeout occupies a worker for the full timeout.

Why under load. Serial testing measures the network. Concurrent testing measures the provider's capacity allocation to you, which is what you are buying. Run the harness at the concurrency you intend to use in production, then run it again at double, and watch what happens to p95. A pool that holds its p95 as concurrency doubles has headroom. One where p95 triples does not.

Record these four numbers per run: p50, p95, p99 and the timeout rate. Then do one thing almost nobody does: repeat the run at a different hour of day. Residential and shared pools vary with the availability of their underlying addresses, and a Tuesday 03:00 UTC result is not a Tuesday 15:00 UTC result. If a provider is only good at quiet hours, you want to know inside the trial. Our piece on proxy latency and speed covers what each component of the number is made of.

This measurement costs almost nothing and drives more of your bill than anything else on the list.

Hold one exit address, either through a sticky session or a static address, and issue requests to your target at production pacing until the responses change. Count them. That count, call it T, is how many requests one address is worth on this target.

T decides two things:

1. How many addresses your workload needs, which is monthly requests divided by T times the address lifetime. On per-IP pricing this is the entire bill.
2. Whether rotation is even the right product. A target tolerating thousands of requests per address does not need a big pool. A target tolerating forty does, and no amount of rotation logic fixes it if the pool is small.

Record the failure mode as well as the count. A clean 429 with a Retry-After header is a target telling you how to behave. A silent switch to a cached or degraded page is a target lying to you, and it is the more common outcome on commercial sites.

Budget: a few hundred small requests. Value: this is the number that makes a per-IP versus per-GB comparison possible at all.

Providers publish IP counts. Targets block prefixes. Those are different units, and the gap between them is where "one million IPs" turns into a pool a target treats as a handful of networks.

Count distinct addresses and distinct /24 blocks across a few hundred rotating requests:

import ipaddress, collections
import requests

seen = []
for _ in range(300):
    ip = requests.get("https://api.ipify.org", proxies=PROXIES, timeout=15).text.strip()
    seen.append(ip)

blocks = {ipaddress.ip_network(f"{ip}/24", strict=False) for ip in seen}
print(f"{len(set(seen))} distinct IPs across {len(blocks)} distinct /24 blocks")
print(collections.Counter(str(ipaddress.ip_network(f'{ip}/24', strict=False))
                          for ip in seen).most_common(5))

The ratio is the interesting part. Three hundred requests returning 280 distinct addresses inside 4 subnets is a much weaker pool than 300 requests returning 120 addresses across 60 subnets, whatever the marketing says about pool size. Proxy pool size claims explains why the headline number is close to meaningless, and what subnet proxies are covers why the prefix is the unit that gets blocked.

Cost: 300 tiny responses, a few hundred kilobytes. Do this one early, because a poor result predicts a poor success rate later and saves you the rest of the budget.

A pass mark is not an industry number somebody published. It is a threshold derived from your own economics or your current baseline. Set all of them in writing before the trial starts, because a threshold you invent after seeing the data is not a threshold.

The success-rate row is the one that catches experienced buyers. If your incumbent's measured rate is 89 percent on a large sample and the challenger shows 91 percent on 250 requests, the challenger's interval is roughly plus or minus 3.6 points, so the ranges overlap and you have measured nothing. Either collect more samples or accept that the two are indistinguishable and decide on price, support or terms instead.

Sized for the shortest trials in the market. Stretch it if you have longer.

Day 0, before signing up. Write the harness. Pick 300 to 1,000 target URLs that represent your real workload, weighted toward your lightest pages. Write down your six pass marks. Estimate your byte budget: requests times average response size, with 30 percent headroom.

Day 1 morning. Sign up. Run measurements 1, 2 and 6 in that order. Roughly 5 MB. If any of them fails a pass mark, stop and move to the next provider. You have spent an hour.

Day 1 afternoon. Run measurement 3 at production concurrency and capture measurement 4 from the same run. This is the bulk of the byte budget.

Day 2, a different hour. Repeat the same run. Compare p95 and success rate against day 1. A provider whose numbers move materially between two runs has told you something more important than either individual number.

Day 2 evening. Run measurement 5 on a single address. Small cost, large consequence.

Day 3. Aggregate. Compare against pass marks, not against the other provider's marketing. Write a two-line verdict per measurement. If you are evaluating more than one provider, run this identical plan on each, and run them on the same targets in the same week, because target behaviour changes.

Keep the harness. It becomes your ongoing monitoring and the switching kit you will want later, and the sequencing in switching proxy providers without downtime assumes you have exactly this.

You cannot detect a curated trial pool from inside a trial.

If a provider routes trial traffic through their cleanest subnets, every measurement above returns a flattering number and there is no experiment you can run from your side to prove it. The addresses look fine because they are fine. They are just not necessarily the addresses you get in month three at production volume.

The mitigation is contractual rather than technical, and it is the reason the refund window deserves as much attention as the trial:

• Buy one month, not one year. The annual discount is real and so is the risk, and the discount is not worth committing to an unmeasured production pool.
• Repeat measurements 3, 4 and 6 in week two of the paid month, at production volume. Any divergence from your trial numbers is the answer to this section.
• Ask directly whether trial and paid traffic share a pool. The answer itself is informative, and a vendor who answers precisely is telling you something about how they operate.
• Check the refund terms before you spend, specifically whether usage voids them, since some money-back guarantees expire the moment you send real traffic.

Combined with the warning signs in how to spot a fake proxy provider before you buy and the deeper method in our complete proxy testing guide, that covers the ground a trial alone cannot.

If a managed API is in your shortlist rather than raw proxies, the same discipline applies with a different meter. SparkProxy's 1,000 free credits, no card required, buy 1,000 plain fetches at 1 credit each or 200 rendered pages at 5, and the response headers report the credits and duration each call consumed so you can cost the job before you commit:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://www.sparkproxy.io/blog" \
  --data-urlencode "render_js=false" \
  --data-urlencode "country_code=US" \
  -o /dev/null -D -

Spend those 1,000 credits on the same six measurements, in the same order, against the same targets.