Filter VPN, Proxy and Datacenter Traffic: When and When Not

Sooner or later you open your click log, sort by IP type and see a block of datacenter and VPN addresses. The first reaction is to tick every box in the filter and be done. That is a reasonable move for one of those groups and a costly one for the other.

Datacenter traffic is almost always automation, so filtering it is usually safe. VPN and proxy traffic is mixed: some of it is scripts, and some of it is real people who care about privacy, work behind a corporate gateway or live in a country where a VPN is part of everyday browsing. Blocking all of it can cost you real conversions, and you only find out by measuring.

Three groups that get mixed up

People say "VPN traffic" when they mean at least three different things. They behave differently, so lumping them together is the main reason blanket rules go wrong.

• Datacenter IPs. Addresses that belong to hosting providers and cloud platforms. A real person does not browse from a server rack. Visits from these ranges are scripts, scrapers, link checkers, monitoring tools and the occasional crawler.
• Consumer VPN and proxy. Commercial VPN apps, browser extensions, privacy relays. Many of their exit nodes sit in datacenter ranges too, but the person behind the connection is a human with a phone or a laptop.
• Corporate and institutional networks. An office gateway, a university network or a mobile carrier that puts thousands of users behind a few addresses. These can look like proxies in a database and still be ordinary visitors.

A fourth case is Tor. It is a separate signal in the overview and the click log, and it deserves its own decision. The reasoning below applies to it as well.

Datacenter traffic: filter it

If the IP belongs to a hosting provider, the odds that a buyer sits behind it are low. The clicks you get from those ranges tend to come from tools that follow links to check them, from scrapers that collect ads and landing pages, and from automated tests. They cost you budget when they arrive through a paid source, and they inflate your click count when they do not.

There is one honest exception to watch for. If you run your own checks from a server, for example a monitoring script that opens your own link, those visits also come from a datacenter. Exclude your own tools by testing from a normal connection, or remember to subtract them when you read the log.

Everything else from datacenter ranges can go to a page you set. The point is to protect the budget and keep the stats clean, not to chase every last visit.

VPN and proxy: measure before you block

The case against blocking all VPN traffic is simple. A share of your visitors use a VPN, and some of them buy. The size of that share depends on your geo, your vertical and your source, and I would not trust anyone's average for it, including mine. In some countries a VPN is switched on by default on many phones. In some corporate setups every employee exits through the same proxy.

The case for blocking is also real. In some sources the VPN segment is full of scripted clicks that rotate through exit nodes to look like different people. If your segment is mostly that, blocking costs you nothing.

You cannot tell which of the two you have from the outside. You tell from the log. The method is below.

How to test a segment in your own log

The idea is to let the questionable segment through, tag it, and see whether it converts. You need a few days of traffic and a way to tie conversions back to clicks, which is what a click ID and a postback do (see click ID and subid explained).

1. Turn the VPN signal off for the test. Keep the datacenter signal on. Run your normal traffic for a few days so the VPN segment is allowed to reach the offer.
2. Filter the click log by VPN. The log has filters for bots, unique clicks, VPN and Tor, so you can pull this segment out in a couple of clicks.
3. Count clicks and conversions in the segment. Do the same for the rest of the traffic from the same source and geo.
4. Compare conversion rate and cost per conversion. If the VPN segment converts at a rate close to the rest, blocking it throws away paying visitors. If it converts at close to zero over a decent number of clicks, block it.
5. Check the quality signals next to it. Look at referrer, device and the time between click and landing view. A segment with empty referrers and a single device model is a different story from one with a normal mix of phones.

A worked example with hypothetical numbers

Say you buy 10,000 clicks at $0.05 from one source in one country. The log shows 800 of them as VPN or proxy. The rest, 9,200, are normal traffic.

Here the VPN segment converts like everyone else, and blocking it would lose four conversions out of fifty. Now change the second row to 800 clicks and 0 conversions. Same cost, no result, and you would block the segment from the next batch. The numbers are made up, and the point is the comparison, not the figures.

Sample size matters. Four conversions is a weak signal in either direction. If your segment is small, wait until you have enough clicks that the result stops moving from day to day.

Other signals that sit next to VPN

VPN and datacenter are two boxes among several. The filter also lets you tick unknown platform, unknown browser, empty country, empty city, IPv6 and empty referrer. Each of them has a similar trade-off, and none is a verdict on its own.

• Empty referrer. Many real visitors arrive without one, because of app browsers, privacy settings and link shorteners. Treat it as a weak signal, and combine it with others before you block.
• IPv6. A normal and growing share of real mobile traffic uses it. Blocking it blindly is rarely a good idea. It is useful as a diagnostic: if one source sends only IPv6 from unusual ranges, that is worth a look.
• Empty country or city. The geo database has no answer for the address. Real users end up here too, but a large share of empty values from one source is a sign to investigate.
• Unknown platform or browser. Scripts often send odd or empty user agents. Real devices almost always identify themselves.

The filter levels (Off, Standard, High, JavaScript browser check and Custom) exist so that you can start gentle and tighten. With Custom you choose the signals one by one, which is the mode for the experiment above. Datacenter on, VPN off, then compare. If you want to understand why IP signals alone have limits, read JS fingerprint vs IP blocking.

Setting it up so you can change your mind

Whatever you decide, make the decision reversible. Two things in the setup help.

• A page for filtered clicks. Filtered visitors are sent to a page you set. Choose something neutral that you control, so a mistaken block does not lead to an error screen.
• The reason stays in the log. Filtered clicks are still logged with the reason, for example vpn, datacenter or suspicious_headers. That is what makes a later review possible: you can open the log, filter by reason and see exactly who was sent away.

There is also a softer control for the start of a flow. You can treat the first N clicks as bots, and a quarantine after the first bot holds suspicious sources for a set number of minutes. These settings are about timing and bursts rather than IP type, so use them alongside the signals and not instead of them.

FAQ

Should I block all VPN traffic?

Not as a default. Some of your VPN visitors are real buyers. Run the segment through your funnel for a test window, compare conversions with the rest of the traffic, and block only if it performs far worse. The answer can differ by source and geo.

Is datacenter traffic always bots?

Nearly always, since people do not browse from hosting ranges. The exceptions are your own tools and some people who run a remote desktop on a cloud machine. For paid traffic, filtering it is the safer default.

Why do some real users look like proxies?

Corporate gateways, university networks and mobile carriers put many users behind shared addresses, and databases can label those ranges as proxy. That is one more reason to test a segment before you cut it.

What happens to a filtered click?

The visitor goes to a page you set, and the click is logged with the reason. You can filter the log by VPN, bots, unique clicks or Tor and review the decisions later.

Does filtering VPN traffic protect my forms?

The filter works on clicks to your link. It does not protect forms or other pages on your site. For those you need your own measures, such as a CAPTCHA or rate limits on the form.

If you want to try this on your own traffic, the bot filtering page lists the signals and filter levels, and traffic filtering covers how filtered clicks are routed and logged.