你的Mac最长连续运行过多久？一周？一个月？如果超过49天，它可能会突然"拒绝联网"——不是因为路由器故障，也不是因为系统更新，而是一个藏在TCP协议底层的整数溢出漏洞。

谁发现了这个"定时炸弹"

打开网易新闻 查看精彩图片

Photon是一家做AI基础设施和开发者工具的创业公司。他们的工程师在日常测试中发现了一个诡异现象：测试用的Mac机器在运行一段时间后，网络连接会出现异常。

进一步排查后，他们定位到了问题的根源。Photon在博客中写道：「每一台Mac都有一个隐藏的过期日期。」具体来说，「在连续运行恰好49天17小时2分钟47秒后」，macOS会发生「整数溢出」，导致「内部TCP时间戳时钟冻结」。

这个时间精度令人印象深刻——不是"大约50天"，而是精确到秒级的49天17小时2分钟47秒。背后的数字是4,294,967,295秒，刚好是32位无符号整数的最大值。

为什么TCP时间戳会"冻住"

要理解这个bug，得先明白TCP时间戳（TCP Timestamp）是做什么的。

TCP协议用这个机制来测量网络往返时间、防止序列号回绕攻击。简单说，它像是一个不停计数的内部时钟，帮助系统判断网络包的新旧顺序。当这个计数器达到32位整数的极限值后，按设计应该归零继续计数——这就是"溢出"处理。

但Photon发现，macOS在这个溢出处理上出了问题。计数器到达最大值后没有正确归零，而是直接卡死。后果是：系统无法判断现有TCP连接是否过期，新连接也建立不起来。

对用户来说，最直观的感受就是"上不了网"。Wi-Fi图标可能还显示已连接，但浏览器打不开页面，App无法同步数据。这种故障排查起来特别头疼——因为路由器正常、账号正常、系统也没报错，就是不通。

谁会真的遇到这个问题

49天连续运行，听起来像是一个极端场景。但Photon的业务场景恰恰说明，这类用户真实存在。

AI基础设施公司需要长时间运行的服务器环境做模型训练、持续集成测试。开发者的Mac可能数周不关机，只是合盖休眠。某些边缘计算场景、自动化测试农场、甚至是重度依赖Mac Pro的工作站用户，都可能触达这个阈值。

更隐蔽的风险在于：macOS的休眠机制不会重置这个计数器。如果你的Mac只是频繁合盖开合，但从未真正重启，时间戳时钟一直在后台累积。一个表面看起来"经常关机"的用户，实际上可能已经逼近49天极限。

Photon指出，这不是一个可被黑客利用的安全漏洞——没有远程攻击面，也不需要紧急打补丁。但它属于那种"沉默的故障"：发生时没有预警，诊断困难，修复前会让人抓狂。

苹果的应对与用户的临时方案

Photon在发现后已向苹果通报。原文提到「该公司正在制定自己的解决方案」，但没有给出具体时间表。考虑到macOS的发布节奏，这个修复可能会随下一个版本推送，也可能需要更久。

在那之前，解决方案出奇地简单：重启。在49天到来之前手动重启一次Mac，TCP时间戳计数器归零，一切恢复正常。

如果你担心忘记，可以设置定时开关机。macOS的系统偏好设置里支持配置每天或每周的自动重启计划。对于服务器场景，也可以用cron任务或launchd脚本定期执行重启。

这个方案听起来有点"土"，但恰恰暴露了现代操作系统的一个张力：我们被训练成"不要重启，保持工作状态"，但底层技术架构仍对" fresh start"有依赖。Windows的"重启解决90%问题"是梗，也是现实。

从Photon的视角看行业

Photon选择公开这个发现，而不是等苹果修复后再发声，符合基础设施公司的技术文化。他们的业务建立在开发者信任之上，披露系统级问题能强化"我们懂底层"的品牌认知。

这也反映了一个趋势：AI创业公司正在深度参与操作系统和硬件的边界探索。大模型训练需要稳定的长时间运行环境，这会暴露传统消费级系统的设计假设——比如"用户每周至少重启一次"。

苹果的沉默也值得玩味。没有官方确认，没有安全公告，只有"正在制定解决方案"的模糊表态。对于一家以"it just works"著称的公司，承认底层计时器有49天寿命上限，显然不符合品牌叙事。

但这个bug的存在本身，说明macOS的TCP栈代码路径可能多年未被重新审视。32位计数器在Unix-like系统中历史悠久，从嵌入式设备到服务器都有类似设计。Photon的发现或许会促使更多团队检查自己的代码——不只是苹果。