pht hang

Thanks for the report — fixed in 3b3eaa6.

Root cause. The /pull endpoint streams tunnel data as base64 chunks and flushes after each one. With proxy_buffering on (Nginx's default), Nginx buffers these small chunks (and the keep-alive heartbeats) instead of forwarding them, so active data transfer hangs until the buffer fills or the upstream closes. Idle heartbeats still got through — they arrive on response close — which is why only data transfer stalled.

Fix. The pull response now sets X-Accel-Buffering: no, which makes Nginx disable buffering for that response and forward each flushed chunk immediately. This keeps the existing streaming model (no extra round-trips, no added load under high throughput) and works with the default Nginx config, so you no longer need proxy_buffering off for the pht endpoints. Nginx consumes the header (it is not forwarded to the client) and it is inert when no proxy sits in front of the listener.

On the suggested approaches:

• SSE would not have helped here — it is the same class of open-ended streaming response and is subject to the same buffering.
• Socket.IO-style polling would avoid it, but at the cost of a new HTTP request per data round-trip, adding server load proportional to throughput.

The fix covers pht, phts, and h3 (shared handler).

Originally posted by @ginuerzh in #721 I think the best option is to support fallback mechanisms — polling, pulling, and connection close handling — similar to Socket.IO, so it works reliably across any network.