Un système métier qui ne se charge pas du tout, et un autre qui se charge pour tout le monde sauf la poignée de requêtes qu'une seule règle continue d'avaler, arrivent au support technique comme le même ticket. Ce ne sont pas la même panne, et elles ne se corrigent pas de la même façon. Voici comment les distinguer rapidement, les filtres de journaux et chemins de menu exacts à vérifier à chaque étape, et les causes qui expliquent la plupart de ces tickets.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Les deux ressemblent à la même page blanche pour celui qui a ouvert le ticket — la différence n'apparaît qu'une fois qu'on va la chercher.
Une application web placée derrière un WAF peut devenir inaccessible pour des raisons qui n'ont rien à voir avec ses règles de sécurité — un chemin rompu vers le serveur d'origine, une négociation SSL que le navigateur du client ne peut pas achever, ou le WAF lui-même en surchauffe. Elle peut aussi devenir inaccessible, ou partiellement inaccessible, parce qu'une de ses propres règles de protection fait exactement ce pour quoi elle a été configurée : bloquer une requête qui ressemble à une attaque mais n'en est pas une. Traiter le second problème comme le premier, ou l'inverse, gaspille les vingt premières minutes de presque chacun de ces tickets.
Voici l'arbre de panne sur lequel repose cette note, les vérifications pour chaque branche avec les filtres de journaux et chemins de menu exacts à utiliser, les causes qui reviennent sans cesse une fois passées les premières vérifications, et quelques réponses de FAQ tirées de cas de terrain réels.
L'inaccessibilité liée au WAF se répartit en exactement deux formes : le site est réellement en panne, ou le jeu de règles arrête un trafic qui devrait être autorisé.
Placer d'abord le symptôme sur cet arbre évite beaucoup d'allers-retours par la suite — cela indique laquelle des sections ci-dessous s'applique réellement à ce que vous observez.
Les légendes du schéma restent en anglais pour la clarté technique.
Savoir si le site est réellement en panne se répond par les mêmes vérifications opérationnelles que pour n'importe quel service web — CPU, connectivité, négociation TLS. Savoir si une règle en est responsable n'apparaît que dans trois journaux spécifiques, et seulement si la règle a été configurée pour y écrire, ce qui est exactement le piège autour duquel s'articule la section suivante.
Trois endroits différents à examiner, trois solutions différentes — et un seul paramètre qui décide si vous verrez ne serait-ce qu'une entrée de journal pour ce qui vient de se passer.
Avant de toucher à une règle, écartez les causes qui n'ont rien à voir avec la politique de sécurité du WAF.
Status > System Overview -- CPU / memory usage at the time of the fault
Status > Historical Data -- filter: Web Traffic / Web Connections / New Web Connections / Web Requests
System > System Maintenance > Packet Capture
interfaces: Lo, business (protect)
match: the failing GET/POST -- compare client-to-WAF vs WAF-to-origin
// origin sends RST -> server is refusing the request, not a WAF issue
// WAF sends RST to client -> block is happening on the WAF side, check Branch B
System > System Maintenance > Running Mode Switch
bridge passthrough / physical passthrough -- confirms whether the WAF is the variableSi le client voit réellement une page de blocage, la trace dans les journaux existe généralement — il faut simplement chercher au bon endroit.
Pas de page de blocage, pas d'entrée de journal évidente, et le responsable métier jure que rien n'a changé — c'est presque toujours une règle configurée pour bloquer sans journaliser.
Log > Application-Layer Protection Log -- Custom Query, filter by server / client IP
Log > Traffic Control Log
Log > CC Protection Log
// no block entry in any of the three logs, but disabling the rule group fixes it:
Policy > Rule Groups > Search Rule
action = "Block, No Alert" OR action = "Drop, No Alert"
-> change action to "Detect Only" // makes the WAF start logging what it blocks
// once a block entry exists:
Alert Details > Triggered Rule ID > [rule page] > "Add Current URL to Whitelist"
// overlapping whitelist paths -- longer, more specific URL must be listed ABOVE the shorter one
/api/v1/order/query/detail <- list first
/api/v1/order/query <- shorter, overlapping path, listed afterUne fois que les branches ci-dessus ont indiqué où se situe le problème, ces quatre causes expliquent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMEL'équipe métier insiste sur le fait que rien n'a changé, les trois journaux de protection ne montrent rien au moment de la panne, et pourtant désactiver le groupe de règles corrige instantanément le problème.
CAUSEL'action d'une règle peut être définie sur « Bloquer, sans alerte » ou « Abandonner, sans alerte » — les deux arrêtent la requête exactement comme une règle de blocage normale, mais aucune n'écrit d'entrée dans le journal de protection de la couche applicative. Du point de vue du journal, rien ne s'est passé ; du point de vue du client, le site est cassé.
SOLUTIONAllez dans Politique > Groupes de règles > Rechercher une règle, filtrez spécifiquement ces deux actions, et basculez-les sur « Détection uniquement » pendant le dépannage afin que le WAF commence à produire les entrées de journal dont vous avez réellement besoin.
SYMPTÔMEL'accès métier ressemble à une panne réseau — intermittente, difficile à reproduire, aucune règle ne semble jamais impliquée — et aucun filtrage de journal ne trouve quoi que ce soit.
CAUSELorsque l'adresse de l'interface de gestion du WAF se trouve dans le même sous-réseau que l'interface métier ou l'IP d'un site protégé, les deux peuvent interférer l'une avec l'autre de manières qui se présentent comme un problème de connectivité générique plutôt que comme quelque chose que les journaux de sécurité capteraient.
SOLUTIONGardez l'interface d'administration, l'interface métier et l'adresse IP de chaque site protégé sur des sous-réseaux distincts les uns des autres. C'est une vérification de conception réseau, faite une fois, pas une correction à répéter à chaque incident.
SYMPTÔMEUne URL spécifique — généralement une qui est interrogée ou actualisée fréquemment par une véritable intégration ou un utilisateur actif — devient intermittemment inaccessible, alors que le reste du site va bien.
CAUSELa protection CC (anti-flood) se déclenche sur des schémas de fréquence de requêtes, et un schéma d'accès légitime mais fréquent vers un chemin peut ressembler exactement à une attaque automatisée du point de vue de la règle.
SOLUTIONAjoutez une condition de correspondance exacte pour ce chemin spécifique dans la règle CC afin qu'elle ne protège que ce dont elle a besoin, et ajoutez l'IP source connue comme légitime à la liste blanche d'IP source CC plutôt que d'assouplir le seuil de débit de la règle pour tout le site.
SYMPTÔMEUne URL qui devrait être en liste blanche est quand même bloquée, alors qu'elle figure clairement dans la liste blanche — et une autre URL plus courte partageant le même préfixe n'est pas bloquée du tout.
CAUSELa correspondance s'exécute du haut vers le bas de la liste blanche, et la première entrée correspondante l'emporte. Lorsqu'une URL en liste blanche est un préfixe d'une autre, ou y est autrement contenue, lister la plus courte en premier fait qu'elle intercepte le trafic destiné à l'entrée plus longue et plus spécifique en dessous.
SOLUTIONPlacez l'URL plus longue et plus spécifique au-dessus de la plus courte qui se chevauche dans l'ordre de la liste blanche, afin que l'entrée voulue corresponde en premier.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Un blocage explicite affiche au client un 403 ou une page de blocage, et — si l'action de la règle est un « Blocage » normal — écrit une entrée dans le journal de protection de la couche applicative que vous pouvez filtrer immédiatement. Un blocage silencieux utilise l'action « Bloquer, sans alerte » ou « Abandonner, sans alerte » : la requête échoue exactement de la même façon côté client, mais aucune entrée de journal n'est produite du tout, ce qui explique pourquoi il est si souvent confondu avec un problème réseau ou de backend.
À partir de l'entrée de blocage dans le journal de protection de la couche applicative, ouvrez les détails de l'alerte et accédez à l'ID de règle spécifique déclenché. Sur la page de cette règle, « Ajouter l'URL actuelle à la liste blanche » n'ajoute cette URL que pour cette règle spécifique — le groupe de règles continue de protéger tout le reste exactement comme avant.
Les deux sont disponibles. Chaque règle individuelle a sa propre liste blanche d'URL, accessible depuis la page de cette règle. Par ailleurs, Groupes de règles > Liste blanche d'URL affiche la liste blanche globale pour tout le groupe de règles, et permet de consulter en un seul endroit chaque entrée de liste blanche au niveau des règles qui s'y trouve.
La correspondance se fait de haut en bas et s'arrête à la première correspondance. Lorsqu'une URL en liste blanche est contenue dans une autre — par exemple un chemin plus long qui est un sous-ensemble d'un chemin plus court — listez d'abord l'URL la plus longue et la plus spécifique, sinon elle n'aura jamais la chance de correspondre avant l'entrée plus courte au-dessus d'elle.
Avant de toucher à une règle, écartez les causes qui n'ont rien à voir avec la logique des règles : le chemin réseau propre au PC client, un navigateur qui ne prend pas en charge TLS 1.1/1.2, une discordance de négociation SSL entre le WAF et le serveur d'origine, le WAF et l'origine simplement incapables de communiquer, ou le WAF fonctionnant sous une charge telle que le proxy est retardé. Ce n'est qu'une fois ces causes écartées qu'il est pertinent de commencer à filtrer les journaux de protection.
Cette note s'appuie sur les filtres de journaux et chemins de menu du WAF Huawei — journal de protection de la couche applicative, journal de contrôle de trafic, journal de protection CC, et recherche de groupe de règles — ainsi que sur les cas de terrain qui les sous-tendent. Si votre WAF est d'un autre fournisseur, les chemins de menu exacts changent, mais l'ordre de diagnostic sous-jacent — écarter d'abord les causes réseau et TLS, puis vérifier si la journalisation était même configurée pour montrer le blocage — s'applique directement. Elle ne couvre pas en profondeur le réglage de règles spécifique à la gestion des bots ni les protections au niveau de la passerelle API.
Dites-nous s'il s'agit d'un 403 franc ou d'un échec silencieux, avec l'entrée de journal — ou le fait qu'il n'y en a pas — et nous vous aiderons à l'interpréter.