Sucuri WAF Blocking Real Visitors on WordPress? The Fix
You turned on Sucuri to keep the bad guys out, and now a real customer is emailing you a screenshot of "Access Denied - Sucuri Website Firewall" instead of your checkout page. This happens more often than Sucuri's marketing pages let on, and it's almost always fixable in a few minutes once you understand how the firewall actually sits in front of your site.
Symptom: What You're Seeing
A few common variations, all pointing at the same root cause:
- Visitors see a Sucuri "Access Denied" or "Your request has been blocked" page instead of your site.
- You or your team get locked out of
wp-adminfrom a home or office IP that hasn't changed in months. - A payment gateway webhook (Razorpay, Stripe, PayPal IPN) stops reaching your site after Sucuri goes in front of it, and orders sit stuck as pending.
- Your cPanel access logs and any IP-based plugin (Wordfence, fail2ban, GeoIP redirects) suddenly show every visitor coming from Sucuri's proxy IPs instead of their real address.
- Legitimate form submissions or REST API calls get rejected with a generic firewall block page instead of a normal HTTP error.
Why This Happens: How Sucuri Actually Sits in Front of Your Site
Unlike Wordfence or a security plugin, Sucuri's WAF (the paid firewall product, not just the free malware scanner plugin) works as a DNS-level reverse proxy. You point your domain's A record — or your nameservers — at Sucuri instead of your hosting IP. Every request hits Sucuri's edge servers first, gets filtered, and only clean traffic is forwarded to your actual origin server. That's the same basic model as Cloudflare, but Sucuri's rule set is tuned more aggressively toward WordPress-specific attack patterns, which is exactly why it catches more real users in the crossfire.
1. Your Origin Server Never Sees the Real Visitor IP
Because Sucuri proxies every request, your server's access logs, any IP allowlist you've set in .htaccess, and plugins like Wordfence or Limit Login Attempts all see Sucuri's proxy IP instead of the visitor's actual IP — unless you specifically configure them to read the X-Sucuri-ClientIP header. This is the single biggest cause of "legitimate visitor blocked" reports: your own security stack is now blocking Sucuri's proxy range, not the attacker.
2. Overzealous Rule Matching on Normal Traffic
Sucuri's WAF ships with rules tuned to catch SQL injection patterns, XML-RPC abuse, and known WordPress exploit signatures. Perfectly normal traffic can trip these: a search query with an apostrophe, a WooCommerce checkout with unusual characters in an address field, or a webhook payload from a payment gateway that includes JSON with characters the rule engine reads as suspicious.
3. Webhooks and API Calls Getting Blocked Outright
Payment gateway webhooks (Razorpay, PayPal IPN, Stripe) and REST API calls from other services don't behave like browser traffic — no cookies, no typical headers, sometimes rapid repeated calls. Sucuri's brute-force and bot-detection rules can flag this pattern and block it before it ever reaches WordPress, which is why orders get stuck on "pending" even though the gateway shows the payment as successful.
4. DNS Wasn't Fully Cut Over, So You're Bypassing (or Fighting) the Proxy
If only some DNS records point through Sucuri while others (like a subdomain or a direct IP someone still has bookmarked) hit the origin server directly, you'll get inconsistent behavior — blocked on the main domain, fine on a subdomain, or vice versa — which looks like a random false positive but is really a DNS configuration gap.
The Fix
Step 1: Check the Audit Trail Before Touching Anything
Log in to your Sucuri dashboard (dash.sucuri.net) and open Firewall > Audit Trail. This shows the exact request, the rule ID that fired, and the IP that got blocked. Don't guess — this tells you whether it's a rule problem, an IP problem, or a real threat you actually want blocked.
Step 2: Whitelist Trusted IPs Properly
In the Sucuri dashboard go to Firewall > Settings > Whitelist and add the IPs your team, office, or a specific service (like your payment gateway's webhook source IPs) connects from. For payment gateways, check the provider's documentation for their published webhook IP ranges rather than whitelisting a single IP that might change.
Step 3: Fix the Real-IP Problem at the Server Level
This is the fix that solves the "everything shows Sucuri's IP" issue for good. Add Sucuri's proxy IP ranges as trusted proxies so your server reads the real visitor IP from the X-Sucuri-ClientIP header instead of the connection IP. On a cPanel/Apache server with mod_remoteip available, or via an .htaccess rule:
<IfModule mod_setenvif.c>
SetEnvIf X-Sucuri-ClientIP "^(.*)$" HTTP_X_SUCURI_CLIENTIP=$1
</IfModule>For WordPress specifically, add this near the top of wp-config.php so WordPress itself (and plugins reading $_SERVER['REMOTE_ADDR']) see the correct visitor:
if (!empty($_SERVER['HTTP_X_SUCURI_CLIENTIP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_SUCURI_CLIENTIP'];
}Once this is in place, Wordfence, fail2ban, your access logs, and any IP-based logic will start working against the real visitor again instead of Sucuri's shared proxy range.
Step 4: Adjust Rule Sensitivity for Known-Safe Endpoints
If a specific WooCommerce field or a specific REST API route keeps tripping the WAF, you can create a targeted whitelist rule for that exact URL path in Firewall > Settings > Whitelist > URL Path rather than disabling protection site-wide. Keep it scoped — whitelist the checkout endpoint, not /*.
Step 5: Confirm DNS Is Fully Cut Over
Run a quick check to make sure nothing is bypassing the proxy:
dig +short yourdomain.com
dig +short www.yourdomain.comBoth should resolve to Sucuri's IPs, not your origin server's IP. If you find records still pointing directly at your hosting IP, update them in your DNS zone (cPanel's Zone Editor if you're managing DNS there) and give it time to propagate before testing again.
Prevention
- Set up the
X-Sucuri-ClientIPforwarding at the same time you enable the firewall — don't wait for a lockout to discover the problem. - Keep a documented list of webhook/service IPs (payment gateways, uptime monitors, staging tools) and whitelist them proactively instead of reactively.
- Check the Audit Trail weekly for the first month after enabling Sucuri — patterns of false positives usually show up early and are easy to tune once you see them.
- Test checkout, contact forms, and any webhook-driven integration immediately after DNS cutover, not days later.
Frequently asked questions
Why does Sucuri show every visitor with the same IP address in my logs?
Because Sucuri proxies all traffic through its own servers before forwarding it to your site. Your server sees the connection from Sucuri's IP unless you configure it to read the real visitor IP from the X-Sucuri-ClientIP header, as shown in the fix above.
Will whitelisting an IP in Sucuri turn off protection for everyone else?
No. Whitelisting only exempts the specific IP, IP range, or URL path you add — every other visitor still goes through the full firewall ruleset.
My payment gateway webhook is being blocked. Is that a Sucuri problem or a gateway problem?
Check the Sucuri Audit Trail first. If you see a blocked request matching the webhook's timing and source IP, it's Sucuri's WAF flagging the automated request pattern — whitelist the gateway's published webhook IPs to fix it.
Do I need mod_remoteip installed, or does the wp-config.php snippet alone work?
For WordPress-level fixes (plugins, REMOTE_ADDR checks in PHP), the wp-config.php snippet is usually enough on its own. mod_remoteip is only needed if you want Apache itself — and things like raw access logs — to log the correct IP.
How long does it take for a whitelist change in Sucuri to take effect?
Whitelist changes in the Sucuri dashboard typically apply within a minute or two, since they're applied at Sucuri's edge rather than requiring DNS propagation.