I spent hours trying to debug and understand this issue and I think I finally figured it out! Just had to learn more about the HTTP proxy CONNECT sub-protocol to get a better understanding.

In short, what should happen is basically the following:

1. Establish a TCP connection to the HTTP proxy.
2. Send a HTTP request using the CONNECT method over the connection, which at least contains the target host to connect to.
3. Establish a TLS connection to the target host through the established proxy connection (optional).

However, there's currently an issue in the implementation of this flow. See the code snippets below.

Here, conn, err := hpd.forwardDial(network, hostPort) actually calls NetDialTLSContext if it's set. But in this context it is only the first step in the flow, resulting in connection errors because the proxy doesn't understand TLS yet:

If we change this to a regular net.Dial, the first and second step in the flow are fixed. But we're not there yet.

We get the established proxy connection here:

But there's currently no API to convert an existing TCP connection net.Conn into a TLS connection tls.Conn . The NetDialTLSContext method requires you to do the dial again, so that's unusable at this point. Therefore, an API change to add such method is required. For example:

// client.go
type Dialer struct {
    // ...
    ProxyTLSConnection func(ctx context.Context, proxyConn net.Conn) (net.Conn, error)
}

Now, further down in the code we can establish the TLS connection to the target host through the proxy connection by calling this new method (if it is defined):

// client.go
if u.Scheme == "https" {
	  if d.ProxyTLSConnection != nil && d.Proxy != nil {
	  		// If we are connected to a proxy, perform the TLS handshake through the existing tunnel
	  		netConn, err = d.ProxyTLSConnection(ctx, netConn)
	  } else if d.NetDialTLSContext == nil {
	  		// ...
	  }
}

Now the third and final step in the flow is fixed!

I hope my detailed explanation is clear and helpful to someone. I'll open a PR soon.

What bothers me about this is the fact that in net/http's Transport type one can specify a Proxy field as well as a DialTLSContext func which is exactly what NetDialTLSContext in gorilla was supposed to mirror. I therefore suspect that it is possible to fix this without requiring an API change.

Before posting this comment, I went ahead and had a quick peek at the source code. Even the golang source code has some weird behavior if DialTLSContext and Proxy are set. Unless I'm misreading this, it turns out that they actually skip the user defined DialTLSContext if the matched proxy URL has an HTTP scheme seen here. If the target's scheme is HTTPS they will upgrade the connection using their own TLS dial function with the user defined TLSClientConfig seen here, completely skipping DialTLSContext. Interestingly, if the proxy scheme is HTTPS, then they will attempt to establish a TLS connection using DialTLSContext directly against the proxy.

In other words, they "fixed" this issue in their code by completely ignoring it.