Usage log analysis

Export proxy usage logs as CSV

Pull the right time window, read each column correctly, and reconcile proxy-side bytes against your app counter before filing a billing question.

Usage logs CSV export Updated 2026-06-12

Match the export window to the run

The dashboard usage logs export as CSV. Before clicking export, set the date filter to the exact window of the run you are reviewing. Comparing a full-month export against a single-job app counter produces a gap that looks like a billing error but is just scope mismatch.

Each row in the CSV covers one proxied request. The columns are: host (the target reached through the gateway), plan, protocol, outcome, HTTP status code, latency in milliseconds, and bytes transferred. Plan and protocol are the two most common sources of confusion when a run mixed Volume Residential and Premium Residential, or HTTP and SOCKS5 on the same credentials.

The host column is the target, not the gateway

Every request exits through proxynade.net:2555, but the host column records the target domain the gateway connected to on your behalf. A single page load can generate rows for the main domain, a CDN, an analytics endpoint, an ad domain, and a font host — all billed separately.

This is where most billing surprises live. A worker that fetches one URL per iteration can still hit six domains per page if the target loads third-party assets. Group by host first, sort by bytes descending, and the outlier is usually visible in the top five rows.

ColumnWhat it recordsCommon use
hostTarget domain reached through the gatewayDomain rollup, finding the heavy target
planProxy plan billed for this rowSeparate Volume from Premium before comparing cost
protocolHTTP, HTTPS, SOCKS5, or socks5hConfirm which protocol the client library used
outcomeProxy-level result (success, block, timeout, fail)Distinguish proxy failure from target error
statusHTTP status code from the targetIdentify block pages (403, 429) vs. content (200)
latencyRound-trip time in millisecondsFlag slow routes or geographic mismatches
bytesBytes transferred for this rowBilling reconciliation, finding heavy responses

App counters undercount by design

Application code typically counts saved rows, parsed bodies, finished screenshots, or some other application-level result. The proxy meter counts every byte that moved, including traffic the app discarded: redirect chains, block pages, failed TLS attempts, retry bodies, and target error pages that were downloaded and then thrown away.

A 403 block page at 12 KB still moves 12 KB through the proxy. A redirect chain through three hops before a 200 bills all three hops. If the app retried five times before succeeding, the proxy log shows six rows where the app shows one.

The gap between the two is not a discrepancy — it is what happened on the wire. The CSV makes it auditable.

Outcome differs from status

Outcome records the proxy-level result before the HTTP status code matters. A row can have outcome success and status 403: the proxy connected and the target responded, but the target refused the request. A row with outcome block may have no status at all — the proxy rejected the connection before a TCP handshake with the target completed.

When success rate looks low, check outcome first. Widespread proxy-side blocks or timeouts point at credentials, plan limits, or routing. Target-side 4xx with proxy-side success points at the site itself: headers, pacing, or session state.

socks5h rows appear when the client delegates DNS

If your client library uses socks5h://, hostname resolution happens at the proxy rather than at the client (RFC 1928). The protocol column in the CSV will show socks5h rather than socks5. This matters for billing reconciliation because the host the proxy resolved may differ from what the client asked for — a redirect or CNAME chain resolved at the proxy side will appear under the final hostname.

Switching from socks5 to socks5h or back in a client library is a one-character change that can shift which hostnames appear in the log. If the host distribution changes unexpectedly between runs, check whether the protocol column changed too.

Reading the CSV for a billing review

Filter the export to the job's time window. Split by plan before summing bytes — Volume Residential ($0.89/GB) and Premium Residential ($5.00/GB) bill at different rates, and mixing them in a total produces a wrong per-GB figure. Static ISP proxies are pay-per-IP with unlimited bandwidth, so their rows appear in the log but do not add to the GB total.

Group by host and sort by bytes descending. If one domain accounts for more than half the bytes, open those rows and check the status column. High bytes with status 200 means the target is heavy. High bytes with status 403 or 429 means the run was fetching block pages at scale and billing for them.

When filing a support question, send the filtered CSV with the app-side number you are comparing it against. A full-month export compared against a one-hour run is not useful to either side.

Usage log CSV FAQ

What columns does the Proxynade usage CSV contain? Each row includes host, plan, protocol, outcome, HTTP status code, latency in milliseconds, and bytes transferred.

Why is the proxy byte count higher than my app counter? The proxy meter counts every transferred byte: redirect chains, block pages, failed attempts, and retry bodies. Application counters typically count only saved or parsed results.

How do I find which domain is consuming the most bandwidth? Group the CSV by the host column and sort by bytes descending. The top domain accounts for most of the variance in nearly every run.

Should I export the full month or filter to the run window? Filter to the exact time window of the run you are reviewing. Comparing a full-month export against a single-job app counter introduces noise and makes discrepancies look larger than they are.

What does the outcome column mean? Outcome records the proxy-level result: whether the connection succeeded, was blocked, timed out, or failed before reaching the target. It is independent of the HTTP status code returned by the target site.

Reconciliation checklist

  • Export covers the exact run window, not the full billing period.
  • Bytes are split by plan before comparing rates.
  • Host rollup done before reading individual rows.
  • Outcome column checked before blaming the target.
  • App counter and CSV window match before filing a dispute.