Autoriser Relvato derrière Cloudflare ou un pare-feu
Si votre site est derrière Cloudflare, Sucuri, Wordfence ou un WAF d’hébergeur, sa protection anti-bots peut bloquer les moniteurs de Relvato avec un 403 — avant même que la requête n’atteigne le site. Voici comment laisser passer Relvato, en toute sécurité, avec une seule règle. L'interface de Relvato est en anglais : ses libellés sont donc cités tels quels.
Pourquoi les moniteurs reçoivent un 403
Relvato exécute vos moniteurs dans un vrai navigateur. Un pare-feu ou une couche anti-bots (souvent Cloudflare) voit ce trafic automatisé et le bloque par un HTTP 403 en périphérie — avant qu’il n’atteigne votre site. C’est un blocage dur, pas une page de vérification du navigateur que Relvato peut attendre.
Vos visiteurs ne le voient jamais : cela ne concerne que les requêtes de surveillance de Relvato. Votre site va bien — il faut simplement indiquer à la périphérie que Relvato est autorisé.
Comment Relvato prouve son identité
Chaque requête que Relvato envoie à votre site porte un en-tête stable, X-Relvato-Token. Sa valeur est unique à votre site et dérivée de votre secret de signature — elle ne change jamais et n’est pas devinable, donc on peut s’y fier dans une règle de pare-feu.
Vous trouverez la valeur exacte dans Relvato, sous votre site → « Settings » → « Behind Cloudflare or a firewall? ». Copiez-la depuis là.
Ajouter la règle Cloudflare
Dans le tableau de bord Cloudflare, ouvrez votre domaine → Security → WAF → Custom rules → Create rule. Réglez l’action sur Skip et cochez toutes les Managed Rules, Bot Fight Mode et Rate limiting.
Pour l’expression, faites correspondre l’en-tête à la valeur de votre site : http.request.headers["x-relvato-token"][0] eq "<your value>". Relvato affiche l’expression complète à copier dans l’onglet « Settings » de votre site. Publiez la règle — la prochaine exécution devrait passer.
Autres pare-feux
Le principe fonctionne partout. Dans Sucuri, Wordfence ou un WAF d’hébergeur/CDN, ajoutez une règle d’autorisation pour les requêtes dont l’en-tête X-Relvato-Token est égal à la valeur de votre site. Si votre pare-feu ne sait autoriser que par IP, c’est possible aussi — avec une réserve : les moniteurs de Relvato partent d’un pool d’adresses qui change, donc une autorisation par IP doit être revérifiée, alors que la règle d’en-tête continue de correspondre. Les adresses actuellement utilisées sont listées dans votre site → « Settings » → « Behind Cloudflare or a firewall? » et sur https://app.relvato.com/api/egress-ips. Quand vous avez le choix, l’en-tête est aussi la correspondance la plus stricte : une adresse peut être partagée, un secret propre au site non.
Imunify360 et les autres pare-feux serveur
Imunify360, mod_security et cPanel/CSF tournent sur le serveur lui-même, pas en bordure : une règle Cloudflare ne les atteint jamais, et votre panneau d’hébergement n’offre généralement aucun réglage d’autorisation. C’est le cas où les moniteurs continuent d’échouer alors que votre règle CDN est active, avec un 403 ou avec une page « Please wait while your request is being verified » servie comme un 200 normal.
Demandez à votre hébergeur l’une de ces deux choses : une règle qui laisse passer les requêtes portant l’en-tête X-Relvato-Token avec la valeur de votre site, ou une entrée d’autorisation pour les adresses d’où partent les moniteurs de Relvato. Sur Imunify360, la seconde tient en une commande par adresse : imunify360-agent ip-list local add --purpose white <address> --scope group
L’onglet « Settings » de votre site affiche les adresses actuelles et les commandes exactes, prêtes à coller dans un ticket. La liste lisible par machine se trouve sur https://app.relvato.com/api/egress-ips — renvoyez-y votre hébergeur plutôt que vers une valeur copiée dans un e-mail. Comme les adresses changent, demandez à votre hébergeur la règle d’en-tête quand c’est possible, et revérifiez cette liste si un blocage revient.
Où autoriser Relvato, selon le pare-feu
| Pare-feu | Où l’ajouter | Ce qu’il faut faire correspondre |
|---|---|---|
| Cloudflare | Security → WAF → Custom rules → Skip | X-Relvato-Token égal à votre valeur |
| Sucuri | Firewall → Access Control → Allowlist | X-Relvato-Token égal à votre valeur |
| Wordfence | Firewall → règles autorisées | Requêtes portant X-Relvato-Token |
| WAF hébergeur/CDN | Règles bots ou sécurité | Autoriser l’en-tête X-Relvato-Token |
| Imunify360 / pare-feu serveur | Demandez à votre hébergeur — Imunify360 → règle d’autorisation ou allowlist d’IP (une règle CDN ne la contourne pas) | En-tête X-Relvato-Token, ou les adresses des moniteurs de Relvato |
Questions
Est-il sûr de filtrer sur l’en-tête ?
Oui. La valeur est un secret propre au site dérivé de votre secret de signature — unique et non devinable —, personne d’autre ne peut l’envoyer. C’est bien plus sûr qu’une règle large par user-agent ou par IP.
Cela affaiblit-il mon pare-feu ?
Non. La règle ne contourne la protection anti-bots que pour les requêtes portant votre jeton secret exact ; toutes les autres restent pleinement protégées.
J’utilise Bot Fight Mode / Super Bot Fight Mode.
Ils sont souvent la cause du 403. Assurez-vous que votre règle Skip couvre Bot Fight Mode (et, sur les offres supérieures, ajoutez une exception pour Super Bot Fight Mode) pour que les requêtes de Relvato passent.
Ça échoue encore après l’ajout de la règle.
Laissez une minute de propagation, puis relancez le moniteur. Si ça échoue encore, vérifiez que la valeur de l’en-tête correspond exactement et que l’action est Skip (Allow seul ne contourne pas Bot Fight Mode).
Puis-je autoriser Relvato par IP à la place ?
Oui. Les moniteurs de Relvato partent d’un petit ensemble fixe d’adresses : l’onglet « Settings » de votre site les liste et https://app.relvato.com/api/egress-ips les renvoie en JSON. C’est l’option pour un pare-feu serveur comme Imunify360, qui se trouve sur l’origine, là où une règle CDN n’arrive jamais. Quand vous avez le choix, l’en-tête reste plus strict : il n’appartient qu’à votre site.