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
- 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. - Built-in middleware -- traffic logging, header modification, block list, latency injection, bandwidth throttling, fault injection, rate limiting, sliding window rate limiting, retry with exponential backoff, circuit breaker, mock responses, and TypeScript scripting
- Conditional rules -- apply middleware only to requests matching a host or path (supports glob patterns:
*,**,?,[a-z]) - TOML config file -- configure the proxy and middleware rules declaratively
- 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 Proxy;
let proxy = builder
.ca_pem_files?
.http_layer
.build?;
proxy.listen.await?;
Reverse proxy
use Proxy;
let proxy = builder
.reverse_proxy?
.http_layer
.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.
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
# 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 listen 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
Config File
For conditional rules and more complex setups, use a TOML config file.
CLI flags override config file settings for global options (listen address, CA paths, etc.) and append additional unconditional rules.
Reverse proxy config
= "127.0.0.1:8080"
= "http://localhost:3000"
# Optional: serve HTTPS to clients
# [tls]
# cert = "server.pem"
# key = "server-key.pem"
[[]]
= true
[[]]
= { = 100, = "1s" }
Forward proxy config
= "127.0.0.1:8080"
[]
= "ca-cert.pem"
= "ca-key.pem"
# accept_invalid_upstream_certs = true
# pool_max_idle_per_host = 8
# pool_idle_timeout = "90s"
# Log all traffic
[[]]
= true
# Log with request/response bodies
# [[rules]]
# log = { bodies = true }
# Add 200ms latency to API requests
[[]]
= { = "/api" }
= "200ms"
# Simulate slow downloads with random latency and bandwidth limit
[[]]
= { = "/downloads" }
= "50ms..200ms"
= 10240
# Inject faults on a specific endpoint
[[]]
= { = "/flaky" }
= { = 0.5, = 0.02 }
# Mock a health check endpoint
[[]]
= { = "/health" }
= { = "ok" }
# Rate limit: 30 requests per second globally
[[]]
= { = 30, = "1s" }
# Rate limit: 1500 requests per minute, per host, with burst of 100
[[]]
= { = 1500, = "60s", = 100, = true }
# Sliding window: hard-cap 10 requests per second (no burst, no smoothing)
[[]]
= { = 10, = "1s" }
# Sliding window: per-host, 500 requests per minute
[[]]
= { = 500, = "60s", = true }
# Retry failed requests (429, 502, 503, 504) up to 3 times
[[]]
= { = 3, = "1s" }
# Retry only 503s with custom statuses
[[]]
= { = "/api" }
= { = 5, = "500ms", = [503] }
# Circuit breaker: trip after 5 consecutive 5xx failures, recover after 30s
[[]]
= { = 5, = "30s" }
# Per-host circuit breaker with 2 half-open probes
[[]]
= { = 3, = "10s", = 2, = true }
# Add a request header and strip a response header
[[]]
= { = { = "noxy" } }
= { = ["server"] }
# Add API version header to /api requests
[[]]
= { = "/api" }
= { = { = "2" } }
# Block requests to tracking domains and admin paths
[[]]
= { = ["*.tracking.com", "ads.example.com"], = ["/admin/*"] }
# Block with custom status and body
[[]]
= { = ["internal.corp.com"], = 404, = "not found" }
# Return 503 for all paths under /fail
[[]]
= { = "/fail" }
= { = 503, = "service unavailable" }
# Glob patterns in match conditions
# Match any subdomain of example.com
[[]]
= { = "*.example.com" }
= "100ms"
# Match any single-segment path under /api/
[[]]
= { = "/api/*/users" }
= { = 10, = "1s" }
# Match all paths recursively under /static/
[[]]
= { = "/static/**" }
= { = { = "public, max-age=86400" } }
Rules
Each rule has an optional match condition and one or more middleware configs. Rules without a match apply to all requests.
| Field | Description |
|---|---|
match |
{ host = "*.example.com", path = "/api/*/users" } or { path_prefix = "/prefix" } — host and path support glob patterns (*, **, ?, [a-z]) |
block |
{ hosts = ["*.tracking.com"], paths = ["/admin/*"] } -- optional status and body fields (default: 403 empty) |
log |
true or { bodies = true } |
latency |
"200ms", "1s", or "100ms..500ms" for random range |
bandwidth |
Bytes per second throughput limit |
fault |
{ error_rate = 0.5, abort_rate = 0.02, error_status = 503 } |
rate_limit |
{ count = 30, window = "1s" } -- optional burst and per_host fields |
sliding_window |
{ count = 10, window = "1s" } -- hard-cap with no burst; optional per_host |
retry |
{ max_retries = 3, backoff = "1s" } -- retry on 429/502/503/504; optional statuses to override |
circuit_breaker |
{ threshold = 5, recovery = "30s" } -- trips after consecutive 5xx failures; optional half_open_probes and per_host |
request_headers |
{ set = { "name" = "value" }, append = { "name" = "value" }, remove = ["name"] } -- modify request headers |
response_headers |
{ set = { "name" = "value" }, append = { "name" = "value" }, remove = ["name"] } -- modify response headers |
respond |
{ body = "ok", status = 200 } -- returns a fixed response without forwarding upstream |
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?
.http_layer
.build;
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
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 listen 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 and apply middleware before routing to a backend:
Testing and development -- inject faults, latency, or mock responses in front of a real API to test client resilience:
# Simulate a flaky upstream
# Surgical fault injection via config file
= "127.0.0.1:8080"
= "https://api.example.com"
[[]]
= { = true }
[[]]
= { = "/api/checkout" }
= { = 0.3, = 503 }
[[]]
= { = "/api/search" }
= "500ms..2s"
[[]]
= { = "/api/health" }
= { = '{"status": "ok"}' }
License
MIT