Trust pages are read after something breaks
A scraper runs overnight. A login CDN eats part of the crawl. Retries pile up, and the app reports a clean job because it only counted the rows it kept. The provider dashboard shows more traffic. That mismatch is not rare, and it is not automatically fraud. It is exactly where the trust page has to stop sounding reassuring and start matching evidence.
Start with one route before scaling. If the result is bad, scaling only hides which part failed and makes the provider meter harder to explain.
Your app counter and the provider meter measure different things
Application-level counters report what your code kept: saved rows, parsed bodies, successful responses after retries. The proxy meter counts every byte that crossed the provider edge: redirects, failed TLS attempts, block pages, retries, and duplicate requests all appear in the total.
That gap is structural, not suspicious. But if a provider cannot show host-level usage after a run with high retry rates, the buyer is left arguing from a local console printout. The trust page should explain what the logs contain so buyers know what to compare.
Logs are the only verifiable trust signal
A trust page that names specific log fields is more useful than one that lists compliance certifications. The fields that matter for debugging are: host, plan, protocol, outcome code, latency, and provider-metered bytes. With those six fields, a buyer can tell whether a failure was proxy authentication (407), target refusal (403), rate limiting (429), or plain bandwidth burn.
Proxynade's network logs show host, outcome, latency, and byte totals per request. Usage logs export as CSV. Apply the same test to any provider: ask what fields customers can actually inspect, not what the privacy paragraph says the provider retains.
| Log field | What it distinguishes |
|---|---|
| Outcome code | Separates 407 (proxy auth) from 403 (target block) from 429 (rate limit) |
| Latency per request | Identifies slow routes vs. target timeouts |
| Provider-metered bytes by host | Shows which hosts drove bandwidth cost |
| Plan label | Confirms routing token matched the intended pool |
A green status badge proves nothing
A status page with only a green badge tells you the provider wants the page to look calm right now. A useful status history has incident entries with a start time, the affected system, and a resolution time. That gives you something to compare against your own run window: if your job had elevated 407s on Tuesday evening, you can check whether the provider logged an authentication issue in that window.
Gaps in incident history are not evidence of reliability. They are evidence of either a reliable network or an incomplete record. Short of a paid test, you cannot tell which.
Sourcing language should name the network type
A trust page that cites a large pool number without explaining how those IPs were sourced is a gap. The minimum useful description names the network type (residential, datacenter, static ISP), explains the mechanism (carrier agreements, user-consent programs, owned infrastructure), and states what use cases are prohibited.
Proxynade's /trust page and AUP follow that structure: the network type is stated, prohibited uses are listed, and no pool sizes or success rates are claimed that cannot be verified. A provider that claims specific pool sizes or carrier names should be able to point to where those numbers come from.
Read the trust page against the rest of the product
The dashboard, /status, docs, pricing, and support answers should all describe the same service. Inconsistencies are worth noting before you commit traffic.
| Check | What a gap looks like |
|---|---|
| Pricing page vs. billing line items | Per-GB rate on the page does not match the rate applied at billing |
| Docs vs. connection string format | Docs describe a token scheme the panel does not actually generate |
| Trust page vs. log fields | Trust page claims minimal logging, but support cannot name what customers can inspect |
| Status history vs. your run window | Your job had errors in a window with no incident record |
When docs are thin and logs are absent, stop treating the trust page as evidence. Run a small paid test first, or hold production traffic until you can verify the claims yourself.
Trust page FAQ
What should a proxy trust page actually prove? It should point to specific log fields customers can inspect, explain how residential IPs are sourced, and link to a status history with incident times — not just affirm that the provider cares about trust.
Why does the provider meter show more traffic than my app? Your app typically counts saved rows or successful responses. The provider meter counts every byte that crosses its edge: redirects, block pages, failed attempts, and retries all appear in the total.
What makes a status page useful rather than decorative? Incident entries with start time, affected system, and resolution time. A green badge only tells you the provider wants the page to look calm.
What sourcing language signals an honest trust page? The page names the network type (residential, datacenter, static ISP), explains how access is obtained, and states which use cases are prohibited. Vague references to a large pool without sourcing detail are a gap.
How should I test trust claims before running production traffic? Run a small paid test. Compare the provider's network log — host, outcome, latency, bytes — against your own output. If those two records do not match up, resolve the gap before scaling.
Pre-commit checklist
- Trust page names specific log fields customers can inspect.
- Status history has incident entries with times, not just a badge.
- Sourcing explanation names the network type and mechanism.
- Prohibited use cases are listed and match the AUP.
- Run a small paid test; compare provider logs against your output.