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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.