Skip to content

Windows Local Capture severely reduces throughput of unrelated high-bandwidth traffic #8446

Open

Description

@Animan8000-OpenWF

Problem Description

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:

const MAX_PACKETS: usize = 1;
let mut buf = [0u8; MAX_PACKET_SIZE * MAX_PACKETS];

### System Information

```raw
Mitmproxy: 12.2.3
Python:    3.14.7
OpenSSL:   OpenSSL 4.0.1 9 Jun 2026
Platform:  Windows-11-10.0.26100-SP0

Checklist

Activity

  1. Marwan-verse commented on Sep 28, 2026

    @Marwan-verse

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions