Problem

The proxy was building up CPU and memory usage over time due to goroutine leaks in CONNECT connection handling. Three specific leaks were identified:

1. streamRequestToTarget (line 684): Spawned goroutine for request body copying that never synchronized or cleaned up properly
2. handleConnectStreaming (line 733): Spawned goroutine for bidirectional tunnel copy that could hang indefinitely
3. Both functions had no synchronization between their bidirectional copy goroutines

Solution

• Use errgroup for proper goroutine lifecycle management and synchronization
• Close write side of connections after copy completes to properly signal EOF
• Add context monitoring to force cleanup when one goroutine completes
• Improved error handling to ignore expected EOF/ErrClosed errors (reduced log noise)

The errgroup ensures that:

• All spawned goroutines are tracked and waited on before the function returns
• When one direction closes (e.g., client disconnects), the context is canceled
• The cleanup goroutine forces both connections closed, unblocking any hanging io.Copy
• No goroutines are left running after the connection handling completes

Testing

✅ All existing tests pass
✅ Code compiles without errors

Changes

• Addedgolang.org/x/sync/errgroup dependency
• ModifiedstreamRequestToTarget to use errgroup with 3 goroutines (request copy, response copy, cleanup monitor)
• ModifiedhandleConnectStreaming to use errgroup with 3 goroutines (client→target, target→client, cleanup monitor)
• Both functions now properly clean up all goroutines before returning
• Connections can remain open indefinitely for long-lived use cases