O que é o nsurlsessiond no Mac? O daemon de download em segundo plano explicado

nsurlsessiond é um daemon do sistema que vem com o macOS e é assinado digitalmente pela Apple. É o agente de transferência em segundo plano para NSURLSession, a API de rede padrão que aplicativos nas plataformas Apple usam para se comunicar com servidores.

O nome se divide claramente uma vez que você sabe disso. NSURLSession é a API, e o d no final é a convenção Unix para um daemon, um processo de fundo sem janela e sem ícone no Dock. Ele é iniciado pelo sistema, não por você, e roda sempre que há trabalho na fila.

A parte que importa é a palavra background. Quando um desenvolvedor usa NSURLSession, ele pode marcar um download ou upload como uma transferência em segundo plano, o que informa ao sistema que ela deve sobreviver a circunstâncias que o próprio aplicativo não suportaria: o usuário fecha o aplicativo, o aplicativo é suspenso, o aplicativo trava, ou a máquina fica ociosa. O macOS respeita isso ao passar a transferência para nsurlsessiond, que a realiza e notifica o aplicativo depois, relançando-o se necessário para entregar o resultado. É por isso que um download grande na App Store continua progredindo mesmo após você fechar a janela da App Store, e por que um episódio de podcast termina de chegar mesmo que você nunca reabra o aplicativo de podcasts.

Você frequentemente verá o nsurlstoraged listado por perto. É um daemon da Apple relacionado que gerencia o armazenamento de dados de URL session, como respostas em cache e cookies, e também é completamente normal. Normalmente, ele mostra muito menos atividade de rede, já que seu trabalho fica no lado do armazenamento, não na conexão de rede.

Esta é a coisa mais importante a entender sobre nsurlsessiond, e é a razão pela qual tantas pessoas ficam desconfiadas dele. O tráfego atribuído a nsurlsessiond geralmente pertence a algum outro aplicativo. Ele é um mensageiro compartilhado, transportando pacotes para quem pedir, e os pacotes não são endereçados a ele.

Quando o Fotos faz upload de um lote de imagens para o iCloud, os bytes passam pelo nsurlsessiond. Quando a App Store baixa uma atualização de vários gigabytes, o mesmo acontece. Quando um cliente de terceiros sincroniza arquivos ou pré-carrega mídia, muitas vezes o mesmo ocorre. Todo esse tráfego é aberto por um processo, atribuído a um processo, e aparece sob um nome só.

O Activity Monitor, e qualquer ferramenta que identifique tráfego apenas pelo processo que possui o socket, não conseguem distinguir isso. Ele mostra o que é verdadeiro no nível do sistema operacional: as conexões pertencem ao nsurlsessiond. O que ele não consegue mostrar é o aplicativo solicitante por trás de cada transferência, porque essa relação fica em uma camada acima do socket. O resultado é uma única linha que parece um processo consumindo uma banda enorme, quando na verdade é o trabalho de vários aplicativos sob um mesmo rótulo.

Portanto, muitos dos alarmes do nsurlsessiond são por má atribuição, não por comportamento errado. Se você está se perguntando por que um daemon da Apple precisaria de quarenta gigabytes de downloads, a resposta é que ele não precisou. Algo no seu Mac pediu por eles.

Isso também explica por que o daemon parece estar sempre rodando. Ele não mantém uma conexão permanente. Ele acorda quando uma transferência é enfileirada, faz o trabalho, e fica quieto. Em um Mac sincronizando fotos, documentos, anexos de email e atualizações de aplicativos, quase sempre há algo na fila.

nsurlsessiond não é malware. É um componente de primeira parte do macOS, presente em todos os Macs atuais, e não precisa ser removido, desativado ou limpo por nenhuma utilidade.

A cautela razoável por trás da pergunta é que malware às vezes adota nomes semelhantes aos processos do sistema, esperando que uma olhada rápida na lista de processos permita que ele passar. Duas verificações no Terminal derrotam isso, e vale a pena saber delas para qualquer processo, não só deste.

A primeira verificação é a localização. Pergunte ao sistema onde o binário em execução está usando o comando pgrep com as flags -lf e nsurlsessiond como padrão. O daemon verdadeiro fica dentro de um caminho de framework do sistema, bem no interior do framework CFNetwork. Qualquer coisa que afirme esse nome na sua pasta Downloads, no seu diretório home, ou em um pacote de aplicativo desconhecido, não é o daemon da Apple.

A segunda verificação é a assinatura de código, e ela é mais forte que a primeira, porque um caminho pode ser imitado enquanto uma assinatura válida da Apple não pode. Execute codesign com as flags -dv e verbose contra o caminho do binário que você encontrou. O daemon verdadeiro relata uma cadeia de autoridade pertencente à Apple, nomeando Software Signing e a Apple Code Signing Certification Authority. Um binário não assinado, ou assinado por um desenvolvedor desconhecido, justificaria preocupação.

Se ambas as verificações passarem, o processo é o que afirma ser, e qualquer surpresa sobre seu comportamento é uma questão sobre os aplicativos que enfileiram trabalho através dele.

Como o nsurlsessiond só trabalha em nome de outra coisa, atividade incomum dele é um sintoma, e o diagnóstico útil é a origem. Uma pequena lista de causas responde pela maioria dos casos.

A mais comum é o iCloud. Uma biblioteca de Fotos do iCloud recém habilitada, um Mac restaurado, ou um lote grande de novas importações gera tráfego sustentado que pode durar horas ou dias, dependendo do tamanho da biblioteca e da velocidade da conexão. O iCloud Drive se comporta da mesma forma após uma grande mudança de pasta. Depois vem a App Store, incluindo atualizações grandes de aplicativos e atualizações do sistema em andamento em segundo plano. Terceiro, aplicativos de mídia pré-carregando conteúdo, como clientes de podcasts puxando vários episódios adiantados.

Uma forma ordenada de verificar, do mais barato ao mais envolvido. Comece com os candidatos do primeiro plano: abra a visualização de atualizações da App Store e as Configurações do Sistema para ver se alguma atualização está sendo baixada. Depois abra Fotos e leia a linha de status na parte inferior da visualização da Biblioteca, que mostra o progresso da sincronização e o número de itens, e verifique o iCloud Drive no Finder para itens pendentes. Considere também qualquer coisa instalada ou reconfigurada recentemente, já que um cliente de sincronização recém adicionado é um gatilho comum. Por fim, deixe rodar, porque transferências com fim definido terminam.

CPU alta geralmente acompanha as mesmas causas, já que transferências sustentadas significam trabalho contínuo, e não espera ocioso. Uma CPU alta persistente, sem throughput significativo, é menos comum, e muitas vezes se resolve com uma reinicialização, que reseta o daemon e sua fila sem efeito duradouro.

O que vale evitar é bloqueá-lo. Você pode negar acesso de rede ao nsurlsessiond com um firewall, e o resultado é que transferências em segundo plano em todo o sistema param de funcionar, geralmente sem erro explicando. Downloads nunca se concluem, a sincronização relacionada ao iCloud trava, e aplicativos que esperam que suas transferências tenham terminado descobrem que não. Como a falha é silenciosa e sistêmica, é uma má troca. A alavanca certa é a fila de trabalho do aplicativo, não o mensageiro que a transporta.

Isso deixa a questão que as ferramentas integradas não conseguem responder: qual aplicativo realmente solicitou tudo isso. O Activity Monitor para na fronteira do processo, então a linha mostra nsurlsessiond e o rastro termina ali.

Uma abordagem mais precisa é parar de confiar nos nomes dos processos e olhar para os destinos. As conexões ainda vão para algum lugar, e esses pontos finais identificam o serviço por trás de uma transferência mesmo quando o nome do processo não. Os pontos finais de entrega de conteúdo da Apple e do iCloud parecem claramente diferentes de um serviço de sincronização de terceiros ou uma CDN de mídia, e uma vez que você consegue ver os domínios, a atribuição deixa de ser uma suposição.

Essa é a lacuna que o NetMute foi criado para preencher. Ele mostra o tráfego em tempo real por aplicativo e por processo, ao invés de um único valor agregado, e combina isso com registros a nível de domínio para que você possa ver quais pontos finais uma transferência está alcançando. Isso transforma uma linha anônima em uma imagem clara: tanto de quanto está indo para o iCloud, quanto de quanto para um aplicativo que você instalou na semana passada.

Depois de saber a origem, o NetMute oferece maneiras proporcionais de agir, focando no aplicativo responsável ao invés do daemon do sistema. Você pode bloquear o acesso à rede de um aplicativo com um clique, ou usar uma regra temporária que expira sozinha quando você só quer silêncio na próxima hora. Um limite de dados por aplicativo bloqueia automaticamente ao atingir o limite, o que é útil para um aplicativo que se comporta bem até decidir pré-cachear uma temporada de algo. Perfis de rede permitem que essas regras mudem com o contexto, então um Mac em um hotspot com limite de uso impõe limites que não são necessários em casa.

Nada disso exige tocar no nsurlsessiond. O daemon continua fazendo seu trabalho, downloads em segundo plano e transferências do iCloud continuam sendo concluídos, e o aplicativo que gera o tráfego é o que fica restrito.