How it works

visitor ──https──▶ menfez edge ◀──wss── menfez CLI ──http──▶ localhost:3000
         abc.menfez.cloud        connect.menfez.dev

1. menfez http 3000 opens a single WebSocket to connect.menfez.dev, authenticates with your token and asks for a tunnel. The edge answers with a hostname under menfez.cloud.
2. When a visitor opens that hostname, the edge opens a new stream inside your WebSocket connection and sends the request through it.
3. The CLI connects to your local port and pipes the bytes both ways. Responses stream back as they are produced; nothing is buffered, so server-sent events, long polling, uploads and WebSockets work.

All traffic from your machine goes out over HTTPS port 443, so it passes most firewalls and proxies. Nothing on your machine listens for incoming connections.

Reconnects

Networks drop. When the connection breaks:

• the edge keeps your hostname for 30 seconds; visitors get a tunnel_reconnecting page with Retry-After: 5;
• the CLI reconnects with backoff (1 s, doubling up to 30 s) and presents a signed ticket for each tunnel, so it gets the same URL back. This also works after the edge restarts.

What your service sees

The request arrives as HTTP/1.1, with these headers set by the edge:

Header	Value
Host	the public hostname, or the local address with --host-header rewrite
X-Forwarded-For	the visitor’s IP address
X-Forwarded-Host	the public hostname
X-Forwarded-Proto	https

Hop-by-hop headers (Connection, Keep-Alive, TE, …) are removed, except the ones a WebSocket upgrade needs.

Errors from the edge

When the edge, not your service, answers a request, the response carries a menfez-error header with a stable error code. Browsers get an HTML page, other clients plain text.