Proxy Terms Buyers Get Wrong: Ports, Threads and Bandwidth

Six words, six questions. Ask these before you compare any two quotes.

Every one of those has a factual answer that a vendor can give in a sentence. A vendor who cannot or will not give it has answered a different question, which is also useful information.

This is the most expensive ambiguity in proxy buying, because it is the unit the entire plan is priced on.

Three vendors selling "100 threads" can mean:

Open TCP connections to the gateway. Every socket counts, including idle ones your HTTP client is holding open for reuse.

Requests in flight. Only requests currently waiting on a response count. Idle keep-alive sockets are free.

Logical sessions. A session identifier counts once regardless of how many connections or requests it carries.

These are not small differences. Work an example. Your scraper talks to 50 hosts and your HTTP client keeps a pool of 4 connections per host, which is a common default. That is 200 TCP connections held open. At any instant, though, maybe 30 requests are actually in flight, because most of those sockets are idle between fetches.

Under the first definition you need a 200-connection plan. Under the second you need 30. Same workload, same code, a difference of nearly seven times in the plan you must buy. Buy on the wrong definition and you either pay for capacity you never use or get throttled at a fraction of the throughput you expected, with no error message that explains why.

The question to ask, verbatim: "If my client holds 200 idle keep-alive connections and has 30 requests in flight, what number does your limit see?" Any vendor's support can answer that. Our explainer on concurrent connections in proxies covers how the count is enforced in practice.

One related trap: some plans count concurrency per sub-account rather than per plan, and some count it per gateway rather than globally. If you run several workers, ask which.

The word is used for two unrelated quantities and vendors switch between them without warning.

Data volume. How many gigabytes you may transfer. Measured in GB, billed per GB or capped per month. This is what "500 GB included" means.

Throughput. How fast the connection runs. Measured in Mbps. This is what "up to 100 Mbps" means.

A plan can be generous on one and tight on the other, and the marketing word is the same. "Unlimited bandwidth" almost always refers to volume, and it almost always sits alongside a throughput ceiling in a fair usage policy that nobody reads.

Here is the useful reframing: a throughput ceiling is a volume cap in disguise, and you can compute it. Take SparkProxy's own published fair usage ceilings, which run 25 Mbps on Starter, 50 on Core, 100 on Boost and 150 on Plus. At 25 Mbps, a continuously saturated link moves 25 divided by 8, or 3.125 megabytes per second. Over a 30-day month of 2,592,000 seconds that is 8,100,000 MB, or 8.1 TB. At 150 Mbps the same sum gives 48.6 TB.

Nobody saturates a link for a whole month, so treat those as ceilings rather than allowances. The point is that the arithmetic is available and it tells you whether "unlimited" is a real answer for your workload or a marketing word hiding a constraint you will hit. If your job needs 2 TB a month, 25 Mbps is genuinely plenty. If it needs 20 TB, the entry tier's ceiling is the binding constraint whatever the volume policy says.

Three follow-up questions worth asking about any bandwidth claim:

• Is the limit a throttle or a stop? A throttle degrades, a stop breaks your pipeline at whatever hour it triggers.
• Is it measured per account, per thread, or per address? They give very different real ceilings.
• Do failed requests count? On any metered plan the honest answer is yes, because bytes moved are bytes moved.

Our notes on what bandwidth means in proxy services and on whether unlimited bandwidth proxies are worth it go further into the trade.

Buyers routinely assume a port number selects a protocol, or worse, a country. It does neither. On a modern proxy gateway, the port selects which behaviour the gateway applies to your connection.

A typical layout, using SparkProxy's own as a concrete example: the gateway host is gateway.sparkproxy.io, and port 11000 gives HTTP and HTTPS with rotation, port 11002 gives HTTP and HTTPS with sticky sessions, and port 13000 gives SOCKS5. Same hostname, same credentials, three behaviours.

That structure matters commercially for one reason: it tells you whether switching behaviour costs money. If sticky sessions live on a different port with the same credentials, you can move a workload from rotating to sticky by editing one number. If a vendor sells sticky sessions as a separate product with separate credentials and a separate price, the same change is a purchase.

Two related confusions worth clearing:

Ports 80, 443, 8080 and 3128 are conventions, not rules. 8080 and 3128 are traditional proxy ports, 80 and 443 are the ports the destination usually listens on. Some restrictive networks only permit outbound 80 and 443, which is a genuine reason to ask whether your vendor offers a proxy endpoint on one of them. Our breakdown of proxy ports covers the conventions.

A port does not choose geography. Country selection is done through the username string, a subdomain, or a dashboard setting, depending on the vendor. If somebody tells you to "use the UK port", ask what they actually mean, because the answer is usually a username parameter.

Across vendors you will meet dedicated, private, exclusive, personal, semi-dedicated and shared, arranged in ladders that do not line up with each other. There is no standards body here and the words are marketing, not specification.

What the words tend to mean, with wide variation:

• Shared. Several customers use the address at once, usually an unstated number.
• Semi-dedicated. A stated small number of customers, commonly three. Sometimes called "semi-private".
• Private or dedicated. One customer at a time, for the duration of the term.
• Exclusive. Usually the same as dedicated, occasionally meaning the address is never resold after you release it, which is a genuinely different and better claim.

The question that cuts through all of it: "How many other customers can send traffic through this specific address during my term, and what happens to it when I cancel?" The second half matters more than people expect. An address that returns to a shared pool the day you cancel tells you something about where the address you were just sold came from.

Our explainers on semi-dedicated proxies, what "private proxy" means across providers and shared proxies map the usual ladders.

Three words for how long you keep an exit address, and the distinction between the middle one and the other two is where purchases go wrong.

Rotating. The address changes, either on every request or on a timer. Correct for spreading load across a large pool. Wrong for anything with a session.

Sticky. The address is held for a defined window, then released. Windows of 1, 10 and 30 minutes are common, and some vendors let you request a session identifier and keep it while it lasts. Correct for multi-step flows: a form, a checkout, a paginated crawl that needs the same exit for consistency.

Static. The address is yours and does not change at all for the term. Correct for logins and allowlisting, where the address is part of your identity rather than a resource.

The mistake is buying sticky when you needed static. Sticky sessions expire, and "expire" means your address changes mid-workflow at an unpredictable moment. For a paginated crawl that is a retry. For an account login it is a security event on the platform's side.

Ask for the number: "For how long is the exit address guaranteed not to change, and what happens at the end of that window?" Our explainers on sticky session proxies and rotation intervals cover the mechanics.

Scraping APIs price in credits, and a credit is not a request. The multiplier depends on what the request does.

On SparkProxy's own Scraping API a plain fetch costs 1 credit, a JavaScript render costs 5, and a screenshot or PDF costs 10. So the Starter tier's 250,000 credits at $49/mo is 250,000 plain fetches, or 50,000 rendered pages, or 25,000 screenshots. Those are very different products at the same price.

The buying consequence is that your credit budget depends almost entirely on one architectural decision: whether the data you need is in the initial HTML or only appears after JavaScript runs. Finding a JSON endpoint under a page and switching from rendering to plain fetching cuts the credit cost by a factor of five, which is usually worth more than any discount you could negotiate.

Three questions for any credit-priced product:

• What does one credit buy in each mode I will actually use?
• Do failed requests consume credits? Policies differ, and a target that blocks you 20% of the time makes this a 20% price difference.
• Do unused credits roll over, and do they expire?

Our breakdown of scraping API credit pricing works through the tiers.

Three figures appear on almost every proxy vendor's page, carry a decimal point, and mean nothing you can act on.

Pool size. "1M+ IPs", "80M+ residential". There is no auditor, no agreed definition of an available address, and no consequence for optimism. SparkProxy publishes such a number too and it deserves the same scepticism as anyone else's. What would be informative, and what nobody publishes, is prefix diversity: how many distinct subnets those addresses occupy, because a target blocking you blocks the prefix.

Success rate. "99.9% success". Against which targets, measured by whom, counting what as success? A 200 response containing a block page is a success by most vendor definitions and a failure by yours. Our note on proxy success rate and how to measure it covers measuring your own.

Uptime. Gateways are rarely the thing that fails. What fails is a target deciding it no longer likes the vendor's addresses, which no uptime figure captures and no status page reports.

None of these is a lie, exactly. They are just claims with no denominator. Spend the attention you would have given them on a trial against your own targets instead, which produces numbers with a denominator you control.

Before comparing two quotes, rewrite both into one sentence with the same shape. This takes ten minutes and it is the single highest-value thing in this post.

The sentence: "For $X per month I get Y simultaneous requests in flight, Z gigabytes of transfer before anything degrades, and an exit address that holds for W minutes, in countries A, B and C."

Fill it in for each vendor from their answers, not from their marketing page. Then notice which figures you had to ask for, because those are the ones the vendor did not want compared.

A worked translation of the same three facts across models:

Notice that the third row cannot be compared with the first two on price at all until you decide how many requests one address can carry before your target objects, which is a property of your target rather than of the vendor. That is not a flaw in the exercise; it is the exercise telling you where the real uncertainty lives.

Copy these. They are short, factual, and none of them can be answered with a brochure.

1. What exactly does your concurrency limit count? Open connections, in-flight requests, or sessions.
2. Is the bandwidth number a volume or a speed? And which one, if either, is enforced.
3. What happens when I exceed it? Throttle, hard stop, or automatic overage at what rate.
4. Which port does what, and are credentials shared across them?
5. How many other customers touch this address during my term, and what happens to it afterwards?
6. For how long is an exit address guaranteed not to change?
7. Do failed requests consume bandwidth, credits or quota?

If the answers arrive as a link to a features page rather than as sentences, that is your answer to a different and more important question. And once you have the answers, get them in the order form or the email thread rather than the chat window, because the definitions are what you are buying.