Why are the interception rules created in the nftables inet family rather than only for IPv4, and what does Happy Eyeballs have to do with it?

The inet family covers IPv4 and IPv6 at once; a dual-stack browser races both and tends to prefer IPv6, so IPv4-only rules would let much of the traffic slip past the proxy.

nftables has separate families: ip (IPv4), ip6 (IPv6) and inet (both in one table). A rule in an ip table never sees IPv6 packets.

Modern browsers implement Happy Eyeballs (RFC 8305): for a host with both A and AAAA records, the client resolves both, starts connecting over IPv6 first, and if that does not succeed within a short delay (about 250 ms) also tries IPv4. Whichever connection completes first is used, and the other is dropped.

So on a dual-stack network, a site like Wikipedia or meteo.ch would mostly be reached over IPv6. With redirect rules only for IPv4, those connections would bypass mitmproxy entirely and the interception would seem to work only sometimes. Using inet catches both paths. (The same logic applies to firewalls in general: an IPv4-only rule set on a dual-stack host leaves the IPv6 door open.)

Go deeper:

• Wikipedia: Happy Eyeballs — the algorithm and its browser implementations.
• RFC 8305: Happy Eyeballs Version 2 — the 250 ms connection-attempt delay and address sorting.