Tunnels into internal networks

Reach services on a private network (a plant, a data center, a Kubernetes cluster) without a VPN. Add tunnels in Settings → Tunnels:

• SSH jump host: HttpDash runs your system's ssh with dynamic port forwarding (ssh -D), so your keys, ssh-agent, ~/.ssh/config and known hosts work as they do in a terminal. Optional: user, port, key file, and other jump hosts to go through first (ssh -J). It opens on first use and stays open; if it drops, the next request opens it again. ssh runs in batch mode, so it never waits for a password: use a key. A new host key is refused unless you tick Accept a new host key the first time, and a changed one is always refused.
• SOCKS5 proxy: any SOCKS5 server, with an optional user name and password.

Each tunnel carries the hosts you list, one per line: names with * wildcards (*.mes.corp) or address ranges (10.42.0.0/16). An environment can instead send all its requests through one tunnel (Tunnel under its color), or through none. Host names are resolved on the far side, so internal DNS names work.

Everything goes through the tunnel (except gRPC requests, for now): Send, the Runner, Monitors, Compare, health reads, WebSockets, and the app's own calls such as service discovery syncs, OAuth sign-ins and imports from a URL. A Consul server inside a plant is reached the same way as its services. The Timeline shows the time the tunnel took and notes that the address and route are on the far side, and the status bar shows while a tunnel is open (red if it failed). Open / Check opens a tunnel and can try a host:port through it.

The CLI uses the tunnels saved in a workspace.json from HttpDash's data folder (with the environment's choice; HttpDash backups don't include tunnels), or --socks5 host:port for every request, for example through an ssh -D started by your CI job. --no-tunnels ignores the saved ones.