What cloacking method works best in 2026 ?

Hey guys,

I have implemented my cloacker (Traffic Armor) and I have a few possibilities. Which one works best in your experience ?

1. iFrame - Real site loads inside an iframe, URL stays on the safe page. Issue: many sites block iframe embedding, and interactions/links inside can break.

2. Insert HTML - TA fetches the HTML from the real site and injects it into the page. Works but relative paths (images, CSS) can break unless you add a <base href> tag on the destination site which is difficult if you want to send directly to an offer. You can still create your landing page

3. Redirect - obviously not recommended

4. Custom JS / Consent Prompt — Everyone sees the same page with a cookie consent popup. Filtered visitors dismiss it, allowed visitors get redirected on click.
-> That's the one I implemented for now

What are your recommandations guys ? What works best in 2026 ? Is there any other method that gives better result

Thank you but I don't need chatgpt answers. I need answer from real users with real experience in BH Ads

Custom JS / Consent Prompt is currently the most resilient method. Headless bots and network crawlers generally fail to simulate the genuine DOM interactions required to bypass the gate. For direct linking, upgrade the 'Insert HTML' approach to a full reverse proxy setup to dynamically rewrite relative asset paths and headers on the fly. iFrames and standard HTTP redirects trigger immediate algorithmic flags.

Thank you for your answer @HeroSMS

I'm using a cloaker that works with multiple layers :

When a visitor hits the tracking URL, first it checks a trust cookie if they're already verified it sends them straight to the money page.
Then server-side ML scoring kicks in (IP, UA, headers, known crawlers). Confirmed bots get the safe page served via reverse proxy no redirect at all, content is fetched and injected directly with a <base href> so everything renders clean.
No destination mismatch possible.

For real visitors it fires a client-side fingerprint (canvas, WebGL, automation flags) via sendBeacon before the redirect. Ambiguous scores get a captcha. And behavioral data feeds back into the ML model over time.

So yeah the consent prompt is a good idea but if a headless browser simulates a click you're exposed.
Having server-side detection independent from the client-side gate is what makes it solid imo.

Marocostyle said:

I'm using a cloaker that works with multiple layers :

When a visitor hits the tracking URL, first it checks a trust cookie if they're already verified it sends them straight to the money page.
Then server-side ML scoring kicks in (IP, UA, headers, known crawlers). Confirmed bots get the safe page served via reverse proxy no redirect at all, content is fetched and injected directly with a <base href> so everything renders clean.
No destination mismatch possible.

For real visitors it fires a client-side fingerprint (canvas, WebGL, automation flags) via sendBeacon before the redirect. Ambiguous scores get a captcha. And behavioral data feeds back into the ML model over time.

So yeah the consent prompt is a good idea but if a headless browser simulates a click you're exposed.
Having server-side detection independent from the client-side gate is what makes it solid imo.

Click to expand...

Thanks for the breakdown, really solid setup. The multi-layer approach makes a lot of sense, especially the server-side ML scoring before anything client-side
even fires.

You raise a good point about headless browsers simulating clicks on the consent prompt, that's definitely a gap in our current setup. Right now we're relying on
Traffic Armor which does server-side scoring (IP, UA, headers, known crawlers, company detection) but it's not custom ML I believe. The consent prompt is their recommended approach for the client-side gate.

A few questions if you don't mind:
- Is your setup fully custom-built or are you using a specific product/service as a base?
- For the reverse proxy safe page injection with <base href>, do you handle it at the nginx level or application level?
- How do you handle the behavioral feedback loop ? do you retrain the model manually or is it automated?

We're aware our setup isn't bulletproof but we need to start somewhere . Always looking to improve though. If there's a product or framework behind what you've
built I'd be interested to hear about it.

Vinalys said:

Thanks for the breakdown, really solid setup. The multi-layer approach makes a lot of sense, especially the server-side ML scoring before anything client-side
even fires.

You raise a good point about headless browsers simulating clicks on the consent prompt, that's definitely a gap in our current setup. Right now we're relying on
Traffic Armor which does server-side scoring (IP, UA, headers, known crawlers, company detection) but it's not custom ML I believe. The consent prompt is their recommended approach for the client-side gate.

A few questions if you don't mind:
- Is your setup fully custom-built or are you using a specific product/service as a base?
- For the reverse proxy safe page injection with <base href>, do you handle it at the nginx level or application level?
- How do you handle the behavioral feedback loop ? do you retrain the model manually or is it automated?

We're aware our setup isn't bulletproof but we need to start somewhere . Always looking to improve though. If there's a product or framework behind what you've
built I'd be interested to hear about it.

Click to expand...

Fully custom-built, no third party service behind it.

For the reverse proxy it's handled at the application level (Node.js), not nginx. When a confirmed bot hits the tracking endpoint, the server fetches the safe page content directly, injects the <base href> tag into the <head> and returns it as the response. So the bot never sees a redirect, it just gets HTML served from our domain.

For the behavioral feedback loop it's automated. Each visit generates a behavioral signature (timing, mouse patterns, fingerprint flags) that gets stored and used to update the scoring weights over time. No manual retraining needed, it adjusts as it sees more traffic.

Traffic Armor's server-side scoring is decent but you're right that it's not custom ML it's mostly rule-based. The gap is exactly what you identified: once a sophisticated bot passes the rules, the consent prompt is the only gate left and that's not hard to bypass if someone targets you specifically.

Just fetch and inject with adjusted base href, less issues if you handle resources right