ChatGPT’s MCP Connector Fails with HTTP 466 — Intermediary WAF Blocks OAuth /register

Before You Apply the Fix — Confirm This Is Your Issue

The specific error text ChatGPT surfaces is “Dynamic client registration failed: registration endpoint returned N”, where N is a value in the 460–469 range. That’s the leading fingerprint. The 60-second curl test below verifies whether an intermediary layer is actually emitting the code — because Royal MCP’s own handler doesn’t use those codes at all, the fact that you saw one means the response came from somewhere between the OAuth client and PHP.

Symptoms

How to Verify It’s This Specific Issue

One curl command from outside your site confirms the diagnosis and identifies which layer emitted the code. Run it from any terminal — macOS, Linux, Windows PowerShell, WSL all work. Don’t run it from inside your hosting account’s SSH; the test is checking what an outside HTTP client sees, so it has to come from outside your host.

curl -i -X POST \
  -H "Content-Type: application/json" \
  -H "User-Agent: python-httpx/0.27.0" \
  -d '{"redirect_uris":["https://chatgpt.com/connector_platform_oauth_redirect"],"client_name":"ChatGPT","token_endpoint_auth_method":"none"}' \
  https://example.com/register

curl -i -X POST \
  -H "Content-Type: application/json" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
  -d '{"redirect_uris":["https://example.com/cb"],"client_name":"diag"}' \
  https://example.com/register

The Fix — Path-Exclude the OAuth Endpoints from the WAF Layer

The pattern is the same whichever WAF is intercepting the request: get the OAuth endpoints excluded from the layer that’s emitting the code. Which team applies the change depends on how much control your host gives you. Try Option A first; if you don’t have direct access to the WAF, jump to Option B.

Option A: Path-exclude the OAuth endpoints yourself (if you control the WAF)

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

Option B: Open a hosting support ticket for path-based exclusion

If your WAF is managed by the host (Websupport, most managed-WordPress hosts, most shared cPanel plans where cPanel doesn’t expose the ModSecurity control), you’ll need to ask them to apply the exclusion. Send them this exact text:

Your web application firewall is returning HTTP status N (a value in the
460-469 range) on POST requests to /register on my WordPress site. The
plugin behind that endpoint (Royal MCP - RFC 7591 Dynamic Client
Registration for MCP OAuth) does not emit any status code in that
range - the response is coming from your WAF layer, not from PHP.

I need path-based exclusions from the WAF for the following OAuth
endpoints so my MCP integration can complete Dynamic Client
Registration:

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

Please also check the WAF audit log on my domain for the exact rule
(or rule set) that fired on POST /register with a python-httpx
User-Agent and let me know which rule triggered.

Most managed hosts respond within a few hours and apply the exclusion server-side. If they push back and ask you to whitelist the User-Agent instead, that’s a partial fix — it will work today, but if OpenAI ever updates their OAuth backend’s HTTP client (or changes its version string), the UA whitelist stops matching. Path-based exclusions on the OAuth endpoints are the durable fix.

Option C: Confirmed host walkthroughs

Why Does This Happen?

The HTTP 4xx status range from 460 to 499 is officially unassigned in the IANA HTTP Status Code Registry. That leaves the range available for “intermediary” or “vendor-specific” uses, and several security and edge-network products have picked codes in that range for their own custom responses. nginx has a documented limit_req_status directive that accepts any 4xx code. Some WAFs let administrators override the default 403 block-action with any 4xx code they prefer, so their responses don’t collide with application-level 403 responses in log analysis. ModSecurity supports the same via custom SecAction directives.

Because the range is unassigned, most HTTP clients don’t have specific handling for these codes and just surface them as raw “server returned N” errors. OpenAI’s MCP connector does exactly this — it reports the numeric status verbatim in the error message, which is what you see in ChatGPT’s UI. That’s the smoking gun: Royal MCP never emits 466, so the OAuth client that surfaced “registration endpoint returned 466” had to have gotten the 466 from somewhere else.

Claude Desktop connects through mcp-remote, a Node.js bridge running locally on the user’s machine that talks to your MCP server directly. Claude.ai web goes through Anthropic’s server-side OAuth backend. ChatGPT’s connector goes through OpenAI’s server-side OAuth backend, which uses python-httpx with additional client-metadata fields specific to their integration. Some WAFs fingerprint the ChatGPT-flavored request specifically — typically because the exact combination of python-httpx User-Agent + OpenAI-shaped DCR body trips a rule that neither Claude path matches. That’s why the split behavior looks so strange: same URL, one OAuth client works, the other doesn’t.

Quick Alternative: Use Claude for MCP While You’re Waiting

If you need MCP working today and your host’s support team is going to take a few days to apply the exclusion, Claude Desktop and Claude.ai web are unaffected by this class of block. They complete OAuth successfully because their MCP client has a different HTTP signature. If your primary goal is having MCP working on your site — not specifically ChatGPT — connect Claude first, verify tool calls work, then follow up with your host on the WAF ticket to get ChatGPT working too.

Claude Desktop’s API-key path (which bypasses OAuth entirely) is documented at Connect Claude Desktop via API Key (Skip OAuth) — that’s the most robust connection method when WAF configuration is fighting you.

Still Stuck? Two Support Paths

If you’ve worked through the steps above and ChatGPT still fails to connect:

Community Support (free) — wp.org Plugin Forum

Post a new thread at wordpress.org/support/plugin/royal-mcp/. The Royal Plugins team monitors the forum regularly. Include the curl output from the Verify section — the response headers and body identify the WAF layer, and without that the reply loop is much slower.

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. Includes a 30-day “if it breaks again” follow-up window on every resolved ticket.