How Long Can a CONNECT Tunnel Stay Open?
Separate an established tunnel's lifetime from HTTP response reuse, intermediary idle policies, and the destination application's own session.
CONNECT has no promise of an indefinitely open tunnel. After a successful exchange, the connection carries a continuing byte stream to the requested host and port. It can carry multiple exchanges within a destination TLS session for as long as the participants and network keep it open.
Two proxy limits behave differently: traffic may keep an idle timer from expiring, but it cannot extend an absolute lifetime limit. The destination protocol also has a say. An inner HTTP client may close its connection; a WebSocket application may end its session. The proxy cannot keep that destination session alive afterward.
A tunnel is tied to its target. Once tunnel bytes are flowing, the connection is no longer an ordinary HTTP request channel on which to issue another CONNECT for an unrelated destination. The client needs another connection or another tunnel managed by its library.
For a persistent feed, plan for reconnects using the client's supported liveness and connection mechanisms. If it closes after silence, an inactivity policy is a useful lead; if it closes at a fixed duration despite traffic, investigate an absolute limit instead. For a WebSocket feed, restore application state after reconnecting too.