When your host or firewall blocks the connection

The single most common reason a cloud AI client cannot connect, even though everything looks fine, is that your host or a security layer in front of WordPress is blocking the connection before it reaches your site. This page explains why it happens and how to fix it.

How to recognize it

It is almost certainly this problem when all of the following are true:

The site opens normally in your browser, and you are logged into WordPress without any issue.
The REST API answers when tested from the server itself, and Novamira’s own checks pass.
But a cloud AI client (for example Claude.ai) fails to connect, or the OAuth sign-in never completes, failing before it reaches WordPress.

Run Novamira > Troubleshoot to confirm: it prints exactly which layer is answering the request.

Why it happens

Novamira is direct by design: no credentials, site content, or requests pass through Novamira’s servers. With OAuth, the AI client opens the connection directly to your site, and for a cloud client that request originates on the AI provider’s own servers, not in your browser.

So the request arrives from a datacenter IP address, with a generic machine HTTP signature (Claude.ai, for example, often uses a Python HTTP client signature such as python-httpx) rather than a browser. A firewall, CDN, WAF, or managed-host security layer can classify this legitimate server-to-server request as automated bot traffic, and block or challenge it before WordPress or PHP ever receives it.

Novamira detects common layers of this kind on the Configuration page, including Kinsta, WP Engine, Hostinger, SiteGround, Pantheon, and Cloudflare, and recommends the best route for your setup. A security plugin such as Wordfence can cause the same block, and can also disable WordPress Application Passwords.

The quickest fix: use an Application Password

Where your AI client supports it, connect with an Application Password instead of OAuth. The Application Password route contacts WordPress through a local bridge that runs from the environment where your AI client runs, not from the AI provider’s cloud. Because the request no longer arrives from a datacenter IP with a machine signature, it is not classified as bot traffic, and it connects. Nothing passes through Novamira’s servers either way. See Connecting Your AI Client for the steps.

OAuth-only clients: ask your host to allow the traffic

Some clients, such as Claude.ai, only support OAuth, so the local-bridge trick above is not available. In that case the connection has to be allowed at the host or security layer. Novamira gives you a ready-to-send message on the Configuration page; forward it to your host’s support. The key is to allow this traffic by path, not by user agent (these clients do not present a browser signature and connect from datacenter IP ranges). Every other protection on the site can stay exactly as it is.

Three things need to be true:

The Authorization header must reach PHP. Application Passwords are sent as HTTP Basic authentication and OAuth tokens as a Bearer header. If the web server or proxy strips that header, every authenticated request looks anonymous to WordPress and fails with a permission error. On Apache this usually means passing HTTP_AUTHORIZATION through; on nginx or a proxy, not dropping the header.
These paths must pass through to WordPress as dynamic requests, without page caching, without redirects to the homepage, and without bot challenges: the whole REST API path /wp-json/ and its subpaths, plus /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource and any subpath of those two. Concretely, the client connects to /wp-json/mcp/novamira-oauth for OAuth and /wp-json/mcp/novamira for an Application Password, and the OAuth sign-in itself calls /wp-json/novamira/v1/oauth/. Allow the whole /wp-json/ path, because the REST prefix changes on subdirectory installs and on sites using plain permalinks.
Any CDN, WAF, or bot protection must allow this traffic by path, not by user agent, since these clients connect from datacenter IP ranges without a browser signature.

Two quick tests your host can run: a plain GET to /wp-json/ should return application/json with HTTP 200, and a GET to a protected endpoint sent with HTTP Basic credentials should return the user rather than a 401. Anything else, a redirect, an HTML page, a 403, or a challenge page, is the failure.

Security plugins

A security plugin such as Wordfence can block these requests at its own firewall, and can also disable WordPress Application Passwords entirely. If you installed or reconfigured a security plugin and connections stopped, check that Application Passwords are still enabled and that the REST API and OAuth paths above are allowed.

Reproduce it on a test site

The free version of Novamira can be installed on any test site at no cost. It ships the same Troubleshoot page, which runs these checks and prints exactly which layer is answering, which is often quicker than describing the problem.