Uma regra de tráfego muito rígida não consegue lidar com cenários modernos; uma muito crua transforma operações em desenvolvimento de software.
As decisões de roteamento no tráfego de aplicações empresariais não dependem mais apenas de host, path ou porta. Correção de headers, compatibilidade com aplicações legadas, política CORS, segurança de cookies, limitação de largura de banda, acionamento de captcha, quarentena, páginas de erro personalizadas e transformação de resposta surgem todos no mesmo caminho de tráfego. Regras simples de balanceamento de carga são insuficientes para atender a essa variedade.
A maioria das abordagens tradicionais se inclina para um de dois extremos. Ou os operadores recebem apenas um punhado de ações predefinidas e casos de uso modernos se tornam insolúveis, ou a flexibilidade total exige escrever scripts brutos ou configuração de baixo nível. No segundo modelo, cada mudança de regra está vinculada a processos pesados — desenvolvimento de software, testes, revisão de código e auditoria de segurança.
O risco cresce ainda mais quando não há controle claro sobre qual tipo de serviço ou fase de tráfego uma ação se aplica. Escrever uma ação de header HTTP em um serviço TCP, esperar comportamento de requisição no lado da resposta ou adicionar uma ação com limite por pool mais de uma vez podem causar problemas em runtime.
O modelo correto combina um editor visual de regras com comportamento compilado em runtime. A GUI deve mostrar apenas combinações válidas; os metadados de ação devem governar o tipo de serviço e a fase de requisição/resposta; e uma saída de escape de regra manual controlada deve permanecer disponível para casos extremos.
O Motor de Regras de Tráfego do TR7 encontra esse equilíbrio: oferece aos operadores mais de 30 ações predefinidas, oculta combinações inválidas e promove regras corretas ao tráfego de produção como configuração validada.
Nossa abordagem
O TR7 aplica regras de tráfego por meio de taxonomia de ações, consciência de fase, configuração compilada e um modelo de promoção validado.
Os metadados de ação determinam combinações válidas antecipadamente
Cada ação carrega metadados para tipo de serviço, fase de requisição/resposta, suporte a condições, requisito de conteúdo, comportamento de código de erro e limite de uso por pool. A GUI lê esses metadados e mostra apenas as opções de regra válidas para o contexto atual.
As regras são compiladas em configuração de runtime na ordem correta
As ações compostas no editor visual são emitidas na configuração de trabalho em uma sequência de prioridade definida. Atribuição de variáveis, roteamento, operações de header, comportamento de erro e seleção de backend são todos executados em uma ordem previsível.
Ações avançadas são roteadas por um caminho de execução baseado em Lua quando necessário
Algumas ações avançadas que não podem ser expressas como diretivas estáticas são convertidas em funções chamáveis em runtime. Os operadores podem gerenciar comportamentos complexos de tráfego pelo mecanismo de regras sem escrever nenhum código por conta própria.
Um novo conjunto de regras não pode alcançar o tráfego ativo até ser validado
A nova configuração é gerada e então passa por uma etapa de validação. Se a validação falhar, a configuração em execução atual é preservada e a regra defeituosa nunca chega ao tráfego de produção.
Capacidades
O Motor de Regras de Tráfego combina ações predefinidas com condições FX para oferecer aplicação de políticas controlada ao longo do caminho de requisição e resposta.
56 ações predefinidas definem o comportamento do tráfego sem scripting
O TR7 fornece mais de 30 ações incluindo add_header, del_header, set_header, replace_header, redirect_scheme, req_redirect_location, set_path, normalize_uri, req_auth, cors, ipMask, cookieEncryption, bandwidthRule, advancedCaptcha, modifyResponse, silentLog, securityHeaders, cookieSecurity, deny, quarantine_table, manualRule e prometheusService. Os operadores selecionam ações no editor visual, preenchem parâmetros e vinculam condições. Isso remove tarefas comuns de manipulação de tráfego do domínio de scripting. As equipes de operações produzem regras mais rapidamente e reduzem a dependência de equipes de desenvolvimento.
Grupos de ações separam cenários de requisição, resposta e erro
As ações são apresentadas sob grupos semânticos como atRequest, atResponse, errorRules, cookieBased e tcpRules. Essa separação torna imediatamente claro em qual fase de tráfego uma regra será executada. Operações de header e path no lado da requisição não se misturam com headers de segurança e comportamento de página de erro no lado da resposta. A GUI reduz a complexidade técnica e organiza a criação de regras por intenção.
A consciência de tipo de serviço evita que ações inválidas apareçam
Cada ação carrega informações de compatibilidade para serviços do tipo HTTP, TCP ou ambos. Ações específicas de HTTP como CORS, manipulação de headers, segurança de cookies e reescrita de path não são mostradas para serviços TCP. Ações específicas de TCP como opções de gerenciamento de conexão não são apresentadas como opções em um serviço HTTP. Essa abordagem evita que os operadores selecionem uma regra que não pode funcionar antes mesmo de tentarem salvá-la.
O controle de fase de requisição e resposta reduz erros em runtime
Os metadados definem exatamente em qual fase cada ação é válida. Ações que devem ser executadas na fase de requisição não podem ser acidentalmente vinculadas ao lado da resposta, e ações focadas na resposta não podem ser indevidamente vinculadas ao caminho de requisição. Quando uma ação é válida em ambas as fases, isso é gerenciado explicitamente. Combinações inválidas são detectadas durante a validação de configuração antes de chegar ao tráfego de produção.
As condições FX vinculam ações a contexto de tráfego rico
As ações podem ser executadas incondicionalmente ou vinculadas a condições escritas na linguagem de expressões FX. IP de origem, país, ASN, path, header, cookie, campo do corpo, papel do usuário, pontuação WAAP e valores de timer podem ser todos usados no mesmo modelo de condição. Múltiplas condições são combinadas com lógica ACL para determinar quando uma ação dispara. Isso torna o mecanismo de regras um tomador de decisões consciente de contexto e conteúdo, não apenas uma tabela de roteamento estática.
Limites por pool reduzem o risco de uso duplicado e conflitante
Algumas ações devem aparecer apenas uma vez em um dado pool. Adicionar uma segunda instância de criptografia de cookies, correção de IP ou preservação de nome de header pode produzir resultados inesperados. O TR7 carrega a contagem máxima de uso por pool nos metadados de cada ação e evita que a GUI adicione uma segunda instância. Essa proteção reduz a inconsistência operacional antes de chegar à produção.
O gate de regra manual fornece flexibilidade controlada para casos extremos
Quando uma ação predefinida não cobre um cenário específico, manualRule permite que uma regra de tráfego bruta seja inserida. Esse recurso atua como uma saída de escape para cenários avançados fora do catálogo padrão do mecanismo. As regras manuais ainda passam pela etapa de validação de configuração e devem ser usadas com cuidado, pois afetam diretamente o comportamento do serviço. A plataforma oferece assim tanto a conveniência de regras visuais quanto a flexibilidade de nível avançado dentro do mesmo modelo.
As ações de cookie, CORS, header de segurança e quarentena estão prontas para uso
A ação cookieSecurity pode aplicar atributos Secure, HttpOnly e SameSite a cookies; cookieEncryption pode criptografar valores de cookies selecionados em trânsito. A ação cors consolida lista de origens permitidas, métodos, headers e configurações de cache de preflight sob uma única política. securityHeaders aplica um conjunto básico de headers de segurança centralmente. quarantine_table coloca um IP específico ou assinatura de cliente em quarentena por um período definido, contendo comportamento ruim repetido na borda.
Profundidade operacional
As regras de tráfego são operadas com promoção atômica, versionamento, sincronização de cluster, gerenciamento de conflitos, monitoramento e tratamento de casos extremos.
Promoção atômica de configuração
Um novo conjunto de regras é gerado separadamente e validado antes de se tornar ativo. Se a validação for bem-sucedida, a configuração ativa é trocada; se falhar, a configuração em execução atual é preservada. Esse modelo ajuda a evitar que uma regra defeituosa interrompa o tráfego de produção.
Registros de versão e auditoria
Cada mudança de regra deve ser registrada com uma identidade e timestamp. A equipe de operações pode ver quem alterou qual regra, qual pool foi afetado e qual versão reverter se necessário. Esses registros têm importância particular durante revisões de segurança e conformidade.
Sincronização de cluster
Em implantações de alta disponibilidade, o mesmo conjunto de regras deve ser distribuído para todos os nós pares. Sem isso, diferentes nós por trás do mesmo VIP podem exibir comportamento de tráfego diferente. O TR7 trata manter os conjuntos de regras consistentes em todo o cluster como parte de seu modelo operacional.
Comportamento de ações conflitantes
Quando mais de uma ação visa o mesmo header ou campo de tráfego, a ordem de prioridade é o fator decisivo. O sistema emite ações em uma sequência definida; o comportamento final depende dessa sequência. Os operadores devem avaliar conflitos potenciais em regras críticas usando registros de auditoria e lógica de prioridade.
Monitoramento de execução de ações
Se as ações estão sendo executadas pode ser rastreado via silentLog e encaminhado a um SIEM como um campo dedicado. Isso revela quantas requisições uma regra realmente correspondeu, em quais condições ela disparou e se produziu o efeito esperado. A observabilidade evita que o mecanismo de regras se comporte como uma caixa preta.
Comportamento de headers HTTP/2
Alguns backends legados são sensíveis à capitalização dos nomes de headers. A ação keepHeaderNames ajuda a preservar a capitalização original dos nomes de headers nesses cenários de compatibilidade. Essa configuração deve ser usada apenas em serviços que genuinamente a requerem e deve ser testada em conjunto com o comportamento da aplicação.
Quando usar
Transformar expectativas de headers para aplicações legadas
Equipes de modernização podem usar replace_header ou set_header para traduzir um nome de header esperado por um backend legado para a forma que a aplicação requer. Uma camada de compatibilidade é criada no ponto de entrada de tráfego sem tocar no código da aplicação.
Aplicar headers de segurança centralmente em todos os serviços
Equipes SaaS podem usar a ação securityHeaders para adicionar headers de segurança comumente exigidos na frente dos serviços centralmente. A linha de base de segurança é reforçada sem que cada equipe de aplicação precise configurar as mesmas definições independentemente.
Limitação de taxa e acionamento de captcha em fluxos de login
Aplicações financeiras podem combinar as ações bandwidthRule e advancedCaptcha para acionar um desafio captcha após tentativas de login repetidas com falha. O comportamento suspeito repetido é roteado para um fluxo de verificação mais rigoroso sem interromper completamente a experiência do usuário.
Proteger cookies de sessão no lado do cliente
Serviços de e-commerce e financeiros podem usar cookieEncryption para entregar cookies de sessão ao cliente em forma criptografada. O backend continua vendo o valor que espera enquanto o conteúdo do cookie é ilegível de forma significativa no lado do cliente.
Perguntas frequentes
Quais grupos de ações são usados com mais frequência entre as 56?
O que acontece se uma ação for vinculada à fase errada — requisição ou resposta?
Quais ações estão disponíveis para serviços TCP?
Quando a ação manualRule deve ser preferida?
Quais fontes de dados as condições FX suportam?
Como uma regra é atualizada sem afetar negativamente o tráfego de produção?
Assuma o controle do seu fluxo de tráfego com o mecanismo de regras
Controle total ao longo do caminho de requisição e resposta com mais de 30 ações predefinidas, condições FX e promoção atômica de configuração. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.