A traffic rule that is too rigid cannot handle modern scenarios; one that is too raw turns operations into software development.
Routing decisions in enterprise application traffic no longer depend only on host, path or port. Header correction, legacy application compatibility, CORS policy, cookie security, bandwidth limiting, captcha triggering, quarantine, custom error pages and response transformation all surface on the same traffic path. Simple load-balancing rules are insufficient to meet this variety.
Most traditional approaches fall toward one of two extremes. Either operators are given only a handful of preset actions and modern use cases become unsolvable, or full flexibility demands writing raw scripts or low-level configuration. In the second model, every rule change ties back to heavy processes — software development, testing, code review and security audit.
The risk grows further when there is no clear control over which service type or traffic phase an action applies to. Writing an HTTP header action on a TCP service, expecting request behavior on the response side, or adding a pool-limited action more than once can all cause runtime problems.
The right model combines a visual rule editor with compiled runtime behavior. The GUI should show only valid combinations; action metadata should govern service type and request/response phase; and a controlled manual-rule escape hatch should remain available for edge cases.
TR7 Traffic Rules Engine strikes this balance: it gives operators 56 ready-made actions, hides invalid combinations, and promotes correct rules to production traffic as validated configuration.
Our approach
TR7 enforces traffic rules through action taxonomy, phase awareness, compiled configuration and a validated promotion model.
Action metadata determines valid combinations up front
Each action carries metadata for service type, request/response phase, condition support, content requirement, error-code behavior and per-pool usage limit. The GUI reads this metadata and shows only the valid rule options for the current context.
Rules are compiled into runtime configuration in the correct order
Actions composed in the visual editor are emitted into the working configuration in a defined priority sequence. Variable assignment, routing, header operations, error behavior and backend selection all execute in a predictable order.
Advanced actions are routed through a Lua-based execution path when needed
Some advanced actions that cannot be expressed as static directives are converted into callable functions at runtime. Operators can manage complex traffic behaviors through the rule engine without writing any code themselves.
A new rule set cannot reach active traffic until it is validated
New configuration is generated and then passed through a validation step. If validation fails, the currently running configuration is preserved and the faulty rule never reaches production traffic.
Capabilities
The Traffic Rules Engine combines ready-made actions with FX conditions to deliver controlled policy enforcement across the request and response path.
56 ready-made actions define traffic behavior without scripting
TR7 provides 56 named actions including 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 and prometheusService. Operators select actions in the visual editor, fill in parameters and attach conditions. This removes common traffic manipulation tasks from the scripting domain. Operations teams produce rules faster and reduce dependence on development teams.
Action groups separate request, response and error scenarios
Actions are presented under semantic groups such as atRequest, atResponse, errorRules, cookieBased and tcpRules. This separation makes it immediately clear at which traffic phase a rule will run. Header and path operations on the request side do not mix with security headers and error page behavior on the response side. The GUI reduces technical complexity and organizes rule authoring by intent.
Service-type awareness prevents invalid actions from appearing
Each action carries compatibility information for HTTP, TCP or both service types. HTTP-specific actions such as CORS, header manipulation, cookie security and path rewriting are not shown for TCP services. TCP-specific actions such as connection management options are not presented as choices in an HTTP service. This approach prevents operators from selecting a rule that cannot work before they even try to save it.
Request and response phase control reduces runtime errors
Metadata defines exactly which phase each action is valid in. Actions that must run at the request phase cannot be accidentally attached to the response side, and response-focused actions cannot be misbound to the request path. When an action is valid in both phases, that is managed explicitly. Invalid combinations are caught during configuration validation before they reach production traffic.
FX conditions bind actions to rich traffic context
Actions can run unconditionally or be tied to conditions written in the FX expression language. Source IP, country, ASN, path, header, cookie, body field, user role, WAAP score and timer values can all be used in the same condition model. Multiple conditions are combined with ACL logic to determine when an action fires. This makes the rule engine a context-aware and content-aware decision maker, not just a static routing table.
Per-pool limits reduce the risk of duplicate and conflicting usage
Some actions should only appear once in a given pool. Adding a second instance of cookie encryption, IP correction or header-name preservation can produce unexpected results. TR7 carries the maximum per-pool usage count in each action's metadata and prevents the GUI from adding a second instance. This guard reduces operational inconsistency before it reaches production.
The manual rule gate provides controlled flexibility for edge cases
When a preset action does not cover a specific scenario, manualRule allows a raw traffic rule to be inserted. This feature acts as an escape hatch for advanced scenarios outside the standard engine catalog. Manual rules still pass through the configuration validation step and should be used carefully, as they affect service behavior directly. The platform thus offers both visual rule convenience and advanced-level flexibility within the same model.
Cookie, CORS, security header and quarantine actions ship ready to use
The cookieSecurity action can enforce Secure, HttpOnly and SameSite cookie attributes; cookieEncryption can encrypt selected cookie values in transit. The cors action consolidates origin allow-list, methods, headers and preflight cache settings under a single policy. securityHeaders applies a baseline set of security headers centrally. quarantine_table places a specific IP or client signature into quarantine for a defined period, containing repeated bad behavior at the edge.
Operational depth
Traffic rules are operated with atomic promotion, versioning, cluster synchronization, conflict management, monitoring and edge-case handling.
Atomic configuration promotion
A new rule set is generated separately and validated before becoming active. If validation succeeds, the active configuration is swapped; if it fails, the currently running configuration is preserved. This model helps prevent a faulty rule from interrupting production traffic.
Version and audit records
Every rule change should be recorded with an identity and timestamp. The operations team can see who changed which rule, which pool was affected and which version to roll back to if needed. These records carry particular importance during security and compliance reviews.
Cluster synchronization
In high-availability deployments the same rule set must be distributed to all peer nodes. Without this, different nodes behind the same VIP can exhibit different traffic behavior. TR7 treats keeping rule sets consistent across the cluster as part of its operational model.
Conflicting action behavior
When more than one action targets the same header or traffic field, priority order is the deciding factor. The system emits actions in a defined sequence; the final behavior depends on that sequence. Operators should evaluate potential conflicts in critical rules using audit records and priority logic.
Action execution monitoring
Whether actions are executing can be tracked through silentLog and forwarded to a SIEM as a dedicated field. This reveals how many requests a rule actually matched, under which conditions it fired and whether it produced the expected effect. Observability keeps the rule engine from behaving like a black box.
HTTP/2 header behavior
Some legacy backends are sensitive to the capitalization of header names. The keepHeaderNames action helps preserve original header name casing in those compatibility scenarios. This setting should only be used on services that genuinely require it and should be tested alongside application behavior.
When to use it
Transforming header expectations for legacy applications
Modernization teams can use replace_header or set_header to translate a header name expected by a legacy backend into the form the application requires. A compatibility layer is created at the traffic entry point without touching application code.
Applying security headers centrally across services
SaaS teams can use the securityHeaders action to add commonly required security headers in front of services centrally. The security baseline is strengthened without each application team having to configure the same settings independently.
Rate limiting and captcha triggering on login flows
Financial applications can combine the bandwidthRule and advancedCaptcha actions to trigger a captcha challenge after repeated failed login attempts. Suspicious repeat behavior is routed into a stricter verification flow without fully interrupting the user experience.
Protecting session cookies on the client side
E-commerce and financial services can use cookieEncryption to deliver session cookies to the client in encrypted form. The backend continues to see the value it expects while the cookie content is unreadable in a meaningful way on the client side.
Frequently asked questions
Which groups of actions are used most often among the 56?
What happens if an action is attached to the wrong phase — request or response?
Which actions are available for TCP services?
When should the manualRule action be preferred?
What data sources do FX conditions support?
How is a rule updated without negatively affecting production traffic?
Take control of your traffic flow with the rule engine
Full control across the request and response path with 56 ready-made actions, FX conditions and atomic configuration promotion. Let us walk through a live setup on your own services.