What's the difference between server-side and client-side cloaking?

Server-side cloaking makes the routing decision before the page is ever rendered — the user's browser only ever sees one page. Client-side cloaking serves both versions and uses JavaScript to swap content in the browser. Server-side is harder to detect statically but loses signals that only show up in real browser behavior. Most modern stacks run server-side as the default and use client-side checks as a second layer.

Which signal carries the most weight in 2026?

IP-range checks still catch the majority of reviewer traffic — every major platform's automated review crawlers fingerprint to known data-center ranges. But operators who survive the longest weight behavior signals (mouse movement, scroll depth, dwell time before a click) higher than IP alone, because that's where the platforms have invested in 2025-2026 to bypass naive IP checks.

How long does a single cloaked account typically last?

It varies by platform and creative, but a well-warmed Meta account on a clean cloaker, with disciplined creative rotation and proper spending cadence, averages 30-90 days before disablement in our cohort. TikTok runs shorter at 14-45 days. Google is the longest at 90-180 days when the setup is clean. Operators who lose accounts faster are usually getting caught on creative or payment-method signals, not the cloaker itself.

Can I run a single cloaker across multiple platforms?

Technically yes; tactically no. Each platform has different reviewer IP ranges, different headless-browser fingerprints, different behavioral profiles, and different post-click validation. A cloaker that survives on Meta will pass-through scenarios that get caught on TikTok and vice versa. The operators who scale at all three keep per-platform routing rules in the same tool, not a generic single rule.

Do I need a paid cloaker if I'm under $1k/day?

For most operators, yes — but the gap is smaller than you'd think. The expensive part of cloaking is the ongoing rule updates and the IP-range freshness. A self-hosted basic cloaker handles the first $500/day of any vertical fine; what you're paying the SaaS cloakers for is the rule-update cadence as platforms change their detection. If you're spending under $300/day on a single offer, self-hosted is defensible. Above that, the time you spend on rule updates is more expensive than the SaaS subscription.

Ad Cloaking: Technical Deep Dive

Sat May 16 2026 · cloaking · by Arthur B.

A reviewer comes in from a Meta IP block in Dublin. Headless Chrome, fresh session, the click ID on the URL doesn’t match anything in your platform records. Your cloaker has eleven milliseconds to decide whether to serve the whitepage or the offer. Get it wrong and you lose the account, the campaign, and whatever creative inventory was rotating through that ad set.

That’s the layer this post lives in. Not “what is cloaking” — you already know. The real question is what the working stack looks like in 2026 and why most operators get the routing wrong before they get anything else wrong.

The three layers operators actually run

Forget the marketing pages. A modern cloaker is three components stacked, each catching what the previous layer missed.

Layer 1 — Edge routing. Sits before your origin server, usually as a CDN worker or a reverse proxy. Inspects request headers, IP, and referrer. Makes the first cut: anything that looks like a known reviewer crawler IP, a known data-center range, or a request with no platform click-ID gets routed to the whitepage immediately. The smart edge layer also does ASN lookups — DigitalOcean, AWS, GCP, Linode IPs are 95%+ automation, period.

Layer 2 — Server-side fingerprinting. Runs at your origin. Looks at the full request: TLS fingerprint (JA3/JA4), header order, header capitalization quirks, missing headers that real browsers always send. Real Chrome has a specific TLS handshake; headless Chrome that hasn’t been carefully patched leaves a different one. This layer catches automation that defeated Layer 1 via residential-proxy rotation.

Layer 3 — Client-side behavioral. JavaScript on the served page that watches what the visitor does in the first 2-5 seconds. Mouse movement entropy, scroll behavior, time to first interaction, viewport-size patterns. Real users move the mouse before they click. Reviewers using headless tools that simulate interaction still produce telltale patterns — mouse movements that are too linear, too fast, or that happen before the page is fully painted.

The reason is that platforms have invested heavily in 2025-2026 in bypassing Layer 1 specifically — they’re routing reviewers through residential proxies and rotating IPs constantly. Layer 1 alone catches less than half of modern review traffic.

How signal scoring works in practice

Each layer assigns a score. Total score above a threshold → whitepage. Below → offer. The trick is calibrating the threshold per offer and per platform, because the cost of a false positive (sending a real buyer to the whitepage) and a false negative (sending a reviewer to the offer) are wildly different by vertical.

IP / ASN Score

37%

Behavioral (Layer 3)

28%

TLS / Header Fingerprint

22%

Referrer / Click-ID

13%

Signal weight distribution — balanced 3-layer stack, 2026 cohort.

The signal weights that actually work in 2026, from operators we’ve worked with:

IP / ASN score: 35-40% weight. Down from 60-70% three years ago because platforms got serious about proxying reviewers.
TLS / header fingerprint: 20-25%. Up sharply since 2024 — this is where headless detection has matured.
Behavioral signals (Layer 3): 25-30%. Cheaper for real users to pass because real browsers produce them automatically; expensive for automation to fake.
Referrer / click-ID validation: 10-15%. Catches direct-load scrapers and competitor reconnaissance more than it catches platform reviewers, but cheap to implement.

The mistake new operators make is weighting IP too high. They build a cloaker that’s 80% IP-driven, it survives the first wave of review, then dies after week 3 when the platform starts routing reviewers through residential ranges.

A minimal scoring config that produces a balanced threshold looks like this:

# Illustrative only — real thresholds are tuned per offer + platform
signals:
  ip_asn:      weight: 0.37  threshold: 0.6   # datacenter or known review range
  tls_ja4:     weight: 0.22  threshold: 0.5   # headless TLS fingerprint match
  behavioral:  weight: 0.28  threshold: 0.4   # low entropy = automation
  referrer:    weight: 0.13  threshold: 0.8   # direct load = no platform click-ID

routing:
  whitepage_score_min: 0.55   # total weighted score above this → whitepage
  false_positive_cost: high   # real buyers routed to whitepage = lost revenue

What 2026 detection actually looks like

A few things changed between 2023 and now. The operators who haven’t updated their stack are dying faster than they realize.

Reviewers come from residential IPs. All three major platforms (Meta, TikTok, Google) now route a portion of automated review traffic through residential-proxy providers. IP allowlists that catch only data-center ranges miss them entirely.

Headless browsers got better at faking human behavior. Puppeteer + scripted mouse movement, scripted scroll, scripted dwell-time. Still detectable — the entropy is wrong — but the naive “no mouse move = bot” check from 2022 catches almost nothing now.

Platforms rotate review fingerprints. Each round of TLS fingerprints gets patched into reviewer browsers within a quarter. The cloaker that hand-coded a JA3 allowlist in 2023 is leaking everything by 2026 unless the rule set updates monthly.

Post-payment validation. Some platforms (Meta specifically) now do a second-pass review after the first conversion event fires from a new account. Your cloaker survived launch and the account ran for 14 days clean? Great — but the moment you record a sale, the system re-checks the landing page. Operators who don’t account for this lose accounts on day 15.

Competitor reporting. Other affiliates report your ads to Meta to take competition off the auction. This isn’t a detection technique — it’s a human reviewer being directed at your URL by a hostile party. No cloaker survives a manual review from a logged-in human who knows what to look for.

The mistakes that burn the stack

These are the ones we see operators repeat:

Running the same whitepage on 10 accounts. Platforms cross-reference URLs across accounts. If account 7 catches a manual review, your whitepage gets flagged, and accounts 1-6 (running the same URL) get caught in the sweep. Different whitepages per account, hosted on different domains, served by different CDNs.

Skipping Layer 2 because it’s annoying. Server-side TLS fingerprint analysis requires either a self-hosted setup or a SaaS that does it well — Cloudflare alone doesn’t expose enough. Operators who skip it run a 2-layer stack that catches 60% less than a 3-layer.

Static rules forever. Platform fingerprints rotate. Either subscribe to a SaaS that updates rules monthly, or budget time every two weeks to patch your own.

Letting one ban poison the rest of the stack. When an account dies, operators rush to launch a new one on the same payment method, same BM, same creative, same IP block. The platform’s bans propagate by linked-entity signal. Clean separation between accounts — different payment methods, different BMs, different ad creative variants, different residential IPs to manage them from — is the difference between a 2-account loss and a 12-account cascade.

Optimizing the blackpage and ignoring the whitepage. The whitepage gets all the platform attention and zero operator attention. Operators spend 8 hours A/B testing the offer page and 20 minutes building a placeholder whitepage that looks obviously fake. Reviewers look at whitepages, not blackpages. Spend the time.

The questions to ask before paying a cloaker SaaS

Most cloaker vendors are mid. A handful are real. The screen before you commit to a monthly fee:

| Question | What a real answer sounds like | Red flag | |---|---|---| | Rule-update cadence? | “Monthly updates, public changelog + operator Discord” | “We update regularly” | | Layer 2 fingerprinting native? | “Yes — JA4 + header-order scoring built in” | “You can add it with a plugin” | | False-positive handling? | “Confidence threshold, configurable per offer” | No mention of false positives | | Post-ban recovery visibility? | “Logs show which signal triggered each route decision” | “Check your dashboard” | | Per-platform rule trees? | “Meta, TikTok, Google each have separate profiles” | “One ruleset covers all platforms” |

If the vendor can’t give a real answer to those five in a single call, find a different one.

Where to go from here

If this post hit the right depth: the Cloaking Guide is the structured operational reference — tool comparisons by category, whitepage build-out templates, full post-ban recovery walkthroughs, and the per-platform rule-tree examples this post didn’t have room for.

For the broader operation around the cloaker — scaling the paid-ads pipeline, structuring ad-account infrastructure, surviving the months-after-launch when the platform’s enforcement waves hit — the rest of the cloaking pillar covers it. The cloaker is a means to an end; the end is the operation that scales the offers it enables.

If you’re already running a stack and just want a sanity check before your next launch, the cohort is where operators trade rule-updates and post-ban diagnoses in real time. Most of what works in this space gets passed peer-to-peer faster than it ever shows up in public posts. That’s still true in 2026.