Does your proxy vendor run a network or rent one?

Your job has been eating 403s from one exit for forty minutes. You open a ticket. Twenty minutes later the reply comes back: "Please rotate and try again."

Two very different companies send that reply. One recruited the phones those exits run on and can look at them. The other has a gateway, a billing system and a contract with the first one, and it is reading the same error you are. The ticket looks identical either way. You find out which kind you were paying on the day the pool shrinks, which is a bad day to find out.

Some of it you can learn before then. RDAP won't tell you who signed up the phone behind an exit, and no public record will. Four lookups and one question will tell you whether the story you were sold can be checked at all, which is worth twenty minutes before you put money on a balance.

Proxyway found new residential brands were predominantly white labels

Proxyway's 2026 market research went looking for new vendors through Google buy-intent keywords and the BlackHatWorld forum. It "found at least 56 companies that emerged between 2025 and March 2026." Sixty percent of them sold residential proxies, and Proxyway's summary of that group is blunt: "the residential proxy vendors were predominantly white labels."

Read the sample before you repeat the number. At least fifty-six new entrants, found where new entrants advertise. It is not a census of the market, and it doesn't put a percentage on "predominantly." Mobile went the other way: those providers "often built their own dongle-based infrastructures."

The line I'd pin to the wall is further down. "The market supports only 10 to 15 companies with their own networks," Proxyway writes, and "a half of them overlap to various extents due to sharing upstream sources." That's residential only, and it's their estimate, not a list with names on it. The report page is dated October 23, the data mostly comes from March and April, and I reread it on November 6.

Do the arithmetic on that estimate. If somewhere between ten and fifteen networks feed the residential market, and the storefronts number in the dozens every year, then plenty of the residential brands you can buy from are buying from someone else. Some of them are ones you like.

Reselling isn't the defect. An unowned failure is.

We run our own network. Resold capacity is not a scam, and this post is not going to tell you it is.

Plenty of resellers are a better deal than the network they buy from. They buy at a volume you won't reach, and some put two or three upstreams behind one API so a bad week at one of them doesn't stop your job. What a reseller can't do is look at the device. When an exit dies, the reseller has its own gateway logs and whatever status feed the upstream decides to share. The SDK that enrolled the phone, and the reason that block went bad on your target, sit at another company, and the reseller files a ticket there exactly the way you filed one with them.

You pay for that gap by the gigabyte. A vendor that can't see causes answers every failure with "rotate and try again," and every retry is billed bandwidth. One dead IP on a rotating pool is churn. Nobody should open a ticket over it. Fifty dead on the same target inside an hour has a cause. Somebody ought to be able to name it, and on a resold pool that somebody often doesn't work for your vendor.

Google saw the same thing from the far end. Its July post on NetNut says that once a botnet degrades, "proxy operators begin buying capacity from their competitors, effectively becoming a reseller." So the vendor you vetted in January can be selling somebody else's exits by August, same logo, same dashboard. You checked the company once. Its supply moved after you stopped looking.

What NetNut's seizure looked like from one step down

On July 2, 2026, the FBI seized "hundreds of domains associated with NetNut," Krebs reported. Its parent, Alarum Technologies, said it was aware of the seizure and cooperating with investigators.

The same day, Google's GTIG post put the network at "at least 2 million devices" and counted 316 distinct threat clusters using suspected NetNut exits in one week of June. Then came the part a buyer should read twice: NetNut had "a robust reseller program that allows whitelabeling of its network," and Google has "high confidence that many popular residential proxy brands are in fact whitelabeling the NetNut botnet."

Google named none of those brands. Neither will I. Nothing in what I read is a finding against any downstream company, and you shouldn't treat it as one.

Picture one of those brands' customers on July 3, with forty dollars of prepaid bandwidth and a dashboard that still loads. If the brand ran mostly on NetNut, the gateway behind that dashboard pointed at a network whose front door was now an FBI notice. It still is. When we checked on November 6, netnut.io, netnut.com and alarum.io each returned HTTP 200 with the page title "Seized by the Federal Bureau of Investigation," and the WHOIS record for netnut.io lists ns1.fbi.seized.gov as a nameserver, last updated August 11. Our NetNut status page follows it.

That customer couldn't have known the upstream from the brand's homepage. They could have asked.

Twenty minutes of checks shows what kind of IP you bought

None of these proves ownership on its own. What they get you is the type of IP you're actually paying for, and a sense of whether the vendor's account of itself holds up under a lookup.

1. Get ten exit IPs. A trial or the smallest top-up. Rotate, and write down the country of each. If you need a sales call to get ten exits, that tells you how the company sells.
2. Look up each IP's block. RDAP gives you the range and the organisation that holds it.
3. Look up the vendor's domain. Registrar, registration date, expiry.
4. Read the sourcing page. Does it name upstream networks, or only say "our network"?
5. Send support one question. Below.

Step two is a loop. Paste it, put your own exits in the list:

for ip in 73.0.0.1 104.16.132.229; do
  curl -sL "https://rdap.org/ip/$ip" | jq -r --arg ip "$ip" \
    '[$ip, .startAddress + "-" + .endAddress,
      ([.entities[]? | .vcardArray[1][]? | select(.[0]=="fn") | .[3]] | first // .name)] | @tsv'
done

73.0.0.1	73.0.0.0-73.1.255.255	Comcast IP Services, L.L.C.
104.16.132.229	104.16.0.0-104.31.255.255	Cloudflare, Inc.

I picked the two addresses above on November 6 because they read cleanly. 73.0.0.1 is in a Comcast block; that's an ISP. 104.16.132.229 is Cloudflare, a data centre. If six of your ten "residential" exits come back with a hosting company's name, you haven't proved anything about who runs the network. You have earned a ticket, and I'd want to read the reply.

Step three is one URL, https://rdap.org/domain/<domain>. Not for .io. There rdap.org gives you a 404 that says "No RDAP service is available for this resource," which is about the TLD and says nothing about the domain. Use whois.

What the records can't tell you

All of that tells you who holds a block or a domain. It can't tell you who put the SDK on the phone or what the contract between them says. A residential IP is registered to the ISP whether the vendor runs its own network or rents from three.

PeeringDB looks like it should help and doesn't. Listing is opt-in. We searched six large vendor names on November 6 and got six empty arrays back, so a missing entry is worth nothing. Domain age is worth about the same: resifactory.net was registered on March 19, 2026, and I'd be annoyed if you held that against us.

Pool overlap is the best public method I know of, and the people who use it are careful with it. Proxyway tested Smartproxy.org's pool and published the result on March 31: one weekly plan, about 6,963,000 requests, 2,023,029 unique exits logged. 773,087 of Smartproxy.org's exits, 38.21%, also sat in a 16,192,293-IP IPIDEA dataset from January. Proxyway called IPIDEA "very likely either a direct upstream supplier or a significant source" of that pool. Same article: the method "doesn't reveal the nature of the commercial relationship (reselling, sub-licensing, or direct infrastructure control)."

Google's January IPIDEA post lands in the same place. It found "significant overlaps between residential proxy network exit nodes, likely because of reseller and partnership agreements, making definitive quantification and attribution challenging." That's Google, with Google's telemetry. You are not going to settle it with curl and a spare afternoon.

Which leaves the ticket. Send this, word for word:

Which networks do you source from, and what can you see and fix when an IP fails?

Say a vendor writes back: "we buy from these two; we can see our gateway and the upstream's status feed; we credit the GB and escalate the rest." You can plan around that. If the whole answer is "we have a global network," you got a slogan. I'd take the first one over a network owner who says "trust us" every time.

What a dead IP means depends on what you bought

On a rotating pool, owned or resold, one failed exit is churn. Track failures by target. When the rate climbs on one site and not the others, ask the vendor for the cause, and judge them by whether they can name one.

Resold pool, and the cause may live upstream. Your vendor can move you to another exit, credit the gigabytes or forward the complaint; fixing the device or the block may not be in its hands. Proxyway wrote of the provider it tested that more enforcement upstream "could shrink its IP pool without warning." That risk belongs to the whole category, so size the prepay to it. If one upstream looks like most of a pool, keep the balance at a number you'd shrug off losing.

A static ISP block works differently. Nobody else is on it. When it fails it's more likely reputation, targeting or the block itself than some stranger's traffic, and the fix is a new block, not a rotation. Know which type you bought, too. Our ISP product is "ISP or business, not home broadband," so RDAP showing an ISP registration on one of those blocks is the right answer, not a residential proxy wearing a fake label.

Run the loop on ten exits from every vendor on your list, ours included, and send each support desk the sourcing question before you prepay. Put money on the one whose answer names an owner for the failure, start with the smallest top-up the pricing page allows, and add more only after your first real failure has had a real answer.