# Residential proxy detection: how residential proxies work and how to spot them

> What residential proxies are, why they defeat IP reputation, how detection works, what to do on a match, and how to evaluate detection data.

---

LLMS index: [llms.txt](/llms.txt)

---

**In short:** a residential proxy relays traffic through someone else's home internet connection, so it arrives from an ordinary consumer address that reputation lists and geolocation treat as legitimate. Detecting one reliably means knowing which addresses each proxy network is using, and when. A detection is a signal about the connection, not a verdict about the person, so the right response is usually proportionate rather than a blanket block.

## What is a residential proxy?

A residential proxy network is a commercial service that sells access to exit points on home and small-business internet connections. A customer sends traffic to the provider, which forwards it through a device in someone's home, so the destination sees the household's address rather than the customer's.

The exit devices come from several sources:

- **Bandwidth-sharing and "proxyware" apps** that pay or reward users for sharing their connection.
- **Software development kits (SDKs)** embedded in free apps, games and browser extensions, sometimes with consent buried in terms of service.
- **Free VPN and utility apps** that turn their users into exits.
- **Malware and compromised devices**, from infected computers to routers and IoT devices.

Customers can usually choose the country, city or network of the exit and rotate to a new address on every request or every few minutes.

## Residential proxy vs datacenter proxy, VPN, Tor and mobile proxy

| | Exit addresses belong to | Looks like | Typical rotation |
|---|---|---|---|
| **Residential proxy** | Home and small-business connections | An ordinary consumer | Per request or per session |
| **Datacenter proxy** | Hosting and cloud providers | A server | Per request, from large pools |
| **Commercial VPN** | The VPN provider's servers, mostly in datacentres | A server shared by many users | Per connection, from known server ranges |
| **Tor** | Volunteer-run exit relays | A published Tor exit | Per circuit |
| **Mobile proxy** | Mobile network operators | A phone, often behind carrier-grade NAT | Per session, as devices move |
| **ISP or static residential proxy** | Address ranges registered to consumer ISPs, often hosted in datacentres | A consumer, with a stable address | Rarely |

The categories blur at the edges, which is why the provider behind an address matters more than the category alone.

## Why are residential proxies hard to detect?

- **The addresses are real.** They belong to consumer internet providers, so network type, owner and geolocation all look like an ordinary customer.
- **They are shared with real people.** The same address carries the household's own traffic and proxy customers' traffic, sometimes at the same moment.
- **They rotate.** A pool of millions of addresses means each one is used briefly, so per-address rate limits and blocklists barely register it.
- **Reputation lags.** By the time an address earns a bad reputation, the operation has moved on, and the household that owns it may be blocked instead.
- **Carrier-grade NAT** puts many customers behind one address, mixing proxy and ordinary traffic further.

## Who uses residential proxies, and for what?

Some uses are legitimate or grey, such as advertising verification, price monitoring and research. Residential proxies are also a common choice for operations that depend on looking like ordinary local users:

- **Intrusion and espionage:** state-sponsored and criminal operators relay attacks on government, defence and critical-infrastructure networks through residential exits near their targets, alongside [ORB networks](/guides/orb-networks/) of compromised devices. Webscout's [Covert network flows](/solutions/intelligence/covert-network-flows/) observes this traffic from inside residential proxy networks.
- **Credential attacks on remote access:** password spraying and credential stuffing against VPN gateways, webmail and identity portals, spread across thousands of addresses so per-address lockouts rarely trigger.
- **Reconnaissance and exploitation:** scanning and exploit attempts against exposed services that arrive from what looks like a local household.
- **Evading geo-blocking and sanctions screening.**
- **Fraud and abuse:** account takeover, fake accounts, payment fraud, and bots and scraping that pass per-address limits.

## How does residential proxy detection work?

Detection approaches fall into four groups. Mature programmes combine them.

1. **Observing the proxy networks.** Recording which addresses each provider routes traffic through, with first- and last-seen times. This approach can name the provider, which the other signals usually cannot, and it is direct evidence that an address was used as a proxy exit at a known time.
2. **Network signals.** Mismatches between what a connection claims and how it behaves: a round-trip time too long for the stated location, or a TCP or TLS fingerprint that does not match the browser in the User-Agent. See [JA4+ fingerprints explained](/guides/ja4-fingerprints-explained/).
3. **Behavioural signals.** Velocity and patterns across sessions: many login attempts through the same provider, one account hopping between distant networks, identical automation from many addresses.
4. **Reputation lists.** Addresses reported for past abuse. Useful, but always behind the rotation.

Observation answers "is this a proxy, whose, and since when?". The other signals help where observation has no record yet, and help decide what a match means.

## What should you do when you detect a residential proxy?

Respond to the risk of the action, not to the address alone:

- **In the SOC:** label sessions whose far end is a residential proxy, VPN or Tor node, and triage them with the provider and pool type in view.
- **In threat hunting:** pivot on the provider, for example in the [Webscout Observability Platform](/solutions/platform/), to see every connection relayed through it across your connection, DNS and HTTP logs, then look at what those connections share, such as a JA4+ fingerprint or a target host.
- **In incident response:** use first- and last-seen times to establish whether an address was a proxy exit when the incident happened, and through which provider.
- **On remote access:** step up authentication for relayed logins to VPN gateways, webmail and administrative portals, rather than trusting the address.
- **In customer-facing services:** at login, sign-up and checkout, step up authentication or add friction rather than locking accounts, and rate-limit automation by provider rather than by address, so rotation stops helping.

Block outright only where relayed traffic has no legitimate place, such as administrative access.

## Limits and false positives

- **Time.** An address can be a proxy exit one week and an ordinary household the next. Use the last-seen time to judge how current a match is.
- **Shared addresses.** Behind carrier-grade NAT, one household's proxy app can put an address used by many customers in the data.
- **Several providers.** Devices are sometimes enrolled in more than one network, so one address can carry several providers.
- **New networks.** Coverage of a newly launched provider starts when it is first observed.

## How to evaluate residential proxy detection data

- **Attribution:** does a match name the provider, or only say "proxy"? A provider lets you link activity across addresses.
- **Timing:** are first- and last-seen times given per provider and per pool type?
- **Pool types:** does it separate residential from datacenter pools?
- **Freshness:** how often is it updated, and how quickly do new addresses appear?
- **Delivery:** can you look addresses up locally, from a downloaded database, as well as over an API? Local lookups suit collectors, ingest pipelines and other paths where a call per address is too slow.
- **Matching:** does a record say how the address matched?
- **Integration:** does it fit your SIEM, NDR and threat intelligence platform without custom work?

## Where Webscout fits

Webscout's [Anonymising IPs](/solutions/datasets/vpn-proxy-detection/) dataset covers more than 90 million anonymising IP addresses across more than 150 VPN and proxy providers, residential and datacenter pools alike, and every public Tor relay. It names the VPN or proxy provider behind an address, or marks it as a Tor relay, with pool type and first- and last-seen times per provider, updated continually in real time. Query it over the API, download it in mmdb, jsonl, csv or parquet for local lookups, or feed it into your SIEM, NDR, EDR or threat intelligence platform. In the [Webscout Observability Platform](/solutions/platform/) it is applied to every IP address in every event. Pair it with [IP geolocation, ASN and ownership data](/solutions/datasets/geo-ip/) to see where an address sits and who runs it.