Firewalls, Bot Protection, and WPVibe’s IP Address

When to use this guide

Use this guide when your WordPress site will not connect (a rest_unreachable error during connect), or a site that worked before suddenly fails with errors about the site being unreachable, blocked, or challenged. These symptoms can come from a firewall, bot-protection layer, access-control rule, or an origin failure. Check the exact REST response and connection report before changing settings.

How WPVibe reaches your site

WPVibe uses HTTPS requests to WordPress core and plugin REST routes, including /wp-json/wp/v2/, /wp-json/wpvibe/v1/ and their ?rest_route= equivalents. No SSH access or additional inbound ports are needed. Requests arrive from Cloudflare’s network or from WPVibe’s static IP address:

192.241.129.49

That address has matching reverse DNS: its PTR record is egress1.wpvibe.ai, and egress1.wpvibe.ai resolves back to 192.241.129.49. If your firewall or host verifies senders by reverse DNS, allowlist that hostname instead of the bare IP.

When a firewall challenges WPVibe (for example, a Cloudflare “checking your browser” page), WPVibe can route supported recovery requests through the static IP above. A failed write may need investigation before retrying to avoid duplicating an action. If your host or firewall asks for the relay IP address to allowlist, that is the one to give them.

Added a firewall rule for the X-WPVibe header? Remove it

An older WPVibe page suggested a firewall rule that skips security checks for any request carrying the header X-WPVibe: 1. Please delete that rule. Anyone can send that header, so the rule lets any visitor, including an attacker, skip your firewall. The same goes for a rule that trusts the WPVibe/1.0 user agent. If your host added a header or user-agent exception for you (that page told WP Engine users and others to ask for one), ask the host to remove it. Use one of the scoped fixes below instead.

Fix a confirmed firewall block

On Hostinger, start with the Hostinger section below: it has a fix we have tested.

Run WPVibe > Check site connectivity in WordPress admin and copy the report. Give your host the failed REST URL, method, UTC time, response and request/Ray ID. A homepage check or a passing read does not explain an earlier failed write.
If you manage Cloudflare, find the matching Security Event and triggering rule. Apply a narrowly scoped exception for the affected hostname, REST route and verified request source. Ask WPVibe support for a matching expression if needed. Direct Worker traffic and relay traffic use different source identities; allowing only the relay IP does not cover every request.
For a confirmed relay request, the configured relay IP is 192.241.129.49. Confirm it against the failed request before adding an IP exception. Do not allow all Cloudflare IPs. The public X-WPVibe and User-Agent headers identify requests in logs but are not proof of identity and must not grant access on their own.
Choose the exception for the product that blocked the request. When your own Cloudflare zone challenges WPVibe’s relay, the simplest fix is an IP Access rule with the Allow action for 192.241.129.49. Cloudflare excludes an allowed IP from its security checks, including Browser Integrity Check, Under Attack mode, custom rules, rate limiting rules and WAF Managed Rules, and Bot Fight Mode does not trigger when an IP Access rule matches first. It covers relay requests only, not requests that arrive from Cloudflare’s network (step 2). Allowing a whole country does not bypass WAF Managed Rules. A custom rule with the Skip action skips only the features you select, and Bot Fight Mode cannot be skipped with a custom rule. Do not disable unrelated protections. Sources: Cloudflare’s IP Access rules actions, IP Access rules, Bot Fight Mode and Skip documentation.
To create the Allow rule in the Cloudflare dashboard:
1. Open your site and go to Security rules.
2. Select Create rule > IP access rules.
3. Enter 192.241.129.49, set Action to Allow, choose This website for the zone, and add a note such as WPVibe relay.
4. Select Create, then ask your AI to retry the request that failed.
The catch: Cloudflare shows the IP access rules option only once your account already has at least one IP access rule. If it is missing from the Create rule menu, create this first rule through Cloudflare’s API, or ask whoever manages your Cloudflare account to add it. See Create an IP access rule.
For a host-managed firewall, ask the host to investigate and apply the supported scoped exception while preserving WordPress authentication. Match both REST URL forms. Do not disable site privacy or make every REST endpoint public; the staging guidance below explains the distinction. Some hosts put Cloudflare in front of your site for you, for example WP Engine’s Global Edge Security, or the Cloudflare CDN that some hosts offer in their dashboards. You can’t add a Cloudflare rule there yourself: send the host’s support the failed request’s UTC time, REST route and Ray ID and ask them for the exception.

Hostinger: writes refused by the Hostinger CDN

What it looks like

Your site is hosted on Hostinger and the Hostinger CDN is on. Reading works: WPVibe lists pages, reads settings and opens files. Saving does not: an Elementor save, a content edit or a plugin action comes back with 403 Forbidden, often only for some pages or some edits. The error WPVibe shows names Hostinger’s CDN and includes a Hostinger CDN request id, and sometimes a Cloudflare Ray ID as well (Hostinger’s CDN runs on Cloudflare).

Reconnecting the site, changing your WordPress password or updating the WPVibe plugin will not change it. The request is refused before it reaches WordPress, so WordPress and your account never see it.

Why it happens

Hostinger’s CDN scores each incoming request. A large save that contains HTML, CSS, scripts or SQL-looking text scores higher, and requests from cloud networks are held to a stricter threshold than requests from a home connection. WPVibe sends your saves from Cloudflare’s network or from its static IP address, so a save that would pass from your own browser can be refused when WPVibe sends it. No single word or tag causes it; the signals add up, which is why one page saves and the next does not.

Fix it

Option 1: turn the Hostinger CDN off for the site. In hPanel go to Websites, choose the site, then Performance > CDN, and deactivate it. Then ask your AI to retry the save. Your site keeps working with the CDN off, and LiteSpeed Cache keeps running. We tested this in both directions on a Hostinger site: with the CDN off the same saves go through, and with it back on they are refused again.

Option 2: keep the CDN on and ask Hostinger for an exception. Contact Hostinger support and ask them to allow authenticated WPVibe requests to your site’s REST API. Give them:

the Hostinger CDN request id and the UTC time from the WPVibe error (and the Cloudflare Ray ID if one is shown)
the two URL forms WPVibe uses: /wp-json/wpvibe/v1/ and /?rest_route=/wpvibe/v1/ (and the same two forms for /wp/v2/)
WPVibe’s static IP address, 192.241.129.49. Allowing this address alone does not cover every request, because most requests arrive from Cloudflare’s network; ask them to match the request path as well.

Hostinger support can look the request up by its id and tell you which protection refused it.

If WPVibe says it switched to its relay

Sometimes the error says the request was refused on WPVibe’s direct path and that WPVibe has switched the site to its relay. Retry the same action once. If the retry goes through, you do not need to change anything. If it is refused too, the error will show the two options above.

What not to do

Do not turn off WordPress authentication, make REST routes public, or disable your security plugin to work around this. The block is at Hostinger’s CDN, in front of WordPress, and none of those change what the CDN does.

NinjaFirewall: writes containing <script> refused

What it looks like

Your site runs the NinjaFirewall security plugin. Reads work, but a save that contains a <script> tag (a WPCode snippet, a theme file, a page with an embed) comes back with 403 Forbidden and a page titled NinjaFirewall 403 Forbidden. The error WPVibe shows names NinjaFirewall.

NinjaFirewall’s cross-site scripting rule refuses a <script> tag in a request body, whoever sends it. Reconnecting, changing your password or updating the WPVibe plugin will not change it. Do not ask your AI to rewrite, split or encode the content to get past the rule.

Allow WPCode snippets with a scoped .htninja file

NinjaFirewall reads an optional .htninja file before it inspects a request. This one allows only WPVibe’s WPCode snippet saves, sent as a POST to /?rest_route=/wpvibe/v1/code-snippet:

<?php
if ( isset( $_SERVER['REQUEST_METHOD'], $_SERVER['REQUEST_URI'], $_GET['rest_route'] )
	&& ! isset( $_POST['rest_route'] )
	&& $_SERVER['REQUEST_METHOD'] === 'POST'
	&& parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH ) === '/'
	&& $_GET['rest_route'] === '/wpvibe/v1/code-snippet' ) {
	return 'ALLOW';
}

Put the file in your site’s document root (DOCUMENT_ROOT) or one directory above it.
Run php -l .htninja before you save it there. A syntax error in this file takes the whole site down with a 500 error.
It exempts any POST to that exact address, whoever sends it. WordPress still requires a valid Application Password, the wpcode_edit_snippets capability and WPVibe’s signed approval for the save.
It covers WPCode snippets only. Content edits, theme files and other writes containing <script> stay blocked while the rule is on.

We tested this file with NinjaFirewall WP Edition 4.9.1 in Full WAF mode: the WPVibe snippet save passed, and the same payload stayed blocked when sent to /index.php, /wp-json/wpvibe/v1/code-snippet, wp-login.php, xmlrpc.php, admin-ajax.php and other REST routes.

NinjaFirewall’s own admin whitelist does not help here: it whitelists by your wp-admin login session, and WPVibe’s Application Password requests do not have one.

one.com, Hostnet and other host filters: a “Blocked” or “Forbidden” page

On sites hosted at one.com or Hostnet, some WPVibe saves (most often PHP theme templates) come back with 403 and a page that says only Blocked. Reads and other saves keep working. It comes from the host’s request filter, which reacts to what the save contains rather than to where it comes from.

Other hosts’ server filters can refuse saves with a plain Forbidden page. Those may react to the content or to the sender, so ask the host to find the request in their logs and tell you which rule matched.

Ask the host’s support to find the refused request in their logs and add an exception for WordPress REST writes to your site. Give them the site address, the request (method and REST route, for example POST /?rest_route=/wpvibe/v1/file/write) and the UTC time from the WPVibe error. Do not rewrite or encode the content to get past the filter.

Private staging sites: what must be reachable?

A private frontend can coexist with WPVibe’s authenticated REST access, provided your access-control layer preserves the discovery and approval flow below. This is an access contract, not a tested configuration for a particular privacy plugin or host. Ask your host or developer to verify the proposed rules on staging before applying them.

Staging sites behind a server password (HTTP Basic Auth)

A directory password (HTTP Basic Auth, often set up in cPanel’s Directory Privacy or by your host for staging) is a second login in front of WordPress. WPVibe signs in with your WordPress Application Password and can’t send that second password. When WPVibe meets the gate, it tells your AI the site is “behind a server-level password”. There are two ways through:

Let WPVibe’s relay IP through the gate. Ask your host or developer to allow requests from 192.241.129.49 past the password (if Cloudflare sits in front of the site, the rule has to match the visitor’s original IP). WPVibe retries through its relay on its own, so there is nothing to ask support for. Wait five minutes after changing the gate, then ask your AI to connect again. The relay IP is shared by all WPVibe users, so the gate no longer guards those requests: keep WordPress logins, Application Passwords and your security plugin on.
Lift the password for as long as you use WPVibe on the site. Putting it back disconnects WPVibe until it is lifted again. Keep Discourage search engines from indexing this site on under Settings > Reading while the staging site is open.

Either way, turn the password off for the Approve click. WordPress won’t create an Application Password while Basic Auth is active on wp-admin/authorize-application.php, and shows “Your website appears to use Basic Authentication, which is not currently compatible with application passwords.” With option 1 you can turn the gate back on after approving, once the relay IP is allowed and a WPVibe read has worked with the gate on. Never put the gate password in the chat.

X-WPVibe-Authorization carries the same WordPress credential as a fallback; it is not a second directory password.

1. Discovery requests before WordPress authorization

Let these requests reach WordPress without a directory password, a browser-login redirect, or a bot challenge. The normal preflight uses GET, not a separate HEAD or OPTIONS requirement. Paths below are relative to the WordPress installation, including any subdirectory. Normal WordPress permission checks still apply.

Route or URL	Use	Expected response
`/?rest_route=/&_fields=name,authentication,namespaces` Fallback: `/wp-json/`	WordPress REST discovery	Normally HTTP 200 with the real REST-index JSON. Preserve its authentication metadata, including Application Password availability and its authorization URL when advertised. Diagnostic reads may also request `url` and `home`.
`/?rest_route=/wpvibe/v1/ping`	Public plugin detection	HTTP 200 JSON with `plugin: "wpvibe"`, plugin/WordPress versions and feature flags when the plugin is active. This is intentionally public metadata, not site content.
`/?rest_route=/wpvibe/v1/health`	Alternative when a command-matching firewall blocks “ping”	The same public plugin payload. Used conditionally, not an extra request on every connection.
`/?rest_route=/wpvibe/v1/site-info`	Legacy/plugin-detection fallback	An anonymous WordPress 401/403 refusal is expected on a protected route. Do not expose site-info data to anonymous visitors just to make this check return 200.
`/?rest_route=/wp/v2&_fields=namespace`	Fallback when the main index fails	HTTP 200 WordPress namespace-index JSON can establish REST reachability. It does not require public access to posts or other content routes.
`/wp-json/wp/v2/users/me/application-passwords` Fallback: `/?rest_route=/wp/v2/users/me/application-passwords`	Advisory logged-out check of the core approval route	A WordPress JSON 401/403 such as `rest_not_logged_in` can be normal. It does not prove that the later browser approval will fail. Never allow anonymous password creation or return a user’s Application Passwords.

These are the normal path and its fallbacks, not a requirement that every probe return 200. Some index failures, timeouts, or a missing plugin produce a warning and still allow an authorization link. A valid WordPress refusal is different from an HTML firewall page or login redirect. Use the connection report to identify the stage that actually failed.

Rules must recognize both REST URL forms: /?rest_route=/... and /wp-json/.... Permit normal query parameters such as _fields and the wpvibe_cb cache-buster; match the route rather than one exact query-string ordering. If the frontend is private, a blanket rule on / must not also block requests that carry rest_route.

2. Browser login and approval are authenticated

The person connecting the site must be able to reach WordPress’s login flow, the real wp-admin/authorize-application.php page and its scripts/styles. A login redirect is normal for that browser page, but not for a machine API request. The authorization URL can differ on subdirectory or alias installations; use the actual link WPVibe provides.

Current WPVibe plugins use GET /wpvibe/v1/authorize/preflight and POST /wpvibe/v1/authorize through WordPress REST from the logged-in browser. Preserve the WordPress session cookie and REST nonce (X-WP-Nonce); keep the capability checks. These routes are not anonymous exceptions. Without that plugin flow, WordPress’s core approval uses POST /wp/v2/users/me/application-passwords with browser authentication. Blocking the entire user-API path can break that flow.

The browser must also reach WPVibe’s connection link and callback at https://mcp.wpvibe.ai/c/... and https://mcp.wpvibe.ai/auth/wp-callback. Those are WPVibe URLs, not paths to add to the staging site’s allowlist. Do not strip the authorization link’s query parameters.

3. Access after connection

Keep the discovery exceptions available for later diagnostics, reconnection and public ping checks used during routing recovery. A saved connection may use authenticated requests directly, but locking all discovery routes immediately after approval can break these later flows.

Permit authenticated requests to the WordPress core and plugin routes used by the requested tools. Connection verification includes /wpvibe/v1/site-info and /wp/v2/users/me?context=edit. Normal work may use core content routes, plugin routes, and GET, POST, PUT, PATCH or DELETE as appropriate. The discovery table alone is not an allowlist for every tool. Preserve WordPress authentication, user capabilities and WPVibe’s operation-approval checks.

A privacy plugin must recognize Application Password authentication, not require a browser cookie for every REST request or reject the request before WordPress can authenticate it. Preserve Authorization, X-WPVibe-Authorization and operation-proof headers. Do not cache authenticated REST responses as public pages. Return native JSON responses and status codes, with the appropriate JSON content type, instead of HTML login pages, challenges or cached homepage content.

You do not need to publish the frontend or all REST content for basic authenticated API access. However, page-rendering tools such as get_page_html make separate page requests without the visitor’s browser session. A private frontend may remain unavailable to those tools even when the REST connection works. A passing read check does not prove publishing, uploads or page rendering work.

Connected, but requests fail with an authorization error

An HTTP 401 or wp_auth_not_received does not by itself prove that the host stripped a header. WordPress may have rejected a stored credential, an authentication header may have been withheld, or another access policy may have refused the request. Check the connection report’s authenticated-access result before changing credentials or server configuration. A logged-out 401 on a protected endpoint is expected and is not a failed saved login.

If the report and host logs establish that Authorization is being stripped, ask the host to preserve it for WordPress. Do not add rewrite rules or reconnect repeatedly based only on a status code. An authenticated WordPress permission refusal calls for checking the connected user’s capabilities; an HTML firewall 403 is a different failure.

Still stuck?

Ask your AI to diagnose the connection. It can read the exact error WPVibe receives and often names the blocking layer directly. Errors while connecting a site have their own page: Site Connection Errors: What They Mean and How to Fix Them. If you are still stuck, visit WPVibe support and include the error message and your hosting provider.