How Proxy Bandwidth Is Measured

Last modified: 22 August 2026

This page sets out exactly what counts as billable traffic on a PRIVATEBYTE proxy account. It forms part of our Terms of Service. Where this page and the Terms of Service conflict, this page prevails for questions of bandwidth measurement.

We publish this because most proxy providers do not. Whether connection overhead is billed, and how much of it, is usually left unstated, which makes per-GB prices hard to compare honestly. Our figures are below.

1. What you are billed for

Two things, both measured per request:

1. The data relayed through the connection. Everything that passes between you and the destination, in both directions. This includes HTTP headers, TLS handshake records, and the response body, because all of it travels through the tunnel.
2. A fixed 672 bytes for opening the connection. Establishing an upstream connection consumes bandwidth before any of your data moves. That cost is real whether the request that follows carries 4 bytes or 4 megabytes.

Both are charged at your tier's per-GB rate. There is no separate per-request fee, no minimum spend per request, and no rounding up.

2. Why connection overhead is counted

Counting only relayed data would mean a request that opens a connection and transfers almost nothing is served free, while the bandwidth it consumed is real. Counting overhead as bandwidth is standard across the residential proxy industry; published figures elsewhere range from 5 KB to 30 KB per request. Ours is 672 bytes, and it covers only what sits outside the tunnel.

We are specific about the number so you can model your costs before you commit, and check them afterwards.

3. What this means in practice

The 672 bytes is a constant, so its share of your bill falls as the amount of data per request rises:

Average request size     Connection overhead as a share of your bill
500 KB                   0.13%
100 KB                   0.67%
40 KB                    1.7%
10 KB                    6.3%
5 KB                     13%
1 KB                     40%

For most workloads this is well under 1% of a monthly bill. It matters if you make very large numbers of very small requests.

4. Reducing it

Connection overhead is charged per connection, not per request. If your client reuses a connection across several requests, you pay it once rather than once each.

• Enable HTTP keep-alive in your client. Most HTTP libraries do this by default; many scraping frameworks disable it.
• Hold a session open rather than reconnecting for each call.
• Check for retry loops. A client that reconnects on every failure can open many times more connections than it makes successful requests.

Reusing connections also reduces latency, because you are not paying for connection setup on every call.

5. Tiers and rates

Overhead is billed at the same per-GB rate as the rest of your traffic, which is the rate for the tier the request used. If you specify a tier per request, each request's overhead is billed at that request's tier.

Current per-GB rates are shown on the pricing page and in your portal.

6. What is not billed

• Requests we reject before they reach an upstream, including authentication failures and requests refused for insufficient balance.
• Connections that are established but relay no data at all. These consume bandwidth on our side; we do not pass them on to you.
• Our own internal health checks and monitoring.

7. Checking your usage

Your portal shows bandwidth used, request counts and remaining balance, updated continuously. If the figures do not match your own measurements, tell us and we will reconcile them with you rather than ask you to take ours on trust.

Questions about anything on this page: [email protected].