Um par de WAF em dupla máquina falha de duas maneiras muito diferentes: o log do sistema avisa sobre um heartbeat VRRP que na verdade é uma incompatibilidade de configuração, não um par morto -- e um único site protegido fica inativo enquanto todos os outros sites do mesmo par continuam funcionando bem. Aqui está como interpretar corretamente os dois, a checklist de HA que os previne, e a correção exata para cada um.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Uma parece um problema de rede e não é; a outra parece isolada a um site e na verdade é um conflito de endereçamento que abrange vários.
O hot standby em dupla máquina em um WAF deveria ser tedioso -- um nó ativo, um em espera, um IP virtual que não se importa com qual caixa física responde. Na prática, duas falhas respondem pela maioria dos chamados: uma entrada de log do sistema dizendo que o heartbeat VRRP entre o par está anormal, que soa como um problema de rede ou cabeamento mas quase sempre é uma incompatibilidade de configuração de site protegido; e um único site de proxy reverso ficando inacessível enquanto seus vizinhos no mesmo par estão bem, o que remonta a uma sobreposição de endereço de link em vez de algo errado no próprio HA.
A seguir está como interpretar corretamente cada uma delas, a checklist de configuração de HA que vale a pena executar antes que qualquer uma delas apareça, as armadilhas que respondem pela maior parte do que realmente está errado, e respostas de perguntas frequentes tiradas de casos de campo.
O HA de proxy transparente e o HA de proxy reverso nem sequer negociam pela mesma interface -- confundi-los desperdiça os primeiros dez minutos de qualquer investigação.
Ambos os modos de implantação compartilham um IP virtual e um papel ativo/em espera, mas o caminho de heartbeat subjacente é diferente: pares de proxy transparente negociam por uma porta HA diretamente conectada no painel, enquanto pares de proxy reverso negociam pela porta de gerenciamento -- que precisa estar na mesma sub-rede do par e ser roteável. Esclarecer isso primeiro indica qual interface realmente vale a pena investigar.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
A segunda falha fica inteiramente abaixo da camada de HA: os sites protegidos de proxy reverso carregam cada um seus próprios endereços de link front-end e back-end, e quando o endereço de link de um novo site colide com o de outro site -- ou com o endereço de broadcast de sua própria sub-rede -- o site afetado fica inativo enquanto o próprio par de HA não relata nada de errado, porque nada na relação de espera realmente quebrou.
Sintoma diferente, lugar diferente a verificar -- a mensagem de log e o escopo afetado apontam imediatamente para a certa.
No modo de proxy reverso, essa linha de log específica não é um alarme de rede -- é o WAF dizendo que as configurações de site protegido dos dois nós não coincidem.
System log (reverse-proxy mode):
VRRP peer heartbeat abnormal
// this line fires when "Apply Changes" finds a protected-site mismatch
// with the peer -- it is a config-diff alarm, not a link-down alarm
Fix:
Configuration > Configuration Sync > Sync Config File
(run from the node with the complete / correct site configuration)Quando apenas um site protegido é afetado, é um conflito de endereçamento no link daquele site, não um problema de HA ou regra de encaminhamento.
Config check: Configuration > Protected Sites
Site A front-end link: 10.10.0.11 back-end link: 10.10.1.11
Site B front-end link: 10.10.0.12 back-end link: 10.10.1.11 // <- collides with Site A
// overlapping back-end link address -> Site B silently unreachable, Site A unaffected
Packet capture interfaces:
Lo -> server-side address
site front-end interface -> link address (front-end)
site back-end interface -> link address (back-end)Depois de saber qual das duas falhas você está vendo, estas respondem pela maior parte do que realmente está errado.
SINTOMALog do sistema: heartbeat VRRP anormal, no modo de proxy reverso, com o link de HA aparentemente bem.
CAUSAAs configurações de site protegido dos dois nós não coincidem. Clicar em Aplicar alterações em um nó dispara uma verificação contra a configuração do par, e qualquer diferença registra exatamente essa linha -- é um detector de diferença de configuração, não uma checagem de atividade do par.
SOLUÇÃOSincronize a configuração completa a partir do nó correto via Configuração > Sincronização de configuração > Sincronizar arquivo de configuração, e crie o hábito de editar sites em apenas um nó.
SINTOMAUm site protegido específico de proxy reverso está inacessível; todos os outros sites no mesmo par funcionam normalmente.
CAUSAOs endereços de link de proxy reverso (front-end e back-end) precisam ser únicos em todos os sites protegidos no dispositivo. O endereço de link de um novo site colidindo com o de um site existente -- ou caindo no próprio endereço de broadcast da sub-rede -- causa desvio silencioso sem nenhum erro na camada de HA.
SOLUÇÃOAudite Configuração > Sites protegidos comparando os endereços de link do site afetado com os de todos os outros sites e seu endereço de broadcast de sub-rede, antes de olhar em qualquer outro lugar.
Site A back-end link: 10.10.1.11
Site B back-end link: 10.10.1.11 // duplicate -> Site B silently unreachableSINTOMAA negociação de HA de proxy reverso reporta anormal mesmo que as configurações dos dois nós “pareçam iguais”.
CAUSAO dual machine de proxy reverso exige configuração de site protegido idêntica em ambos os nós, exceto o papel VRRP. O campo que realmente quebra as coisas é o ID de rota virtual, que precisa ser idêntico entre o par para o mesmo site enquanto o papel ativo/backup difere -- um ID de rota virtual duplicado entre sites diferentes no mesmo dispositivo é um modo de falha separado e silencioso.
SOLUÇÃOConfirme que cada site protegido tem VRRP habilitado, que o papel ativo/backup de cada dispositivo é consistente em todos os seus sites, e que nenhum par de sites no mesmo dispositivo compartilha um ID de rota virtual.
SINTOMANegociação de HA anormal, e a interface sendo verificada não coincide com o modo de implantação.
CAUSAO heartbeat do dual machine em proxy transparente negocia pela porta HA diretamente conectada no painel. O heartbeat do dual machine em proxy reverso negocia pela porta de gerenciamento, que além disso precisa estar na mesma sub-rede do par e ser roteável -- resolver o errado desses dois desperdiça tempo em cabeamento ou roteamento que nunca foi o problema.
SOLUÇÃOConfirme primeiro o modo de implantação, depois verifique a interface correspondente: porta HA para proxy transparente, alcançabilidade da porta de gerenciamento para proxy reverso.
SINTOMANegociação de HA de proxy transparente anormal, com ambas as caixas configuradas individualmente e aparentemente bem.
CAUSAUm dispositivo está configurado em modo dual-active enquanto o outro ainda espera uma relação primário/backup -- ou os campos de IP local e IP do par da configuração de HA foram inseridos ao contrário em um dos lados.
SOLUÇÃOConfirme que ambos os dispositivos selecionam o mesmo modo (ambos dual-active, ou um primário mais um backup), e reverifique a atribuição de IP local versus IP do par na página de Configuração de HA em ambos os nós.
Tiradas de casos de campo -- as que vale a pena ter uma resposta pronta.
O dual machine de proxy transparente negocia seu heartbeat por uma porta HA diretamente conectada no painel do dispositivo. O dual machine de proxy reverso negocia pela porta de gerenciamento, e essa porta de gerenciamento além disso precisa estar na mesma sub-rede do par e ser realmente roteável -- não é intercambiável com a porta HA usada no modo transparente.
Geralmente não. No modo de proxy reverso, essa mensagem específica dispara quando o nó em que você aplicou alterações verifica sua configuração de site protegido contra a do par e encontra uma incompatibilidade -- é um alarme de diferença de configuração disfarçado de aviso de heartbeat. Sincronize a configuração a partir do nó correto via Sincronização de configuração antes de supor que há um problema de cabeamento ou roteamento.
Quase nunca -- verifique se o endereço de link front-end ou back-end do novo site sobrepõe o de um site existente, ou o endereço de broadcast de sua sub-rede. Essa colisão causa exatamente esse padrão: um site específico fica inativo enquanto seus vizinhos, e o próprio par de HA, parecem completamente normais.
Primeiro verifique os logs do sistema em busca de alarmes, depois confirme que o número e o conteúdo dos sites protegidos coincidem entre o par e que a sincronização de configuração realmente foi concluída. Em Configuração > Sites protegidos, confirme que cada site tem o suporte VRRP habilitado, que o papel ativo/backup de cada dispositivo é consistente em todos os seus sites, e que os IDs de rota virtual não estão duplicados.
Confirme que ambos os dispositivos estão configurados no mesmo modo -- ambos dual-active, ou um primário e um backup, não uma incompatibilidade entre os dois. Depois verifique Configuração > Configuração de HA em ambos os nós e confirme que os campos de IP de interface estão corretos, especificamente que o IP local e o IP do par não foram inseridos ao contrário em nenhum dos lados.
Esta nota se baseia no modelo de hot standby em dupla máquina de um appliance WAF Huawei -- seus caminhos de heartbeat de porta HA / porta de gerenciamento, seu failover de proxy reverso baseado em VRRP, e o modelo de configuração de site protegido por trás dos dois casos de campo aqui. Se sua plataforma usa um mecanismo de HA diferente, os caminhos de menu exatos e as strings de log mudam, mas o padrão subjacente -- verificar a sincronização de configuração antes de supor uma falha de rede, e checar colisões de endereçamento antes de supor uma falha de HA -- se aplica diretamente. Não cobre projetos de HA geograficamente dispersos (entre sites), nem clustering ativo-ativo além do modo dual-active mencionado acima.
Conte-nos a mensagem de log exata ou qual site específico está afetado, além de se você está em modo transparente ou de proxy reverso, e ajudamos você a restringir isso.