DEV Community: yooexo

Building a Proxy Health-Check Dashboard for 1000+ Residential IPs

yooexo — Wed, 30 Sep 2026 03:24:00 +0000

A rotating residential pool with 1,000 IPs sounds like abundance until you measure it. On any given hour, 4-7% of the pool is broken: unreachable, geo-drifted, ISP mislabeled, or already on someone else's abuse list. Nobody tells you which ones. Your account gets flagged, you check the proxy provider dashboard, and it shows "all systems operational."

The only fix is your own monitoring stack. This article covers the one that has held up across three production pools: what to check, how often, where to store the data, which Grafana panels actually catch incidents before users do, and how the health signal loops back into the BitBrowser profile fleet so bad IPs stop getting reassigned.

What "proxy health" actually means

Proxy health is not a single metric. It is a rolling composite of five signals, each of which fails independently:

Connectivity. Does the proxy answer a TCP handshake in under 3 seconds?
Egress IP correctness. When you route a request through it, does the destination see the IP the provider promised?
Geolocation accuracy. Does the IP resolve to the country and region the provider claims?
ISP classification. Does the IP register as residential (or mobile) rather than hosting or datacenter?
Reputation status. Is the IP on Spamhaus DROP, on Scamalytics' fraud list, or blocked by Cloudflare's threat score?

A proxy can pass 1-3 and fail 4-5, and the failure is invisible until an account signup gets a CAPTCHA loop or a payment gateway declines the transaction. All five need continuous checks.

The metrics catalog

The dashboard tracks eleven metrics per IP. Nine come from active probes, two from the fleet feedback loop:

proxy_up (0 or 1)
proxy_latency_ms (histogram)
proxy_egress_ip_match (0 or 1)
proxy_geo_country, proxy_geo_region (labels)
proxy_isp_type (residential, mobile, hosting, unknown)
proxy_reputation_score (0-100, lower is worse)
proxy_blocklist_hits (count of lists flagging the IP)
proxy_last_check_timestamp
proxy_bitbrowser_profile_flags_24h (from the fleet feedback loop)
proxy_bitbrowser_session_failures_24h (from the fleet feedback loop)

Eleven metrics, one label set per IP, roughly 11,000 time series for a 1,000-IP pool. Prometheus handles that on a t3.medium without breaking a sweat.

The architecture

   Proxy pool (Proxy-Seller, IPRoyal, Bright Data, ...)
                    │
                    ▼
   ┌───────────────────────────────┐
   │      Check worker (Node.js)   │
   │  ─ Round-robin scheduler       │
   │  ─ HTTP probe (via proxy)      │
   │  ─ Geo lookup (ipinfo.io)      │
   │  ─ Reputation lookup           │
   │  ─ Prometheus /metrics         │
   └───────────────┬───────────────┘
                   │  scrape /metrics every 15s
                   ▼
   ┌───────────────────────────────┐
   │        Prometheus              │
   │  ─ 30d retention               │
   │  ─ Alertmanager rules          │
   └───────────────┬───────────────┘
                   │
                   ▼
   ┌───────────────┴───────────────┐
   │            Grafana             │
   │  ─ Pool overview               │
   │  ─ IP drill-down               │
   │  ─ Provider comparison         │
   └────────────────────────────────┘

One check worker per 500 IPs. Two workers cover a 1,000-IP pool with room to spare. Prometheus scrapes both workers on the same interval so metrics stay aligned.

The check worker

Node.js with axios, prom-client, and a small round-robin queue. The core loop for one proxy:

const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');
const client = require('prom-client');

const proxyUp = new client.Gauge({
  name: 'proxy_up',
  help: '1 if the proxy answered, 0 otherwise',
  labelNames: ['proxy_id', 'provider', 'geo_expected']
});

const proxyLatency = new client.Histogram({
  name: 'proxy_latency_ms',
  help: 'Round-trip latency to the probe endpoint',
  labelNames: ['proxy_id', 'provider'],
  buckets: [50, 100, 250, 500, 1000, 2500, 5000]
});

async function checkOne(proxy) {
  const agent = new HttpsProxyAgent(proxy.url);
  const start = Date.now();
  const labels = { proxy_id: proxy.id, provider: proxy.provider, geo_expected: proxy.geo };

  try {
    const res = await axios.get('https://ipinfo.io/json', {
      httpsAgent: agent,
      timeout: 8000
    });
    const elapsed = Date.now() - start;
    proxyUp.set(labels, 1);
    proxyLatency.observe({ proxy_id: proxy.id, provider: proxy.provider }, elapsed);
    return { ok: true, data: res.data, elapsed };
  } catch (err) {
    proxyUp.set(labels, 0);
    return { ok: false, error: err.code || err.message };
  }
}

The probe endpoint is ipinfo.io/json because it returns IP, country, region, city, and ASN in a single call. Free tier gives 50,000 requests per month, enough for a 1,000-IP pool checked every 5 minutes.

Reputation lookups are more expensive. Batch them: pull every distinct IP from the pool once per hour, hit IPQualityScore or Scamalytics in bulk mode, cache results for 60 minutes in Redis. This keeps the reputation API bill under $30/month even at 1,000 IPs.

Storage choice

Prometheus over InfluxDB, TimescaleDB, or Victoria Metrics for a pool this size. Reasons:

The metric cardinality (11 metrics × 1,000 IPs = 11k series) sits comfortably in the middle of Prometheus's sweet spot
Grafana's Prometheus data source is the most polished
The Prometheus query language handles the "IPs currently dead" and "IPs that failed 3 checks in a row" queries in one line each
Alertmanager ships with Prometheus and needs no extra binary

Retention: 30 days. Anything older than a month is not useful for triage and takes up disk. If you need long-term trends, export daily aggregates to a Postgres table and query that instead.

The Grafana dashboard

Four panels. That is it. Adding more panels reduces incident response speed, not increases it.

Panel 1: Pool health heatmap. X-axis is time (last 6 hours). Y-axis is proxy_id. Cell color is proxy_up. A sudden vertical stripe of red means a provider outage. A slowly growing pattern of red dots means IPs are being burned individually.

Panel 2: Failed-probe rate per provider. Line graph, one line per provider (Proxy-Seller, IPRoyal, NetNut, DataImpulse). Y-axis is (1 - avg(proxy_up)) * 100. Any line crossing 8% is a signal to open a support ticket with that provider.

Panel 3: Geo drift table. A table of IPs where proxy_geo_country != geo_expected. If a US IP starts resolving to Panama, remove it from the pool immediately.

Panel 4: Correlation with BitBrowser flags. Scatter plot: X-axis is proxy_reputation_score, Y-axis is proxy_bitbrowser_profile_flags_24h. The cluster of high-flag / low-reputation IPs in the bottom-right is your daily kill list.

Alertmanager rules

Three alerts, no more. Every additional alert dilutes the ones that matter:

groups:
- name: proxy-health
  rules:
  - alert: ProxyPoolDegraded
    expr: (1 - avg by (provider) (proxy_up)) > 0.08
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "{{ $labels.provider }} pool is >8% down for 10 minutes"

  - alert: ProxyGeoDrift
    expr: count(proxy_geo_country != on(proxy_id) group_left proxy_geo_expected) > 20
    for: 5m
    labels:
      severity: warning

  - alert: ProxyReputationCollapse
    expr: avg by (provider) (proxy_reputation_score) < 40
    for: 15m
    labels:
      severity: critical

Route them to a dedicated Slack channel that only fires on proxy issues. Muted-by-default. Anyone whose account gets flagged checks that channel first.

Feeding the signal back into BitBrowser

The dashboard is not the endpoint. It is the input to a decision loop. A small service (also Node.js, also under 300 lines) subscribes to Prometheus queries every 5 minutes and, for any IP flagged as unhealthy:

Calls the BitBrowser LocalAPI to find every profile bound to that IP
Marks each profile as proxy_stale in a local database
Prevents the dispatcher from opening those profiles until a new IP is assigned
Requests a fresh IP from the provider's rotation API
Updates the profile via /browser/update with the new proxy config

This closes the loop. A dying IP takes profiles offline in under 5 minutes instead of after a user complaint. Protocol-level nuances (why HTTP vs SOCKS5 vs Shadowsocks matter here, especially for mobile carrier detection) are covered in this proxy protocol comparison.

Where cloud phones fit in the same pipeline

Mobile pools have a different failure mode: the phone itself can be fine while the carrier's IP block goes on Snapchat's ban list. Extending the dashboard to cover BitCloudPhone Android and BitCloudPhone iOS devices means adding two more probe types:

App-store reachability check. Every 15 minutes, from each cloud phone, hit the App Store or Play Store discovery endpoint. A 403 or 429 means the device's carrier IP is soft-blocked at the app layer, invisible from web-only probes.
In-app CAPTCHA rate. Track how often accounts running on a given device hit CAPTCHAs. Above a threshold, cycle the device.

Both probes return the same Prometheus metric names with a platform=ios or platform=android label. One dashboard covers three worlds.

Scaling notes

The stack above sizes to roughly 5,000 IPs on a single Prometheus instance and a two-worker check fleet. Beyond that:

Layer	Bottleneck	Fix
Check worker	Node event loop under 2,000 concurrent HTTP calls	Split into worker pool via `piscina`
Prometheus	Series cardinality above 100k	Shard by provider onto separate Prometheus instances
Reputation API	Cost per lookup	Extend cache TTL, batch harder, drop reputation for internal-only pools
Grafana	Panel query time above 3 seconds	Add recording rules for expensive expressions

At 10,000 IPs the architecture pattern is the same, the numbers on each box change.

FAQ

Which reputation service is worth paying for?
IPQualityScore for general fraud scoring, Scamalytics for stricter e-commerce use cases, and MaxMind minFraud when payment risk is the specific concern. All three have similar accuracy; the choice comes down to which one your target platforms use themselves.

Can I skip reputation checks entirely?
For internal automation that never touches a payment gateway or an identity-verification vendor, yes. For anything that touches Stripe, Facebook Ads, or account creation on a Tier-1 platform, no. The reputation check catches issues 24-48 hours before the destination platform's own risk engine does.

What if my proxy provider does not expose sticky sessions?
The dashboard still works, but the metric labeling shifts. Instead of proxy_id, label by session_token and expect a much higher series churn. Prometheus handles it up to about 20,000 unique tokens per hour.

How do I probe from the same geo as the proxy claims to be in?
For most checks the probe origin does not matter — ipinfo.io returns the same data whichever direction the query comes from. For app-store and CAPTCHA checks, the probe must originate from the proxy itself; that is what the cloud phone probes cover.

Does this replace the proxy provider's own dashboard?
Yes, and you should stop trusting the provider's dashboard the day you have your own. Provider dashboards report internal health. What matters is what the destination platforms see, and only your own probes measure that.

Where to take it from here

Start with 50 IPs from one provider and the four Grafana panels. Prove the check worker stays under 10% CPU. Prove the alert rules fire on real outages, not on transient blips. Then add the second provider, then the third, then the cloud phone probes.

Every monitoring stack I have shipped in production started as one worker checking one pool with two panels. The stack that tried to cover everything from day one is still in a Git branch nobody merged.

Affiliate disclosure: This post contains affiliate links. If you sign up for a paid BitBrowser or BitCloudPhone plan through the links above, I may earn a small commission at no additional cost to you. All numbers above come from monitoring stacks I run against my own paid accounts.

Wildberries Multi-Seller: A Complete Guide to the Anti-Detect Browser

yooexo — Tue, 18 Aug 2026 17:36:26 +0000

Wildberries blocked over 14,000 seller accounts in Q1 2026 alone, according to their published seller report. Most of those bans weren't for fake products or review fraud. They were triggered by what the platform calls "associated account detection": two or more stores sharing the same device fingerprint, IP range, or browser session data.

If you run more than one Wildberries store, or you're planning to, this guide covers the exact tools and setup that keep accounts isolated. You need an antidetect browser for desktop management, a cloud phone for mobile app access, and a dedicated Russian residential proxy per account. Read on for the specifics.

What is an antidetect browser, and why do Wildberries sellers need one?

A regular browser (Chrome, Firefox, Safari) sends a fingerprint to every website you visit. That fingerprint includes your screen resolution, installed fonts, canvas rendering hash, WebGL vendor string, time zone, language settings, and about 40 other parameters. Wildberries logs this fingerprint when you log into the seller portal.

Open a second Wildberries seller account on the same device and the same browser, the fingerprint matches. Their system flags both accounts as related and suspends them simultaneously.

An antidetect browser solves this by creating isolated browser profiles, each with its own fabricated fingerprint. Account A runs in Profile 1, which shows a Windows 10 machine with a 1920×1080 screen, Calibri font, and a specific canvas hash. Account B runs in Profile 2: different OS, different screen resolution, different canvas signature. Each profile stores cookies and local storage separately, so there's no bleed between sessions.

The antidetect browser doesn't just change the user-agent string. That's what incognito mode does, and it doesn't work. It replaces the entire device identity at the API level.

How Wildberries actually detects related seller accounts

Before setting up anything, it helps to know what you're defending against. Wildberries' association detection looks at several layers:

Browser fingerprint matching. Canvas hash, WebGL renderer, AudioContext fingerprint, font enumeration, and screen parameters. Two accounts with identical values on three or more of these get flagged automatically.

IP address correlation. Two accounts logging in from the same IP address on the same day is a hard trigger. Even if the fingerprints differ, shared IPs create an "association chain" in their system.

Cookie and localStorage sharing. If your browsers share session cookies (common when running multiple tabs), account A's session data can leak into account B's requests. Regular Chrome profiles don't isolate these.

Behavioral timing patterns. Wildberries tracks login times. If Account A and Account B both log in every morning between 9:00 and 9:05 Moscow time from the same approximate IP range, their system marks that as suspicious even without a direct fingerprint match.

Payment method overlap. Accounts that list the same bank card, phone number, or OGRN get linked in their seller database regardless of technical isolation. This one has nothing to do with browsers. It's a business data problem.

A proper antidetect browser handles the first three. A proxy handles the fourth (partially). Business data separation handles the fifth.

Which antidetect browser works best for Wildberries in 2026?

BitBrowser is the strongest option for Wildberries multi-seller setups right now, and it holds that position for three specific reasons.

First, it supports Russian-locale fingerprints natively. You can set the browser language to ru-RU, the time zone to Europe/Moscow, and the keyboard layout to Russian inside each profile. When Wildberries reads your browser's navigator.language property, it gets ru-RU instead of something that contradicts your Russian IP. Mismatched locale and IP is one of the easier ways to get flagged.

Second, BitBrowser has a free tier with up to 10 profiles. That covers most Wildberries multi-sellers who run 3 to 8 stores. You don't need to pay to test the setup or run a small operation. Paid plans start at around $10 per month for more profiles and team access features.

Third, it passes standard fingerprint audit tools. Running a fresh BitBrowser profile through BrowserLeaks, CreepJS, and Pixelscan should show no automation flags, no WebDriver property exposed, and no canvas or WebGL anomalies. Test this before you log into any real account.

The setup process for a Wildberries profile in BitBrowser takes about 4 minutes:

Create a new profile. Name it after the store (e.g., "WB Store 2: Electronics").
Set OS to Windows 10 or Windows 11. Russian sellers overwhelmingly use Windows, so matching that reduces fingerprint suspicion.
Set language to ru-RU, time zone to Europe/Moscow.
Assign your proxy (covered in the next section).
Open the profile, go to browserleaks.com, and confirm the IP, locale, and time zone all match before logging in.

One thing to do before running the profile: open chrome://settings/ inside the profile and disable any auto-fill or sync features. BitBrowser profiles are isolated from Chrome sync, but disabling it explicitly prevents unexpected data requests.

What proxy setup do you need for Wildberries accounts?

The proxy choice matters as much as the browser. A good antidetect browser with a bad proxy still gets flagged. For Wildberries, the rules are clear:

Use Russian residential proxies. Wildberries is headquartered in Moscow and most of its seller base operates from Russian ISPs. A login from a US datacenter IP triggers immediate scrutiny. A residential IP from Rostelecom or MTS looks like a normal Russian internet connection.
One dedicated IP per account. Shared proxy pools rotate IPs between users, which means Account A might occasionally get the same exit IP as another seller's Account B. Dedicated IPs cost a bit more but the isolation is worth it for accounts generating real revenue.
For mobile app access, use Russian mobile proxies. 4G proxies from Russian mobile carriers (MTS, Megafon, Beeline) give you a mobile ASN, which matches the expected IP type when logging in through a phone or cloud phone.

This dev.to article covers how to architect proxy rotation if you're managing a larger number of accounts programmatically:

Digital Growth Pro

Jan 13

Building a Proxy Rotation System for Web Automation: Architecture Patterns and Implementation

#webdev #javascript #proxy #automation

8 min read

For manual multi-seller setups, you just need static residential IPs, one per account.

Assigning the proxy in BitBrowser:

In the profile settings, click the Proxy tab.
Select SOCKS5 (preferred) or HTTP.
Enter the IP, port, username, and password from your proxy provider.
Save, then click Check Proxy inside BitBrowser. It shows you the resolved IP and country. Confirm it shows RU before using the profile.

Do you need a cloud phone for Wildberries?

Desktop browser management covers the Wildberries Partner Portal (partners.wildberries.ru) but the mobile app is a separate channel. Many sellers use the Wildberries Seller app on iOS or Android to handle order fulfillment, buyer messages, and listing updates. The app fingerprints the device separately from the browser: UDID, device model, OS version, and screen resolution.

Log into two different Wildberries seller accounts from the same physical iPhone and those accounts get linked at the device level. The fix is a cloud phone: a virtual mobile device hosted remotely, with its own isolated device identity and a separate IP assignment.

BitCloudPhone (Android) and BitCloudPhone iOS handle this for Wildberries sellers. Each cloud phone instance has its own device fingerprint, its own app environment, and accepts its own proxy assignment. You run it from your regular browser and it presents as a completely separate physical device to Wildberries.

The iOS version specifically matters for the Russian market because iOS penetration among Russian e-commerce buyers and sellers is high. Wildberries iOS app updates ship regularly and sometimes add new device checks. BitCloudPhone iOS keeps pace with those updates. You're not jailbreaking a phone or running an emulator that an app can detect as virtual. The cloud phone environment is designed to look like real device hardware.

For a Wildberries multi-seller operation running 5 stores, the typical setup is:

Component	Tool	Per account
Partner Portal (desktop)	BitBrowser profile	1 Russian residential IP
Mobile seller app	BitCloudPhone iOS	1 Russian 4G mobile IP

You access both from the same laptop. The cloud phones are remote, so there's no local hardware fingerprint from your actual machine.

What account-level separation does Wildberries require?

Technical isolation through an antidetect browser gets you past fingerprint detection. Business data separation keeps you clean at the account-record level. These are different problems.

For each Wildberries seller account, Wildberries stores: the seller's legal entity (IP or OOO), the OGRN/OGRNIP number, the bank account tied to payouts, the phone number for verification, and the email address. Accounts sharing any of these get linked in Wildberries' seller database regardless of how well your browser profiles are isolated.

Each store needs:

Its own phone number for SMS verification
Its own email address (different domain if possible; similar patterns like store1@gmail.com and store2@gmail.com draw less scrutiny than exact matches, but separate domains are cleaner)
Its own payout bank card or account
Its own legal entity (IP or OOO registration with a unique OGRN)

Most Russian multi-sellers operating legally use separate sole proprietor (IP) registrations or different OOO entities. The point is that the paper trail for each account has to be genuinely distinct.

How to warm up a new Wildberries seller account

Wildberries treats brand-new seller accounts with a lower trust score. Account-association detection is more sensitive during the first 30 days. Three things help here:

Log in gradually at first. Don't open all 5 accounts on day one. Start with one, let it run for a week with normal activity, then add the second account, and so on. Accounts that start simultaneously from different profiles on the same day raise a pattern flag.

Match your activity hours to the account's supposed location. If the account's store is listed as being based in Novosibirsk (UTC+7), seller login activity should happen during Novosibirsk business hours, not 2:00 AM Moscow time. BitBrowser lets you set the time zone per profile. Use it.

Don't copy listings between accounts during the warm-up period. Two accounts listing the exact same product with the exact same title, photos, and description on the same day. Wildberries' content matching system flags them as related. Differentiate the listings even for the same product: different main image, different title structure, different keyword emphasis.

Browser automation for Wildberries: is it worth it?

Some sellers automate Wildberries seller tasks: bulk listing uploads, price updates, stock adjustments. BitBrowser exposes a local REST API that automation tools can call to create profiles, assign proxies, and open sessions. You can build scripts using Selenium, Playwright, or Puppeteer that connect to BitBrowser's existing browser instances rather than launching a detectable headless browser.

The advantage of going through BitBrowser's API rather than directly launching Playwright is that the browser instance already has a full human fingerprint. A standard playwright.chromium.launch(headless=True) exposes the navigator.webdriver flag that Wildberries can read. A session launched through BitBrowser's API inherits the profile's fingerprint and doesn't set that flag.

This dev.to article walks through the technical connection pattern for setting up automated sessions with real fingerprints:

Digital Growth Pro

Apr 16

BitBrowser + Selenium: Setting Up Automated Browser Sessions with Real Fingerprints

#selenium #webdev #automation #security

6 min read

For most Wildberries multi-sellers, full automation isn't necessary. Manual management of 5 to 8 accounts through BitBrowser profiles takes maybe 90 minutes per day across all stores. Automation becomes worthwhile at 15+ accounts or when you need bulk price updates across hundreds of SKUs.

What happens if one account gets flagged?

Set up proper isolation and one account still gets a warning or temporary suspension, the other accounts shouldn't be dragged down with it. That's the entire point of isolation. With a proper antidetect browser setup and separate proxies:

The flagged account's cookie data doesn't exist in other profiles
Each account's IP is dedicated, so it can't be traced to other accounts' IPs
Each profile fingerprint is unique, so Wildberries can't find matches to other stores

The investigation stays contained. You lose one account, not all five.

Without isolation, running everything on Chrome with a VPN toggle means a single suspension investigation can unravel every related account, because Wildberries can trace the shared fingerprint and IP history through their logs. That's how sellers lose entire portfolios at once.

Russian marketplace multi-account management: same rules apply

Everything covered here transfers to Ozon, Avito, and Yandex Market. All three use fingerprinting and IP correlation to detect related accounts. That antidetect browser + Russian residential proxy + separate business data stack works across all of them.

Wildberries differs from those platforms in one specific way: the mobile app requirement. More Wildberries sellers manage day-to-day operations through the app than through the Partner Portal web interface. That's why the cloud phone component matters more for Wildberries than it does for Ozon, which has a more complete web-based seller interface.

For sellers managing accounts on multiple Russian marketplaces simultaneously, one practical approach is to extend the naming convention: "WB Store 1," "Ozon Store 1," "Avito Account 1": each gets its own BitBrowser profile and its own proxy, clearly labeled so there's no confusion about which account is active in which profile.

What does a full Wildberries multi-seller setup cost?

Here's a rough monthly cost breakdown for running 5 stores:

Item	Monthly cost
BitBrowser paid plan (10+ profiles)	~$10–$20
5 dedicated Russian residential proxies	~$30–$60
BitCloudPhone iOS (5 instances)	varies by plan, check here
5 virtual phone numbers for verification	~$5–$15
Total	~$50–$120

Against the revenue that 5 active Wildberries stores generate, that's a small operational cost. Losing all accounts to a single suspension wave costs significantly more.

FAQ

What is an antidetect browser and why do Wildberries sellers need one?

An antidetect browser replaces your real device fingerprint with a separate, isolated profile for each session. Wildberries uses fingerprinting to detect related accounts sharing the same device. Running two stores from one regular browser gets both flagged. BitBrowser assigns each store its own unique fingerprint, so the platform sees two completely different devices.

How many Wildberries accounts can I safely run with BitBrowser?

BitBrowser's free tier supports up to 10 isolated profiles. Paid plans start around $10/month and scale to hundreds of profiles. Most Wildberries multi-sellers run 3 to 8 accounts per operator without issues, pairing each profile with a dedicated Russian residential IP.

Do I need a cloud phone to manage Wildberries accounts?

Not for the Partner Portal, but yes for the mobile seller app. The iOS and Android apps use device fingerprinting that a desktop browser can't replicate. BitCloudPhone and BitCloudPhone iOS give each account a completely separate device identity, without needing multiple physical phones.

Which proxy type works best for Wildberries multi-seller accounts?

Russian residential proxies, one dedicated IP per account. For mobile app access, Russian 4G mobile proxies match the expected mobile ASN. Shared proxies and datacenter IPs both get flagged faster for Wildberries seller logins.

Can Wildberries detect BitBrowser?

BitBrowser is designed to pass standard fingerprint tests including BrowserLeaks, CreepJS, and Pixelscan. The key is pairing each browser profile with a matching residential proxy and not reusing fingerprint parameters across accounts. Test every new profile before using it on a real account.

Is using multiple Wildberries accounts against the platform's rules?

Wildberries prohibits one legal entity from operating multiple accounts to exploit promotional systems. Separate legal entities operating separate stores is common practice. The requirement is true isolation: different IPs, different devices or browser profiles, different payment methods, and no shared registration data.

What is BitCloudPhone iOS and how does it help Wildberries sellers?

BitCloudPhone iOS is a cloud-hosted iPhone environment. Each instance has its own iOS device fingerprint, UDID, and IP. For sellers managing orders through the iOS Wildberries app, it removes the need for multiple physical phones. Assign a Russian mobile IP and it presents as a real Russian iPhone to Wildberries.

How do I set up a Russian residential proxy in BitBrowser?

Open your BitBrowser profile settings, go to the Proxy tab, select SOCKS5, paste in your IP:port:user:pass, and set the location tag to RU. Save and run a leak test at browserleaks.com before logging into any Wildberries seller account. The IP shown should be a Russian residential address, not a datacenter range.

Wrapping up

Wildberries' detection systems have gotten more precise over the past 18 months. Sellers getting caught aren't running 10 accounts behind a VPN (Wildberries handled that threat years ago). Sophisticated operators are losing accounts now because they missed one layer of isolation: a shared mobile device, a proxy pool that occasionally assigns duplicate IPs, or business registration data that creates a traceable link between otherwise technically separated accounts.

BitBrowser profiles with Russian residential IPs for the Partner Portal, BitCloudPhone iOS instances with Russian 4G IPs for the mobile app, and genuinely separate business registration data per account. This closes those gaps. Start with the free BitBrowser tier to validate the fingerprint isolation before investing in cloud phones, then scale once you've confirmed the setup passes fingerprint tests.

For a wider comparison of antidetect browsers beyond Wildberries use cases:

Best Anti-Detect Browsers in 2026: Why BitBrowser Took the Top Spot This Year - GoToProxy - Expert Proxy Service Reviews & Privacy Tools

Best Anti-Detect Browsers in 2026: Why BitBrowser Took the Top Spot This Year A hands-on ranking of the 5 anti-detect browsers we tested across 26,400 profiles,

gotoproxy.com