A login request arrives from an Australian household connection. The ISP and location look ordinary. The address does not appear on a data-centre list.
The request could belong to a customer. It could also have been sent by someone elsewhere and relayed through that connection. The IP tells you where the traffic exited. It does not tell you who controlled the request.
That is the residential proxy problem in one request.
This article is the blog entry point for Peakhour's residential proxy research. The stable explainers now live in our Residential Proxies learning centre, where definition, supply, detection and policy each have a clear home.
What Counts as a Residential Proxy
A residential proxy routes a third party's traffic through consumer or ISP connectivity. The destination sees the exit address rather than the operator's original connection.
Mobile proxy traffic is closely related and often needs similar controls, but it should remain separately labelled. Carrier routing and CGNAT create different sharing and false-positive conditions. Compromised small-office routers are also important proxy supply without automatically becoming residential simply because they sit at the edge.
The full definition, legitimate uses and abuse patterns are covered in What Is a Residential Proxy?.
How the Networks Get Their Supply
Residential proxy capacity can come from people who knowingly install a bandwidth-sharing product. It can also come from monetisation SDKs inside unrelated applications, unclear disclosures, compromised endpoints and pre-infected connected devices.
Those routes differ legally and ethically. They create the same visibility problem for the destination: the web application usually cannot see how the exit joined the pool.
How Residential Proxy Networks Are Formed owns the stable supply model. Our investigation into bandwidth sharing and residential proxy supply follows the recent evidence from app platforms, malware research and device takedowns.
Why Static IP Classification Misses the Moment
IP intelligence is useful. It can identify hosting networks, known VPNs, Tor exits, prior abuse and addresses previously observed in proxy pools. The limitation is time.
Residential addresses are reassigned. Mobile subscribers move between gateways. Several users may share one public address. Proxy applications start and stop. A new exit can carry traffic before a database labels it, and an old label can outlive the session that created it.
Per-connection detection addresses that gap by evaluating evidence available when the request reaches the protected service. Network and protocol fingerprints, browser consistency, route, account state, behaviour and recent outcomes can show that the connection deserves different treatment even when the address looks ordinary.
The canonical detection guide is What Is Residential Proxy Detection?.
A Signal Is Not the Decision
Detecting a likely residential proxy does not prove that the request is malicious. Privacy tools, monitoring systems, authorised research and shared networks all complicate the result. The action should follow the route and the cost of being wrong.
A proxy signal on a public article may only be worth logging. The same evidence on login, combined with an exposed credential and failures across several accounts, may justify a challenge or tighter rate limit. On account recovery, payment or API token creation, the application may require stronger verification.
Proxy Signals and Security Decisions sets out the allow, log, challenge, rate-limit, step-up, block and review choices without turning the proxy label into a blanket ban.
What Buyers Should Ask a Detection Vendor
Do not stop at whether an API returns proxy=true.
Ask how the provider handles fresh exits, mobile carriers, CGNAT and changing address assignments. Test the result against your own customer traffic and known incidents. Confirm that analysts can see enough evidence to review a decision. Measure missed abuse and legitimate-user impact on the routes that matter to your business.
The Proxy Detection Vendor Evaluation guide provides the full checklist.
What the 2026 Takedowns Added
Google's actions against IPIDEA and NetNut gave defenders a rare view across applications, SDKs, control infrastructure, proxy pools and reseller relationships. The operations removed capacity and imposed material operating costs. They also showed why a provider name is not a stable security boundary.
We cover that evidence in three articles:
- IPIDEA and NetNut: What Two Residential Proxy Takedowns Actually Changed examines enforcement and supplier accountability.
- When a Proxy Network Dies but Its IPs Survive examines what address overlap proves and where the inference stops.
- A Proxy Takedown Is Not a Security Control gives application and fraud teams a post-disruption operating checklist.
The conclusion is practical. Upstream action can reduce supply. The destination still needs to judge the next request using current evidence.
Continue by Job
- Start with the Residential Proxies learning hub for the complete topic map.
- Read Five Routes, Five Residential Proxy Decisions for concrete login, signup, recovery, checkout and API policies.
- Read Residential Proxy Detection for APIs Without JavaScript for machine-facing traffic.
- Read What a Residential Proxy Decision Log Should Contain for evidence and review requirements.
- See Peakhour Residential Proxy Detection for the production capability.
