Repository navigation
macOS tcp_now overflow after 49.7 days causes TIME_WAIT exhaustion #2665
Description
Describe the bug
Long-running Docker scraper traffic through OrbStack exhausted the macOS IPv4 ephemeral port range. New host and container IPv4 TCP connections then failed with EADDRNOTAVAIL / Can't assign requested address, while DNS, ICMP, IPv6, routing, and existing GUI connections remained healthy.
The closed connections remained in TIME_WAIT well beyond 2 * net.inet.tcp.msl, survived stopping/removing the containers, and survived stopping OrbStack Helper. After Helper PID 56486 exited, netstat -anv -p tcp still showed the sockets as ownerless :56486. Only a macOS reboot cleared them.
Evidence
- macOS automatic range:
49152-65535(16,384 ports) 16,382 / 16,384IPv4 ephemeral ports occupied- approximately
21,900 TIME_WAITsockets and22,672TCP PCBs - approximately
15,990IPv4TIME_WAITsockets attributed toOrbStack Helper:56486 net.inet.tcp.msl: 15000- counts remained unchanged for several minutes and after OrbStack stop/start
curl -4 https://ghcr.io/v2/failed immediately withCan't assign requested address- binding
curlto source address192.168.50.60or a port outside the ephemeral range succeeded curl -6succeeded- route remained valid: destination ->
192.168.50.1->en6->192.168.50.60 - application firewall disabled; file and mbuf limits were not exhausted
After reboot:
TIME_WAITdropped to 9- IPv4 ephemeral usage dropped to
40 / 16,384 - host GHCR returned the expected HTTP 401
- container GHCR returned the expected HTTP 401
Most leaked destinations matched the container workload exactly (api.car2search.com and 28car.com behind Cloudflare). The workload generated significant connection turnover, but a healthy stack should expire the closed PCBs rather than retain them indefinitely and break host networking.
A separate broken-state report was captured before reboot at ~/.orbstack/diag/orbstack-diagreport_2026-08-21T09-18-30.985114Z.zip; its automatic upload failed because OrbStack could not open an IPv4 socket. It can be provided privately if needed.
Diagnostic report
OrbStack info:
- Version: 2.2.3
- Commit: c83556b0ef8f1ba9a33abbb194622b6b7a1c0307
System info:
- macOS: 26.3.1 (25D2128)
- Apple M1 Mac mini, 8 GiB
Full post-reboot report (includes persistent logs):
https://orbstack.dev/_admin/diag/orbstack-diagreport_2026-08-21T09-39-54.723500Z.zip
Reproduction pattern
Run an always-on HTTP/Playwright scraper in Docker through OrbStack for an extended period, then monitor:
netstat -anv -p tcp | awk '$6 == "TIME_WAIT" {n++} END {print n}'\nnetstat -anv -p tcp | grep "OrbStack Helper"\n```\n\nExpected: `TIME_WAIT` PCBs expire normally.\n\nActual: OrbStack-attributed PCBs accumulated until nearly every IPv4 ephemeral port was occupied.
Activity
kdrag0n commentedon Aug 21, 2026
This is a macOS bug that shows up after long uptime: https://photon.codes/blog/we-found-a-ticking-time-bomb-in-macos-tcp-networking
[-]OrbStack exhausts macOS ephemeral ports with non-expiring TIME_WAIT sockets[/-][+]macOS tcp_now overflow after 49.7 days causes TIME_WAIT exhaustion[/+]wongws11 commentedon Aug 21, 2026
Confirmed. The affected Mac booted at 2026-06-29 09:16:42 BST, so its
tcp_nowoverflow point was 2026-08-18 02:19:29 BST. Failure was captured on August 21 at 53 days uptime. This precisely matches the 49-day 17:02:47 XNU overflow described in the linked Photon analysis.Correction to my original attribution: OrbStack was the source process for most short-lived container connections, but it did not cause the timer failure; the scraper traffic only accelerated ephemeral-port exhaustion after the macOS TCP clock had frozen. Reboot resetting the count from ~21,900 to 9 is also consistent with this root cause. Thanks for the confirmation.