Streaming & WebSockets

WebSockets, Server-Sent Events, and long-lived streaming bodies pass through end to end with no timeout.

osmRouter passes streaming responses through end to end. WebSockets, Server-Sent Events, and chunked/streaming bodies all work, with no wall-clock timeout on the request. A stream ends only when the visitor cancels or the upstream closes it.

This is what makes osmRouter suitable for streaming LLM output, live dashboards, collaborative editing, and other long-lived connections — not just short request/response.

Why it works

The edge forwards responses with flushing enabled, so bytes are written to the visitor as soon as your service emits them rather than being buffered until the body is complete. There is no proxy-level read timeout that would cut a quiet but healthy stream.

WebSockets

WebSocket upgrades are forwarded transparently. Point a client at the public hostname exactly as you would at localhost:

const ws = new WebSocket("wss://my-app.osmrouter.com/socket");
ws.onmessage = (e) => console.log(e.data);

Server-Sent Events

SSE streams flow through unbuffered. A typical receiver:

const es = new EventSource("https://my-app.osmrouter.com/events");
es.onmessage = (e) => console.log(e.data);

Streaming LLM responses

The classic case is an OpenAI-compatible server (Ollama, vLLM, llama-server) with "stream": true behind the tunnel. Tokens stream to the caller as they're generated:

curl -N https://llm.osmrouter.com/v1/chat/completions \
  -d '{"model":"...","messages":[...],"stream":true}'

If a streaming client appears to "hang", the tunnel is almost always fine — a non-streaming client is calling a streaming upstream and buffering the whole body before returning. With curl, add -N (--no-buffer) to print chunks as they arrive. In an SDK, use the streaming API (an async iterator / event handler) rather than awaiting .text() / .json().

Confirming a stream is healthy

Open the Traffic Inspector. A long-running streaming request shows up as in-flight with a steadily climbing latency — that's the stream working, not a stall. The request only ends when the visitor cancels or the upstream closes it.

Next steps

HTTP tunnels — how requests route through the edge.
Troubleshooting — when a stream really is stuck.