Hello everyone.
Every proxy user knows this one. The Wi-Fi icon is full. The system swears you are online. TCP connections even connect — the handshake goes out, the server agrees — and then nothing comes back. Pages spin until they give up. You toggle the VPN; nothing improves. You switch nodes; nothing improves. The problem is not the node and not the app. The network between them is eating your packets, and nothing on the phone will say so.
This is what we call a black-hole path, and the engine now detects it and tells you about it.
What a Black Hole Looks Like
A path in this sense is a route out of the device: a source address on a specific network. A black hole is a path that can complete handshakes but never carries data — packets leave, nothing returns. It happens more often than it should:
- A cellular link stuck after a re-attach. The radio re-registers, the system still shows a fine-looking address, and every flow through that address quietly dies. The OS has not declared the network unusable, so nothing tells you.
- A half-opened captive portal. DNS sometimes even answers; TCP handshakes to some hosts complete; real payloads go nowhere.
- UDP-hostile networks. Hotel, airport and office Wi-Fi that let DNS through and swallow everything else on UDP — QUIC-based protocols starve first.
- A route that drops silently. No ICMP unreachable, no reset, no timeout error in the ordinary sense — the packets just do not come back.
What makes these hard to notice is that the system still reports the network available and individual failures look like ordinary flakiness. One timeout means nothing. So the engine watches the pattern, not the event: outbound connections that keep timing out and keep receiving no data, while the system insists the network is up, sustained over a window. When that pattern holds, the path is reported as a black hole. A single slow request, or one unreachable node, never triggers it — the same policy as the rest of Chute’s notification system, which only fires on sustained or large-scale anomalies.
What You See
You get a system notification saying the network cannot carry data. It fires once per occurrence — it will not repeat at you every thirty seconds — and re-arms only after traffic recovers or the network changes. The same stale path cannot spam you.
Where the switch lives:
- Chute Mac gives it its own switch in notification settings, on by default.
- Chute iOS and Chute Android follow the mass connection failures switch.
- Apple TV does not display notifications; the engine still logs the event, and it appears in the web console.
Two neighbours in the same update make the picture complete. The network address change notification now lists the addresses this device actually has, per family — it used to show a meaningless “exit IP”. And on Tailscale, a change of home DERP region is its own logged event instead of hiding inside a catch-all.
What To Do When It Fires
The notification means the path, not the proxy, is the problem. In practice:
- Toggle the network, not the app. Wi-Fi off and on, or switch to cellular and back. This is the one action that reliably re-homes flows onto a working path.
- Check for a captive portal if it is public Wi-Fi — open a plain
http://page and see whether the portal intercepts it. - If you just switched networks, give it a second. Chute closes flows whose upstream source address no longer exists on any interface the moment the change is noticed, instead of letting them hang until an idle timeout — and re-attachments of the same kind (a cellular link coming back on the same radio) are recognised too. But a link that is still attached and still broken is exactly the black-hole case.
- If it fires on your own router repeatedly, the culprit is usually an overzealous firewall or a misconfigured NAT on that router — not Chute.
When It Is Slow Instead of Dead
A black hole is the loud case. The quiet case is the flow that works but crawls, and you cannot tell whether the node, the transit, or your uplink is to blame. The engine now answers that too: when a long-running bulk flow closes, one log line says which leg it waited on — device to entry, entry to exit, or the far end — so the slow hop is named instead of guessed at. It is written to the session log at connection close, so it shows up in the session log viewer, the web console, and the diagnostic bundle you can hand to support.
The full description of the event, its thresholds and every notification switch is in the Chute Manual. And if you have been debugging a stubborn network by feel for years — this one is for you.
Thanks.
Chute Devs