Which Squid Byte Counter Should a Traffic Quota Use?
Decide whether a proxy quota measures replies, requests, upstream bodies, or access-link traffic before summing Squid log fields.
“Give each user ten gigabytes” sounds precise until two reports disagree. One summed replies sent to clients; another counted bytes fetched upstream. Both may be reporting their chosen field correctly.
Squid's log format has distinct counters:
| Field | Documented measurement |
|---|---|
%<st | Total reply traffic sent to the client, after adaptation |
%>st | Total request size received from the client, excluding chunked-encoding bytes |
%<bs | HTTP-equivalent message-body bytes received from the next hop, with documented exclusions |
The native Squid log's bytes column uses the client-reply counter. It is not a promise that the value equals the saved file's length, nor a measurement of every Ethernet or IP byte charged by an ISP.
Cache hits illustrate the difference: Squid can send a reply without making a fresh upstream fetch. Upload-heavy work illustrates another: counting replies alone leaves the request direction out of the budget.
For CONNECT, the proxy can account for relayed traffic without understanding each encrypted file or page inside the tunnel. It cannot turn a tunnel's byte total into an exact inventory of downloaded application objects.
Write the quota contract next to the counter: direction, observation point, accounting period, and identity. Then retain the log-format version with the reports. A disagreement over what a byte means should not be “fixed” by multiplying every value by a guessed correction factor. For enforcement, completed transaction totals can lag live usage.