# ProxyTracer: VPN & Proxy Blocker
**URL:** https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958
**Category:** Plugin
**Created:** [April 4, 2026, 7:56pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958 "2026-04-04T19:56:00Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@ProxyTracer](https://meta.discourse.org/u/ProxyTracer)
#### Post date: [April 4, 2026, 7:56pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/1 "2026-04-04T19:56:00Z")
| | | |
| --- | --- | --- |
| ℹ | **Summary** | Detect and block VPN, Tor and proxy traffic during user registration, login, and/or globally using the ProxyTracer API. |
| 🛠 | **Repository Link** | [https://github.com/ProxyTracer/discourse-proxytracer](https://github.com/ProxyTracer/discourse-proxytracer) |
| 📖 | **Install Guide** | [How to install plugins in Discourse](https://meta.discourse.org/t/install-plugins-in-discourse/19157) |
This plugin uses the ProxyTracer API to detect and block VPN, Tor and proxy traffic in Discourse.
### Features
- It gives you fine control over blocking VPN, Tor and Proxy users during new user registrations, existing user authentication, or globally for all site visitors. If you’re fine with VPN, Tor and Proxy users having read access to your forum then you can save on API requests and only enable it for user registration and authentication.
- It uses caching to store recent IP address evaluations thus saving requests to the API and lowering latency. You can control how long to remember an IP address evaluation in the settings.
- In the event of an API timeout or network failure, the plugin prioritizes user access to prevent wide-scale lockouts. This behavior can be changed through the options.
- Built-in support for exact IP and CIDR subnet whitelisting.
### Configuration
1. Procure a standard API key from the [ProxyTracer Dashboard](https://proxytracer.com/dashboard).
2. Navigate to your Discourse administration panel: **Admin → Plugins → ProxyTracer** to find ProxyTracer’s settings.
3. Input your API key into the `ProxyTracer API Key` field.
4. Enable the protection parameters by toggling `Enabled during Signup`, `Enabled during Login` and/or `Enabled for All Visitors`.
5. Add any trusted IPs or CIDR ranges to the `Whitelisted IPs` list.
6. (Optional) Adjust the API timeout and Redis cache duration limits to suit your server’s specific traffic requirements.
7. (Optional) Customize the Block Message that appears to blocked users. For instance, you can add instructions for contacting the administration of the site in case they believe that the block isn’t warranted and that they’re not accessing the site through a proxy, Tor or VPN.
### Settings
Include a table of settings and setting descriptions
| Name | Description |
| --- | --- |
| API Timeout (ms) | How long to wait for the API to respond before timing out. |
| Cache Duration (hours) | How long to remember an IP address before checking the API again. |
| Fail Open on Error | If the API crashes or times out, allow the user to register/login anyway to prevent locking everyone out. |
| Enabled during Signup | Block proxies and VPNs when a new user attempts to register. |
| Enabled during Login | Block proxies and VPNs when an existing user attempts to log in. |
| Enabled for All Visitors | Block proxies and VPNs from accessing or viewing any page on the forum. (Warning: This checks every visitor and heavily utilizes your API quota). |
| Block Message | The exact error message shown to the user when they are blocked. |
| Whitelisted IPs | IP addresses or CIDR ranges (e.g., 192.168.1.0/24) that are strictly allowed to bypass the blocking. |
## Network Configuration: Cloudflare & Reverse Proxies
> ⚠ **For ProxyTracer to function effectively, the Discourse application must receive the true client IP address.**
To ensure correct IP address forwarding you can follow these [detailed instructions](https://github.com/proxytracer/discourse-proxytracer/#direct-cloudflare-integration-standard-installation).
### Emergency Access
If you locked yourself out you can regain access by following these [simple steps](https://github.com/proxytracer/discourse-proxytracer/#emergency-access).
* * *
If you want to test things then you can signup to ProxyTracer and get some free API credits for testing.
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [April 4, 2026, 8:41pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/2 "2026-04-04T20:41:52Z")
the credits restart every next month?
---
### Author:  [@ProxyTracer](https://meta.discourse.org/u/ProxyTracer)
#### Post date: [April 4, 2026, 9:49pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/3 "2026-04-04T21:49:23Z")
> [@eisammy](#):
>
> the credits restart every next month?
You’re asking about the free credit during signup? If that’s the case then it’s only a one-time top-up.
---
### Author:  [@darkpixlz](https://meta.discourse.org/u/darkpixlz)
#### Post date: [April 5, 2026, 4:10am UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/4 "2026-04-05T04:10:18Z")
> [@](#):
>
> **Locked out?** If you accidentally block your own IP address while configuring ProxyTracer (e.g., you are currently connected to a VPN), you can easily regain access using Discourse’s built-in [Safe Mode](https://meta.discourse.org/t/53504?silent=true).
>
> 1. Navigate to `https://yoursite.com/safe-mode`
> 2. Check the box for **“Disable all plugins”** and click **“Enter [Safe Mode](https://meta.discourse.org/t/53504?silent=true)”**.
> 3. Log in normally and navigate to **Admin → Plugins → ProxyTracer**.
> 4. Temporarily disable the plugin or add your current IP to the **Whitelisted IPs** list.
> 5. Exit [Safe Mode](https://meta.discourse.org/t/53504?silent=true) to resume normal site operations.
Does this not defeat the entire point of the plugin? Anybody can use safe mode.
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [April 5, 2026, 5:49am UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/6 "2026-04-05T05:49:31Z")
It depends. There is a site setting that allows you to disable [safe mode](https://meta.discourse.org/t/53504?silent=true), which is helpful for the gated topic component and other components/plugins users shouldn’t easily disable like that (advertising, guest gate, …). But while you are logged out, that would also make using [safe mode](https://meta.discourse.org/t/53504?silent=true) more difficult for admins. I think they can still enable it using [admin-login](https://meta.discourse.org/t/log-back-in-as-admin-after-locking-yourself-out-with-read-only-mode-or-an-invalid-sso-configuration/89605).
For this plugin, I doubt [safe mode](https://meta.discourse.org/t/53504?silent=true) helps. [Safe mode](https://meta.discourse.org/t/53504?silent=true) disables only the front-end part of plugins, and this plugin in 100% Ruby. So I don’t think disabling JavaScript customizations is any help. This fact makes me a little skeptical about the plugin, as does the fact that it includes an `about.json` file as if it were a theme component. But in the end, everyone is responsible for the code they install on their forum.
---
### Author:  [@ProxyTracer](https://meta.discourse.org/u/ProxyTracer)
#### Post date: [April 5, 2026, 2:19pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/7 "2026-04-05T14:19:04Z")
> [@Moin](#):
>
> For this plugin, I doubt [safe mode](https://meta.discourse.org/t/53504?silent=true) helps
You are completely right on this, I can confirm this through my own testing with a freshly spun up Discourse instance. I went ahead and updated the documentation with instructions that actually work which consist of logging into the server and manually disabling the addon:
```bash
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
```
> [@darkpixlz](#):
>
> Does this not defeat the entire point of the plugin? Anybody can use [safe mode](https://meta.discourse.org/t/53504?silent=true).
I can confirm that **[safe mode](https://meta.discourse.org/t/53504?silent=true) is inaccessible when the “Enabled for All Visitors” setting is enabled and someone tries to access [safe mode](https://meta.discourse.org/t/53504?silent=true) while connecting using a VPN/proxy**.
> [@Moin](#):
>
> it includes an `about.json` file as if it were a theme component.
Indeed, an `about.json` is redundant for standard plugins, I went ahead and removed it from the repo.
Thanks for all of your feedback @Moin. If you have any other remarks or suggestions feel free to leave them here. The code is fully open source and any contribution is welcome: [GitHub - ProxyTracer/discourse-proxytracer](https://github.com/proxytracer/discourse-proxytracer/).
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [April 14, 2026, 2:09am UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/8 "2026-04-14T02:09:48Z")
@ProxyTracer When I attempt to log with cloudflare warp return ‘unknown error’ and not the blocked message
---
### Author:  [@ProxyTracer](https://meta.discourse.org/u/ProxyTracer)
#### Post date: [April 14, 2026, 11:45pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/9 "2026-04-14T23:45:50Z")
> [@eisammy](#):
>
> @ProxyTracer When I attempt to log with cloudflare warp return ‘unknown error’ and not the blocked message
Great catch! This should be fixed in version 0.1.1. Could you confirm if upgrading resolves the issue for you?
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [August 26, 2026, 5:29pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/10 "2026-08-26T17:29:39Z")
I am testing your service and would like to know if there is any conflict with ‘templates/cloudflare.template.yml’ and whether the plugin will support any future updates to the Discourse core.
---
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [August 26, 2026, 5:45pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/11 "2026-08-26T17:45:14Z")
I wonder what the middle ground could be for not losing users like me, in a privacy-respecting community.
---
### Author:  [@ProxyTracer](https://meta.discourse.org/u/ProxyTracer)
#### Post date: [August 26, 2026, 5:55pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/12 "2026-08-26T17:55:47Z")
Thanks for testing! The documentation in the README.md regarding [Cloudflare integration](https://github.com/proxytracer/discourse-proxytracer/#direct-cloudflare-integration-standard-installation) clearly recommends the inclusion of `"templates/cloudflare.template.yml"` as it’s necessary to ensure that Discourse extracts the user’s real IP when the forum is behind Cloudflare. Hence there’s no conflict with that template, in fact including it is necessary.
And yes, we are committed to follow Discourse’ core updates to ensure full compatibility with newer versions.
---
### Author:  [@ProxyTracer](https://meta.discourse.org/u/ProxyTracer)
#### Post date: [August 26, 2026, 6:02pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/13 "2026-08-26T18:02:00Z")
I was wondering if the inclusion of an option that - instead of blocking users - would require merely passing an hCaptcha instead, and making such an option the default would constitute a good compromise, as it’s adding just enough friction to make it more difficult for spammers and ban evaders while still allowing legitimate users who want to safeguard their online privacy through VPNs, Tor and the like. Of course, admins who would still want to stick to full bans on those networks would still have that option. What do you think?
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [August 26, 2026, 6:06pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/14 "2026-08-26T18:06:04Z")
Thank you so much! I just ran a test in a sandbox and it’s working perfectly.
Are you planning to add any functionality related to mobile network IPs/ASNs? A common issue on my forum is users switching from their broadband connection to a carrier’s 4G/5G network to get a different IP, which they then use to try to bypass registration or login restrictions in Discourse.
It would be great to be able to identify when an IP belongs to a mobile carrier’s ASN and, optionally, allow these IPs to be handled differently during registration/login.
This might be a bit out of scope for ProxyTracer, since it’s not necessarily related to VPNs/proxies, but it would be useful for a specific problem regarding how Discourse handles per-IP account limits.
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [August 26, 2026, 6:10pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/15 "2026-08-26T18:10:31Z")
In the case of hCaptcha, I already use it in my installation and it has been working very well! Perhaps a combination of the plugin that apparently is already in the Discourse core with your plugin, maybe as an extra feature?
I like the idea of maintaining the full block, after all, that is the goal, but regarding the IPv4 and IPv6 of fixed and mobile networks, it seems very useful to make this access difficult through challenges, given that AI loves creating accounts on forums.
---
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [August 26, 2026, 6:20pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/16 "2026-08-26T18:20:39Z")
> [@ProxyTracer](#):
>
> What do you think?
Hello, thanks for taking my reply into consideration. It’s really something that interests me, and I find it to be a particularly sensitive implementation for everyone, both as users and administrators.
Honestly, I feel like a robot completing CAPTCHAs to prove I’m human, deliberately acting like a bot. I’ve mentioned in related topics that Anubis’s implementation (POW) feels much more pleasant and functional to me.
I understand that this is out of scope for this project, but from what I can analyze from my position, the use of the CAPTCHA you mentioned would be feasible and could literally not block users who value their privacy and want to contribute without being kept outside.
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [August 27, 2026, 4:25pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/17 "2026-08-27T16:25:08Z")
Another feature the plugin could offer is information on which account attempted to log in using a VPN/proxy.
---
### Author:  [@ProxyTracer](https://meta.discourse.org/u/ProxyTracer)
#### Post date: [August 30, 2026, 8:54pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/18 "2026-08-30T20:54:56Z")
> [@eisammy](#):
>
> Thank you so much! I just ran a test in a sandbox and it’s working perfectly.
Thanks for testing, it is really appreciated!
> [@eisammy](#):
>
> Are you planning to add any functionality related to mobile network IPs/ASNs?
It’s an interesting use case and I do see the value in giving users more granular control like that. This would require a completely new API endpoint as the v1 endpoint is rather limited in scope and only provides a boolean about whether a certain IP is a proxy/VPN or not.
I do have some concerns regarding data accuracy when seeking to implement something like that, as the accuracy with determining whether an IP is used for 4G/5G network is far from ideal, and there are applications where some innocent users could be unfairly punished such as those on 4G/5G Home Wireless Broadband.
With that being said, for now the focus is on improving the v1 endpoint of the API to expand coverage.
> [@eisammy](#):
>
> Another feature the plugin could offer is information on which account attempted to log in using a VPN/proxy.
We’re working on a new testing release of the extension with the captcha option and we’re considering this feature as well, would you find a tab like this sufficient or do you think we can add more columns to it?
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [August 30, 2026, 9:05pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/19 "2026-08-30T21:05:38Z")
This information is more than enough to make tracking request usage easier :high_five:
> [@ProxyTracer](#):
>
> We are working on a new release of the extension and are considering this feature. Would you find a tab like this sufficient, or do you think we could add more columns to it?
Regarding these points, thank you for explaining; I understand that it is complicated.
> [@ProxyTracer](#):
>
> I have some concerns regarding the accuracy of the data when trying to implement something like this, as the accuracy in determining whether an IP is used on a 4G/5G network is far from ideal, and there are applications where some innocent users could be unfairly penalized, such as those using Home Wireless Broadband via 4G/5G.
---
### Author:  [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [August 31, 2026, 6:25pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/20 "2026-08-31T18:25:29Z")
@ProxyTracer I have a question about how requests are counted. I noticed that a request is deducted every time there is a new login, even if the network is not using a VPN or proxies. Is this expected behavior?
I know that the registry needs to be checked regardless, and it probably deducts a request from the panel. Is that correct? Because if I set it to block all sites from these accesses, it will deduct a much larger number of requests from the package I purchased, right?
I thought about increasing the ‘Cache Duration hours’ to something close to 30 days, but it doesn’t seem ideal. Am I wrong?
---
### Author:  [@ProxyTracer](https://meta.discourse.org/u/ProxyTracer)
#### Post date: [September 2, 2026, 5:13pm UTC](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958/21 "2026-09-02T17:13:40Z")
> [@eisammy](#):
>
> Is this expected behavior?
Yes, to determine whether an incoming IP address belongs to a VPN/proxy or not the plugin must query the ProxyTracer API.
However, the result (whether clean or VPN/proxy) is immediately cached in your forum’s Redis database. If that same IP logs in again within your configured Cache Duration hours window, Discourse serves the answer directly from Redis. Thus, no API request is deducted. Same thing applies if you enable the option to block VPN/proxies from all site pages.
> [@eisammy](#):
>
> Because if I set it to block all sites from these accesses, it will deduct a much larger number of requests from the package I purchased, right?
Visitor-level blocking does consume more requests than login-only protection due to anonymous traffic, however the Redis caching ensures that repetitive page views from returning visitors never generate unnecessary API deductions.
> [@eisammy](#):
>
> I thought about increasing the ‘Cache Duration hours’ to something close to 30 days, but it doesn’t seem ideal. Am I wrong?
Dynamic residential/mobile IPs rotate occasionally, and new VPN exit nodes spin up over time. So with a 30-day cache it could be that a previously clean dynamic IP that gets reassigned to a VPN provider wouldn’t be re-checked until the cache expires. This is why something like 4 days would be much better than 30 days.
Hope this clears things up.
[Next page](https://meta.discourse.org/t/proxytracer-vpn-proxy-blocker/399958.md?page=2)