Inside the IPIDEA residential proxy network disrupted by Google

Written on January 29, 2026.

TL;DR

Google disrupted what it describes as one of the world’s largest residential proxy networks, the IPIDEA proxy network, and linked multiple commercial “brands” (including PY Proxy (PyProxy), Luna Proxy, and PIA S5 Proxy) to the same underlying operation.

In this post, I’m publishing two downloadable CSVs containing proxy IPs I personally verified as working, whose latest observed provider is part of the IPIDEA network. These IoC datasets are intended for investigations, enrichment, and risk scoring, not for direct blocking, as residential proxy IPs are often shared and naive blocking would lead to false positives.




Google’s disruption of the IPIDEA proxy network

On January 28, 2026, Google Threat Intelligence Group (GTIG) published a report describing a disruption of the IPIDEA residential proxy network. According to Google, the operation combined several actions: legal measures to take down domains used to control infected devices and proxy traffic, intelligence sharing about IPIDEA SDKs and proxy software with partners, and enforcement via Google Play Protect to warn users, remove affected applications, and block future installation attempts.

Google also states that “ethical sourcing” claims commonly made in the residential proxy ecosystem are often incorrect or overstated. In their analysis, many of the apps involved did not clearly disclose that installing them would enroll the user’s device into the IPIDEA proxy network.

Why I’m publishing IPIDEA-linked proxy intelligence

As part of my verified proxy IP detection database, I track proxy IPs across a wide range of residential, datacenter, and ISP proxy providers:

This database is built to answer a practical question defenders regularly face: which proxy IPs are actually usable right now, not just advertised or theoretically available.

After Google publicly tied multiple proxy “brands” to the IPIDEA network (including PY Proxy, Luna Proxy, and PIA S5 Proxy), I wanted to share a concrete artifact defenders can use immediately: recent, verified exit IPs whose latest observed provider is linked to the IPIDEA network.

The goal is not to restate Google’s findings, but to complement them with operational data that can help security teams investigate recent activity, enrich events, and reason about risk in environments where residential proxies intentionally blur the line between legitimate users and automation.

IPIDEA proxy IoCs, 16M+ verified residential exit IPs

This post includes IPs observed in the last 30 days, relative to January 29, 2026. It only contains IPs whose last observed appearance is linked to a proxy provider associated with the IPIDEA network.

In total, the dataset contains 16,192,295 unique IPs linked to the IPIDEA network, with the following breakdown by last observed provider:

  • PY Proxy (PyProxy): 13,429,821 IPs
  • PIA S5 Proxy: 2,213,174 IPs
  • Luna Proxy: 549,300 IPs

Available downloads

Dataset structure and field definitions

The full CSV includes the following fields:

  • ip: The IP address of the detected proxy server.
  • asn.asn: The Autonomous System Number (ASN) associated with the proxy IP address.
  • asn.name: The name of the organization that owns the ASN (for example, “Amazon.com” or “DigitalOcean”).
  • asn.network: The network range in CIDR notation that contains the proxy IP address (for example, 192.168.1.0/24).
  • geo.countryCode: The ISO 3166-1 alpha-2 country code of the proxy IP address (for example, “US”, “FR”).
  • lastSource: The proxy provider or platform through which I last observed this IP address operating as a proxy.

    Note that a proxy IP may be usable through multiple providers at the same time or over its lifetime. This field only reflects the most recent provider I observed.

  • lastSeenAt: An ISO 8601 timestamp indicating when this IP address was last confirmed to be operating as a proxy.
  • firstSeenAt: An ISO 8601 timestamp indicating when this IP address was first confirmed to be operating as a proxy.
  • numDaysSeen: The number of distinct days on which proxy activity was observed for this IP address.

How these IoCs were collected and verified

These IPs come from the proxy tracking pipeline behind Proxies & IPs. Every IP included in these datasets is verified, meaning I was able to route traffic through it and confirm that it behaved as an active proxy endpoint.

The tracking process continuously monitors a wide range of residential, datacenter, and ISP proxy providers and records when an IP is actually usable, not just advertised. This allows me to reason about recency, persistence, and provider attribution rather than relying on static or self-reported lists.

For the purpose of this post, I applied a narrow scope filter: I only include IPs whose last observed provider (lastSource) is associated with the IPIDEA network, including brands explicitly mentioned by Google such as PY Proxy (PyProxy), Luna Proxy, and PIA S5 Proxy.

This means the datasets reflect what was accessible through IPIDEA-linked services recently, not a historical or exhaustive inventory of every IP ever associated with those providers.

How to interpret and use these IoCs safely

These IPs are often shared, and residential exit nodes frequently mix traffic from automated tools and legitimate human users. As a result, treating this dataset as a blocklist would almost certainly lead to false positives.

There are also a few important caveats to keep in mind when interpreting the data:

  • Provider attribution is based on the last observed source.

    I only track the most recent proxy provider through which an IP was observed. Some IPs may have been used by other proxy networks in the past, or even concurrently.

  • Proxy networks reuse and chain infrastructure.

    Like many large proxy networks, IPIDEA does not rely exclusively on its own residential pool. Requests may be routed through or resold from other residential proxy networks. As a result, some IPs in this dataset may also appear in, or originate from, other proxy ecosystems while still being usable through IPIDEA-linked services.

Because of this, the dataset is best used as context, not as a verdict.

Recommended use cases:

  • Risk scoring: use presence in the dataset as a supporting signal combined with recency, frequency, and behavior.
  • Behavioral enrichment: correlate with session-level signals such as velocity, navigation patterns, and device characteristics.
  • Incident investigation: quickly assess whether suspicious activity recently involved IPs accessible through IPIDEA-linked proxy providers.
  • Secondary signals: alert prioritization, step-up authentication, or analyst triage.

What I do not recommend:

  • Blind IP blocking based solely on membership in this dataset, especially for residential IPs.

Access to the full 30-day proxy intelligence database

This post is a scoped extract focused on IPIDEA-linked providers. If you want access to the full 30-day proxy database (with many more proxy providers), contact me:

contact@deviceandbrowserinfo.com

Other recommended articles

Privacy leak: detecting anti-canvas fingerprinting browser extensions

In this article, we present 2 approaches that can be used to detect anti-canvas fingerprinting countermeasures and we discuss the potential consequences in terms of privacy for their users.

Read more29-06-2024
Fraud detection: how to detect if a user lied about its OS and infer its real OS?

In this article, we explain how we explain how you can detect that a user lied about the real nature of its OS by modifying its user agent. We provide different techniques that enable you to retrieve the real nature of the OS using JavaScript APIs such as WebGL and getHighEntropyValues.

Read more11-06-2024
(Unmodified) Headless Chrome instrumented with Puppeteer: How consistent is the fingerprint in 2024?

In this article, we conduct a deep dive analysis of the fingerprint of an unmodified headless Chrome instrumented with Puppeteer browser. We compare it with the fingerprint of a normal Chrome browser used by a human user to identify the main differences and see if they can be leveraged for bot detection.

Read more02-06-2024