You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Windows Local Capture severely reduces throughput of unrelated high-bandwidth traffic #8446
On Windows, mitmproxy's Local Capture mode appears to cause a severe throughput reduction for unrelated high-bandwidth network traffic.
I am using mitmproxy 12.2.3 as part of a tool that uses Local Capture to intercept only two specific processes (Launcher.exe and Warframe.x64.exe).
While Steam is downloading a large game depot, Steam itself is not selected for interception. However, simply having Local Capture active causes Steam's download throughput to drop substantially.
The behavior is reproducible for the affected user.
As a comparison, using the same application with regular System Proxy mode does not cause the slowdown.
Observed example:
System Proxy: ~97-100 MB/s
Local Capture: ~37 MB/s at the same stage of the download
windows-redirector.exe: ~10.4% total CPU usage during the Local Capture test
Steam download throughput returns to normal when Local Capture is not active.
The Steam workload is relatively demanding: it is downloading a ~50 GiB game depot containing a very large number of chunks.
This suggests that unrelated traffic passing through the Windows Local Capture redirector may incur significant overhead at high packet rates.
The current mitmproxy-windows redirector implementation appears to divert non-loopback TCP/UDP traffic and then pass through traffic belonging to processes that are not selected for interception.
I also noticed that the current network receive loop uses:
I traced the receive loop in mitmproxy_rs/mitmproxy-windows/redirector/src/main2.rs. It calls recv_ex(..., MAX_PACKETS) with MAX_PACKETS = 1, then forwards each returned packet as a separate NetworkPacket event to the main event loop. That confirms the one-packet-at-a-time path mentioned in this report is still present.
This is a plausible place to benchmark for the slowdown, but the source alone does not establish it as the cause. A before-and-after run with a larger receive batch, keeping the workload and process filters constant, would help test that hypothesis. I have not run that benchmark. AI-assisted source review.
Activity
Marwan-verse commentedon Sep 28, 2026
I traced the receive loop in
mitmproxy_rs/mitmproxy-windows/redirector/src/main2.rs. It callsrecv_ex(..., MAX_PACKETS)withMAX_PACKETS = 1, then forwards each returned packet as a separateNetworkPacketevent to the main event loop. That confirms the one-packet-at-a-time path mentioned in this report is still present.This is a plausible place to benchmark for the slowdown, but the source alone does not establish it as the cause. A before-and-after run with a larger receive batch, keeping the workload and process filters constant, would help test that hypothesis. I have not run that benchmark. AI-assisted source review.