When a Proxy Network Dies but Its IPs Survive

2026-08-03T08:30:00+10:00

A residential proxy network goes dark. Its domains are seized, its control systems are disrupted and its branded pool almost disappears. Two weeks later, many of the same public IP addresses appear through other proxy services.

Did the takedown fail? Did the same devices move? Were several providers selling the same supply all along?

The honest answer is narrower: the address inventory overlapped across time. That is valuable evidence, but it is not device identity, ownership or motive.

This distinction matters to security and fraud teams deciding what to do with traffic. It also matters to buyers, auditors and researchers trying to establish whether a proxy provider controls the supply chain it describes.

One Address Sits Above Several Relationships

The destination website sees the last layer in a longer chain:

device -> public IP -> SDK or supplier -> proxy pool -> reseller -> buyer -> destination

Each arrow represents a separate relationship.

The device may be a phone, laptop, streaming box, household gateway or server. Software on it, or elsewhere on the same network, sends a buyer's traffic out through a public IP assigned by an ISP or mobile carrier.

An SDK or supplier enrols that capacity. A proxy pool makes it selectable. A reseller may buy the service upstream and sell it under another name. A buyer chooses a location or session through an API. The destination sees a request from the exit address, not this commercial history.

Those layers do not map one-to-one. Several devices can share one public address through a household router or carrier-grade NAT. One device can receive different addresses over time. One supplier can feed several pools. A pool can combine direct supply with upstream inventory. A reseller may not know which device, supplier or SDK produced a particular session.

Our article on how bandwidth sharing feeds residential proxy networks covers the ways capacity enters this chain. The question here is different: what can we infer when a named network disappears but addresses associated with it remain visible elsewhere?

What the NetNut Measurement Found

On 2 July 2026, Google, the FBI, Lumen and other partners took action against the NetNut residential proxy network, also known as Popa. Our comparison of the IPIDEA and NetNut actions separates the controls and public claims involved. Google said it disabled accounts and services used for command and control, shared technical intelligence, and updated Play Protect to disable applications known to contain NetNut SDKs. Google estimated that the network included at least two million devices and said it had high confidence that multiple proxy brands white-labelled NetNut capacity.

Layer3 Intel then published a useful post-event measurement. Its NetNut takedown analysis says the number of unique NetNut exit IPs it observed per hour fell by 99.92% by 5 July. At the brand or gateway layer, that is a decisive decline.

The cross-network result was less absolute. Layer3 Intel took IPv4 addresses it had observed through NetNut in the 30 days before the shutdown and checked whether they appeared through other networks during the following 14 days. Among addresses seen through NetNut in the final one to two days, 78.81% reappeared elsewhere.

The researchers also tried to account for ordinary churn. They applied reappearance rates from a 4 June placebo cutoff to the July cohort. On that basis, they expected about 17.96 million recent addresses to reappear and observed 16.90 million. The difference produced a baseline-adjusted estimate of about 1.06 million IP addresses removed from the wider proxy ecosystem beyond normal churn.

These measurements support three bounded findings:

NetNut's branded, observable exit service collapsed.
Much of the recent public-address inventory associated with NetNut was observable through other proxy networks after the disruption.
Reappearance was lower than the selected June baseline, consistent with a real takedown effect beyond ordinary address churn.

That is already operationally important. A provider name can disappear while some of the address inventory remains commercially reachable.

An IP Match Is Not a Device Match

The same measurement does not prove that the same physical device survived, moved between suppliers or carried two SDKs.

Public addresses are assigned to connections, not permanently engraved on devices. DHCP leases expire. Mobile subscribers move between network gateways. Consumer routers reconnect. Carrier-grade NAT lets many subscribers share public addresses from a provider-controlled pool. RFC 6598 documents shared address space used by service providers for CGNAT, but the ambiguity exists outside that range too: the destination only sees the translated public address.

If 203.0.113.x appears through Network A before a cutoff and Network B afterwards, several explanations fit:

the same device was available through both networks;
different devices behind the same household or carrier address were enrolled;
an ISP reassigned the address to a different subscriber;
a shared upstream supplied both pools;
one provider resold another provider's capacity;
the enumeration system attributed one of the observations incorrectly.

IP overlap increases confidence that address inventory is shared or recycled across the market. It does not identify which explanation is correct for any one address.

It also does not prove supplier ownership. A provider may own infrastructure, contract directly with a supplier, buy capacity through an intermediary, or combine all three. Nor does overlap prove that a device owner did not consent. Consent belongs to a specific person, device, software version, disclosure and time. An IP address contains none of those records.

Most importantly, overlap does not prove motive. It can show that a buyer's request travelled through an observed exit. It cannot establish what the supplier, reseller or provider knew, why a buyer selected the route, or whether the destination request was benign or abusive.

Google's earlier IPIDEA investigation reached beyond address overlap. It analysed applications, Windows binaries, SDK code, command infrastructure and shared server pools, and paired that technical work with platform and legal action. Even then, Google noted that overlaps between exit nodes made definitive quantification and attribution difficult. That is the right standard: use IP observations as one part of a multi-layer attribution, not as a shortcut through the layers.

Read the 1.06 Million Estimate as an Estimate

Layer3 Intel's analysis is stronger than a simple before-and-after count because it recognises ordinary churn and uses an age-matched comparison. Its scale and high-frequency observation also give it a useful view of the market.

The public methodology still leaves material uncertainty:

Enumeration is proprietary. The post describes the volume and timing of observations, but does not publish the complete sampling system, provider coverage, request selection, deduplication rules or validation set. Readers cannot independently reproduce the population from the article alone.
An IP is a noisy unit. Dynamic addressing and CGNAT break a stable link between address, subscriber and device. Counting distinct IPv4 addresses can overstate devices and obscure shared use.
The windows choose what can reappear. The source cohort covers 30 days; the follow-up covers 14. Shorter or longer windows would change both the raw overlap and the churn model.
There is one published placebo cutoff. A single June comparison is useful, but it does not show the normal week-to-week distribution, seasonal effects or whether that period was representative.
No confidence intervals are published. The 1.06 million figure is presented as a point estimate. The post does not provide uncertainty bounds, sensitivity analysis or an error rate for network attribution.
The counterfactual is observational. The difference from baseline is consistent with the takedown removing capacity. Other simultaneous supplier, demand, enforcement or measurement changes could contribute.

None of these limits makes the result useless. They set its resolution. “About 1.06 million fewer addresses reappeared than this baseline predicted” is supported by the published method. “Exactly 1.06 million devices were removed” is not.

What a Sourcing Claim Can Responsibly Prove

A vendor can responsibly prove facts about processes and records it controls.

It can show which entity contracted each direct supplier, which software package enrolled a device, what disclosure was presented, how affirmative consent was recorded, how withdrawal works, which versions were active, and whether a buyer's session can be traced to that evidence. It can document reseller dependencies, prohibit undisclosed sub-supply, test compliance and publish exceptions.

A policy page can prove that a policy exists. A contract can prove that parties accepted terms. Neither proves that every active exit followed the policy.

“Ethically sourced” is therefore too broad unless the provider defines the claim and its coverage. Does it apply only to a proprietary pool? To upstream suppliers? To every session sold by resellers? Does consent come from the device user, the account holder, the network owner or all relevant parties? How quickly is an exit removed after withdrawal?

The strongest claim is session-level and time-bound: for this delivered connection, the provider can trace the supply path to a named enrolment mechanism and current evidence, subject to stated audit limitations. Anything less should be described at its actual scope.

What Auditors and Buyers Should Request

Do not ask only whether sourcing is ethical. Ask for evidence that follows the chain:

a current inventory of direct suppliers, upstream pools and white-label dependencies;
the percentage of delivered traffic covered by direct, auditable sourcing rather than policy language alone;
SDK names, package hashes, versions, distribution channels and signed build provenance;
the exact user disclosure and consent event, including timestamp, software version and withdrawal path;
proof that the person giving consent had authority over the device and network connection;
controls for CGNAT, reassigned addresses, duplicate exits and concurrent appearance across providers;
session-level lineage from buyer request to pool, supplier and enrolment record, sampled by an independent auditor;
contractual limits on sub-suppliers, plus evidence that those limits are tested;
complaint, removal and incident records, including time to disable an exit across every downstream reseller;
methodology for advertised pool size, unique-IP counts and active-device counts, with uncertainty and deduplication rules;
independent test results, exceptions and remediation, not only a clean summary statement.

Buyers should also keep their own record: product and upstream named at purchase time, contract revision, stated sourcing basis, session identifiers where available, destination and purpose, and the control used to prevent abuse. A provider's assurance does not transfer accountability for how the buyer uses the route.

Defenders Still Have a Request to Judge

Post-takedown research can improve proxy intelligence. It cannot turn an IP address into a verdict.

An address that reappears across pools may deserve closer observation, especially on login, account recovery, checkout or expensive APIs. The action should still depend on route, account state, client consistency, behaviour and recent outcomes. That is why a proxy flag is not a security policy.

Keep the provenance of the observation as well. Record which network label was seen, when it was observed, which dataset and version supplied it, what other evidence changed the action, and what happened next. Our guide to residential proxy decision logging sets out that operating record.

A takedown can kill a service without retiring every address that passed through it. The surviving IPs tell us that the market has shared, changing inventory. To say who supplied it, whether a device owner consented, or why a request was sent, we have to follow the rest of the chain.

For the destination, the work continues with the request. The final article in this series explains why a proxy takedown is not a security control and what security and fraud teams should rebaseline after a disruption.

Peakhour.IO - Supply Chain