Internet connection sometimes reported incorrectly as DOWN, Stats restart fixes it

[uhkeller]

Describe the bug

When connecting to tethered WiFi provided by my Android phone, the internet connection is often incorrectly reported as DOWN even though the connection is working fine.

Clicking the reset button next to "Details" has no effect. It never changes to UP. When I restart Stats, however, it'll work fine from then on. I'm typically using this connection on train rides so sometimes there will in fact be no connectivity, but after the restarts Stats reliably detects the network coming back up.

I'm using TripMode to filter network usage when connected to the phone, but Stats is on the allow list and a Stats restart fixes it, so it seems unlikely that TripMode is to blame here.

I noticed that in the screenshots the order of the public IP addresses changes after the restart (before IPv6 is first, after IPv4 is first), so maybe this is some kind of IPv6-related problem?

If there is anything I can do to provide more information please let me know.

Details:

• Device: M1 MacBook Pro 2021
• macOS: 15.4.1
• Application version: 2.11.42

[uhkeller]

Since reporting this I've seen it happen on multiple different networks, not only on the (high latency) phone connection. Just now it happened on my workplace's wired network with latency below 3ms. Just to rule out high network latency as a possible trigger.

[j01am]

Same behavior for me :)

[uhkeller]

For me this has stopped happening since at least version 2.11.58. I'm still an macOS 15 though.
Edit: Happened again shortly after updating to 2.11.62.

[uhkeller]

Out of curiosity I asked GitHub Copilot about this. It gave me a plausible-sounding explanation (which might still be utter nonsense of course).
Here's the important part:

The status should ideally use usage.interface?.status (the actual interface UP/DOWN state) instead of reachability.isReachable, or combine both checks. The interface status is updated on every read cycle and reflects the true state of the network interface, not just internet reachability.

[uhkeller]

This has gotten worse for me with recent releases (now on 2.12.6). Basically every network change triggers this behavior now. I guess I'll just disable the network indicator.

[brndnsh]

I did some digging into the source and I think I've found the root cause (possibly two contributing factors):

1. ConnectivityReader.resolve() only accepts IPv4 addresses

In Modules/Net/readers.swift, the resolve() method loops through DNS results for the ICMP ping host (default 1.1.1.1) but filters to only keep AF_INET (IPv4) addresses. The ICMP socket is also IPv4-only. On a dual-stack tethered connection, macOS sometimes returns IPv6 results first — and when that happens, resolve() returns nil. Once addr is nil, icmpCheck() silently bails every tick, and crucially resolve() is only re-called when the configured host string changes — which it never does. So the nil addr is permanently stuck until restart.

2. Overly simplistic reachability flag check

In Kit/plugins/Reachability.swift, setFlags only checks the .reachable bit. Apple's own docs recommend also checking .connectionRequired — during tethering, the network can report .reachable + .connectionRequired (still establishing), and the callback may never re-fire once fully connected, leaving isReachable stuck as false.

Both of these would explain why a restart fixes it: on relaunch, the network is fully up and IPv4 results resolve cleanly.

Proposed fixes:

In icmpCheck(), retry resolve() when addr is nil (in the background) rather than silently returning — this handles the stuck-nil case without a restart.
In Reachability.setFlags, use Apple's recommended evaluation: reachable AND (not connection-required OR can connect without user intervention).
Happy to open a PR with these changes if that would be welcome — just wanted to discuss first before doing so. Thanks for the great app!

[uhkeller]

I don't see anything in the changelog about this, but for whatever reason the problem seems to be gone with 2.12.14 – I've also updated to macOS 26.5, so maybe the OS now reports interface/connection status more reliably?