Proxies for Ad Verification: What to Check Before You Buy

Residential exits pinned to the campaign's city, held for the whole check, under a real browser. Where datacenter fits, and what to ask any provider.

What an ad-verification proxy has to do

For ad verification, buy residential exits in the campaign's market, pinned to the city the campaign bought, held for the whole check and run under a real browser. Datacenter addresses fit only the jobs that never need to pass as the audience, and carrier-targeted buys need mobile exits, a category Node4 does not sell. This page explains why, then lists what to ask any provider before you buy. If you only need the type decision, proxies for ad verification: which type to use is the shorter answer.

The reason is who judges the probe: not you, but the ad server. An ad server is a decision engine. Every impression is an auction that evaluates the viewer's location, device and traffic quality before choosing what to serve, and the whole industry spends heavily on filtering non-human and hosting-range traffic out of paid impressions, because advertisers refuse to pay for bots. A verification probe is trying to observe that decision without changing it. So the proxy that works for ad verification is the one the decision engine treats as a member of the audience, and everything else is secondary. Five properties follow:

1. It arrives with the network reputation of an ordinary household, so the traffic-quality filter lets the auction run.
2. It is pinned to the geography the campaign bought, at the granularity it was bought at: a city buy needs a city pin, not a country.
3. It holds one address across the whole chain, from page load through the ad request to the landing-page click, because a mid-flight address change is itself a fraud signal.
4. It works underneath a real browser, since ad slots are assembled by JavaScript and do not exist in the raw HTML a plain client fetches.
5. Its provider can tell you where the addresses come from, because your evidence will be challenged, and "we do not know how our supplier sourced that exit" is not an answer a vendor's lawyer will accept.

Measured against those five, three options are worth describing, and one of the three is a category we do not sell.

1. Residential proxies in the campaign's market

Residential exits win on the first property outright, and the first property is the one that decides whether you get a measurement at all. Traffic from consumer broadband is the audience, so a probe from it is not what the filters are looking for. Country and city pinning give you the second property, session pinning gives you the third, and both ride in the gateway username as segments described in residential targeting. A probe verifying a Milan buy looks like a viewer in Milan, holds that viewer's address for the length of the check, and starts the next check as a different person.

Where residential loses: the exits we sell are partner capacity, not addresses we own. Coverage is therefore whatever the partner network can place an exit in today, city by city, and it changes; the per-market pages, Italy and the United Kingdom among them, list what is targetable now. A campaign geofenced to a city with no exits online is a gap to disclose to the client up front, not to discover mid-flight. A location with no exits is refused rather than silently served from the nearest city, which is the right behavior for a verifier: a refusal is a visible empty cell, a silent relocation is a wrong-geo finding you would later have to retract.

Billing is by bandwidth, and a real browser loading a page with its full ad stack pulls megabytes, not kilobytes. Verification is a breadth workload, a handful of page loads per placement across many markets and dayparts, so the bill stays sane if the sampling plan is lean; it stops being sane if someone points a crawler at it. Allowances are on the pricing page.

Whitelisting is untargeted on this product. IP whitelisting works on every product, including residential, but a whitelisted residential connection sends no username, and the username is where the country, city and session segments live. So a whitelisted probe rotates freely across the whole pool, which is the opposite of what a geo-pinned check needs. Verification probes authenticate with credentials.

2. Datacenter proxies, for the narrow jobs they fit

Datacenter addresses fail the first property: a probe from a hosting range is precisely what invalid-traffic filters exist to catch. The ad server may serve nothing, serve unpaid filler, or flag the session, and none of those tells you anything about what the audience saw. They are the wrong tool for auditing delivery, even though datacenter address space is what Node4 owns.

They still earn the second slot, because a verification program has jobs that never need to pass as the audience:

• Tag and pipeline QA. Confirming your own pages fire the right tags, that the capture pipeline screenshots and stores correctly, that the parser reads a rendered slot. None of that depends on a paid impression being served.
• Landing-page integrity on destinations you control. Following your own clickthrough chain to check it lands where the insertion order says. Cloaked redirects are conditional on geography and device, so a datacenter probe sees the clean version, which is still useful as the baseline the in-market probe is compared against.
• Negative checks. Probes that should see nothing, confirming exclusion lists exclude and geofences hold, are cheaper from a static address, and their "nothing" is the expected result either way.
• Brand-safety crawling of the surrounding content, which is a fetch of the page rather than of the ad, and on many publishers does not require consumer reputation.

The addresses are our own, static, and priced per address rather than per gigabyte (dedicated addresses are not metered at all; the shared tier carries a pooled allowance per proxy), which is why the pipeline-shaped work belongs on them. The mechanics of why hosting ranges get classified, and how to measure a block rate on a specific target before paying for anything, are in datacenter vs residential proxies.

3. Mobile proxies, the category we do not sell

The third entry matters even though Node4 cannot sell it. Some buys can only be verified from a carrier address: in-app inventory and campaigns targeted by carrier, where the platform resolves the carrier from the network the viewer arrives on and a broadband or hosting address simply falls outside the buy. Carrier-grade NAT puts a large number of real handsets behind each address, which is why platforms are reluctant to block one and why a carrier exit is the hardest reputation for a platform to refuse.

Node4.io does not sell mobile proxies. The category is withdrawn from sale here and enforced as unsellable, so nothing on this site will take money for one. For carrier-targeted verification, source them from a provider that publishes how its carrier exits are obtained, and hold that provider to the fifth property above at least as hard as you would hold us: an exit sourced from an SDK bundle a handset owner never knowingly consented to is evidence you may not want to stand behind.

What to check before buying from anyone, including us

Six questions separate a provider that can support a verification program from one that can only support a scraper. They apply to us; ask them of every entry on any shortlist.

Where do the addresses come from? For residential, is the sourcing published, and is consent part of it? For datacenter, does the provider own the space or rent it from someone who might reassign it?

How fine is the pin? Country is table stakes. City is where campaign buys actually live, and a "city" that quietly resolves to a region is a wrong-geo false alarm waiting to happen. Test a known city before promising city-level evidence.

What happens when the location is impossible? Refused, or silently redirected? Only the first is safe for a verifier.

How long does a session hold? Long enough for a page load, the auction, the render and a click, with margin. The mechanics, and the failure signature when a session drops mid-chain, are in sticky versus rotating sessions.

Can it sit under a real browser? HTTP and SOCKS5, credentials the browser can pass, and no interception of TLS. Attaching the proxy to a scripted browser is covered in Puppeteer and Playwright proxies, and the request fingerprint tool will show you whether the headers that browser sends through the proxy still look like a browser, and whether their language agrees with the exit's country.

What does one check cost? Per address or per gigabyte, and what a browser page load with an ad stack actually weighs on that meter. A provider that cannot answer has not thought about this workload. Read the renewal rate rather than the promotional one; a promotion answers what the first invoice will be, not the twelfth, and the Proxy-Cheap comparison is a worked example of telling the two apart.

The failures a probe is hunting

Once the access layer is right, the probe looks for a short list of nameable things, and the data model follows from the list.

Non-delivery. The campaign never appears in its bought context across a sensible number of clean samples. One empty slot is auction noise; persistent absence across dayparts and exits is a finding.

Wrong-geo delivery. Creative bought for one market rendering in another, where the buyer may have neither rights nor stock. Only a probe in the wrong market can see it, so the sampling plan deliberately includes exits outside the target, expecting them to see nothing.

Domain spoofing. The report says a reputable publisher; the impression happened somewhere cheap. Catch it by recording the rendering context (page, frame, declared domain) and comparing it to the seller's supply-chain declarations.

Stacking and invisible delivery. Layered creatives, one-pixel frames, slots outside the viewport: all billed, at most one seen. A scripted browser can measure rendered size, position and occlusion where a reporting pixel cannot.

Landing-page and redirect integrity. The click chain hopping through intermediaries nobody signed off, usually conditional on geography or device, which is exactly why it survives casual checking from the buyer's office and fails in front of an in-market probe.

Brand-safety adjacency. Served exactly as bought, next to content the brand excluded. A contract question rather than fraud, and it needs the surrounding page captured, not just the slot.

Evidence, calibration and the first probe

A finding that cannot be shown to a vendor is an anecdote, so every check records a full-page screenshot with the creative in context, a UTC timestamp at render, the probe's own vantage point (exit country and city, user agent, viewport), the network trace of the ad request chain and the click redirects, and all of it in append-only storage, because last Tuesday's impression cannot be re-run next week. Whether any of it has standing in a formal dispute is a question for the contract and for counsel; platform terms govern automated access to ad systems, and that compliance homework is yours, jurisdiction by jurisdiction.

Calibrate before accusing anyone. Run a tiny self-serve placement of your own, targeted at one city, and confirm probes from that city see it while probes from elsewhere do not. That one exercise validates the geo pin, the browser fingerprint, the capture pipeline and the parser together, and it gives you a false-negative baseline: if your own always-on placement is caught in most clean probes, an audited campaign caught in none is a real absence with a number attached, rather than the vendor's unfalsifiable "auctions are probabilistic".

A minimal first probe is one scripted browser, one residential exit pinned to the campaign's city, one page load, one screenshot with metadata. Prove that loop on a placement you control, then scale along the sampling plan toward breadth of markets and dayparts, not toward request volume.

The two neighboring workloads on the use-cases page are worth reading for contrast. Rank tracking is the same clean-session discipline against a target that classifies datacenter space even harder, and price monitoring is an in-market vantage problem where nobody is trying to deceive the observer and the number still comes back wrong. Ad verification is the one of the three where the counterparty profits from the gap between what you see and what your audience saw, which is why the vantage point is the whole product, and why a shortlist for this query is mostly about reputation rather than speed.