Choosing the Right Proxy Type
Decision criteria for shared, dedicated, rotating and residential proxies, and a test procedure that tells you which one your target needs.
The right proxy type depends on what your target checks, and you rarely know that in advance. The procedure that finds out: start with the least expensive configuration that could work, measure, and change one thing at a time when your own results give you a reason. This page gives the decision criteria, then the procedure. It assumes you know what the types are; understanding proxy types covers that, and nothing there is repeated here.
| What it changes | Fits when | |
|---|---|---|
| Shared datacenter | Nothing yet: the starting point | Public APIs, sites without bot defenses, price feeds, ordinary content sites |
| Dedicated datacenter | One customer per IP at a time, so no co-tenant's traffic lands on your address | Logged-in sessions and anything where the target remembering your IP is a feature |
| Rotating | How requests are distributed: a fresh exit per connection with no list to manage | A per-address rate limit that you would otherwise beat by spreading load yourself |
| Residential | What kind of address you arrive from | Targets that refuse hosting ranges outright, and jobs that need country or city targeting |
If you are not yet sure the problem is your address at all, work through whether you need proxies first. A rate limit keyed to your account, or a login you already hold, does not get cheaper by routing it through a different IP.
Step zero: decide what success means
Before sending a proxied request at your real target, decide two things.
What counts as success: the target returned the content you wanted, not merely an HTTP 200. Plenty of sites answer 200 with a challenge page, a consent interstitial or a degraded response. Parse for the data; proxy error codes explained covers the codes worth telling apart when it is not a 200.
How you will sample: a batch large enough to show a pattern, with the outcome recorded per URL and per exit address. Without per-exit records you cannot tell "the target dislikes all of these addresses" from "the target dislikes two of them", and that difference decides the next step. Measuring proxy performance goes further on measurement.
Step one: start on shared datacenter
Run the sample batch on shared datacenter and apply your success definition. For a large share of real targets everything works and the procedure ends here. Move on only when your own measurements show a block pattern, not because a forum post called the target hard. If the batch will run from a Scrapy spider, proxies for Scrapy covers which product to point the middleware at first.
Reading a block pattern
When failures appear, their distribution across exits and over time is a clue to which defense fired. Three patterns cover most cases, and each suggests one change. Treat them as a reason to run the next test, not as proof; a target can combine defenses, and client-side signals (headers, TLS fingerprint, timing) can produce any of these shapes.
Refused from the very first request, on every fresh exit. An address with no history at this target is turned away before it does anything. Uniform failure across several fresh exits suggests the target is classifying by network registration, in which case no datacenter address does better, dedicated included; the change to test is residential.
Requests succeed at first, then blocks begin after some volume, and a fresh exit resets the clock. This looks like per-address rate accounting. The address type is acceptable; the volume from any one address is not. The change to test is distribution, not a different type: the same total spread across more exits. Residential driven at the same per-address rate would usually trip the same counter.
Scattered failures: some exits refused at once while others keep working. A uniform mechanism does not produce scattered results, so what distinguishes a refused exit from a working one is likely its past. The change to test is dedicated datacenter, where no other customer's traffic shares the address while you hold it.
The habit that separates these cheaply: test several fresh exits before concluding anything.
The escalation for each pattern
Shared to dedicated datacenter. You change tenancy and nothing else. Registration and throughput stay datacenter-shaped. After switching, rerun the step-zero batch: fresh dedicated exits should behave the way the working shared exits did. If they also fail at once, the pattern was registration-based after all, and the evidence now points at residential.
Datacenter to residential. Run a small batch through a residential exit at the same URLs before migrating anything. If it succeeds where every datacenter exit failed, the migration is justified. If it also fails, the defense is behavioral and a different address type will not move it; see the last section. When the migration is justified, respect the metering: residential is billed by traffic, so request the JSON endpoint instead of the rendered page, skip images and fonts, and cache what does not change. How much traffic a plan carries is on pricing.
Static to rotating. This changes how requests are distributed, not what kind of address carries them, and exists in both datacenter and residential forms on the rotating proxies page. Your request rate divided by the rate one address tolerates gives the number of exits the work needs at once. When that number is small, a few static endpoints and a round-robin in your own code may do; how many proxies do I need works through the estimate. When it is large or the tolerance keeps shifting, a gateway does the distribution for you; IP rotation strategies covers the mechanics. Rotation breaks flows that depend on one address (logins, carts, paginated crawls), so pin those to a sticky session or a static endpoint and rotate the rest. The two rotating products differ only in how they are billed; metered bandwidth versus no meter at all works out which is cheaper for a given job.
When no change of address helps
If residential exits at modest per-address rates are still refused, stop changing proxy types. The remaining defenses (header consistency, TLS fingerprints, JavaScript challenges, the timing of your traffic) evaluate your client, not your address. The productive work moves to the request side: web scraping best practices and why is my IP getting blocked cover it.
The procedure, condensed
- Define success as correct content, and record outcomes per exit.
- Start on shared datacenter; if the measurements are clean, stop.
- Uniform instant failure on fresh exits: test residential with a small batch first.
- Failure that grows with per-address volume: rotate, sized from the arithmetic.
- Scattered failure across exits: test dedicated datacenter.
- Failure that survives residential at low rates: change the client, not the proxy.
Escalate the failing part of a workload, not all of it. Most pipelines touch several targets with different defenses, and each can run on the least expensive tier that passes its own measurements. If this is your first setup, the quick start guide gets the first verified request working before any of these decisions arise.