WordPress is a magnet for VPN and proxy abuse

Stand up a fresh WordPress site, leave wp-login.php exposed, and you'll see automated login attempts within hours — long before you've published a single post. Almost none of it is human. It's credential-stuffing scripts, comment-spam bots, and vulnerability scanners, and a large share of it arrives through VPNs, open proxies, hosting datacenters, and Tor exit nodes.

That's not a coincidence. Attackers route through these networks for the same reason privacy-conscious users do: to hide where they really are and to rotate through fresh IPs faster than any rate limit can keep up. The difference is that a real customer on a VPN wants to read your content or buy something. The bot on a datacenter IP wants your admin password.

The instinct is to block every VPN outright. Don't — you'll lock out legitimate visitors, remote workers on corporate VPNs, and privacy-minded customers along with the bots. This guide covers how to filter the genuinely malicious traffic *by risk*, while leaving real people alone. (If you'd rather skip straight to the tooling: the free Predax Security plugin implements everything below with per-signal Block/Monitor/Off controls.)

What VPN, proxy and Tor traffic actually does to a WordPress site

A few patterns show up on practically every site once it has any traffic at all:

Brute-force and credential stuffing from datacenter IPs. Genuine visitors browse from home ISPs and mobile networks. When a wave of wp-login.php POSTs arrives from AWS, OVH, DigitalOcean, or Hetzner ranges, it's a script on a rented server, not a customer who forgot their password. Datacenter origin is one of the cleanest "this is automated" signals you can get.

Comment and registration spam through open proxies. Spam bots cycle through proxy pools to dodge IP-based rate limits. If you allow open registration or comments, proxies are how the junk gets in at volume.

Probing and scanning over Tor. Tor is disproportionately used to scan for known plugin vulnerabilities and exposed files, precisely because the exit node masks the source. Very few legitimate buyers shop through Tor; plenty of scanners do.

None of these are exotic. They're the background radiation of running a WordPress site — and they're exactly the kind of traffic an IP signal catches early, before the damage is done.

The layer most WordPress security plugins skip

Most WordPress security plugins are good at one half of the problem: they lock the door. Brute-force lockouts, rate limits, two-factor, a web application firewall that matches request signatures. All useful. But they mostly don't ask the other question — *who is knocking?*

That's the gap. A login attempt from a residential broadband line in your own city is a very different thing from the same attempt arriving from a Tor exit relay or a server in a hosting datacenter on the other side of the world — even though the two requests look identical at the firewall layer. Without IP intelligence you treat both the same.

Filling that gap means classifying each visitor's IP in real time: is it a known VPN provider, an open proxy, a Tor exit node, or a datacenter range — and how risky is it on a 0–100 scale? That's a different input from "this IP failed five logins," and it lets you act *before* the fifth attempt instead of after. (How we detect VPN users and how risk scoring works go deeper on the mechanics.)

Block by risk, not by blanket rule

Here's the principle that keeps you from blocking real customers: don't treat "is a VPN" as an automatic block. Treat it as one input into a risk decision.

A good setup gives you two independent controls:

• Per-category modes — set VPN, proxy, Tor, and datacenter each to *Off*, *Monitor*, or *Block*. Tor and open proxies are usually safe to block hard; VPNs almost never are.
• A risk-score threshold — block anything scoring above a number you choose (0–100), so a high-confidence malicious IP gets stopped even when it slips past the category rules.

Start everything in Monitor for a week. Monitor logs what *would* have been blocked without actually blocking it, so you see your real traffic mix before you switch on enforcement. Then tighten from evidence, not guesswork.

A reasonable decision matrix for a typical content or ecommerce site:

The through-line: hard-block the categories real customers never use, and risk-score the ones they do. (Residential vs datacenter proxies explains why residential VPNs are the hardest call of all.)

Setting it up in WordPress

You don't need to write code or manage IP feeds yourself. The Predax Security plugin does the classification through a hosted API and surfaces the controls above directly in the WordPress admin. The free tier covers 1,000 IP checks a day which — with one-hour per-IP caching — comfortably handles roughly a thousand unique visitors daily. No credit card.

The short version:

1. Install and activate Predax Security from the WordPress plugin directory, then connect a free API key through the setup wizard (one click via "Connect with Predax", or paste a key manually).
2. Pick the "Monitor Only" preset to start. Nothing is blocked yet — you're just collecting data.
3. Open Settings → Protection and set your category modes: Tor → *Block*, open proxy → *Block*, datacenter → *Block* (on login and registration), VPN → *Monitor*.
4. Set a risk threshold. 70 is a sensible starting point — lower it if abuse is still getting through, raise it if you catch false positives.
5. Turn on the protections you need. Login, registration, comment, and XML-RPC/REST are independent toggles. If you don't use XML-RPC, block it outright.
6. Enable the custom block page so blocked visitors see a clear, branded message instead of a bare WordPress error.

After a week in Monitor, review the Threat Log, confirm the blocks look right, and flip the preset to enforcing. That's the entire workflow.

Add country rules where they make sense

Geo-blocking pairs well with IP intelligence. If you don't ship to a country, sell to it, or serve content there, blocking it removes a whole class of automated abuse in one move — a lot of credential-stuffing and card-testing runs from a handful of regions.

But country blocking is a blunt instrument. Block too broadly and you'll lose travelers, expats, and customers whose mobile carrier happens to route through an unexpected country. Keep it to countries you genuinely have no business in, layer it on top of risk scoring rather than leaning on it alone, and never use it to block search-engine crawlers. (Blocking visitors by country covers the SEO and compliance angles in detail.)

Don't block the visitors you actually want

This is the part that separates a security setup from a customer-service problem. A few rules keep the false positives down:

Never block search engines. Googlebot and Bingbot crawl from published, verifiable ranges, and blocking them will quietly tank your rankings. Good tooling verifies a claimed crawler with reverse-plus-forward DNS before trusting it, and treats verified search engines as allowed regardless of other signals. If you take one thing from this section: confirm your crawler handling before you enforce anything.

Whitelist yourself and your team. If you administer the site from a corporate VPN or a static office IP, add it to the allowlist so you never lock yourself out of your own dashboard. The plugin accepts individual IPs and CIDR ranges.

Respect the residential VPN edge case. Some privacy-focused VPNs route through real ISP addresses and are genuinely hard to tell apart from ordinary home connections — which is exactly why you keep VPNs on Monitor or behind a CAPTCHA rather than a hard block. A customer paying you while connected to ProtonVPN is not a threat.

Watch the log for the first couple of weeks. Every site's traffic is different. The Threat Log shows you exactly who was blocked and why, so if a real customer trips a rule you'll see it and can adjust the threshold or whitelist them on the spot.

A sensible starting configuration

If you want a configuration to copy and adjust, this works for most content and ecommerce sites:

• Monitor everything for 7 days first, then enforce.
• Block: Tor, open proxies, datacenter IPs at login and registration, and anything scoring 85 or above.
• Monitor (don't block): VPNs — or require a CAPTCHA at login instead.
• Risk threshold: 70.
• Country rules: block only regions you have no customers in.
• Always allow: verified search engines and your own whitelisted IPs.
• Custom block page: on, with a support link so a misflagged visitor can reach you.

That stops the overwhelming majority of automated abuse while leaving real, paying, privacy-conscious visitors untouched — which is the whole point.

Related guides

• How to block Tor users (without breaking real visitors) — the nuance on Tor specifically.
• How to detect VPN users with an IP API — what's happening under the hood when an IP gets flagged.
• How to block visitors by country — geo-blocking without wrecking your SEO.
• IP risk scoring explained — what the 0–100 score actually means.
• Residential vs datacenter proxies — why residential VPNs are the hardest to judge.
• Credential stuffing in 2026 — the attack this setup is mostly defending against.

Ready to filter the bad traffic without losing the good? Install Predax Security on your WordPress site — the free tier needs no credit card — or see pricing if you're running higher volume.