Skip to content

Allow WP Safer in Cloudflare, Sucuri and a hosting firewall

The layers in front of WordPress that no plugin can open for you: the Cloudflare IP access rule and what it does not cover, the Sucuri firewall, and the one line to send your host about Imunify360 or ModSecurity.

Last updated

Not every block happens inside WordPress. A CDN, a cloud firewall or a filter on the hosting server can stop our request before WordPress ever sees it. Those layers sit in front of the site, so no plugin on the site can open the door for you. This article covers them; for security plugins running inside WordPress see Allow WP Safer in Wordfence, Solid Security, Jetpack and other security plugins.

The address to allow is 65.21.186.173, and our requests carry the user agent WPSafer/1.0 (+https://wpsafer.com).

How we know something in front of the site blocked us

When a request comes back as a refusal rather than an answer, we look at what came back. A challenge page, a vendor’s own block page, or a status code that only a filter returns (401, 403, 405, 406, 409, 418, 429 and 503 among them) is enough to say “this was a firewall” instead of “this site has no plugin”. Where the response identifies the product — Cloudflare, Sucuri, Imunify360, ModSecurity — the dashboard names it and prints the steps for that product right in the dialog where you hit the error.

Ordinary 404 and 500 responses are never read as a block. Those mean something else is wrong, and sending you to a firewall would waste your time.

Cloudflare

  1. Open the Cloudflare security rules screen and pick the domain of this site.
  2. Go to Security → Security rules. On older dashboards this is Security → WAF → Tools.
  3. Choose Create rule → IP access rules.
  4. Enter 65.21.186.173 as the IP address and choose Allow as the action.
  5. Leave the scope on this website, save the rule, then press Check again in your dashboard.

An Allow rule does not cover everything. It gets past managed WAF rules, custom rules and rate limiting, but Bot Fight Mode and Browser Integrity Check are separate switches, under Cloudflare’s bot and security settings, and an IP allow rule does not turn them off. If the site still cannot be reached after the rule is saved, that is the next place to look.

To check whether the rule took effect, Cloudflare logs every request it acts on: look up 65.21.186.173 in the firewall events for that domain and see whether our requests are now allowed instead of blocked.

We will never ask for your Cloudflare API token

We could write that rule for you if you handed over an API token with permission to edit your firewall. We have decided not to hold tokens like that, so Cloudflare is a guided flow and not a button. The five steps above are the whole of it.

If the site sits behind Cloudflare

When a site sits behind Cloudflare, our request reaches WordPress from a Cloudflare edge address rather than from us, and our real address travels in a header. The plugin reads that header — but only when the request genuinely comes from a Cloudflare address, so nobody can fake it. You do not have to configure anything for this.

It matters for one reason: do not put a Cloudflare address on any allow list on the site. That would let through every visitor arriving through that edge, not just us.

Sucuri (the cloud firewall)

This is the hosted Sucuri Firewall, not the Sucuri plugin inside WordPress.

  1. Open the Sucuri Firewall dashboard and pick this site.
  2. Go to Security → Access Control.
  3. Add 65.21.186.173 under Whitelist IP Address.
  4. Save, then press Check again in your dashboard.

Imunify360, ModSecurity and other hosting filters

These run on the hosting server, outside WordPress, and you usually cannot reach their settings from a control panel. This is a support ticket, and it is a short one. Send your host this line:

Please allow the IP address 65.21.186.173 for my domain.

If they ask what the traffic is, it is a remote management service calling /wpsafer-api on the site with the user agent WPSafer/1.0 (+https://wpsafer.com). That is usually enough for them to find the blocked requests in their log and confirm the rule took effect.

A blocked site blocks everything, not just setup

It is easy to read “could not add the site” as a one-off setup problem. It is not. Because all traffic goes one way — from us to your site — a firewall that blocks us also stops backups, updates, uptime checks and scans for as long as it is in place. The error you see while adding a site is the first symptom of a permanent block, so it is worth fixing properly rather than retrying.