Book a demo
Book a demo
Login

Fix MCP OAuth Connection Failures on OpenLiteSpeed Sites

Updated October 9, 2026 · 3 min read

If you run a WordPress MCP server on your own site — such as the Novamira plugin — and the site is hosted on an OpenLiteSpeed (OLS) server, AI clients that sign in over OAuth (Claude Desktop, Claude Code and similar) could fail to connect. A permanent fix is now live: new OLS sites work out of the box, and existing OLS sites are fixed by regenerating the OLS config and toggling the firewall, as described below.

This is specific to an MCP server running on your WordPress site. It does not affect xCloud’s own MCP at app.xcloud.host, which is served by xCloud and unaffected by your site’s config.

Symptoms

On an OpenLiteSpeed site, the OAuth sign-in from an AI client fails in one of two ways:

  • OAuth discovery returns a 404. The client’s request to /.well-known/oauth-authorization-server or /.well-known/oauth-protected-resource on your site returns a LiteSpeed 404 page instead of reaching WordPress, so the client never finds the authorization server.
  • The authorize step returns a 403. The desktop client’s localhost / 127.0.0.1 loopback callback is blocked, so signing in on authorize-application.php, admin.php or wp-login.php fails with a firewall 403.

Application-password connections and non-OLS sites are not affected.

What caused it

  • The generated OLS vhost answered every /.well-known/* request itself, so OAuth discovery never reached WordPress and hit the LiteSpeed 404.
  • The 7G/8G firewall rules blocked any localhost / 127.0.0.1 value in a URL — which is exactly how a desktop app’s OAuth callback works — so the authorize step was rejected with a 403.

Hand fixes applied to a site worked, but regenerating the OLS config or toggling 7G/8G wiped them, so the problem could return.

Fix an existing OpenLiteSpeed site

New OLS sites already include the fix. For an existing OLS site, apply it in two steps from the xCloud dashboard:

Step 1: Regenerate the OpenLiteSpeed config

Open the site’s server in xCloud and regenerate the OpenLiteSpeed configuration. This restores correct /.well-known/ handling so OAuth discovery reaches WordPress. SSL is unaffected — only the ACME challenge path (/.well-known/acme-challenge/) stays served statically, and dot-files such as .env and .git stay blocked.

Step 2: Toggle the 7G/8G firewall off and on

If the 7G or 8G firewall is enabled on the site, turn it off and then on again. This reinstalls the firewall with the loopback-callback exception in place. Switching between 7G and 8G, or off and on, now always leaves exactly one firewall block — no stale 7G sitting next to 8G.

After both steps, reconnect the AI client and complete the OAuth sign-in against your site.

What the fix changes

  • /.well-known/ handling. Only /.well-known/acme-challenge/ is served statically (so SSL issuance and renewal keep working); every other /.well-known/ path is passed to WordPress, which lets OAuth discovery succeed. Dot-files like .env and .git remain blocked.
  • Firewall loopback exception. 7G and 8G now allow a genuine loopback OAuth callback, and only on authorize-application.php, admin.php and wp-login.php when they redirect to it. Every other firewall rule still runs on those pages, and a localhost / 127.0.0.1 value on any other URL is still blocked.
  • Clean firewall state. Toggling 7G ↔ 8G, or off and on, always ends with exactly one firewall block installed.

Still failing after the fix? Two other blockers

A security plugin hides or locks wp-admin

If OAuth discovery now returns JSON but the authorize step still returns a 403 with a message such as “This has been disabled”, the block is coming from a WordPress security plugin rather than the server. Solid Security’s Hide Backend setting, for example, returns 403 for logged-out requests to wp-admin, which includes the OAuth authorization screen. Turn that feature off (or add the authorization URL to its allow list), then retry the sign-in.

Nginx sites on the 7G firewall

Nginx sites running the 7G firewall still block the loopback OAuth callback — this is tracked as a follow-up. Nginx sites on 8G are not affected.

Until it ships, you can add a path-limited exception yourself without disabling the firewall: open the site → Tools → Nginx Customization → Add a New Config, choose Use My Own Config with the 7G Block placement, and limit the bot-check exception to the OAuth paths only (/.well-known/oauth-*, /wp-admin/authorize-application.php, /wp-admin/admin.php and /wp-login.php with the authorize redirect). Use Run & Debug before Save Config. If you would rather not edit the rule yourself, contact xCloud support and mention the loopback OAuth callback on Nginx + 7G.

Still stuck? Contact our support team and mention the MCP OAuth connection on OpenLiteSpeed.

Frequently asked questions

What exactly is affected?

Signing an AI client in over OAuth to a WordPress MCP server that runs on your own site — for example the Novamira plugin — when that WordPress site is hosted on an xCloud OpenLiteSpeed (OLS) server. It is not about connecting xCloud’s own MCP at app.xcloud.host, which is unaffected. Application-password connections and non-OLS sites are also not affected.

Do new OpenLiteSpeed sites need this fix?

No. New OLS sites created after the permanent fix shipped work out of the box. This procedure is only for existing OLS sites created before the fix.

Is regenerating the OLS config or toggling the firewall safe?

Yes. Regenerating the OLS config keeps SSL working (only the ACME challenge path stays served statically), and toggling 7G/8G off and on leaves exactly one firewall block in place. Both now install the official fix instead of removing any hand fixes support may have applied.

My site was hand-fixed by support — do I still need to do this?

It keeps working as-is. The next time you regenerate the OLS config or toggle the firewall, the temporary hand fix is replaced by the official one, so you do not need to do anything special.