Web Server 301-Redirects /register to /register/

Confirm What’s Happening

From any terminal:

curl -i -X POST -H "Content-Type: application/json" -d '{}' https://example.com/register

You’re hitting this issue if you see:

If the response is a 4xx, 5xx, or 200, you’re looking at a different issue and this guide doesn’t apply.

Why This Happens

Nginx, Apache, and many .htaccess-based hosts emit a 301 redirect on any non-file URL path that lacks a trailing slash. The behavior is built into:

• Nginx: when a request path matches a directory location (or could match one), Nginx adds the slash via an internal redirect
• Apache mod_dir: the DirectorySlash directive (default On) does the same thing
• Apache mod_rewrite / .htaccess: many cPanel and shared-host default configs include a canonicalization rule that forces trailing slashes

For browser-facing pages this is fine — browsers follow 301 on GET. For OAuth, RFC 7231 specifically says clients SHOULD NOT auto-follow 301 redirects on POST (the response method-change behavior is undefined and unsafe). Real-world OAuth clients including claude.ai, mcp-remote, and Anthropic’s backend treat a 301 on a POST as a failure.

Royal MCP’s rewrite rules in 1.4.22+ match both bare and trailing-slash variants of /register, /authorize, and /token — so when WordPress handles the request internally, both forms work. But this web-server 301 happens before WordPress even sees the request, so the plugin can’t fix it from PHP. It has to be fixed in your web-server config.

Fix: Nginx

Add a location block above your main location / block in your server config (usually /etc/nginx/sites-available/your-site.conf on Debian/Ubuntu, or /etc/nginx/conf.d/your-site.conf):

location = /register {
    try_files $uri $uri/ /index.php?$args;
}
location = /authorize {
    try_files $uri $uri/ /index.php?$args;
}
location = /token {
    try_files $uri $uri/ /index.php?$args;
}

The = prefix means “exact match” — Nginx evaluates these before any prefix or regex location, so the request goes straight to PHP without canonicalization. After saving, reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

Re-run the curl test from the top — you should now see HTTP/2 200 or a JSON error response instead of HTTP/2 301.

Fix: Apache (with mod_dir)

In your virtual host config or in your site’s root .htaccess, add before the WordPress block:

<IfModule mod_dir.c>
    <LocationMatch "^/(register|authorize|token)$">
        DirectorySlash Off
    </LocationMatch>
</IfModule>

If you don’t have <LocationMatch> available (it requires server-config or virtual-host-level access), use the .htaccess-only version instead:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^(register|authorize|token)$ index.php?$0 [L]
</IfModule>

Add this above the existing WordPress # BEGIN WordPress block in .htaccess. Reload Apache (sudo systemctl reload apache2) or just save the .htaccess file (Apache re-reads it per-request).

Re-run the curl test — you should no longer see a 301.

Fix: LiteSpeed

LiteSpeed reads .htaccess files like Apache does, so the mod_rewrite snippet from the Apache section above works identically. After saving, you may need to clear the LiteSpeed cache:

WP Admin → LiteSpeed Cache → Toolbox → Purge All

Re-run the curl test to confirm.

Verify the Fix Worked

1. Run the curl POST command from the top of this page again — you should now see a JSON response or a 4xx/5xx (Royal MCP responding), not a 301
2. In WordPress admin, go to WP Admin → Royal MCP → Settings and save the form to invalidate the 12-hour self-check transient
3. Reload any Royal MCP admin page — the “OAuth registration may be blocked” notice should no longer appear
4. Reconnect Claude.ai (or whichever MCP client was failing) — the OAuth handshake should now complete

Still Stuck? Two Support Paths

If you’ve worked through the steps above and your connection still fails:

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 and community members often help disambiguate issues faster than email could. 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. Includes a 30-day “if it breaks again” follow-up window on every resolved ticket.