How to Get Around DataDome With Residential Proxies

DataDome scores three things at once: the address you come from, the device and browser you show, and how you behave. A residential proxy fixes the first. On October 22, 2026, we sent a plain request with a Chrome user agent from a home line to two sites that run DataDome. Both answered 403, and one of them put its verdict in a header: a risk score of 0.988 out of 1. The address was residential, and the score said bot anyway, because the client was curl.

This guide covers what DataDome checks and how to recognize each of its responses. It shows why datacenter addresses lose first and home addresses still lose without a browser. Then it covers where DataDome runs, which exit country to pick, and what a browser job costs in residential traffic. We sell residential proxies, so we have a stake in the first third of the problem. The other two thirds are yours, and they are most of this page.

Can residential proxies get past DataDome?

Not on their own. DataDome's docs describe four groups of detection models. The reputation group reads the address: "An IP address may have been recently associated with malicious activity or identified as a data center or residential proxy by DataDome machine learning models. Because IP addresses can be shared, DataDome combines IP reputation with other criteria for more precise detection."

Two things follow from that sentence. DataDome sets out to identify residential proxies too, so a home address lowers your risk without hiding you. And no address decides the verdict alone, which is why the browser and the behavior carry the rest of the weight.

How do you know a site runs DataDome?

The response tells you, if you read the headers instead of the status code. Our two plain requests from a home connection got these back (cookie values and client ids cut):

The signs to look for:

• x-datadome: protected on the response, with an x-datadome-cid client id and x-dd-b.
• A datadome cookie set with a lifetime of about a year (Max-Age 31,104,000 seconds at datadome.co and 31,536,000 at Adorama). DataDome's cookie documentation gives "1 year" as its expiration.
• A short page with the 403 that asks a browser to "enable JS and disable any ad blocker". On both of our requests it was the Device Check interstitial. Its script carries 'rt':'i' and loads i.js from ct.captcha-delivery.com, which curl never runs.
• Sometimes a score. Adorama returned X-DataDome-riskscore, the same 0.9880644696962504 on both of our requests four minutes apart.

The server name is no guide: datadome.co answered through Amazon CloudFront, and DataDome runs as a module inside many CDNs and web servers. DataDome guards its own site the same way. Our server's text reader fetches pages without running JavaScript. It got the same 403 page on all three DataDome pages it requested that day, including DataDome's own guide on how to bypass DataDome.

What DataDome checks

DataDome's documentation sorts its models into four groups. Signature-based models read "TLS fingerprints, browser fingerprints, and HTTP headers". Behavioral models flag "abnormal or aggressive behavior that is not associated with human activity". Reputational models read the address, as quoted above. Vulnerability-scanner models catch clients probing predictable paths. For a scraper, the first three collapse into three levers: your address, your fingerprint and your behavior.

TLS and HTTP/2 fingerprint

Before any page loads, your client completes a TLS handshake. The order of its cipher suites and extensions produces a fingerprint (JA3, or the newer JA4), and each browser version has a known one. Python's requests, Go's HTTP client and curl each have their own. So does the shape of their HTTP/2 frames: the SETTINGS values and pseudo-header order that Akamai's HTTP/2 fingerprinting research first mapped. A Chrome user agent on a non-Chrome handshake is a contradiction the model can see. Stack Overflow holds questions of exactly this shape, such as "Curl works but python requests doesnt" (2,610 views). The asker had the same address and headers, two clients and two verdicts. Our JA3 and JA4 explainer covers the formats.

Browser and device fingerprint

DataDome's JavaScript inspects the device: screen and resolution details, codecs, plugins, browser type and version, and hardware. It also reads the tells of automation, such as navigator.webdriver or a headless build. Its documentation describes the purpose of the Device Check as spotting "any type of automation frameworks, spoofed environments or programmatic access to the interfaces".

Behavior

Across a session, the behavioral models watch timing, navigation order and interaction. People are irregular. Scripts request pages in perfect sequence at even intervals and never move a pointer before they click.

What DataDome answers with

DataDome's documentation lists nine response types. Three of them are what a scraper meets, and a fourth is the one most guides miss.

Device Check, the interstitial

A page that runs JavaScript on your device "without the need for any user interaction" and collects hundreds of signals. Then it lets you through, escalates you to the Slider or blocks you. A client that never runs the script skips the check. DataDome's analytics call that outcome "Discarded" and count it among the requests blocked after Device Check. Both of our plain requests got this interstitial with their 403. That is the whole reason a plain HTTP client goes nowhere on a DataDome site. Once a real browser passes, DataDome "remembers the outcome and does not repeat the verification".

The Slider, DataDome's captcha

A puzzle where you drag a piece into a gap, with an audio challenge for accessibility. DataDome serves it when its score is unsure about you. Its response analytics list each step of the flow. One of the outcomes is "Blocked: DataDome detected an automated challenge solver or a challenge-solving service". Machine-solving the slider is something DataDome watches for by name.

Block

A block page with no challenge in it. The score was high enough to refuse the request outright, and nothing you send on that request changes it.

Custom: a 200 that may not be the real page

DataDome's Custom response lets the request through with a header tag so the site decides what to do with it. The documentation's own examples: "You might decide to obfuscate some data on the page or send alternate content." A scraper that checks only for a 200 can collect altered prices for weeks. Compare a sample of what your scraper receives with what a person sees in a browser. Repeat that check after every change to your setup.

The solver path

Answering these flows without a browser is what Hyper Solutions built its DataDome product for. Its product page names "Interstitial, slider and tags" as "DataDome's three main flows, and the API covers all three". The tags are the proactive part: telemetry events that, in Hyper Solutions' words, "keep trust high so challenges fire less often". You still make every request through your own proxies. The payload their API generates is bound to the exit address you declare, so it has to match the address you actually leave from. Our guide to proxy setup for antibot solver APIs covers that pairing, and what an antibot solver API is explains the category.

Their product page is candid about the limit of that approach. The quote is the whole argument for the proxy half: "Known datacenter and proxy ranges are penalized on sight, regardless of how clean your payload is." A perfect challenge answer does not survive a reputation verdict reached before the challenge was served.

Why datacenter IPs lose first, and why a home IP is not enough

A datacenter address loses on the first signal, before the fingerprint or the behavior is weighed. The reputation models know the hosting ranges, and almost nobody browses a store or a classifieds site from inside a server farm. That penalty is what a residential proxy removes.

What it does not remove shows up clearly in our own data. On August 24, 2026, we sent a plain request to 52 US retail storefronts from a home line and from a datacenter server. It carried a desktop Chrome user agent and no JavaScript. DataDome was the main defense on four of them: AutoZone, Anthropologie, Petco and Adorama. All four returned 403 from both addresses. Nine other stores, none of them DataDome stores, split their answers between the home and the datacenter request. Those two requests also came from two separate clients, and our controlled test at Cloudflare stores showed the client alone changing answers. The retail bot-defense study lists every site.

So with DataDome, the residential address is the price of entry, and the browser does the rest of the work. Our capture of October 22 shows the same thing from the other side. A home line, a Chrome user agent and a plain client got a risk score of 0.988.

Where DataDome runs, and which exit country to pick

DataDome is a specialist. Wappalyzer, which detects the technology behind websites, tracks 86,000 live websites running DataDome, against 200,000 running Akamai Bot Manager. Its count for Cloudflare Bot Management is 3,000,000. Wappalyzer does not say how it separates Cloudflare's paid product from the free bot features many Cloudflare sites run, so that figure stays out of the chart.

The sites matter more than the count. Among the most visited sites Wappalyzer lists for DataDome are idealista, Airbnb, Ecosia, Vinted, SeLoger and Etsy. Allegro, Leboncoin, SoundCloud, Immobiliare, The New York Times and TripAdvisor follow. The Stack Overflow questions about DataDome name the same kind of targets: Leboncoin (2,001 views), Vinted (847) and idealista (543).

That list also tells you where to exit from. About half of DataDome's sites are outside the United States:

A French classifieds site sees French visitors on French home connections. A request from a US address with a US-English browser asking for Leboncoin listings is an outlier before the fingerprint is read. Pick a residential exit in the country the site serves, and set the browser's language and time zone to match. Every one of our residential pools targets by country, and Residential Premium adds state, city and ISP targeting for sites that price by region.

Rotation: sticky inside a session, fresh between sessions

DataDome's cookie docs say the datadome cookie is "used for both server-side and client-side detection to assess the legitimacy of a request". It lives for a year and is encrypted. It does not say what the cookie encodes. Treat a change of address in the middle of a session as a risk. The cookie, the address and the fingerprint arrived together, and a session that splits them gives the scoring a reason to look again. Scrapfly's DataDome guide gives the same advice. The pattern that follows:

• One sticky exit per session. Hold one residential address for the length of a browsing flow, so the cookie, the address and the browser stay consistent. Our sticky and rotating sessions guide shows how sessions are set.
• Rotate between sessions. A new session gets a new address, a new browser context and a fresh cookie jar.

In Playwright, that means one context per session, one proxy login per context, and the context's cookies kept for the life of the session:

from playwright.sync_api import sync_playwright

# One sticky residential session per browser context.
# YOUR-LOGIN and YOUR-PASSWORD come from your dashboard; pick a sticky session there.
PROXY = {"server": "http://YOUR-GATEWAY:PORT", "username": "YOUR-LOGIN", "password": "YOUR-PASSWORD"}

with sync_playwright() as p:
    browser = p.chromium.launch(headless=False)
    context = browser.new_context(proxy=PROXY, locale="fr-FR", timezone_id="Europe/Paris")
    page = context.new_page()
    page.goto("https://www.example.fr/")          # the Device Check runs here, in a real browser
    page.wait_for_timeout(4000)                    # let the check finish and redirect
    page.goto("https://www.example.fr/search?q=velo")  # same exit, same cookie, same browser
    context.storage_state(path="session.json")     # keep the datadome cookie with this session
    browser.close()

Use HTTP proxy lines with Playwright: Chromium cannot log in to a SOCKS5 proxy with a username and password. The Playwright proxy guide covers the rest of the setup.

The half proxies cannot touch

Give DataDome a residential address and a default headless browser, and the other two signals still give you away.

Fingerprint. A raw HTTP library sends a handshake and headers that say automation no matter where the request comes from. A stock headless browser carries navigator.webdriver, a headless build string and missing device details. When the address says person and the fingerprint says script, the mismatch is itself a signal.

Behavior. Fifty pages in fifty seconds with no pointer movement and no variation reads as a script even with a perfect address and fingerprint. The behavioral models exist for exactly what a proxy cannot disguise: how you act once you are in.

What a DataDome job costs in residential traffic

Residential proxies bill per GB, and the browser DataDome requires is the expensive part. A plain client fetches the HTML and nothing else; a browser loads the whole page. At the HTTP Archive's October 2024 medians, that is 18 KB of HTML. A full desktop page weighs 2,652 KB and a mobile one 2,311 KB.

One GB carries about 377 full desktop page loads at that median. At our one-GB residential price of $0.50 per GB, 1,000 desktop pages come to about 2.65 GB, or $1.33, before caching. Images are the largest share, 1,054 KB of the median desktop page, so blocking them in the browser cuts the bill. It also makes the session look less like a person's, so test it on your target before you rely on it. Solver APIs trade the browser for request-sized traffic, which is why our headless browser bandwidth cost page compares the two.

A setup that gets through

None of this is a single trick. Getting past a real DataDome deployment means lining up all three signals:

1. Use a real browser. A patched automation browser or an anti-detect browser runs the Device Check script and produces a genuine fingerprint as a side effect. If you must stay on an HTTP client, the solver path above is the alternative to a browser.
2. Exit from a residential address in the site's country, with one sticky session per browsing flow and a new address between flows.
3. Make everything agree. The user agent, the TLS fingerprint, the language, the time zone and the exit country should describe one plausible person. A German address with a US-English browser and a Python handshake is three contradictions in one request.
4. Pace like a person. Randomized delays, real time on each page, no even intervals. Slow and unblocked beats fast and challenged.
5. Keep the session's cookies with its address, and start a clean context for the next one.
6. Check what you received. A 200 can carry the Custom response's alternate content, so compare samples against a real browser view.

Expect the Slider now and then even with all six in place. On a mature deployment it is the behavioral layer asking for more proof, and no proxy removes it.

Test before you scale

Before you point a real job at a DataDome site, confirm your exits are alive and residential. Our IP lookup shows the network behind an address, and the proxy checker confirms an exit answers from the country you expect. Then run one full session against one page and read the response headers. The x-datadome header tells you DataDome answered. Where a site exposes X-DataDome-riskscore, the number tells you how far you are from passing. One identity tested end to end tells you which of the three signals is failing. That is the only way to fix the right one.

When the wall is not your problem to solve

Before committing to a DataDome bypass, check whether someone has already done it for you. Our scraper APIs cover a set of platforms end to end and return parsed JSON from one call, anti-bot layer included. Detection changes then land on us instead of on your pipeline. Build the bypass for targets outside that list.

Limits of this guide

We ran no bypass tool, stealth browser or solver against DataDome, and we tested no proxy's success rate on it, ours included. Our requests were plain clients, so they show what fails, never what passes. The risk score comes from one site on one day, and the August test had four stores with DataDome as the main defense. Wappalyzer's counts are its detections on the sites it crawls, not DataDome's customer list. DataDome says its models are continuously updated, so check any setup against your target again before a large run. We will re-read the sources by January 22, 2027.

Sources

• DataDome documentation, read October 22, 2026: Threats Detection (updated August 17, 2026), Device Check (July 31, 2026), Analyze responses (August 18, 2026), Responses (May 26, 2026) and Cookies and stored data (October 14, 2026).
• Our requests: a plain curl request with a Chrome 141 user agent from a home line to datadome.co and adorama.com, October 22, 2026, 11:40 and 11:44 UTC. Our server's text reader on three datadome.co pages the same day. The retail bot-defense study of August 24, 2026.
• Wappalyzer's DataDome, PerimeterX and Kasada pages, read October 22, 2026. They give live website counts, the alternatives ranking, the most visited sites and the country split.
• HTTP Archive, Web Almanac 2024, Page Weight, medians of the October 2024 crawl.
• Stack Overflow questions tagged or titled with DataDome, read through the Stack Exchange API on October 22, 2026: views and dates as quoted.
• Hyper Solutions, DataDome solver product page, read October 22, 2026. It describes the three flows (interstitial, slider, tags) and states that datacenter and proxy ranges are penalized on sight regardless of payload quality. Provenance: they sell DataDome bypass tooling, so they have a commercial interest in the system reading as both formidable and beatable. The technical detail is specific and matches DataDome's own docs, which is why those claims stay on this page. Weigh the framing with that interest in mind. Not linked here.
• JA3 (Salesforce) and JA4 (FoxIO): the TLS ClientHello fingerprints signature models read.
• Akamai: Passive Fingerprinting of HTTP/2 Clients: the HTTP/2 fingerprint behind the shape of your frames.