The log sees traffic the app never counted
Your app counts kept rows. The proxy meter counts every transferred byte: redirect chains, challenge pages, failed TLS handshakes, font tiles, retries, and response bodies your parser discarded before writing a row. A worker can save one record and still move a lot of bytes before that record exists.
That gap is why the bill and the app count rarely match. It is not usually a counting error on either side — they are measuring different things.
The Proxynade dashboard network logs show host, outcome, latency, and byte totals per request. Usage logs export as CSV from the same view.
Start with host and bytes
Open the log and sort by bytes descending. If the biggest host is not the target you meant to fetch, stop there. A common pattern: the app reports 1,240 kept products so the job looks healthy, but the usage log shows most bandwidth went to a thumbnail CDN. The browser fetched every image tile while the scraper only kept text. The app looked cheap because it counted rows; the log shows the thumbnails, redirects, cache misses, and retries.
On the Proxynade pool at proxynade.net:2555, the log ties each row to a plan token (volume, premium, or datacenter) embedded in the username. Unexpected bytes on a premium line when volume was intended points to a misconfigured worker credential, not higher traffic.
Status codes mean less than they look like
A 407 is proxy auth: wrong username token, wrong password, or zero account balance. It never reaches the target. (MDN: 407 Proxy Authentication Required)
A 403 means the proxy connected and the target refused (MDN: 403 Forbidden). A 429 points toward pacing or concurrency limits at the target. A 200 only means a response body came back — it might be a login page, a soft block, an empty result set, or the wrong page with a clean status code.
| Status | What it means | Where to look |
|---|---|---|
407 | Credentials failed at the proxy gateway | Username token, password, account balance |
403 | Proxy connected; target refused | Headers, session age, target policy |
429 | Target rate-limiting | Concurrency, pacing, retry interval |
200 | Body received — content unknown | Outcome column and app result |
The outcome and app result columns resolve the ambiguity. If status is 200 but app result says skipped, empty, or blocked, the proxy did its job. The question shifts to what body came back.
Protocol mistakes look the same as target blocks
One worker using HTTP while another uses SOCKS5. A credential line copied to the wrong plan. DNS resolved locally with SOCKS5 when the job expected proxy-side resolution via socks5h. These show up as failures that look like target refusals until you filter by protocol and compare workers.
Python requests and curl behave differently when curl runs with -L and silently follows a redirect chain. If the log shows bytes moving to an unexpected host, the redirect chain from a different client is often the explanation.
High latency creates repeat spend
A worker that times out marks the item unfinished and retries the same URL. The app may show no extra kept records. The proxy log shows the repeated requests against the same host with the same byte cost each time.
Latency in the log is the time from the gateway receiving the request to the last byte of the response. A spike that correlates with a single target host is a target-side issue. A spike that correlates with a single worker credential points to a routing or plan problem on that line.
Reduce spend without upgrading the plan
Most bandwidth waste comes from fetching content the job does not need. Block images if images are not needed. Avoid full browser pages when a narrow API endpoint or feed covers the same data. Cut blind retries — a stable 403 or soft block will not change on the fifth attempt.
Split a slow target into its own worker pool so its latency and retry behavior does not inflate metrics for everything else. When one worker is noisy, compare its plan token, protocol setting, timeout value, retry count, and app result before treating the issue as a total-bandwidth problem.
Volume Residential costs $0.89/GB and Premium Residential $5.00/GB, billed per transferred byte. Reducing wasted bytes on a premium plan matters more than on volume — the same thumbnail CDN leak costs more than five times as much.
Usage log FAQ
Why does the proxy log show more bytes than my app counted? The proxy meter counts all transferred bytes: redirects, blocked pages, assets, retries, and discarded response bodies. Your app typically counts only the rows it kept.
What does a 407 mean in a proxy usage log? 407 Proxy Authentication Required means credentials failed at the gateway — check the username token, password, and account balance.
What does a 200 outcome mean in the proxy log? A 200 means a response body came back. It may still be a soft block, login redirect, or empty result — the app outcome column tells you whether that body was useful.
How do I export Proxynade usage logs? The Proxynade dashboard network logs show host, outcome, latency, and byte totals. Usage logs can be exported as CSV from the dashboard.
Why does high latency increase bandwidth spend? A worker that times out marks the item unfinished and retries the same URL. Each retry moves bytes. The app may show no extra kept rows, but the proxy log shows the repeated traffic.
Log triage order
- Sort by bytes descending. Identify the top host.
- Check whether that host was intentional.
- Filter by status. Separate 407s (proxy auth) from 403s (target refusal).
- Compare outcome and app result on any 200 row that looks suspicious.
- Filter by protocol to catch misconfigured workers.
- Check latency spikes against worker credential and target host.
- Export as CSV and join against app logs when the discrepancy is large.