Book a demo
Book a demo
Login

Fix MCP OAuth Connection Failures on OpenLiteSpeed Sites

Updated October 7, 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.

Known limitation

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. If you hit this on an Nginx + 7G site, contact xCloud support and mention the loopback OAuth callback.

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