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 usually mean a firewall, bot-protection layer, or security plugin is blocking WPVibe’s requests before WordPress ever sees them.

How WPVibe reaches your site

WPVibe manages your site through normal HTTPS requests to the WordPress REST API, under /wp-json/wpvibe/v1/. Nothing runs on your server beyond the WPVibe plugin, and no inbound ports or SSH access are needed. Requests arrive from Cloudflare’s network or from WPVibe’s static IP address:

192.241.129.49

When a firewall challenges WPVibe (for example, a Cloudflare “checking your browser” page), WPVibe automatically retries through the static IP above. If your host or firewall asks for an IP address to allowlist, that is the one to give them.

Fix it

1. Security plugins. If you run Wordfence or a similar firewall plugin, check its live traffic or blocked-requests log for requests to /wp-json/wpvibe/v1/. Allowlist 192.241.129.49 there.
2. Cloudflare on your site. If your own domain sits behind Cloudflare, its managed WAF rules can challenge WPVibe. These challenges usually fire on request content, not on who is asking: the rules inspect each request body and block writes that contain code or SQL, which is a normal shape for legitimate WPVibe edits, while plain reads pass. That is why the failures often look intermittent and hit only some saves.
   • The reliable fix is a WAF custom rule with the Skip action. In the Cloudflare dashboard, go to Security > WAF > Custom rules > Create rule, set the action to Skip (skip the managed ruleset, or all remaining rules), and match WPVibe’s traffic. Matching on WPVibe’s IP is tightest, for example ip.src eq 192.241.129.49. If you prefer to match by URL, cover both forms WPVibe uses, the path /wp-json/wpvibe/ and the query-string form ?rest_route=/wpvibe/v1/, because a rule that matches only the path silently misses the second form.
   • An IP Access Rule that allows 192.241.129.49 is a useful secondary measure for bot-score and reputation blocks such as Bot Fight Mode and Under Attack mode. On its own it usually does not exempt an address from the managed WAF rules, so it is not a substitute for the Skip rule above.
3. Host-level firewalls. Some managed hosts run their own bot protection in front of your site. Ask your host’s support to allowlist 192.241.129.49. They can see the blocked requests in their logs.
4. Leave /wp-json/ reachable. Password protection, geo-blocking, or “disable REST API” hardening on /wp-json/ blocks WPVibe along with everything else. WPVibe’s own endpoints require authentication already, so exposing /wp-json/ does not expose your site.

Connected, but requests fail with an authorization error

A different problem with a similar look. If tools reach your site but fail with wp_auth_not_received (an HTTP 401), your hosting setup is stripping the Authorization header before WordPress sees it. This is common on some Apache and FastCGI configurations. Add this line inside the rewrite block of your .htaccess file, or ask your host to pass the Authorization header through:

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

If you instead see permission_denied (an HTTP 403), the header is arriving fine and WordPress itself is denying the action. Check that the connected WordPress user has the capabilities the task needs (usually an Administrator account).

Still stuck?

Ask your AI to diagnose the connection. It can read the exact error WPVibe receives and often names the blocking layer directly. If you are still stuck, visit WPVibe support and include the error message and your hosting provider.