One of our clients generates between 90,000 and 134,000 requests per day to Wildberries through a single mobile proxy — and has been doing so continuously for over 20 days without a single block. 95.9% of requests complete successfully. Real payment transactions also pass through the same proxy: Tinkoff, Rosbank, and 3D Secure for Mir cards. This is not a test — this is real production load that we see in our logs.
Why does it work? Because a mobile proxy with the correct TCP fingerprint looks to Wildberries like an ordinary user's Android smartphone. A datacenter proxy — even one with a perfectly "clean" IP reputation — gives itself away at the TCP handshake level before a single HTTP request is ever sent. In this article, we break down the architecture of Wildberries' antibot system, present a real map of API endpoints from our logs, and explain why TCP fingerprint matters more than IP reputation.
Why Proxies Are Needed for Wildberries and Other Marketplaces
Proxies for marketplaces are a fundamental automation tool for any seller. Wildberries is Russia's largest marketplace with tens of millions of product listings. Ozon holds second place and is catching up fast. Proxies for WB and proxies for Ozon solve similar problems, with a few differences. Competition among sellers is fierce, and automation has become not a luxury but a necessity. Let's walk through the main use cases where proxies are indispensable.
Competitor Price and Inventory Monitoring
Prices on Wildberries change dozens of times a day. Major sellers use dynamic pricing systems that continuously scan competitors and automatically adjust their own prices. One of our parsing clients in our logs makes requests to a.wb.ru (the main API) and www.wildberries.ru (the main site) totaling more than 4,000 times per day — that's a poll roughly every 20 seconds.
Without proxies, this kind of monitoring is impossible: Wildberries limits the number of requests from a single IP and blocks addresses that don't behave "like users." The proxy's job is to distribute the load and give each request stream a "human" connection profile.
Seller Multi-Account Management (FBO/FBS)
Sellers with multiple brands or legal entities manage several personal accounts on WB. Proxies for WB in this scenario are a mandatory account isolation tool. Wildberries ties accounts to an IP address — if two accounts log in from the same IP, the system flags a potential connection. Full isolation requires a separate proxy with a unique IP for each account.
An important nuance: Wildberries checks not just the IP but also browser fingerprint, behavioral patterns, and temporal login correlations. A mobile proxy solves the IP isolation problem and gives each account a "mobile" connection profile typical of a real user.
WB API Automation
Wildberries provides an official API for sellers (statistics, stock levels, orders), but some data is only available through unofficial endpoints or requires bypassing rate limits. Automated supply management systems, repricers, and analytics platforms all operate through proxies.
In our logs, we see the full spectrum of API calls: from fetching product cards via CDN servers at basket-*.wbbasket.ru to checking ratings through user-grade.wildberries.ru and working with support chat through chat.wildberries.ru.
How Wildberries Detects Unwanted Connections
Wildberries' antibot system operates on multiple layers. Understanding each layer helps you choose the right defense tool.
Layer 1: ASN and IP Reputation
The first and most obvious filter is checking the ASN (Autonomous System Number) of the incoming IP. Every IP address on the internet belongs to an autonomous system: this can be a datacenter (OVH, Hetzner, Digital Ocean), a corporate network, or a mobile carrier (MTS — AS8359, Megafon — AS31133, Beeline — AS3216, Tele2 — AS41330).
Requests from datacenter ASNs are treated by Wildberries as potentially bot-driven, triggering elevated checks. Mobile carrier IPs pass through with minimal restrictions — because behind them are real users with phones, not servers.
Layer 2: antibot.wildberries.ru — Active Antibot System
A special subdomain stands out in our logs: antibot.wildberries.ru. It receives ~760 requests per day from a single client — these are continuous checks that WB initiates in parallel with main requests. This is not a passive firewall, but an active system that probes the client connection.
A key figure: 73% of requests to antibot.wildberries.ru succeed. The system sees our proxy, analyzes it, and in 73% of cases decides to let it through. This is because a mobile proxy with the correct fingerprint successfully passes the "are you a real smartphone?" check.
Layer 3: TCP Fingerprint — Identification Before HTTP
The most sophisticated layer of protection is analysis of TCP connection parameters at the network stack level. This happens before any HTTP headers are sent. The tool is called p0f (passive OS fingerprinting): the server examines TCP SYN packet parameters to determine the client's device type and OS.
More on TCP fingerprint in a dedicated section below. The key point here: a Linux-based server proxy produces a specific set of TCP parameters that instantly signals to the antibot system: "this is not a phone."
Layer 4: Network Error Logging (nel.wb.ru)
We also see nel.wb.ru in our logs — this is an implementation of the Network Error Logging (NEL) standard. The browser or app sends reports to this endpoint about network failures: timeouts, DNS errors, dropped connections. Wildberries uses NEL to monitor the quality of user connections. Anomalous patterns (such as an overly stable connection with zero errors) can signal automation.
Running in parallel are marketplace-sentry.wb.ru — a client-side error tracking system — and acollector.wb.ru — a collector for user behavior analytics and metrics.
Why Datacenter and Server Proxies Don't Work on WB
A server proxy is a rented IP from a hosting provider. The IP may formally be "clean" — no entries in spam databases, no abuse history. But the problem isn't the IP's reputation; it's in how the server's network stack is built.
When a Linux server establishes a TCP connection, it sends a SYN packet with characteristic parameters. Wildberries sees these parameters and immediately understands: this is not a phone.
| TCP Parameter | Android (Mobile) | Linux Server | Windows Server |
|---|---|---|---|
| TTL | 64 | 64 | 128 |
| Window size | 65535 | 29200 | 64240 / 42340 |
| WScale | 8–9 | 7 | 6, 11, or 12 |
| MSS | 1460 or 1452 | 1460 | 1460 |
| TCP options | MSS, SAckOK, Timestamp, NOP, WScale | MSS, SAckOK, Timestamp, NOP, WScale | MSS, NOP, WScale, SAckOK |
| TOS | 8 or 40 | 0 | 0 |
| Verdict | Android smartphone | Linux server — blocked | Windows server — blocked |
The key parameter is Window size. Android devices use a value of 65535. A Linux server outputs 29200 by default — a distinctive value that is difficult to spoof without kernel-level intervention. Windows servers return 64240 or 42340 with non-standard WScale values (6, 11, 12) that are never seen on mobile devices.
WB's antibot — like any system using p0f — sees "window=29200, wscale=7" and stamps it "Linux," after which the connection is placed under heightened scrutiny or blocked outright.
Even if you run an Android emulator on a server or spoof the User-Agent, the TCP fingerprint will reveal the real OS. This is the core advantage of a mobile proxy: it runs on a real Android modem that is physically a smartphone or USB dongle with a SIM card.
Real Anatomy of Wildberries Traffic — Data from Our Logs
We analyzed real logs from one of our clients working through Frigate Proxy mobile proxies. The data has been anonymized, but the numbers are real.
Overall Statistics
- ~90,000 requests per day through a single mobile proxy
- 95.9% successful requests (code 00000 in the SOCKS5 protocol)
- 3.5% — connection refused (code 00013 — the WB server temporarily rejected the connection, not a block)
- 0.6% — other errors (timeouts, DNS, network issues)
- Running continuously for several weeks: between 77,000 and 134,000 requests every day
- Protocol: SOCKS5 (not HTTP proxy)
96% successful requests at 90,000/day is a result that a server proxy simply cannot achieve. For comparison: a typical datacenter proxy under this kind of load on WB starts getting blocked within just a few hours.
Wildberries Endpoint Map
Here is the complete list of Wildberries subdomains through which real client traffic flows (with daily request frequency):
| Endpoint | Requests/day | Description |
|---|---|---|
a.wb.ru |
~2,300 | Main Wildberries API — catalog, search, filters, recommendations |
www.wildberries.ru |
~2,100 | Main site — HTML pages for products and categories |
antibot.wildberries.ru |
~760 | WB antibot system — active client authenticity checks (73% successful) |
basket-12/15/38–43.wbbasket.ru |
Thousands | CDN servers with product cards and images (multiple servers) |
static-basket-01.wbbasket.ru |
Hundreds | Static assets (JS, CSS, fonts) |
nel.wb.ru |
Hundreds | Network Error Logging — WB monitors client-side network failures |
marketplace-sentry.wb.ru |
Dozens | Sentry error tracking in the client application |
acollector.wb.ru |
Dozens | User behavior analytics and metrics |
data-checker.wildberries.ru |
Dozens | Data verification — request consistency checks |
user-grade.wildberries.ru |
Dozens | User ratings and reviews |
chat.wildberries.ru / chat-prod.wildberries.ru |
Dozens | Buyer and seller support chat |
user-storage-01.wb.ru / user-storage-02dp.wb.ru |
Dozens | User profile storage, settings, shopping cart |
wb-balance.wildberries.ru |
Dozens | WB wallet balance, transaction history, loyalty program |
wbx-bell-v3.wildberries.ru |
Dozens | Push notifications for orders, promotions, and price changes |
Payment Transactions Through the Proxy
Payment traffic deserves special attention. Our logs include real requests to payment systems that pass through the same mobile proxy:
paywb.com— ~234 requests per day. This is Wildberries' payment system, processing marketplace transactions.securepay.rsb.ru— Rosbank payment processingsecure.tbank.ru/business.cdn-tinkoff.ru— Tinkoff payment gateway3ds-ds2.mirconnect.ru— 3D Secure for Mir payment system cardsnuc-cdp.voskhod.ru— CRL (Certificate Revocation List) for qualified electronic signatures
This is a significant indicator: the mobile proxy is so "transparent" to payment systems that real financial transactions with 3D Secure pass through it without issue. A server proxy is blocked by bank antifraud systems in most cases at the very beginning of the payment flow.
Android TCP Fingerprint — Why It's the Key Trust Factor
What Is a TCP SYN Fingerprint and Why Does It Matter
When your browser or application connects to a server, the first thing that happens is the TCP handshake: the client sends a SYN packet, the server responds with SYN-ACK, and the client confirms with ACK. The SYN packet contains a set of parameters set by the operating system: window size, window scale (WScale), maximum segment size (MSS), and option flags.
Different operating systems set these parameters differently — this is the TCP fingerprint. The tool p0f (passive OS fingerprinting) makes it possible to identify the client's OS simply by looking at the incoming SYN packet — with no request to the client whatsoever, passively. Wildberries, like other major platforms, uses the same approach.
The result: the WB server knows whether you're on Android or Linux before you ever send an HTTP request with a User-Agent header. No amount of User-Agent spoofing or header manipulation helps if the TCP fingerprint reveals a server.
Android Parameters in Our Servers
Our mobile servers at the proxy farm use real Android modems. Here are the actual TCP parameters they produce:
- TTL: 64
- Window size: 65535 — characteristic of Android, iOS, and some mobile operating systems
- WScale: 8–9 — standard values for the Android kernel
- MSS: 1460 or 1452 — depends on connection type (LTE vs. Wi-Fi)
- TCP options: MSS, SAckOK, Timestamp, NOP, WScale — the standard set
- TOS (Type of Service): 8 or 40 — mobile traffic priority values
We have documented 28 unique Android device profiles — real fingerprints collected from a variety of Android smartphones and tablets. We use the syn_rewrite technique: on the fly, we rewrite the TCP SYN packet leaving the modem, replacing its parameters with the matching profile of a real device.
This means every connection through our proxy looks to the p0f analyzer on WB's servers like a connection from a specific Android device model — Samsung Galaxy, Xiaomi Redmi, Huawei, and so on.
Why window=29200 Is a Death Sentence for a Server Proxy
Linux by default uses an algorithm for determining the initial window size that produces values around 29200 (specifically: 14600 × 2, where 14600 is the initial congestion window in Linux). This value is not found on any mobile device. When WB's antibot sees window=29200, it classifies the connection with high confidence as "datacenter" or "Linux server."
Changing this value on a standard VPS is impossible without modifying kernel parameters — and even then, other markers remain (WScale=7 instead of 8–9, TOS=0 instead of 8/40), and their combination still produces a verdict of "not Android."
Proxies for Ozon: Specifics of Working With the Platform
Ozon is Russia's second-largest marketplace, and the use cases are similar: price monitoring, managing multiple seller accounts, data scraping. But there are platform-specific nuances.
Qualified Electronic Signature (QES) for Sellers
Ozon requires a qualified electronic signature (QES) for certain operations (signing contracts, approving acts). In our logs we see specific endpoints:
gost.stg.ozonru.me— GOST cryptography for QES (GOST 34.10-2012)rsa.stg.ozonru.me— RSA operations for electronic signaturesnuc-cdp.voskhod.ru— CRL endpoint for checking revoked certificates (also used on WB)
All of these requests pass through the mobile proxy without any issues. Cryptographic QES operations work through any proxy, since the encryption happens on the client side — the proxy merely transports the encrypted traffic.
Comparing WB and Ozon Antibot Systems
In our experience, Ozon's antibot system is less aggressive than Wildberries'. Ozon has no dedicated subdomain like antibot.wildberries.ru with active probing, and the frequency of CAPTCHA triggers when using mobile proxies is significantly lower. This doesn't mean Ozon is "unprotected" — the threshold for action is simply higher.
That said, the basic rules remain the same: ASN from a Russian mobile carrier, correct TCP fingerprint, IP rotation. Server proxies are also unstable on Ozon — blocks just take a bit longer to arrive.
For working with both marketplaces through mobile proxies, we recommend the same infrastructure — it is universal across all marketplaces in Russia.
Checklist for Choosing a Mobile Proxy for Marketplaces
Not all "mobile proxies" are created equal. Here's what actually matters when making your choice, based on our experience with Wildberries and Ozon traffic.
- Russian mobile carrier only. The IP must belong to the ASN of MTS (AS8359), Megafon (AS31133), Beeline (AS3216), or Tele2 (AS41330). Verify via ipinfo.io: the "org" field should contain the carrier's name, not a datacenter.
- SOCKS5 protocol, not HTTP. Wildberries actively uses CONNECT tunnels (HTTP CONNECT), and some requests travel over UDP. SOCKS5 supports both. Our client with 90,000 requests/day runs exclusively over SOCKS5.
- IP rotation. The mobile IP should change periodically — this is normal behavior for mobile networks (CGNAT, cell tower handoffs). The optimal rotation interval is 5–30 minutes. Rotating too frequently (every 30 seconds) creates an anomalous pattern.
- Android TCP fingerprint (syn_rewrite). This is critical for long-term operation. A proxy running on a real Android modem without syn_rewrite will still produce the correct fingerprint — but verify that the provider doesn't route traffic through a Linux router without packet rewriting. Ask the provider for window size data on outgoing connections.
- Stability over speed. Marketplaces don't require high bandwidth (product cards are small JSON payloads). Modem uptime and successful connection rate are what matter. Our client sees 3.5% connection refused — this is normal, representing temporary rejections from WB's own servers, not blocks.
- UDP support. Our logs contain UDPMAP entries — the client actively uses UDP tunneling over SOCKS5. This is needed for some APIs and WebSocket connections. Make sure your proxy provider supports UDP over SOCKS5, not just TCP.
Frequently Asked Questions About Proxies for Wildberries
Can I use a server (datacenter) proxy for Wildberries?
Technically — yes, you can try. In practice — it's extremely unstable. A server proxy exposes a datacenter ASN and a Linux TCP fingerprint (window=29200), which Wildberries treats as signs of automation. The lifespan of a server proxy on WB under heavy load ranges from a few hours to a few days. A mobile proxy with the correct fingerprint runs for weeks without blocks, as our statistics show.
Do I need a separate proxy for each WB account?
Yes, this is strongly recommended. Wildberries tracks connections between accounts by IP — if two accounts log in from the same IP, the system notes this. Full isolation requires a separate proxy with a unique IP for each account. If using a rotating proxy, make sure the IP in use for one account is not simultaneously serving other accounts.
Are IPv6 proxies suitable for Wildberries?
No. Wildberries does not accept IPv6 for key API endpoints — specifically, a.wb.ru and most subdomains only work over IPv4. Attempting to connect via an IPv6 proxy will result in a connection error before any antibot checks even run. You need IPv4 only, with a mobile ASN.
How do I verify that a proxy works on Wildberries?
Basic check — open https://a.wb.ru through the proxy. If you get a JSON response (or even a 401 authorization error) — the proxy works. If you get connection refused or a timeout — the IP is blocked. For a more precise check, try a catalog request: https://search.wb.ru/exactmatch/ru/common/v4/search?query=proxy.
Can real purchases be made on WB through a proxy?
Yes — our logs confirm this. Real transactions on paywb.com pass through the mobile proxy (~234 times per day for our client), as do requests to the Tinkoff, Rosbank, and Mir 3D Secure payment gateways. Bank antifraud systems are tolerant of mobile IPs from Russian carriers — these are the same addresses from which millions of people make purchases from their phones every day.
Do I need a proxy for the official WB Seller API?
Wildberries' official Seller API works with an API key and filters IPs less aggressively. However, at high request frequencies — more than a few thousand per hour — rate limiting kicks in here as well. For uninterrupted operation of analytics tools and repricers, a mobile proxy is recommended even for the official API.
Try our mobile proxies for Wildberries — the first 24 hours will show you the full difference compared to server-based solutions. Clients switching from datacenter proxies typically see their successful request rate jump from 40–60% to 95%+ on day one.
