You are launching a parser or warming up accounts through a proxy, estimating consumption based on page size — and you receive a bill 2-3 times higher than expected. It's not a scam by the provider: traffic includes everything that actually passed through the channel — request headers, TLS handshake, connection retries, and control packets. Let's analyze what constitutes the "check" for traffic and how to reduce consumption without losing quality of work.
What the provider actually counts as traffic
When you estimate consumption "by eye," the formula in your head usually consists of: the size of the HTML page plus images. But the proxy provider counts the total volume of data that has passed through both directions of the channel — outgoing (request) and incoming (response). This volume includes not only the payload but also all control traffic: protocol headers, TLS metadata, TCP ACK packets, and connection retries during timeouts.
For a single request to a regular page, the ratio of "useful data" to "control" can be 80/20. But if you are working with an API where responses are small (a couple of kilobytes of JSON) and there are many headers and handshakes, the ratio can easily flip the other way. This is why arbitrageurs who send tens of thousands of small requests to advertising APIs or marketplaces are often surprised by the bill: each request carries a fixed "tax" regardless of the size of the payload.
Another important point: the provider counts traffic at the proxy server level, meaning all traffic that has actually passed through the IP — including failed attempts, redirects, and reloading resources on the page (styles, scripts, trackers) that your script or browser requested automatically, even if you only needed the text.
HTTP/HTTPS headers: the hidden weight of each request
Each HTTP request and response carries a set of headers: User-Agent, Cookie, Accept-Language, Referer, Content-Type, and dozens of others. In modern browsers and anti-detect tools (Dolphin Anty, AdsPower, Multilogin), the set of headers can occupy from 500 bytes to 2-3 KB per request — especially if the cookies have accumulated a session with dozens of values.
For example: if you make 10,000 requests to a marketplace API with session cookies of 1.5 KB, about 15 MB of traffic will be spent just on headers — and this does not include the body of the response. When scaling across multiple accounts and profiles, this figure grows linearly.
| Header Type | Average Size | Impact on Traffic |
|---|---|---|
| User-Agent | 100-150 bytes | Low, but accumulates at scale |
| Cookie (session) | 500-2000 bytes | High for long sessions |
| Referer / Origin | 50-200 bytes | Low |
| Accept-* headers | 150-300 bytes | Low |
| Server response headers | 300-800 bytes | Medium, not dependent on you |
Practical takeaway: if you are writing a script to monitor prices on Wildberries or Ozon, clean cookies of unused values and avoid dragging in unnecessary headers copied "just in case" from the browser's DevTools.
TLS handshake: how much traffic encryption consumes
Almost the entire modern web operates over HTTPS, meaning every new connection starts with a TLS handshake — exchanging certificates, encryption keys, and protocol parameters. One complete TLS handshake (TLS 1.2 or 1.3) weighs between 4 to 8 KB depending on the size of the site's certificate and the protocol extensions used.
If you open a new connection for each request (and do not use a persistent connection), the TLS handshake is repeated each time. With 10,000 requests without reusing the connection, you will incur an additional 40-80 MB of traffic just for encryption — which can be more than the actual useful content.
TLS 1.3 is slightly lighter than TLS 1.2 due to a reduced number of round-trips, but the difference is noticeable only with a large number of connections. For mobile proxies, where the operator's network adds its own latency and session reinstatements, the TLS overhead is particularly noticeable — this should be considered when choosing mobile proxies for tasks with frequent short requests.
Retries: how repeated requests double consumption
Retries are the most unnoticed and most expensive item of traffic consumption. If your parser or script is set to automatically retry on timeout or error 429/503, each failed request has already consumed traffic for establishing the connection, TLS handshake, and headers — and then the whole process repeats itself.
A common mistake in SMM automation and marketplace parsing is aggressive retry policies without exponential backoff: the script makes 5 attempts in a row with a one-second interval at the first sign of IP blocking. As a result, for one "useful" response, the traffic of five failed attempts plus the final successful request is consumed.
This is especially critical when working with data center proxies on sites with aggressive protection (such as Avito or large marketplaces), which may return a captcha or block most requests from a "hot" IP. In this case, it makes sense to consider residential proxies — they are less likely to get blocked on the first request, which reduces the number of retries and, consequently, the actual traffic consumption.
Keep-Alive vs new connections
HTTP Keep-Alive allows reusing a single TCP/TLS connection for multiple consecutive requests, avoiding repeated handshakes. This is one of the most effective traffic optimizations available in almost all HTTP clients and anti-detect browsers.
If you use libraries for parsing (requests, httpx, axios) without explicitly specifying a session with a persistent connection, each request by default may open a new TCP connection. In conjunction with proxies, this means: a new connection to the proxy server, a new TLS connection to the target site, and all the overhead is repeated for each call.
| Connection Mode | Overhead for 1000 requests |
|---|---|
| New connection for each request | 4-8 MB (only TLS) |
| Keep-Alive, one session for 50 requests | 0.1-0.2 MB (one handshake for the group) |
The difference is significant — and this is pure traffic savings without any change in the payload of the requests.
How different types of proxies count traffic
The traffic billing model depends on the type of proxy. Data center proxies often have billing based on traffic volume or the number of IPs/ports — the infrastructure itself is faster and adds minimal overhead for routing. Residential and mobile proxies usually have stricter billing because real user IPs are a more expensive and limited resource, and the route through the operator or home provider adds additional hops and, consequently, slightly more control data.
Mobile proxies are the "most expensive" in terms of traffic: cellular networks add their own session reinstatement mechanisms, NAT translations, and sometimes compression/decompression of traffic at the operator level, which increases the data counter compared to the same request through a fixed network.
If the task is to maintain a stable high volume of requests with minimal overhead (for example, mass price parsing on Wildberries or Ozon), data center proxies are better suited for this — they are faster and more predictable in terms of traffic consumption for similar tasks.
How to reduce traffic consumption in practice
Let's break down specific steps that reduce actual traffic consumption without losing the functionality of the parser, automation, or multi-accounting.
1. Disable loading unnecessary resources. If you only need the text of the page or the JSON response from the API, disable loading images, fonts, analytics scripts, and advertising trackers in the settings of the anti-detect browser or headless tool. This often reduces traffic consumption by 60-80% for parsing tasks.
2. Use Keep-Alive and connection pooling. Configure the HTTP client to reuse sessions for a group of requests to a single host — this drastically reduces the number of TLS handshakes.
3. Set a reasonable retry policy. Exponential backoff (1s → 2s → 4s) with a limit of 3 attempts instead of aggressive 5-10 consecutive attempts reduces useless traffic from failed requests while simultaneously decreasing the risk of additional IP blocking.
4. Clean cookies and session headers. Periodically remove accumulated cookie values that are not used by the target site — especially relevant for long sessions warming up accounts on Instagram or TikTok through anti-detect browsers.
5. Cache static responses. If the data (for example, product catalog) does not change every minute, cache the response locally instead of making repeated requests through the proxy for each monitoring cycle.
6. Use compression. Ensure that the Accept-Encoding: gzip header is sent and that the server indeed returns a compressed response — this reduces the volume of incoming traffic on pages with a lot of text or JSON.
Tools for monitoring traffic
To understand where traffic is actually going, it's helpful to look not only at the provider's counter but also at a detailed breakdown of requests. The following tools are suitable:
- Charles Proxy / Fiddler — show the size of each request and response, including headers, which helps find "heavy" cookies or unnecessary resources.
- Wireshark — for deep analysis of TCP/TLS overhead at the packet level, if you need to assess the actual weight of the handshake.
- Built-in traffic counters in anti-detect browsers (Dolphin Anty, AdsPower, GoLogin) — many show consumption for each profile separately, which is convenient for distributing the budget among accounts.
- Logging at the HTTP client level — when writing your own parsing scripts, it's useful to log the size of requests/responses for each call to identify anomalies.
Comparing the readings of your tools with the provider's counter helps quickly understand where traffic is lost — in retries, TLS, or loading unnecessary resources.
Optimization checklist before launch
Before a large-scale launch of a parser, SMM automation, or warming up advertising accounts, go through this short list:
- Loading of images, fonts, and analytics is disabled where they are not needed;
- Keep-Alive / session reuse is configured for a series of requests to a single host;
- The retry policy is limited to 2-3 attempts with delays, rather than infinite repetition;
- Session cookies are periodically cleared of unused values;
- Response compression (gzip/deflate/br) is enabled;
- There is local caching for repeating static requests;
- The type of proxy is chosen according to the task: data center for speed and volume, residential for bypassing blocks, mobile for social networks and advertising platforms.
Conclusion
Traffic consumption through proxies is not only about the useful data of the page but also all the control overhead: headers, TLS handshakes, retries on errors. Understanding this mechanics allows for more accurate budgeting for proxies and avoiding unpleasant surprises in the bill, especially when scaling parsing for marketplaces, SMM automation, or warming up advertising accounts.
If your task is stable parsing with predictable traffic consumption, consider data center proxies. For working with social networks and advertising platforms, where low blocking frequency is important, mobile proxies are better suited. And if you need a balance between anonymity and stability for bypassing website protections, take a look at residential proxies, which reduce the number of retries due to less frequent blocks.