У вашего Mac есть секретный аварийный выключатель

Представьте, что ваш Mac, безупречно работающий неделями, внезапно теряет все сетевые подключения. Не из-за мимолетного сбоя Wi-Fi или проблемы с маршрутизатором, а из-за внутреннего коллапса, который оставляет вашу машину изолированной. Это не гипотетический страх; это бомба замедленного действия, зарытая глубоко в macOS, готовая сработать после длительного времени безотказной работы. Точно 49 дней, 17 часов и 2 минуты непрерывной работы сделают весь сетевой стек вашей машины совершенно бесполезным, превратив мощную рабочую станцию в инертный, отключенный от интернета «кирпич». Ваш Mac остается включенным, но его цифровой мир сжимается до нуля.

Это не малоизвестный городской миф или редкая, неповторимая ошибка; это полностью проверенный сбой на уровне ядра. Инженеры стартапа Photon недавно обнаружили и тщательно задокументировали эту критическую уязвимость в реализации TCP от Apple. Их подробный анализ выявляет фундаментальный сбой в том, как macOS обрабатывает внутренние системные метки времени, в частности 32-битное беззнаковое целое число под названием `tcp_now`. Команда Photon, сталкиваясь с этой проблемой неоднократно на своем парке Mac, используемых для мониторинга сервисов iMessage, тщательно воспроизвела ошибку на нескольких машинах. Затем они кропотливо проследили ее происхождение до конкретной ошибки логики сравнения внутри самого ядра XNU, основного компонента операционной системы Apple.

Обнаружение этого точного, срабатывающего по времени сбоя служит отрезвляющим напоминанием о присущей хрупкости даже самых сложных современных операционных систем. В 2026 году простой счетчик, работающий в самом ядре системы, все еще может поставить Mac на колени, влияя на все: от обычного просмотра веб-страниц и электронной почты до критически важных задач разработки, таких как `git push`. Это подчеркивает значительную уязвимость, которая оставалась скрытой годами, подтверждено, что она затрагивает macOS 10.15 (Catalina) и все последующие версии. Тот факт, что такой фундаментальный недосмотр сохранялся, подчеркивает огромную сложность поддержания надежного, высокопроизводительного программного обеспечения в масштабе.

Как такой точный таймер вызывает катастрофический сбой сети, и почему система, обычно разработанная для стабильности, внезапно разваливается? Виновник кроется в 32-битном беззнаковом целом числе и его неизбежном переполнении, в сочетании с критической ошибкой в логике сравнения. Эта статья подробно расскажет, как этот, казалось бы, незначительный арифметический недосмотр в коде Apple приводит к полному исчерпанию доступных временных портов, парализуя способность вашего Mac устанавливать любые новые TCP-соединения. Мы углубимся в специфику работы переменной `tcp_now`, исследуем "запутавшегося" сборщика TCP-соединений ядра и раскроем точную последовательность событий, которая превращает непрерывное время безотказной работы в критический цифровой обрыв для вашего Mac, требуя не менее полного перезапуска системы для восстановления функциональности.

Основная сетевая проблема вашего Mac кроется глубоко в ядре macOS, а именно в переменной с именем `TCP_NOW`. Это 32-битное беззнаковое целое число, тщательно разработанное для отслеживания миллисекунд с момента последней загрузки системы. Оно незаметно отсчитывает время, отмечая каждый момент, когда ваш Mac остается включенным, являясь фундаментальным таймером для сетевых операций.

32-битное беззнаковое целое число по своей природе обладает конечной емкостью. Оно может хранить значения от нуля до 2^32 - 1. Для `TCP_NOW` это означает максимальное значение в 4 294 967 295 миллисекунд. Как только этот числовой порог достигается, переменная больше не может увеличиваться, инициируя фундаментальное вычислительное событие, известное как переполнение целого числа.

Это переполнение происходит ровно через 49 дней, 17 часов, 2 минуты и 47,296 секунды непрерывной работы. В этот точный момент счетчик `TCP_NOW` выполняет «обнуление». Он достигает своего максимального значения, а затем, подобно одометру, переваливающему за свою наивысшую цифру, сбрасывается обратно к нулю. Этот сброс является предсказуемой и неотъемлемой характеристикой арифметики целых чисел фиксированного размера.

Такие сбросы счетчиков являются нормальным, ожидаемым поведением в вычислениях, и большинство операционных систем надежно спроектированы для их беспроблемной обработки. Обычно системы просто корректируют свою внутреннюю логику, чтобы учесть сброс, часто путем сравнения значений, признавая при этом возможность обнуления. Однако реализация `TCP timestamps` от Apple в `macOS` содержит критический недостаток в том, как она обрабатывает это конкретное событие.

Инженеры `Photon` обнаружили, что логика сравнения ядра неверно интерпретирует сброшенное значение `TCP_NOW` после обнуления. Это неверное толкование фактически замораживает внутренние часы `TCP timestamp`, что критически важно для управления жизненным циклом сетевых соединений. Вместо адаптации система рассматривает сброшенный счетчик как аномалию.

Это предотвращает необходимую очистку соединений `TIME_WAIT`, что приводит к постепенному исчерпанию эфемеральных портов — временных идентификаторов, которые Ваш `Mac` использует для исходящих сетевых запросов. Это упущение, скрытое в ядре, превращает обычное поведение целых чисел в мощную системную уязвимость, в конечном итоге парализуя способность Вашего `Mac` устанавливать новые сетевые соединения.

Ровно через 49 дней, 17 часов, 2 минуты и 47 секунд непрерывной работы 32-битное беззнаковое целое число ядра `macOS`, `TCP_NOW`, достигает своего максимального значения. Это соответствует 2^32 миллисекундам времени безотказной работы. В этот точный момент счетчик подвергается переполнению целого числа, обнуляясь. В то время как большинство современных операционных систем изящно справляются с такими сбросами, `macOS` страдает от фундаментального недостатка в своей логике сравнения.

Неисправная реализация `TCP timestamps` ядром неверно интерпретирует этот сброс. Вместо того чтобы распознать обнуление и продолжить прогрессию `timestamp`, внутренние часы `TCP timestamp` фактически замораживаются. Этот критический просчет создает условия для каскадного сбоя в сетевом стеке.

Центральное место в этом сбое занимает TCP reaper — жизненно важный процесс ядра, отвечающий за очистку закрытых сетевых соединений. Обычно `reaper` эффективно удаляет соединения, находящиеся в состоянии TIME_WAIT, освобождая системные ресурсы и `ephemeral ports`. Эти соединения остаются ненадолго после закрытия, чтобы обеспечить надежную передачу всех сегментов данных и предотвратить проблемы с задержанными пакетами от предыдущих соединений.

Однако замороженный `timestamp` полностью сбивает с толку `reaper`. Он постоянно сравнивает `timestamps` этих закрытых соединений `TIME_WAIT` со статическими, не продвигающимися системными часами. Логически, `reaper` воспринимает эти соединения как постоянно новые или недавно активные, никогда не достигающие срока своего истечения. Он считает, что они должны оставаться открытыми, отказываясь их завершать.

Следовательно, соединения `TIME_WAIT` накапливаются бесконечно в ядре, никогда не освобождая связанные с ними `ephemeral ports`. Это не внезапный сбой системы, а скорее медленная, коварная форма паралича. `Mac` постепенно исчерпывает свой конечный пул `ephemeral ports`, обычно около 16 384.

Как только все временные порты исчерпаны, Mac больше не может устанавливать новые исходящие TCP-соединения. Хотя существующие сетевые сессии могут сохраняться, любая попытка инициировать новое соединение — будь то просмотр веб-страниц, проверка электронной почты или выполнение команды `git push` — будет просто зависать на неопределенное время. Этот тихий, ползучий сбой фактически делает сетевые возможности системы бесполезными, и все это из-за одной, упущенной из виду логической ошибки. Инженеры Photon обнаружили и подробно задокументировали этот точный механизм; для получения более подробной технической информации прочитайте Мы нашли бомбу замедленного действия в сетевом стеке TCP macOS — она детонирует ровно через 49 дней — Photon.

Установление нового сетевого соединения, будь то загрузка веб-страницы, отправка электронного письма или выполнение `git push`, фундаментально зависит от временных портов. Эти временные номера портов, динамически назначаемые операционной системой, действуют как уникальные идентификаторы для клиентской стороны исходящего TCP-соединения. Без доступного временного порта ваш Mac просто не может инициировать контакт с какой-либо внешней службой, фактически изолируя его от интернета.

Обычно, как только TCP-соединение закрывается, оно переходит в состояние `TIME_WAIT` на короткий, критически важный период. Это обеспечивает надежную доставку всех пакетов и предотвращает проблемы с задержанными сегментами от старых соединений. Выделенный процесс ядра, часто называемый сборщиком TCP-соединений, затем тщательно очищает эти соединения, освобождая связанные с ними порты для повторного использования. Этот эффективный цикл поддерживает пул доступных портов готовым для новых запросов.

Однако ошибка метки времени `TCP_NOW` фундаментально нарушает этот критически важный механизм очистки. Из-за замороженных внутренних часов меток времени TCP сборщик ядра ошибочно воспринимает все соединения в состоянии `TIME_WAIT` как постоянно активные; он просто отказывается их удалять. Это создает серьезную и коварную утечку ресурсов, поскольку каждое закрытое соединение продолжает занимать один из ограниченных 16 384 временных портов системы, никогда не возвращая его обратно в пул.

Представьте себе оживленный ресторан, где грязные столы никогда не убираются после того, как посетители закончат трапезу. Приходят новые клиенты, но поскольку каждый стол занят задерживающимися, необслуженными посетителями, новые обедающие не могут быть посажены. Несмотря на то, что ресторан кажется открытым и функциональным, в конечном итоге он становится совершенно непригодным для нового бизнеса, что отражает сетевые возможности вашего Mac.

Это исчерпание портов не является мгновенным событием на отметке в 49 дней, 17 часов и 2 минуты. Вместо этого оно проявляется как постепенное сжатие, постепенно потребляя доступные порты в течение нескольких часов. Изначально сетевые операции могут замедляться, приложения могут периодически зависать, или запросы данных могут завершаться неудачей. В конечном итоге у вашего Mac полностью закончатся порты, что сделает все новые TCP-соединения невозможными и фактически разорвет его связь с цифровым миром.

Пользователи сталкиваются с ошеломляющим каскадом сетевых сбоев после того, как их Mac превышает порог бесперебойной работы в 49 дней. Веб-браузеры останавливаются, отображая постоянные индикаторы загрузки или ошибки «connection timed out». Разработчики обнаруживают, что команды `git push` бесконечно зависают, а критически важные вызовы API из приложений просто не могут подключиться, часто возвращая досадные общие сетевые ошибки. Это не полное отключение сети; это избирательный, коварный сбой.

Вдобавок к путанице, долгоживущие сетевые соединения часто остаются работоспособными. Активная SSH session к удаленному серверу может продолжать функционировать идеально, позволяя выполнять команды и передавать вывод без прерываний. Этот резкий контраст между работающими существующими соединениями и полностью неудачными новыми попытками соединения делает первоначальную диагностику невероятно сложной для ничего не подозревающих пользователей и IT professionals.

Что еще больше вводит в заблуждение, базовые сетевые диагностические средства, такие как команда `ping`, часто сообщают о полной связности, получая ответы от удаленных хостов, как и ожидалось. Это происходит потому, что `ping` полагается на ICMP (Internet Control Message Protocol), другой уровень сетевого стека, полностью обходящий проблемный TCP layer. Работающая команда `ping` ошибочно сигнализирует о здоровой сети, направляя специалистов по устранению неполадок по непродуктивным путям.

Эти разрозненные симптомы — сбои новых TCP connections, сохранение существующих TCP connections и функциональность ICMP — создают идеальный шторм диагностического разочарования. Без предварительного знания о переполнении счетчика TCP_NOW и его специфическом влиянии на ephemeral port exhaustion, выявление первопричины становится почти невыполнимой задачей. Единственное немедленное, хотя и временное, решение — полная перезагрузка системы, сброс внутренних часов и восстановление сетевой функциональности.

Инженеры из Photon, стартапа в области AI infrastructure и developer tools, первыми выявили неуловимый сбой сети macOS. Они управляли значительным парком Mac, специально для требовательной задачи мониторинга iMessage. На этих машинах они наблюдали озадачивающую, коррелирующую со временем закономерность: примерно через 49 дней непрерывной работы сетевая функциональность постоянно ухудшалась, а затем полностью отказывала. Эта аномалия не была случайной; она проявлялась с разочаровывающей предсказуемостью.

Их путь отладки был тщательным, выходя за рамки поверхностных симптомов. Команда Photon систематически отслеживала проблему, углубляясь в исходный код XNU kernel. Они скрупулезно обнаружили ошибочную логику сравнения, связанную с 32-битным беззнаковым целым числом `TCP_NOW`, точно определив, где часы TCP timestamp фактически замерзали после их переполнения. Этот глубокий анализ подтвердил происхождение ошибки на уровне ядра, далеко от пользовательских приложений.

Последующее публичное раскрытие информации Photon оказалось решающим для оповещения широкого технологического сообщества. Их подробный технический блог-пост, выпущенный в начале 2026 года, раскрыл механику этой коварной ошибки. Эта прозрачность обеспечила четкое, действенное понимание того, почему сетевой стек Mac саморазрушался через 49,7 дней. Пользователи Apple и системные администраторы наконец-то получили объяснение ранее необъяснимых сетевых сбоев.

Что особенно важно, работа Photon включала воспроизводимый тестовый пример. Это позволило другим разработчикам и системным администраторам независимо проверить ошибку, подтвердив ее широкое влияние на macOS 10.15 (Catalina) и последующие версии. Их всесторонний анализ демистифицировал проблему, превратив ее из анекдотического разочарования в хорошо понятный, критический недостаток в операционной системе Apple. Для получения дополнительной информации о технических особенностях ошибки и более широких последствиях, macOS has a 49.7-day networking time bomb built in that only a reboot fixes — comparison operation on unreliable time value stops machines dead in their tracks | Tom's Hardware предлагает дальнейшее чтение. Этот подробный отчет подчеркнул уязвимость, присущую даже простому переполнению 32-битного целого числа.

Примечательно, что ошибка, обнаруженная инженерами Photon в macOS, перекликается с печально известным недостатком из прошлого вычислительной техники. Windows 95 и 98, как известно, страдали от аналогичного сбоя после 49,7 дня бесперебойной работы, также вызванного переполнением 32-битного таймера. Эта старая ошибка, как и текущая проблема с Mac, приводила к зависанию системы после того, как ее внутренний счетчик миллисекунд обнулялся, делая ОС не отвечающей.

Эти инциденты подчеркивают постоянную, фундаментальную проблему в информатике: надежную обработку времени. Казалось бы, простой акт подсчета времени неоднократно ставил в тупик даже самых опытных разработчиков. Вспомните глобальную панику вокруг проблемы Y2K, когда двухзначное представление года угрожало широкомасштабным сбоям систем на рубеже тысячелетий.

Сегодня для 32-битных систем Unix нависает проблема 2038 года, когда целое число `time_t`, отсчитывающее секунды с 1 января 1970 года, переполнится. Этот будущий кризис может вызвать широкомасштабные ошибки, связанные с датами, опять же из-за ограничений 32-битного целого числа. Текущее затруднительное положение вашего Mac служит ярким, современным напоминанием об этих исторических и надвигающихся уязвимостях, связанных со временем.

Несмотря на десятилетия изучения этих событий, тот же класс ошибок продолжает появляться. Реализация Apple `TCP_NOW` как 32-битного беззнакового целого числа без надежной обработки переполнения демонстрирует эту циклическую закономерность. Разработчики должны тщательно управлять пределами целых чисел и избегать магических чисел в критически важных компонентах ядра.

Это не просто программный сбой; это глубокий урок о хрупкости предположений в системном проектировании. Бесшумный выключатель вашего Mac, как и его предшественники, подчеркивает абсолютную необходимость предвидения переполнения счетчиков и реализации отказоустойчивых механизмов, особенно в коде, который лежит в основе основных сетевых функций. Анализ Better Stack и открытие Photon подтверждают этот важнейший инженерный принцип.

Обычные пользователи Mac могут в значительной степени игнорировать эту критическую сетевую ошибку. Большинство людей часто выключают или перезагружают свои машины для обновлений программного обеспечения, обеспечения стабильности системы или даже ежедневных выключений. Эти рутинные перезагрузки эффективно сбрасывают счетчик TCP_NOW, не позволяя ему когда-либо приближаться к порогу бесперебойной работы в 49 дней, 17 часов и 2 минуты, при котором проявляется проблема.

Однако угроза велика для определенных профессиональных групп. Разработчики, специалисты по данным и ИТ-администраторы, управляющие обширными парками Mac, представляют группы высокого риска. Эти специалисты часто настраивают Mac как безголовые серверы, выделенные платформы для непрерывной интеграции, сборочные машины или узлы для долгосрочного сбора данных, требующие бесперебойной работы в течение недель или месяцев.

Для этих специализированных сценариев использования поддержание длительного времени безотказной работы — это не просто почетный знак; это фундаментальное операционное требование. Бесперебойное обслуживание имеет первостепенное значение для таких задач, как компиляция больших кодовых баз, выполнение обширных наборов тестов, обработка научных симуляций или мониторинг критической инфраструктуры, где любой простой напрямую приводит к потере производительности и задержкам проекта. Неожиданный сетевой паралич после 49 дней может серьезно нарушить процессы разработки или поставить под угрозу целостность данных.

Чтобы смягчить действие этого «тихого убийцы», проактивный мониторинг времени безотказной работы системы незаменим для затронутых групп. Администраторы должны внедрить надежные механизмы оповещения, возможно, пользовательские скрипты или интегрированные решения от таких платформ, как Better Stack, для отслеживания `sysctl kern.boottime`. Настройте эти системы для выдачи срочных предупреждений задолго до 49-дневного «цифрового обрыва».

Планирование регулярных, контролируемых перезагрузок в настоящее время является единственной надежной профилактической мерой. Эти плановые отключения, выполняемые до критической отметки в 49 дней, 17 часов и 2 минуты, гарантируют сброс счетчика `TCP_NOW`, предотвращая исчерпание портов и последующее зависание сети. Эта стратегия позволяет критически важной инфраструктуре Mac продолжать функционировать без неожиданных сбоев.

Единственное общедоступное решение для сетевого сбоя macOS через 49,7 дня остается обезоруживающе простым: перезагрузка. Перезапуск машины эффективно сбрасывает счетчик `TCP_NOW`, очищая память системы от накопленных, неубранных TCP-соединений и восстанавливая часы временных меток TCP до их правильного, монотонного состояния. Это старое как мир решение мгновенно восстанавливает полную сетевую функциональность, позволяя стеку TCP обрабатывать новые соединения и правильно управлять эфемерными портами в течение еще 49 дней, 17 часов и 2 минут.

ИТ-отделы и пользователи, управляющие постоянно работающими системами Mac, особенно те, которые выполняют серверные роли или работают в средах непрерывного мониторинга, должны внедрить политику проактивной перезагрузки. Планирование перезапусков как минимум каждые 45 дней предотвращает приближение машин к критическому 49-дневному порогу. Это рутинное обслуживание, хотя и кажется базовым, оказывается необходимым для предотвращения разочаровывающих, трудно диагностируемых симптомов исчерпания портов и обеспечения бесперебойной доступности сети для критически важных служб. Невыполнение этого может привести к значительным операционным сбоям и потере производительности.

Для высокоспециализированных, критически важных систем, где перезагрузки просто невозможны, уже исследуются продвинутые обходные пути. Инженеры Photon, фирмы, которая тщательно обнаружила и задокументировала эту ошибку, по сообщениям, разрабатывают сложный патч ядра в реальном времени. Это высокотехническое решение будет направлено на манипулирование внутренним состоянием ядра — в частности, переменной `TCP_NOW` и связанной логикой сравнения — без необходимости полной перезагрузки системы. Такая возможность предлагает жизненно важную поддержку для инфраструктуры, которая абсолютно не может допустить простоя, например, для парка мониторинга iMessage, где Photon впервые обнаружил проблему.

Пользователи могут легко отслеживать текущее время работы своего Mac непосредственно из Терминала. Просто откройте приложение Терминал (находится в Applications/Utilities), введите `uptime` и нажмите Enter. Вывод покажет, сколько времени система работает с момента последней загрузки, обычно отображая дни, часы и минуты. Это простой способ отслеживать ваше приближение к 49-дневному порогу и заранее планировать необходимые перезагрузки.

Хотя Apple еще не выпустила официальный патч, бдительность и регулярные перезагрузки остаются основной защитой от этого бесшумного убийцы сети. Эта ситуация подчеркивает, что даже современные операционные системы могут скрывать фундаментальные, низкоуровневые недостатки со значительным реальным воздействием. Для получения более подробной информации об этой сложной проблеме, включая ее исторические параллели и глубокий анализ от Photon, вы можете прочитать статью Bizarre bug in macOS is a 'ticking time bomb' that takes out networking capabilities if a Mac is left on for too long | TechRadar.

Apple, несомненно, решит эту критическую проблему. Ожидайте патч на уровне ядра в предстоящем обновлении программного обеспечения macOS, непосредственно нацеленный на ошибочную логику сравнения и обработку целочисленных значений `TCP_NOW`. Это исправление, вероятно, будет распространено через стандартные обновления программного обеспечения для всех затронутых версий macOS, начиная с Catalina.

Открытие Photon наносит значительный удар по тщательно культивируемой репутации Apple в создании систем, которые «просто работают». Профессиональные и корпоративные пользователи, которые часто поддерживают парки Mac для критически важных операций, ощутят это влияние наиболее остро. Фундаментальный сбой в сети, делающий Mac бесполезным без перезагрузки, подрывает доверие к корпоративной стабильности Apple.

Это не незначительная ошибка; это цифровая пропасть, которая подрывает надежность, ожидаемую от современной операционной системы. Для таких компаний, как Photon, использующих Mac для основных служб, таких как мониторинг iMessage, 49-дневный лимит бесперебойной работы неприемлем. Apple гордится надежностью своих систем, что делает этот основной недостаток заметным пятном на ее предполагаемой надежности.

Как такая фундаментальная ошибка могла так долго сохраняться в нескольких итерациях macOS? Большинство обычных пользователей Mac просто не держат свои машины включенными непрерывно в течение 49 дней, 17 часов и 2 минут. Они часто перезагружаются для обновлений macOS, установки приложений или общего обслуживания, непреднамеренно сбрасывая счетчик `TCP_NOW`.

Эта закономерность указывает на потенциальное «слепое пятно» в методологиях обеспечения качества и тестирования Apple. Стандартные процессы контроля качества, вероятно, сосредоточены на типичных пользовательских циклах, упуская из виду экстремальные краевые случаи бесперебойной работы, с которыми естественным образом сталкиваются корпоративные развертывания, подобные Photon. Автоматизированное тестирование может не быть специально нацелено на такие длительные состояния системы, что позволяет этому «тихому убийце» оставаться незамеченным годами.

Откровение Photon служит отрезвляющим напоминанием для всей технологической индустрии. Даже в 2026 году, с изощренным оборудованием и сложными программными стеками, одно 32-битное беззнаковое целое число все еще может привести операционную систему современного технологического гиганта к полному коллапсу. Этот фундаментальный недостаток перекликается с печально известными ошибками сбоя через 49,7 дней в Windows 95 и Windows 98, доказывая, что некоторые низкоуровневые проблемы остаются вне времени. Это подчеркивает постоянную бдительность, необходимую при разработке ядра, где, казалось бы, незначительные детали могут привести к катастрофическим сбоям.

Что такое 49-дневный сетевой баг macOS?

Это ошибка на уровне ядра, при которой 32-битный таймер переполняется примерно через 49,7 дней бесперебойной работы. Это замораживает метки времени TCP и в конечном итоге препятствует установке всех новых сетевых соединений.

Как узнать, затронут ли мой Mac?

Если ваш Mac работает непрерывно более 49 дней и внезапно не может получить доступ к веб-сайтам или другим сетевым службам, вы, вероятно, затронуты. Вы можете проверить время бесперебойной работы вашей системы в приложении Terminal с помощью команды 'uptime'.

Каково постоянное решение этой ошибки Mac?

Единственное постоянное решение — это официальный патч ядра от Apple в будущем обновлении macOS. Текущее и единственное исправление на уровне пользователя — перезагружать ваш Mac по крайней мере раз в 49 дней, чтобы сбросить внутренний таймер.

В основном это затрагивает пользователей, которым требуется длительное время бесперебойной работы, таких как разработчики, исследователи или те, кто использует Mac в качестве серверов. Большинство обычных пользователей, которые регулярно выключают или перезагружают свои устройства для обновлений, никогда не столкнутся с ней.

It primarily affects users who require long uptimes, such as developers, researchers, or those using Macs as servers. Most casual users who shut down or reboot regularly for updates will never encounter it.