Allowlist Relvato behind Cloudflare or a firewall
If your site sits behind Cloudflare, Sucuri, Wordfence or a host WAF, its bot-protection can block Relvato’s automated requests with a 403 — before the request even reaches your site. Here’s how to let Relvato through, securely, with one rule.
Why the monitors get a 403
Relvato runs your monitors in a real browser. A firewall or bot-protection layer (Cloudflare is the common one) sees that automated traffic and blocks it with an HTTP 403 at the edge — before it reaches your site. That’s a hard block, not a “checking your browser” challenge Relvato can wait out.
Your visitors never see this: it only affects Relvato’s verification requests. Nothing is wrong with your site — the edge just needs to be told Relvato is allowed.
How Relvato proves it’s Relvato
Every request Relvato makes to your site carries a stable header, X-Relvato-Token. Its value is unique to your site and derived from your site’s signing secret — it never changes and can’t be guessed, so it’s safe to match on in a firewall rule.
You’ll find the exact value in Relvato under your site → Settings → “Behind Cloudflare or a firewall?”. Copy it from there.
Add the Cloudflare rule
In the Cloudflare dashboard, open your domain → Security → WAF → Custom rules → Create rule. Set the action to Skip, and tick all Managed Rules, Bot Fight Mode, and Rate limiting.
For the rule expression, match the header to your site’s value: http.request.headers["x-relvato-token"][0] eq "<your value>". Relvato shows the full copy-paste expression in your site’s Settings. Deploy the rule — the next run should pass.
Other firewalls
The same idea works anywhere. In Sucuri, Wordfence, or a host/CDN WAF, add an allowlist rule for requests where the header X-Relvato-Token equals your site’s value. If your firewall can only allowlist by IP, you can do that too — but know the trade-off: Relvato’s requests go out through a pool of addresses that rotates, so an IP allowlist needs re-checking, while the header rule keeps matching. The addresses currently in use are listed under your site → Settings → “Behind Cloudflare or a firewall?” and at https://app.relvato.com/api/egress-ips. Where you have the choice, the header is also the tighter match — an address can be shared, a per-site secret can’t.
Imunify360 and other server-side firewalls
Imunify360, mod_security and cPanel/CSF run on the server itself, not at the edge — so a Cloudflare rule never reaches them, and there’s usually no allowlist switch in your own hosting panel. This is the case where runs keep failing even though your CDN rule is live, either with a plain 403 or with a “Please wait while your request is being verified” splash page served as a normal 200.
Ask your host for one of two things: a rule that lets through requests carrying the X-Relvato-Token header with your site’s value, or an allowlist entry for the addresses Relvato’s requests come from. On Imunify360 the second is one command per address: imunify360-agent ip-list local add --purpose white <address> --scope group
Your site’s Settings card lists the current addresses and the exact commands, ready to paste into a support ticket. The machine-readable list is at https://app.relvato.com/api/egress-ips — point your host at it rather than at a value copied into an email. Because the addresses rotate, ask your host for the header rule where they support it, and re-check this list if a block comes back.
Where to allowlist Relvato, by firewall
| Firewall | Where to add it | What to match |
|---|---|---|
| Cloudflare | Security → WAF → Custom rules → Skip | X-Relvato-Token equals your value |
| Sucuri | Firewall → Access Control → Allowlist | X-Relvato-Token equals your value |
| Wordfence | Firewall → allowlisted rules | Requests carrying X-Relvato-Token |
| Host / CDN WAF | Bot or security rules | Allowlist the X-Relvato-Token header |
| Imunify360 / server firewall | Ask your host — Imunify360 → allow rule or IP allowlist (a CDN rule can’t bypass it) | X-Relvato-Token header, or Relvato’s addresses |
Questions
Is it safe to match on the header?
Yes. The value is a per-site secret derived from your signing secret — unique to your site and not guessable — so no one else can send it. It’s far safer than a broad user-agent or IP rule.
Does this weaken my firewall?
No. The rule only skips bot-protection for requests that carry your exact secret token; every other request stays fully protected.
I use Bot Fight Mode / Super Bot Fight Mode.
Those are the usual cause of the 403. Make sure your Skip rule ticks Bot Fight Mode (and on higher plans, add an exception for Super Bot Fight Mode) so Relvato’s requests bypass it.
It still fails after I add the rule.
Give it a minute to propagate, then re-run the monitor. If it still fails, confirm the header value matches exactly and that the action is Skip (Allow alone doesn’t bypass Bot Fight Mode).
Can I allowlist Relvato by IP instead?
Yes. Relvato’s requests leave from a small, fixed set of addresses — your site’s Settings card lists them, and https://app.relvato.com/api/egress-ips returns them as JSON. That’s the option for a server-side firewall such as Imunify360, which sits on the origin where a CDN rule never reaches. Where you can choose, the header is still the tighter match: it’s unique to your site.