Internet stops working when using local mode on LinuX

[alto4truth]

Problem Description

Internet stops working when running mitmweb in local mode. Can't even curl google.com

Steps to reproduce the behavior:

1. run mitmweb --mode local

At first mitmweb prints no interesting logs but after some program tries to estabilish a connection this happens:

[11:01:25.361][169.254.0.1:46247] server connect 8.8.8.8:53
[11:01:25.364][169.254.0.1:40176] client connect
[11:01:25.365][169.254.0.1:51778] server connect 8.8.8.8:53
[11:01:25.368][169.254.0.1:48428] client connect
[11:01:25.376][169.254.0.1:40176] server connect 8.8.8.8:53
[11:01:25.378][169.254.0.1:48428] server connect 8.8.8.8:53

mitmwebs spams the log with these messages, looks like it redirects DNS requests to itself (?). It also eventually reaches open file limit.

Log after pressing Ctrl+C:

...
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.4.4:53
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.4.4:53
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.4.4:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
INFO:mitmproxy.proxy.server:server disconnect 8.8.8.8:53
DEBUG:mitmproxy_rs.udp_client:UDP client task shutting down.
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
DEBUG:smoltcp.iface.interface:failed to transmit IP: device exhausted
...

Error messages when reaching open file limit:

[11:11:22.581][169.254.0.1:50476] error establishing server connection: [Errno 24] Too many open files
[11:11:22.583][169.254.0.1:50476] client disconnect
[11:11:24.146][169.254.0.1:50480] client connect
[11:11:24.148][169.254.0.1:50480] error establishing server connection: [Errno 24] Too many open files

System Information

mitmproxy --version
Mitmproxy: 12.1.1
Python:    3.12.10
OpenSSL:   OpenSSL 3.4.1 11 Feb 2025
Platform:  Linŭ-6.12.31-x86_64-with-glibc2.40

mitmweb --version
Mitmproxy: 12.1.1
Python:    3.12.10
OpenSSL:   OpenSSL 3.4.1 11 Feb 2025
Platform:  Linŭ-6.12.31-x86_64-with-glibc2.40

Checklist

• This bug affects the latest mitmproxy release.

[lz80b]

Hi, I've identified the root cause of this issue.

When using --mode local on Linux, egress traffic is intercepted by eBPF and redirected to mitmproxy, which then forwards it to its original destination.

For TCP, this forwarding is done by the main mitmproxy process. However, for UDP (e.g., DNS queries), it's handled by an async worker thread (tokio-runtime-worker). The problem is that the eBPF filter does not exclude these threads, so mitmproxy ends up capturing its own retransmitted UDP packets. This creates an infinite loop and eventually leads to file descriptor exhaustion.

Root Cause:

Mitmproxy implicitly sets a rule in eBPF to exclude its own PID. The eBPF filter currently uses ctx.pid() to identify the source of traffic. However, this returns the thread ID (TID), and only the main thread is excluded. The worker threads have different TIDs and are not excluded.

Fix:

Use ctx.tgid() instead of ctx.pid(). tgid refers to the thread group ID, which corresponds to the process ID (PID) shared by all threads.

The relevant change is in mitmproxy_rs/mitmproxy-linux-ebpf/src/main.rs, line 31:

  pub fn should_intercept(ctx: &SockContext) -> bool {
      let command = ctx.command().ok();
-     let pid = ctx.pid();
+     let pid = ctx.tgid();

Verification:

With this change, mitmweb --mode local works as expected. The infinite loop is resolved.

Before: tokio-runtime-worker threads appeared repeatedly in tokio-console, indicating a self-loop.

After: No such thread activity, and network traffic works normally.

I’d be happy to submit a pull request for this fix if that would be helpful.

Temporary Workaround:

Until the fix is merged, you can exclude the worker threads by name:

mitmweb --mode local:!tokio-runtime-w

tokio-runtime-w is the prefix (15 chars) of the worker thread name ( tokio-runtime-worker ).

[alto4truth]

Temporary Workaround:

Until the fix is merged, you can exclude the worker threads by name:

mitmweb --mode local:!tokio-runtime-w

tokio-runtime-w is the prefix (15 chars) of the worker thread name ( tokio-runtime-worker ).

For me this workaround doesn't work on 12.1.1

[lz80b]

Hi! Thanks for the update.

Just confirmed again on my side -- excluding tokio-runtime-w does fix the infinite loop issue caused by DNS queries.

I tested this with mitmproxy 12.1.1 (not mitmweb), since my local mode testing environment is only available on a cloud VM right now, and I don't have easy access to run mitmweb with GUI there. But the behavior should be identical.

Quick Note on Shell Escaping

One thing I noticed during this test: the ! character needs to be properly escaped, otherwise the shell might interpret it.

To ensure your command works correctly, you should wrap the entire mode string in single quotes, like this:

mitmweb --mode 'local:!tokio-runtime-w'

Sorry I didn’t mention that in my earlier comment!

You can also verify the mode is set correctly by opening mitmweb UI in the browser, going to Options => Edit Options, and confirming the mode field.

Hope this helps!

[thegu5]

Copying and pasting untested LLM-generated slop doesn't help...

Local mode also breaks internet for me - I think it's due to dns breaking? (dig hangs forever`)

I'm on NixOS, and my dns is handled by systemd-resolved. resolv.conf just has nameserver 127.0.0.53

When not using dns, a different message shows up:
OpenSSL Error([('SSL routines', '', 'tlsv1 alert internal error')])

[jasper-war]

Experiencing exactly the same on Nixos 26.05 with kernel 6.18.7. Excluding tokio-runtime-w reduces the amount of connections registered significantly though. Makes local mode unusable.