WordPress Plugins
GuardPress Royal AI Firewall ForgeCache SiteVault SiteVault Lite SEObolt Royal Links Royal Affiliates FormForge Royal MCP Pro Royal MCP Royal SMTP Royal Access
Free Tools
SERP Preview Schema Validator Meta Tag Checker SSL Checker HTTP Headers Site Scanner Plugin Scanner Royal Links (Chrome) Royal Access (Chrome)
Pricing Blog Case Studies Switch to Royal Plugin Graveyard Support My Account Cart
Support / Royal MCP / Sucuri / CloudProxy Blocks Royal MCP OAuth Discovery

Sucuri / CloudProxy Blocks Royal MCP OAuth Discovery

If Claude, ChatGPT, or Cursor fails to connect to your Royal MCP endpoint and a direct curl against /.well-known/oauth-authorization-server returns HTTP 404 with a Server: Sucuri/Cloudproxy response header, the Sucuri firewall is intercepting the request at its edge and returning a 404 before your origin sees it. MCP clients read the 404 and abort the OAuth handshake. Fix is in the Sucuri firewall dashboard, not WordPress and not your host.

Before applying this fix

Royal MCP connection issues that look edge-specific are often a plugin conflict, cache layer, or stale OAuth state — work through our Troubleshooting Start Here checklist first if you haven’t already. This article assumes the basics are ruled out and the curl fingerprint below matches.

Very common on SiteGround

SiteGround’s stack fronts most sites with Sucuri / CloudProxy by default, so this pattern shows up more often on SG installs than any other host. If you’re on SiteGround and hit this, also check the SiteGround-specific fix — there’s a companion origin-layer rule that sometimes stacks on top of the Sucuri block.

Symptoms

You’re hitting this specific issue if the following are true:

The Telltale Signs

  • Claude.ai, ChatGPT, or Cursor fails to connect to your Royal MCP endpoint — often silently or with a reference code the client can’t explain
  • A curl against /.well-known/oauth-authorization-server returns HTTP 404 with a response header Server: Sucuri/Cloudproxy (or bare Server: Sucuri)
  • The 404 response body is a large HTML page (typically tens of kilobytes — one observed measurement was ~84 KB) that does not contain the words “Sucuri” or “CloudProxy” anywhere in the visible text — it’s an unbranded generic 404 template
  • Your site homepage loads normally at HTTP 200 — only the OAuth discovery path returns 404
  • Royal MCP’s Activity Log (WP Admin → Royal MCP → Activity Log) stays empty for every failed connection attempt — requests never reach WordPress
  • Your site is fronted by Sucuri firewall (either directly or bundled with your host — SiteGround is the most common example)
Why body content won’t match “Sucuri”

Sucuri’s edge 404 template is an unbranded generic HTML page. There is no “Blocked by Sucuri” text, no branding image, nothing you can grep for. The only reliable Sucuri signal on a blocked 404 is the Server response header. If you see Server: Sucuri/Cloudproxy on the 404, you have the fingerprint — body content will not give you a second confirmation.

How to Confirm It’s Sucuri

A 30-second curl test confirms the signature. Run from any terminal — replace example.com with your actual domain:

Test the OAuth discovery URL and inspect the Server header

curl -I https://example.com/.well-known/oauth-authorization-server

The diagnostic fingerprint is HTTP/2 404 with a Server: Sucuri/Cloudproxy (or Server: Sucuri) header. Response looks like:

HTTP/2 404
server: Sucuri/Cloudproxy
content-type: text/html; charset=UTF-8
content-length: 83816

Confirm the 404 comes from Sucuri’s edge, not your origin

curl -sI https://example.com/.well-known/oauth-authorization-server | grep -i "^server:"

Sucuri edge 404s report server: Sucuri/Cloudproxy. Origin 404s (from nginx/Apache/PHP) report server: nginx or server: Apache. Confirming the header is Sucuri narrows the fix location to the Sucuri dashboard.

Windows PowerShell: PowerShell aliases curl to Invoke-WebRequest; use curl.exe -sI ... | Select-String -Pattern "^server:" instead.

Confirm the block is scoped to /.well-known/, not domain-wide

curl -I https://example.com/

Your site homepage should return HTTP 200 with normal WordPress output (Server header will still be Sucuri/Cloudproxy — that’s expected, all Sucuri-fronted traffic carries that header). The point of this test is that HTTP 200 confirms Sucuri is proxying your site correctly — only specific paths are being blocked.

Why the Activity Log stays empty

Sucuri’s edge intercepts blocked requests before they reach your origin server, which means WordPress never runs and Royal MCP’s Activity Log never gets a chance to log the request. An empty Activity Log combined with the Server: Sucuri/Cloudproxy header on the 404 is conclusive.

The Fix — Allow the OAuth Paths in the Sucuri Dashboard

Sucuri firewall runs at its own edge, ahead of your host and ahead of WordPress. The fix is inside the Sucuri firewall dashboard under Access Control → Allow URL Paths (or by opening a support ticket with Sucuri if you can’t reach the dashboard yourself). This is a routine change on their end.

Option A — Fix it yourself (if you have Sucuri dashboard access)

Log in to the Sucuri firewall dashboard

Go to waf.sucuri.net and sign in. If your Sucuri account is managed by your host (SiteGround, WP Engine, etc.), you may not have direct access — jump to Option B below.

Open Access Control → Allow URL Paths

In the left sidebar select your protected site, then navigate to Access Control. Look for the Allow URL Paths section (labeled Whitelist URL in some dashboard versions). This lets you specify paths that should be allowed through the firewall to your origin.

Add these five path entries

/.well-known/oauth-authorization-server
/.well-known/oauth-protected-resource
/authorize
/token
/register

Save each entry. Propagation is typically within a minute or two — if it hasn’t taken effect after that, purge the Sucuri edge cache (Performance → Clear Cache) and retest.

Retest with curl

Re-run the curl from the “How to Confirm” section. You should now see a JSON body (the OAuth discovery document) instead of the 404 HTML.

Sucuri’s “Allow URL Paths” is a bypass, not an intersection

Sucuri support has confirmed that entries in Allow URL Paths mean “this URL is allowed from any IP address” — they are NOT filtered by any other Access Control rules you may have (IP allowlists, geo-blocks, etc.). Requests on these paths still pass through Sucuri’s IDS signature engine — malicious payloads will still get blocked — but the paths themselves are unrestricted by any of your other Sucuri access controls. This is exactly what MCP discovery needs.

Option B — Ready-to-paste request for Sucuri support (or your host)

If you can’t reach the Sucuri dashboard yourself (managed hosting, delegated account), open a ticket with Sucuri support at support.sucuri.net or with your hosting provider’s support team. Copy the text below into the ticket — substitute example.com with your actual domain:

Subject: Please add OAuth paths to Allow URL Paths for example.com

Hi,

We’re running the Royal MCP WordPress plugin on example.com,
which lets AI assistants like Claude, ChatGPT, and Cursor
connect to our site via the Model Context Protocol (MCP).
The connection requires OAuth 2.0 discovery and token endpoints
to reach our origin (they are handled by the WordPress plugin,
not by static files).

Right now the Sucuri firewall is returning a 404 for
/.well-known/oauth-authorization-server before the request
reaches our origin, and MCP clients abort the OAuth handshake.

Please add the following URL paths to Allow URL Paths for
example.com in the Sucuri firewall Access Control settings:

  /.well-known/oauth-authorization-server
  /.well-known/oauth-protected-resource
  /authorize
  /token
  /register

Important: please use path-based rules (Allow URL Paths), NOT
IP allowlists. Claude.ai and other MCP client backends connect
from constantly-rotating IP ranges, so an IP-based rule will
silently break within a few weeks. Path scope is the correct
mechanism.

These are standard WordPress REST API + OAuth 2.0 (RFC 8414)
endpoints. Allowing them will not reduce security — they
are the plugin’s own authenticated endpoints subject to
WordPress’s standard capability checks, and Sucuri’s
IDS signature engine still applies on Allow URL Paths.

Thanks in advance.
If your host or Sucuri asks “why can’t you just whitelist your IP?”

Claude.ai and Anthropic’s backend connect from constantly-rotating IP ranges. You can’t whitelist a fixed set of Anthropic IPs, so path-based rules are the correct approach. The paste-ready text above already explains this — point them at this article if they need further convincing.

Retry the connection

Once the paths are allowed in Sucuri (or the support ticket is resolved), the fix is immediate:

  1. Re-run the curl test from the “How to Confirm” section above. You should now see a normal OAuth metadata JSON response, not a Sucuri 404.
  2. In Royal MCP’s admin notice for this issue, click Re-check now to invalidate the cached status. The notice should disappear on the next admin page load.
  3. In your MCP client, delete the existing Royal MCP connector if present, wait 30 seconds, then re-add it fresh. This forces the full OAuth flow from scratch rather than reusing cached failure state.
  4. Complete the authorize consent screen. Royal MCP’s Activity Log should now show entries the moment you click “Authorize.”

What NOT to Try (WordPress-Side Fixes Won’t Help)

Sucuri runs at its own edge, in front of your host and in front of WordPress. That means the following common troubleshooting steps will NOT resolve this issue — don’t waste time on them:

What Royal MCP Already Does for You

Royal MCP detects this exact failure mode automatically. When the plugin’s well-known-endpoint self-check sees a 404 response with Server: Sucuri/Cloudproxy in the headers, it surfaces a dismissible admin notice on the Plugins screen and Royal MCP settings linking back to this page.

So future customers on Sucuri-fronted sites (very common on SiteGround) land here from inside their own WordPress admin instead of having to search for “Royal MCP can’t connect” and stumble across the diagnosis. The plugin can’t auto-fix the block for you — Sucuri is entirely outside WordPress’s reach and the customer’s Sucuri dashboard change is the only mechanism — but the notice makes the diagnosis fast.

Re-check button on the admin notice

Every host-blocked admin notice in Royal MCP now includes a Re-check now button. After you’ve made the Sucuri dashboard change, click Re-check on the notice — the plugin will re-probe your OAuth discovery endpoint in the same request and the notice will disappear on the next page load if the fix worked. No need to wait for the 12-hour cache to expire (which shortens to 1 hour automatically on WAF-fronted sites like Sucuri anyway).

Still Stuck? Two Support Paths

If Sucuri completed the path allow and Claude still can’t connect:

Community Support (free) — wp.org Plugin Forum

Post a new thread at wordpress.org/support/plugin/royal-mcp/. Include the diagnostic info listed below in your post.

Premium Support (paid) — direct one-on-one help

For priority response (24-hour SLA) and hands-on diagnostic help, our Premium Support tier is $149/year.

Information to include in your post or ticket

  • Full curl output for /wp-json/royal-mcp/v1/mcp and /.well-known/oauth-authorization-server BEFORE and AFTER Sucuri applied the path allow (use curl -i, not just -I, so we see the body)
  • Your hosting provider (SiteGround, self-hosted, etc.) — helps us cross-reference known-good Sucuri patterns for that host
  • Confirmation the Sucuri path allow is in place (screenshot of the Sucuri Access Control panel, or paste any confirmation email from Sucuri support)
  • Royal MCP version from WP Admin → Plugins
  • Whether the Activity Log now shows entries during a failed attempt (any entry means the request now reaches WordPress — different diagnosis)
Back to Troubleshooting Start Here Back to Royal MCP Support