Per-request logs, not daily totals
The first thing to check is not a chart. Pick one failed request from your app and try to find the matching row in the usage logs. If the dashboard can only show a daily aggregate, it is already hiding the part that matters.
A usable log row contains: timestamp, plan, protocol, host, outcome, status code, latency, provider byte count, app byte count, and session mode. Without all of those, every diagnosis turns into memory work.
time_utc,plan,protocol,host,outcome,status,latency_ms,provider_bytes,app_bytes,session_type
2025-11-18T13:41:18Z,Premium Residential,https,api.example.test,blocked_by_target,403,812,184320,172900,sticky
2025-11-18T13:42:03Z,Volume Residential,socks5,cdn.example.test,auth_failed,407,91,0,0,rotating
2025-11-18T13:43:27Z,Datacenter,http,example.test,rate_limited,429,344,32768,28110,hardA 407 is not a 403. A 429 is different again. Rolling them into one failure bucket protects the provider's graph at the expense of the person debugging the traffic.
Provider bytes must sit next to app bytes
App dashboards undercount bandwidth. They typically count saved rows, parsed bodies, or completed jobs. The proxy path still sees redirects, retries, headers, block pages, and partial transfers. On Volume Residential ($0.89/GB) or Premium Residential ($5.00/GB) billing, that discarded traffic is still charged per transferred byte.
If the dashboard shows only one byte column, assume it is the app-side number. The gap between that and the provider invoice is where surprise charges come from.
Proxynade network logs show host, outcome, latency, and byte totals per request, and usage logs export as CSV. The CSV export is the one to keep open during a billing audit.
Connection generation belongs in the UI, not in support chat
The dashboard should let you generate HTTP, HTTPS, or SOCKS5 lines and show which plan each line points at: Volume Residential, Premium Residential, Datacenter, or Static ISP. If you have to ask support which pool a pasted line lands on, the labeling is broken.
The failure mode is quiet. A misrouted line lands on the wrong plan, throws a clean 403, and the usage export is the only place you can see the run was never on the pool you intended. That is not a proxy mystery. That is a labeling problem.
On Proxynade the routing options are encoded directly in the username: base user + plan token (volume, premium, or datacenter) + optional country-<cc> + optional lifetime-<minutes> rotation window. Datacenter lines skip the lifetime token. The dashboard generates the full string, so there is nothing to guess.
Session mode must be logged, not just configured
Rotating, sticky, and hard sessions are not cosmetic labels. They change how a run behaves. If the dashboard lets you choose a session mode at setup but never records it in the logs, later debugging requires reconstructing intent from memory.
The session type column in the log is what tells you whether a stuck session was actually configured sticky, or whether it rotated under you and the app never noticed.
Balance split by plan, not as a single wallet
A single wallet number works for accounting. It does not explain why spend moved. A bad retry rule on Volume Residential is a different problem from a Static ISP workflow or a Datacenter test hitting 429s. The dashboard should show per-plan spend so you can match the number to the code that generated it.
Static ISP proxies are pay-per-IP with unlimited bandwidth, so the cost profile looks nothing like per-GB plans. Mixing them into one balance display makes both harder to read.
Domain blocking still needs a log row
Browsers pull telemetry hosts, image CDNs, update checks, and tracking pixels that were never part of the job. Blocking those domains at the proxy level saves bandwidth on per-GB plans. The block should still produce a log row. Traffic that disappears without a record is not an audit trail.
Proxy dashboard FAQ
Why do provider-metered bytes differ from app bytes? The proxy path counts redirects, retries, block pages, and partial transfers that the app never surfaces. On per-GB billing, that gap is real spend.
What is the minimum a usage log row needs to show? Host, outcome, status code, latency, plan, and provider byte count. Without all six you cannot tell whether a failure came from the proxy or the target.
Why keep 407, 403, and 429 separate in logs? A 407 is a proxy credential failure. A 403 is a target refusal. A 429 is rate limiting. Rolling them into one failure bucket hides which layer failed.
What does session mode visibility mean in a dashboard? The dashboard should record which session mode — rotating, sticky, or hard — each request used. Without that, debugging a stuck session requires guessing.
Why does plan labeling matter on connection lines? A misrouted line lands on the wrong plan, throws a clean 403, and the usage export is the only place you can see it was never on the expected pool.
Does blocking domains save bandwidth? Yes. Telemetry hosts, image CDNs, and tracking pixels that were never part of the job still count toward bandwidth on per-GB plans. Each blocked domain should still produce a log row.
Dashboard checklist
- Per-request log rows, not only daily totals.
407,403, and429in separate outcome fields.- Provider byte count next to app byte count.
- Plan label visible on every generated connection line.
- Session mode recorded in the log, not only at config time.
- Per-plan balance split, not only a single wallet total.
- CSV export available for billing audits.
- Domain blocks logged, not silently dropped.