HTTP tunnels

tnnl http <port> forwards a local HTTP port and gives you a public HTTPS URL. Routing is by hostname, so many HTTP tunnels share a single public port.

$ tnnl http 3000
  Tunnel ready:  https://flying-bird-4024.tnnl.uz

Getting a hostname

There are three ways to choose the public hostname for a tunnel:

Default — you get a friendly auto subdomain, for example flying-bird-4024.tnnl.uz.
A name you pick — pass --subdomain my-app (or -s my-app) to get my-app.tnnl.uz. A subdomain is a single DNS label: 1–63 characters of lowercase a–z, 0–9, and hyphens (not leading or trailing). It is rejected if the name is already in use.
Your own domain — pass --hostname example.com to serve the tunnel on a domain you control. See Custom domains.

$ tnnl http 3000 -s my-app
  Tunnel ready:  https://my-app.tnnl.uz

HTTPS is automatic

Subdomains under tnnl.uz are covered by a wildcard certificate, so a new subdomain is live over HTTPS instantly — there is nothing to provision. TLS is terminated at the edge: the CLI keeps your local service plain HTTP on 127.0.0.1:<port>, and the server handles the public TLS.

Routing and ports

Public traffic is routed by the HTTP Host header, which is why many HTTP tunnels can share one public port (443). WebSocket and other connection upgrades are supported and proxied transparently.

Watch traffic live

While a tunnel is running, the terminal shows a live request feed. Full request and response inspection is available in the dashboard when request logging is enabled for your account — see Request inspection.

Staying connected

If the tunnel drops, the CLI automatically reconnects with backoff. Press Ctrl-C to stop it.

Limits

Each tunnel counts toward your per-account limit. See Limits & permissions.