Summary
Reintroduce warm-connection pooling to reduce backend connection latency for new client connections.
Background
The previous implementation maintained a pre-established TCP connection (“warm connection”) to the backend to avoid connection setup delay on the first incoming client.
During the hostname-based routing + whitelist refactor, this logic was removed to simplify the architecture.
The proxy now creates a fresh backend connection for every client, which is correct but adds handshake latency.
Proposed Direction
- Maintain 1 warm connection per configured backend
- When a client needs a backend connection:
- Serve the warm connection
- Immediately recreate it in the background
Potential future improvements:
- Configurable pool size (perhaps per-backend)
- Enable/disable via config
Notes
This is purely a performance optimization.
Current behavior is correct and safe.
Pooling must not weaken whitelist guarantees or introduce open-proxy behavior,
Summary
Reintroduce warm-connection pooling to reduce backend connection latency for new client connections.
Background
The previous implementation maintained a pre-established TCP connection (“warm connection”) to the backend to avoid connection setup delay on the first incoming client.
During the hostname-based routing + whitelist refactor, this logic was removed to simplify the architecture.
The proxy now creates a fresh backend connection for every client, which is correct but adds handshake latency.
Proposed Direction
Potential future improvements:
Notes
This is purely a performance optimization.
Current behavior is correct and safe.
Pooling must not weaken whitelist guarantees or introduce open-proxy behavior,