Do Two Proxy Providers Share the Same Exit Pool? An Overlap Test

Buying from two proxy providers does not automatically create two independent exit pools. Providers may source capacity from overlapping access networks, announce routes through the same upstreams, or expose similar inventory in the same market. That overlap can be acceptable for coverage, but it weakens a failover plan that assumes one provider will survive a network-specific disruption affecting the other.

This guide shows how to measure overlap at five levels: exact exit IP, routed prefix, origin ASN, requested geography, and time window. Use it for authorized procurement tests—not to enumerate, stress, or bypass controls on networks you do not own.

Define the decision before collecting exits

An overlap score has meaning only when tied to a decision. Common questions include:

• Will Provider B add new market coverage?
• Are the providers independent enough for outage failover?
• Does a premium pool add new networks or mostly relabel existing capacity?
• Is observed overlap stable, or does it appear only during a supply shortage?
• Does one provider reach the same networks with better session quality or lower cost?

Write an acceptance threshold for every critical market. A team seeking geographic breadth may tolerate address overlap if city coverage improves. A team seeking network resilience should place more weight on prefix, ASN, gateway, and time-window independence.

Build a fair collection matrix

Test both providers under equivalent conditions:

• identical authorized destinations or an endpoint you control;
• the same requested market and granularity;
• the same residential, mobile, static ISP, or hosting class;
• the same IPv4 or IPv6 requirement;
• matching sticky or rotating session policy;
• equal observation windows, request intervals, and trial counts;
• the same client, DNS mode, headers, timeout, and validation rules.

Interleave providers instead of finishing one test before starting the other. This reduces time bias when inventory changes during the day. Cap concurrency and stop when a destination or provider signals a rate or policy limit.

Record one neutral observation

Store only the fields needed for comparison:

trial_id
provider_alias
observed_at_utc
requested_market
observed_market
address_family
exit_token
routed_prefix
origin_asn
session_policy
gateway_region
valid_result
failure_class
duration_ms
bytes

Replace the raw exit address with a keyed, rotating token in the analytics table when the address itself is not required. Keep the key in an approved secret system and define a short retention window. Never store proxy credentials, cookies, personal data, or customer payloads.

Enrich carefully: registration is not routing

Use standardized RDAP data to identify the registered network range and responsible organization. For operational routing context, use a route-observation source that reports the containing announced prefix and origin ASN.

Do not treat these fields as interchangeable:

• registered range: the Internet number resource registration record;
• announced prefix: the route containing the exit when observed;
• origin ASN: the autonomous system originating that route in the selected routing view;
• access-network label: the proxy provider's commercial classification;
• geolocation: an estimate that can differ across databases and time.

Cache enrichment results for a bounded period, record the source and lookup time, and preserve “unknown” rather than inventing a value. Registration organization, route origin, end-user ISP, and proxy supplier can be different entities.

Calculate five overlap layers

1. Exact exit-IP overlap

Let A and B be the unique exit-token sets observed for each provider in the same market and window.

intersection = count(A ∩ B)
union = count(A ∪ B)
jaccard = intersection / union
coverage_from_B = count(B - A) / count(B)

Jaccard overlap is symmetric. coverage_from_B answers a different buying question: what share of Provider B's observed exits was new relative to Provider A?

Report set sizes with every percentage. Two shared addresses out of four is very different evidence from two shared addresses out of forty thousand.

2. Routed-prefix overlap

Exact IP comparison can understate shared infrastructure. Two exits may be different addresses inside the same announced prefix. Normalize each valid address to the containing prefix from the same routing view and lookup window, then compare prefix sets.

Also compute a coverage-weighted result so that one frequently observed prefix cannot masquerade as broad diversity. Keep raw and weighted metrics separate.

3. Origin-ASN overlap

Compare the set and distribution of origin ASNs. Useful fields include:

• unique ASN count per provider;
• ASN-set Jaccard overlap;
• share of observations in ASNs used by both providers;
• top-one and top-five ASN concentration;
• new-ASN contribution from the second provider.

High ASN overlap does not prove the pools are identical. Large access networks contain many independent prefixes and users. It does show that provider-level failover may still depend on the same network operators.

4. Geography overlap

Compare requested country, state, or city with the observed consensus from more than one allowed signal. Distinguish exact address overlap from shared geographic coverage. Two providers can cover the same city through completely different networks, or show different city labels for addresses in the same routed block.

Do not use geolocation disagreement as evidence of fraud. Treat it as a measurement uncertainty that needs classification.

5. Temporal overlap

Run the same matrix across several approved windows. Calculate overlap per window and across the full study. Track:

• exits seen from both providers in the same window;
• exits shared only on different days;
• first-seen and last-seen times;
• churn within each provider;
• persistence of shared prefixes and ASNs.

A one-hour snapshot can miss rotating inventory or overstate overlap during a temporary supply event.

Prevent biased results

Separate sessions from requests

A hundred requests through one sticky session are one exit observation for pool coverage, not one hundred independent exits. Keep request reliability metrics, session metrics, and unique-exit metrics separate.

Control the sampling policy

If Provider A rotates per request and Provider B rotates every ten minutes, raw unique counts are not comparable. Use matching documented policies or state clearly why they differ.

Avoid destination-driven selection

A destination may block or route certain exits differently. Where allowed, collect the route observation from an endpoint you control and validate the business task separately. Never interpret blocked observations as proof that an address did not exist.

Preserve failed trials

An exit returned only by successful requests creates survivorship bias. Retain gateway, authentication, tunnel, timeout, policy, and content-validation failures in the denominator, even when no exit token is available.

Turn overlap into a procurement decision

Create a market-level scorecard with:

• useful-result rate and cost per useful result;
• exact-IP, prefix, and ASN overlap;
• unique contribution from each provider;
• top-network concentration;
• geography validity;
• sticky-session survival;
• churn and repeat-window agreement;
• gateway and operational dependency;
• unresolved policy or sourcing concerns.

Do not use one composite score unless the weights were fixed before seeing results. A low-overlap pool that fails the authorized workload is not valuable. A high-overlap provider can still be useful if it delivers a better gateway, support path, session policy, or commercial contract.

Failover validation

After measuring overlap, run a controlled failure drill. Disable one provider route in the client, not the external network, and confirm that the second route:

1. authenticates independently;
2. resolves through its intended DNS path;
3. reaches the required market and address family;
4. does not reuse the disabled provider's gateway configuration;
5. stays within retry, latency, and cost budgets;
6. preserves or intentionally resets application sessions;
7. emits distinct telemetry and can be rolled back.

Provider diversity is not complete if both routes depend on one credential store, gateway hostname, deployment region, billing state, or retry controller.

Release checklist

• [ ] Decision and market-specific overlap thresholds are written first.
• [ ] Providers use equivalent route classes and session policies.
• [ ] Tests are interleaved across the same approved windows.
• [ ] Requests, sessions, exits, prefixes, and ASNs have separate denominators.
• [ ] Registration, routing, access type, and geolocation are not conflated.
• [ ] Exact-IP, prefix, ASN, geography, and temporal overlap are reported.
• [ ] Set sizes and uncertainty accompany every rate.
• [ ] Failed and missing observations remain visible.
• [ ] Cost per useful result is measured.
• [ ] The failover route has no hidden shared operational dependency.
• [ ] Credentials and personal data are absent from logs.

FAQ

Is any exact-IP overlap a problem?

No. Shared inventory can be legitimate, and small overlap may occur by chance over time. Interpret overlap relative to sample size, market, route class, persistence, and the buying objective.

Does the same ASN mean the same proxy pool?

No. An ASN can originate many networks. ASN overlap is a resilience indicator, not proof of a commercial or technical relationship.

How many observations are enough?

There is no universal number. Continue until critical market estimates stabilize across multiple windows and the uncertainty is small enough for the procurement decision. Report the denominator and stopping rule.

Should raw exit IPs be shared in a report?

Usually not. Use salted or keyed tokens for set comparison, aggregate prefix and ASN results, restrict retention, and share raw addresses only when a legitimate operational need and access policy require it.

Compliance and safe operation

Use only authorized endpoints, provider accounts, markets, and traffic. Respect provider terms, destination policies, privacy requirements, rate limits, and local law. Do not use this method to enumerate third-party pools, evade blocks, or identify end users. Minimize identifiers, restrict access, and delete raw observations on schedule.

Continue with the proxy pool ASN concentration audit, proxy exit churn measurement guide, and residential proxy geo-granularity test.

Source note: APNIC, Registration Data Access Protocol documentation, reviewed September 11, 2026; RIPE NCC, Network Info API documentation, reviewed September 11, 2026; ARIN, IP and ASN Registry Services documentation, reviewed September 11, 2026.