A fast forward proxy written in Rust

HTTP/1.1, HTTPS, HTTP/2, WebSocket and SOCKS5 in one binary. One event loop per core: ~55k requests per second on one core, ~440k on eight, against ~21k (3proxy) and ~117k (Squid) for the best competitor in each case.

curl -fsSL https://raw.githubusercontent.com/EdouardCourty/rustle/main/install.sh | sh

See the benchmarks Source on GitHub

Benchmarked on Scaleway Elastic Metal servers, authentication on: 1 core per proxy, and up to 8 cores for plain HTTP. See the full benchmark data

2.6×
requests per second at 1 KB
~55k req/s on one core, against ~21k for 3proxy, the next best.
See the chart
95 MB
for 25,000 open tunnels
Tinyproxy, the next lowest, needs ~274 MB; the others 0.9 to 3.2 GB.
See the chart
3.6×
new connections per second
~28k requests per second when every request opens a new connection, against ~7.8k for Squid, the next best.
See the table

Benchmarked on Scaleway Elastic Metal servers, authentication on: 1 core per proxy, and up to 8 cores for plain HTTP. See the full benchmark data

Benchmarks

rustle against 3proxy, Squid, gost and Tinyproxy

Each competitor ran with the tuning its own documentation recommends, at the connection count where it performs best.

Small requests, 1 core: 1 KB responses

req/s, higher is better.

rustle55k
3proxy21k
Squid15k
Tinyproxy7.6k
gost4.8k

1 KB responses, keep-alive. Plain HTTP proxy port.

Data table

Small requests, 1 core: 1 KB responses: req/s, measured values by proxy
Proxy	Version	req/s	Connections
rustle	1.0.0	55,258	64
3proxy	1.0.0	21,032	256
Squid	7.7	15,140	64
Tinyproxy	1.11.3	7,580	64
gost	3.3.0	4,755	64

1 core per proxy · authentication on · Scaleway Elastic Metal, Paris, AMD EPYC 8224P · 25 Gbit/s private network (23.5 measured) · median of 3 runs · seed 2004113323 · campaign of 2026-10-28.

Memory with 25,000 open tunnels, 1 core

MB, lower is better.

rustle95
Tinyproxy274
Squid912
3proxy2.5k
gost3.2k

25,000 idle CONNECT tunnels held open, peak RSS of the proxy. Plain HTTP proxy port.

Data table

Memory with 25,000 open tunnels, 1 core: MB, measured values by proxy
Proxy	Version	MB	Connections
rustle	1.0.0	95	n/a
Tinyproxy	1.11.3	274	n/a
Squid	7.7	912	n/a
3proxy	1.0.0	2,461	n/a
gost	3.3.0	3,228	n/a

1 core per proxy · authentication on · Scaleway Elastic Metal, Paris, AMD EPYC 8224P · 25 Gbit/s private network (23.5 measured) · median of 3 runs · seed 2004113323 · campaign of 2026-10-28.

Benchmark results of rustle and four other proxies, one core unless stated, authentication on
1 core unless stated, auth on	rustle	3proxy	Squid	gost	Tinyproxy
1 KB responses, req/s	55k	21k	15k	4.8k	7.6k
1 KB responses, 8 cores, req/s	440k	115k	117k	31k	—
1 KB, new connection per request, req/s	28k	5.1k	7.8k	4.8k	7.6k
1 MB responses, req/s	2.6k	1.8k	353	1k	199
CONNECT tunnels, Gbit/s	22	16	14	13	1.8
RAM with 25,000 open tunnels, MB	95	2.5k	912	3.2k	274
HTTPS proxy, 1 KB, req/s	49k	—	14k	2.5k	—
HTTP/2 proxy, 1 KB, req/s	33k	—	—	5.2k	—
WebSocket, 64 B messages, msg/s	59k	33k	44k	47k	—

Benchmarked on Scaleway Elastic Metal servers, authentication on: 1 core per proxy, and up to 8 cores for plain HTTP. Best value of each row in bold; “—” means not supported or not measured. See the full benchmark data

How it is built

One core, one lane. Nothing shared.

Each core runs its own event loop, its own listener and its own connection pool. A connection never leaves its core: no locks on the hot path, no work stealing, no cross-core wakeups.

1 core: ~55k; req/s
8 cores: ~440k; req/s
Scaling: ~8×; plain HTTP, 1 KB

See the multi-core results

Under the hood

Three layers, one idea: never share.

From the design down to the kernel, every level is built so that a connection stays on one core.

01 Design02 Runtime03 Kernel

Shared-nothing shards

One core is one shard: a thread that owns its listener, its connection pool and its buffers. A connection is accepted, served and closed on the same core. The only shared state is cold: the configuration, the keys, the DNS cache and a few atomic counters. So there is no lock on the hot path.

~8×the throughput on 8 cores against 1, plain HTTP at 1 KB

One Tokio runtime per core

Each shard runs its own single-threaded Tokio runtime: no work stealing, no cross-core wakeup. Request heads are parsed in place, as spans into the read buffer, and scratch buffers live as long as the connection, so the hot path does not allocate.

~18 µsof CPU per 1 KB request, against ~48 µs for 3proxy

Let the kernel do the heavy lifting

The kernel spreads new connections across the cores. On Linux, it also moves the bytes of tunnels and large transfers straight from one socket to the other, so the proxy never copies them: less copying, less CPU. TLS and HTTP/2 cannot take this shortcut, so their throughput is lower.

~28k connections/son one core when every request opens a new connection, against ~7.8k for Squid.

Safe by default

A proxy that refuses what it should refuse.

The defaults are the safe ones. Anything that opens the proxy up is a line you write in the config.

API key authentication
Several keys can be configured; the comparison is constant-time over all of them.
Client allowlist
IPs and CIDRs outside the list are closed at accept, before any read.
Bans
An address is banned after 5 wrong keys in 1 minute (the defaults), for 15 minutes.
Private destinations refused
Loopback, private and internal address ranges are blocked by default. The check is made on the address a name resolves to, so a name that points inside your network is refused too.
Allowed ports
Restrict the destination ports, for example 80 and 443 only.
Hostile clients
Clients that send their request very slowly are cut off, and malformed requests meant to smuggle a second request are rejected.

With api_keys empty, the proxy is an open relay. On the plain port and on SOCKS5, the key travels in clear text: expose them only on a trusted interface (loopback, VPN) and use the HTTPS port over the Internet. Read the security guide

Configuration

One TOML file, ten lines to start

An unknown or misplaced key fails the startup. Reload it without restarting, rustle reload, and the file is validated first.

[server]
listen  = "127.0.0.1:8080"
workers = 0                       # one worker per CPU core

[auth]
api_keys = ["<openssl rand -base64 32>"]

[tls]                             # HTTPS to the proxy, also speaks HTTP/2
listen = "0.0.0.0:8443"
cert   = "/etc/rustle/fullchain.pem"
key    = "/etc/rustle/privkey.pem"

[socks5]
listen = "127.0.0.1:1080"

Every section and its defaults are in the configuration reference.

Get started

Installed in one command, without sudo

The installer detects your system, verifies the release SHA-256 and installs rustle into ~/.local/bin.

curl -fsSL https://raw.githubusercontent.com/EdouardCourty/rustle/main/install.sh | sh

rustle initwrite a config with a fresh API key (~/.config/rustle/config.toml)
rustle runrun in the foreground
rustle service enableor install it as a systemd user unit / launchd agent

Pin a version with RUSTLE_VERSION=v1.0.0. Release archives carry a GitHub build provenance attestation:

gh attestation verify rustle-<target>.tar.gz --repo EdouardCourty/rustle

Platforms

Linux (x86_64, aarch64), glibc ≥ 2.35: the reference platform, with every fast path (splice, kernel TLS, core pinning).
macOS (Apple Silicon, Intel): fully functional, without the Linux-only fast paths.

From source: cargo build --release -p rustle. MIT licensed, source on GitHub.

A fast forward proxy written in Rust

Headline benchmark figures

requests per second at 1 KB

for 25,000 open tunnels

new connections per second

Small requests, 1 core: 1 KB responses

Memory with 25,000 open tunnels, 1 core

All the results side by side

Shared-nothing shards

One Tokio runtime per core

Let the kernel do the heavy lifting

API key authentication

Client allowlist

Bans

Private destinations refused

Allowed ports

Hostile clients

Platforms