Autoriser Relvato derrière Cloudflare ou un pare-feu
Mis à jour en septembre 2026
Si votre site est derrière Cloudflare, Sucuri, Wordfence ou un WAF d’hébergeur, sa protection anti-bots peut bloquer les contrôles 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.
Pourquoi les contrôles reçoivent un 403
Relvato exécute vos parcours 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 un défi « vérification du navigateur » que Relvato peut attendre.
Vos visiteurs ne le voient jamais : cela ne concerne que les requêtes de vérification 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 → Paramètres → « Derrière Cloudflare ou un pare-feu ? ». 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 les Paramètres de votre site. Publiez la règle — le prochain contrôle 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, sachez que les contrôles de Relvato partent d’un pool dynamique — l’en-tête est donc l’option fiable.
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 |
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 contrôle. 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).