Connection problem

Hi @alexcz ,

Thanks for the report. Quick note first: the ofid_* codes are Anthropic-side reference IDs (Claude’s OAuth backend generates them to trace failures on their side), so they don’t decode to a specific error on our end. Two different ofid_ codes across two attempts usually means the request is failing at a different step each time.

On a Hostinger + LiteSpeed + hcdn + Wordfence stack there are four layers a request can be dropped at before Royal MCP ever sees it, so the fastest path is to narrow down which layer. Three quick checks (each under 2 minutes) and will tell us where to look:

1) ACTIVITY LOG CHECK (most important, 30 seconds)

In wp-admin go to Royal MCP → Activity Log. Reproduce the failing connection attempt in Claude, then refresh the log page.

– If you see rows with action starting oauth: in the last few minutes (even ERROR rows) → the request reached WordPress and we can debug from what the plugin logged.

– If the log stays empty after a reproduced failure → the request never reached PHP. Hostinger’s hcdn CDN, LiteSpeed, or Wordfence dropped it upstream.

Wordfence Live Traffic won’t show a block from hcdn or LiteSpeed — Wordfence only records what makes it to PHP. So “no block in Live Traffic” is fully consistent with hcdn or LiteSpeed silently dropping the request upstream.

2) OUTSIDE-IN CURL PROBE (2 minutes)

Our start-here doc has a 30-second probe that shows whether your edge is interfering with OAuth discovery:

https://royalplugins.com/support/royal-mcp/troubleshooting-start-here.html

Run the two curl lines from “Step 0” from your own machine (not from the WordPress server) and paste the output back. That will tell us if hcdn is serving a challenge page, stripping headers, or caching the OAuth endpoints.

3) CONTEXT

– Which client are you connecting from — Claude.ai web, Claude Desktop, something else?
– Does the WordPress OAuth consent screen render at all, or does it fail before you get there?
– If consent renders and you click Approve — does the browser bounce back to the client and then show the error, or does it fail during the bounce?

“Consent completes, then ofid_ appears” points at the token-exchange step, which Anthropic’s backend performs server-to-server against your site. That step is the most sensitive to host-layer IP blocks or WAF rules on POST bodies — if that’s your pattern, the fix is usually a specific ask to Hostinger support.

While you’re at it, one thing to try that costs nothing: open Royal MCP → Settings and click Reset OAuth State. That wipes any stale records from a half-completed flow. Won’t fix an upstream block, but it rules out corrupted state as a variable.

Post back the Activity Log result + the two curl outputs and we’ll narrow it in the next reply.

RP Team

• This reply was modified 1 week, 2 days ago by rpteam. Reason: bad formatting