Your Mac Stops Connecting to the Internet After 49 Days and the Only Solution is to Restart It

Every Mac has a hidden "expiration" for network activities. After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, macOS stops opening new TCP connections: browsers, email clients, and communication apps silently freeze. Pings still respond, everything else "dies" and the only available way out is a system restart.

The bug was discovered by Photon, a company that develops tools for connecting AI agents to iMessage and manages a fleet of continuously active Mac servers. It was precisely that operational continuity that highlighted the anomaly, first empirically observed on several machines in the fleet, and later reproduced in a controlled manner on two separate systems to trace it back to the root cause in the XNU kernel source code. Photon published a detailed technical analysis, including the reproduction procedure and live observations during the 9.5 hours of gradual degradation before the final collapse.

The tcp_now Counter and 32-bit Overflow

The problem resides in how the macOS XNU kernel internally manages TCP time. The counter involved is called tcp_now and is implemented as a 32-bit unsigned integer, capable of representing values from 0 to about 4.29 billion. Reaching the maximum limit causes the value to return to zero due to arithmetic overflow, which happens after exactly 49 days, 17 hours, 2 minutes, and 47 seconds of uptime.

The rollover itself wouldn’t be catastrophic if the system managed it correctly. The trouble arises from the interaction between this reset and the mechanism for cleaning up TCP connections in the TIME_WAIT state. When tcp_now resets, the timing comparison logic that should determine the expiration of old connections stops functioning: the timestamps recorded before the overflow now appear "in the future" relative to the new counter value, and the system no longer recognizes those connections as expired. Photon traced the defect to a single comparison in the XNU source code.

Connections in TIME_WAIT are never released and continue to occupy ephemeral ports, which are finite in number on macOS. With each new connection opened and no old ones ever closed, the pool gradually depletes. When all ports are occupied by "zombie" connections, any attempt to establish a TCP connection fails. ICMP traffic, which does not depend on TCP, continues to work: this is why pings respond but any other network operation becomes impossible.

The degradation is not instant: Photon documented a slow agony in the hours following the overflow, with observable CPU spikes as the system tries to handle the increasing pressure on the ports, before the definitive network collapse.

Who is Really at Risk

The vast majority of Mac users will never encounter this bug in practice. System updates almost always require a restart, and the habit of turning off or putting the Mac to sleep daily naturally resets the tcp_now counter. The problem becomes concrete for devices operating as always-on servers or workstations: Mac mini and Mac Studio used in AI pipelines, Mac Pros left running on prolonged development projects, or fleets of Macs used to automate services. This latter is exactly the situation that led to Photon’s discovery.

Among the affected models is the MacBook Neo, the entry-level laptop launched by Apple in March 2026 with the A18 Pro chip and macOS Tahoe. Although designed for the general public, the Neo is nonetheless subject to the same behavior of the shared XNU kernel: if kept powered on continuously for over 49 days, it will lose TCP connectivity just like any other Mac. A concrete use case could be students or developers using the Neo as an always-connected machine, never restarting it between updates.

The growing interest in Mac mini and Mac Studio in AI workflows makes this category increasingly relevant. These devices are chosen precisely for their energy efficiency in server-like configurations and are left on for weeks or months without interruption. With an uptime exceeding 49 days, they inevitably encounter this behavior. Developers who maintain active Mac workstations on long-term projects also fall into the at-risk category.

The Windows 95 Precedent

Windows 95 suffered from a similar problem: its kernel used a 32-bit millisecond counter for the system tick, which overflowed after about 49.7 days causing a complete freeze of the operating system. The difference from the macOS bug is that Windows 95 froze totally, while on macOS only TCP networking fails. The parallel is nonetheless significant: 32-bit integer overflows in system timers are a well-known class of defects, and their survival until modern systems indicates how they can remain latent in environments where prolonged uptime is not the norm.

How to Work Around the Problem, While Waiting for a Solution

Currently, the most immediate solution is also the simplest: restart the Mac before reaching 49 days of uptime. For those managing always-on machines, it is advisable to set a periodic restart policy, at least weekly. macOS allows checking the current uptime via the uptime command in the Terminal and enables scheduling restarts via launchd or the system power settings.

Photon has stated they are working on a solution that does not require a system restart. Apple currently does not have an official solution to the problem.