use of http(s)_proxy

[holygrolli]

thanks for providing the source and the project at all. I realized you recently implemented socks5 support (and I also verified a working connection). For my scenario a simple http(s) proxy would suffice. My expectation was to just provide http_proxy and https_proxy as environment variables. I know Golang respects those when implemented the "classic" way. But without luck.
I have limited Go knowledge but I then went down the road of setting the dialer to use the proxy environment variables here but somehow this still does not work (at least I expected this from the docs). When looking into the code it also might have something to do with this proxy.Direct conditional. I have no clue what's the difference between net.DialTCP() and c.dialer.Dial(). Perhaps my change didn't have any effect and is still causing the condition to evaluate to true.

If you wonder why I would like the proxy setup, I want to reliably run sniproxy on an external server having a private tunnel to my home network. So finally all clients will be seen as the very source home IP.

Thank you!

[mosajjal]

Hi.

Http (s) proxies are designed to pass http(s) connections through. Passing any TCP connection through it is technically a misuse of it. I can take a look at supporting it in sniproxy. UDP DNS traffic will be an issue though; since UDP was never supported by http proxies.

As for using env variables, I believe your method works with http connections by default but not generic tcp dialer.

[holygrolli]

I wasn't aware this sni proxy thingy does direct tcp calls. was expecting it kind of acts as real proxy and does "simple" http(s) requests. so I guess if you don't have any idea then we can close this.
I am using socks proxy for now, but setting up a http proxy is simpler

[mosajjal]

sniproxy usually tries to stay as transparent as possible, so the user only needs to change the DNS settings and not set up an actual proxy on the endpoint. for TLS, sniproxy parses the first packet that comes from the client, tries to determine the SNI out of it (TLS client Hello) and establish a TCP connection to the "real" endpoint, then it pipes the original TCP connection from the user to the newly established one, so the client doesn't even notice the traffic being routed from somewhere else.

I'll try to add a HTTP proxy support for upstream connections at some point with the limitation of not allowing UDP DNS at the same time.

hopefully above clarifies how things work behind the scene.