You start monitoring prices on Ozon or a listing parser ā and within minutes you receive a 403 or a CAPTCHA. The reason is almost always the same: the site is protected by DataDome. This is one of the most advanced anti-bot services on the market, and it can block not only simple scripts but also requests through regular data center proxies. In this article, we will explore how DataDome works, what it analyzes, and why the right choice of proxies is key to stable operation.
What is DataDome and where is it used
DataDome is a commercial anti-bot service that websites use to protect against automated requests. It is used by large retailers, marketplaces, news aggregators, booking services, and fintech platforms. According to the company, DataDome processes over 5 trillion requests per month and protects thousands of websites worldwide.
Unlike simple solutions like Cloudflare Bot Management at the entry level, DataDome operates as a separate layer between the user's request and the server. Each HTTP request to a protected site first passes through DataDome's infrastructure, where a decision is made in milliseconds: to allow, show a CAPTCHA, or block.
If you are monitoring competitors' prices on marketplaces, collecting product data, scraping listings, or conducting automated ad testing from different regions ā there is a high chance you have already encountered DataDome. Here are typical signs:
- A 403 Forbidden or 429 Too Many Requests response after several requests
- Redirect to a CAPTCHA page (usually Slider or FunCaptcha)
- Empty response or a page with the message "Access Denied"
- The site works in the browser, but errors occur when requests are made through a script or parser
- Blocking even when changing IP if other parameters remain unchanged
Among the well-known sites using DataDome are: Reddit, Rakuten, Foot Locker, TripAdvisor, Leboncoin, and many others. In the Russian segment, DataDome is encountered less frequently, but it is used by some large e-commerce platforms and aggregators.
How DataDome identifies bots: what it analyzes
Understanding DataDome's logic means understanding why half of the "solutions" from the internet do not work. The system uses multi-level analysis, and blocking occurs not based on a single criterion, but on a combination of signals. Let's break down each level.
1. IP reputation and ASN
The first thing DataDome checks is the reputation of the IP address and the autonomous system (ASN) it belongs to. If the IP is registered to a data center (Amazon AWS, DigitalOcean, OVH, Hetzner, etc.) ā this is an immediate red flag. DataDome maintains its own databases of "dirty" IPs and exchanges data with other anti-bot services. An IP that has already been used to scrape another protected site will get blocked faster.
2. Behavioral patterns
DataDome analyzes not only the fact of the request but also its behavior over time. Too uniform intervals between requests are a sign of a bot. Accessing only certain endpoints (for example, only product pages) without visiting the homepage is suspicious. The absence of loading CSS, fonts, images when requesting HTML is also a signal.
3. HTTP headers and their order
A real browser sends headers in a strictly defined order and set. DataDome checks: does the User-Agent match a real browser fingerprint? Is there a sec-ch-ua header? Is the Accept-Language correct? If you simply substitute a User-Agent string but do not reproduce the full set of headers ā the system sees it.
4. JavaScript challenge and browser fingerprint
DataDome injects JavaScript code into the page that collects a "fingerprint" of the browser: screen resolution, list of fonts, WebGL rendering, Canvas fingerprint, presence of plugins, device type. If JavaScript does not execute (as with regular HTTP requests via requests or curl) ā DataDome records this and blocks. This is why simple parsers without JS rendering do not work on protected sites.
5. Cookies and session tokens
DataDome sets its own cookies (datadome) on the first visit. On subsequent requests, the presence and validity of this cookie are checked. If the parser does not save cookies between requests or starts a new session each time ā this is another signal of automation.
Conclusion: why DataDome is more complex than regular blocks
DataDome does not block based on a single parameter ā it calculates a "risk score" based on dozens of signals simultaneously. You can bypass the IP filter but fail at the JS challenge. You can set the correct headers but get banned due to behavioral patterns. Effective bypass requires a comprehensive approach.
Why data center proxies do not work with DataDome
This is the most common question from those encountering DataDome for the first time: "I bought a proxy, connected it ā and it still blocks. Why?" The answer lies in the type of proxy.
Data center proxies are IP addresses registered to commercial hosting and server farms. DataDome (like most modern anti-bot systems) maintains up-to-date databases of all known data center ASNs. When a request comes from such an IP ā it automatically receives a higher level of suspicion even before behavior analysis.
The problem is not only in the IP reputation. Data center proxies are often used by thousands of users simultaneously, creating an abnormal traffic pattern from one address. DataDome sees this and blocks the entire pool of the provider's IPs.
| Proxy Type | Chance to pass DataDome | Why |
|---|---|---|
| Data center (shared) | Very low | Data center ASN, "dirty" IPs |
| Data center (dedicated) | Low | Still server ASN |
| Residential (static) | Medium | Real ISP, but one IP = suspicious |
| Residential (rotating) | High | Real home IPs, rotation |
| Mobile (4G/5G) | Maximum | Mobile operators, NAT, high trust |
The conclusion is simple: to bypass DataDome, you need IPs with high reputation ā those that look like real users. This is why residential proxies have become the standard for working with protected sites.
Residential vs mobile proxies: which to choose for DataDome
When it is clear that data center proxies are not suitable, the next question arises: residential or mobile? Each type has its strengths, and the choice depends on the task.
Residential proxies
Residential proxies use IP addresses of real home users connected through internet service providers (Rostelecom, MTS, Comcast, etc.). From DataDome's perspective ā this is an ordinary person sitting at home with a laptop. Key advantages include:
- A huge pool of IPs ā millions of addresses from different countries and cities
- Rotation: each request can come from a new IP
- Geo-targeting: you can choose a specific country, region, or city
- High reputation with anti-bot systems
- Suitable for mass scraping and price monitoring
The limitation of residential proxies is speed. They are slower than data center proxies, which is critical when scraping thousands of pages per minute. But for working with DataDome, this is a compromise worth accepting.
Mobile proxies
Mobile proxies operate through SIM cards from mobile operators (4G/5G). This is the most "trusted" type of traffic from the perspective of any anti-bot system. The reason: mobile operators use NAT ā behind one IP can hide hundreds of real users. DataDome knows this and cannot block a mobile IP without risking cutting off real customers.
- Maximum trust level with anti-bot systems
- Real ASNs of mobile operators
- IP change with each reconnection (or on a timer)
- Ideal for tasks where minimal risk of blocking is required
The downside of mobile proxies is the price and limited pool of IPs compared to residential ones. They are excellent for tasks where the reliability of each request is important, rather than mass volume.
When to choose what:
- Price monitoring, catalog scraping ā residential rotating proxies
- Working with accounts, authorization ā mobile or static residential
- Ad testing from different regions ā residential with geo-targeting
- High-load scraping with anti-bot ā rotating residential
Practical methods to bypass DataDome
The right type of proxy is a necessary but not sufficient condition. DataDome analyzes dozens of parameters, and proxies only cover one of them ā IP reputation. Here is the complete set of methods that work in conjunction.
Method 1: Correct HTTP headers
DataDome checks the full set of headers sent by the browser. The minimum set to imitate Chrome on Windows looks like this: correct User-Agent, headers sec-ch-ua, sec-fetch-site, sec-fetch-mode, correct Accept-Language corresponding to the proxy's geolocation. A mismatch between the language and the country of the IP is a common reason for blocks.
Method 2: JavaScript rendering
If the site is protected by DataDome ā simple HTTP requests via curl or requests will not pass the JS challenge. You need a tool that actually executes JavaScript: a headless browser (Playwright, Puppeteer) or a full browser through anti-detect. For business tasks without code, the optimal option is anti-detect browsers: Dolphin Anty, AdsPower, GoLogin. They run real Chromium with a unique fingerprint and support proxy connections.
Method 3: IP and session rotation
DataDome remembers "bad" sessions. If an IP gets blocked ā change it immediately, do not attempt to repeat requests from the same address. When using rotating residential proxies, each request or session gets a new IP. Important: change not only the IP but also the cookie session ā otherwise, DataDome will link the new IP to the old blocked session.
Method 4: Simulating human behavior
DataDome's behavioral analysis tracks request patterns. Add random delays between requests (from 2 to 8 seconds), simulate navigation: first the homepage, then a category, then a product. Do not scrape only target pages directly. Load static resources (CSS, images) ā or at least simulate their requests.
Method 5: Geo-matching
This is often ignored. If you are scraping a Russian site but using an American IP ā DataDome sees this. Use proxies from the same country as the target site. Moreover: set the Accept-Language and browser timezone according to the proxy's geolocation.
Method 6: Managing DataDome cookies
The cookie datadome is a token that DataDome issues to "good" visitors. If you successfully pass the check, save this cookie and use it in subsequent requests. Do not reset cookies unnecessarily. When changing IPs, it is better to start a new session with a fresh token rather than carrying over the old one.
Configuring proxies to bypass DataDome: step by step
Let's break down practical configuration for two scenarios: working through an anti-detect browser (for business tasks without code) and configuration for scraping.
Scenario A: Anti-detect browser (Dolphin Anty / AdsPower / GoLogin)
This method is suitable for those working with accounts, testing ads from different regions, or manually browsing protected sites.
- Create a new browser profile in Dolphin Anty or AdsPower. Each profile is a separate "digital fingerprint".
- In the profile settings, find the "Proxy" section. Choose the type: SOCKS5 (preferable) or HTTP.
- Enter the proxy details: host, port, username, password. For rotating residential proxies, use the gateway address of the provider.
- Check the geolocation: click "Check proxy" ā the browser will show the country and city. Ensure they match the target site.
- Set the browser language according to the proxy's geolocation. If the proxy is from Germany ā set it to de-DE.
- Set the correct User-Agent: choose the current Chrome on Windows or macOS ā these are the most common configurations.
- Launch the profile and go to the target site. Do not open the desired page immediately ā first visit the homepage.
Scenario B: Scraping through Playwright/Puppeteer
For automated data collection from sites protected by DataDome, a headless browser with proxy support and correct fingerprint settings is needed.
# Playwright + residential proxies (Python)
# Key parameters to bypass DataDome:
browser = playwright.chromium.launch(
proxy={
"server": "http://gate.proxyprovider.com:8000",
"username": "user",
"password": "pass"
}
)
context = browser.new_context(
# Real User-Agent of the current Chrome
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
# Geolocation matches the country of the proxy
locale="ru-RU",
timezone_id="Europe/Moscow",
# Real screen resolution
viewport={"width": 1920, "height": 1080}
)
# Random delay between actions
import time, random
time.sleep(random.uniform(2, 5))
Additionally: use libraries to mask headless mode (playwright-stealth, puppeteer-extra-plugin-stealth). DataDome can detect headless Chrome based on several technical signs, and these plugins help to hide them.
Proxy configuration checklist for DataDome:
- ā Proxy type: residential or mobile (not data center)
- ā Protocol: SOCKS5 (preferable) or HTTPS
- ā Proxy geolocation matches the country of the site
- ā Accept-Language and timezone correspond to the proxy's country
- ā JavaScript is executed (headless browser or anti-detect)
- ā Cookies are saved between requests
- ā Delays between requests: 2-8 seconds
- ā IP rotation with each new session
Common mistakes that still get blocked by DataDome
Even with the right proxies, many continue to receive blocks. Here are the most common reasons and how to fix them.
Mistake 1: Mismatch between geolocation and language
You connected a French proxy, but the browser sends Accept-Language: en-US. DataDome sees: IP from France, but the language is English ā atypical behavior. Solution: always synchronize the language, timezone, and locale with the proxy's geolocation.
Mistake 2: Reusing a blocked IP
Got a 403? Do not attempt to repeat the request from the same IP again. DataDome remembers "bad" addresses and will block them instantly. At the first sign of blocking ā immediately change the IP and clear the cookies.
Mistake 3: Too high request frequency
Even with residential proxies, you cannot make requests every 100 milliseconds. A real user reads a page for 10-30 seconds. DataDome analyzes navigation speed. The optimal mode: 1-3 pages per minute from one IP, after 10-15 requests ā change the IP.
Mistake 4: Using outdated User-Agent
User-Agent Chrome 89 in 2024 ā this is a red flag. DataDome knows which browser versions are current. Use only fresh versions: Chrome 120+, Firefox 120+. Update the User-Agent regularly.
Mistake 5: Ignoring the JS challenge
The most critical mistake is trying to scrape a DataDome-protected site through regular HTTP requests without rendering JavaScript. DataDome injects JS code into the page that must execute and return a token. Without this token, subsequent requests will be blocked. The solution is only a headless browser or anti-detect browser.
Mistake 6: One IP for many parallel threads
If you are running 10 parallel scraping threads through one IP ā this is instantly detected. DataDome sees an abnormal number of requests from one address. The rule is: one IP = one thread = one session. For parallel scraping, you need a pool of IPs with rotation.
| Error | Symptom | Solution |
|---|---|---|
| Data center IP | 403 from the first request | Switch to residential/mobile |
| No JS rendering | CAPTCHA or empty response | Use a headless browser |
| High request frequency | 429 after 5-10 requests | Add delays, rotate IPs |
| Geo/language mismatch | Block after 2-3 requests | Synchronize locale and IP |
| Old User-Agent | CAPTCHA on every login | Update to the current version of Chrome |
Conclusion
DataDome is a serious system that cannot be bypassed simply by changing IPs. It simultaneously analyzes the reputation of the address, user behavior, browser fingerprint, request headers, and cookies. This is why data center proxies do not work here, and "just changing the User-Agent" is not enough.
A working combination to bypass DataDome looks like this: high-quality residential or mobile proxies + headless browser or anti-detect (Dolphin Anty, AdsPower, GoLogin) + correct headers with geo-matching + human-like delays + cookie management. Each element is important, and skipping any of them reduces the chances of success.
If you are engaged in price monitoring, catalog scraping, or ad testing from different regions on sites protected by DataDome, we recommend starting with residential proxies ā they provide the optimal balance between IP reputation, address pool volume, and cost. For tasks where maximum reliability of each request and minimal risk of blocking are critical, consider mobile proxies ā their traffic is rarely blocked by DataDome.
```