Change upstream proxy for https flow

My eventual goal is to dynamically change the upstream proxy of my https flow based on the domain of the destination server or the value of a header.

For now, I’m just trying to get a minimal example working following the example of https://github.com/mitmproxy/mitmproxy/blob/master/examples/complex/change_upstream_proxy.py but I’m not getting the expected results.

I run mitmdump in upstream mode like so:

mitmdump -U https://default-proxy:port -s change-upstream.py

With this script

def request(flow):
  flow.live.change_upstream_proxy_server(("other-proxy", port))

When make an http request through mitm to an ip echo server I get the ip of “other-proxy” as expected.

curl -x localhost:8080 http://api.ipify.org  --insecure

But when I make ah https request instead I get the ip of “default-proxy” indicating that the upstream server of the request was not changed dynamically by the script.

curl -x localhost:8080 http://api.ipify.org  --insecure

Mitm proxy logs the request and does not indicate any errors.

127.0.0.1:34124: clientconnect
127.0.0.1:34124: GET https://api.ipify.org/
              << 200 OK 13b
127.0.0.1:34124: clientdisconnect

What do I need to do differently to change the upstream proxy of the https request?

In the case of an http request the header and the hostname are visible .But in the case of an https request you wont be able to access the header or hostname .The headers are available only after the TLS handshake occurs.You can change your upstream server after the TLS handshake by using the serverconnect event .

What do I need to do differently to change the upstream proxy of the https request?

Sorry for the late reply. We lately fixed a bug regarding that, the next release should have you covered.

@mhils I just ran this test again after downloading the 2.0 release and it now works as expected. Thanks for the solution.

1 Like

@wmrowan You got this working? I am using the latest version but it seems HTTPS still uses the default proxy. As described here:

Got any insight?

@Jake232: See https://github.com/mitmproxy/mitmproxy/issues/2253