Discourse
The official ProxyTracer integration for Discourse . This plugin brings enterprise-grade IP intelligence to your community, automatically detecting known VPNs, proxies, datacenters and Tor nodes and giving you the option of preventing them from registering, or logging in, or even from viewing your Discourse forum entirely.
The plugin is distributed through this Github repository .
Features
- Granular control allowing administrators to enforce IP validation during new user registrations, existing user authentication, or globally for all site visitors.
- Built-in Redis caching stores recent IP address evaluations, drastically reducing external API calls and ensuring zero latency.
- 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.
Installation
-
Access your server via SSH and navigate to your Discourse directory:
cd /var/discourse -
Open your container configuration file for editing:
nano containers/app.yml -
Locate the
hookssection and append the repository clone command directly below thedocker_managerinstallation:hooks: after_code: - exec: cd: $home/plugins cmd: - git clone https://github.com/discourse/docker_manager.git - git clone https://github.com/proxytracer/discourse-proxytracer.git -
Save the configuration file and rebuild your Discourse container to compile the plugin:
./launcher rebuild app
Configuration
- Procure a standard API key from the ProxyTracer Dashboard .
- Navigate to your Discourse administration panel: Admin → Plugins → ProxyTracer to find ProxyTracer’s settings.
- Input your API key into the
ProxyTracer API Keyfield. - Enable the protection parameters by toggling
Enabled during Signup,Enabled during Loginand/orEnabled for All Visitors. - Add any trusted IPs or CIDR ranges to the
Whitelisted IPslist. - (Optional) Adjust the API timeout and Redis cache duration limits to suit your server’s specific traffic requirements.
- (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 or VPN.

Network Configuration: Cloudflare & Reverse Proxies
For ProxyTracer to function effectively, the Discourse application must receive the true client IP address. If your infrastructure utilizes Cloudflare or another reverse proxy, Discourse may default to logging the proxy node’s IP address thus making ProxyTracer’s job unreliable.
Please follow the configuration guidelines below that match your server’s architecture to ensure accurate IP forwarding.
Direct Cloudflare Integration (Standard Installation)
This applies if your Discourse server connects directly to the internet and utilizes Cloudflare exclusively for DNS and edge proxying. In this standard setup, you must configure Discourse to trust Cloudflare’s IP ranges and extract the true client IP from the incoming headers.
- Connect to your server via SSH and edit your container configuration:
nano /var/discourse/containers/app.yml - Locate the
templates:block and append the official Cloudflare templatetemplates/cloudflare.template.yml:templates: - "templates/postgres.template.yml" - "templates/redis.template.yml" - "templates/web.template.yml" - "templates/web.ratelimited.template.yml" - "templates/cloudflare.template.yml" - Save the file and rebuild the Discourse container to apply the changes:
./launcher rebuild app
Multi-Layer Proxy Architecture (Cloudflare + Local Reverse Proxy)
This applies if your Discourse instance is routed through a local server management panel or reverse proxy (e.g., CloudPanel, Nginx Proxy Manager, Traefik, Plesk) which sits behind Cloudflare. In a multi-layer (or “double”) reverse proxy architecture, the standard Discourse cloudflare.template.yml will fail because the traffic is handed to Discourse by your local network interface, not directly by Cloudflare. Do not use the Cloudflare template in this scenario.
Instead, you must configure your local reverse proxy to strip the Cloudflare node IPs and forward the CF-Connecting-IP header directly to the Discourse Docker container.
Nginx Example:
Locate your location / or @reverse_proxy directive within the host’s Nginx configuration and modify the IP forwarding headers as follows:
proxy_set_header X-Real-IP $http_cf_connecting_ip;
proxy_set_header X-Forwarded-For $http_cf_connecting_ip;Save the configuration and reload your host’s Nginx service. A Discourse container rebuild is not required for this step.
Validation and Testing
To verify that your networking configuration is successfully passing the correct data to ProxyTracer:
- Navigate to your Discourse administrative dashboard: Admin → Users.
- Review the
Registration IPorLast IPcolumns for recent activity.- Incorrect Setup: If you observe Cloudflare IPs (see here for a full list) or local network IPs (e.g.,
127.0.0.1,172.x.x.x), IP forwarding is failing. ProxyTracer cannot protect your site in this state. - Correct Setup: If you observe standard, unique residential IP addresses, your network architecture is configured correctly and ProxyTracer is actively monitoring your traffic.
- Incorrect Setup: If you observe Cloudflare IPs (see here for a full list) or local network IPs (e.g.,
License
This plugin is licensed under the GNU Affero General Public License v3.0 (AGPLv3).