Lorsqu'une panne du WAF fait tomber l'activité qu'il est censé protéger, la correction la plus rapide dépend entièrement de la façon dont il est déployé — proxy transparent, reverse proxy, surveillance hors chemin (bypass) ou mode pont ont chacun leur propre chemin de contournement, et se tromper fait perdre les minutes qui comptent le plus.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Avant de toucher à la moindre configuration sous pression, confirmez lequel des quatre modes de déploiement vous utilisez réellement — la mécanique de contournement n'est jamais la même entre deux modes.
Le fait qu'une panne du WAF puisse faire tomber l'activité qu'il protège, et ce que « contournement » signifie même pour y remédier, dépend entièrement du fait que l'équipement soit en ligne dans le chemin du trafic ou n'observe qu'une copie miroir de celui-ci. Le proxy transparent, le reverse proxy et le mode pont sont tous en ligne — une panne y bloque réellement le trafic, et chacun a sa propre mécanique de récupération d'urgence. Le mode de surveillance hors chemin (bypass) n'est pas du tout en ligne, donc une panne de l'équipement ne peut structurellement pas y interrompre l'activité, et la bonne réaction est de le reconnaître plutôt que de commencer à modifier la configuration.
Voici une carte de ce que « en ligne » signifie réellement pour chaque mode, les étapes de récupération d'urgence pour chacun avec les chemins exacts de la console, une échelle de vérification et de retour en arrière par étapes, une liste de contrôle de retour d'expérience, les pièges qui font perdre le plus de temps sous pression, et 5 réponses de FAQ tirées de déploiements réels.
Le fait que l'équipement soit réellement en ligne décide s'il a même besoin d'une procédure de contournement d'urgence.
Comparez votre déploiement réel à cette carte avant de faire quoi que ce soit d'autre — elle indique laquelle des procédures ci-dessous s'applique réellement.
Les légendes du schéma restent en anglais pour la clarté technique.
Seuls les trois modes en ligne ont réellement besoin d'une procédure de contournement d'urgence — une panne en mode de surveillance hors chemin ne peut par définition pas interrompre le trafic métier, car l'équipement n'a jamais été dans le chemin de transfert.
La mécanique de contournement de chaque mode est différente — voici le chemin de récupération exact pour chacun, dans l'ordre à essayer.
Deux types de récupération logicielle avant le matériel : désactiver le site protégé, puis basculer l'équipement lui-même en bypass physique.
Configuration > Protected Sites > [site] > Enable [ ] unchecked
Apply Changes ... Apply changes successful
// business restored? if not, escalate to physical bypass below
System > (scroll to runtime section) > Running Mode: [ Physical Bypass ]
[Switch Running Mode] ... Switch successful
// device is now hardware-bypassed -- traffic flows around every WAF engine entirelyDeux types de récupération : une règle d'autorisation totale au niveau applicatif d'abord, puis un contournement au niveau réseau si cela seul ne rétablit pas l'activité.
Configuration > Application Layer Access Control > Create Rule
Match type: URL Pattern: .*
Match mode: Match Action: Allow Status: Enable Scope: All
Save Rule -> drag to position #1 -> Apply Rules ... applied
// business restored? if not, the fault is below layer 7 -- bypass at the network level instead
// diversion switch: remove inbound/outbound diversion ACL for this site
// or: gateway device -- cancel NAT mapping / domain binding, point traffic at the real server IPC'est le seul mode de déploiement qui n'a strictement aucune procédure d'urgence à exécuter — et le confirmer est la vérification elle-même.
Comme un WAF en mode bypass ne reçoit jamais qu'une copie miroir du trafic et n'a jamais fait partie du chemin de transfert, une panne sur l'équipement — un crash, un disque plein, un moteur de détection bloqué — n'a aucun moyen d'interrompre le trafic métier. Si un site protégé est en panne alors que le WAF fonctionne dans ce mode, le WAF n'en est pas la cause ; regardez plutôt le véritable chemin de transfert. Ajuster la configuration de mise en miroir/SPAN du commutateur est une tâche d'administration distincte, non urgente, à ne pas toucher sous la pression d'une panne.
Le moins de leviers logiciels des quatre — la récupération va directement au niveau matériel.
Le mode pont n'a pas de règle équivalente d'autorisation totale au niveau applicatif sur laquelle se rabattre avant le niveau matériel, car l'équipement est un pont de couche 2, pas un proxy. Les deux types de récupération sont : couper complètement l'alimentation de l'unité, de sorte que son relais de bypass physique s'enclenche automatiquement, ou contourner directement l'équipement avec un câble. L'un ou l'autre rétablit la liaison brute ; aucun n'est élégant, et le site doit être considéré comme totalement non protégé jusqu'à ce que la panne sous-jacente soit corrigée et que l'équipement soit délibérément remis en ligne.
Retirer un contournement dans le mauvais ordre peut masquer le fait que la panne réelle est toujours présente.
Une fois que vous savez dans quel mode vous êtes, ces cinq causes expliquent l'essentiel des minutes perdues lors d'une panne réelle.
SYMPTÔMEUn ingénieur se met à chercher une procédure de contournement pour un WAF fonctionnant en mode de surveillance hors chemin pendant une panne.
CAUSELe mode de surveillance hors chemin ne voit jamais qu'une copie miroir du trafic — il n'a jamais été dans le chemin de transfert, donc une panne sur l'équipement ne peut structurellement pas être la raison pour laquelle un site est en panne.
SOLUTIONSi un site est en panne alors que le WAF est dans ce mode, arrêtez complètement de regarder le WAF et vérifiez le véritable chemin de transfert — le routage, la véritable passerelle, le serveur lui-même. Confirmer le mode est la vérification ; il n'y a aucune étape de contournement à exécuter.
SYMPTÔMEUne règle d'autorisation totale de contrôle d'accès en reverse proxy est créée et enregistrée, mais le site est toujours bloqué.
CAUSELes règles de contrôle d'accès sont évaluées dans l'ordre. Une règle d'autorisation totale placée n'importe où sous une règle de blocage existante n'est jamais atteinte, car la règle antérieure a déjà correspondu et agi en premier.
SOLUTIONAprès avoir enregistré la règle, faites-la glisser en position n°1 de la liste et cliquez sur « Appliquer les règles » — créer la règle et l'appliquer sont deux étapes distinctes, et sauter l'étape de glisser en tête est la raison la plus courante pour laquelle ce contournement semble échouer.
SYMPTÔMELa règle d'autorisation totale est confirmée appliquée et correctement priorisée en mode reverse proxy, mais le site ne revient toujours pas.
CAUSEUn contournement de contrôle d'accès ne traite que la couche du moteur de sécurité. Si le trafic arrive via les ACL d'un commutateur de dérivation ou une règle NAT/liaison de domaine de passerelle qui fait elle-même partie du problème, une règle d'autorisation totale à l'intérieur du WAF ne change rien à la manière dont le trafic y parvient au départ.
SOLUTIONPassez au niveau réseau : supprimez les ACL de dérivation entrante/sortante du commutateur de dérivation, ou annulez le mappage NAT ou la liaison de domaine de la passerelle, afin que le trafic aille directement vers la véritable IP du serveur sans du tout toucher le WAF.
SYMPTÔMEL'activité est rétablie après un basculement direct en bypass matériel/physique, mais personne ne peut dire ensuite quel moteur du WAF a réellement causé la panne.
CAUSELe bypass physique écarte tous les moteurs du WAF à la fois — moteur de règles/sécurité, moteur proxy/transfert, et moteur de statistiques web — donc rétablir l'activité de cette façon répond à « est-ce réparé » mais pas à « qu'est-ce qui a réellement cassé ».
SOLUTIONLorsque la panne le permet, procédez d'abord par les étapes les plus ciblées — désactiver le groupe de règles référencé, puis une règle d'autorisation totale, puis désactiver un seul site — avant de sauter au bypass physique, de sorte que chaque étape qui rétablit l'activité indique aussi quel moteur était impliqué.
SYMPTÔMELe contournement est retiré et la protection est rétablie, et la même panne se reproduit en quelques heures.
CAUSELe fait que l'activité soit rétablie par un contournement prouve seulement que le contournement a fonctionné — cela ne dit rien sur le fait que la condition sous-jacente (une tendance à l'épuisement des ressources, une règle qui se déclenchera à nouveau, une panne matérielle qui n'a en réalité pas été réparée) ait été traitée.
SOLUTIONConfirmez que le CPU, la mémoire, la charge et le disque sont revenus dans leurs plages normales et que la cause racine est réellement identifiée avant de retirer le contournement — pas seulement que le site se charge à nouveau pendant que le contournement est encore en place.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Escaladez progressivement : désactivez le groupe de règles référencé par le site, puis une règle d'autorisation totale au niveau applicatif en priorité maximale, puis désactivez le site unique (bypass pont au niveau du site), puis basculez tout l'équipement en mode pont/passage, et n'utilisez le bypass physique/matériel ou une coupure d'alimentation qu'en dernier recours. Chaque étape écarte un moteur différent, et les étapes antérieures, plus ciblées, vous laissent le plus d'informations pour diagnostiquer ensuite.
Non. Comme l'équipement ne voit jamais qu'une copie miroir du trafic dans ce mode, une panne du WAF ne peut structurellement pas y faire tomber l'activité. Si un site est en panne alors que le WAF est en mode de surveillance bypass, regardez le véritable chemin de transfert, pas le WAF.
Passez au niveau réseau : connectez-vous au commutateur de dérivation et supprimez les ACL de dérivation entrante et sortante, ou annulez le mappage NAT ou la liaison de domaine de la passerelle afin que le trafic aille directement vers la véritable IP du serveur sans toucher du tout au WAF.
Confirmez à partir d'un véritable test client, pas de la passerelle ou de la console propre du WAF. Confirmez que le CPU et la mémoire sont sous 60 %, la charge CPU sous 30, le disque sous 70 %, et confirmez que le volume de journaux d'alerte est revenu dans sa plage normale par site (environ 10 000 à 50 000 entrées par jour) avant de retirer le contournement et de déclarer l'incident clos.
Un manuel combiné unique, mais il doit se ramifier par mode dès la toute première étape, car les mécaniques ne se recoupent pas : le proxy transparent revient à désactiver le site puis au bypass physique ; le reverse proxy revient à une autorisation totale de contrôle d'accès puis à un contournement au niveau dérivation/NAT ; le mode pont revient directement à la coupure d'alimentation ou au câble de pontage ; et le mode de surveillance bypass n'a aucune procédure de contournement, car il n'a jamais été en ligne au départ.
Cette note s'articule autour du modèle des modes de déploiement de la série Huawei WAF5000 — proxy transparent, reverse proxy, surveillance hors chemin et mode pont — et des cas de terrain de maintenance d'urgence qui la sous-tendent. Si votre WAF est d'un autre fournisseur ou d'une autre version de firmware, les chemins exacts de la console varieront, mais la logique sous-jacente — si l'équipement est réellement en ligne, et quelle couche chaque étape de contournement écarte — s'applique directement. Elle ne couvre pas en profondeur le basculement de paire WAF en grappe/HA, ni les scénarios de déploiement en superposition SD-WAN.
Dites-nous votre mode de déploiement — proxy transparent, reverse proxy, surveillance bypass, ou pont — ainsi que ce que vous avez déjà essayé, et nous vous aiderons à l'interpréter.