If you run a WordPress site with open registration, a contact form or a WooCommerce checkout, you've seen it: a wave of new accounts with throwaway emails, contact-form spam at 3 a.m., orders that look fine until the chargeback arrives. A lot of that traffic doesn't come from home internet connections. It comes through VPNs, open proxies, Tor and rented cloud servers.
Detecting that is easy. Deciding what to do with it is where most setups go wrong: millions of legitimate people use a VPN every day, and a site that blocks all of them loses real customers.
Here's how to approach it on WordPress, in the order that keeps false positives low.
1. Know which network your visitors come from
Every request arrives from an IP address, and that address belongs to a network. The useful question isn't "which IP?" but "what kind of network?":
- Residential or mobile ISP: home broadband, phone carriers. This is almost everyone.
- Hosting or datacenter: AWS, DigitalOcean, OVH, Hetzner and friends. Real people rarely browse from these; scripts and cheap proxies do.
- Commercial VPN, open proxy, Tor: anonymized traffic. Common for privacy-minded users, also common for abuse.
- Known malicious IPs: addresses already seen scanning, spamming or attacking.
WordPress doesn't tell you any of this. You need an IP intelligence lookup: either a plugin that calls one, or a layer in front of the site (Cloudflare) that classifies traffic for you.
2. Look before you block
The most common mistake is installing a blocker, switching on "block all VPNs", and walking away. Two weeks later a customer emails to say they couldn't check out from their company laptop.
Run in monitor mode first, for a week if you can:
- What share of registrations come from hosting networks or VPNs?
- What share of orders, and do those orders get refunded or charged back more?
- Are your contact-form spam submissions concentrated on a few networks?
You'll usually find that the abuse sits in a few clear patterns (datacenter IPs on the registration form, say), while VPN users on checkout are mostly fine. That tells you exactly where to add friction and where to leave things alone.
3. Watch out for page caching
If you use a full-page cache (WP Rocket, LiteSpeed Cache, W3 Total Cache, or your host's built-in cache), a PHP check that runs when WordPress renders the page doesn't run on a cached page. The cache serves the stored HTML without WordPress ever looking at the visitor's IP. Server-side blocker plugins usually document this and ask you to exclude protected pages from the cache.
Two ways around it:
- Check at the edge: a Cloudflare WAF rule or Worker sees every request before the cache.
- Check in the browser and on submit: a small script on the page reports the visit and the form submit, so cached pages are covered too. The decision happens when the form is actually submitted.
4. Protect the forms, not the whole site
Blocking every page for every VPN user is a blunt tool. The forms are where abuse costs you money, so put the friction there:
| Form | Typical abuse | A reasonable response for risky submits |
|---|---|---|
Registration (wp-login.php?action=register, membership plugins) |
Bot signups, fake accounts | A Turnstile check or email verification |
Login (wp-login.php, WooCommerce My Account) |
Credential stuffing | A short wait plus a challenge after failures |
| Contact and lead forms | Spam leads | A challenge for hosting networks only |
| WooCommerce checkout | Card testing, fraud | A challenge, or hold the order for review |
"Risky" should mean several signals together (a datacenter IP plus a brand-new account plus a burst of attempts), not a VPN on its own.
5. Your options on WordPress
There are three common routes, and they combine well:
- Cloudflare WAF rules. If your site is behind Cloudflare, custom rules can block or challenge by ASN, country or Cloudflare's own threat signals, before the cache. Powerful, but you write and maintain the rules yourself, and you don't get a per-form view of what happened.
- A blocker plugin backed by an IP API. Plugins such as Proxy & VPN Blocker (proxycheck.io) or VPN Guard (vpnapi.io) check the visitor IP against an API and block or redirect on pages you choose. Simple and effective for hard blocking; mind the caching caveat above and the API's daily quota.
- A monitoring-first plugin with form protection. Score every visit and form submit, see the reasons in a dashboard, and add friction only on the forms and signals that turn out to matter.
Where FindIP Shield fits
Disclosure: we make FindIP Shield, a free plugin for the third route.
- Every visit, signup, login and WooCommerce checkout gets a risk score with the reasons: VPN, proxy, Tor, relay, hosting or datacenter network, or a known malicious IP.
- It runs on regular pages and on
wp-login.php, in the browser, so full-page caching doesn't skip it. - With WooCommerce active it adds cart, checkout, payment-failure and order-completion context, so you can see which orders came through anonymizing networks.
- It doesn't block anything by default. When you're ready, you switch on form protection from the dashboard and choose what a risky visitor sees: a message, a short wait, or a Cloudflare Turnstile check.
- It never reads form values, passwords, emails or payment details, and starts in strict privacy mode.
- Setup is install, click Connect, pick your site. Free up to 10,000 events per site per day.
It's on WordPress.org as FindIP Shield: VPN, Proxy & Bot Traffic Detection, and there's an example dashboard with sample data if you want to see what it shows before installing.
The short version
- Find out which networks your visitors come from: residential, hosting, VPN, Tor.
- Monitor for a week before blocking anything.
- Remember that page caching skips server-side checks; check at the edge or in the browser.
- Add friction on the forms where abuse costs money, when several signals stack up.
- Never block VPN users outright. Challenge them when the rest of the picture looks wrong.
Top comments (0)