Mitmproxy taking long time to respond on Macbook M1 Sonoma

[Srijan67]

I am facing issue where mitmproxy takes a long time to send response due to which it throws 502 bad gateway error for traffic through browser.
While trying through terminal using command curl -x localhost:8080 -k https://www.google.com or curl -x localhost:8080 -k https://lh3.googleusercontent.com. It is taking a long time to send response in terminal.

I started proxy server using command mitmdump and installed it using command pip install mitmproxy

System Information:
Device: Macbook M1
Mitmproxy: 10.3.0
Python: 3.12.0
OpenSSL: OpenSSL 3.2.1 30 Jan 2024
Platform: macOS-14.3-arm64-arm-64bit
Homebrew 4.3.0

[mhils]

All the commands you mentioned work instantaneously for me on the following system:

Mitmproxy: 11.0.0.dev (+10, commit f05c050)
Python:    3.12.1
OpenSSL:   OpenSSL 3.1.4 24 Oct 2023
Platform:  macOS-14.4.1-arm64-arm-64bit

[vineet1984]

I also ran into a similar issue on my Macbook M1.

The Mitmproxy version I am running is 10.1.4. Is it fixed in later versions?

[mhils]

I would recommend to update to the latest release anyhow. :)

[Srijan67]

@mhils can you test the same on 10.3.0 version as well since its the latest version available online in pip. The issue I am facing looks similar to #6474

[mhils]

#6474 is a complete freeze of the application, which seems unrelated.

[vineet1984]

@mhils I upgraded to 10.3.0 that is the latest available version online. The proxy worked fine last night but the response times today morning are ~5 minutes or it times out depending on the website.

curl -x localhost:8080 -k https://www.google.com ---- 4 minutes
curl -x localhost:8080 -k https://www.facebook.com ---- 4 minutes
curl -x localhost:8080 -k https://www.yahoo.com ---- curl: (28) Proxy CONNECT aborted due to timeout

I tried to see the error in the logs by using mitmdump -v but didn't see much except connect/disconnect and response statements.

Can you please help?

[mhils]

I don't have capacity at the moment, sorry. This needs a good reproducer in the first place, otherwise it's not really actionable.

[vineet1984]

Sure. If there are any mitmproxy logs beyond mitmdump we can use for troubleshooting, please let us know.

[mhils]

It may be useful to send SIGUSR1 / SIGUSR2 signals to a running mitmproxy instance that exhibits that behavior to see if anything sticks out.

[vineet1984]

I just sent SIGUSR1 and SIGUSR2 signals to mitmproxy. Links to the logs are below:-

https://gist.github.com/vineet1984/3db14195b78a6a83f15b7d0bb2a2c2b0
https://gist.github.com/vineet1984/62d8422053bea9cc473a4618d69ad89c

From what I can see, there is a line "work_item = work_queue.get(block=True)" in SIGUSR2 logs that could be a possible glitch. Do you see any other glaring issue?

[mhils]

This all looks good - I'm wondering what kind of output you'd get here during one of these super slow requests?