WordPress Plugins
GuardPress Royal AI Firewall ForgeCache SiteVault SiteVault Lite SEObolt Royal Links Royal Affiliates FormForge 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 / StackCDN Interferes with Royal MCP OAuth

StackCDN Interferes with Royal MCP OAuth

If Claude’s custom connector fails intermittently against your Royal MCP endpoint — consent screen sometimes renders, sometimes not, with two different reference IDs across attempts — and your response headers include x-provided-by: StackCDN, the CDN sitting in front of WordPress is interfering with the OAuth callback and token-exchange steps. This is not a bot block; it’s caching or regional-routing inconsistency. Common on 20i hosting and hosts reselling StackCDN. Fix is host-side.

Before applying this fix

Royal MCP connection issues that look host-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 header signature below matches.

Different from bot-block failure modes

This article covers intermittent OAuth failures with a StackCDN header signature. If your issue is a consistent block (HTTP 403, 406, 429, or an HTML challenge page on every request), you’re looking at a different layer — start with Troubleshooting Start Here and match your symptom to the right guide. StackCDN interference specifically produces flaky behavior, not a hard block.

Symptoms

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

The Telltale Signs

  • Claude.ai (web) fails intermittently with an ofid_… reference code — not the same code every time; you see two or more distinct codes across attempts in the same session
  • The OAuth consent screen sometimes renders, other times fails before reaching it — behavior is inconsistent even with identical retry conditions
  • Response headers on your site include x-provided-by: StackCDN
  • Response headers include x-via: or similar region markers that CHANGE between requests (e.g., SIN1, LAX1, CDG1 alternating within one session) — multi-region edge routing
  • Royal MCP’s Activity Log (WP Admin → Royal MCP → Activity Log) stays completely empty for every failed connection attempt
  • Your hosting provider is 20i, or any host reselling StackCDN under a white-label brand
Why the Activity Log stays empty

StackCDN terminates the connection at the edge. When the OAuth flow fails before token exchange completes, no tool call ever runs, so Royal MCP’s Activity Log stays empty even if the /authorize endpoint was reached. Empty log means “no successful tool invocation happened,” not “no request reached WordPress.”

How to Confirm It’s StackCDN

A curl test against your OAuth endpoints reveals the CDN layer. Run from any terminal — replace example.com with your actual domain:

Inspect response headers on the OAuth discovery URL

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

Look for the definitive signature in the response headers:

x-provided-by: StackCDN

Presence of this header confirms StackCDN is terminating the request at its edge.

Repeat the same curl to look for multi-region routing

for i in 1 2 3; do curl -sSI "https://example.com/.well-known/oauth-authorization-server" | grep -iE "x-via|x-provided-by|cache-control"; echo "---"; done

Watch for x-via: (or similar) values that CHANGE between requests. Different edge regions hitting the same request in one session can produce inconsistent cache and WAF behavior for OAuth state.

Check for cacheable Cache-Control on OAuth endpoints

OAuth flow endpoints must be served with Cache-Control: no-store. If you see public or max-age=<n> on these paths, the CDN may be caching responses that must always be fresh:

curl -sSI -X POST -H "Content-Type: application/json" "https://example.com/wp-json/royal-mcp/v1/mcp" | grep -i cache-control

Royal MCP itself sets no-store on these responses. If a downstream CDN is overriding that header, that’s the interference.

Red herring — PHPSESSID cookie churn is NOT the cause

You may notice a fresh Set-Cookie: PHPSESSID=… on every response from a StackCDN-fronted site. This is worth mentioning to your host as context, but it’s NOT the cause of Royal MCP OAuth failures — Royal MCP stores OAuth state in dedicated database tables (wp_royal_mcp_oauth_tokens, wp_royal_mcp_oauth_clients, wp_royal_mcp_oauth_auth_codes), not in PHP’s $_SESSION. Session cookie churn is a separate hosting quirk. Don’t let a support agent point at it as the root cause.

The Fix — Ask Your Host for Cache Exclusion + Header Passthrough

StackCDN lives at the hosting provider’s layer. The fix is a support ticket to your host (20i or the reseller white-labeling StackCDN) asking for three specific things: cache exclusion for the OAuth paths, header passthrough confirmation, and WAF rule verification on POST bodies.

Ready-to-paste hosting-provider request

Copy the text below into a support ticket with your hosting provider. Substitute example.com with your actual domain:

Subject: StackCDN interference with Royal MCP OAuth on example.com

Hi,

We’re running the Royal MCP WordPress plugin on example.com,
which lets AI assistants like Claude connect to our site via
the Model Context Protocol (MCP). The OAuth 2.0 handshake is
failing intermittently and the response headers show
“x-provided-by: StackCDN” on our OAuth endpoints. We need
three configuration changes on the CDN layer:

1. CACHE EXCLUSION. Please exclude these paths from StackCDN
   cache entirely (they must always be served fresh from origin):

     /wp-json/royal-mcp/v1/*
     /.well-known/oauth-authorization-server
     /.well-known/oauth-protected-resource
     /authorize
     /token
     /register

2. HEADER PASSTHROUGH. Please confirm the following request
   headers are passed through unmodified to origin for those
   paths (not stripped, not rewritten):

     Authorization
     Content-Type
     Accept
     Mcp-Session-Id

3. WAF POST-BODY RULES. Please verify no WAF rule is inspecting
   or blocking POST bodies that contain OAuth code exchange
   fields (grant_type=authorization_code, code=…,
   code_verifier=…, redirect_uri=…) on the paths above.

These are standard WordPress REST API + OAuth 2.0 (RFC 8414)
endpoints. Excluding them from CDN cache will not reduce
performance meaningfully — they are low-traffic, per-user
flow endpoints, not asset requests.

Thanks in advance.
While you’re waiting on your host

Two things to check on your end that occasionally rule out other causes:

  • If you have the WPChat plugin active, temporarily deactivate it. It also sets session cookies and can compound the churn (unlikely to be the root cause but rules it out).
  • Enable WP_DEBUG_LOG in wp-config.php, retry the connection, then check wp-content/debug.log for any OAuth-related entries. This tells you whether the OAuth callback is reaching WordPress at all. Turn WP_DEBUG_LOG back off after diagnosis — leaving it on bloats the log file and may leak file paths in rendered errors.

Retry the connection

Once your host confirms the exclusion + passthrough changes:

  1. Re-run the curl inspection from the “How to Confirm” section above. x-provided-by: StackCDN may still appear, but Cache-Control on the OAuth paths should now be no-store (from origin).
  2. In Claude, delete the existing Royal MCP connector, wait 30 seconds, then re-add it fresh. Try connecting from a browser session with an empty cookie state to rule out client-cached state.
  3. Complete the authorize consent screen. Royal MCP’s Activity Log should now show entries once tools start being called.

What NOT to Try (Common Wrong Turns)

Because the symptom is intermittent rather than a hard block, it’s easy to chase the wrong cause. Skip these:

Still Stuck? Two Support Paths

If your host completed the allowlist 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 your host applied the allowlist (use curl -i, not just -I, so we see the body)
  • Your hosting provider (SiteGround, Bluehost, HostGator, Namecheap, etc.) — helps us cross-reference known-good allowlist patterns for that host
  • Confirmation your host completed the allowlist (paste any confirmation email they sent)
  • Royal MCP version from WP Admin → Plugins
  • Whether the Activity Log now shows entries during a failed attempt (any entry means the request reached WordPress — different diagnosis)
Back to Troubleshooting Start Here Back to Royal MCP Support