Common Issues

By far the most common report, and it's rarely a problem with the filter itself. Check these in order:

1. You tested by pasting the URL directly, not through a real ad click. If the stream has Require Click ID turned on, a visit with no click ID from a recognized ad platform is treated the same as bot/direct traffic and never reaches your money page at all — typing your tracking link into a new tab, or opening an old bookmark, doesn't carry one. Test with a real ad click, or add your platform's own click-ID parameter to the URL yourself: gclid (Google — or gbraid/wbraid for app-to-web/web-to-app clicks), fbclid (Meta), ttclid (TikTok), msclkid (Microsoft/Bing), yclid (Yandex), twclid (X/Twitter), ScCid (Snapchat), epik (Pinterest), li_fat_id (LinkedIn), or tblci (Taboola).
2. The stream is in Review mode. Review mode sends every visitor to your safe page by design — including entries on your own whitelist — for the window while an ad platform is reviewing your campaign. Open the stream and check its Filtering Mode; switch it back to Filter (or Moderation) once the review period is over.
3. Your own destination page is down. This has happened: a customer's destination domain expired and stopped resolving, and every visitor kept ending up somewhere that wasn't the real offer — which looks identical to "cloaking is broken" from the outside, when the actual problem has nothing to do with Cloaking X. Open your destination URL directly in a browser, with no stream or tracking link involved — if it doesn't load there either, that's the problem, and it needs to be fixed on your hosting/domain side first.
4. A country, device, or OS filter is excluding you. Open the stream and check its Allowed Countries / OS / Devices lists — once any of the three has entries, a visitor who doesn't match is blocked immediately. Add your own location/device, or test from one that's already allowed.

Domain-locked VSL video players (VTURB, ConverteAI, and similar) refuse to play once the page they're embedded on is served from a different hostname than the one they were built for — a limitation of the player itself, not a filter bug. This happens under both proxy and mirror delivery.

Only iframe delivery loads these players correctly, since the destination keeps running under its own real origin inside the frame. Open the stream and switch Money Page Delivery to iframe.

Some destination pages are more fragile under proxy delivery than others:

• Single-page apps built with React, Vue, Next.js, Nuxt, or Angular try to take control of the browser's address bar the moment they load, which can break when the page is actually running under a different domain — see My SPA destination breaks under proxy delivery in the FAQ for the full detail.
• Interactive elements that submit in the background (contact forms, cart/checkout, live search) — commonly built with page builders and form plugins like Elementor, Contact Form 7, WPForms, and WooCommerce — can also stop responding under proxy, since those calls are written to talk back to the page's real origin.

Plain, static/classic pages (no JavaScript framework, no AJAX-driven forms) are unaffected and keep working normally under proxy — this is specific to pages that lean on client-side JavaScript talking back to their own origin. Be aware going in: proxy is the simplest and most stable delivery method, but it isn't the right choice for every destination.

Every block gets a reason code, visible per-click in Reports and Live — see the Block Reason Reference (sign-in required) for what each one means and how to read it.

Before assuming something broke, rule out the two most common testing mistakes:

• Testing from your own network while your IP is whitelisted. A whitelisted visitor bypasses detection entirely, so your own test passing (or failing, if the stream is in Review mode, which overrides even a whitelisted IP) proves nothing about how a bot or a reviewer is actually treated. Check your entries on the Whitelist tab first.
• Testing from a VPN or proxy. That's exactly the traffic category this product exists to catch — seeing your own VPN test blocked is expected, not a bug.

If a spike is real once those are ruled out, check Reports for which specific reason codes are firing and go from there — a sudden change usually traces back to a stream setting (threshold, allow-lists) that changed, or a real shift in the traffic hitting that stream.

This is almost always an installation issue rather than a filtering decision. In rough order of likelihood:

• The filter file isn't actually included/loaded on the page at all.
• It's installed on the wrong page — it has to be the exact page your ad points to, not just somewhere on the site.
• A page cache (a caching plugin, or a CDN in front of the site) is serving a stale, cached copy of the page from before you added the filter, so the filter code never actually runs for a real visitor.
• The wrong stream's filter file is installed — every stream's downloaded file is unique to that stream, so a file downloaded for a different stream will never log against this one. Re-download the file from Integration with this exact stream selected.

If a request does appear in Live but the click still isn't showing up as expected in Reports, a stream setting may be intentionally skipping the log — see No clicks appearing in Reports in the FAQ.

Usually a stale sign-in in that browser. Sign out and sign back in.

To confirm it's browser-side rather than account-side, open the dashboard in a private/incognito window — if it loads correctly there, the problem is local to that browser (cached session or cookies), not your account.