Una regla de tráfico demasiado rígida no puede manejar los escenarios modernos; una demasiado en bruto convierte las operaciones en desarrollo de software.
Las decisiones de enrutamiento en el tráfico de aplicaciones empresariales ya no dependen solo del host, la ruta o el puerto. La corrección de headers, la compatibilidad con aplicaciones heredadas, la política CORS, la seguridad de cookies, la limitación de ancho de banda, la activación de captcha, la cuarentena, las páginas de error personalizadas y la transformación de respuestas emergen todas en el mismo camino de tráfico. Las reglas de balanceo de carga simples son insuficientes para satisfacer esta variedad.
La mayoría de los enfoques tradicionales se inclinan hacia uno de dos extremos. O se les da a los operadores solo un puñado de acciones preestablecidas y los casos de uso modernos se vuelven irresolubles, o la flexibilidad total exige escribir scripts en bruto o configuración de bajo nivel. En el segundo modelo, cada cambio de regla se vincula a procesos pesados — desarrollo de software, pruebas, revisión de código y auditoría de seguridad.
El riesgo crece aún más cuando no hay un control claro sobre qué tipo de servicio o fase de tráfico aplica una acción. Escribir una acción de header HTTP en un servicio TCP, esperar un comportamiento de solicitud en el lado de la respuesta, o añadir una acción limitada por pool más de una vez pueden causar problemas en tiempo de ejecución.
El modelo correcto combina un editor visual de reglas con comportamiento de runtime compilado. La GUI debe mostrar solo combinaciones válidas; los metadatos de acción deben gobernar el tipo de servicio y la fase de solicitud/respuesta; y debe permanecer disponible una válvula de escape de regla manual controlada para casos extremos.
El Motor de Reglas de Tráfico TR7 logra este equilibrio: ofrece a los operadores más de 30 acciones listas para usar, oculta las combinaciones inválidas y promueve las reglas correctas al tráfico de producción como configuración validada.
Nuestro enfoque
TR7 aplica las reglas de tráfico a través de taxonomía de acciones, conciencia de fase, configuración compilada y un modelo de promoción validado.
Los metadatos de acción determinan las combinaciones válidas de antemano
Cada acción lleva metadatos para el tipo de servicio, la fase de solicitud/respuesta, el soporte de condiciones, el requisito de contenido, el comportamiento de código de error y el límite de uso por pool. La GUI lee estos metadatos y muestra solo las opciones de regla válidas para el contexto actual.
Las reglas se compilan en la configuración de runtime en el orden correcto
Las acciones compuestas en el editor visual se emiten en la configuración de trabajo en una secuencia de prioridad definida. La asignación de variables, el enrutamiento, las operaciones de headers, el comportamiento de errores y la selección de backend se ejecutan todos en un orden predecible.
Las acciones avanzadas se enrutan a través de una ruta de ejecución basada en Lua cuando es necesario
Algunas acciones avanzadas que no pueden expresarse como directivas estáticas se convierten en funciones invocables en tiempo de ejecución. Los operadores pueden gestionar comportamientos de tráfico complejos a través del motor de reglas sin escribir ningún código ellos mismos.
Un nuevo conjunto de reglas no puede llegar al tráfico activo hasta que sea validado
La nueva configuración se genera y luego pasa por un paso de validación. Si la validación falla, la configuración en ejecución actual se preserva y la regla defectuosa nunca llega al tráfico de producción.
Capacidades
El Motor de Reglas de Tráfico combina acciones listas para usar con condiciones FX para ofrecer una aplicación de política controlada a través del camino de solicitudes y respuestas.
56 acciones listas para usar definen el comportamiento del tráfico sin scripting
TR7 proporciona más de 30 acciones incluyendo 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 y prometheusService. Los operadores seleccionan acciones en el editor visual, completan los parámetros y adjuntan condiciones. Esto elimina las tareas comunes de manipulación de tráfico del dominio del scripting. Los equipos de operaciones producen reglas más rápido y reducen la dependencia de los equipos de desarrollo.
Los grupos de acciones separan los escenarios de solicitud, respuesta y error
Las acciones se presentan bajo grupos semánticos como atRequest, atResponse, errorRules, cookieBased y tcpRules. Esta separación hace inmediatamente claro en qué fase del tráfico se ejecutará una regla. Las operaciones de header y ruta en el lado de la solicitud no se mezclan con los headers de seguridad y el comportamiento de página de error en el lado de la respuesta. La GUI reduce la complejidad técnica y organiza la creación de reglas por intención.
La conciencia del tipo de servicio evita que aparezcan acciones inválidas
Cada acción lleva información de compatibilidad para HTTP, TCP o ambos tipos de servicio. Las acciones específicas de HTTP como CORS, la manipulación de headers, la seguridad de cookies y la reescritura de rutas no se muestran para los servicios TCP. Las acciones específicas de TCP como las opciones de gestión de conexiones no se presentan como opciones en un servicio HTTP. Este enfoque evita que los operadores seleccionen una regla que no puede funcionar antes de intentar guardarla.
El control de fase de solicitud y respuesta reduce los errores en tiempo de ejecución
Los metadatos definen exactamente en qué fase es válida cada acción. Las acciones que deben ejecutarse en la fase de solicitud no pueden vincularse accidentalmente al lado de la respuesta, y las acciones centradas en la respuesta no pueden enlazarse incorrectamente a la ruta de solicitud. Cuando una acción es válida en ambas fases, eso se gestiona explícitamente. Las combinaciones inválidas se detectan durante la validación de configuración antes de que lleguen al tráfico de producción.
Las condiciones FX vinculan las acciones a un contexto de tráfico enriquecido
Las acciones pueden ejecutarse incondicionalmente o vincularse a condiciones escritas en el lenguaje de expresión FX. La IP de origen, el país, el ASN, la ruta, el header, la cookie, el campo del cuerpo, el rol del usuario, el score WAAP y los valores del temporizador pueden usarse todos en el mismo modelo de condición. Múltiples condiciones se combinan con lógica ACL para determinar cuándo se activa una acción. Esto convierte al motor de reglas en un tomador de decisiones consciente del contexto y del contenido, no solo en una tabla de enrutamiento estática.
Los límites por pool reducen el riesgo de uso duplicado y conflictivo
Algunas acciones deben aparecer solo una vez en un pool dado. Añadir una segunda instancia de cifrado de cookies, corrección de IP o preservación de nombres de header puede producir resultados inesperados. TR7 lleva el recuento máximo de uso por pool en los metadatos de cada acción y evita que la GUI añada una segunda instancia. Esta protección reduce la inconsistencia operacional antes de que llegue a producción.
La válvula de escape de regla manual proporciona flexibilidad controlada para casos extremos
Cuando una acción preestablecida no cubre un escenario específico, manualRule permite insertar una regla de tráfico en bruto. Esta característica actúa como válvula de escape para escenarios avanzados fuera del catálogo estándar del motor. Las reglas manuales aún pasan por el paso de validación de configuración y deben usarse con cuidado, ya que afectan el comportamiento del servicio directamente. La plataforma ofrece así tanto la comodidad de reglas visuales como la flexibilidad de nivel avanzado dentro del mismo modelo.
Las acciones de cookie, CORS, header de seguridad y cuarentena vienen listas para usar
La acción cookieSecurity puede aplicar los atributos de cookie Secure, HttpOnly y SameSite; cookieEncryption puede cifrar los valores de cookie seleccionados en tránsito. La acción cors consolida la lista de origins permitidos, métodos, headers y configuración de caché de preflight bajo una única política. securityHeaders aplica un conjunto de headers de seguridad de base de forma centralizada. quarantine_table coloca una IP específica o una firma de cliente en cuarentena durante un período definido, conteniendo el comportamiento mal reiterado en el edge.
Profundidad operacional
Las reglas de tráfico se operan con promoción atómica, versionado, sincronización de clúster, gestión de conflictos, monitoreo y manejo de casos extremos.
Promoción atómica de configuración
Un nuevo conjunto de reglas se genera por separado y se valida antes de activarse. Si la validación tiene éxito, la configuración activa se intercambia; si falla, la configuración en ejecución actual se preserva. Este modelo ayuda a evitar que una regla defectuosa interrumpa el tráfico de producción.
Registros de versión y auditoría
Cada cambio de regla debe registrarse con una identidad y marca de tiempo. El equipo de operaciones puede ver quién cambió qué regla, qué pool se vio afectado y a qué versión revertir si es necesario. Estos registros tienen particular importancia durante las revisiones de seguridad y cumplimiento.
Sincronización de clúster
En despliegues de alta disponibilidad, el mismo conjunto de reglas debe distribuirse a todos los nodos pares. Sin esto, diferentes nodos detrás de la misma VIP pueden mostrar un comportamiento de tráfico diferente. TR7 trata mantener los conjuntos de reglas consistentes en todo el clúster como parte de su modelo operacional.
Comportamiento de acciones conflictivas
Cuando más de una acción apunta al mismo header o campo de tráfico, el orden de prioridad es el factor decisivo. El sistema emite las acciones en una secuencia definida; el comportamiento final depende de esa secuencia. Los operadores deben evaluar los posibles conflictos en las reglas críticas usando los registros de auditoría y la lógica de prioridad.
Monitoreo de ejecución de acciones
Si las acciones se están ejecutando puede rastrearse a través de silentLog y reenviarse a un SIEM como un campo dedicado. Esto revela cuántas solicitudes coincidieron realmente con una regla, bajo qué condiciones se activó y si produjo el efecto esperado. La observabilidad evita que el motor de reglas se comporte como una caja negra.
Comportamiento de headers HTTP/2
Algunos backends heredados son sensibles a las mayúsculas y minúsculas de los nombres de header. La acción keepHeaderNames ayuda a preservar las mayúsculas originales de los nombres de header en esos escenarios de compatibilidad. Esta configuración solo debe usarse en servicios que realmente lo requieran y debe probarse junto con el comportamiento de la aplicación.
Cuándo usarlo
Transformar las expectativas de header para aplicaciones heredadas
Los equipos de modernización pueden usar replace_header o set_header para traducir un nombre de header esperado por un backend heredado a la forma que requiere la aplicación. Se crea una capa de compatibilidad en el punto de entrada del tráfico sin tocar el código de la aplicación.
Aplicar headers de seguridad de forma centralizada en todos los servicios
Los equipos SaaS pueden usar la acción securityHeaders para añadir los headers de seguridad comúnmente requeridos frente a los servicios de forma centralizada. La base de seguridad se fortalece sin que cada equipo de aplicación tenga que configurar los mismos ajustes de forma independiente.
Limitación de tasa y activación de captcha en flujos de login
Las aplicaciones financieras pueden combinar las acciones bandwidthRule y advancedCaptcha para activar un desafío captcha después de intentos de login fallidos repetidos. El comportamiento sospechoso repetido se enruta a un flujo de verificación más estricto sin interrumpir completamente la experiencia del usuario.
Proteger las cookies de sesión en el lado del cliente
Los servicios de e-commerce y financieros pueden usar cookieEncryption para entregar las cookies de sesión al cliente de forma cifrada. El backend continúa viendo el valor que espera mientras el contenido de la cookie es ilegible de forma significativa en el lado del cliente.
Preguntas frecuentes
¿Cuáles son los grupos de acciones más utilizados entre las 56?
¿Qué ocurre si una acción se vincula a la fase incorrecta — solicitud o respuesta?
¿Qué acciones están disponibles para los servicios TCP?
¿Cuándo debería preferirse la acción manualRule?
¿Qué fuentes de datos soportan las condiciones FX?
¿Cómo se actualiza una regla sin afectar negativamente al tráfico de producción?
Tome el control de su flujo de tráfico con el motor de reglas
Control total a través del camino de solicitudes y respuestas con más de 30 acciones listas para usar, condiciones FX y promoción atómica de configuración. Permítanos guiarle por una configuración en vivo sobre sus propios servicios.