Noxy
The darkness your packets pass through.
An HTTP proxy with a pluggable middleware pipeline. Forward mode intercepts HTTPS via TLS MITM; reverse mode sits in front of a backend and forwards traffic directly. Built on top of tower, Noxy gives you full access to decoded HTTP requests and responses flowing through the proxy using standard tower Service and Layer abstractions -- including all existing tower-http middleware out of the box.
Features
- Forward proxy -- CONNECT tunnel with TLS MITM, per-host certificate generation signed by a user-provided CA
- Reverse proxy -- point Noxy at a fixed upstream and forward all incoming HTTP traffic directly -- no CONNECT, no CA, no client-side proxy configuration required
- Multi-upstream routing -- route requests to different backends by path prefix, host, or custom predicates. Load balance across multiple backends with round-robin or random strategies.
- Tower middleware pipeline -- plug in any tower
LayerorServiceto inspect and modify HTTP traffic. Works with tower-http layers (compression, tracing, CORS, etc.) and your own custom services. Usefrom_fnto create middleware from a simple async closure without boilerplate. - Built-in middleware -- traffic logging, header modification, URL rewriting, block list, latency injection, bandwidth throttling, fault injection, rate limiting, sliding window rate limiting, retry with exponential backoff and retry budget, circuit breaker, fixed responses, and TypeScript scripting
- Redis backend -- optional Redis-backed state for rate limiting, sliding window, and circuit breaker middleware. Enables shared state across multiple proxy instances for horizontal scaling. Falls back to in-memory on Redis errors. (
redisfeature) - Conditional rules -- apply middleware only to requests matching a host, path, or HTTP method (supports glob patterns:
*,**,?,[a-z]) - KDL config file -- configure the proxy and middleware rules declaratively, with nested
matchblocks for layered rules - Upstream connection pooling -- reuses TLS connections to upstream servers across client tunnels. HTTP/2 connections are multiplexed; HTTP/1.1 connections are recycled from an idle pool.
- HTTP/1.1 and HTTP/2 support (auto-negotiated via ALPN)
- Streaming bodies -- middleware can process data as it arrives without buffering
- Async I/O with Tokio and Hyper
Library Usage
Forward proxy (TLS MITM)
use Duration;
use Proxy;
use *;
let proxy = builder
.ca_pem_files?
// Log all traffic with request/response bodies
.layer
// Decode gzip/brotli/deflate/zstd response bodies
.layer
// Add latency to every request
.layer
// Limit bandwidth to 50 KB/s
.layer
// Global rate limit: 100 requests per second
.layer
// Per-host sliding window: 10 req/s per hostname
.layer
// Retry 429/5xx responses up to 3 times with exponential backoff
.layer
// Trip circuit after 5 consecutive failures, recover in 30s
.layer
// Inject request/response headers
.layer
// Rewrite request paths
.layer
// Block tracking domains
.layer
// 50% of requests to /flaky return 503
.layer
// Glob pattern: add latency to all paths under /api/*/slow
.layer
// Return a fixed response for /health
.layer
.build?;
proxy.listen.await?;
Reverse proxy
use Proxy;
let proxy = builder
.reverse_proxy?
.layer
.build?;
proxy.listen.await?;
Multi-upstream routing
use Proxy;
use Upstream;
let proxy = builder
.reverse_proxy?
// Route /api to a dedicated backend
.route_prefix?
// Load balance /static across two CDN nodes
.route_prefix_balanced?
// Custom predicate with full-flexibility API
.route
.build?;
proxy.listen.await?;
Any tower Layer<HttpService> works in both modes. The innermost service forwards requests to the upstream server; your layers wrap around it in an onion model and can inspect or modify requests before forwarding and responses after.
Custom middleware
Use middleware to create middleware from an async closure instead of implementing Layer + Service manually. The closure receives each request and a Next handle for forwarding it downstream:
use Proxy;
let proxy = builder
.ca_pem_files?
.middleware
.build?;
proxy.listen.await?;
Short-circuit without forwarding upstream by returning a response directly:
use Proxy;
use full_body;
let proxy = builder
.reverse_proxy?
.middleware
.build?;
For shared state across requests, capture an Arc in the closure:
use ;
use Proxy;
let counter = new;
let c = counter.clone;
let proxy = builder
.reverse_proxy?
.middleware
.build?;
The equivalent from_fn function works with layer for composability with Conditional and other layers:
use Proxy;
use from_fn;
let proxy = builder
.ca_pem_files?
.layer
.build?;
Installation
Pre-built binaries
Download a pre-built binary from the latest release:
| Platform | Architecture | Download |
|---|---|---|
| Linux | x86_64 | noxy-x86_64-unknown-linux-gnu.tar.gz |
| Linux | aarch64 | noxy-aarch64-unknown-linux-gnu.tar.gz |
| macOS | Apple Silicon | noxy-aarch64-apple-darwin.tar.gz |
# Example: install on Linux x86_64
|
Cargo
Quick Start
Reverse proxy (simplest)
No certificates needed -- just point Noxy at a backend:
# Start noxy in front of a local service
# Requests go directly to noxy, no proxy configuration needed
Forward proxy (TLS MITM)
1. Generate a CA certificate
Or with OpenSSL:
2. Run the proxy
3. Make a request through the proxy
Trusting the CA system-wide
Instead of passing --cacert every time, you can install ca-cert.pem into your OS or browser trust store. This lets any application use the proxy transparently.
Important: Only do this in development/testing environments. Remove the CA when you're done.
CLI
The CLI provides flags for common middleware without needing a config file.
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
# Log all traffic
# Log traffic including request/response bodies
# Add 200ms latency to every request
# Add random latency between 100ms and 500ms
# Limit bandwidth to 10 KB/s
# Rate limit: 30 requests per second
# Per-host rate limit: 10 requests per second per hostname
# Multi-window rate limiting
# Sliding window: hard-cap 30 requests per second
# Per-host sliding window: 10 requests per second per hostname
# Retry failed requests up to 3 times with exponential backoff
# Circuit breaker: trip after 5 consecutive 5xx failures, recover after 30s
# Rewrite request paths using matchit patterns
# Rewrite request paths using regex
# Block requests to tracking domains
# Block requests to admin paths
# Add a request header to all proxied requests
# Remove the Server response header
# Combine multiple flags
# Set upstream connection pool size per host (0 to disable)
# Set pool idle timeout
# Accept invalid upstream certificates (e.g. self-signed)
# Custom port, bind address, and CA paths
# Reverse proxy to a local backend
# Reverse proxy to an HTTPS backend with rate limiting
# Reverse proxy with client-facing TLS
# Run a TypeScript middleware script (requires scripting feature)
# Limit body bytes scripts may buffer when calling req.body()/res.body()
# Use Redis for distributed rate limiting across multiple proxy instances (requires redis feature)
Config File
For conditional rules and more complex setups, use a KDL config file.
A config has three zones at the top level:
- Process settings —
redis, timeouts, pool sizing, etc. Apply across every listener. - Global rules — middleware leaves and
matchblocks declared at the top level. They are applied to every listener, with innermost-wins shadowing if a listener redeclares the same exclusive kind. - Listener blocks — one or more
forward { … }orreverse { … }blocks. Each block declares its own port, mode-specific config (cafor forward,upstreamfor reverse), and rule body.
Rule nodes are either middleware leaves (log, latency, rate-limit, …) or match blocks (with aliases host, path, method, methods) that scope nested rules to requests satisfying their predicate. Nested matches AND naturally — host "x" { path "/y" { … } } is the same as match host="x" path="/y" { … }.
CLI middleware flags (--rate-limit, --log, …) append to the global rule body and apply to every listener. CLI listener flags (--port, --upstream, --cert/--key) synthesize a single listener block when the config has none.
Forward proxy (basic)
forward port=8080 {
ca cert="ca-cert.pem" key="ca-key.pem"
log
block {
host "*.tracking.com"
}
}
Point a browser or HTTP client at localhost:8080 as its proxy, install the CA cert in your trust store, and Noxy will MITM every HTTPS connection — logging traffic and blocking tracking domains.
Reverse proxy (sidecar)
reverse port=8080 {
upstream "http://localhost:3000"
// Optional: serve HTTPS to clients
// tls cert="server.pem" key="server-key.pem"
log
rate-limit count=100 window="1s"
}
// Optional: use Redis for distributed middleware state (requires redis feature)
// redis url="redis://localhost:6379"
Multi-upstream routing
reverse port=8080 {
upstream "http://default:3000"
// Route /api to a dedicated backend with rate limiting
path "/api/" {
upstream "http://api:8080"
rate-limit count=100 window="1s"
}
// Load balance /static across two CDN nodes
path "/static/" {
upstream "http://cdn1:9000" "http://cdn2:9000" balance="round-robin"
}
// Random selection for /images
path "/images/" {
upstream "http://img1:9000" "http://img2:9000" balance="random"
}
}
Forward proxy
// Process-level settings (apply to all listeners)
// accept-invalid-upstream-certs true
// pool-max-idle-per-host 8
// pool-idle-timeout "90s"
// Global rules — apply to every listener below
log
// Block tracking domains for everyone
block {
host "*.tracking.com"
host "ads.example.com"
path "/admin/*"
}
forward port=8080 {
ca cert="ca-cert.pem" key="ca-key.pem"
// Forward-only proxy auth
// credential "alice" "secret"
// Add 200ms latency to API requests
path "/api/" {
latency "200ms"
}
// Simulate slow downloads with random latency and bandwidth limit
path "/downloads/" {
latency "50ms..200ms"
bandwidth 10240
}
// Inject faults on a specific endpoint
path "/flaky" {
fault error-rate=0.5 abort-rate=0.02
}
// Mock a health check endpoint
path "/health" {
respond body="ok"
}
// Rate limit: 30 requests per second globally for this listener
rate-limit count=30 window="1s"
// Rate limit: 1500 requests per minute, per host, with burst of 100
rate-limit count=1500 window="60s" burst=100 per-host=true
// Sliding window: hard-cap 10 requests per second (no burst, no smoothing)
sliding-window count=10 window="1s"
// Retry failed requests (429, 502, 503, 504) up to 3 times
retry max-retries=3 backoff="1s" max-replay-body-bytes=1048576
// Retry only 503s with custom statuses, scoped to /api
path "/api/" {
retry max-retries=5 backoff="500ms" {
statuses 503
}
}
// Retry with budget: at most 20% of requests can be retries (prevents retry storms)
retry max-retries=3 {
budget ratio=0.2 window="10s" min-retries=30
}
// Circuit breaker: trip after 5 consecutive 5xx failures, recover after 30s
circuit-breaker threshold=5 recovery="30s"
// Per-host circuit breaker with 2 half-open probes
circuit-breaker threshold=3 recovery="10s" half-open-probes=2 per-host=true
// Circuit breaker with local cache to reduce Redis round-trips (Redis only)
circuit-breaker threshold=5 recovery="30s" cache-ttl="100ms"
// Add a request header and strip a response header
set-request-header "x-proxy" "noxy"
remove-response-header "server"
// Add API version header to /api requests
path "/api/" {
set-request-header "x-api-version" "2"
}
// Rewrite request paths using matchit patterns
rewrite-path "/api/v1/{*rest}" "/v2/{rest}"
// Rewrite request paths using regex
rewrite-path-regex "/api/v\\d+/(.*)" "/latest/$1"
// Block with custom status and body
block {
host "internal.corp.com"
response status=404 body="not found"
}
// Run a TypeScript middleware script from a file (requires scripting feature)
// script-file "middleware.ts"
// Or inline the script source directly with a raw string
// script r#"
// export default async function(req, respond) {
// req.headers.set("x-from-inline", "yes");
// return await respond(req);
// }
// "#
// Run a script with a shared V8 isolate across all connections, scoped to /api
// path "/api/" {
// script-file "api_middleware.ts" shared=true
// }
// Return 503 for all paths under /fail
path "/fail/" {
respond status=503 body="service unavailable"
}
// Glob patterns in match conditions
// Match any subdomain of example.com
host "*.example.com" {
latency "100ms"
}
// Match any single-segment path under /api/
path "/api/*/users" {
rate-limit count=10 window="1s"
}
// Match all paths recursively under /static/
path "/static/**" {
set-response-header "cache-control" "public, max-age=86400"
}
// Match by HTTP method, scoped to /api
methods "POST" "PUT" "DELETE" {
path "/api/" {
rate-limit count=10 window="1s"
}
}
}
Multiple listeners in one process
A single config can declare any mix of forward and reverse listeners. Each listener has its own port and rule body; global rules apply to every listener.
// Global: log and block trackers everywhere
log
block {
host "*.tracking.com"
}
// Forward proxy on 8080 (HTTPS MITM)
forward port=8080 {
ca cert="ca.pem" key="ca-key.pem"
credential "alice" "secret"
}
// Sidecar #1: in front of the API backend
reverse port=8081 {
upstream "http://api:3000"
rate-limit count=100 window="1s"
}
// Sidecar #2: in front of the search backend, with a stricter circuit breaker
reverse port=8082 {
upstream "http://search:4000"
circuit-breaker threshold=3 recovery="30s"
// Override the global log: skip body logging for high-volume search
log bodies=false
}
The last listener overrides the global log for itself only — the forward proxy and the API sidecar still log with default settings.
Rule nodes
The body of a config is a sequence of rule nodes. Match nodes scope their nested children to requests satisfying a predicate; middleware nodes apply directly. Match nodes nest, AND-ing predicates as you go deeper.
Match nodes
| Node | Form | Notes |
|---|---|---|
match |
match host="..." path="..." method="..." { ... } |
Multi-field predicate. All fields AND together. |
host |
host "*.example.com" { ... } |
Single-host alias. Glob supported. |
path |
path "/api/" { ... } |
Single-path alias. Glob supported; trailing / means subtree-including-self. |
method |
method "GET" { ... } |
Single-method alias. |
methods |
methods "GET" "POST" { ... } |
Multi-method alias (variadic). |
Match properties: host, path, method, and header { ... } (child node, name + value). Each match node also accepts an optional name="..." for stable Redis key scoping.
Path globs use * (single segment), ** (any depth), ? (single char), [a-z] (character class). Trailing / on a path turns it into a "subtree-including-self" match: path "/v1/" matches /v1, /v1/foo, /v1/foo/bar.
Middleware nodes
| Node | Form | Notes |
|---|---|---|
log |
log or log bodies=true |
Traffic logger. |
latency |
latency "200ms" or latency "100ms..500ms" |
Fixed or random range. |
bandwidth |
bandwidth 10240 |
Bytes/sec throughput limit. |
fault |
fault error-rate=0.5 abort-rate=0.02 error-status=503 |
Random faults. |
rate-limit |
rate-limit count=30 window="1s" burst=100 per-host=true |
Token bucket. |
sliding-window |
sliding-window count=10 window="1s" per-host=true |
Hard-cap, no burst. |
retry |
retry max-retries=3 backoff="1s" max-backoff="30s" max-replay-body-bytes=1048576 { statuses 503 429; budget ratio=0.2 window="10s" min-retries=30 } |
Retry on 429/5xx by default. statuses and budget are child nodes. |
circuit-breaker |
circuit-breaker threshold=5 recovery="30s" half-open-probes=2 per-host=true cache-ttl="100ms" |
cache-ttl is Redis-only. |
respond |
respond body="ok" status=200 |
Short-circuits without forwarding upstream. |
upstream |
upstream "http://a:80" "http://b:80" balance="round-robin" |
Variadic URLs; balance="round-robin" (default) or "random". Routes matched requests to the given backend(s). |
block |
block { host "*.tracking.com"; path "/admin/*"; response status=404 body="not found" } |
host / path children stack; response child is optional (default 403). |
set-request-header |
set-request-header "x-proxy" "noxy" |
Sets one request header. |
append-request-header |
append-request-header "via" "noxy" |
Appends one request header. |
remove-request-header |
remove-request-header "x-internal" |
Removes one request header. |
set-response-header |
set-response-header "x-served-by" "noxy" |
Sets one response header. |
append-response-header |
append-response-header "via" "noxy" |
Appends one response header. |
remove-response-header |
remove-response-header "server" |
Removes one response header. |
rewrite-path |
rewrite-path "/api/v1/{*rest}" "/v2/{rest}" |
matchit-pattern rewrite. |
rewrite-path-regex |
rewrite-path-regex "/v\\d+/(.*)" "/latest/$1" |
Regex rewrite. |
script |
script r#" /* inline TS or JS source */ "# shared=true max-body-bytes=1048576 |
Requires scripting feature. The positional arg is the source; use a raw string for multiline content. |
script-file |
script-file "middleware.ts" shared=true max-body-bytes=1048576 |
Requires scripting feature. Loads the script from disk; TS is transpiled. |
Scripting Middleware
Write request/response manipulation logic in TypeScript or JavaScript. Scripts run in an embedded V8 engine via deno_core. Requires the scripting feature.
use Proxy;
use ScriptLayer;
let proxy = builder
.ca_pem_files?
.layer
.build;
In KDL configs you can either point at a file or inline the source as a raw string. The inline script form is convenient for short scripts, demos, and tests; script-file is the right choice once a script grows past a handful of lines.
forward port=8080 {
ca cert="ca.pem" key="ca-key.pem"
// Short script inline
script r#"
export default async function(req, respond) {
req.headers.set("x-injected", "yes");
return await respond(req);
}
"#
// Or load from a file (TS is transpiled automatically)
// script-file "middleware.ts" shared=true
}
The script exports a default async function that receives the request and a respond function to forward it upstream:
// middleware.ts
export default async function(req: Request, respond: Function) {
// Add a header before forwarding
req.headers.set("x-proxy", "noxy");
// Forward to upstream
const res = await respond(req);
// Modify the response
res.headers.set("x-intercepted", "true");
return res;
}
Short-circuit responses without forwarding upstream:
export default async function(req: Request, respond: Function) {
if (req.url === "/health") {
return new Response("ok", { status: 200 });
}
return await respond(req);
}
Read request or response bodies (lazy -- only buffered if you call body()):
export default async function(req: Request, respond: Function) {
const body = await req.body(); // Uint8Array
console.log("Request size:", body.length);
const res = await respond(req);
const resBody = await res.body(); // Uint8Array
return new Response(resBody, {
status: res.status,
headers: res.headers,
});
}
By default, each connection gets its own V8 isolate, so global state in the script (like variables declared outside the handler) is scoped per connection. Use .shared() to reuse a single isolate across all connections:
// Per-connection (default) -- each connection gets a fresh isolate
from_file?
// Shared -- one isolate for all connections, global state is shared
from_file?.shared
Limit script body buffering (applies to both req.body() and res.body()):
from_file?
.max_body_bytes
Redis Backend
Stateful middleware (rate limiting, sliding window, circuit breaker) keeps state in-memory by default. For horizontal scaling across multiple proxy instances, enable the redis feature to share state via Redis.
KDL config
redis url="redis://localhost:6379"
// redis url="redis://localhost:6379" prefix="noxy:"
reverse port=8080 {
upstream "http://api:3000"
rate-limit count=100 window="1s"
circuit-breaker threshold=5 recovery="30s"
}
When redis is configured, all rate-limit, sliding-window, and circuit-breaker rules automatically use Redis. If Redis becomes unreachable, each store transparently falls back to an in-memory store and logs a warning.
Scoped Redis: per-listener and per-match overrides
redis declarations follow the same innermost-wins shadowing rule as middleware. A redis at the top level is the default; a listener block can override it; a match block can override that:
redis url="redis://main:6379" prefix="main:"
forward port=8080 {
ca cert="ca.pem" key="ca-key.pem"
// No redis here → uses main:
rate-limit count=100 window="1s"
}
reverse port=8081 {
upstream "http://api:3000"
// Override for this listener
redis url="redis://api:6379" prefix="api:"
rate-limit count=1000 window="1s"
host "premium.example.com" {
// Premium tier uses its own redis
redis url="redis://premium:6379" prefix="prem:"
rate-limit count=10000 window="1s"
}
}
The same (url, prefix) declared in multiple scopes opens one connection (deduped automatically), so cross-scope state stays consistent.
CLI
Library API
use Duration;
use Proxy;
use ;
let conn = open?;
let store = new; // rate=100/s, burst=100
let limiter = with_store; // global key
let proxy = builder
.reverse_proxy?
.layer
.build?;
All three stores follow the same pattern: RedisRateLimitStore, RedisSlidingWindowStore, and RedisCircuitBreakerStore each take a RedisConnection and embed an in-memory fallback internally.
How It Works
Noxy operates in two modes. Both feed traffic through the same tower middleware pipeline -- the difference is how connections are established.
Forward proxy (TLS MITM)
Normal HTTPS creates an encrypted tunnel between client and server -- nobody in the middle can read the traffic. Noxy breaks that tunnel into two separate TLS sessions and sits in between, with your middleware pipeline processing decoded HTTP traffic.
sequenceDiagram
participant C as Client
participant N as Noxy
participant S as Server
C->>N: CONNECT example.com:443
N-->>C: 200 OK
N->>S: TLS handshake (real cert verified)
S-->>N: TLS established
Note over N: Generate fake cert for<br/>example.com signed by CA
C->>N: TLS handshake (fake cert)
N-->>C: TLS established
rect rgb(40, 40, 40)
Note over C,S: TLS Session 1 ← Noxy → TLS Session 2
C->>N: GET / HTTP/1.1
Note over N: Tower middleware pipeline<br/>[Layer] → [Layer] → upstream
N->>S: Forwarded request
S-->>N: Response
Note over N: upstream → [Layer] → [Layer]
N-->>C: Modified response
end
-
HTTP CONNECT -- the client sends an unencrypted
CONNECT example.com:443request to the proxy. The proxy learns the target hostname from this plaintext request. -
Upstream TLS -- Noxy opens a real TLS connection to
example.com, verifying the server's authentic certificate against Mozilla's root CAs. -
Fake certificate generation -- Noxy generates a TLS certificate for
example.comsigned by the user-provided CA, created on the fly per host. -
Client TLS -- Noxy performs a TLS handshake with the client using the fake certificate. The client accepts it because it trusts the CA.
-
HTTP relay with middleware -- with both TLS sessions established, Hyper handles the HTTP connection on both sides. Each request from the client passes through your tower middleware pipeline before being forwarded upstream, and each response passes back through the pipeline before being sent to the client.
Reverse proxy
In reverse proxy mode, Noxy sits in front of a fixed upstream and forwards all incoming HTTP traffic directly. There is no CONNECT tunnel, no CA certificate, and no client-side proxy configuration -- clients talk to Noxy as if it were the real server.
sequenceDiagram
participant C as Client
participant N as Noxy
participant S as Upstream (fixed)
C->>N: GET /api/users HTTP/1.1
Note over N: Tower middleware pipeline<br/>[Layer] → [Layer] → upstream
N->>S: GET /api/users HTTP/1.1
S-->>N: 200 OK
Note over N: upstream → [Layer] → [Layer]
N-->>C: 200 OK (modified)
-
Direct HTTP -- the client sends a plain HTTP request to Noxy's address. No CONNECT, no proxy configuration, no certificate trust needed.
-
Middleware pipeline -- the request passes through the tower middleware stack (rate limiting, logging, header injection, etc.), exactly the same pipeline used in forward mode.
-
Upstream forwarding -- Noxy forwards the request to the configured upstream. The upstream can be HTTP or HTTPS -- Noxy handles TLS to the backend transparently.
-
Response relay -- the upstream response passes back through the middleware stack and is returned to the client.
Optionally, Noxy can serve HTTPS to clients using a TLS certificate you provide (--tls-cert / --tls-key). This is independent of the upstream scheme -- you can terminate TLS at Noxy while forwarding to a plain HTTP backend, or chain TLS end-to-end.
sequenceDiagram
participant C as Client
participant N as Noxy (TLS)
participant S as Upstream (HTTP)
C->>N: TLS handshake (your cert)
N-->>C: TLS established
C->>N: GET /api/users HTTP/1.1
Note over N: Middleware pipeline
N->>S: GET /api/users HTTP/1.1 (plain)
S-->>N: 200 OK
N-->>C: 200 OK (over TLS)
Use cases
Sidecar proxy -- put Noxy in front of a microservice to add rate limiting, circuit breaking, retry, and logging without modifying the service itself:
API gateway -- terminate TLS, route to multiple backends, and apply middleware:
// Multi-backend gateway via config file
reverse port=443 bind="127.0.0.1" {
upstream "http://web:3000"
tls cert="server.pem" key="server-key.pem"
path "/api/" {
upstream "http://api:8080"
rate-limit count=1000 window="60s"
}
path "/static/" {
upstream "http://cdn1:9000" "http://cdn2:9000" balance="round-robin"
}
}
Testing and development -- inject faults, latency, or fixed responses in front of a real API to test client resilience:
# Simulate a flaky upstream
// Surgical fault injection via config file
reverse port=8080 {
upstream "https://api.example.com"
log bodies=true
path "/api/checkout" {
fault error-rate=0.3 error-status=503
}
path "/api/search/" {
latency "500ms..2s"
}
path "/api/health" {
respond body="{\"status\": \"ok\"}"
}
}
License
MIT