A successful HTTP/1.1 CONNECT response ends after its header section:

HTTP/1.1 200 Connection Established

After that boundary, the same connection carries the tunnel. For an HTTPS destination, the next client bytes normally start its TLS exchange with the destination.

The proxy must not add Transfer-Encoding or Content-Length to a successful CONNECT response. There is no HTTP response body to chunk. Appending an empty terminating chunk would instead inject bytes into the new tunnel.

The client has a requirement too: it must ignore those framing fields if they appear in a 2xx CONNECT response. A malformed sender is therefore not a reason to describe every compliant client as waiting for a chunked body.

Keep the established connection open for relaying. Closing it after 200 destroys the tunnel; opening a different connection is not the continuation of the accepted CONNECT request.

A failed CONNECT response has different handling and can carry an ordinary HTTP error body. Separate that response from the successful handoff when implementing or reading a proxy trace.

Artiglyn mynjee