Provider verification

How to verify a proxy provider's claims

Start with unit pricing and a working curl line. Pool size, success rate, and uptime get checked against log rows and billed bytes — not homepage copy.

Trust and controls Updated 2026-06-12

Public pricing and a working connection come before anything else

A small test needs a cost ceiling. Find the per-GB or per-IP number on a public pricing page — no sales call required. Volume Residential at $0.89/GB and Premium Residential at $5.00/GB are what a checkable number looks like. No public rate means the test cannot be scoped.

Once price is settled, get a working connection: protocol, host, port, username, password. Test a neutral URL before the real target. A 407 here means the credentials or username format is wrong, not a blocked site. Fix that before reading anything else into the results.

On a gateway like http://proxynade.net:2555, the username carries routing: a base user, a plan token (volume, premium, or datacenter), an optional country code, and an optional rotation window in minutes. A 407 after copying an example means something in that string is wrong.

Log rows, not daily charts

A requests-per-day chart is useful for a manager. It cannot diagnose a failed run. Useful logs show host, HTTP status code, latency, provider-metered bytes, and the route or plan name per request — not just a time-bucketed total.

Proxynade's dashboard network logs expose host, outcome, latency, and byte totals per request. Usage logs export as CSV. That granularity lets you match a spike in billed bytes to a specific request path rather than guessing from a time range.

If a provider's logs only show aggregate stats, two things become invisible: whether failures cluster on one target or spread across routes, and whether retries are driving the bill.

Ten URLs catches obvious problems cheaply

Use real URLs from the workload. Ten is enough for the first pass. Hold everything constant — headers, timeout, retry rule, parser — and change only the provider. Record: HTTP status code, latency, country, ASN if available, provider-metered bytes, and which plan was used.

This is not a benchmark. It catches setup failures and policy blocks before they appear on a bill. If the provider cannot explain an odd row — a 403 on a public page, a status code that matches nothing in the docs — that gap is diagnostic information.

Observed resultWhat it likely meansNext check
407Credentials or username format wrongRe-read the connection string docs.
403Proxy connected; target refusedTry different headers or a different route.
429Rate limit at the targetSlow the request cadence.
TimeoutRoute stalled or target slowTest a lighter endpoint first.
Empty parseHTML arrived but structure changedProblem is the parser, not the proxy.

App rows versus provider-metered bytes

The app counter shows accepted rows. The proxy meter shows every byte that moved: retries, redirects, blocked HTML, image assets, partial transfers, and pages the parser discarded. Both numbers can be technically accurate. Only one appears on the invoice.

Put accepted rows next to provider-metered bytes before calling a per-GB rate cheap. A run that saves 480 rows at 2.3 GB billed looks different from one that saves the same rows at 0.4 GB billed. The row count tells you what you kept. The meter tells you what you paid for.

Pool size and success rate cannot be audited from outside

A homepage can print any pool size. There is no external audit trail. The checkable signal is exit diversity: run a sticky-session test and count unique exits. If the claimed scale is real, it shows up in the data.

Success rate has the same problem. A 99% figure only means something once the provider defines target mix, retry policy, which status codes count as success, sample size, and time window. A 200 on a challenge page is a successful proxy connection and a failed scrape at the same time.

Policy is soft until it blocks a real job. Check the acceptable-use page against the category you intend to run before starting a test. Proxynade's AUP is at /acceptable-use. If the category is excluded, no routing change fixes that.

What Proxynade publishes for this test

The observable surface: public unit pricing per GB, copyable connection examples with the full username-token format, supported protocols, session controls (country code and lifetime-minutes tokens in the username), dashboard network logs with per-request byte and status data, and CSV export for usage logs. That does not guarantee a specific target will succeed, but it provides enough to run the small test, read the actual bill, and decide what to change.

If a provider's homepage carries the entire weight of verification — no public pricing, no raw logs, no copyable connection string — the small test cannot happen. That is the gap worth checking before committing to scale.

Provider verification FAQ

What is the first thing to check when evaluating a proxy provider? Public unit pricing. A per-GB or per-IP number visible without a sales call sets a cost ceiling for a small test and confirms the provider accepts self-serve buyers.

How do you test a proxy provider before committing? Run ten real URLs from your workload through the gateway with consistent headers, timeout, and retry settings. Record status codes, latency, country, and provider-metered bytes for each request.

Why does the app row count differ from the proxy bill? The app counts accepted rows. The proxy meters every byte transferred — retries, redirects, blocked pages, image assets, and HTML the parser discarded. Both counters can be accurate, but only one becomes the bill.

How do you evaluate a pool size claim? Run a sticky-session test and count unique exits. A large pool number on a homepage cannot be audited from outside, but exit diversity over a real workload can be measured directly.

What should proxy dashboard logs include? Host, HTTP status code, latency, provider-metered bytes, and route or plan name. A daily chart is not enough for diagnosing failures.

Verification checklist

  • Unit pricing visible without a sales call.
  • Working connection string with a neutral URL test first.
  • 407 resolved before reading 403s as blocks.
  • Log rows show per-request status, latency, and bytes.
  • App rows compared to provider-metered bytes before scaling.
  • AUP checked against the intended use category.