En los últimos meses ha salido a la luz un fallo bastante peculiar en macOS que, pese a no afectar normalmente al usuario de a pie, ha puesto en alerta a desarrolladores, administradores de sistemas y a cualquiera que use un Mac como servidor, como en guías para solucionar los errores más comunes de macOS Sequoia. Tras algo menos de 50 días encendido sin reiniciar, algunos equipos dejan de poder abrir nuevas conexiones a internet.
Este problema, bautizado coloquialmente como el “error de internet de 49 días de macOS”, no es una simple caída de la Wi‑Fi ni un corte puntual del router. Se trata de un bug profundo en la pila de red del sistema operativo, que hace que el Mac parezca conectado pero, en la práctica, se quede aislado para cualquier comunicación nueva.
De dónde sale el bug: un contador de 32 bits al límite
La investigación, liderada por el equipo de Photon (empresa centrada en integrar agentes de IA en servicios de mensajería), ha desvelado que el origen del fallo está en la forma en que macOS mide el tiempo dentro de su sistema TCP. El núcleo XNU utiliza una variable interna llamada tcp_now para llevar la cuenta del tiempo en milisegundos desde que se arranca el sistema. Un fallo similar de kernel se documentó en un error de ejecución de código en macOS Big Sur y anteriores.
Este contador está implementado como un entero sin signo de 32 bits, lo que implica un valor máximo de 4.294.967.295. Si se expresa esa cifra en milisegundos, la cuenta cuadra casi al milímetro con el comportamiento observado:
4.294.967.295 ms ≈ 49 días, 17 horas, 2 minutos y 47 segundos.
Al llegar a ese umbral, el contador alcanza su tope y se desborda. En un diseño ideal, el sistema debería gestionar correctamente ese reinicio a cero, pero lo que se ha detectado es que, en macOS, la lógica de temporización de TCP se rompe en ese punto. A efectos prácticos, el reloj interno que se usa para decidir cuándo caducan ciertas conexiones se queda “congelado” o empieza a hacer comparaciones de tiempo incorrectas.
Los investigadores de Photon se toparon con el problema mientras usaban una granja de Mac mini y Mac Studio para monitorizar servicios de iMessage y desplegar su plataforma OpenClaw. Varias máquinas, tras semanas encendidas, dejaron de aceptar conexiones nuevas sin previo aviso, aunque seguían respondiendo a peticiones de ping y aparentaban estar en buen estado.
Qué se estropea exactamente en la red de macOS
Lo más llamativo de este bug es que no produce la típica desconexión total en la que el icono de la Wi‑Fi desaparece o el sistema indica que no hay red. De hecho, las conexiones ya establecidas pueden seguir funcionando con normalidad durante un tiempo.
El fallo se manifiesta en la gestión de la nueva actividad de red. Una vez que el contador interno se desborda, macOS empieza a calcular mal los tiempos asociados a las conexiones TCP cerradas, especialmente las que se encuentran en el estado TIME_WAIT, que es la fase en la que el sistema espera un poco antes de dar por finalizada del todo una comunicación.
En condiciones normales, el kernel va limpiando periódicamente esas conexiones finalizadas para liberar puertos efímeros y recursos. Sin embargo, cuando el reloj TCP deja de avanzar como es debido, el sistema concluye una y otra vez que esas conexiones “todavía no han caducado” y no las retira.
El resultado es una acumulación progresiva de entradas en la tabla de conexiones hasta que se agotan los puertos disponibles para nuevas comunicaciones TCP. A partir de ahí, cualquier intento de abrir una conexión nueva (una página web, una API, un túnel SSH, etc.) empieza a fallar, mientras que otras funciones como el ping (ICMP) pueden seguir respondiendo, lo que complica el diagnóstico.
En la práctica, el Mac sigue aparentemente conectado a la red local, responde a pruebas básicas y hasta puede mantener sesiones abiertas que ya estuvieran en marcha, pero es incapaz de iniciar conexiones frescas. Para un servicio en producción, esto se traduce en interrupciones silenciosas, tiempos de espera y errores intermitentes en aplicaciones que dependen de internet.
Un caso clásico de overflow que recuerda a Windows 95
El patrón que se ha detectado en macOS no es nuevo en la historia de la informática. Se trata de un desbordamiento de un contador de tiempo de 32 bits, una categoría de errores bastante conocida y que ya dio que hablar en otros sistemas.
En los años noventa, Windows 95 y Windows 98 sufrían un fallo similar: tras aproximadamente 49,7 días de funcionamiento, el sistema empezaba a comportarse de forma errática debido a cómo medían el tiempo en milisegundos dentro de ciertos controladores. También aquí la matemática era la misma: un entero de 32 bits midiendo milisegundos acaba por dar problemas justo en esa franja temporal.
Algo parecido ocurre con otros bugs de tiempo, como el famoso problema del año 2038 en sistemas Unix de 32 bits, donde el contador de segundos desde 1970 se desborda y genera fechas incorrectas. En el caso de macOS, el impacto se concentra en el subsistema TCP, que no gestiona bien el reset del contador tcp_now y deja conexiones “fantasma” ocupando recursos.
Los análisis publicados apuntan además a una implementación defectuosa del estándar TCP (con referencias al RFC 7323) por parte de Apple, al menos en lo que respecta al manejo de temporizadores y la limpieza de conexiones cada cierto intervalo. Un detalle aparentemente menor en el código, pero con consecuencias importantes tras semanas de uso continuado.
Quiénes son los más afectados: de servidores Mac a portátiles en reposo
En un uso doméstico típico en España o Europa, en el que se apaga el ordenador con cierta regularidad o se instalan actualizaciones que obligan a reiniciar, no es habitual alcanzar esos 49,7 días de tiempo de actividad. Por eso muchos usuarios jamás se toparán con este bug.
Sin embargo, la situación cambia cuando se habla de entornos profesionales y máquinas siempre encendidas. Aquí entran en juego varios perfiles de riesgo:
- Mac mini y Mac Studio usados como servidores, muy comunes en estudios de desarrollo de apps, agencias creativas o empresas que necesitan macOS para compilar software de Apple.
- Equipos de CI/CD y automatización, donde runners de integración continua corren sobre hardware Apple durante semanas sin apagarse.
- Estaciones de trabajo que rara vez se reinician, por ejemplo en departamentos de ingeniería, edición de vídeo o audio profesional.
- Portátiles como el MacBook Air o los MacBook Pro que se usan a base de cerrar y abrir la tapa, entrando en reposo pero sin apagarse nunca.
En muchos hogares y oficinas es habitual simplemente bajar la tapa del portátil y seguir trabajando al día siguiente, sin pasar por un reinicio explícito. Si a esto se suma la costumbre de posponer actualizaciones de sistema, no es tan raro que un Mac acumule más de un mes y medio de uptime sin que nadie se dé cuenta.
Varios testimonios recogidos por desarrolladores apuntan precisamente a este patrón: tras semanas de uso, un MacBook que parecía ir “cada vez más raro” empieza a dar errores de conexión, ciertas páginas no cargan, algunas apps se quedan colgadas al intentar acceder a internet y el usuario culpa al router o a la operadora, cuando el origen está en el contador interno de macOS.
Síntomas habituales: parece que hay red, pero nada nuevo conecta
Quien se tropieza con este error suele describir una situación bastante desconcertante. Por un lado, el Mac sigue mostrando que está conectado por Wi‑Fi o Ethernet, responde a pings y, en muchos casos, algunas conexiones ya establecidas continúan vivas.
Pero al mismo tiempo, empiezan a fallar operaciones tan básicas como abrir una web, conectar por SSH a otro servidor, sincronizar con la nube o hacer llamadas a APIs. Las aplicaciones muestran mensajes de tiempo de espera agotado, las descargas no arrancan y determinados servicios dejan de recibir tráfico sin que aparezca un error claro a nivel de sistema.
En servidores y entornos de producción, esto se traduce en interrupciones de servicio en plataformas web, colas de trabajos que dejan de procesarse, integraciones que no responden y pipelines de CI/CD que fallan al intentar conectarse a repositorios, bases de datos o endpoints externos.
Algunas herramientas de monitorización han permitido ver qué ocurre por debajo: justo después del momento crítico de los 49 días, el número de conexiones en estado TIME_WAIT empieza a crecer sin parar, mientras que el rango de puertos efímeros (que en macOS ronda las 16.000 opciones) se va llenando hasta quedar totalmente “ocupado” por conexiones que nunca caducan.
Por eso, aunque el sistema no muestre una alerta evidente, lo que está pasando es que ya no queda ningún puerto disponible para abrir conexiones TCP nuevas. La red no está caída, pero la pila TCP está, de facto, saturada.
Soluciones actuales: reiniciar y prevenir antes de llegar al límite
A día de hoy, y según coinciden tanto Photon como otros desarrolladores que han analizado el problema, la única solución realmente fiable es reiniciar por completo el Mac. Ese reinicio resetea el contador tcp_now, limpia las conexiones acumuladas y devuelve la red a la normalidad.
Esto tiene una consecuencia clara para cualquiera que gestione infraestructura sobre macOS, ya sea en un pequeño estudio de desarrollo, en una pyme o en un centro de datos: no conviene dejar que un Mac supere los 49 días de uptime sin un apagado o reinicio de por medio.
Entre las medidas de mitigación que se están recomendando en entornos profesionales en Europa están:
- Programar reinicios periódicos (por ejemplo, cada 30 o 40 días) en servidores Mac mini, Mac Studio o nodos de CI.
- Configurar alertas de tiempo de actividad para recibir avisos cuando un equipo se acerca a los 40 días encendido.
- Vigilar el número de conexiones TIME_WAIT y el uso de puertos efímeros mediante herramientas de red, sobre todo en máquinas críticas.
- En arquitecturas mixtas, considerar mover cargas de servidor a Linux cuando no sea imprescindible usar macOS, reservando los Mac para tareas concretas como compilación de apps o pruebas específicas.
En el caso de usuarios particulares con MacBook, iMac o Mac mini de sobremesa, el consejo es mucho más sencillo: reiniciar el equipo de vez en cuando. Un reinicio mensual suele ser más que suficiente para evitar tropezar con este límite, y además ayuda a limpiar procesos en segundo plano y pequeñas fugas de memoria que se acumulan con el tiempo.
¿Es un problema de seguridad o de estabilidad?
Por ahora, el consenso entre los expertos es que el error de los 49 días en macOS es principalmente un problema de estabilidad y disponibilidad, no una vulnerabilidad explotable en el sentido clásico. No hay indicios de que un atacante pueda aprovecharse directamente de este bug para ejecutar código o tomar el control de un sistema.
Eso no quita que tenga impacto en la continuidad de servicio. Para empresas que operan servicios 24/7 sobre Mac, una caída silenciosa de las conexiones nuevas puede suponer tiempo de inactividad, pérdida de datos en tránsito o interrupciones en procesos críticos.
En cierto modo, el comportamiento se asemeja más a una condición de denegación de servicio accidental que a una brecha de seguridad. El sistema, por sí solo, entra en un estado en el que deja de aceptar conexiones, con el consiguiente impacto operativo.
Preguntas frecuentes sobre el error de internet de 49 días
¿macOS se queda sin internet después de 49 días encendido?
Lo que ocurre no es una desconexión total, sino que las nuevas conexiones TCP empiezan a fallar. El sistema puede seguir pareciendo conectado, responder a pings y mantener algunas sesiones, pero deja de poder abrir conexiones nuevas a servicios, webs o APIs.
¿Afecta a todas las versiones de macOS y a todos los Macs?
Los análisis apuntan a que el bug está presente en todas las versiones modernas de macOS y, por tanto, en cualquier equipo que ejecute el sistema: MacBook, iMac, Mac mini o Mac Studio. El factor clave no es el modelo, sino el tiempo que lleva encendido sin reiniciar.
¿Es un fallo confirmado oficialmente por Apple?
El problema ha sido documentado por desarrolladores y administradores de sistemas, y reportado a Apple, pero no existe todavía una descripción oficial detallada en la documentación pública del fabricante ni constancia de un parche específico lanzado para este caso.
¿Cómo puedo evitar que mi Mac se quede sin nuevas conexiones de red?
La medida más eficaz es muy simple: reiniciar el Mac con regularidad. En el caso de servidores o equipos críticos, lo recomendable es programar reinicios antes de alcanzar los 49 días de uptime. Para usuarios domésticos, bastan reinicios ocasionales, por ejemplo al instalar actualizaciones del sistema.
Todo apunta a que este bug, aunque poco visible para el usuario corriente, tiene un impacto claro en infraestructuras que dependen de macOS y permanecen encendidas durante largos periodos. Hasta que Apple implemente un arreglo definitivo a nivel de kernel, controlar el tiempo de actividad y programar reinicios periódicos se ha convertido en una práctica casi obligada para quienes usan Macs como servidores o herramientas de trabajo continuas.
