Traffic Limit for Parsing Wildberries and Ozon: How to Avoid Wasting a Monthly Proxy Package Overnight

A seller launches a competitor price parser overnight, only to receive a notification in the morning: traffic is exhausted, and the package is 90% used up. Does this sound familiar? More often than not, the issue isn't with the parser itself, but rather the lack of limits at the proxy and script levels. In this article, we will explore how traffic "leaks" unnecessarily and how to implement safeguards to ensure that a monthly package of residential or mobile proxies lasts until the end of the billing period.

Why Traffic Runs Out Overnight

Parsing Wildberries, Ozon, or Avito seems like a straightforward task: send a request and receive a JSON with the price. However, in practice, traffic is consumed not only for useful data. The main sources of overspending are:

• Loading images and media. If the parser opens the product page entirely through a browser (rather than making a direct API request), it automatically loads images, videos, and banners—this can add up to tens of megabytes per product card.
• Repeated requests due to CAPTCHAs and blocks. The marketplace recognizes the bot, issues a CAPTCHA or temporary IP ban, and the script makes a repeated request—traffic is wasted, and data does not come through.
• Lack of request caching. Without logic like "already parsed this hour—do not repeat," the script may query the same product cards multiple times overnight.
• Unrestricted parallel streams. Running 50-100 streams simultaneously may seem like a speed boost, but traffic is consumed much faster than planned, and some requests are simply blocked.
• Incorrect choice of proxy type. Residential and mobile proxies are usually billed based on traffic volume (GB), unlike data center proxies, where payment is often based on the number of IPs or rental time. If the parser is set to a residential pool without control, the limit burns quickly.

The combination of these factors leads to a situation where a script intended for a month of operation consumes a traffic package in just one overnight session parsing 10-20 thousand product cards.

How Traffic is Calculated for Different Types of Proxies

Before setting limits, it is important to understand what exactly you are paying for. Different types of proxies account for consumption differently, and this directly affects your savings strategy.

Proxy Type	Billing Method	Risk of Overspending	When to Use
Residential Proxies	By traffic volume (GB)	High without limits	Parsing with bypassing anti-bot protection of marketplaces
Mobile Proxies	By traffic volume or time	High, traffic is more expensive	Parsing mobile versions of websites, bypassing strict blocks
Data Center Proxies	By number of IPs / rental time	Low, traffic is usually unlimited	Mass parsing without strict anti-bot protection

If you are parsing Wildberries or Ozon, where anti-bot protection is actively in place, residential or mobile IPs are almost always necessary—data center addresses are quickly blocked. However, due to traffic billing, it is especially important to set limits in advance.

How Much Traffic is Actually Needed for Parsing

To set an adequate limit, you need to rely on real figures rather than feelings. Approximate expenses in practice:

• API request for a product card (JSON, without images): 5-30 KB per card. For 10,000 cards—about 50-300 MB.
• Loading a product page through a headless browser with images: 1-3 MB per card. For the same 10,000 cards—10-30 GB.
• Price monitoring once an hour for 1,000 SKUs: with lightweight requests—about 1-5 GB per day, with full page loads—50-100 GB per day.

The difference between "light" and "heavy" parsing can be in the tens of times. Therefore, the first step in saving traffic is to disable the loading of images, videos, and third-party scripts wherever possible and work directly with the marketplace API or the mobile version of the site, which is lighter than the desktop version.

Limits in Anti-Detect Browsers and Proxy Managers

For those who parse through an anti-detect browser (for example, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) or their own proxy manager, the simplest way to limit consumption is to set limits at the profile and proxy provider account levels.

1. Log into your proxy provider's personal account and find the section for managing traffic or limits for sub-users/ports.
2. Create a separate sub-account or port for parsing—do not use the same proxy pool as for farming accounts on Instagram or TikTok. Task separation immediately shows where the traffic is going.
3. Set a daily or hourly traffic limit on this sub-account—for example, 5 GB per day instead of consuming the entire monthly package in one session.
4. In the anti-detect browser, disable auto-loading of images for profiles used solely for data collection, not for visual page viewing.
5. Schedule profile launches so that parsing occurs not in one long session, but in short intervals with pauses—this reduces the risk of blocking and allows time to track traffic consumption between launches.

This approach is especially important for agencies and freelancers who parse multiple marketplaces simultaneously: without separation by sub-accounts, it is difficult to understand which specific project "ate" the traffic.

Traffic Limitation at the Script and API Level

If the parser is written in-house in Python or Node.js, limits can and should be integrated directly into the code—this provides more precise control than the settings of the proxy provider interface.

Here is an example of a simple traffic counter in Python using requests:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # limit 5 GB per day
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("Daily traffic limit exhausted, parsing stopped")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# example call
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Traffic used:", round(used_bytes / 1024 / 1024, 2), "MB")

The logic is simple: the script counts the size of each response in bytes and stops as soon as the specified limit is reached. This protects against situations where, due to an error in a loop or infinite request repetition, the script "eats" a monthly traffic package in just a few hours.

Additionally, it is worth adding:

• Exponential backoff on errors (retry with backoff)—instead of immediately retrying a request upon encountering a CAPTCHA or ban, the script waits an increasing interval (5 seconds, 15 seconds, 60 seconds), which reduces the number of useless requests.
• Limiting the number of parallel streams—for example, no more than 10-20 simultaneous connections through the proxy pool to avoid provoking blocks and wasting traffic unnecessarily.
• Disabling resource loading in the headless browser—if parsing is done through Selenium or Puppeteer, you can block the loading of images, fonts, and CSS in the browser settings, leaving only HTML/JSON responses.

Real-Time Consumption Monitoring

A limit without monitoring works worse because you only learn about the problem after the script has stopped. To control consumption on the fly:

• Enable notifications in your proxy provider's personal account for reaching 50%, 80%, and 100% of the monthly traffic package—most services support such alerts via email or Telegram.
• Keep a simple log in the script itself: record the volume of traffic by hour in a file or database to see consumption peaks and quickly identify the source of the problem.
• Separate traffic by tasks through individual sub-accounts or tags—one for parsing Wildberries, one for Ozon, one for Avito. This simplifies the analysis of which project consumes the most.
• Cross-check consumption with the expected data volume: if 20 GB was used for 10,000 cards instead of the projected 300 MB, it means that unnecessary resources are being loaded or repeated requests are being made.

Traffic Budget Control Checklist

Common Mistakes of Beginners

In practice, most "burned" traffic packages can be explained by several typical mistakes:

• Running parsing "overnight unattended" without limits. The script runs for 8-10 hours without stopping, and if a loop of repeated requests occurs somewhere, traffic is continuously consumed until morning.
• One common proxy pool for all tasks. Farming Instagram accounts, testing ads in Facebook Ads, and parsing Ozon all use the same traffic—it's impossible to understand what exactly is consuming it.
• Ignoring CAPTCHAs. Instead of reducing the request frequency at the first signs of a CAPTCHA, the script continues to hammer the site with the same intensity, wasting traffic on useless error code responses.
• Choosing residential proxies where data center ones are sufficient. If the marketplace does not strictly block data center IPs, overpaying for the traffic of a residential pool is unjustified—data center proxies with a different billing model are suitable for less protected targets.
• Lack of a test run. Before launching a full parse on thousands of cards, it is advisable to run the script on 50-100 cards and measure actual traffic consumption to extrapolate for the entire volume.

Conclusion

Traffic for parsing "burns" not due to the volume of data, but due to a lack of control: unnecessary images, repeated requests during blocks, unrestricted parallel streams, and a common proxy pool for all tasks. The solution is to separate traffic by projects, set daily limits at the proxy account level, integrate a consumption counter into the script itself, and configure monitoring with notifications before the package actually runs out.

If you are parsing marketplaces with active bot protection like Wildberries or Ozon, we recommend using residential proxies to bypass blocks and additionally mobile IPs for the most sensitive anti-bot protection scenarios—but in both cases, be sure to set traffic limits in advance to prevent the monthly package from being consumed in one overnight session.