Three Clicks to Block a VPN — Configuration Without the Complexity
Detecting VPNs, proxies, antidetect browsers, and scraping bots is hard. Configuring what to do about them shouldn't be. Here's how IPrating turns multi-layer detection into a four-option dropdown.
The hard part of traffic filtering is not deciding what to block. The hard part is knowing that you are blocking the right thing — that the visitor you flagged as a VPN user actually is one, and not a legitimate customer on a corporate network or a mobile carrier with an unusual network path. That detection work is complex, multi-layered, and we have invested years in it. The configuration of what to do with the result, by deliberate design, is not.
This article is about that second part: how easy it is, once the detection has run, to tell the platform what to do. Not how to install the probe on your site — that is two lines of code and depends on your backend. Not how the detection works internally — that would help the wrong people. Just the configuration surface, and why it is built around four words.
The Four Words
With IPrating, every classification the platform makes — VPN, Tor, datacenter proxy, public proxy, corporate proxy, residential proxy, search engine, scraper, AI crawler, antidetect browser, or any custom pattern you define — resolves to one of four actions:
- Allow — let the visitor through
- Block — deny the request
- Challenge — present an interactive challenge to slow down traffic or add friction (cost)
- Redirect — send the visitor to a different URL
That is the entire decision vocabulary. You do not write rules that evaluate conditions. You do not build scoring pipelines. You do not tune thresholds. The platform has already determined what the visitor is; your job is to say what happens next, and there are exactly four answers.
Network Rules: One Dropdown Per Threat Type
The dashboard's Network Rules section is a grid of labeled rows, each with a single dropdown. The labels name the threat categories the platform detects:
- Virtual Private Networks (VPN)
- Tor networks
- Datacenter proxies
- Public proxies
- Corporate proxies
- Residential proxies
Each dropdown has the same four options. To block all VPN traffic, you set the VPN dropdown to Block and save. To challenge visitors on datacenter proxies instead of blocking them, you set that dropdown to Challenge. To redirect Tor traffic to a landing page, you set Tor to Redirect and configure the destination URL once in your global redirect settings.
There is no order to manage, no priority to configure, no regex to write. The detection and the cross-layer correlation that distinguishes a datacenter proxy from a residential one — the part that would take a security team months to build and weeks to maintain — happens before the dropdown is even rendered. By the time you see "datacenter proxy," the platform has already resolved the ASN type, confirmed the proxy suspicion against the browser's network-stack behavior, and ruled out legitimate encapsulation like PPPoE or satellite connections. You are acting on a concluded detection, not a raw signal.
Antidetect Browsers and Scraping Bots
Two categories of traffic deserve special mention because they are where most filtering tools fail silently, and where the configuration story is deliberately simple.
Antidetect browsers are tools that present a real browser's User-Agent and environment while running on a different operating system, behind a proxy, or with a modified network stack. They are designed to defeat signature-based detection. IPrating does not detect them by their User-Agent — which they forge — but by whether the browser's claimed identity is consistent with what the network and the TLS handshake reveal. When the platform detects that a browser claims to be on Windows but the TCP fingerprint shows Linux, or that the browser claims to support a protocol it does not, the classification captures that inconsistency. Your configuration does not change: the traffic is routed through the same network rules, and you decide whether to block, challenge, or allow it with the same dropdown.
Scraping bots are the combination case. A scraper running on a datacenter IP with a forged browser identity is detected through the intersection of the network type (datacenter proxy) and the browser reality check (fake browser). The platform resolves both and presents the result as a network-rule classification. You do not need to write a rule that says "if datacenter AND fake browser then block" — the correlation is done for you, and the dropdown you already set for datacenter proxies applies.
Custom Signatures: When the Built-in Catalog Is Not Enough
The platform ships with a maintained catalog of known bots, crawlers, and automation tools, each classified by category (search engine, marketing, social media, AI crawler, AI search, automation tool, archiver, monitor, security, academic). Each category has its own dropdown, so you can allow search engines while blocking automation tools, or challenge AI crawlers while allowing AI search.
When you encounter traffic that does not match any built-in category — a proprietary scraper, a competitor's crawler, a niche automation tool — you add a custom signature. A custom signature is three fields:
- A name so you can recognize it in your reports
- A User-Agent regex pattern that matches the traffic you want to catch
- An action from the same four options
Signatures are evaluated in the order you define them, and the first match wins. If you want to block a scraper that identifies itself as "AcmeCrawler/2.0," you add a signature named "Acme Crawler," set the pattern to AcmeCrawler, and set the action to Block. The traffic is classified against your signature on every request, and the match appears in your analytics with the signature name you gave it — not as an opaque rule ID.
Overrides: When You Need to Be Explicit
Sometimes you know better than any automated detection. A partner's office IP that routes through a VPN. A country you want to geo-block entirely. A specific CIDR range from a hosting provider that keeps probing your endpoints. The Overrides section handles these cases with the same simplicity:
- IP whitelist / blacklist — type an IP or CIDR range, press add. Whitelisted IPs are always allowed; blacklisted IPs are always blocked, overriding every other rule.
- Country whitelist / blacklist — select a country from a searchable list, press add. The lists are applied before any network or bot rule, so a whitelisted country is allowed even if the detection finds a proxy.
Overrides are the escape hatch for the cases where policy must trump detection, and they require zero configuration beyond the values themselves.
The Point: Detection Is Complex, Decisions Are Not
The reason the configuration surface is this simple is that the complexity has been absorbed by the platform, not pushed onto the customer. Every dropdown represents the output of a multi-layer detection pipeline that correlates network fingerprints, browser proofs, TLS behavior, and ASN metadata before it commits to a classification. You never see the pipeline. You see the conclusion, and you choose an action.
A security engineer could spend a month building rules to detect datacenter proxies, tune them to avoid false positives on corporate VPNs, and then build a second set of rules to catch antidetect browsers on top of those proxies. Or they could open the dashboard, set two dropdowns, and save. The detection quality is the same. The time spent is not.