Apple se ha ganado fama de ofrecer ordenadores estables, seguros y con muy buen rendimiento, pero ni macOS es infalible. Un grupo de investigadores ha destapado un fallo bastante incómodo: si un Mac permanece encendido sin reiniciarse durante unos 49,7 días seguidos, puede perder la capacidad de abrir nuevas conexiones a Internet.
Este bug afecta a la pila de red TCP/IP de macOS y se produce tanto en sobremesa como en portátiles, desde Mac mini y Mac Studio hasta MacBook Air o MacBook Pro. El equipo sigue pareciendo conectado, responde a ping e incluso mantiene algunas sesiones, pero deja de establecer conexiones nuevas, algo especialmente delicado en servidores, equipos de desarrollo y entornos profesionales en Europa donde los Mac se usan como máquinas siempre encendidas.
Un fallo que se dispara tras 49 días, 17 horas, 2 minutos y 47 segundos
El hallazgo llega de la mano de Photon, una empresa estadounidense que integra agentes de IA en servicios de mensajería y que utiliza granjas de Mac para monitorizar iMessage y desplegar su plataforma de agentes OpenClaw. Al cabo de varias semanas de actividad continua, algunos de sus Mac mini y Mac Studio dejaron de aceptar conexiones de red de repente, aunque seguían respondiendo a las comprobaciones básicas.
Al investigar, detectaron que el problema aparecía siempre al alcanzar un uptime muy concreto: 49 días, 17 horas, 2 minutos y 47 segundos desde el último arranque. Justo en ese instante, los equipos que estaban creando nuevas conexiones constantemente simplemente dejaban de hacerlo sin mostrar ningún error visible. Un reinicio devolvía todo a la normalidad, pero el fallo reaparecía tras otros 49,7 días encendido.
Lo llamativo es que el bug no depende de la versión concreta de macOS: según los análisis publicados, afecta a la línea moderna basada en Unix, desde versiones recientes hasta macOS actuales. Da igual que sea un MacBook de última generación o un iMac más veterano: lo que importa es el tiempo que lleva encendido sin reiniciar.
Para muchos usuarios domésticos en España y el resto de Europa, parece algo poco probable, pero la realidad es que es muy fácil acumular semanas de actividad si solo cierras la tapa del portátil, lo pones en reposo o pospones las actualizaciones. Millones de personas apenas apagan su MacBook, y ahí es donde el error puede dar la cara.
El origen: un contador TCP interno de 32 bits que se desborda
La raíz del problema está en cómo macOS mide el tiempo dentro de su sistema de red. El kernel XNU utiliza una variable interna llamada tcp_now para llevar la cuenta del tiempo en milisegundos desde que el sistema se pone en marcha. Este valor se almacena como un entero sin signo de 32 bits, lo que significa que solo puede llegar hasta 4.294.967.295.
Si se traduce esa cifra a tiempo real, las matemáticas encajan con lo que se ha observado en las pruebas:
4.294.967.295 ms ≈ 49 días, 17 horas, 2 minutos y 47 segundos
Cuando el contador alcanza su valor máximo, debería gestionarse bien el retorno a cero, pero en macOS el comportamiento no es el esperado. Según Photon y otros desarrolladores, el bug provoca que el reloj interno de TCP se «congele» o empiece a hacer comparaciones de tiempo erróneas, de forma que la lógica que decide cuándo caducan las conexiones deja de funcionar correctamente.
Este contador se usa para múltiples tareas, entre ellas limpiar conexiones antiguas y gestionar los temporizadores asociados al protocolo. Al desbordarse (overflow) el entero de 32 bits, la pila TCP pierde la referencia temporal y deja de considerar vencidas ciertas comunicaciones, aunque en realidad ya han terminado hace rato.
Los análisis apuntan a una implementación defectuosa del estándar TCP, en particular del RFC 7323, que regula, entre otros aspectos, la gestión de temporizadores y las extensiones para alto rendimiento. En lugar de reciclar correctamente el contador y seguir limpiando conexiones cada cierto intervalo, el sistema mantiene vivas entradas que ya no deberían estar ahí.
Qué se rompe en la práctica: TIME_WAIT, puertos efímeros y nuevas conexiones
Para entender el impacto real del bug, hay que fijarse en el estado TIME_WAIT del protocolo TCP. Cuando una conexión se cierra, no desaparece de golpe: entra en esta fase de espera durante un tiempo (normalmente unos minutos) para asegurarse de que no quedan paquetes colgando y se evita confundir comunicaciones antiguas con nuevas.
En condiciones normales, el kernel de macOS va eliminando periódicamente las conexiones en TIME_WAIT que ya han cumplido su plazo, liberando así recursos y, sobre todo, los llamados puertos efímeros, que son los puertos temporales que el sistema utiliza para iniciar conexiones salientes.
Cuando el reloj interno asociado a tcp_now se desborda, esta limpieza deja de hacerse bien. El sistema pasa a creer que esas conexiones cerradas no han llegado aún a su tiempo de expiración, por lo que no las borra. Se van acumulando entradas en la tabla de conexiones, ocupando sockets y puertos de manera indefinida.
macOS suele disponer de unos 16.000 puertos efímeros en su rango por defecto (aproximadamente entre los puertos 49.152 y 65.535). Una vez que estos puertos quedan copados por conexiones en TIME_WAIT que nunca caducan, el sistema es incapaz de abrir nuevas conexiones TCP. A partir de ahí aparecen los síntomas: errores al conectar con webs, APIs, bases de datos, túneles SSH y cualquier servicio que dependa de TCP.
Lo curioso es que, en paralelo, otras funciones como el ping (ICMP) pueden seguir funcionando. Por eso, al hacer una comprobación rápida, parece que el Mac está en línea: responde a la red local, puede mantener alguna sesión ya abierta y el icono de Wi-Fi o Ethernet no muestra problemas, pero a efectos prácticos no hay forma de iniciar comunicaciones nuevas.
Un viejo conocido: el «bug de los 49,7 días» y otros errores de tiempo
Lo que está ocurriendo en macOS no es un fenómeno aislado. Se trata de un caso clásico de desbordamiento de enteros de 32 bits en contadores de tiempo, una familia de errores que ha dado guerra en la industria del software durante décadas.
En los años 90, Windows 95 y Windows 98 sufrían un bug casi idéntico: tras aproximadamente 49,7 días encendidos, el sistema empezaba a fallar por culpa de un contador de milisegundos de 32 bits utilizado por ciertos controladores. El cálculo era el mismo: 2³² milisegundos equivalen a esos 49,7 días fatídicos. Microsoft acabó corrigiendo el problema en versiones posteriores como Windows XP.
También se han visto variantes de este patrón con otros intervalos: en algunos sistemas Windows más modernos, contadores en fracciones de segundo provocaban fallos similares tras 497 días de uptime, y el famoso problema del año 2038 en Unix de 32 bits responde al mismo concepto, en este caso con segundos desde 1970 que se desbordan y generan fechas imposibles.
En macOS, el comportamiento detectado guarda un claro paralelismo. El contador tcp_now, al alcanzar su tope de 32 bits, no se recicla de forma segura y termina afectando a la gestión de tiempos del subsistema TCP. Un pequeño detalle en el diseño de la pila de red que, pasado mes y medio de funcionamiento ininterrumpido, se traduce en un fallo crítico para cualquier infraestructura que dependa de Internet.
Para los equipos de ingeniería y operaciones, el caso se ha convertido ya en un ejemplo de manual: un bug de tiempo silencioso, difícil de diagnosticar sin contexto y capaz de tirar abajo servicios enteros sin generar apenas alarmas en la capa de aplicación.
Quién lo nota más: de servidores macOS a portátiles que nunca se apagan
En el día a día de un usuario normal, que apaga su Mac con cierta frecuencia o instala actualizaciones de sistema, el bug probablemente pase desapercibido. Sin embargo, en entornos profesionales de España y Europa donde macOS se usa como sistema de larga duración, el impacto puede ser serio.
Entre los escenarios más sensibles se encuentran los Mac mini y Mac Studio usados como servidores, muy populares en estudios de desarrollo de apps, agencias creativas, empresas de software o centros de datos que necesitan hardware Apple para compilar y probar aplicaciones de iPhone, iPad y Mac. Estas máquinas suelen estar encendidas semanas o meses seguidos.
También destacan los runners de CI/CD en plataformas como GitHub Actions, GitLab CI o soluciones propias de integración continua, que se apoyan en equipos con chips Apple Silicon (M1, M2, M3…) para generar builds nativos. Si uno de estos nodos alcanza los 49,7 días de uptime sin reinicio, puede dejar de establecer conexiones con repositorios, APIs externas o bases de datos justo en mitad de despliegues importantes.
Otro caso frecuente son las estaciones de trabajo de desarrollo, diseño, edición de vídeo o sonido que rara vez se apagan. En muchos estudios de producción o departamentos técnicos, el Mac se pone en reposo por la noche, pero no se reinicia durante semanas, lo que facilita llegar al umbral del bug sin que nadie se dé cuenta.
Y, por supuesto, están los MacBook de uso diario. Es tremendamente cómodo cerrar la tapa, dejar el portátil en reposo y retomarlo al día siguiente en el mismo punto. Si a esto se suma cierta pereza a la hora de aplicar actualizaciones que requieren reinicio, no es extraño que un portátil acumule mes y medio de actividad y empiece a mostrar fallos de conexión aparentemente aleatorios: apps que dejan de cargar contenido, webs que se quedan pensando o servicios en la nube que se cortan sin motivo aparente.
Síntomas: el Mac “tiene Internet”, pero no abre nada nuevo
Para quien se topa con el bug, la situación es bastante confusa. Por un lado, el sistema muestra que está conectado a la red Wi‑Fi o por cable, las luces del router están encendidas y, al hacer un ping a otra máquina, hay respuesta. Incluso algunas conexiones ya establecidas, como una sesión SSH abierta de antes o un flujo de datos en marcha, pueden seguir funcionando un rato.
Al mismo tiempo, empiezan a fallar acciones básicas: páginas web que no cargan, clientes de correo que se quedan intentando sincronizar, aplicaciones que dependen de APIs externas lanzan errores de tiempo de espera y los servicios internos dejan de recibir tráfico nuevo.
En servidores y entornos de producción, esto se traduce en problemas tan variados como plataformas web que dejan de servir peticiones, colas de trabajos que no se vacían, integraciones con terceros que se cortan y pipelines de despliegue que fallan al intentar descargar dependencias o subir artefactos.
Las herramientas de monitorización de red que han usado algunas empresas muestran un patrón claro: justo después del momento crítico de los 49,7 días, el número de conexiones en estado TIME_WAIT empieza a subir sin parar, mientras que el pool de puertos efímeros disponibles se va vaciando hasta quedar totalmente saturado. El sistema no avisa al usuario de nada de esto, simplemente deja de poder abrir sockets nuevos.
No es raro que, ante este panorama, el primer sospechoso sea el router o la conexión del operador. Sin embargo, al comprobar otros dispositivos en la misma red (móviles, tabletas, otros ordenadores), todo funciona con normalidad. Es entonces cuando suele llegar la solución más sencilla y, paradójicamente, la más efectiva: reiniciar el Mac y ver cómo todo vuelve a ir fino.
Qué soluciones hay ahora mismo: reinicios y medidas de mitigación
A día de hoy, y según coinciden tanto Photon como otros desarrolladores y administradores de sistemas que han analizado el problema, la única forma realmente eficaz de recuperar el funcionamiento normal de la red es reiniciar el equipo. Ese reinicio pone a cero el contador tcp_now, vacía las conexiones acumuladas en TIME_WAIT y permite de nuevo abrir conexiones TCP sin restricciones.
Esto convierte el bug en una especie de reloj de cuenta atrás para cualquier infraestructura basada en macOS: si se deja correr el sistema más allá de los 49,7 días de uptime, tarde o temprano las nuevas conexiones dejarán de funcionar. Mientras Apple no publique un parche que modifique el comportamiento del kernel, toca jugar con la prevención.
Entre las medidas de mitigación que se están recomendando en entornos profesionales, tanto en España como en el resto de Europa, destacan varias prácticas:
- Programar reinicios periódicos en servidores macOS, por ejemplo cada 30 o 40 días, para no acercarse al umbral crítico.
- Monitorizar el tiempo de actividad de los equipos y configurar alertas cuando el uptime supere ciertos límites, de forma que se pueda planificar un reinicio en ventana de mantenimiento.
- Vigilar el número de conexiones en TIME_WAIT y el uso de puertos efímeros con herramientas de red, como parte del monitoreo habitual de los sistemas.
- En arquitecturas mixtas, mover cargas de servidor a Linux u otros sistemas cuando no resulte imprescindible usar macOS, reservando los Mac para compilaciones, pruebas específicas o tareas de escritorio.
En el caso de usuarios domésticos, las recomendaciones son mucho menos dramáticas. Basta con reiniciar el Mac de vez en cuando, por ejemplo una vez al mes o aprovechando las actualizaciones del sistema. Además de evitar el bug, este hábito ayuda a limpiar procesos que se quedan en segundo plano y pequeñas fugas de memoria que se acumulan con los días.
¿Un problema de seguridad o de estabilidad?
Por ahora, el consenso entre la comunidad técnica es que el llamado “error de Internet de 49 días de macOS” es ante todo un problema de estabilidad y disponibilidad, no una vulnerabilidad que permita tomar el control de los equipos de forma directa.
No hay indicios de que un atacante pueda explotar este fallo para ejecutar código arbitrario o escalar privilegios. El bug se comporta más bien como una condición de denegación de servicio involuntaria: cuando el contador se desborda y la pila TCP deja de reciclar conexiones, el propio sistema se queda sin capacidad para aceptar nuevas comunicaciones.
Eso no significa que el impacto sea menor. Para empresas que operan servicios 24/7 sobre macOS, quedarse sin nuevas conexiones de red puede suponer caídas de servicio, interrupciones en procesos críticos y pérdida de confianza por parte de clientes y usuarios. Aunque la solución sea tan simple como reiniciar, el daño ya está hecho si no se detecta a tiempo.
El problema ha sido reportado a Apple por parte de Photon y otros actores, pero, de momento, no se ha documentado públicamente un parche específico para este caso en las notas de actualización de macOS. Entre las posibles soluciones de fondo se ha mencionado el uso de contadores de 64 bits o cambios más profundos en el kernel, pero cualquier modificación de este tipo requiere tiempo, pruebas y una validación exhaustiva.
Mientras llega ese posible arreglo oficial, muchos administradores han optado por tratar este bug como un riesgo operativo más: algo que se mitiga con procedimientos y monitorización, igual que se hace con otros límites de capacidad o ventanas de mantenimiento programadas.
Este fallo recuerda, en el fondo, que incluso sistemas tan pulidos como macOS esconden limitaciones técnicas heredadas y decisiones de diseño que solo salen a la luz en escenarios muy concretos, como mantener un equipo encendido durante casi 50 días sin descanso. Para la mayoría de usuarios apenas será una anécdota, pero para quienes dependen de Macs como servidores o estaciones de trabajo críticas, controlar el tiempo de actividad y planificar reinicios se ha convertido en una pieza más de la estrategia para evitar sorpresas con la conexión a Internet.
