¿Qué es nsurlsessiond en Mac? El daemon de descargas en segundo plano explicado

nsurlsessiond es un daemon del sistema que viene con macOS y está firmado por Apple. Es el agente de transferencia en segundo plano para NSURLSession, la API de red estándar que las aplicaciones en plataformas Apple usan para comunicarse con servidores.

El nombre se desglosa claramente una vez que sabes eso. NSURLSession es la API, y la d final es la convención Unix para un daemon, un proceso en segundo plano sin ventana ni icono en el dock. Es iniciado por el sistema en lugar de por ti, y se ejecuta siempre que hay trabajo en cola para él.

Lo que importa es la palabra background. Cuando un desarrollador usa NSURLSession, puede marcar una descarga o carga como una transferencia en segundo plano, lo que indica al sistema que debe sobrevivir a circunstancias en las que la propia aplicación no lo haría: el usuario cierra la aplicación, la aplicación se suspende, la aplicación se cierra por error, o la máquina se deja sola. macOS respeta eso entregando la transferencia a nsurlsessiond, que la realiza y notifica a la aplicación después, relanzándola si es necesario para entregar el resultado. Por eso, una descarga grande en App Store sigue avanzando después de cerrar la ventana de la App Store, y por qué un episodio de podcast termina llegando aunque nunca vuelvas a abrir la aplicación de podcasts.

A menudo verás cerca a nsurlstoraged. Es un daemon de Apple estrechamente relacionado que maneja el almacenamiento de datos de URL session, como respuestas en caché y cookies, y también es completamente normal. Normalmente muestra mucho menos actividad de red, ya que su trabajo se centra en el almacenamiento en lugar de en la transferencia de datos.

Esta es la cosa más importante que debes entender sobre nsurlsessiond, y es la razón por la que muchas personas terminan desconfiando de él. El tráfico atribuido a nsurlsessiond generalmente pertenece a alguna otra app. Es un mensajero compartido, que lleva paquetes para quien lo solicite, y los paquetes no están dirigidos a él.

Cuando Fotos sube un lote de imágenes a iCloud, los bytes viajan a través de nsurlsessiond. Cuando la App Store descarga una actualización de varios gigabytes, lo mismo. Cuando un cliente de terceros sincroniza archivos o pre-cacha medios, muy a menudo lo mismo. Todo ese tráfico es abierto por un proceso, atribuido a un proceso, y aparece bajo un solo nombre.

Activity Monitor, y cualquier herramienta que identifique el tráfico solo por el proceso que posee el socket, no puede distinguir eso. Reporta lo que es cierto a nivel del sistema operativo: las conexiones pertenecen a nsurlsessiond. Lo que no puede mostrar es la app que solicita cada transferencia, porque esa relación vive en una capa por encima del socket. El resultado es una fila única que parece un proceso consumiendo un ancho de banda enorme, cuando en realidad son varias apps trabajando bajo una misma etiqueta.

Por eso, muchas alarmas de nsurlsessiond son por atribución errónea, no por comportamiento indebido. Si te preguntas por qué un daemon de Apple necesitaría cuarenta gigabytes de descargas, la respuesta es que no lo hizo. Algo en tu Mac los solicitó.

Esto también explica por qué el daemon parece estar en ejecución constante. No mantiene una conexión permanente propia. Se despierta cuando hay una transferencia en cola, realiza el trabajo y se queda en silencio, y en una máquina que sincroniza fotos, documentos, adjuntos de correo y actualizaciones de apps, casi siempre hay algo en cola.

nsurlsessiond no es malware. Es un componente de primera mano de macOS, presente en todos los Mac actuales, y no necesita ser eliminado, desactivado o limpiado por ninguna utilidad.

La precaución razonable detrás de la pregunta es que el malware a veces adopta nombres que parecen procesos del sistema, esperando que una mirada rápida a la lista de procesos lo deje pasar. Dos verificaciones en Terminal lo derrotan, y vale la pena conocerlas para cualquier proceso, no solo este.

La primera verificación es la ubicación. Pregunta al sistema dónde vive el binario en ejecución usando el comando pgrep con las banderas -lf y nsurlsessiond como patrón. El daemon genuino vive dentro de una ruta de framework del sistema, en lo profundo del framework CFNetwork. Cualquier cosa que reclame ese nombre desde tu carpeta de Descargas, tu directorio personal, o un paquete de aplicación desconocido, no es el daemon de Apple.

La segunda verificación es la firma del código, y es la más fuerte de las dos, porque una ruta puede ser imitada mientras que una firma válida de Apple no. Ejecuta codesign con las banderas -dv y verbose contra la ruta del binario que encontraste. El daemon genuino reporta una cadena de autoridad perteneciente a Apple, nombrando Software Signing y la Autoridad de Certificación de Firma de Código de Apple. Un binario sin firmar, o firmado por un desarrollador desconocido, justificaría preocupación.

Si ambas verificaciones pasan, el proceso es lo que dice ser, y cualquier sorpresa sobre su comportamiento es una cuestión sobre las apps que le envían trabajo.

Porque nsurlsessiond solo trabaja en nombre de otra cosa, una actividad inusual de su parte es un síntoma, y el diagnóstico útil está en el origen. Un pequeño conjunto de causas explica la gran mayoría de los casos.

La más común es iCloud. Una biblioteca de Fotos de iCloud recién habilitada, un Mac restaurado, o un lote grande de nuevas importaciones produce tráfico sostenido que puede durar horas o días dependiendo del tamaño de la biblioteca y la velocidad de conexión. iCloud Drive se comporta igual después de un cambio grande en una carpeta. Luego viene la App Store, incluyendo actualizaciones grandes de apps y actualizaciones del sistema en segundo plano. La tercera es la precarga de contenido en apps de medios, como clientes de podcasts que descargan varios episodios por adelantado.

Una forma ordenada de verificar, desde la menos costosa hasta la más laboriosa. Comienza con los candidatos en primer plano: abre la vista de actualizaciones de la App Store y Configuración del Sistema para ver si hay una actualización en descarga. Luego abre Fotos y lee la línea de estado en la parte inferior de la vista Biblioteca, que informa el progreso de sincronización y el conteo de elementos, y revisa iCloud Drive en Finder para elementos pendientes. Considera también cualquier app instalada o reconfigurada recientemente, ya que un cliente de sincronización añadido recientemente es un desencadenante frecuente. Finalmente, déjalo correr, porque las transferencias con un fin definido sí terminan.

El alto uso de CPU generalmente sigue las mismas causas, ya que transferencias sostenidas significan trabajo continuo en lugar de espera inactiva. Un uso persistente alto de CPU sin un rendimiento significativo es menos típico, y a menudo se resuelve con un reinicio, que restablece el daemon y su cola sin efecto duradero.

Lo que vale evitar es bloquearlo. Puedes negar el acceso de red a nsurlsessiond con un firewall, y el resultado es que las transferencias en segundo plano en todo el sistema dejan de funcionar, generalmente sin un error que lo explique. Las descargas nunca terminan, la sincronización relacionada con iCloud se detiene, y las apps que esperan que sus transferencias hayan terminado descubren que no lo han hecho. Como la falla es silenciosa y a nivel del sistema, es una mala decisión. La palanca correcta es la app que pone el trabajo en cola, no el mensajero que lo transporta.

Eso deja la pregunta que las herramientas integradas no pueden responder: qué aplicación realmente solicitó todo esto. Activity Monitor se detiene en el límite del proceso, así que la fila dice nsurlsessiond y la pista termina allí.

Un enfoque más preciso es dejar de confiar en los nombres de proceso y mirar los destinos en su lugar. Las conexiones todavía van a algún lado, y esos puntos finales identifican el servicio detrás de una transferencia incluso cuando el nombre del proceso no lo hace. Los puntos finales de entrega de contenido de Apple y iCloud se ven claramente diferentes de un servicio de sincronización de terceros o un CDN de medios, y una vez que puedes ver los dominios, la atribución deja de ser una conjetura.

Esta es la brecha en la que NetMute está construido. Muestra tráfico en tiempo real por aplicación y proceso en lugar de una sola cifra agregada, y lo combina con registros a nivel de dominio para que puedas ver a qué puntos finales llega una transferencia. Eso convierte una fila anónima en una imagen clara: cuánto va a iCloud, cuánto a una aplicación que instalaste la semana pasada.

Una vez que conoces la fuente, NetMute te ofrece formas proporcionales de actuar, dirigidas a la aplicación responsable en lugar del daemon del sistema. Puedes bloquear el acceso a la red de una aplicación con un clic, o usar una regla temporal de expiración automática cuando solo quieres silencio durante la próxima hora. Un límite de datos por aplicación bloquea automáticamente al alcanzar el límite, lo que es útil para una aplicación que se comporta bien hasta que decide precargar una temporada de algo. Los perfiles de red permiten que esas reglas cambien con el contexto, así que una MacBook en un hotspot medido aplica límites que no necesita en casa.

Nada de esto requiere tocar nsurlsessiond. El daemon sigue haciendo su trabajo, las descargas en segundo plano y las transferencias de iCloud siguen completándose, y la aplicación que genera el tráfico es la que se ve restringida.