Authority Override
Demonstrates overriding the HTTP Host header sent to a specific upstream cluster, including requests received over HTTP/2
Configurations in Traffic Management.
Demonstrates overriding the HTTP Host header sent to a specific upstream cluster, including requests received over HTTP/2
A minimal HTTP reverse proxy with one listener and one upstream cluster.
Gates a filter on the logical upstream the router bound for the request
Selects an upstream endpoint straight from the logical binding, with no second router
Sends 10% of traffic to a canary backend while the stable backend handles the remaining 90%
Prevents cascading failures by tracking consecutive upstream errors per cluster
Tags an upstream cluster with opaque application metadata that consuming filters interpret
Selects an upstream endpoint from a trusted mutation source (e.g. external processing)
Detects gRPC requests from the content-type header and promotes the variant to filter metadata and results
Honours the grpc-timeout request header as a real deadline
Per-cluster health checks probe endpoints on a timer and remove unhealthy backends from the load balancer rotation
Demonstrates using DNS hostnames instead of IP addresses for upstream endpoints
One listener serves multiple domains
Demonstrates provider failover using the iterative_request_router filter
Demonstrates origin-aware failover: only an upstream 429 (rate limit) triggers the fallback
Routes each request to the backend with the fewest in-flight requests
Pins a user’s requests to one backend by hashing a request header through a Maglev lookup table
Samples two random endpoints and picks the one with fewer in-flight requests
Routes by URL path prefix
Defines primary and failover endpoint tiers
Selects an upstream endpoint at random, weighted by endpoint weight
Token bucket rate limiter with per-IP or global modes
Returns a 3xx redirect without contacting any upstream
Automatically retries failed upstream requests with exponential backoff and a token-bucket budget to prevent retry storms
Routes requests to a stable backend by hashing a configurable request header through a sorted virtual-node ring
Default strategy Configuration example for praxis.
Hashes a request header to pin a user’s requests to one backend
Returns a fixed response without contacting any upstream
Pins clients to a specific backend across requests
Filters endpoints by metadata labels and applies an inner strategy within the matching subset
Returns 504 if the upstream takes longer than timeout_ms to respond
Traffic split proportional to per-endpoint weights
Prefers same-zone endpoints to reduce cross-zone network costs and latency