HTTP and HTTPS tunnels

Expose a web service running on a device through a secure tunnel. This page focuses on HTTP and HTTPS protocols and the extra options that adjust how traffic is proxied.

Create a tunnel

1. Open Infrastructure → Tunnels.
2. Start Create tunnel and give the tunnel a clear name and optional description.
3. Choose HTTP or HTTPS as the protocol.
4. Select the device that runs the service.
5. Pick the organization context for the tunnel when more than one is valid for that device.
6. Set Remote host to where the service listens (often localhost for a service on the device itself, or a LAN address to reach another machine on the same network).
7. Set Remote port to the service port (for example 80, 8080, or 443).
8. Use additional port mappings when you need multiple incoming ports mapped to different targets on the device.
9. Save the tunnel.

Edit a tunnel

You can reconfigure an existing tunnel in place from the tunnel list or the device detail page. The edit form distinguishes two kinds of changes:

• Metadata edits — name, description, organization, and expiration. Applied instantly and do not disrupt in-flight traffic.
• Data-plane edits — protocol, remote host and ports, additional port mappings, host rewrite / target host, WebSocket redirect, LAN URL rewriting, and legacy device compatibility. Because these fields are baked into the proxy at creation time, saving them closes the existing listeners and rebuilds them. The form surfaces a warning on the exact fields that will churn so you can time the change during a maintenance window.

The device itself is immutable — to move a tunnel to another device, delete and recreate it.

Data-plane edits require the higher-privilege tunnels:create permission in addition to tunnels:update; if your role has only tunnels:update, the form will let you change metadata but the server will refuse data-plane changes.

Options for HTTP(S) traffic

These options appear on the tunnel form for HTTP and HTTPS. Use them when the default proxy behavior is not enough.

Host rewrite

• Enable host rewriting when the application expects a specific hostname in the request.
• When enabled, set Target host to the hostname the application should see (for example the public site name).

WebSocket redirect

• Enable WebSocket redirect when the app uses WebSockets and connections must be upgraded correctly through the proxy.
• This option is disabled automatically when LAN URL rewriting is on (see below), because LAN rewrite covers a broader set of cases.

LAN URL rewriting

• Enable LAN URL rewriting when pages served through the tunnel contain links or scripts that point to private LAN IPs (for example 192.168.x.x) and those references should be rewritten to flow through the tunnel.
• Useful when the device serves HTML or assets that reference other hosts on the same network.
• When LAN rewrite is on, it takes precedence over WebSocket redirect alone.

Legacy device compatibility

• Enable Legacy device compatibility for older embedded devices that crash TCP connections (sending RST instead of FIN) after transmitting a full HTTP body without a Content-Length header.
• This option buffers the response in memory (up to 2 MiB) to prevent "Connection Reset" errors in the browser.
• Do not enable this for streaming endpoints (like SSE or MJPEG), as their continuous responses would be buffered until the limit is reached.

Good practices

• Name tunnels by environment and purpose (prod-api, staging-ui).
• Set an expiration on tunnels that are meant to be temporary.
• After changes, verify in the browser that the full page load, APIs, and WebSockets behave as expected.