Pewarta Proxy

📋 Server Request & Proxy Logs

Loading active proxy settings...
Developed by Khairul Adha (adhexa.id)
Mengambil log server...

⚙️ Pengaturan Proxy Target

Skip to content

macOS tcp_now overflow after 49.7 days causes TIME_WAIT exhaustion #2665

Closed

Description

@wongws11

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,384 IPv4 ephemeral ports occupied
  • approximately 21,900 TIME_WAIT sockets and 22,672 TCP PCBs
  • approximately 15,990 IPv4 TIME_WAIT sockets attributed to OrbStack 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 with Can't assign requested address
  • binding curl to source address 192.168.50.60 or a port outside the ephemeral range succeeded
  • curl -6 succeeded
  • 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_WAIT dropped 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

  1. kdrag0n commented on Aug 21, 2026

    @kdrag0n
    Member

    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

  2. changed the title [-]OrbStack exhausts macOS ephemeral ports with non-expiring TIME_WAIT sockets[/-] [+]macOS tcp_now overflow after 49.7 days causes TIME_WAIT exhaustion[/+] on Aug 21, 2026
  3. wongws11 commented on Aug 21, 2026

    @wongws11
    Author

    Confirmed. The affected Mac booted at 2026-06-29 09:16:42 BST, so its tcp_now overflow 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions