When to Move From Shared to Dedicated Proxies

Move when you can demonstrate that your results depend on somebody else's traffic. That means at least one of these is true and you have the measurement to show it:

• Your block rate moves on a daily or weekly rhythm that does not match your own request schedule.
• A target you have barely touched is already treating you as hostile on first contact.
• Two addresses from the same pool, used identically at the same moment, return wildly different success rates.
• The target has started acting on whole address ranges rather than individual addresses.
• You need an address that holds an identity, in which case you needed a fixed address rather than an exclusive one and the two are not the same purchase.

Stay on shared when your block rate tracks your own behaviour, when halving your request rate halves your challenges, and when your workload is stateless collection at volume. In that world a shared rotating pool is not a compromise, it is the correct product, and dedicated addresses would be both more expensive and more fragile.

A shared address is used by you and by other customers of the same provider, either at the same time or in sequence. That has three consequences, and only the third is the one worth paying to escape.

Consequence one: rate-limit budgets are split. A target counting requests per address counts everyone's. If it tolerates 500 requests a day from an address and two other customers are already using 400 of them, your 300 are not going to land the way your arithmetic says.

Consequence two: reputation is collective. Fraud and bot-detection scores attach to the address, not to the customer. Whatever the previous user did is part of the address's history the moment you get it. Our explainer on IP reputation covers how those scores are built and why they are slow to decay.

Consequence three, the one that matters: your outcomes become correlated with strangers. This is different from the first two in kind, not degree. The first two are costs you can measure and price. This one makes your system's behaviour unpredictable in a way no amount of tuning on your side fixes, because the variable driving it is not yours. A pipeline whose success rate you cannot explain is much more expensive to operate than one with a known, stable, slightly worse success rate.

Worth noting that pool design matters as much as exclusivity. A large shared pool spread across many subnets behaves very differently from a small one concentrated in two ranges, because targets increasingly act on prefixes rather than single addresses. Our notes on mixed subnet datacenter proxies and proxy pool size claims cover what to ask about a pool before you conclude that sharing is the problem.

Each of these has a test. Run it before you spend, because four of the five have a non-neighbour explanation that is cheaper to fix.

Symptom 1: your block rate has a rhythm that is not yours

Challenge rates that rise every weekday afternoon, or every Sunday night, while your own schedule is flat, point at somebody else's schedule. Test: plot your challenge rate per hour over two weeks alongside your own request volume per hour. If the two curves are uncorrelated, the driver is external. If they track each other, the driver is you and dedicated addresses will not help.

Symptom 2: cold targets treat you as hostile

You point a modest, well-paced crawler at a site you have never touched and get challenged inside the first hundred requests. That is not your history, because you do not have one there. Test: send the same request through a residential exit and through a freshly issued address from a different range. If the cold target accepts those and rejects the pool address, the address arrived with a reputation. Fresh and unused datacenter proxies covers what "fresh" actually means when a vendor claims it.

Symptom 3: identical usage, wildly different outcomes

Two addresses, same pool, same target, same headers, same pacing, same minute, and one returns 200 while the other returns challenges. Test: run a controlled pair for an hour, alternating requests between two addresses with everything else identical. A persistent gap means the addresses themselves differ, which on a shared pool means their usage histories differ. This is the single cleanest evidence for the move, because it holds your own behaviour constant by construction.

Symptom 4: the target has moved to range-level action

Individual addresses stop working in groups. You lose four addresses at once and they share a prefix. Test: record the address for every blocked request and group them by /24. If blocks cluster by prefix rather than scattering, the target is acting on ranges, and here is the uncomfortable part: dedicated addresses inside the same range do not help. What helps is subnet diversity, which is a pool property rather than an exclusivity property. Our guide to bypassing IP fingerprinting with clean subnets covers that distinction, and it is the reason symptom 4 is on this list with an asterisk.

Symptom 5: you need the address to hold an identity

A login, an allowlist entry, an address-bound licence, a long-running account. Test: none needed, this one is structural. But be precise about what you are buying: you need a static address, and dedicated is a property that usually comes with it rather than the property you are after. Buying "dedicated" from a vendor whose dedicated addresses still rotate solves nothing.

Two of those seven rows point away from dedicated addresses entirely, and a third points at a pool property rather than exclusivity. That ratio is roughly what we see in support conversations, which is why the tests come before the purchase.

"We are scaling up, so we need dedicated proxies."

Volume by itself is an argument for more addresses, not for exclusive ones, and on a rotating pool more addresses is what you already have. A pool of a million addresses spreads a million requests far more thinly than fifty dedicated addresses can, and thinness is what keeps per-address counters low. Scaling on dedicated addresses means either buying hundreds of them or concentrating your volume onto a handful, which is the opposite of what your rate-limit arithmetic wants.

The honest version of the scaling argument is narrower: as volume rises, so does the chance that a neighbour's bad day intersects your important job. That is a variance argument rather than a capacity one, and it is a real reason to want exclusivity for the jobs that must not fail, while leaving the bulk on the shared pool. Split by criticality, not by volume.

The per-address rate below is an illustrative $1.50 a month, because we did not verify a dedicated datacenter price on any vendor's own page while writing this and will not quote one from memory. Replace it with the quote in front of you; the shape of the result is what matters and it does not change much.

Assume a target that tolerates roughly 500 requests per address per day before it starts challenging. That number is workload-specific and you should measure your own, but it is a reasonable middle figure for datacenter traffic against a moderately defended site.

Two things fall out of that table, and they point in opposite directions.

Below roughly 750,000 requests a month, dedicated is cheaper. The crossover is where the address count times the rate equals the plan price: $75 divided by $1.50 is 50 addresses, and 50 addresses at 500 requests a day is 25,000 a day, or 750,000 a month. Under that line, buying a handful of exclusive addresses genuinely undercuts a plan floor, which is why small, careful operators often run dedicated and are right to.

Above it, the gap widens fast and never closes. At five million requests a month you are looking at $501 against $75, and the rotating plan is not even stretched: 166,667 requests spread over an eight hour window is 5.8 a second, which at two seconds a request is about 12 threads in flight against Starter's 100. You are paying $426 a month for exclusivity alone.

Is $426 worth it? Turn it into a rate you can judge. If shared is costing you a 12% block rate and dedicated would get you to 2%, you recover 10% of five million requests, which is 500,000 requests a month. $426 divided by 500,000 is about $0.00085 per recovered request. If a recovered page is worth more than a tenth of a cent to you, the move pays for itself. If you have no idea what a page is worth, that is the number to go and find before you buy anything.

Note what the table does not do: it does not price the second rotating plan you would need at higher volumes, because at these volumes you do not need one. Threads, not addresses, are the ceiling on a rotating plan, and 5.8 requests a second is nowhere near it. Our explainer on concurrent connections covers that conversion.

Shared and dedicated are the two ends of a spectrum with useful positions in between, and jumping straight to the expensive end is common.

Semi-dedicated. A small, capped number of users per address, usually two or three, at a price much closer to shared than to dedicated. It removes the long tail of the neighbour problem without removing the neighbours. For symptom 1 and symptom 2 this is often enough. See semi-dedicated proxies for how the products are typically structured.

A wider pool rather than an exclusive one. If your problem is per-address counters, more addresses solves it more cheaply than fewer exclusive addresses. This is the answer for symptom 4 and for most volume-driven concerns.

Split by criticality. Keep bulk collection on the shared pool and put the jobs that must not fail on dedicated addresses. Most teams that "need dedicated" need it for perhaps 5% of their traffic, and buying it for 100% is how the bill triples for no gain.

Ask the vendor for a different range first. It costs nothing and it resolves a surprising share of symptom 2 cases. If the answer is that they cannot move you, that is useful information about the pool.

Ask what the address did before you. Recycled addresses arrive with history, and a dedicated address that used to be in a hot rotating pool is dedicated but not clean. Most vendors will not volunteer this, so check the address against a reputation service before you build on it.

An honest list, because the disappointment after a dedicated purchase is usually one of these.

Fingerprint-driven detection. TLS characteristics, HTTP/2 frame ordering, header order and automation signals get you classified before the address is scored. Exclusive addresses change none of it.

Range-level action. If the target has decided about your prefix, owning an address inside it exclusively changes nothing. This is the asterisk on symptom 4 and it catches people out regularly.

Your own pacing. A dedicated address hammered at ten requests a second gets limited exactly like a shared one, and faster, because there is now nobody else's traffic to hide in. A surprising number of teams see their block rate rise after moving, because they raised their rate at the same time.

Accumulated history, which is now entirely yours. On a shared pool a bad afternoon is diluted. On a dedicated address it is yours permanently, and you cannot rotate out of it. Exclusivity cuts both ways and the downside arrives later.

Datacenter network classification. An exclusive address in a hosting range is still in a hosting range. If the target scores networks, the fix is a different network type, not a different sharing model. Our comparison of residential and datacenter proxies covers where that line sits.

Short version, because the mechanics are the same as any proxy change.

Run both in parallel for at least two weeks with a shadow copy of one real workload on the new addresses, comparing success rate, challenge rate and response bodies rather than status codes alone. Move the most critical workload last, not first. Keep the shared plan live for a full billing cycle after the final cutover, because a new set of addresses can behave differently on a specific target only after it has accumulated some history with you. And re-measure your per-address tolerance on the new addresses, since it will not be the same number.

If you conclude that dedicated is right, buy it from a vendor that genuinely sells per-address products and can tell you the range, the term and whether the address is static as well as exclusive. Our guide to choosing a dedicated proxy provider covers the questions, and what a dedicated datacenter proxy is covers what you should expect to receive. SparkProxy's own plans are rotating pool products, so if your diagnosis lands on exclusivity we are telling you to buy something we do not sell, which is the correct answer more often than vendors admit. The full migration mechanics are in switching proxy providers without downtime.