The problem
Your laptop has a server running on http://localhost:3000. You want a thing on the internet — a webhook from Stripe, an OAuth callback from Auth0, a stakeholder testing on their phone — to reach it.
The natural answer would be: open a port on your router, point a DNS record at your home IP, done. In practice that doesn't work for most people:
- Most home networks are NAT'd; the public IP is shared, you can't bind it.
- Mobile / café Wi-Fi has no inbound at all.
- ISP changes your IP whenever; dynamic DNS tries to chase it but lags.
- HTTPS requires a cert; certs require a public-DNS-resolvable name; etc.
A reverse tunnel sidesteps all of that.
How it works
The "reverse" is from the perspective of the server: instead of waiting for inbound connections (the normal direction), it dials outbound to a public relay. That outbound connection is what NAT and most firewalls allow by default.
┌──────── public ─────────┐
│ │
user's browser ──https──▶ relay.example.com │
│ │ │
│ │ long-lived │
│ │ TLS conn │
│ ▼ │
│ your laptop │
│ (agent dials out) │
└──────────────────────────┘
The relay accepts the inbound HTTP request, finds the right outbound tunnel (keyed by subdomain), ships the bytes through it. Your agent on the laptop reads the request from its end of the tunnel, makes a normal local HTTP call to localhost:3000, gets a response, sends it back the other way.
Multiplexing — many concurrent requests over the single agent connection — happens via a stream protocol like yamux. Without it you'd open a new TCP connection per request, which is slow and breaks under NAT.
Reverse tunnel vs port forwarding
| Port forward | Reverse tunnel | |
|---|---|---|
| Direction | Inbound | Outbound |
| Works behind NAT | No | Yes |
| Requires control of router | Yes | No |
| Public DNS / cert | Manual | Provided by service |
| Bandwidth path | Direct | Through relay |
Port forwarding wins on raw throughput (no relay hop). Reverse tunnels win on practicality (works from a coffee shop).
Reverse tunnel vs ssh -R
ssh -R is a reverse tunnel — you hold a long-lived SSH connection out to a public-IP server and it forwards connections back to your localhost. Same shape, different transport. Tradeoffs:
- ssh -R needs you to operate the public-IP server.
- ssh -R doesn't terminate TLS for you; you handle certs yourself.
- ssh -R has no inspector / dashboard / replay.
Hosted reverse-tunnel services (lrok, ngrok, Cloudflare Tunnel) take care of these for you. The price is a bit of latency at the relay (lrok adds ~30-50ms in the EU region; ~100-180ms US-East-to-Helsinki) and you trust the relay operator with your traffic.
Use cases
- Webhook testing — Stripe / GitHub / Twilio webhook delivery during dev.
- OAuth callbacks — local dev with Apple / Google IDPs that require https.
- Mobile-app backends — testing a real device against your laptop.
- Stakeholder previews — design / PM review without deploying.
- Database access — TCP tunnel for a colleague to psql against your laptop's Postgres.
Try it
$ curl -fsSL https://lrok.io/install.sh | sh
$ lrok login
$ lrok http 3000
Forwarding https://violet-mole.lrok.io → http://127.0.0.1:3000