Semi-Dedicated Proxies: When 2-3 Users per IP Makes Sense

Proxy products differ mainly in how many people send traffic from the same address. Laid out as a ladder:

The first four tiers are static lists: you receive a set of addresses and keep them. The rotating pool is a different shape entirely, and it is often the better comparison for scraping workloads. We come back to it at the end.

The difference between shared and dedicated is covered in depth in shared vs dedicated datacenter proxies. Semi-dedicated inherits properties from both sides, and which side dominates depends on the terms in the next section.

Two providers that publish a semi-dedicated tier, as described on their own pages as of September 2026:

Rayobyte describes semi-dedicated proxies as usable by "up to three people at one time", in the United States, United Kingdom and Germany, with datacenter IPs from $1 per IP per month and ISP IPs from $2.50, and unmetered bandwidth and connections.

BuyProxies describes its semi-dedicated service as "shared by no more than three customers in a controlled pool", with HTTP, SOCKS5 and UDP support and either username and password or IP authentication. Published packages:

Prices change, so check both vendors' current pages before buying.

Now look at what neither overview page states. Neither page read for this guide spelled out replacement terms, whether co-users are kept off the same target websites, or how the group of co-users is chosen. BuyProxies notes that some details are confirmed on its configuration screen before purchase. Those unstated terms decide most of the tier's value, which is why the checklist later in this guide exists.

A clause worth asking for specifically is target exclusion: an undertaking that two customers sharing an IP will not be assigned to the same website. Neither overview page read for this guide mentions one, so ask directly. Where it exists, semi-dedicated behaves much closer to dedicated on the sites you use. Where it does not, the cap of three is the only protection you have.

Semi-dedicated datacenter or semi-dedicated ISP?

Rayobyte's listing shows the tier in both flavours, and the price gap is large: $1 against $2.50 per IP at the entry point. The sharing model is identical. What changes is who the address is registered to. Datacenter IPs belong to hosting networks, which many anti-bot systems score as automated before a single request is judged. ISP addresses are announced by consumer internet providers, so they start from a more trusted position on sites that filter by network type.

That makes the ISP version worth the premium only when your targets already treat hosting ranges harshly. If plain datacenter addresses get through to your sites, paying two and a half times more for the same sharing arrangement buys nothing. Test one small datacenter batch first. Our explainer on what ISP proxies are covers how those addresses are sourced.

Most sites that limit automated traffic do it per IP: a number of requests in a window, after which you see slow responses, challenges or 429 errors. On a dedicated IP, that budget is all yours. On a semi-dedicated IP, it can be split.

The arithmetic is simple. If a target tolerates R requests per hour from one IP, and k customers on that IP send traffic to the same target, each gets roughly R / k before the limit bites. Whether k is 1 or 3 depends on overlap: how likely your co-users are to be scraping the same site at the same time.

An illustrative example, with a budget of 300 requests per IP per hour. The 300 is an assumed figure for the arithmetic, not a measured limit for any site:

The overlap probability is the variable to think about, and it is driven by target popularity. Customers who buy datacenter proxies cluster around the same high-demand destinations: large marketplaces, search engines, ticketing and sneaker sites, social platforms. If your target is one of those, assume overlap. If you are monitoring prices on 40 regional hardware suppliers, overlap is unlikely, and semi-dedicated behaves close to dedicated for a fraction of the price.

So the cheapest way to size a semi-dedicated order is to size it as if you were buying dedicated IPs for niche targets, and as if you had one third of the budget per IP for popular ones. For the general method of turning request volume into IP counts, see how many proxies you need for scraping.

Target exclusion solves the rate budget problem. It does not solve reputation.

An IP's reputation is built from everything it has done, across every site that reports abuse or feeds a scoring service. If a co-user sends spam, runs credential attacks or trips a large anti-bot vendor's network, the address can land on blocklists or get a poor risk score. Your requests from that IP then carry the penalty, even on sites the co-user never touched. The mechanics are explained in what IP reputation is and why it matters.

Semi-dedicated improves the odds compared with shared plans for a simple reason: two strangers are fewer chances for bad behaviour than an unstated crowd. It does not reduce the risk to zero, and it adds one exposure that dedicated IPs lack. You cannot see your co-users' traffic, so a sudden reputation drop cannot be traced to its source. Your only remedy is replacement, which is why replacement terms matter so much.

History matters too. Static addresses get recycled between customers and tiers. An address that was a shared proxy last year and a semi-dedicated one today may carry an old listing. Checking a new batch before putting it into production takes minutes, and it is covered below.

The allowlisting row deserves emphasis because it is easy to miss. If a partner or client system grants access to a specific IP, anyone else using that IP inherits the access path. That makes semi-dedicated addresses unsuitable for allowlisting regardless of how trustworthy the vendor's co-user screening is.

Send these to the vendor's sales or support team before you pay. The answers, and whether you get clear ones, tell you more than the product page.

1. Is the user cap per IP or per pool? "Shared by three" should mean three customers on each address, not three customers on a whole subnet or product.
2. Do you keep co-users off the same target sites? If yes, how is it enforced, and what happens if you add a new target later?
3. How often can I replace IPs, and is there a cost? Monthly free replacement is common for static plans; confirm the number and turnaround.
4. Were these IPs previously sold as shared or public proxies? A straight answer is a good sign even if the answer is yes.
5. How many distinct subnets will my order span? Fifty IPs in one /24 range can be blocked with a single rule. What subnet proxies are explains why spread matters.
6. Are threads or connections limited per IP? "Unmetered bandwidth" and unlimited concurrency are different promises.
7. Which locations are really available? Semi-dedicated tiers often cover far fewer countries than dedicated or rotating products.
8. What happens when a co-user is removed for abuse? Does the address get replaced for you automatically, or do you find out from your error logs?
9. Is there a trial or refund window long enough to test on my targets? Forty-eight hours is enough for the checks below; an hour is not.

Three checks catch most bad batches before they cost you anything.

Blocklist lookups. Query each IP against DNS-based blocklists. A listing is not automatically fatal for scraping, but a batch with many listed addresses is worth replacing on day one while replacement is easy.

import socket

LISTS = ["zen.spamhaus.org", "bl.spamcop.net", "b.barracudacentral.org"]

def listed(ip: str) -> list[str]:
    reversed_ip = ".".join(reversed(ip.split(".")))
    hits = []
    for zone in LISTS:
        try:
            socket.gethostbyname(f"{reversed_ip}.{zone}")
            hits.append(zone)
        except socket.gaierror:
            pass
    return hits

for ip in open("batch.txt").read().split():
    print(ip, listed(ip) or "clean")

Blocklist operators set their own usage terms. Spamhaus, for example, does not answer queries sent through large public DNS resolvers, so run this from a resolver you control and stay within each list's free-use conditions.

Subnet spread. Count distinct /24 prefixes in the batch. If 100 addresses share three prefixes, you have three failure domains, not 100.

from collections import Counter

ips = open("batch.txt").read().split()
prefixes = Counter(".".join(ip.split(".")[:3]) for ip in ips)
print(f"{len(ips)} IPs across {len(prefixes)} /24 prefixes")
print(prefixes.most_common(5))

Throttle point versus your own traffic. On one IP, send requests to your real target at a steady, polite rate and note when responses change: slower, challenged or rate limited. Repeat on a second IP at a different hour. If one address hits its limit long before your own request count explains it, someone else is probably spending that budget. That is precisely the co-user overlap you cannot see directly, and it is the evidence to include in a replacement request.

SparkProxy does not sell a semi-dedicated tier, so treat this section as the view of a vendor with a different product. For a large share of scraping workloads, the question of how many people share each IP matters less than it seems, because the better answer is not to depend on any single IP.

A rotating datacenter pool spreads your requests across a very large set of addresses. SparkProxy's network is 1M+ datacenter IPs across 80+ countries, including 50,000+ in the US. Plans are sold by concurrency, not by IP: Starter at $75 a month for 100 threads, Core at $140 for 250, Boost at $240 for 500 and Plus at $440 for 1,000, all with unlimited bandwidth and 30 days of validity. Requests through gateway.sparkproxy.io on port 11000 get a random exit per request; port 11002 keeps a sticky session when a flow needs the same exit for several steps; port 13000 is SOCKS5.

On a rotating pool, a single bad address costs you one request, not a slice of your fixed list, and per-IP rate budgets stop being something you manage by hand. That tends to win for high-volume collection and for popular targets where semi-dedicated overlap is likely. The broader trade-off is laid out in rotating vs static datacenter proxies.

A fixed list still wins in three situations: when a target or partner needs to recognise a stable address, when you want to run the reputation checks above on every IP you use, and when your workload is small enough that a few dozen well-chosen addresses at around a dollar each cost less than a thread plan. Those are real cases. Semi-dedicated is a good product for them, provided the vendor answers the nine questions well.