Comment contourner le pare-feu Vercel pour votre propre supervision

À quoi ressemble le blocage

Vos contrôles reviennent en « Ignoré » au lieu de réussi ou échoué, avec une note indiquant que le site a renvoyé un HTTP 403 ou qu'une vérification anti-bot ne s'est pas terminée. Relvato conserve une capture de ce que son navigateur a réellement reçu, pour que vous puissiez le vérifier vous-même dans le détail de l'exécution.

Cette capture montre la page intermédiaire de Vercel : un indicateur de chargement au-dessus de « We're verifying your browser », avec « Vercel Security Checkpoint » et un identifiant de requête en pied. Lorsque la vérification n'aboutit jamais, vous voyez plutôt « Failed to verify your browser » suivi d'un code court : le même blocage, une étape plus loin.

Votre site n'a aucun problème. Les vrais visiteurs ne sont pas concernés ; la vérification ne touche que les requêtes automatisées.

Pourquoi Vercel bloque un outil de supervision et pas vos visiteurs

Le pare-feu de Vercel évalue chaque requête selon sa ressemblance avec une personne réelle. Les contrôles navigateur de Relvato perdent sur deux tableaux à la fois : ils s'exécutent en mode headless et depuis la plage d'IP d'un fournisseur cloud, et non depuis une connexion résidentielle ou mobile.

D'où un blocage sélectif. Les contrôles qui récupèrent une URL en HTTP simple — liens morts, analyses SEO et métadonnées, contenu mixte — passent généralement, tandis que ceux qui pilotent un vrai navigateur (régression visuelle, Core Web Vitals, dérive de structure) sont bloqués. Si seuls les contrôles à base de navigateur échouent, c'est la raison.

Le phénomène peut aussi être intermittent : un contrôle isolé passe, alors qu'un « Tout exécuter » complet est bloqué en cours de route, car une rafale de chargements de pages est moins bien notée qu'un seul.

Contourner le pare-feu Vercel : la règle unique

Chaque requête que Relvato envoie à votre site porte un en-tête stable, X-Relvato-Token. Sa valeur est propre à votre site et dérivée de sa clé de signature : elle ne change jamais et ne peut pas être devinée, elle est donc sûre à utiliser dans une règle de pare-feu. Copiez-la dans Relvato depuis votre site → Paramètres → « Derrière Cloudflare ou un pare-feu ? ».

Dans le tableau de bord Vercel, ouvrez votre projet → Firewall → Custom Rules → New Rule. Ajoutez une condition où Request Header x-relvato-token est égal à la valeur copiée, puis choisissez l'action Bypass. Enregistrez et déployez : Vercel applique les changements de pare-feu en quelques secondes.

Relancez le contrôle. Ceux qui étaient ignorés devraient désormais se terminer normalement et afficher de vrais résultats au lieu d'une capture du checkpoint.

Si vous utilisez l'Attack Challenge Mode

L'Attack Challenge Mode soumet chaque visiteur à une vérification, donc Relvato aussi. Il est conçu comme une réponse temporaire à une attaque en cours : s'il est simplement resté activé, le désactiver rétablit aussitôt la supervision normale.

Si vous devez le garder actif, ajoutez la règle ci-dessus puis relancez un contrôle pour vérifier que Relvato passe. Si le checkpoint apparaît toujours, l'Attack Challenge Mode prime sur votre règle et vous devrez le désactiver le temps que Relvato capture une référence.

Toujours bloqué ? Étalez la charge

Si vous ne pouvez pas ajouter de règle de pare-feu — projet d'un client, ou offre sans règles personnalisées — vous pouvez réduire le volume de trafic navigateur que Relvato envoie d'un coup.

Dans votre site → Paramètres, « Espacer les contrôles » insère des pauses entre eux pour que « Tout exécuter » ne forme pas un flux continu de chargements de pages. Et dans la régression visuelle, surveiller un seul navigateur au lieu de plusieurs divise par deux les chargements du contrôle le plus lourd.

Considérez cela comme une atténuation, pas une garantie : cela réduit le risque d'être bloqué sans supprimer la vérification. La règle de pare-feu reste la solution fiable.