The same proxy port can easily handle 50 parallel requests when parsing Wildberries — yet it can "burn out" after three simultaneous sessions in Facebook Ads Manager. The issue is not the quality of the proxy, but rather that different types of traffic create different loads on the IP. In this article, we will discuss how to calculate the real limit of threads for your task and avoid burning accounts or proxy pools due to a simple mathematical error.
What is a "thread" on a proxy port
A thread is a single parallel connection through a proxy at a specific moment in time. If you open 10 tabs in the anti-detect browser Dolphin Anty, and all of them are simultaneously loading Instagram through the same proxy port, that counts as 10 threads. If your Python parser sends 50 requests to Wildberries simultaneously through one IP, that counts as 50 threads.
It is important to understand: the number of threads is not about internet speed, but rather how many "simultaneous identities" the target site sees from one IP address at a given time. This is the number that anti-fraud systems of Facebook, Instagram, TikTok, and marketplace protections analyze when deciding whether to ban an IP or allow traffic.
For an arbitrage specialist and SMM expert, a thread usually corresponds to one open account at one moment in time. For a seller on a marketplace, a thread is a simultaneous HTTP request from a parser or price monitoring script. The difference in the nature of traffic determines how many threads can be safely held on one port.
What affects the thread limit
There is no universal number "proxy can handle N threads" — this is a myth that leads to bans. The real limit is determined by a combination of factors:
- Type of IP. Residential, mobile, and data center proxies are perceived differently by anti-fraud systems. A mobile IP is often a single real person, so even 2-3 parallel sessions with different cookies on it look suspicious.
- Target platform. Facebook and TikTok analyze behavioral patterns more strictly than most marketplaces. Wildberries and Ozon primarily look at the frequency of requests rather than the number of "identities".
- Type of request. A simple GET request to retrieve a product price is light load. A full session with authentication, media loading, and interaction with the interface is heavy.
- Proxy provider. The pool of IP addresses, speed of rotation, and technical capacity of the channel vary significantly among different providers.
- Purpose of traffic. Multi-accounting requires uniqueness of "identity" on the IP, while parsing requires just bandwidth without identity attachment.
This is why it is more accurate to speak not of the "proxy thread limit," but of the "thread limit for a specific task on a specific platform."
Calculation for multi-accounting (SMM and arbitration)
For multi-accounting, the golden rule is simple: one account — one IP — one session. Ideally, there should be exactly 1 active thread per proxy port when it comes to Facebook Ads, TikTok Ads, or Instagram accounts. The reason is not the technical limitations of the proxy, but that anti-fraud systems track the combination of IP + device fingerprint + behavior. If two accounts are simultaneously "logged in" on one IP through different tabs of an anti-detect browser, it significantly increases the risk of a chain ban — blocking the entire chain of accounts at once.
In practice, SMM agencies and arbitration teams use the following distribution logic:
| Task | Threads per port | Comment |
|---|---|---|
| Farming Facebook Ads accounts | 1 | Strictly 1 account per 1 stable IP, preferably a sticky session |
| Managing client Instagram accounts | 1 | Even a brief parallel session is caught as an anomaly |
| TikTok Ads with warming up | 1 | TikTok is particularly sensitive to sudden IP changes within one session |
| Mass account checking (without actions) | 2-3 | Permissible for light checking operations without risk to main activity |
For this scheme, IP stability is critical: if the proxy changes the address in the middle of a session, it breaks the link between the account and the "identity" and looks like device spoofing. Therefore, for multi-accounting, it is usually advisable to use residential proxies that allow one IP to be kept stable for a long time (sticky session from 10 minutes to several hours), and for particularly sensitive platforms — mobile proxies, which provide the most "human-like" traffic profile.
In anti-detect browsers like Dolphin Anty, AdsPower, Multilogin, or GoLogin, this is easily configured: in the profile of each account, a separate proxy port is specified, rather than a common pool for the entire browser. You open the profile settings → the "Proxy" section → insert separate data (IP, port, username, password) for each account → save. This physically excludes the situation where two accounts accidentally end up on the same IP simultaneously.
Calculation for marketplace parsing
With parsing Wildberries, Ozon, or Avito, the logic is the opposite. There is no concept of "identity" — there is the concept of "request frequency from one IP in a unit of time." Marketplace protections react not to the number of parallel threads as such, but to the speed of requests and behavior patterns (identical intervals, absence of pauses, identical headers).
The practical calculation is based on the formula:
In practice, for most major marketplaces, the safe corridor is 3-8 parallel threads per data center IP with pauses between requests of 1 to 3 seconds. If you exceed this value, the percentage of 403 and 429 responses (captcha, temporary request blocking) increases.
| Platform | Recommended threads per IP | Delay between requests |
|---|---|---|
| Wildberries (product cards) | 3-6 | 1-2 sec |
| Ozon (price monitoring) | 4-8 | 1-2 sec |
| Avito (ad parsing) | 2-4 | 2-4 sec |
| Yandex.Market | 3-5 | 1-3 sec |
If the task is to bypass a large volume of products quickly, the right approach is not to "overload" one IP beyond the limit, but to increase the pool of IP addresses and distribute the load. With 1000 products and a limit of 5 threads per IP with a delay of 1.5 seconds, one IP will handle about 200 requests in 5 minutes — whereas with a pool of 10 IPs, the same task will take about 30 seconds. For such tasks, in terms of speed/cost ratio, data center proxies are optimal — they are faster than residential proxies and sufficient for parsing public pages without authorization.
Residential vs mobile vs data center: thread table
Below is a summarized table that helps quickly estimate the safe limit of parallel threads depending on the type of proxy and the nature of the task. The numbers are approximate and depend on the specific platform but provide the correct order of magnitude for planning.
| Type of Proxy | Multi-accounting (threads/port) | Parsing (threads/port) | Feature |
|---|---|---|---|
| Residential Proxies | 1 | 3-5 | High trust from platforms, flexible rotation |
| Mobile Proxies | 1 | 2-3 | Maximum "human-like" behavior, but limited bandwidth |
| Data Center Proxies | not recommended for social networks | 5-10 | High speed and low cost, but easier to detect by social networks |
Note: Data center proxies do not technically prohibit opening multiple Instagram accounts, but such IPs are much more likely to be listed in social media detection databases as "server-based," which significantly increases the risk of a ban even with one thread. For social networks and advertising platforms, the type and reputation of the IP are more important than the number of threads.
Common mistakes in load calculation
In practice, most bans and blocks are related not to poor proxies, but to incorrect distribution of threads. Here are the most common mistakes:
- Common proxy pool for the entire anti-detect browser. If individual ports for each account are not specified in the profile settings, the system may accidentally route two profiles through the same IP.
- Ignoring delays in the parser. A script without pauses between requests creates a pattern that is immediately detected as automation, even if the thread is formally one.
- Mixing tasks on one port. Using one proxy simultaneously for warming up an account and for parsing the feed is a typical cause of sudden blocks.
- IP rotation in the middle of an active session. For multi-accounting, a sticky session is important: changing the IP while working with an account looks like account compromise.
- Estimating threads "by eye". Without considering the response time of the platform and its real limits, it is easy to either overload the IP or inefficiently use the proxy pool.
Checklist: how to calculate the required number of threads
Before launching a task — whether farming Facebook Ads accounts or monitoring prices on Wildberries — go through this short checklist:
- Determine the type of traffic: multi-accounting (1 account = 1 thread = 1 IP) or parsing (multiple requests on 1 IP are acceptable).
- Check if the platform has public request limits (rate limits) or documented blocking thresholds.
- For social networks and advertising accounts, choose residential or mobile IPs and strictly fix 1 thread per port.
- For parsing, calculate the formula "request limit ÷ response time" and add a buffer of 20-30% for load spikes.
- Manually set delays between requests, even if the parsing tool does not require it by default.
- Test on a small pool of IPs before scaling — this way, you will see the real blocking threshold of a specific platform.
- Keep logs of errors (403, 429, captchas) — an increase in these codes signals that the current thread limit has been exceeded.
Conclusion
There is no universal answer to the question "how many threads can a proxy port handle" — it all depends on the type of traffic. For multi-accounting in Facebook Ads, TikTok Ads, or Instagram, the rule is one: 1 account — 1 IP — 1 thread, and here the reputation of the IP is more important than its bandwidth. For parsing Wildberries, Ozon, or Avito, you can safely hold 3-8 parallel threads on one IP if the delays between requests are properly configured.
If your task is to farm and manage multiple accounts without the risk of a chain ban, pay attention to residential proxies with support for sticky sessions, and for particularly sensitive platforms — to mobile proxies. If the goal is fast and bulk parsing of prices and product cards, where speed is more important than the "humanity" of the IP, it is wiser to calculate the load on a pool of several data center proxies and distribute requests evenly, without exceeding the safe threshold of threads per address.