Shared Proxies: Who You Share an IP With and When It Is Fine

• Shared is fine for public data collection, price and SERP checks, ad verification samples, and any job where a failed request can be retried on a different IP without losing state.
• Shared is not fine for account management, checkout flows, anything allowlisted by IP on the target side, or work where you must prove which IP did what.
• "Dedicated" removes only one layer of sharing. You still share the subnet, the ASN, the IP's history, and on residential and mobile networks, the address itself with real users.

A shared proxy is a proxy IP that more than one party sends traffic through during the same period. The vendor sells access to the same address, or the same pool of addresses, to several customers, and splits the infrastructure cost between them. That is why shared plans cost a fraction of dedicated ones.

Most explanations stop at "several customers per IP" and treat it as a datacenter concept. Our existing piece on what a shared datacenter proxy is covers that case and the bad-neighbor problem in detail. This post zooms out: sharing exists on every proxy type, it happens at more than one level, and the level that bites you depends on the network your IP comes from.

When a target decides whether to trust a request, it does not care which invoice the IP sits on. It sees the address, its recent behaviour, its neighbours and its network. Each of those can be shared.

Tenancy is what vendors mean when they say "shared." It is the layer you pay to remove.

Time is the layer nobody prices. A dedicated IP that was abused by its last owner for six months arrives on day one already flagged. IP reputation follows the address, not the account.

Subnet and ASN sharing applies to everyone. Many anti-bot systems score a request partly by its network block. If a neighbouring /24 is hammering a target, the whole range can be throttled, and your exclusive IP inside it goes down with the rest.

Real users matter on residential and mobile. Carrier-grade NAT puts many subscribers behind one public IPv4, which is explained in CGNAT and proxies. Targets know this, so they tolerate far more activity per mobile IP than per datacenter IP. Sharing with real people is the one layer that tends to help.

The same word hides four different products.

Shared datacenter proxies

Sold two ways. A static shared list gives you fixed IPs that the vendor also assigns to other customers, often with a stated cap on customers per IP. A rotating gateway gives you one hostname and port, and each request (or each session window) exits from a pool that all customers on that product draw from. On a rotating gateway, tenancy exposure is time-sliced: any single IP carries your traffic for one request or a few minutes, then moves on, so one noisy co-tenant does not stay welded to your jobs. The shared vs dedicated datacenter proxies comparison works through the cost per request on both.

Shared ISP proxies

ISP (static residential) proxies are datacenter-hosted addresses registered to a consumer ISP's ASN. See what ISP proxies are for the mechanics. Most are sold dedicated because the whole appeal is a stable, clean identity, and a shared ISP IP gives up that appeal while keeping most of the price. The trap here is the subnet layer: ISP ranges are often small and resold, so a handful of heavy customers can burn a range quickly.

Shared residential proxies

Nearly every residential pool is shared by design. The exit IP belongs to a household device that opted into a network, and every customer of that network rotates through the same devices. Some devices can also sit in more than one provider's pool, so the "other tenants" can include customers of a vendor you have never heard of. Where residential proxy IPs come from covers the sourcing. When residential vendors sell "dedicated," they usually mean a filtered sub-pool or per-target exclusivity, not an IP nobody else touches, as dedicated residential proxies explained sets out.

Shared mobile proxies

A shared mobile port means several customers reach the internet through the same physical modem, and often any of them can trigger an IP rotation. Even a dedicated port shares its public IP with real subscribers via CGNAT. The real difference is who controls rotation and whether another tenant's automation overlaps with yours on the same platform in the same minute. Dedicated vs shared mobile proxies prices that trade-off.

Vendors use three tiers, and the labels are not standardised. "Semi-dedicated" is commonly listed as a small fixed cap of customers per IP, but the number varies, so read the plan terms rather than the label.

The last row is the one to remember. Every tier shares the subnet and inherits history. Paying for dedicated buys you control of the tenancy layer and nothing else.

The most concrete cost of tenancy sharing is rate-limit contention. Many targets cap requests per IP per window. When several tenants on the same IP hit the same target, they split that allowance whether they know it or not.

A simple planning model, with illustrative assumptions rather than measured figures:

• Target allows R requests per minute per IP before throttling.
• k tenants on the IP are hitting that same target.
• Your usable budget on that IP is roughly R / k, and less if others are bursty.

If a target tolerates 60 requests a minute per IP and three tenants on your static shared IP scrape it, you have about 20. If you are the only tenant targeting it, you have all 60 even though the IP is "shared," because contention only happens per target.

This is why a large rotating pool changes the math. Spreading N requests a minute across P IPs puts N / P on each address. With a pool in the hundreds of thousands, co-tenants on any given IP at any given second are rare, and you rarely approach a per-IP threshold. The planning question for rotating shared pools is not "how many users per IP" but "how many IPs do my requests actually land on," which you can measure yourself.

No external test counts co-tenants directly. The vendor's routing table is the only exact source. You can still build a reliable picture from five signals.

1. Get the tenancy number in writing

Ask for the maximum customers per IP, whether that cap applies per target or overall, and whether it is enforced or a target. A vendor that will not state a number on a shared plan is telling you the number is high.

2. Classify the IP and its network

Confirm what you bought before you judge how shared it is. Check the ASN, organisation and reverse DNS:

# Exit IP and network owner through the proxy
curl -s --proxy http://USER:PASS@gateway.sparkproxy.io:11000 https://ipinfo.io/json

# Reverse DNS on the returned address
dig -x 203.0.113.45 +short

A hosting ASN on a plan sold as residential or ISP means the sharing profile is datacenter, whatever the label says.

3. Look for other people's history

Query the IP in public abuse and blocklist databases such as AbuseIPDB and the Spamhaus lookup. Recent reports that predate your use, or that describe traffic you never sent, are direct evidence of other tenants or previous holders. The IP blacklisting guide lists what each entry type means.

4. Run a cold-start and low-rate test

Send a single clean request from a fresh browser profile to your real target. A CAPTCHA or challenge on request one means the IP arrived with a reputation. Then send requests at a rate well below what that target normally tolerates. 429 responses at a low, steady rate point to someone else spending the same per-IP budget.

5. Measure the pool you actually reach

For rotating shared pools, estimate how many distinct IPs your traffic spreads across. Take two independent samples of exit IPs and apply a capture-recapture estimate (the Lincoln-Petersen method biologists use to count animal populations):

import requests

PROXY = "http://USER:PASS@gateway.sparkproxy.io:11000"  # rotates per request
PROXIES = {"http": PROXY, "https": PROXY}

def sample(n):
    ips = set()
    for _ in range(n):
        try:
            r = requests.get("https://api.ipify.org?format=json",
                             proxies=PROXIES, timeout=15)
            ips.add(r.json()["ip"])
        except requests.RequestException:
            pass
    return ips

first = sample(300)
second = sample(300)
overlap = len(first & second)

print("unique in sample 1:", len(first))
print("unique in sample 2:", len(second))
print("seen in both:", overlap)
if overlap:
    # Chapman's version of Lincoln-Petersen, stable when overlap is small
    est = (len(first) + 1) * (len(second) + 1) / (overlap + 1) - 1
    print("estimated reachable pool:", round(est))
else:
    print("no repeats: reachable pool is far larger than the sample")

Treat the result as an order of magnitude, not a count. It assumes every IP is equally likely to be picked, which geo-targeting and load balancing break. It still answers the useful question: if you see almost no repeats across 600 requests, your per-IP exposure to any co-tenant is tiny. If the same 40 addresses keep coming back, you are on a small shared list, and the rate-limit math above applies in full.

Shared is the correct buy, not merely the cheap one, when all of these hold:

1. Requests are stateless. No login, no cart, no session cookie that must survive on one IP.
2. Failures are retryable. A blocked request can be re-sent through a different IP at no real cost.
3. The data is public. Product pages, search results, listings, public profiles, ad placements.
4. You rotate. Per-request rotation or short sticky windows keep any one IP's contribution small. Proxy rotation covers the patterns.
5. Volume matters more than identity. Concurrency per dollar is the metric, and shared pools win it by a wide margin.

Most scraping workloads meet all five. Price monitoring, SEO rank tracking, catalogue collection, travel fare checks and market research rarely need an exclusive IP, and paying for one mostly buys idle capacity.

Upgrade when any of these apply:

• You hold accounts. A platform that sees your account and a stranger's automation on the same IP in the same hour links them. One ban can cascade.
• The target allowlists your IP. Partner APIs, B2B portals and internal tools that permit specific addresses expect that address to be yours alone.
• Sessions last longer than a few minutes. Long checkout, booking or form flows need the IP to stay clean and stable for the whole flow. A sticky session on a pool helps with stability, but not with tenancy.
• You need an audit trail. If compliance requires stating which IP touched which system and when, shared tenancy makes that statement impossible to defend.
• Your retry rate climbs past what the price saved. Track cost per successful request, not cost per IP. When retries on a shared list double your effective cost, the dedicated premium may already be cheaper.

Send these before paying, and keep the answers:

1. What is the maximum number of customers per IP on this plan, and is it enforced?
2. Is the cap per IP overall, or per target domain?
3. Is this a static list or a rotating pool, and roughly how large is the pool I can reach?
4. How are IPs that pick up blocklist entries handled: replaced, rested, or left in the pool?
5. On request, can I replace an IP that arrives flagged, and how fast?
6. Which ASNs do the addresses belong to?
7. For mobile ports: who can trigger a rotation?
8. What behaviour does your usage policy ban, and how is it enforced on shared IPs?

Question 8 matters more than it looks. On shared infrastructure, the vendor's abuse policy is your reputation policy. A vendor that lets co-tenants run spam or credential attacks through your IPs is selling you their blocklist entries.

SparkProxy is a datacenter-first provider, and it does not sell residential or mobile proxy plans. Its proxy plans use a rotating gateway: requests exit from a network of 1M+ datacenter IPs across 80+ countries, including 50,000+ US IPs, with random per-request rotation and 5-minute auto rotation, covering the USA and worldwide targets. That is the time-sliced shared model described above, which suits stateless, high-concurrency collection.

Four plans have public prices, all with unlimited bandwidth and 30 days validity:

The speed figures are ceilings under the Fair Usage Policy, not guaranteed rates. Larger Pro (1500 threads) and Pro+ (2000 threads) tiers exist in that policy without a public price, so contact sales for those.

Connect through gateway.sparkproxy.io: port 11000 for HTTP and HTTPS with rotation, 11002 for sticky sessions, 13000 for SOCKS5. Run the pool sampling script above against port 11000 during a trial and you will see your own exposure numbers rather than taking anyone's word for them.

If the problem is blocks from behaviour rather than from the IP, a managed endpoint can be cheaper than moving up an IP class. The SparkProxy Scraping API includes 1,000 free credits with no card, then Starter at $49 for 250,000 credits a month (50 concurrent), Growth at $99 for 1,000,000 (100), Pro at $249 for 3,000,000 (200) and Scale at $599 for 8,000,000 (400). A plain fetch costs 1 credit, a JavaScript render 5, a screenshot or PDF 10.