'Proxy: true' is not a fraud strategy

Benjamin Brundage — Mon, 28 Sep 2026 04:12:16 +0000

A lot of IP-risk responses are technically correct and operationally useless.

They tell you an address is a proxy. Sometimes they add a confidence score. Then the fraud team is left to decide whether to block a login, challenge a checkout, or ignore the signal.

The missing piece is usually context.

A commercial VPN exit used by thousands of ordinary customers is not the same thing as a residential proxy endpoint that appeared ten minutes ago. A crawler operated by a known search engine is not the same thing as a relay sourced through an opaque bandwidth-sharing SDK. If all four become proxy=true, the detection is doing less work than it appears to be doing.

Provider attribution changes the decision

The most useful question is not just “is this a proxy?” It is:

Which provider or network is behind it?
What kind of access does that provider sell?
Is the address residential, mobile, hosting, or mixed?
When was it last observed behaving this way?
Do the surrounding signals agree?

Provider attribution turns a generic flag into something an analyst can investigate and a rules engine can treat differently.

For example, a login from a long-lived consumer VPN exit might deserve a small risk increase. The same login through a rotating residential network, combined with a new device and rapid account switching, deserves a much stronger response. The proxy signal did not make that decision on its own; it made the other evidence easier to interpret.

Freshness matters more than a giant historical list

Proxy infrastructure moves quickly. Residential endpoints churn, VPN providers add ranges, and resellers change upstream networks. A database can contain millions of rows and still be stale where it matters.

We have found it more useful to preserve observation time and source context than to pretend an IP has one permanent identity. Ask how recently the address was seen, whether the observation repeated, and whether the network relationship still exists.

A practical response should give your system enough information to apply decay. An observation from minutes ago can affect a real-time decision. One from six months ago may still help an investigation, but it should not carry the same weight.

Keep the risk policy in your system

Detection vendors should describe infrastructure. Your application should decide what to do with it.

A simple policy might look like this:

Treat proxy or VPN status as one feature, never the verdict.
Increase weight for recent residential or mobile proxy observations.
Add provider-specific rules only when you understand the provider's product and sourcing model.
Combine network evidence with account age, device history, velocity, payment risk, and user behavior.
Log the fields that caused a challenge or block so an analyst can explain it later.

This also reduces false positives. A privacy-conscious customer using a mainstream VPN can pass when the rest of the session looks normal, while an attacker rotating through residential endpoints still accumulates enough evidence to trigger a step-up.

What we return at Synthient

We built Synthient around this problem. A lookup can include the observed provider, proxy or VPN type, network ownership, geography, behavior signals, timestamps, and a risk score. The same data is available as bulk feeds and a live stream for teams that need to update controls continuously.

The goal is not to produce the loudest possible blocklist. It is to make an IP signal specific enough that a fraud or security team can defend a decision.

You can try a lookup at synthient.com/context. I am especially interested in the fields your team needs before it will trust a proxy signal in production.

Residential Proxy Detection: Why IP Reputation Alone Is Not Enough

Benjamin Brundage — Sun, 27 Sep 2026 04:35:59 +0000

Here’s the awkward question at the center of residential proxy detection: what do you do with an IP address that is both legitimate and being used as proxy infrastructure?

That isn’t a hypothetical edge case. It’s the normal case.

A residential proxy exits through an ordinary consumer connection. The ASN belongs to a real ISP. The geolocation may be accurate down to the city. A person in that household could be streaming a movie while, through the same public address, somebody else is automating signups or testing stolen credentials.

Calling the IP “bad” doesn’t just lose context. Calling it “clean” is worse.

That’s where traditional reputation systems start to wobble. Most were built around addresses that stay suspicious long enough to earn a reputation: hosting ranges, known VPN exits, scanners, or repeat offenders. Residential proxy addresses rotate, disappear, return, and keep serving normal household traffic in between.

The IP is real. The session may not be.

Where does the supply come from? A user might knowingly install a bandwidth-sharing app. Another might install an unrelated app with a proxy SDK buried in its terms. Other endpoints are routers, Android TV boxes, or phones that were compromised outright.

On the receiving end, all of them can look frustratingly normal:

The network is a consumer ISP, not a datacenter.
The country and city fit the account profile.
A large pool lets an operator change addresses after every request.
The same address can alternate between human and automated sessions.
Resellers can obscure which provider actually supplied the endpoint.

ASN, country, and yesterday’s abuse complaints can’t answer the question the risk team actually has: what is happening through this address right now?

What we saw in the traffic

Synthient monitors proxy SDKs and their outbound traffic through Helios, our proxy-tracking and honeypot platform. In May 2026, the residential proxy traffic we observed touched roughly 9.2 million unique domains and subdomains.

The headline number sounds dramatic. The distribution told us more. Traffic wasn’t spread evenly across the web; streaming platforms, financial services, advertising networks, and major e-commerce sites received a disproportionate share.

In one observed botnet, video streaming and media made up 41% of targeted domains. Advertising-related traffic accounted for another 9.3%, much of it consistent with ad fraud. The rest included familiar headaches: credential stuffing, account takeover, automated purchasing, large-scale scraping, and promotion abuse.

One category was easy to miss. Residential proxy access can provide a path toward services exposed inside consumer networks. Botnets keep probing Android Debug Bridge on port 5555, looking for poorly secured TV boxes and other Android devices. The endpoint isn’t always just an exit node. Sometimes it’s the next target.

A useful answer needs a timestamp

“Proxy” shouldn’t be a permanent tattoo on an IP address. It should be an observation with provenance and time attached.

Before we act, we ask five things:

Is the network residential, mobile, hosting, or something else?
Which proxy, VPN, relay, or reseller was seen using it?
When was that provider last observed on the address?
Was the activity programmatic, botnet-related, or otherwise unusual?
What is this particular session doing?

Recency changes the answer. An observation from five minutes ago can matter during a password reset. Six months later, it may be little more than historical trivia.

An IP-only block rule doesn’t age well. It compresses four different facts—the network owner, the person using the connection, the proxy provider, and the current requester—into one brittle label.

Detection is not the same as blocking

The most effective policy we have seen is deliberately boring: enrich first, then choose friction based on the action.

Public browsing can usually continue while the signal is recorded. Signup, password reset, payment, gift-card redemption, and promotional claims deserve more scrutiny. A recent residential-proxy observation combined with a new device, impossible travel, or unusual account velocity is a good reason for step-up authentication. Blocking makes sense when several high-confidence signals agree, or when the product explicitly prohibits anonymized traffic.

That policy catches more abuse without pretending every customer behind a residential ISP address is suspicious.

Looking up an IP with the Synthient API

Synthient’s v4 IP API returns network and location context alongside a risk score, behavioral categories, provider attribution, and the last observation time for each provider.

curl -G https://api.synthient.com/api/v4/lookup/ip/101.53.218.152 \
  -H "x-api-key: $SYNTHIENT_API_KEY"

A response can say, at the same time, that an address belongs to a legitimate residential ISP and that one or more proxy providers were recently observed using it. That apparent contradiction is the point. The network owner and the current use of the address are different facts.

For higher-volume systems, the same intelligence is available through batch lookups, downloadable snapshots, and real-time NDJSON streams. Keep API keys server-side, scope them narrowly, and separate them by environment.

Residential proxy detection is not a contest to build the longest blocklist. It is an effort to preserve the context that blocklists throw away: who used the address, how recently, for what kind of traffic, and during which customer action.

You can run a live proxy and VPN lookup, review the IP API documentation, or read the complete Synthient and Infoblox-backed research in Who Are the Victims of Residential Proxies?.

DEV Community: Benjamin Brundage