Chisel

Last reviewed Aug 26, 2026 · 826 words

Two commands are the entire product:

chisel server -p 8080 --reverse --auth admin:a-long-random-secret
chisel client --auth admin:a-long-random-secret https://tunnel.example.com R:2222:localhost:22

After the second one, SSH on the machine that ran it is reachable at tunnel.example.com:2222, from behind a firewall that only permitted outbound HTTPS. That is Chisel in full: a roughly 10 MB static Go binary (MIT, 16,444 stars, happy in 64 MB of RAM) with no configuration file, no dashboard and no database. Everything else is a flag, which is why the documentation reads sparse and why people who want a GUI should pick a different tool.

How it passes through things that block everything else

The client opens an ordinary HTTP connection, upgrades it to a WebSocket, and runs the SSH protocol inside. To a corporate proxy or a hotel captive portal it is one long-lived web request, and because SSH provides the encryption and authentication, the outer transport does not need TLS to be safe. In practice you put Caddy in front anyway so the endpoint looks like a normal HTTPS site and gets a real certificate. The --backend flag lets the server hand non-Chisel requests to another web server, so tunnel.example.com can serve a decoy page while the WebSocket upgrade goes to Chisel. Multiple tunnels are multiplexed over the single connection, so adding remotes costs nothing on the network side.

Forward, reverse, SOCKS and UDP use one syntax

A remote is local-port:remote-host:remote-port. Written plainly, the client listens locally and the server end connects onward, which is a forward tunnel. Prefix it with R: and the roles flip: the server listens and traffic lands on the client's side, which is what you want for exposing a home service. The server must be started with --reverse for that to be allowed. The keyword socks instead of a port triple opens a SOCKS5 proxy on 1080 (--socks5 on the server enables it), so a laptop on a hostile network can route a browser through the VPS with chisel client https://tunnel.example.com socks. Append /udp to a remote and the same tunnel carries UDP, which is enough for a WireGuard handshake or a game server. None of it needs a restart to change; you run a new client with different remotes.

Lock it down before it is public

Three things turn the two-command demo into something safe to leave running. Use --authfile rather than --auth once you have more than one user; it takes a JSON map from user:password to a list of regular expressions over the remotes that user may open, so a backup job can be limited to one port and nothing else. Give the server a stable identity with --keygen and --keyfile on newer builds (older releases used a --key seed), then pin it on every client with --fingerprint, otherwise you have SSH with the host-key check switched off. And expose exactly one port, the one Caddy listens on. The server does not need anything else open, and a restart: unless-stopped container from the jpillora/chisel image on a small VPS is the whole deployment.

On the client side, wrap the command in a systemd unit with Restart=always. Chisel reconnects with backoff on its own (--max-retry-count and --max-retry-interval tune it), but a unit file survives reboots and gives you logs in one place.

When frp, rathole or Tailscale is the better answer

Chisel is the tool for ad-hoc and hostile situations: a network that allows only HTTP egress, a one-off port you need reachable tonight, a pentest box. For a permanent set of named services with virtual-host routing, a web dashboard and a config file you can commit, frp is more comfortable and better documented. rathole is the closest sibling, a single Rust binary with slightly lower overhead and a TOML config, and I would pick it over Chisel when the tunnel list is long and stable. For reaching your own machines day to day, Tailscale or Headscale gives you a mesh with no exposed port at all, and the three ways to remote access comparison lays out when each shape fits. Chisel wins only where those cannot get out, which is a real and recurring situation.

What I'd do

Run the server in Docker on a small VPS behind Caddy on 443, --authfile with one entry per client, --keyfile on the server and --fingerprint on every client, --reverse enabled and nothing else exposed. Keep it as the fallback path alongside Tailscale rather than the primary one, and treat the client command as something you can type from memory, because on the day you need Chisel you will be on a network that is stopping everything else.