Proxy detection false positives: CGNAT, corporate egress and Private Relay

Explore checkers, demos and evaluation routes →

A proxy false positive occurs when a legitimate connection is incorrectly classified or when a correct network label triggers an unjustified restriction. Measure both. Correctly identifying a corporate gateway or privacy relay can still produce a bad product outcome if the application treats every masked connection as abuse.

Build independent case labels

Create known legitimate cases before looking at vendor results: home broadband, mobile carrier NAT, office egress, managed corporate security gateways, hotels, universities and Apple Private Relay. Add authorized proxy, VPN, Tor and direct-control sessions. Keep unresolved real-world cases out of the ground-truth set.

The label needs two parts: the network condition and whether the protected action was legitimate. A legitimate user can use a VPN. An abusive account can use a direct residential connection. Conflating those labels makes accuracy numbers impossible to interpret.

Inspect reasons, not just booleans

Record the returned type, confidence, provider, recency and named signals. Ask whether a datacenter label caused the proxy verdict, whether a corporate gateway has its own field and how a missing result is represented. Preserve the raw evidence available for support and investigation.

ShieldLabs classifies risk for visitors, users, devices and IP as Trusted, Suspicious or Dangerous and returns a 0–100 risk score with current device/network context. A privacy or masking signal can contribute evidence without being the entire conclusion. That design supports a more proportionate response than an undifferentiated IP blocklist.

Measure product impact

Report at least four outcomes: incorrect network classification, legitimate action restricted, controlled abuse missed and result unavailable. Include the denominator for every rate. A support appeal is evidence to investigate, not automatic proof that the original classification was wrong.

Response ladder

Use the least disruptive control that fits the evidence and action: observe, request additional verification, limit a benefit, send to review or deny a high-risk operation. Preserve a correction path. Re-test after provider, browser, CDN or authentication changes.

Classification error and customer harm are different measurements

A privacy-relay user can be correctly labeled as using a relay and still be wrongly denied a legitimate purchase. Report both classification quality and the effect of the application's response. This avoids congratulating a detector for correct labels while missing the support cost of an over-broad policy.

Worked example with explicit denominators

Imagine a synthetic evaluation with 1,000 known direct sessions and 100 authorized proxy sessions. If ten direct sessions receive an incorrect proxy label, the classification false-positive rate is 1 percent. If 90 of the proxy sessions are detected, recall is 90 percent. Now add 50 legitimate relay users who are correctly labeled as relays but denied checkout: the relay label may be correct, yet the business has restricted 50 legitimate actions.

These are illustrative numbers, not results from this site's ranking. The lesson is to keep the known connection type, whether the action was legitimate, the detector output and the application response as separate columns. Report sample size and unknown results, then repeat the comparison by network type and region.

A review path for shared networks

Apple describes Private Relay as a privacy service with separate relays, not as evidence of fraud. Corporate gateways, carrier NAT and hotels introduce other forms of sharing. Maintain controlled examples of each in the evaluation set and inspect whether the vendor offers specific fields, confidence, observation time or reasons.

When a known customer is restricted, preserve the result that triggered the response. Reviewers need the account action and its supporting evidence, not a fresh IP lookup performed days later. Integrate the result with a trusted event, then compare vendors in the review directory using the legitimate-network cases that matter for your application.

FAQ

Sources

• Apple Private Relay
• RFC 6598: carrier NAT shared address space
• IPQualityScore strictness and shared-network settings

Sources reviewed October 23, 2026.