Tunnel types

Router.direct tunnels HTTP, TCP, and UDP traffic. Each tunnel is identified by an API key (sk_live_…) that the relay validates against Redis on every connection.

HTTP tunnels

An HTTP tunnel gives you a public URL: https://<subdomain>.router.direct. Nginx terminates TLS at the wildcard edge and forwards the request to the relay, which matches the Host header to your tunnel and streams it to your local web server.

router run --server 77.42.121.237:2333 --token sk_live_... --subdomain myapp --local 127.0.0.1:3000
# → https://myapp.router.direct

Subdomain rules:

• 1–63 characters; lowercase letters, digits, and hyphens; no leading or trailing hyphen.
• Reserved names are rejected: dashboard, api, www, admin, status, docs, and others.
• Subdomains are unique across all users.

TCP tunnels

A TCP tunnel reserves a dedicated public port on the relay in the 10000–20000 range. The port is assigned automatically when you create the tunnel in the dashboard, and any inbound connection is piped straight to your local address — no protocol awareness, so SSH, databases, VNC, and game protocols all work.

router run --server 77.42.121.237:2333 --token sk_live_... --tcp-port 14090 --local 127.0.0.1:22
# → ssh -p 14090 user@77.42.121.237

UDP tunnels

UDP tunnels reserve a public UDP port and relay datagrams to your local UDP socket. Each remote peer gets its own local socket, so connection-oriented UDP protocols like WireGuard work correctly.

router run --server 77.42.121.237:2333 --token sk_live_... --udp-port 51820 --local 127.0.0.1:51820

Lifecycle & security

• Creation — the dashboard writes the tunnel to PostgreSQL and mirrors {id, type, subdomain, tcpPort, userId} into Redis under tunnel_key:<apiKey>.
• Authentication — the relay reads the key from Redis on the control connection and enforces a rate limit (10 failed attempts per 5 minutes per IP).
• Data channels — every incoming connection is handled on a second TLS connection that must originate from the same IP as the control connection, preventing request-ID hijacking.
• Revocation — deleting a tunnel in the dashboard removes the Redis key first, so the relay stops accepting it immediately, then removes the record from PostgreSQL.
• Encryption — the control and data channels between your machine and the relay are TLS; public HTTP traffic is TLS at the edge. UDP payloads travel inside the TLS data channel.

Persistence & reconnection

Every tunnel keeps itself alive automatically:

• Exponential backoff — after a disconnect the client retries at 2, 4, 8… seconds, capped at 60s, and resets the backoff after a clean session.
• Watchdog — if no bytes (not even heartbeats) arrive from the relay for 40 seconds, the client treats the link as dead and reconnects.
• Heartbeats — the relay pings every 30 seconds and expects a pong within 45 seconds.
• Service supervision — with router install, the OS service manager (systemd, launchd, or a Windows scheduled task) additionally restarts the client if the process itself dies, and starts it again after reboots.

Multiple tunnels

Create additional tunnels in the dashboard and install each one under its own service name:

router install --server 77.42.121.237:2333 --token sk_live_AAA... --subdomain app --service-name app
router install --server 77.42.121.237:2333 --token sk_live_BBB... --tcp-port 15000 --local 127.0.0.1:22 --service-name ssh

There is no per-tunnel fee — create as many as you need.

See CLI reference for every command and Quickstart for a step-by-step walkthrough.