Error 429 When Scraping Wildberries and Ozon: 6 Reasons Switching Proxies Won't Fix

Are you changing proxies, buying a new pool of IP addresses, yet the parser still crashes with a 429 Too Many Requests error? This is a classic situation: 70% of blocking cases are not related to the IP address, but to how the request itself looks. We will discuss six real reasons why the site continues to ban you even after changing proxies — and what to do in each case.

What does error 429 mean and why proxies are not a panacea

The HTTP code 429 Too Many Requests formally means "request limit exceeded." But in practice, sites — especially Wildberries, Ozon, Avito, Yandex.Market — use this code as a universal signal "we think you are a bot." The reason may be in the request frequency, but just as likely — in the headers, browser fingerprint, lack of cookie session, or limits tied not to the IP, but to your account.

This is why changing proxies often does not help: if the system blocks not the IP, but the request pattern (fingerprint, headers, click speed), then from the new IP address you will get the same 429 in a couple of minutes. We will discuss each reason in detail and show how to check and fix it without buying a new pool of proxies.

Important: proxies remain a necessary tool — but only as part of a system, not as the only solution. Residential and mobile IPs reduce the likelihood of being blacklisted due to IP reputation, but do not protect against blocking due to behavior or headers.

Reason 1: Too high request frequency

The most obvious, yet often misdiagnosed reason. Many think: "since I change proxies for each request — frequency doesn't matter." This is incorrect. Modern anti-bot systems (for example, Wildberries and Ozon use Cloudflare-level solutions or their own WAF) analyze not only the frequency from one IP, but also the overall load on a specific API endpoint or product page over time from all sources combined with behavioral signals.

If your parser makes 50-100 requests per second to the same section of the catalog, the system sees an abnormal traffic spike regardless of how many different IPs you use. The solution is not to change proxies, but to implement artificial delays (throttling) between requests: 1-3 seconds of random delay instead of a fixed interval, plus exponential backoff when receiving a 429 (doubling the pause after each block).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

If you are using a ready-made parser without code (for example, a cloud price monitoring service), check the settings for the interval between requests — most of these tools have a "scan speed" slider. Reducing the speed by 30-40% often completely removes 429, even without changing proxies.

Reason 2: Incorrect or missing headers

Many parsers send requests with a minimal set of headers or use the default User-Agent string from the library (for example, "python-requests/2.28.1"). Such a header instantly identifies a bot — a real browser sends dozens of headers: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer, and others in a specific order.

Wildberries and Ozon compare the set of headers with the expected "fingerprint" of a real Chrome or Safari browser. If there are too few headers, they are in the wrong order, or the User-Agent does not match the other parameters (for example, Chrome is declared on Windows, but the TLS fingerprint resembles Python) — the request is blocked with a 429 regardless of the IP.

Header	Typical mistake	Solution
User-Agent	Outdated version or clearly library string	Current UA of real Chrome/Safari, rotation from the pool
Accept-Language	Missing or does not match the geolocation of the IP	ru-RU for Russian marketplaces
Referer	Empty, although a real transition always has a Referer	Specify the previous catalog page
Sec-Fetch-*	Completely absent (not a browser client)	Copy the full set from DevTools of a real browser

The easiest way is to copy the full set of headers from the Network tab in DevTools of a real browser by manually opening the desired page, and use this set in the parser — taking into account the order of the headers, if the library allows it (for example, curl_cffi or httpx with explicit order).

Reason 3: Lack of session and cookie rotation

An error that is often overlooked: the parser changes the IP for each request but uses the same cookie session or does not save cookies at all. A real user receives a set of cookies (session tokens, device identifiers, antibot protection labels like Cloudflare __cf_bm or similar ones from Ozon/WB) on the first visit and uses them in all subsequent requests within the session.

If you send a request without cookies obtained from a "warmed-up" page, the anti-bot system sees a "zero" session — and this is immediately suspicious, especially when accessing API endpoints directly, bypassing the main page. The solution is to emulate the full scenario: first load the main page or category page, obtain cookies, wait 1-2 seconds, and only then access the desired API or product card, keeping cookies in the same session throughout the chain of requests.

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# Warming up the session
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Main request already with cookies
response = session.get(target_url)

If you are using an anti-detect browser like Dolphin Anty or AdsPower to monitor product cards manually or through built-in automation, make sure the profile saves cookies between sessions and does not start each time "from scratch" — this also triggers the system's suspicion.

Reason 4: Bot-like behavior

Even with perfect headers and cookies, the parser may reveal itself through behavioral patterns: strictly linear order of accessing products (increasing ID), identical intervals between requests down to milliseconds, absence of "garbage" requests for static resources (images, CSS, JS) that a regular browser loads automatically.

Advanced protection systems of Wildberries and Ozon analyze not only HTTP requests but also whether JavaScript was executed on the page (through headless detection), whether the "mouse" moved, and whether there was scrolling. If you make clean HTTP requests without rendering JS, and the site expects script execution to obtain a token (for example, anti-bot JavaScript challenge), a request without executing this script automatically receives 429 or 403.

The solution depends on the scale: for small volumes, using a headless browser (Playwright, Puppeteer) with emulated mouse movements and random delays is suitable. For industrial parsing — randomizing the order of product traversal, adding "noise" in the form of requests for secondary resources, variability of time intervals according to a normal distribution rather than a fixed step.

Reason 5: TLS/JA3 fingerprint and HTTP/2

This is the most "invisible" technical reason that 90% of people engaged in parsing without deep technical training do not know about. Each TLS client (requests library, curl, urllib) leaves a unique fingerprint when establishing an HTTPS connection — a set of supported ciphers, protocol versions, TLS extensions. This fingerprint is called JA3/JA4 fingerprint.

Anti-bot systems at the level of Cloudflare, Akamai, and proprietary solutions of large marketplaces compare the JA3 fingerprint with a database of known bots and libraries. The standard Python requests or Node.js https module has an easily detectable fingerprint that is completely different from the fingerprint of a real Chrome. Even with perfect headers and cookies, the request is blocked precisely at the level of the TLS handshake, before the server sees the HTTP headers.

Additionally, many marketplaces require HTTP/2 with specific parameters (the order of SETTINGS frames, stream prioritization) — libraries based on HTTP/1.1 are automatically distinguished against this background. The solution is to use libraries that emulate the fingerprint of a real browser: curl_cffi (emulates Chrome TLS fingerprint), tls-client, or full-fledged headless browsers based on Chromium, which provide a "real" fingerprint by definition.

Reason 6: Account or API key level limit

If you are working through the official or semi-official API of the marketplace (for example, Wildberries Seller API or Ozon Seller API), 429 may be tied not to the IP, but to the seller's account or API token itself. In this case, changing proxies is completely pointless — the limit is stored on the server side tied to your account identifier, and any IP from that account will receive the same restriction.

This situation is typical for sellers who simultaneously monitor competitors' prices through their personal account and pull the API for inventory downloads — both streams of requests are summed up in the overall account limit. The solution is to spread the load over time, use official API quotas more economically (cache data that does not change every minute), and for pure monitoring of competitors' prices, use a separate unauthorized stream of requests not tied to the seller's account.

It's easy to check this: if 429 continues even when accessing from a clean new IP and without a single cookie from previous sessions, but you are logged into your personal account in a neighboring tab — most likely, the limit is indeed account-based.

How to diagnose the real reason

Before changing infrastructure, conduct diagnostics according to the following algorithm. First, manually open the page in a regular browser and ensure that 429 does not occur with live behavior — this will confirm that the problem is on the parser's side, not a global regional block.

Then compare your parser's headers with those of a real browser through DevTools (Network tab → Copy as cURL). If the difference is minimal, check the TLS fingerprint through services like tls.peet.ws — send a request with your library and compare the JA3 hash with the reference browser one. If the request fails at the TLS handshake stage (the connection breaks before receiving the HTTP response) — the reason lies in the fingerprint, not in frequency or headers.

Next, check whether the limit is tied to the IP or the account: make a request from a new clean IP without authorization. If 429 disappears — the problem was in the reputation of the previous IP or in the frequency from that address. If 429 remains — look for the reason in headers, TLS, or behavior, not in proxies.

Checklist for resolving 429 without changing proxies

1. Add random delays of 1-4 seconds between requests instead of a fixed interval.
2. Copy the full set of headers from a real browser, including Sec-Fetch-* and Accept-Language.
3. Save and pass cookies within one session, starting with warming up the main page.
4. Check the TLS fingerprint of your library — use curl_cffi or a headless browser instead of a plain HTTP client.
5. Randomize the order of page traversal and add "noise" requests for static resources.
6. Separate the load of the API account and anonymous price monitoring into different streams.
7. Implement exponential backoff when receiving 429, rather than an immediate request retry.
8. Only after checking all the above points — change proxies or expand the IP pool.

When proxies are still needed and which to choose

After addressing all six reasons, proxies remain an important element of the infrastructure — but now as a means of scaling, not the only way to combat blocks. If your task is to monitor thousands of Wildberries and Ozon cards in parallel from different "virtual users," you need a pool of IPs with a good reputation to avoid accumulating a history of blocks on one address.

For mass monitoring of prices and catalogs of marketplaces, residential proxies are best suited — they use real IPs from home providers, so anti-bot systems perceive requests as traffic from regular buyers, not data centers. This is critical, as Wildberries and Ozon have long maintained blacklists of data center IP ranges.

If the task is related to checking the mobile version of the site, working through the marketplace app, or testing ads in TikTok Ads and Facebook Ads with geographical accuracy down to the city, mobile proxies are relevant — they have the highest level of trust with most protection systems, as the IPs belong to real cellular operators.

For less sensitive tasks — for example, parsing open catalogs without authorization at small volumes — you can use data center proxies: they are significantly cheaper and faster but require more careful header and TLS fingerprint configuration, as they inherently carry a higher risk of being flagged.

Proxy Type	When it resolves 429	When it won't help
Residential	IP already blacklisted due to reputation	Blocked due to TLS fingerprint or headers
Mobile	Maximum trust is needed for sensitive scenarios	Limit tied to the account, not the IP
Data Center	Simple parsing of open pages without authorization	Strict anti-bot systems with reputation checks on ranges

Conclusion

Error 429 while parsing is rarely resolved by simply clicking "change proxy." In most cases, the problem lies in request frequency, incomplete headers, lack of cookie session, detectable TLS fingerprint, behavioral patterns, or limits tied to the account rather than the IP address. Go through the diagnostics for each of the six points in this article before spending your budget on expanding your proxy pool.

When the technical part is set up correctly — headers match a real browser, the TLS fingerprint does not reveal the library, and requests imitate natural user behavior — proxies become a truly effective scaling tool. For monitoring prices on Wildberries and Ozon at industrial volumes, we recommend starting with residential proxies: they provide the best balance between cost and level of trust with anti-bot systems.