What Are Whitelabel and Reseller Proxy Networks?

Three words get used loosely in this market, and they mean different things.

Reseller. A company that buys capacity wholesale from a network operator and sells it on, usually under its own brand and pricing. The customer relationship, the support queue and the risk of non-payment sit with the reseller. The IPs do not.

Whitelabel. A stronger version of the same thing: the upstream operator supplies not just the bandwidth but the entire product surface, dashboard, API, documentation and sometimes the billing engine, rebranded with the reseller's logo and domain. From the buyer's side it looks like a self-built platform. Under the skin it is the upstream's software talking to the upstream's network.

Aggregator. A brand that buys from several operators and blends them behind one gateway. Aggregators genuinely do add diversity, but the diversity is theirs to configure and can change without notice, and you rarely get to see the current mix.

The distinction that matters is not the label a company uses. It is whether the company controls the address space. A network operator holds IP allocations from a Regional Internet Registry, runs an Autonomous System, announces its prefixes with BGP as specified in RFC 4271, and can therefore add, retire, renumber or clean up addresses. A reseller can do none of that. It can open a ticket.

Almost every proxy product on sale today sits somewhere on this stack. Knowing which layer you are buying from tells you what your vendor can actually fix.

Each layer down adds margin and adds latency to problem resolution. A sub-reseller reporting a subnet-wide block has to convince a reseller, who has to convince the operator, who has to decide whether one downstream customer's complaint is worth a renumber. That chain is why "we have escalated to our network team" sometimes means "we emailed a vendor."

Reselling dominates because owning a network is expensive in ways that are invisible from the outside.

For datacenter and ISP pools, an operator needs address space. IPv4 has been exhausted at the registry level for years, and RIPE NCC ran out in November 2019, so new space is bought or leased on a transfer market rather than requested. On top of that sit transit contracts, an AS number, route objects, RPKI Route Origin Authorizations per RFC 6482, and abuse handling staff. None of that is a weekend project.

For residential and mobile pools the barrier is different and higher: sourcing. Consent-based peer-to-peer proxy networks are built by bundling an SDK into free apps or VPNs, paying the publisher, disclosing the arrangement to the end user, and keeping records that survive a data protection audit under the GDPR. Building that supply chain takes years and legal budget.

So the rational move for a new entrant is to buy wholesale and compete on the parts that are cheap to differentiate: price, UX, support, documentation, payment methods. That is a legitimate business. Plenty of well-run resellers deliver better day-to-day service than the operator behind them.

Be precise about the value here, because "reseller" gets thrown around as an insult and it should not be.

• Packaging. Operators often sell in commitments that a small team cannot absorb. A reseller who buys a large block and retails 5 GB plans is doing real work.
• Billing and payments. Local currency, local payment rails, invoices a regional finance department will accept, tax handling. Cross-border payment friction is a genuine barrier that resellers remove.
• Support in your language and timezone. A responsive first line that reproduces your issue and files a clean upstream ticket is worth money.
• Product surface. Better dashboards, saner APIs, usable docs, and integrations the operator never bothered to build.
• Vertical specialisation. A reseller who serves only ad verification, or only price monitoring, accumulates knowledge about targets and configurations that a general operator does not have.
• Regional presence. A legal entity you can contract with, and in some markets sue, in your own jurisdiction.

None of that is fake. The problem is not reselling. The problem is a buyer who believes they bought network diversity and bought a logo instead.

You share subnets with customers of other brands

An upstream pool is one pool. If three brands resell the same /24, the reputation of every address in that range is a shared resource, and you have no visibility into what the other brands' customers are doing with it. This is the ordinary economics of shared subnet proxies, except the sharing is happening across companies rather than inside one.

The practical effect: a target that fingerprints at the network level rather than the address level will decide about your traffic based on behaviour you did not generate. Many anti-bot systems score at /24 granularity precisely because it is cheap and effective.

An IP you consider yours can be burned by traffic you never sent

"Dedicated" from a reseller usually means dedicated within that reseller's allocation, not globally exclusive at the operator. Even where exclusivity is real today, the address had a history before you, and it will have a history after you. When the reputation of an address collapses, the operator decides whether to retire it. Your vendor does not.

Support cannot fix network-level problems

This is the sharpest consequence and the easiest to test. Ask a candidate vendor what happens when a whole /22 gets blocked by a target you care about. An operator answers in terms of actions: pull the range from rotation, renumber, announce replacement space, adjust the pool weighting. A reseller answers in terms of process: raise it with the provider, monitor, offer credit. Both answers can be given in good faith. Only one of them ends with the problem fixed on your timeline.

Your SLA is a copy of somebody else's SLA, minus the bargaining power

A reseller cannot promise more availability than it buys, and its remedy against the operator is usually a service credit. So a 99.9% figure in a reseller contract is a pass-through of the upstream commitment, backed by a company with far less bargaining power to enforce it than you would have contracting directly. Read the remedies clause, not the percentage. Our guide to evaluating a proxy service covers the contract questions in more depth.

Two brands on one pool is not redundancy

This is the expensive mistake. Teams buy a second vendor as failover, split traffic 70/30, and feel covered. If both resell the same operator, the failure modes are perfectly correlated: the same outage takes out both, the same burned ranges block both, the same rotation bug hits both. You have paid twice for one point of failure and added an integration to maintain.

Redundancy is a property of the underlying network, not the number of invoices.

The consent and compliance chain gets longer than your paperwork

If you process personal data through a residential pool, your data protection assessment needs to reach the layer where consent was actually collected. Every resale step adds a party whose practices you are inheriting and cannot inspect. Ask for the chain in writing before your legal team asks you for it.

None of these checks require the vendor's cooperation. Run them during a trial, on real exit IPs, and the picture usually resolves within an hour. The examples below use addresses from the documentation range reserved by RFC 5737.

1. Look up the ASN behind the exit IPs

Map each exit address to the Autonomous System that originates its prefix. The classic tool is the Team Cymru IP to ASN mapping service, which answers over plain whois:

whois -h whois.cymru.com " -v 203.0.113.45"

Read the origin AS and the allocation date. For a datacenter or ISP pool, one operator's own space tends to concentrate in a small number of AS numbers, with prefixes announced by the AS the company publicly claims. Scattered origins across a dozen unrelated hosting ASNs are the signature of a pool assembled by purchasing capacity, not by building it.

Residential pools are the exception, and an honest one: their exits sit on consumer ISP addresses, so the origin AS will be a carrier like Comcast or Vodafone no matter who operates the pool. For residential, the ASN test tells you almost nothing. Use the gateway test and the overlap test instead.

2. Read the RIR allocation record, not just the org name

whois, specified in RFC 3912 and now largely superseded by RDAP (RFC 7480), exposes the allocation hierarchy. That hierarchy is where resale shows up.

whois 203.0.113.45 | grep -Ei 'netname|status|org|descr|mnt-by|country'
dig +short -x 203.0.113.45

In the RIPE database, the status: field is the tell. ALLOCATED PA means the registry handed the block to that member directly. SUB-ALLOCATED PA or ASSIGNED PA sitting under someone else's allocation means the holder received it from another party. In ARIN space the equivalent signal is a network shown as Reallocated or Reassigned, published through SWIP, with a parent block belonging to a different organisation. A vendor whose ranges are consistently reassignments under a hosting company's allocation is buying, not building.

Also check whether an RPKI Route Origin Authorization exists and which AS it authorises. Only the address holder can create one.

3. Check reverse DNS for consistency

PTR records, defined in RFC 1035, can only be set by whoever controls the reverse zone, and that control follows the allocation. Sample fifty addresses across a range and look at the pattern.

Consistent, structured names across the whole block (pool-2.ams.operator.example, pool-3.ams.operator.example) indicate one operator with delegated control. A block where PTRs are empty, or point at a hosting company's generic template while the vendor claims the space, tells you the vendor never received the delegation. Mixed naming conventions inside a single /24 usually means several parties are being served from one allocation.

4. Inspect the gateway, not only the exits

This is the check most buyers skip and the one that most often settles the question for residential pools. Resolve the vendor's gateway hostname, then look at where it actually terminates:

dig +short gateway.vendor-under-test.example
whois -h whois.cymru.com " -v 198.51.100.10"
openssl s_client -connect gateway.vendor-under-test.example:443 \
  -servername gateway.vendor-under-test.example </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Three things leak here regularly. The gateway IP belongs to an ASN with no relationship to the vendor's brand. The TLS certificate carries subject alternative names for a different company's domains. And the error bodies returned on a bad password, a blown concurrency limit or an unroutable target come back in a format and wording that belongs to somebody else's product. Custom response headers are another giveaway: an unusual X- header appearing on a supposedly bespoke gateway is upstream software talking.

5. Compare the control plane against the network

Ask for a feature the operator layer owns and the reseller layer cannot fake. Can you request a specific city, not just a country? Can you get a static exit held for thirty days? Can you have a named /24 excluded from your rotation? Can you see, per request, which exit IP served it? An operator can usually say yes to at least some of these because it is manipulating its own routing. A reseller can only offer what the upstream proxy exposes through its API, which is why reseller feature sets across unrelated brands look strangely identical.

6. Ask who operates the ASN, in writing

The direct question, phrased so it cannot be answered ambiguously: which AS numbers originate the prefixes our traffic will exit from, and is your company the registered holder of those allocations? A network operator answers with numbers. A reseller either declines, which is a fair and honest answer, or names the upstream, which is also fine. Anything vague in response to a specific question is the actual signal.

If you are buying a second vendor for redundancy, this is the single test worth running before you sign.

Take trials from both. Pull 500 exit IPs from each, targeting the same country and the same rotation mode so you are comparing like with like. Reduce every address to its /24 and compare the two sets.

Run the same comparison on the ASN set rather than the /24 set for a coarser but faster read. Then repeat it a month later. Aggregator mixes shift, and a pair that looked independent in March can converge by June when one vendor changes supplier.

One caveat keeps this honest: two genuinely independent residential networks recruiting from the same large ISPs will show some natural overlap, especially in small countries with two or three dominant carriers. Judge the magnitude, not the existence.

Collecting a few hundred exit IPs by hand is tedious. The SparkProxy Scraping API accepts an own_proxy parameter, which makes it a convenient harness for auditing somebody else's gateway: SparkProxy handles the request plumbing while the traffic exits through the pool under test. Vendor hostnames below use the reserved .example TLD from RFC 2606.

import requests
from collections import Counter

SPARK = "https://scrape.sparkproxy.io/api/v1"
API_KEY = "YOUR_API_KEY"
CANDIDATE = "http://user:pass@gateway.vendor-under-test.example:7000"

exits = Counter()

for i in range(500):
    r = requests.get(
        SPARK,
        headers={"X-API-Key": API_KEY},
        params={
            "url": "https://api.ipify.org",
            "own_proxy": CANDIDATE,      # exit through the pool under test
            "render_js": "false",        # no browser needed for a plain echo
            "session_id": f"audit-{i}",  # new label per call, fresh rotation
            "format": "html",
        },
        timeout=60,
    )
    if r.status_code == 200:
        exits[r.text.strip()] += 1

subnets = {".".join(ip.split(".")[:3]) for ip in exits}
print(f"{len(exits)} unique IPs across {len(subnets)} /24s")

The same check in cURL, useful for a quick single look:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://api.ipify.org" \
  --data-urlencode "own_proxy=http://user:pass@gateway.vendor-under-test.example:7000" \
  --data-urlencode "render_js=false"

Two numbers fall out of this that vendors rarely publish. Unique IPs per thousand requests is the real rotation depth for your country and your plan, which is usually a small fraction of the advertised pool size. Distinct /24s is the actual subnet spread, and that is what a target scoring at network level cares about. A pool advertising millions of IPs that returns 340 unique addresses across 12 subnets in 500 calls is not lying about the pool. It is telling you which slice of it you were assigned.

Feed the collected addresses straight into the whois and ASN checks above and you get the ownership picture and the pool-depth picture out of one dataset.

Send these before the trial ends. The answers, and the speed of the answers, are both data.

A "yes, we resell, here is who from and here is what we add on top" answer is a good answer. Disclosure is the thing being tested, not ownership.

There are plenty of situations where the reseller is objectively the better purchase.

• Small volume. If you need 20 GB a month, an operator's minimum commitment may be five times your total budget. A reseller's packaging is the whole reason you can buy at all. The same logic runs to the bottom of the market, where the real question becomes free versus paid proxies.
• You need a local counterparty. Contracting, invoicing and dispute resolution inside your own jurisdiction has real value that has nothing to do with packet forwarding.
• Support quality beats network control for your workload. If you collect data from ordinary, lightly defended targets, subnet hygiene barely matters and responsive support matters a lot.
• You want a specialist. A vertical-focused reseller may hand you working configurations for your exact targets that a general operator has never tested.
• Short projects. For a six-week engagement, a fast start and flexible terms beat long-run network guarantees.

The rule is simple. Buy from a reseller when what you need is packaging, price and service. Buy from the operator when what you need is control over addresses, subnets and routing. Just know which one you bought, and never count two resellers of the same network as two networks.