Um sistema de negócio que simplesmente não carrega, e outro que carrega para todos, exceto para o punhado de solicitações que uma única regra continua engolindo, chegam ao suporte parecendo o mesmo chamado. Não são a mesma falha, e não se corrigem da mesma forma. Aqui está como distingui-los rapidamente, os filtros de log e caminhos de menu exatos a verificar em cada etapa, e as causas que respondem pela maioria desses chamados.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Ambos parecem a mesma página em branco para quem abriu o chamado — a diferença só aparece quando você vai procurá-la.
Uma aplicação web atrás de um WAF pode ficar inacessível por razões que não têm nada a ver com suas regras de segurança — um caminho quebrado até o servidor de origem, uma negociação SSL que o navegador do cliente não consegue completar, ou o próprio WAF sob carga alta. Também pode ficar inacessível, ou parcialmente inacessível, porque uma de suas próprias regras de proteção está fazendo exatamente o que foi configurada para fazer: bloquear uma solicitação que parece um ataque, mas não é. Tratar o segundo problema como o primeiro, ou o contrário, desperdiça os primeiros vinte minutos de quase todos esses chamados.
A seguir está a árvore de falhas na qual esta nota se baseia, as verificações de cada ramo com os filtros de log e caminhos de menu exatos a usar, as causas que aparecem repetidamente depois das primeiras verificações, e algumas respostas de perguntas frequentes tiradas de casos reais de campo.
A inacessibilidade relacionada ao WAF se divide em exatamente duas formas: o site está realmente fora do ar, ou o conjunto de regras está bloqueando tráfego que deveria ser permitido.
Colocar primeiro o sintoma nesta árvore evita muito retrabalho depois — ela indica qual das seções abaixo realmente se aplica ao que você está vendo.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Se o site está realmente fora do ar se responde com as mesmas verificações operacionais que você faria para qualquer serviço web — CPU, conectividade, o handshake TLS. Se uma regra é responsável só aparece em três logs específicos, e somente se a regra foi configurada para escrever neles, que é exatamente a armadilha em torno da qual a próxima seção é construída.
Três lugares diferentes a verificar, três soluções diferentes — e uma configuração que decide se você sequer verá uma entrada de log do que acabou de acontecer.
Antes de mexer em qualquer regra, descarte as causas que não têm nada a ver com a política de segurança do 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 variableSe o cliente realmente vê uma página de bloqueio, o rastro no log geralmente existe — só é preciso procurar no lugar certo.
Sem página de bloqueio, sem entrada de log óbvia, e o responsável pelo negócio jura que nada mudou — isso quase sempre é uma regra configurada para bloquear sem registrar.
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 afterDepois que os ramos acima indicarem onde está o problema, essas quatro causas explicam a maior parte do que realmente está errado.
SINTOMAA equipe de negócio insiste que nada mudou, os três logs de proteção não mostram nada no momento da falha, e mesmo assim desabilitar o grupo de regras resolve instantaneamente.
CAUSAA ação de uma regra pode ser definida como "Bloquear, sem alerta" ou "Descartar, sem alerta" — ambas param a solicitação exatamente como uma regra de bloqueio normal, mas nenhuma escreve uma entrada no log de proteção da camada de aplicação. Do ponto de vista do log, nada aconteceu; do ponto de vista do cliente, o site está quebrado.
SOLUÇÃOVá para Política > Grupos de regras > Pesquisar regra, filtre especificamente essas duas ações, e mude-as para "Somente detectar" durante a solução de problemas para que o WAF comece a produzir as entradas de log que você realmente precisa ver.
SINTOMAO acesso de negócio parece uma falha de rede — intermitente, difícil de reproduzir, nenhuma regra parece estar envolvida — e por mais que filtre os logs, nada é encontrado.
CAUSAQuando o endereço da interface de gerenciamento do WAF cai na mesma sub-rede que a interface de negócio ou o IP de um site protegido, os dois podem interferir um no outro de maneiras que se apresentam como um problema de conectividade genérico, e não como algo que os logs de segurança chegariam a capturar.
SOLUÇÃOMantenha a interface de administração, a interface de negócio e o endereço IP de cada site protegido em sub-redes distintas entre si. Esta é uma verificação de design de rede, feita uma vez, não uma correção por incidente.
SINTOMAUma URL específica — geralmente uma que é consultada ou atualizada com frequência por uma integração real ou um usuário ativo — fica intermitentemente inacessível, enquanto o resto do site funciona bem.
CAUSAA proteção CC (anti-inundação) é acionada por padrões de taxa de solicitação, e um padrão de acesso legítimo, mas frequente, a um caminho pode parecer idêntico a um ataque automatizado do ponto de vista da regra.
SOLUÇÃOAdicione uma condição de correspondência exata para esse caminho específico na regra CC para que ela proteja apenas o que precisa, e adicione o IP de origem conhecido como bom à lista branca de IP de origem CC em vez de afrouxar o limite de taxa da regra para todo o site.
SINTOMAUma URL que deveria estar na lista branca ainda é bloqueada, embora apareça claramente na lista branca — e outra URL mais curta que compartilha o mesmo prefixo não é bloqueada de forma alguma.
CAUSAA correspondência é executada de cima para baixo na lista branca, e a primeira entrada correspondente vence. Quando uma URL na lista branca é um prefixo de outra, ou está de outra forma contida nela, listar a mais curta primeiro faz com que ela intercepte tráfego destinado à entrada mais longa e específica abaixo dela.
SOLUÇÃOColoque a URL mais longa e específica acima da mais curta que se sobrepõe na ordem da lista branca, para que a entrada pretendida corresponda primeiro.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Um bloqueio explícito mostra ao cliente um 403 ou uma página de bloqueio, e — assumindo que a ação da regra seja um "Bloqueio" normal — escreve uma entrada no log de proteção da camada de aplicação que você pode filtrar imediatamente. Um bloqueio silencioso usa a ação "Bloquear, sem alerta" ou "Descartar, sem alerta": a solicitação falha exatamente da mesma forma do lado do cliente, mas nenhuma entrada de log é produzida, motivo pelo qual é tão frequentemente confundido com um problema de rede ou de backend.
A partir da entrada de bloqueio no log de proteção da camada de aplicação, abra os Detalhes do alerta e clique até o ID da regra específica acionada. Na página dessa regra, "Adicionar URL atual à lista branca" adiciona essa URL apenas para essa regra específica — o grupo de regras continua protegendo tudo o mais exatamente como antes.
Ambas estão disponíveis. Cada regra individual tem sua própria lista branca de URL, acessada a partir da página dessa regra. Separadamente, Grupos de regras > Lista branca de URL mostra a lista branca global para todo o grupo de regras, e permite revisar cada entrada de lista branca em nível de regra abaixo dele em um só lugar.
A correspondência é executada de cima para baixo e para na primeira correspondência. Quando uma URL na lista branca está contida em outra — por exemplo, um caminho mais longo que é um subconjunto de um mais curto — liste primeiro a URL mais longa e específica, ou ela nunca terá a chance de corresponder antes da entrada mais curta acima dela.
Antes de mexer em qualquer regra, descarte as causas que não têm nada a ver com a lógica das regras: o próprio caminho de rede do PC cliente, um navegador que não suporta TLS 1.1/1.2, uma incompatibilidade na negociação SSL entre o WAF e o servidor de origem, o WAF e a origem simplesmente não conseguindo se comunicar, ou o WAF operando sob carga suficiente para atrasar o proxy. Só depois de descartadas essas causas faz sentido começar a filtrar os logs de proteção.
Esta nota se baseia nos filtros de log e caminhos de menu do WAF Huawei — log de proteção da camada de aplicação, log de controle de tráfego, log de proteção CC, e busca de grupo de regras — além dos casos de campo por trás deles. Se o seu WAF for de outro fabricante, os caminhos de menu exatos mudam, mas a ordem de diagnóstico subjacente — descartar primeiro as causas de rede e TLS, depois verificar se o registro sequer foi configurado para mostrar o bloqueio — se aplica diretamente. Não cobre em profundidade o ajuste de regras específico de gerenciamento de bots nem as proteções em nível de gateway de API.
Conte-nos se é um 403 rígido ou uma falha silenciosa, junto com a entrada de log — ou o fato de que não há uma — e ajudamos você a interpretá-la.