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
- 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/. Allowlist192.241.129.49there. - Cloudflare on your site. If your own domain sits behind Cloudflare, bot-protection features (Bot Fight Mode, Under Attack mode, managed challenges) can challenge WPVibe. Either add an IP Access Rule that allows
192.241.129.49, or add a WAF skip rule for paths starting with/wp-json/wpvibe/. - 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. - 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.