- macOS sufre un bug en su pila TCP que, tras 49,7 días de uptime, bloquea la creación de nuevas conexiones de red.
- El fallo se debe al desbordamiento de un contador interno de 32 bits (tcp_now) que rompe la lógica de expiración de conexiones.
- Las conexiones en TIME_WAIT se acumulan, saturan los puertos efímeros y dejan al Mac sin internet aunque responda a pings.
- Hasta que Apple publique un parche, la única solución eficaz es reiniciar periódicamente los equipos antes de alcanzar ese límite.
Si tienes un Mac que presume de potencia, estabilidad y sistema operativo fiable, seguramente pienses que estas cosas solo les pasan a otros. Sin embargo, se ha destapado un fallo muy peculiar en macOS que puede dejar tu equipo completamente sin internet tras un tiempo de uso continuado sin reiniciar. No es un problema del router, ni de la WiFi, ni de tu operador: el origen está en las tripas del propio sistema.
Este comportamiento viene de un bug a nivel muy bajo, dentro del kernel y de la pila TCP/IP de macOS, que provoca que, después de 49 días, 17 horas, 2 minutos y 47 segundos de funcionamiento ininterrumpido, el Mac deje de ser capaz de establecer nuevas conexiones de red. El equipo sigue encendido, responde a pings y aparenta normalidad, pero las aplicaciones dejan de poder hablar con internet y la única solución práctica, por ahora, es reiniciar.
Apple, macOS y la cara menos visible de un sistema muy pulido
Apple lleva desde los años 70 construyendo su reputación como fabricante de dispositivos de gama alta con sistemas estables y seguros. Empezó en un garaje vendiendo ordenadores montados casi a mano, dio el salto con el histórico Macintosh de 1984 —uno de los primeros con interfaz gráfica controlada con ratón y teclado— y ha ido evolucionando hasta los actuales MacBook, iMac, Mac mini o Mac Studio.
El sistema clásico de la compañía se cerró con Mac OS 9 como última gran versión de aquella etapa. A partir de 2001, con Mac OS X 10.0, se produjo un cambio profundo: un sistema moderno con base Unix, mucho más robusto a nivel interno. Desde entonces, las versiones han ido sucediéndose a buen ritmo, hasta llegar a las ramas actuales de macOS, que siguen afinando rendimiento, seguridad y experiencia de usuario.
La imagen que Apple ha sabido construir es la de un entorno donde todo funciona “sin pensar”, con menos errores que sus rivales directos como Windows o Android. No obstante, por muy pulido que esté un sistema, sigue siendo software, y como tal, no está libre de bugs. El fallo que provoca la pérdida de conexión tras 49,7 días es un ejemplo llamativo de cómo un detalle aparentemente minúsculo en el código puede generar un efecto en cadena.
En este caso, además, no se trata de un problema gráfico o de una app concreta, sino de un error que afecta al corazón de la comunicación en red de macOS, algo mucho más delicado, sobre todo en escenarios profesionales donde los equipos se mantienen encendidos durante semanas.
El bug de los 49,7 días: qué pasa exactamente en tu Mac
Un grupo de investigadores de Photon, una empresa estadounidense que se dedica a integrar agentes de IA en aplicaciones de mensajería, se topó con este bug mientras monitorizaba servicios de iMessage con un conjunto de ordenadores macOS. De repente, varias máquinas dejaron de aceptar conexiones de red nuevas, aunque seguían respondiendo a los pings sin ningún problema.
Lo desconcertante era que, a nivel superficial, el sistema parecía estar bien: la red seguía “viva” para ciertas comprobaciones, no se mostraban errores claros y, sin embargo, las aplicaciones no podían establecer conexiones nuevas ni comunicarse con servicios externos. Solo tras reiniciar las máquinas el servicio se restauraba por completo.
El equipo de Photon decidió investigar más a fondo y observó que otros Mac del mismo grupo se acercaban a una cifra muy concreta de tiempo de actividad (uptime): justo 49,7 días, o lo que es lo mismo, 49 días, 17 horas, 2 minutos y 47 segundos. Cuando alcanzaban ese punto, el comportamiento se repetía: el equipo dejaba de crear conexiones, el software se quedaba “colgado” en la parte de red y no había mensajes de error visibles en la interfaz.
Tras correlacionar estos tiempos y revisar el comportamiento del sistema, concluyeron que el fallo estaba vinculado a un contador interno que mide el tiempo desde que arrancó el sistema. Ese contador suma milisegundos de forma continua desde el momento del encendido, y aquí es donde entra en juego la parte matemática del bug.
El contador tcp_now, el límite de 32 bits y el overflow fatídico
Dentro del kernel de macOS, en el subsistema de red, existe un contador llamado tcp_now, que actúa como referencia de tiempo para las operaciones de la pila TCP. Este contador está implementado como un entero sin signo de 32 bits (unsigned int), lo que significa que el valor máximo que puede representar es 4.294.967.295.
Cuando conviertes ese valor máximo a milisegundos de tiempo real, obtienes exactamente esos 49 días, 17 horas, 2 minutos y 47 segundos que aparecen en el bug. Al alcanzar dicho límite, lo esperado sería que el contador volviera a cero y todo siguiera funcionando con normalidad, ajustando bien las operaciones que dependen del tiempo.
Lo que se ha descubierto es que en macOS esa vuelta al inicio no se gestiona correctamente: el contador no se resetea de forma segura, sino que “sigue subiendo” lógicamente más allá de su tope real, lo que en términos de representación implica que se produce un overflow y el valor deja de tener sentido para la lógica de TCP. Es como si el reloj interno de esa parte de la red se congelara o empezara a dar lecturas incoherentes.
El resultado es que el sistema pierde la referencia temporal que utiliza para tareas tan importantes como limpiar conexiones antiguas, gestionar expiraciones y controlar estados internos. A partir de ese instante, las decisiones que toma el kernel respecto a qué conexiones deben mantenerse o cerrarse dejan de ser correctas, pero el usuario no ve una alerta directa: simplemente nota que internet empieza a “morir”.
TIME_WAIT, puertos efímeros y el colapso silencioso de la red
Para entender por qué este fallo termina dejando a tu Mac sin internet, hace falta revisar cómo funciona una parte importante de TCP: el estado TIME_WAIT. Cuando una conexión TCP se cierra, no desaparece de inmediato; entra en un estado de espera durante un tiempo, normalmente unos minutos, para asegurarse de que todos los paquetes pendientes se hayan recibido o descartado correctamente.
En condiciones normales, macOS va revisando periódicamente esas conexiones en TIME_WAIT y las va eliminando cuando considera que ya es seguro hacerlo. Así se libera espacio en la tabla de conexiones del kernel y se permite reutilizar los llamados puertos efímeros (ephemeral ports), que son los que usa el sistema para las conexiones salientes.
El problema aparece cuando el contador tcp_now se desborda y el reloj interno de TCP deja de avanzar de forma coherente. En ese momento, las conexiones que deberían expirar en TIME_WAIT nunca llegan a marcarse como “caducadas”. El sistema cree que aún no ha pasado el tiempo necesario, por lo que las mantiene vivas indefinidamente, aunque en realidad ya están cerradas.
Estas entradas se van acumulando en la tabla de conexiones hasta que los puertos efímeros —en macOS suelen abarcar un rango de algo más de 16.000 puertos disponibles— se agotan. Cuando todos esos puertos están ocupados por conexiones que jamás terminan de expirar, el kernel no puede abrir ninguna conexión TCP nueva.
A efectos prácticos, eso significa que tu Mac deja de poder iniciar tráfico de red: no puedes abrir webs, las APIs fallan, SSH deja de funcionar y un montón de servicios que dependen de internet comienzan a devolver errores. Curiosamente, el ping (ICMP) sí puede seguir funcionando, por lo que desde fuera puede dar la engañosa impresión de que la máquina “está ahí” y la red va bien.
Este escenario es especialmente crítico en ordenadores que se usan como servidores, nodos de CI/CD, máquinas de desarrollo o infraestructuras que se dejan encendidas durante semanas o meses. En esos casos, llegar al límite de los 49,7 días es cuestión de tiempo, y cuando el bug se activa, la caída es total y sin avisar.
Un viejo conocido: el bug de los 49,7 días en Windows 95 y 98
Lo más curioso del asunto es que esta clase de fallo no es nueva. En la época de Windows 95 y Windows 98 ya se detectó un bug muy similar. Aquellos sistemas utilizaban un contador de tiempo basado en enteros de 32 bits sin signo para medir el uptime en milisegundos. Pasado el mismo umbral de 49,7 días se producía un desbordamiento que podía provocar cuelgues y comportamientos extraños.
En el caso de Microsoft, el problema se rastreó, entre otros componentes, hasta el driver VTDAPI.VXD, que usaba ese contador de forma directa. De nuevo, 2^32 milisegundos equivalían a esos 49,71 días, y cuando se llegaba al límite, el sistema ya no gestionaba bien el tiempo. La solución definitiva llegó con Windows XP, que corrigió este tipo de errores de diseño.
Estos bugs de overflow de 32 bits forman parte de una familia bien conocida de errores de tiempo. El famoso problema del año 2038 es otro ejemplo: en muchos sistemas Unix antiguos, el tiempo se almacena como un entero con signo de 32 bits que representa segundos desde 1970. Al llegar a una fecha concreta de 2038, ese contador se desbordará si no se ha actualizado a 64 bits.
En macOS, el patrón es el mismo: un contador de tiempo con un tamaño de dato limitado al que no se le ha aplicado una lógica de gestión o actualización adecuada una vez alcanza su tope. El efecto se manifiesta décadas después de que la industria ya haya visto problemas calcados, pero adaptados ahora al contexto de la pila TCP en el kernel XNU.
Cómo se manifiesta el error en el día a día: del usuario doméstico al entorno profesional
Este bug no afecta de igual manera a todo el mundo. Muchos usuarios apagan o reinician su MacBook, iMac o Mac mini con relativa frecuencia, ya sea porque instalan actualizaciones de sistema, por costumbre o porque lo usan de forma más ocasional. En esos casos, es poco probable que lleguen a los 49,7 días de uptime seguidos.
Sin embargo, el uso típico de un portátil actual juega a favor del problema. Mucha gente simplemente cierra la tapa del MacBook y lo deja en reposo, sin apagarlo jamás. Se despierta al abrir la pantalla, sigue donde lo dejaste y el contador interno continúa sumando tiempo, aunque el equipo esté durmiendo parte del día.
Así, no es extraño que un porcentaje de usuarios llegue sin darse cuenta a ese punto crítico de casi 50 días. Lo que empiezan a notar entonces son fallos aparentemente aleatorios: webs que no cargan, apps que se quedan pensando, servicios en la nube que se desconectan y un WiFi que parece ir y venir sin explicación.
Es muy típico pensar que el problema está en el router o en la red doméstica, sobre todo si, de vez en cuando, el icono de la WiFi desaparece un instante o hay cortes breves. Sin embargo, al comprobar otros dispositivos en la misma red —móviles, otros ordenadores, tablets— se ve que todo funciona bien fuera del Mac afectado, lo que delata que el origen está en el propio macOS.
En entornos profesionales, el problema es mucho más evidente. Servidores de CI/CD, nodos de clúster basados en Mac mini, estaciones de trabajo de desarrollo o productos desplegados sobre macOS que necesitan estar siempre activos pueden pasar largos periodos sin reiniciarse. En el minuto exacto en que alcanzan los 49,7 días de uptime, dejan de poder establecer nuevas conexiones TCP, lo que significa que pipelines, servicios web, integraciones o agentes de IA se quedan directamente inoperativos.
Casos reales: del Mac que cae de internet varias veces al día a OpenClaw
Más allá del descubrimiento de Photon, hay testimonios de usuarios que cuentan situaciones en las que su Mac, con versiones como macOS 15.7.2 o 15.7.3, se queda sin conexión varias veces al día y solo consiguen recuperar internet reiniciando el equipo. En esos casos, se observa que:
- La señal WiFi es buena y el Mac está conectado al SSID correcto.
- No hay acceso a internet con ningún navegador ni aplicación.
- Apagar y encender la WiFi del Mac no soluciona nada.
- En la misma red, otros equipos —incluidos otros Mac— no sufren el problema.
- Ese mismo Mac, en otras redes, funciona con normalidad.
Aunque estos casos pueden deberse a varias causas, el patrón de que solo reiniciando se recupere la conectividad encaja muy bien con lo que se ha visto en el bug del contador de 32 bits, sobre todo si la máquina lleva mucho tiempo sin un reinicio completo del sistema.
En el mundo de las empresas tecnológicas, el ejemplo más documentado es el de Photon Codes y su plataforma OpenClaw, un sistema de agentes de IA desplegable en macOS. Sus nodos se quedaban sin red tras semanas en producción, y el problema se manifestaba como errores misteriosos en la capa de aplicación, sin logs claros.
Solo cuando correlacionaron el tiempo de actividad de las máquinas con los fallos y reprodujeron el escenario esperaron a que el sistema llegase a los 49,7 días (o aceleraron el contador mediante técnicas de debugging del kernel) consiguieron ver que el error era perfectamente reproducible y que la causa estaba en el overflow del contador interno de tiempo.
El proceso de análisis implicó revisar el código abierto de XNU, el kernel de Apple, y rastrear cómo el desbordamiento de ese entero de 32 bits afectaba a los temporizadores de TCP, a la gestión del estado TIME_WAIT y a la limpieza de conexiones. Es un trabajo de depuración a muy bajo nivel que no suele verse a menudo fuera de los equipos de sistemas operativos de grandes compañías.
Por qué reiniciar “arregla” el problema y qué se puede hacer mientras
La razón por la que un simple reinicio devuelve todo a la normalidad es bastante directa: al apagar y volver a encender el Mac, el contador interno de tiempo vuelve a cero, se limpian todas las conexiones abiertas y TIME_WAIT en la tabla del kernel y se restablece el estado de los puertos efímeros.
Eso sí, si vuelves a dejar el equipo funcionando sin interrupción otros 49,7 días, el problema reaparecerá tal cual, ya que el bug está en la lógica interna de la pila TCP y no se ha corregido de raíz. De ahí que, hasta que Apple publique un parche específico, la única solución efectiva sea evitar llegar a ese límite de uptime.
Para minimizar riesgos, se plantean varias estrategias prácticas:
- Programar reinicios periódicos cada 30-40 días en máquinas que estén siempre encendidas (por ejemplo, usando LaunchDaemons y launchd en macOS).
- Monitorizar el uptime del sistema y generar alertas cuando se acerque al umbral crítico, para organizar un reinicio controlado.
- Vigilar el número de conexiones en estado TIME_WAIT con herramientas como
netstat; si el conteo solo sube y no baja, es mala señal. - En infraestructuras serias, valorar mover ciertas cargas a servidores Linux, reservando macOS para lo estrictamente necesario (por ejemplo, builds nativas para iOS o macOS).
Algunos desarrolladores también sugieren ajustar parámetros de TCP mediante sysctl para reducir el tiempo de TIME_WAIT o ampliar el rango de puertos efímeros, pero son medidas paliativas: ayudan a aguantar algo más, aunque no solucionan el origen, que es el overflow del contador.
A día de hoy, la opción sencilla para la mayoría de usuarios es adquirir el hábito de reiniciar el Mac de vez en cuando, aunque sea una vez al mes. No solo por este bug concreto, sino porque así se resetean muchos procesos, se libera memoria y se evitan otros pequeños fallos que se acumulan con el tiempo.
¿A qué modelos y versiones de macOS afecta este fallo?
Todo apunta a que el bug no está ligado a un modelo de hardware concreto, sino a la implementación del stack TCP/IP en el kernel de macOS. Es decir, puede afectar tanto a equipos con procesador Intel como a los más recientes con chips Apple Silicon (M1, M2, M3…), siempre que corran versiones de macOS con la misma lógica interna del contador tcp_now.
Según la información compartida por Photon y otros análisis, se habría reproducido en todas las versiones actuales de macOS probadas en sus entornos, lo que incluye desde equipos relativamente antiguos hasta máquinas muy recientes funcionando con ramas modernas del sistema.
Como el problema reside en una parte central del kernel, la corrección requeriría que Apple revisara el uso de enteros de 32 bits para ese contador de tiempo, migrando probablemente a 64 bits o modificando la lógica que gestiona las expiraciones de las conexiones cuando se produce el desbordamiento.
Este tipo de cambios no son triviales: exigen revisar impactos colaterales, probar a fondo y asegurarse de que no se rompe nada más en el camino. Por eso, aunque el bug ya se ha reportado, no hay, por ahora, constancia pública de un parche definitivo incorporado a una actualización concreta de macOS.
Mientras no llegue esa corrección oficial, la recomendación de los expertos es tratar a los Mac como servidores “frágiles” en cuanto a uptime: mejor reiniciar de manera programada que confiar en que podrán aguantar meses sin apagarse, sobre todo si dependen de una red estable para servicios críticos.
En definitiva, lo que podría parecer una simple anécdota de laboratorio se convierte en un factor real de riesgo para infraestructuras basadas en macOS y explica muchos casos de equipos que, después de semanas de uso sin reiniciar, empiezan a tener un comportamiento errático en todo lo que toca a internet, hasta que un reinicio “mágico” lo arregla todo por unas cuantas semanas más.
