Skip to content

Live-tail/SSE shows nothing behind your own proxy

Live-tail under Logs — and any other place that updates live via Server-Sent Events (SSE), such as the streamed answer of the AI chat — stays empty, or only updates in a burst every few minutes instead of continuously. This symptom appears almost exclusively when you run your own reverse proxy in front of Vesana (see TLS / Reverse Proxy) — directly against the Vesana stack without an additional proxy, SSE works without any extra configuration.

Check first: do logs arrive at all?

Before suspecting the proxy:

  • The first lines take up to 30 seconds. Agents send logs in batches every 30 seconds; as soon as someone opens a device's live view, the agent switches to a 5-second interval.
  • Is there a log source? Without a configured log source on the device nothing arrives. journald sources may only send from a minimum level onwards (new sources from warning).
  • Permission hosts.view: live-tail, log search and log statistics require it for the device.

If the normal log search shows new lines but live-tail does not, the proxy is the cause.

Cause: response buffering

SSE keeps an HTTP connection open and sends individual events as they occur. A reverse proxy buffers responses by default until a buffer fills up or the connection ends — for a stream that stays open for a long time and only occasionally sends a few bytes, that means the client sees nothing until the proxy eventually flushes the buffer (or never does).

Vesana sends the header X-Accel-Buffering: no with its stream responses. nginx honours it by default and turns buffering off for that response on its own — as long as nothing in your configuration ignores it (proxy_ignore_headers X-Accel-Buffering). It is safer to switch buffering off explicitly for the stream paths:

location = /api/v1/logs/stream {
    proxy_pass https://<vesana-stack>;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 3600s;
}

<vesana-stack> is the address under which your proxy reaches the Vesana stack. The same applies to the stream paths of the AI chat and AI analysis (/api/v1/ai/chat/stream, /api/v1/ai/analyze/…/stream).

With Traefik this matches the default (no response buffering for normal proxy requests) — usually a sufficiently high timeout is enough. With HAProxy: do NOT set option http-buffer-request, and choose a generous timeout server. With Caddy, SSE is usually unproblematic without extra directives.

Two nginx layers

If your own nginx (or Caddy/Traefik) sits in front of the Vesana stack, there are two proxy layers between browser and backend: your proxy in front and the nginx inside the Vesana stack behind it. Both must pass the stream through unbuffered.

  1. Your own reverse proxy — buffering off for the stream paths (see above), timeout high enough.
  2. The internal nginx in the stack — already has the stream paths configured unbuffered. Only if you applied your own changes there, check whether buffering was accidentally re-enabled.

Diagnosis: is it really the proxy?

On the server itself, bypassing your proxy and going directly against the Vesana stack (port according to your installation, default 443; -k because the stack certificate is often self-signed):

curl -N -k -H "Authorization: Bearer <JWT>" \
  "https://127.0.0.1:443/api/v1/logs/stream?host_ids=<host-id>"

If data: lines keep arriving here but not via the public domain name, the cause is the reverse proxy, not Vesana itself. -N (--no-buffer) matters here, otherwise curl itself buffers.

The splash during an update (see UI issues after update) polls via normal HTTP requests, not SSE — buffering doesn't affect it. If it still hangs, that's a different cause.

Checklist

  • [ ] Log source configured, normal log search shows new lines?
  • [ ] Waited up to 30 seconds for the first lines?
  • [ ] Buffering off on every proxy layer between browser and Vesana for the stream paths?
  • [ ] proxy_read_timeout high enough (stream stays open for a long time)?
  • [ ] Direct curl -N test against the stack shows events arriving?

Next