How to test residential proxy detection APIs fairly

Test a residential proxy detection API with independently labeled, permitted sessions and legitimate controls. Repeat comparable routes, record timestamps and separate missing results from completed classifications. Report proxy recall and false positives with their denominators; a few public checker results cannot establish production accuracy.

A consumer ISP address can carry ordinary household traffic or relay traffic. That makes an address’s ownership an inadequate ground-truth label. Your test needs to establish what the route was doing when the check ran.

Define the decision and the label first

Choose a protected action, such as a signup or benefit claim. Define the positive label independently: an authorized session intentionally sent through a known residential proxy route. Define legitimate controls through permitted normal usage rather than through a detector returning “clean.”

Do not use one provider’s proxy flag as truth when scoring another. That measures agreement between services and can reproduce a shared blind spot. Ground truth should come from the route setup and controlled conditions, with its own timestamp.

Keep two labels where necessary: connection masking and confirmed application abuse. A proxy can be present on a legitimate action. A detector that identifies the connection has not automatically established that the account should be restricted.

Build cohorts that expose useful differences

Use accounts and traffic you are allowed to test. Record whether a route changed during the session. A test that begins on one exit and completes on another needs an explicit label; silently assigning the first address can distort results.

The methodology includes coverage, freshness and false-positive discipline as separate categories. Keep that separation in the pilot spreadsheet.

Send comparable inputs to each product

For an IP lookup, query the observed exit at the relevant time. For a browser-assisted product, install its supported collection in the same action flow. Do not give one candidate session evidence and then describe another candidate’s IP-only result as an identical-input test.

You can compare products on the same business task while preserving these interface differences. Record the input each actually received, collection completion and when the backend had a usable result. That makes the comparison reproducible.

ShieldLabs adds current device/network context and account-abuse detection to the observed visit. Spur, IPinfo and other IP intelligence products expose their own network observations and attribution. Evaluate the specific product rather than grouping every service as a static list.

Calculate metrics with explicit denominators

Proxy recall is the number of known proxy sessions correctly classified divided by the number of known proxy sessions assessed. False-positive rate is the number of legitimate negative controls incorrectly classified divided by the number of legitimate negative controls assessed.

For an illustrative result, suppose a test contains 200 known proxy sessions and 400 legitimate non-proxy controls. If 170 proxies are identified and 8 controls are incorrectly flagged, proxy recall is 85 percent and the false-positive rate is 2 percent. These are sample calculations, not measured vendor results.

A legitimate customer using an actual corporate VPN is a separate policy case: the connection may be correctly classified as a VPN while restricting the customer is still the wrong application decision. Measure classification quality and customer outcome independently.

Precision depends on the composition of the evaluated population. Record the positive base rate and avoid transferring a precision figure from a proxy-heavy laboratory sample to ordinary signups without examining that difference.

Count unavailable and late results

A failed lookup should not improve the reported false-positive rate by disappearing from the spreadsheet. Count missing, invalid and late responses explicitly. Publish the number of completed assessments alongside the number attempted.

For browser collection, record whether the script ran and whether the result reached the backend before the action deadline. For IP APIs, record authentication, quota and transport failures. Keep operational availability separate from detection correctness.

Use the Python adapter guide and JavaScript integration guide to design these result states before the first comparison.

Repeat after rotation and reassignment

Run a later check on the same permitted routes and observed exits. Record what changed: route, address, time, provider, confidence, last-seen field or classification. A changed result can reflect a real route change, a data refresh or a previous error; investigate before assigning a cause.

Cache behavior can conceal freshness differences. Record whether the response came from your own cache, a local database edition or a new provider request. The latency and caching guide gives a suitable record structure.

Finish with an action-specific decision: which result, deadline and legitimate-user impact fit the deployment? Preserve the sample definition and enough records to repeat the test. That is more useful than naming an “accuracy winner” without its traffic mix.

FAQ

Sources

• MaxMind Anonymous Plus, anonymizer confidence and legitimate shared infrastructure.
• IPinfo residential-proxy context, observed activity and recency.
• Spur documentation, separate API and session evidence.
• ShieldLabs Network Intelligence, live device/network corroboration.