Skip to main content
Infrawatch combines active service observations, network ownership, provider attribution, and classification signals to identify infrastructure associated with residential proxy and VPN services.

​
The best coverage on the market

A new generation in anonymisation network coverage. Proxy and VPN datasets answer one question: does this address belong to an anonymity service? That answer is a lookup against a catalogue of known networks, and the catalogue is the ceiling. Whatever nobody has listed is not merely unranked, it is absent. A catalogue covers a scattered minority of addresses while Infrawatch observes every one of them Infrawatch starts from the other end. We revisit the internet itself, then run two more collections and land all three on the same endpoint record:
  • Residential proxy collection - Exits observed first-party, rather than licensed from a reseller and passed along.
  • VPN collection - Commercial, hosted, corporate, and self-hosted endpoints, collected the same way.
  • Daily internet scanning - Every address revisited across more protocols than web-first search, with the full protocol evidence retained.
The third collection is what changes the answer, in two ways. It carries the evidence. An attribution arrives with the provider, the network, and the service the host was observed running, so you can see why an address was classified rather than trusting that it was. When a verdict is challenged, the evidence is already attached to it. It also reaches further, and this is where the coverage gap opens. A dataset assembled from provider directories is bounded by that directory. It knows the networks somebody has catalogued, and an endpoint belonging to no catalogued service is invisible to it, however active that endpoint is. Scanning does not work from a list. Every address is visited on its own merits, so a self-hosted VPN, a one-off exit, or infrastructure no reseller has ever advertised is observed like anything else. Those are the endpoints a catalogue structurally cannot hold, and they are the ones worth catching: an operator who does not want to be found does not register with a provider directory first.

​
What teams use it for

Knowing an address is a residential proxy exit rather than a home connection changes the decision on the other side of it.

Beat fraud

Step up or decline transactions arriving through proxy and VPN exits, where the stated location is not the real one.

Enforce KYC

Catch onboarding that hides its origin, and evidence the decision with the provider and service behind the address.

Stop account takeover

Spot logins and password resets coming from residential exits used to blend in with ordinary consumer traffic.

Enforce geography

Hold up licensing, sanctions, and regional restrictions against traffic that is deliberately misrepresenting where it is.
Residential proxy traffic is difficult precisely because it looks like a customer. It arrives from a consumer ISP, on a residential address, in the right country. The attribution is what separates it from the real thing.

​
What you can investigate

  • Observed endpoints - Start from an IP, ASN, provider, protocol, or port.
  • Service behavior - Inspect the protocol evidence behind an attribution.
  • Provider context - Connect an endpoint to the named service or network where attribution is available.
  • Infrastructure overlap - Compare addresses, ASNs, certificates, HTTP properties, and other shared evidence.
  • Change over time - Restrict results to recent observations or compare activity across time windows.

​
Start an investigation

Search for observed proxy protocols, then refine the result with network and time constraints:

Learn InfraQL

Combine service, attribution, tag, and time fields.

Browse service fields

Find protocol-specific and network-attribution fields.