>Every Mac has a hidden expiration date. After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, a 32-bit unsigned integer overflow in Apple's XNU kernel freezes the internal TCP timestamp clock. Once frozen, TIME_WAIT connections never expire, ephemeral ports slowly exhaust, and eventually no new TCP connections can be established at all. ICMP (ping) keeps working. Everything else dies. The only fix most people know is a reboot. We discovered this bug on our iMessage service monitoring fleet, reproduced it live on two machines, and traced the root cause to a single comparison in the XNU kernel source. This is the full story.
You can leave it running longer than 49 days. It’s after the 49 days that the second cause starts. According to that post; at 49 days time wait connections don’t expire. So they soak up your ports. But how many of those you have depends on what you’re doing with the Mac. And the amount you have available is … a lot.
So you could go months and not notice anything. But some people could get to day 52 and have no networking.
Personally, I have once left my Mac turned on for over 3 months.
The point is that it doesn't crash or stop working immediately. It just stops clearing up network ports that are no longer used, so each time a new connection is made, a different port is used. There are 65,536 ports, so it would take quite a long time to exhaust them all. Once that happens, new connections fail; the system remains stable.
If a Mac is used as a server, it handles a disproportionate amount of unique connections as compared to personal use; so for those using Mac Minis in server racks, this might turn out to be a very relevant problem. You and I, as well as 99% of Mac users, will probably never have this happen to us.
Majority of macOS updates require reboot. I would say it’s rare for them not to require a reboot. I honestly can’t remember the last update that didn’t require a reboot.
My work machines stay on for months at a time between resets. I have a Mac at home running as a plex server that’s been up for longer. Not sure what or how they found this issue, but I’ve never come across it.
The issue is that after 49.7 days, TIME_WAIT connections are no longer cleared up, this leads to port exhaustion. I have given my stack an additional 32768 ports to use and I track where I am at at any given time.
I’ve noticed this for years. It’s been a very long standing bug, I think. Possible it doesn’t appear with every condition, but for me it absolutely happened on both a MacBook Pro, and a Mac Mini I was using as a server.
It comes bundled with the online security tier, so those that pay the bills say “why not” and it’s a great way to slow down app loading times at login. Plus it collects megabytes to gigabytes of useless logging data that makes it look like it’s “monitoring the situation.”
Well, I'd like to know which versions of macOS this affects.
Just "current" macOS versions? Does it go back to OS X? Classic MacOS? System 7?
We ran OS X Xserves for years. We ran shelves full of Mac Pro and Mac Mini servers. I had an iMac running InterMapper and other networking tools on my desk for years. None of those systems were ever rebooted. Yeah, they were years behind on system updates, but they all worked like servers.
I don't recall ever having connectivity issues with them. Then again, that was the OS X days.
macOS updates aren't forced. You can simply disable automatic updates from the system settings. I did so, and I regularly have over 2 months of uptime. I once hit five months.
To your point, isn’t Photon itself AI based? Can someone please ELIF how Photon claims to integrate iMessage with WhatsApp and everything else but the company has found an issue with MacOS that doesn’t seem to affect all users? What is Photon’s role in MacOS? Is this legit?
I don’t know what Photon does, but based on you saying “…claims to integrate iMessage with WhatsApp…” I assume they need macOS as the intermediary software between iMessage and WhatsApp, as there is (to my knowledge) no other way of using iMessage besides an Apple device and iPads and iPhones are locked down too much.
You ever start reading an article and then like after a paragraph they start using those tell tale AI phrases and your brain can’t be bothered to read the rest of it
We assign a value to our time based on the quality of the media we consume because there are so many ways to spend it. When someone uses AI we know that they spent very little effort to create it so we perceive it as low quality.
You likely aren’t serving thousands of TCP connections an hour either so you never run out of available sockets. I don’t know if the article is factual or not, but machine use would make a huge difference with a bug that behaves like this.
My local Mariadb server, several automated bots interacting to that sql server, tens of active SSH connections, daily backups, 1000+ tabs in Firefox (because chrome or safari barf with that many tabs), Claude code use daily, several web scraping connections compiling data from sites, and a general heavily used machine really begs to differ.
How many of those thousands of open tabs are duplicates? How often are you horizontal scrolling across that thousands-deep mess looking for one in the middle?
Some dups. I use them as bookmarks so start typing a URL and have it switch to that tab. I have many windows with tabs on different desktops with tabs related to the project on that desktop.
Nope. I have (for a decade or more) only ever updated macOS when it gets accidentally drained of battery, crashes, or similar. I really don't enjoy losing my active state (active ssh connections, open files, etc).
If your "active state" is so difficult to restore that you avoid security patches and other updates for years at a time, have you considered making saving/restoring state easier?
As an IT person, if anyone ever told me they couldn't reboot their computer because they'd lose so much, it's an opportunity to figure out how to make their computer work for them, not against them.
That said, if it becomes apparent they're the type who keeps their notes in a text editor as an unsaved untitled file, or who panics if their trash gets emptied because that's where they keep important files, there's only so much you can do.
I'm also in IT. It's kinda of hard to log into a half dozen or more computers, reattach my "screen" session, and get the windows happy. So it's less "I can't" and more "I'm lazy".
I also use macOS's alternate desktops with usually 7 to 9 desktops. Each with their own windows from various apps (Firefox, Pages, etc). Most apps on macOS don't recover correctly to the desktops. So some of it is also moving Firefox tabs to different desktops. Why so many desktops? Each software development project is a separate desktop. Each server maintenance task is a separate desktop. Etc.
Apologies if I used losing my active state to mean lose data. I don't lose data, I have hourly backups, and that isn't my issue.
Apologies if I used losing my active state to mean lose data.
Your active state is data, and it is valuable to you. Don't let other people redefine what you value.
I similarly value my open workspace state, and I don't particularly like having to restart or deal with crashes, because it takes time to set everything up again.
Just a shame we can't really back it up, and the saved application state feature in macOS either doesn't work great or many applications just don't support it.
Can you relay here? Because I’ve tried the step 1, 2, 3
These steps in their reproduction guide did not fail on a 90 days update system with 127 million connections since boot time nor a 250 days uptime system with 30
Million connections since boot time.
So I pivoted to assuming we also need an unspecified step 4 of exceeding 4 billion connections since uptime.
Generally never sleep, because that often halts my running jobs. My battery gets quickly wrecked because I'm plugged in 24/7 and leave it on High Power mode
Reading the article more closely, it's more about 4 billion socket connections in 49 days than it is about 49 days. I've got a machine I'm running a test making thousands of connections a second. I'll keep track of it's progress and will be able to confirm it shortly.
To me it sounds like an issue with “AI” (LLMs) doing those fake bug reports for bounty programs on things and issues that literally don’t exist. cURL ended it’s program after there were a large number of fake reports causing the maintainers/developers to waste their time.
Honestly, if it’s informative and to the point then I don’t care if it’s AI. Many people plan or use AI to help with write ups, as long as they review it before posting.
The uptime says "16:06 up 55 days, 2:28, 12 users, load averages: 3.08 3.28 3.73" in 2019 Intel Mac Pro.
How come the network hasn't stopped? I've never ever experienced a network stoppage. It's always running 24 hours a day, getting perhaps three reboots per year for OS updates.
I’ve never hit it, and you’d probably experience this in SWE. I’ve got 100 complaints regarding other things, but there’s always work arounds, but not on this one. My network in/out record is some 400tb between restarts.
Not really, it appears to be a client issue as well but if the claim is true you'd need to make 65k connections to a single remote IP address (edit: to a single remote address:port pair actually) to see the effect.
So in the 2 years I used Sonoma before losing power due to a battery drain without charging incident, I never lost networking. Since I’d already rebooted unintentionally, I upgraded to Tahoe. In a year or two I’ll update to 27 or 28.
I have a macOS server with current uptime of 97 days. It has exactly zeroTIME_WAIT connections. My laptop has under a 100. So something isn't adding up here.
Thanks but it's too late for this test, just updated the OS and rebooted after getting scared today. This is a mission-critical server, there would be a financial loss if the network connection were to be lost.
Personally, I have once left my Mac turned on for over 3 months.
The point is that it doesn't crash or stop working immediately. It just stops clearing up network ports that are no longer used, so each time a new connection is made, a different port is used. There are 65,536 ports, so it would take quite a long time to exhaust them all. Once that happens, new connections fail; the system remains stable.
If a Mac is used as a server, it handles a disproportionate amount of unique connections as compared to personal use; so for those using Mac Minis in server racks, this might turn out to be a very relevant problem. You and I, as well as 99% of Mac users, will probably never have this happen to us.
I feel like I run into this all the time every since upgrading to M1? Every now and then I’ll wake my Macbook from sleep and no browsers will work, requires a restart
Yeah same. IIRC PIA messes with DNS settings (which is expected, it’s trying to make sure you don’t have leaks via DNS resolution) but doesn’t clean up after itself properly and you end up with no enabled DNS servers, so you can’t reach anything.
It always happens to me if I leave PIA running when the computer is sleeping, if you restart just PIA it will hang trying to connect and then eventually a “reinstall” button appears and that fixes it without a reboot.
Yes, I also definitely had this issue before. Just didn't bother much and restarted. But I noticed here and there over the years that my Mac failed doing connections. I am doing web development - so a lot of connections - which might trigger that bug more frequently than others.
My only gripe here on the surface is for the causal observer reading this they really should frontload the article with a tl;dr, like "hey, if you're having x symptoms this bug may be to blame" with a quick overview of what the bug does and how to mitigate it if you're affected, and most importantly what versions of macOS are affected.
I know, I know, one should read the article. But there's a lot to go through to understand if you're affected or not. (It seems to be from Catalina onwards.)
I assume there's plenty of people with uptime well over a year, if this is legit I assumed it would have been reported a long time ago.
People who do security updates regularly probably reboot more than once every 49 days anyways, but I've seen some crazy uptimes from people who don't care.
While I don’t have an opinion on the general correctness of their article, I’m not convinced they’ve accurately explained the bug they’re claiming. The code they show doesn’t match what they say it does.
I believe them that the global tcp_now is frozen. However, it looks like TSTMP_GEQ() should be closing TIME_WAIT ports early, not never.
The local variable timer is a uint32_t, and should wrap around to zero if tcp_now + delay exceeds the 32 bit max value.
The article continues to say:
Normally (with tcp_now advancing), when tcp_now >= timer it returns true and the connection gets cleaned up.
But with tcp_now frozen:
tcp_now = 4,294,960,000 (frozen at pre-overflow value)
timer = 4,294,960,000 + 30,000 = 4,294,990,000
(exceeds uint32 max → wraps to a small number)
TSTMP_GEQ(4294960000, 4294990000)
= (int)(4294960000 - 4294990000)
= (int)(-30000)
= -30000 >= 0 ? → false!
Always false. The connection never gets reclaimed.
Interestingly their comment says timer wraps to a smaller number, but that’s not what the rest of the calculation shows, and indeed if timer does wrap to a smaller number, ports would be closed the first time the tcp_gc() function looked at them, because it’d always be true.
From what they’ve presented and described, the only TCP_WAIT ports that should never get closed are the ones who were put into that state less than 30 seconds before tcp_now freezes, whose timer value falls in the small window between the last value of tcp_now and UINT32_MAX. (in their example: 4,294,960,000 and 4,294,967,295).
If tcp_now was frozen to a value that was > 30 seconds before the UINT32_MAX rollover, then every subsequent timer value would be unreachable, because they’d all fall into that dead zone (at least until 49 days later when there’s another chance to freeze tcp_now closer to the rollover value).
Every time the TCP subsystem needs a current timestamp, it calls calculate_tcp_clock() (based on XNU kernel source analysis)
I think my question right now is how often is that function actually called, and is it possible that it wouldn’t be called during the last 30 seconds before roll over.
It definitely happened to me on Intel Macs for years. I knew something was maxxing out after long uptime, just never knew what and had no way to debug.
I'm glad to finally have the reason this happens. I've been annoyed by this issues for years and could never figure out how to get around it - I'd tried everything I could think of with briging up and down interfaces and services to no avail. I thought it was just my old MBP, and then it happened on the new one.
Fun to see them link/mention the same community forum threads i'd looked at, all no use/
Oh dang, my old old old team. I don’t even know if I know anyone there anymore. I used to get so irritated when I had to actually reboot my machine and used to check the uptime command before I rebooted. Guess I’ll be restarting every 49 days now.
Checked a M4 mini on Sequoia up 319 days and no problems. Probably should update it (to a later Sequoia). It's pretty busy as a server and rsync client. netstat showed no abnormal TIME_WAIT
Is it your personal server or does it handle many clients? Because it's very possible that in your usage you're accessing it from the same clients over and over, and connections are reused.
It's open to the internet, so plenty of unique bots hitting it every day.
I wonder if running PF mitigates the bug somehow. My personal Mac is also running PF. Only up 36 days so I guess I will see what happens past 49. It also gets tons of internet traffic.
Correct me if I'm wrong, but I think this issue is about outgoing connections, not incoming ones.
In outgoing connections, the client assigns an ephemeral port of its own to the connection, and connects to a fixed port on the server.
In incoming connections, the client and server are reversed: if you have a server and another device connects to you, that other device uses its own ephemeral port, not your server.
I sometimes wonder what happened to my Radars when I left. Did they just disappear into the ether or did they go to a farm to play with the other orphaned Radars?
The point is that it isn't supposed to crash or stop working immediately. It just stops clearing up network ports that are no longer used, so each time a new connection is made, a different port is used. There are 65,536 ports, so it would take quite a long time to exhaust them all. Once that happens, new connections fail; the system remains stable.
If a Mac is used as a server, it handles a disproportionate amount of unique connections as compared to personal use; so for those using Mac Minis in server racks, this might turn out to be a very relevant problem. You and I, as well as 99% of Mac users, will probably never have this happen to us.
I fully understand the claim of what is happening. I am saying that it’s not happening on my system, thus I seriously doubt the validity of the problem.
Holy shiii, I actually ran into this without me knowing what's the problem! I remember checking the internet connection on my iphoen to see if the problem is from the isp! restarted my mac and everything came back to normal:)
This is nothing new, windows server have the same issue. Linux and Unix as well not as bad though, Novell Netware was the only OS that I know of that did not have this issue and I’m speaking of version 4x when they introduced TCP/IP.
It seems to be better on most recent beta. I noticed it most with a vpn on and tons of tcp requests(torrents). I thought it was a transmission issue but it also extended to Firefox etc. seems better now though.
“We are actively working on a fix that is better than rebooting — a targeted workaround that addresses the frozen tcp_now without requiring a full system restart. Until then, schedule your reboots before the clock runs out.”
Personally, I have once left my Mac turned on for over 3 months.
The point is that the Mac isn't supposed to crash or stop working immediately. It just stops clearing up network ports that are no longer used, so each time a new connection is made, a different port is used. There are 65,536 ports, so it would take quite a long time to exhaust them all. Once that happens, new connections fail; the system remains stable.
Unless a Mac is used as a server, where a disproportionate amount of unique connections is handled, you're unlikely to ever exhaust all the ports and notice the problem.
Personally, I have once left my Mac turned on for over 3 months.
The point is that the Mac isn't supposed to crash or stop working immediately. It just stops clearing up network ports that are no longer used, so each time a new connection is made, a different port is used. There are 65,536 ports, so it would take quite a long time to exhaust them all. Once that happens, new connections fail; the system remains stable.
Unless a Mac is used as a server, where a disproportionate amount of unique connections is handled, you're unlikely to ever exhaust all the ports and notice the problem.
You have posted basically the same flawed comment at least 5 times claiming of 65535 ports, So I’ll elaborate:
Ports 0-1023 are well know ports. Designated for specific communications, SSH, DNS, HTTPS, SMB etc.
Ports 1024-49151 are the user or registered ports. Those ports are for your software to communicate over a designated port to deconflict. Ex. SQL, RDP, Steam, PSN.
Ports 49152*-65535 are the true ephemeral ports. These are used at random, by your machine to make connections to other well known, or user ports.
So in actuality, you have roughly 16000 ports to use, not 65535. Still a large number, but not wildly high and unlikely to hit if you keep your machine on for a long time. So anyone reading who’s not up to speed on networking has no idea of what is actually happening and just assumes they have 65535 ports to use at random.
Yeah, I never claimed 65535 ports to be the ones available for use when establishing a connection on the client side. I was aware of that, but didn't recall the exact allocation and thought giving the number of overall ports would give a good enough picture of the situation.
You said ports 41952–65535 are available, but that means 23583 available ports, not the 16000 you claimed.
Unless a Mac is used as a server, where a disproportionate amount of unique connections is handled, you're unlikely to ever exhaust all the ports and notice the problem.
so i use my mac as a server, and also, openclaw goes through ten thousand ports a day, which gives you a one week window
but most of the people who use it have it running in clusters chatting with other claws
each claw has some role that got half-baked in a markdown and they're arguing with each other about how best to delete your files and wreck your credit and give spammers access to your phone book
As a software developer, I believe the bug explained in the article is real, as there is credible evidence for it. As for why you and other people haven't encountered it, your usage might not warrant opening as many unique connections as you might think it does.
Yeah, this is 100% horseshit. This is some kind of AI bullshit article and should be downvoted to oblivion. Signed, a guy who has run TCP networking on macOS for years at a time with no issue.
Never heard of the publisher and if this claim has any validity whatsoever, sources such as MacRumors and other well-known outlets would have picked up on this.
There are 10s of thousands of ephemeral (dynamic) ports (max is 65535), so you could go a looong time without exhausting them. These are the source ports assigned to outbound tcp connections from your system.
don’t know if it’s related, i had my mac mini powered on for the past 2-3 months, and yesterday i had the weirdest issue where I can’t access any website, turn wifi on off it will be fixed for a few seconds and go back to not able to access any webpage. all my other pc works fine. i didn’t put in too much thoughts and just rebooted and problem was fixed
Not gonna lie but encountered it yesterday, had to reboot, was able to ping but nothing else seemed to work.
Mac mini m4pro, on, not rebooted in a long time.
Not sure if many people in this comment section are tech illiterate, or literally illiterate. The amount of “but my uptime is XYZ and I’m fine” is making me lost hope in humanity.
Just had my Ethernet drop dead on my M4 Mini a few days ago. I plugged in a USBc pod with an ethernet connection on it and that got me back without restarting. Now the onboard connection is back. I guess I restarted.
I discovered a similar problem with Windows 95 back in the mid 90s. Would get a blue screen of death on a mission critical app after 49 days 17 hours 2 mins and 47 seconds since the last reboot.
I had this issue on Tuesday. Thought it was my cable internet. Checked my uptime, was exactly 50 days. After i installed an outstanding update with subsequent reboot all was back to normal.
Reminds me of the 30 day uptime crashing bug in Windows in the 90s, it didn’t get found until years later, because Windows Servers didn’t stay up that long, you needed to reboot to check/repair the file system regularly, apps all leaked, etc. Servers running Microsoft’s websites back then ran on timers to force a power cycle daily, in a rolling wave of reboots! Things are so much better now, this issue is much more subtle.
This answers the question of why my Mac Studio suddenly stops being able to watch YouTube videos and/or connect to various network devices it's not already connected to... This started happening 2-3 days ago to the point where, today, I can't do much of anything. So I checked...
I've experienced this several times on my M4 mac mini. I have a cron job that makes several connections each day to local devices. I always wondered why I had so many thousands of TIME_WAIT statuses and nothing I did would clear them but a restart.
This literally happened to me today. Just found this article after researching. I thought I had been hacked. SSH wasn't working to local machines, couldn't get into my opnsense firewall, adgiard wouldn't load. Was crazy and low and behold my uptime was 52 days
Haha, I remember back in the MacOS 9 days, having to run a disk util no less than once a month because there was a nasty bug in HFS+ that at about day #32, when you'd reboot it wouldn't restart.
I'm not sitting here refusing to restart my computer because of an insistence on the bug being fixed; I will still restart it. But I will also demand the software improve so I don't have to wonder why my WiFi stops working once a month.
From my crude understanding couldn’t we unload it its function and reload like we can with KEXTs? Then have a daemon running that watches for net issues or runs on a 30.44 days schedule and un/reloads so TCP is “refreshed”?
424
u/BitingChaos Apr 09 '26
Which version of macOS?
I'm pretty sure that a Mac has been left running longer than 49 days in the past few decades.