A proxy or VPN review should identify the exact product being evaluated. A provider name alone is not a test condition. Residential, ISP or static residential, datacenter, mobile, shared VPN, dedicated IP, browser extension, and enterprise gateway products can behave differently even when sold by the same company.
Define the product
- Provider and product name.
- Proxy or VPN network type.
- Shared, dedicated, rotating, sticky, static, or session behavior.
- Authentication method.
- Protocol support.
- Geographic selection model.
- Billing unit and minimum commitment.
- Traffic, endpoint, connection, or seat limits.
- Checked date.
Do not combine different products into one performance or price conclusion merely because the provider brand is the same.
Separate provider claims from observations
Provider material is the correct source for what the provider currently sells or claims. It is not independent proof of performance, pool size, anonymity, legal compliance, or no-logging behavior.
| Claim type | Preferred evidence |
|---|---|
| Current list price | Official pricing or checkout page, dated |
| Supported protocol | Official technical documentation plus endpoint test when available |
| Server or location count | Official current claim, attributed |
| Success rate | Documented independent or Aerod-observed sample |
| Latency and throughput | Controlled measurement with baseline and environment |
| Privacy or logging policy | Current policy text, audit, legal evidence, and stated limits |
| Support quality | Dated support interaction or documented process |
Normalize pricing before comparison
- Currency.
- Monthly, annual, pay-as-you-go, or prepaid billing.
- Minimum spend.
- Included traffic.
- Per-GB, per-IP, per-endpoint, per-port, per-user, or flat-rate pricing.
- Renewal price after an introductory discount.
- Overage and unused-balance rules.
- Refund and trial conditions.
A low advertised starting price can describe a long commitment or small allowance. It should not be compared directly with a flexible monthly plan without explaining the difference.
Define the task
- General privacy browsing.
- Browser and app route verification.
- Allowed public-web data collection.
- Account or ad verification.
- Long-lived static sessions.
- High-volume datacenter traffic.
- Remote access.
- Streaming or region access where lawful and permitted.
A provider can be strong for one task and unsuitable for another. The conclusion should identify the workload rather than assign an unexplained universal rank.
Establish the direct baseline
For network performance, record the direct connection before testing the provider: IPv4 and IPv6 state, latency to the target, download and upload capacity when relevant, packet loss or failure, test location and network, and time window.
The provider result should be compared with this baseline rather than an unrelated published internet speed.
Test comparable routes
- Target service.
- Protocol.
- Route type.
- Country or region.
- Session duration.
- Concurrency.
- Request count.
- Timeout.
- Retry rule.
- Browser, app, or test client.
If one provider offers only a different route type, explain the difference instead of hiding it.
Measure success separately from speed
- Connection success rate.
- Target success rate.
- Median latency.
- Tail latency.
- Throughput.
- Session stability.
- Rotation or stickiness accuracy.
- Country or region match.
- ASN and organization consistency.
- Error categories.
Results should report the sample size and conditions. A single successful request cannot support a broad reliability claim.
Verify the visible route
- Public IPv4 and IPv6.
- ASN and organization.
- Approximate location.
- WebRTC candidates for browser workflows.
- Browser-state and fingerprint consistency.
- Expected DNS path when a controlled test is available.
A provider endpoint can work while one application remains direct. Route verification must be performed from the application under test.
Review security, privacy, and policy
- Encryption and protocol choices.
- Authentication and credential handling.
- Logging and retention language.
- Ownership and jurisdiction where material.
- Independent audits and their scope.
- Abuse handling.
- Residential or mobile sourcing disclosures.
- Account security.
- Incident history.
- Terms that restrict the intended task.
A policy statement should be attributed. An audit should be described by date and scope rather than reduced to “audited.”
Evaluate usability and support
- Dashboard clarity.
- Endpoint generation.
- Documentation.
- Authentication setup.
- Rotation and session controls.
- Usage reporting.
- Error messages.
- Cancellation and refund process.
- Support response and technical competence.
A support assessment should identify the date and scenario. One interaction is a sample, not a permanent provider characteristic.
Handle unavailable testing honestly
- Do not imply that a product was tested when it was not.
- Use official and independent evidence with attribution.
- State which values are provider claims.
- State which values are unavailable.
- Avoid invented benchmark numbers.
- Prioritize the page for a future controlled retest.
Affiliate and commercial separation
Affiliate relationships are disclosed. They do not change the inclusion criteria, test environment, meaning of a failure, source hierarchy, correction process, or conclusion.
A provider without a commercial link can still be the stronger recommendation. A provider with a commercial link can receive a limited or negative conclusion.
Update and correction triggers
A provider page should be reviewed after pricing or plan changes, product renaming or retirement, network-type changes, ownership changes, policy changes, material incidents, new audit evidence, repeated performance changes, or a supported correction request.
Weighting and conclusions
Aerod should not publish an unexplained overall score. When a comparison uses categories or weights, the page should identify them and explain why they fit the intended task. A general privacy-browsing comparison can weigh policy and route consistency differently from a high-volume data-collection comparison, where success rate, cost, rotation behavior, and concurrency may dominate.
A category score should be traceable to evidence. Missing data should be marked unavailable or untested rather than silently assigned an average value. A provider should not gain points merely because its marketing page supplies more claims, and it should not lose points for declining to publish a value that competitors also cannot substantiate.
Regional and temporal variation
Proxy and VPN networks can vary by country, city, ASN, server, time of day, and target. A successful endpoint in one region does not prove equivalent performance elsewhere. Comparisons should avoid extending a regional sample into a worldwide conclusion unless the sample actually covers the claimed scope.
Time also matters. Congestion, routing, target defenses, and provider maintenance can change a result. Material performance claims should use more than one run and should state the test window. A page that cannot be retested should retain its historical date and avoid presenting the sample as current universal performance.
Legal and acceptable-use boundaries
A technical capability is not permission to use it. Provider reviews should consider applicable terms, target rules, authorization, rate limits, privacy obligations, and local law. Aerod does not evaluate a provider by how effectively it enables account abuse, unauthorized access, evasion of security controls, or other prohibited conduct.
When a workload is legally or contractually sensitive, the page should describe the legitimate use case and advise readers to confirm authorization. A provider’s willingness to sell access is not proof that every intended use is allowed.
Provider evidence record
Each public provider page appears in the Evidence Register with its current review date, source count, disclosure state, and migration status. The record is an audit aid; the article remains the complete explanation.
FAQ
Does Aerod buy or receive every provider plan it reviews?
Not necessarily. A provider page must distinguish official plan information, available independent evidence, and Aerod-observed testing. It must not imply hands-on testing that did not occur.
How are proxy and VPN providers compared fairly?
The comparison defines a common task, route type, target, region, protocol, sample, billing basis, and limitation before comparing results or prices.
Are performance results universal?
No. Performance is specific to the tested plan, endpoint, target, time, network, concurrency, protocol, and workload. Results should be treated as samples.
How are affiliate providers handled?
Affiliate relationships are disclosed. They do not control inclusion, methodology, test interpretation, corrections, or the final conclusion.
When is a provider page updated?
A page should be reviewed after material pricing, product, network, ownership, policy, protocol, or observed-performance changes and when a correction request provides stronger evidence.