--- title: "Residential proxy detection: signals and false alarms" description: "Evaluate residential proxy detection across shared or mobile networks. Keep labels, precision and false-positive denominators clear before limiting access." status: published author: Michael Delgado datePublished: 2026-10-21 dateModified: 2026-10-21 --- # Residential proxy detection: signals and false alarms *By Michael Delgado · Published 2026-10-21 · Last updated October 21, 2026.* Residential proxy detection evaluates whether traffic is being relayed through a connection associated with a residential network. Network type alone does not establish that a request is a proxy, and a proxy label does not establish a fraudulent customer. Assess category evidence and the application response separately, including shared networks and legitimate privacy use. ## Keep address ownership and request behavior distinct A residential or mobile network label describes one aspect of the connection context. It does not identify the person operating a browser or explain why traffic arrived through that route. Ask how the provider distinguishes network classification from evidence of proxy use. The result also depends on input quality. Confirm the client address at the trusted reverse-proxy boundary, including the relevant IP family. The [proxy API guide](/blog/proxy-detection-api/) covers that integration detail. Avoid using an unexplained network label as a permanent customer identity. An account can change connections, and a shared address can represent more than one legitimate user. ## Define the reference cases for a vendor test | Case | What needs review | Why it matters | | --- | --- | --- | | Verified relay use | How the category was established | Provides a meaningful test reference | | Ordinary residential access | Current connection context | Helps identify mistaken proxy labels | | Shared or mobile access | Network sharing and IP changes | Avoids treating a group as one customer | | Legitimate privacy service | Documented service context | Separates masking from abusive intent | | Unknown result | Available evidence and uncertainty | Prevents forced or misleading labels | Retain the time of observation. A later result about an address may not explain an earlier event under the same conditions. If the reference is uncertain, preserve that status rather than assigning convenient ground truth. ## Measure the specific false positive First define whether the test concerns a mistaken proxy classification or a mistaken business restriction. Those are different outcomes. A correct proxy label can still lead to an incorrect account decision. For classification, the false-positive rate uses false positives divided by all reviewed legitimate negatives in the defined test. Precision asks a different question: how many positive labels were correct. Keep the denominator visible. As an illustrative calculation, 20 mistaken positive labels among 1,000 verified negative cases gives a false-positive rate of 2 percent for that test. It says nothing by itself about a different region, time window or business action. The [general metrics guide](/blog/reduce-fraud-false-positives/) explains the full confusion matrix. ## Use account context before applying friction An established account with normal activity can have a different risk profile from a new cluster repeatedly claiming benefits, even if both use the same network category. Evaluate the protected action and available business evidence. For a hypothetical SaaS company, several employees signing up from a shared connection may be expected. The relevant question is whether each account is authorized and eligible for a benefit. A blanket connection rule can interfere with the team the product is meant to serve. The [signup guide](/blog/fake-account-prevention/) and [account takeover signals guide](/blog/account-takeover-signals/) explain those different decision contexts. ## Treat privacy relays and location as separate fields [Apple documents Private Relay](https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/) as a network environment websites should handle. Do not assume that every unfamiliar relay reflects an abuse service or that its apparent location identifies a customer precisely. Keep location confidence, network category and account action separate. The [location-spoofing article](/blog/location-spoofing-detection/) explains why a location mismatch needs time and accuracy context before it drives a travel-related policy. Request the vendor’s field definitions and handling of missing data. A single score should not conceal which observation produced the result. ## Compare providers on the same workload Use the same reviewed cases, client input and observation window. Record latency, unavailable results, category disagreements and operating effort. Do not compare two advertised accuracy percentages that use different definitions or test populations. Then test the response in observation mode. Track legitimate completion, reviews and corrections alongside suspected abuse. A provider’s value depends on both the evidence it contributes and how the business uses that evidence. Choose a narrow rollout and an owner for corrections. Keep the original event reference so that support and risk operations can revisit the same decision rather than a later lookup that may have changed. ## FAQ ### Does a residential IP prove the request is legitimate? No. It describes network context, not the complete account or action history. ### Does every proxy label justify blocking a login? No. Evaluate the account, authentication and requested action with the reason for the network assessment. ### What is a good false-positive rate for residential proxy detection? There is no universal target here. State the reference population, label definition, denominator and customer impact before comparing results. ## Sources - [MaxMind: anonymizer and proxy data](https://support.maxmind.com/knowledge-base/articles/anonymizer-and-proxy-data-maxmind). - [Apple: Private Relay network guidance](https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/). - [Cloudflare: client IP headers](https://developers.cloudflare.com/fundamentals/reference/http-headers/).