# Fix MCP OAuth Connection Failures on OpenLiteSpeed Sites

> AI clients that sign in over OAuth to a WordPress MCP server like Novamira can fail on OpenLiteSpeed sites. Regenerate the OLS config and toggle the 7G/8G firewall to fix it.

If you run a **WordPress MCP server on your own site** — such as the [Novamira](/docs/how-to-connect-ai-clients-to-wordpress-with-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](/docs/how-to-connect-xcloud-mcp-to-ai-agent/) 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](/docs/how-to-configure-firewall-management-in-xcloud/) 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](/support/) and mention the loopback OAuth callback.

## Related docs

-   [Connect AI clients to WordPress with Novamira on xCloud](/docs/how-to-connect-ai-clients-to-wordpress-with-novamira/)
-   [How to Configure Firewall Management in xCloud](/docs/how-to-configure-firewall-management-in-xcloud/)
-   [Enable the 8G Firewall in xCloud](/docs/enable-8g-firewall-in-xcloud/)

Still stuck? Contact our [**support team**](/support/) and mention the MCP OAuth connection on OpenLiteSpeed.