Proxies for Ad Verification
Ad verification is usually a browser task, not just an HTTP task. You often need to see what a real user in a specific market would see, confirm the landing page path, and repeat the check without contaminating every run with the same route identity.
Guardrail: keep the proxy endpoint copied from the portal and express country targeting or session stickiness through the username. Do not guess hostnames, ports, or undocumented geo parameters.
What ad verification needs from a proxy
- Browser-compatible proxy auth for Playwright or similar tooling.
- Country-level route selection so campaign checks line up with the intended market.
- Residential or mobile identity when ad platforms or publishers are sensitive to datacenter traffic.
- Short-lived sticky sessions so one verification run can load ads, redirects, and landing pages consistently.
Which NinjaProxy product fits and why
| Proxy setup | Best for | Why |
|---|---|---|
| Rotating residential with country targeting | Most ad verification and landing-page checks | Residential traffic is a strong default when you need a realistic market-specific browsing path. |
| Sticky residential session | Single-run redirect chains and landing-page validation | Sticky routing keeps the same identity stable while the ad click path unfolds. |
| Mobile | Campaigns where mobile-network presentation materially changes the result | Mobile traffic is useful when the campaign, publisher, or fraud checks behave differently on mobile networks. |
Working code example
This Playwright example verifies one country-targeted run using the currently documented rotating-gateway pattern: fixed endpoint, structured username controls, and proxy auth in the browser launch config.
import { chromium } from "playwright"
const browser = await chromium.launch({
proxy: {
server: "http://<ROTATING_HTTP_ENDPOINT>",
username: "<USERNAME>--session-ad-check-uk-01--duration-180--provider-res--geo-country-gb",
password: "<API_KEY>",
},
})
const page = await browser.newPage()
await page.goto("https://example.com/campaign-preview", { waitUntil: "networkidle" })
console.log(await page.title())
await page.screenshot({ path: "ad-verification-check.png", fullPage: true })
await browser.close()Common failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Wrong market experience | The route is not constrained to the intended country. | Add the appropriate --geo-country-xx control to the username and rerun the check. |
| Landing page redirects break mid-run | The route changed before the full click path completed. | Use a sticky session duration that covers the whole verification run. |
| No ad loads or instant challenges | The publisher or ad stack distrusts the current route type. | Move the workflow to residential or mobile traffic instead of datacenter. |
| Browser proxy auth errors | The endpoint or proxy credentials are malformed. | Re-copy the portal endpoint and keep the account API key in the proxy password field. |
Related docs
- Node.js integration for the current Playwright proxy launch pattern.
- Authentication for username + API key and rotating username controls.
- Rotating proxies for session controls and route overrides.
- Mobile proxies for workflows that need mobile-network presentation.
- Troubleshooting for auth, timeout, and block-response triage.