In recent months a rather peculiar flaw has come to light in MacOS While it doesn't usually affect the average user, it has put developers, system administrators, and anyone using a Mac as a server on alert, as seen in guides for Fix the most common macOS Sequoia errorsAfter just under 50 days of being turned on without restarting, some computers stop being able to open new internet connections.
This problem, colloquially known as the “macOS 49-day internet bug”It's not a simple Wi-Fi drop or a temporary router outage. It's a deep bug in the operating system's network stack, which makes the Mac appear connected but, in practice, leaves it isolated from any new communication.
Where the bug comes from: a 32-bit counter at its limit
The research, led by the team of Photon (a company focused on integrating AI agents into messaging services), has revealed that the origin of the flaw lies in the way macOS measures time within its TCP system. The XNU kernel uses an internal variable called tcp_now to keep track of the time in milliseconds since the system started. A similar kernel flaw was documented in a code execution error in macOS Big Sur and earlier.
This counter is implemented as a 32-bit unsigned integer, which implies a maximum value of 4.294.967.295. If that figure is expressed in milliseconds, the calculation matches almost perfectly with the observed behavior:
4.294.967.295 ms ≈ 49 days, 17 hours, 2 minutes and 47 seconds.
Upon reaching that threshold, the counter reaches its limit and overflows. In an ideal design, the system should correctly handle this reset to zero, but what has been observed is that, in macOS, TCP timing logic breaks down At that point, the internal clock used to decide when certain connections expire becomes "frozen" or starts making incorrect time comparisons.
Photon researchers encountered the problem while using a farm of Mac mini and Mac Studio to monitor iMessage services and deploy their OpenClaw platform. Several machines, after being powered on for weeks, suddenly stopped accepting new connections without warning, although they continued to respond to ping requests and appeared to be in good working order.
What exactly goes wrong with the macOS network?
The most striking thing about this bug is that it doesn't produce the typical total disconnection where the Wi-Fi icon disappears or the system indicates that there is no network. In fact, Existing connections can continue to function normally for a while.
The flaw manifests itself in the handling of new network activity. Once the internal counter overflows, macOS begins to miscalculate the times associated with closed TCP connections, especially those in the [unclear/unclear] state. TIME_WAIT, which is the phase in which the system waits a little while before completely ending a communication.
Under normal conditions, the kernel periodically cleans up these terminated connections. free ephemeral ports and resources. However, when the TCP clock stops advancing properly, the system repeatedly concludes that those connections "have not yet expired" and does not remove them.
The result is a progressive accumulation of entries in the connection table until The available ports for new TCP communications are exhausted.From that point on, any attempt to open a new connection (a web page, an API, an SSH tunnel, etc.) starts to fail, while other functions like ping (ICMP) may continue to respond, complicating the diagnosis.
In practice, the Mac appears to remain connected to the local network, responds to basic tests, and can even maintain existing sessions, but it is unable to initiate new connections. For a production service, this translates to silent interruptions, wait times, and intermittent errors in applications that depend on the internet.
A classic case of overflow reminiscent of Windows 95
The pattern detected in macOS is not new in the history of computing. It is a overflow of a 32-bit time counter, a well-known category of errors that has already caused a stir in other systems.
In the 1990s, Windows 95 and Windows 98 suffered from a similar flaw: after approximately 49,7 days of operation, the system began to behave erratically due to how it measured time in milliseconds within certain drivers. The underlying mathematics was the same: a 32-bit integer measuring milliseconds inevitably causes problems precisely in that time frame.
Something similar happens with other timing bugs, such as the famous problem of the year 2038 On 32-bit Unix systems, the seconds counter from 1970 onwards overflows and generates incorrect dates. In the case of macOS, the impact is concentrated on the TCP subsystem, which does not handle the reset of the tcp_now counter well and leaves "ghost" connections occupying resources.
The published analyses also point to a faulty implementation of the TCP standard (with references to RFC 7323) by Apple, at least regarding timer management and the clearing of connections at regular intervals. A seemingly minor detail in the code, but with significant consequences after weeks of continuous use.
Who is most affected: from Mac servers to laptops at rest
In typical home use in Spain or Europe, where the computer is turned off regularly or updates are installed that require a restart, It is not common to reach those 49,7 days of uptime.That's why many users will never encounter this bug.
However, the situation changes when we talk about professional environments and machines that are always onSeveral risk profiles come into play here:
- Mac mini and Mac Studio used as servers, very common in app development studios, creative agencies or companies that need macOS to compile Apple software.
- IC/CD and automation equipmentwhere continuous integration runners run on Apple hardware for weeks without shutting down.
- Workstations that rarely restartFor example, in engineering departments, professional video or audio editing.
- Laptops like the MacBook Air or the MacBook Pro which are used by closing and opening the lid, entering rest mode but never turning off.
In many homes and offices it is simply common lower the laptop lid and continue working the next day, without an explicit restart. Add to that the habit of postponing system updates, and it's not uncommon for a Mac to accumulate more than a month and a half of uptime without anyone noticing.
Several testimonies gathered by developers point precisely to this pattern: after weeks of use, a MacBook that seemed to be "getting stranger and stranger" starts to have connection errors, certain pages fail to load, some apps freeze when trying to access the internet, and the user blames the router or the internet provider, when the problem actually lies with the device itself. macOS internal counter.
Common symptoms: there seems to be a network, but nothing new connects
Those who encounter this error usually describe a rather perplexing situation. On the one hand, the Mac continues to show that it is connected via Wi-Fi or EthernetIt responds to pings and, in many cases, some already established connections remain active.
But at the same time, even basic operations like opening a website or connecting via [unclear - possibly "connection by" or "connection by"] begin to fail. SSH to another server, synchronize with the cloud, or make API calls. Applications display timeout messages, downloads fail to start, and certain services stop receiving traffic without a clear system-level error appearing.
In servers and production environments, this translates to service interruptions On web platforms, job queues stop processing, integrations become unresponsive, and CI/CD pipelines fail to connect to external repositories, databases, or endpoints.
Some monitoring tools have allowed us to see what's happening underneath: right after the critical 49-day mark, the number of connections in TIME_WAIT state starts to grow steadily, while the ephemeral port range (which in macOS has around 16.000 options) gradually fills up until it is completely "occupied" by connections that never expire.
Therefore, even though the system doesn't display an obvious alert, what's really happening is that no ports are available anymore to open new TCP connections. The network is not down, but the TCP stack is, in effect, saturated.
Current solutions: restart and prevent before reaching the limit
As of today, and according to both Photon and other developers who have analyzed the problem, the only truly reliable solution is completely restart your MacThis restart resets the tcp_now counter, clears accumulated connections, and returns the network to normal.
This has a clear consequence for anyone managing infrastructure on macOS, whether in a small development studio, an SME, or a data center: It's not advisable to let a Mac exceed 49 days of uptime. without a shutdown or restart in between.
Among the mitigation measures being recommended in professional settings in Europe are:
- Schedule periodic restarts (for example, every 30 or 40 days) on Mac mini servers, Mac Studio, or CI nodes.
- Setup uptime alerts to receive alerts when a device approaches 40 days of being powered on.
- Monitor the number of TIME_WAIT connections and the use of ephemeral ports through network tools, especially on critical machines.
- In mixed architectures, consider move server loads to Linux when it is not essential to use macOS, reserving Macs for specific tasks such as compiling apps or specific tests.
For individual users with a MacBook, iMac, or Mac mini desktop computer, the advice is much simpler: restart your computer from time to timeA monthly restart is usually more than enough to avoid hitting this limit, and it also helps to clean up background processes and small memory leaks that accumulate over time.
Is it a security or stability problem?
For now, the consensus among experts is that the 49-day bug in macOS is primarily a stability and availability problemIt is not an exploitable vulnerability in the classic sense. There is no indication that an attacker could directly exploit this bug to execute code or take control of a system.
That doesn't mean it doesn't have an impact on the continuity of serviceFor companies that operate 24/7 services on Mac, a silent drop in new connections can mean downtime, loss of data in transit, or disruptions to critical processes.
In some ways, the behavior is more like a condition of accidental denial of service that is, a security breach. The system, on its own, enters a state in which it stops accepting connections, with the consequent operational impact.
Frequently asked questions about the 49-day internet outage
Does macOS lose internet access after 49 days?
What happens is not a total disconnection, but rather New TCP connections start to failThe system may still appear connected, respond to pings, and maintain some sessions, but it will no longer be able to open new connections to services, websites, or APIs.
Does it affect all versions of macOS and all Macs?
The analysis suggests that the bug is present in all modern versions of macOS And therefore, on any computer running the system: MacBook, iMac, Mac mini, or Mac Studio. The key factor isn't the model, but how long it's been on without restarting.
Is this a bug officially confirmed by Apple?
The problem has been documented by developers and system administrators, and reported to Apple, but There is no detailed official description yet. in the manufacturer's public documentation nor any record of a specific patch released for this case.
How can I prevent my Mac from running out of new network connections?
The most effective measure is very simple: Restart your Mac regularlyFor servers or critical equipment, it's recommended to schedule restarts before reaching 49 days of uptime. For home users, occasional restarts are sufficient, for example, when installing system updates.
Everything suggests that this bug, although barely noticeable to the average user, has a clear impact on infrastructures that rely on macOS and remain powered on for extended periods. Until Apple implements a definitive kernel-level fix, monitor uptime and schedule periodic restarts It has become an almost mandatory practice for those who use Macs as servers or continuous work tools.
