What a Proxy Plan Includes: Reading the Spec Sheet

Most people read a proxy plan top to bottom and stop at the first number they recognise. Three passes works better and takes about the same time.

Pass one: what limits throughput. Threads or concurrent connections, bandwidth terms, and any speed figure. These three decide how fast the plan can go regardless of anything else.

Pass two: what limits reach. Pool size, countries, rotation behaviour, and protocol or port support. These decide whether the plan can get to your target at all and in what disguise.

Pass three: what limits you commercially. Validity, sub-users, authentication slots, replacement policy, and the acceptable use terms. These decide whether the plan fits your organisation rather than your code.

A plan can be excellent on pass one and unusable on pass three. The commonest example is a generous throughput plan with whitelist-only authentication bought by a team whose runners have dynamic egress addresses.

Threads, or concurrent connections

The number of requests the plan will carry at the same instant. Not the number of requests per second, not the number of addresses, not the number of users.

Throughput falls out of threads and latency together: 100 threads against a target answering in 1 second is roughly 100 requests per second, and the same 100 threads against a target answering in 5 seconds is 20. That relationship is the single most useful thing to know when sizing a plan, and understanding concurrent connections works through it properly.

Ask: what happens at the ceiling? Two behaviours exist. The gateway queues your 101st connection until a slot frees, which shows up as latency. Or it refuses it, which shows up as a connection error your client has to handle. Those produce completely different bug reports, and the spec sheet almost never says which one you get.

Also ask: is the limit per account or per credential? It matters the moment two jobs share a plan.

Bandwidth

Three possible meanings, and the sheet rarely distinguishes them: a hard monthly quota, a soft quota with overage billing, or genuinely unmetered.

"Unlimited" is a real thing on some plans and a marketing shape on others. SparkProxy's four public plans carry unlimited bandwidth with no byte meter, for example, and the honest qualification is in the next field rather than in this one. Our piece on whether unlimited bandwidth proxies are worth it covers where the word holds up.

Ask: what is metered, exactly? Response bytes only, or request bytes too? Compressed wire bytes, or uncompressed body size? On text-heavy pages those can differ by a factor of three. What bandwidth means in proxy services covers the accounting.

Speed, in Mbps

This is a ceiling, not a rate, and it is the field most often misread as a promise.

SparkProxy's fair usage policy states a per-tier ceiling: 25 Mbps on Starter, 50 on Core, 100 on Boost, 150 on Plus, 200 on Pro, 250 on Pro Plus, and up to 1 Gbps on custom arrangements. What that says is how much you are permitted to pull, not how much any given route will deliver. Actual throughput depends on the target, the route, the time of day and your own concurrency, none of which a proxy vendor controls.

Ask: is the ceiling applied per connection or across the account? A 100 Mbps account ceiling shared across 500 threads is a very different product from 100 Mbps per thread.

A practical note on how these two interact: for small HTML responses, the thread count binds long before the speed ceiling does. For image or video payloads, the ceiling binds first. Know which shape your workload is before you compare plans on either number.

Pool size, or IP count

The size of the inventory the gateway may draw from. It is not a count of addresses allocated to you, not a guarantee of uniqueness within a session, and not a promise that any particular address will be available.

SparkProxy publishes 1M+ datacenter IPs across 80+ countries including 50,000+ US addresses, and every vendor publishes a comparable headline. Treat all of them the same way: as an upper bound on variety, not a description of what you will see. Proxy pool size claims explained covers why the number is close to meaningless on its own.

Ask: how many distinct subnets, not addresses? Targets block prefixes. A million addresses inside a few hundred /24 blocks behaves like a few hundred addresses to a target that blocks at the prefix level, which is what subnet proxies are about. Almost no vendor publishes this, and asking is still worth doing.

Countries and locations

Coverage is a list. Depth is a distribution. A plan covering 80 countries might hold 40 percent of its addresses in three of them, which is normal and not dishonest, and it still means the country you care about could be thin.

Ask: how many addresses in the specific country or city you need, and is city-level selection available or only country? Our explainer on geo-targeting in proxies covers what selection granularity actually gets you.

Rotation

Three behaviours, and a plan may offer one, two or all three: a new address on every request, a timed rotation at a fixed interval, and sticky sessions that hold one address for a defined period.

SparkProxy's proxy plans do random rotation per request plus 5-minute automatic rotation, with sticky sessions available on a dedicated port. If the distinction between those modes is new, how proxy rotation works is the primer.

Ask: what is the maximum sticky duration, and what happens when it expires mid-session? A session that silently changes address under a logged-in account is a challenge waiting to happen.

Ports and protocols

A spec sheet that lists a hostname and two or three port numbers is describing a gateway product: one endpoint that routes you into a pool. A sheet that offers a downloadable list of addresses is describing allocated proxies. Those are different products with different failure modes, and the port line is the fastest way to tell which one you are buying. What a proxy gateway is covers the distinction.

SparkProxy's gateway is gateway.sparkproxy.io with HTTP and HTTPS on port 11000, sticky sessions on 11002, and SOCKS5 on 13000. Reading that line tells you three things without any marketing copy: it is a gateway, sticky sessions are a separate route rather than a flag, and SOCKS5 is genuinely supported rather than listed as a coming feature.

Ask: does HTTPS go through a CONNECT tunnel, and is SOCKS5 fully supported including remote DNS resolution? Our explainers on proxy ports and HTTP, HTTPS and SOCKS5 protocols cover what each one implies.

Authentication and whitelist slots

Two mechanisms, usually both offered: credentials sent with each request, or an allowlist of source addresses that may connect without credentials.

Whitelist slots are a countable resource and one of the most commonly underestimated fields on a sheet. SparkProxy's plans carry 5 slots on Starter, 10 on Core, 15 on Boost and 25 on Plus. One slot is one egress address, so a team running from an office, two laptops on home connections and three cloud workers is already at six. Autoscaling runners with rotating public addresses can exhaust any slot count, which is why credential auth exists. How proxy authentication works and IP whitelisting for proxies cover both mechanisms.

Ask: how long does a whitelist change take to apply, and can it be done through an API? A slot change that needs a support ticket is not a slot you can use in an incident.

Validity

Read this as a number of days, not as "monthly". SparkProxy's plans state 30 days validity, which is a fixed window from activation rather than a calendar month. The difference matters for anything scheduled monthly, and it matters more when a plan expires rather than auto-renews, because an expired plan is a stopped pipeline.

Ask: does it auto-renew, and does unused capacity carry over? On metered plans, the answer to the second question is usually no, and it changes the effective price of a lumpy workload. Monthly versus annual proxy plans covers the longer commitment.

Sub-users and credentials

Whether you can issue separate credentials per job, per team or per client, and whether usage is attributable to each one. This looks like an administrative detail and is actually your only route to cost attribution and to revoking one job's access without rotating everything.

Ask: can sub-users be created programmatically, and do they carry their own limits?

Replacement allowance

Specific to plans that allocate addresses to you. Addresses accumulate reputation damage, and the replacement policy determines whether your usable address count holds steady or decays across a term. A plan with no replacement clause is a plan whose real inventory shrinks all month.

Ask: how many replacements per cycle, on what grounds, and how fast?

Support and service terms

The support tier line on a spec sheet is a marketing field. The document behind it is not. If an SLA exists, read it for what it actually commits to and what the remedy is, which is usually a credit rather than anything resembling your losses. Our guide to reading a proxy SLA covers the clauses that matter.

Read the acceptable use policy in this pass too, not later. It defines which workloads the plan is sold for, and a mismatch there ends the relationship at the first incident rather than at renewal. Proxy acceptable use policies explained covers the common restrictions.

Here is a real published ladder with the fields decoded, so you can see how a tier actually escalates.

Three things to notice about how this ladder is shaped, which generalise to other vendors:

Only two fields scale. Threads and slots. The pool, the rotation behaviour, the ports and the protocols are the same product on every tier, which means upgrading buys capacity rather than capability. On other vendors' ladders, capability is often gated by tier instead, and that is the thing to check: if a feature you need only exists two tiers up, your entry price is not the entry price.

Price per thread falls as you climb. $0.75 per thread on Starter, $0.56 on Core, $0.48 on Boost, $0.44 on Plus. That is normal volume pricing and it is worth computing on any ladder, because it tells you whether the vendor wants large customers or is indifferent.

Higher tiers can exist without a published price. SparkProxy's fair usage policy lists Pro at 200 Mbps and Pro Plus at 250, both above Plus, and neither carries a public price. A spec sheet that describes a tier without pricing it is telling you that tier is a conversation, not a checkout.

No proxy plan promises any of the following. Some buyers assume all of them.

• A success rate on your targets. No vendor commits to one, because it depends on the target's defences, your pacing and your headers as much as on the network.
• The same address twice, unless you bought sticky sessions or allocated addresses. Rotation means rotation.
• Exclusivity on a shared pool. Other customers use the same addresses, and their behaviour affects the reputation of addresses you later receive.
• Compatibility with a named website. A plan is a transport layer. It does not warrant that any particular site will serve you.
• Any parsing, structure or data. A proxy returns whatever the target returned, including a challenge page with a 200 status.
• Burst above the speed ceiling, even when the ceiling is rarely reached.
• A country or city that is listed but thin. Listed coverage is not a supply commitment for a specific location.
• Refunds after material usage, on many plans. Check whether usage voids the money-back window before you rely on it.

None of that is hidden, and none of it is unreasonable. It is simply not written on the sheet, and assumptions about it cause more disappointment than any field that is.

Five properties matter more than half the published fields, and you will not find them on a pricing page.

1. Subnet diversity. How many distinct prefixes the pool spans. This predicts block rate better than address count.
2. Per-address tolerance on your target. How many requests one address survives before your specific target reacts. Nobody can publish this, because it belongs to the target rather than the vendor.
3. Queue behaviour at the concurrency ceiling. Whether excess connections wait or fail.
4. Pool refresh rate. How often addresses are added and retired. A static pool degrades as targets learn it.
5. How usage is reported. Real-time or in arrears, per sub-user or in aggregate. You cannot control a cost you can only see after the billing cycle.

All five are measurable during a trial and none of them are quotable from marketing. Measuring them is the difference between buying a spec sheet and buying a product.

One field limits you and the rest are scenery. Find yours before comparing plans.

If two candidate plans differ on a field that is not your binding constraint, that difference is not a reason to choose either one. That single filter removes most of the noise from a plan comparison, and it is why the same ladder can be obviously correct for one team and obviously wrong for another.