Mac 上的 nsurlsessiond，先找到传输来源

在活动监视器里看到 nsurlsessiond 排在前面，先找有没有仍在推进的传输，照片上传、应用下载和没完成的同步各有各的入口，即使忙的是同一个进程，也要先记下当前状态，再决定暂停哪一项。

nsurlsessiond 在做什么

nsurlsessiond 是 Apple 的后台传输服务，Apple 的开发者说明把它描述为后台 URL 会话使用的系统级服务，并不是你另外安装的应用。

进程名只能提供一个排查起点，不能直接告诉你该停哪个应用，可以检查 iCloud、照片和下载队列，但不能反过来认定这些服务的每一次传输都经过它。

iCloud 本身的排查放在 bird 和 cloudd 指南，想查其他联网来源，可以接着看哪个应用在使用网络。

分开看网络流量和 CPU

打开活动监视器，选择网络，Apple 的网络活动说明区分了累计收发的数据量和进程列表下面的每秒速率。

同一项传输还在进行时，隔一段时间对照两次显示，累计数字很大，不等于这台 Mac 现在还在高速传输。

把 CPU 占用当作另一项观察记录，不要直接判成资料库损坏，真正有用的是看一项能找到的任务有没有推进、完成，还是一直报同一个错误。

改设置前先看照片和 iCloud

在照片里打开图库，选择所有照片，滚动到底部，Apple 的 iCloud 照片说明介绍了如何查看上传状态，以及在按钮可用时暂停一天的上传。

暂停前先记下剩余任务，如果最近刚导入照片，就把上传状态和网络读数对照，不要为了降流量去删照片，同一份说明也写清了，iCloud 照片里的删除会同步到其他设备。

iCloud 云盘则先看你正在等同步的文件，另一个设备还需要它，就先确认文件是否已经到达，不要把关掉同步当成试验，无法替代的内容另存一份独立副本。

再看应用下载和待更新项目

打开 App Store，找有没有正在进行的下载，Apple 记录了如何用下载旁的控件暂停和恢复应用下载。

也看看更新里有哪些待更新应用，入口见 Apple 的手动更新说明，有待更新项目只是一个需要核对的线索，不能证明流量来自它。

如果已经开始 macOS 更新，先读当前进度，不要把安装阶段当成普通应用下载，也不要为了验证网络猜测而中断安装。

一次暂停一个来源，再看结果

挑一项能看到、也有官方暂停入口的传输，比如照片上传或 App Store 下载，记下时间、进度和网络速率，然后只暂停这一项。

再看同一组读数，如果流量降下来了，方便时恢复任务，检查进度和流量是否一起回来，这能支持两者有关，但多项传输并行时，仍不能单凭它确认来源。

如果没有变化，先恢复这一项，再试下一项，不要把照片、iCloud 和更新的设置一起改掉，否则很难知道哪一步起了作用。

这里不用结束 nsurlsessiond 来暂停，Apple 的开发者讨论把服务终止和后台会话断开联系在一起，控制入口留在发起传输的应用里，不要把重启进程变成日常修复办法。

找不到推进中的任务时

简短记下进程名、时间、CPU 读数、流量变化和来源应用显示的完整错误，再补上暂停、恢复一项任务后有没有变化。

同一个应用一直卡着，就把这些信息交给它的支持渠道，如果来源是照片，再带上同步状态，任务归属还不清楚时，先别删资料库、传输数据库或支持目录。

Mole 能帮上什么

Mole Mac 的状态页在网络卡片里显示总下载和上传速率，可以用这组总量对照暂停前后，再回到来源应用管理传输。

总速率不能证明 nsurlsessiond 的任务属于照片，或属于某个特定应用。

常见问题

nsurlsessiond 是需要卸载的应用吗？

不是，它是 Apple 的后台传输服务，要从请求任务的应用或服务查起，不要尝试移除这个守护进程。

网络占用高就代表坏了吗？

不能单凭这一点判断，把能看到的上传、下载进度和当前速率对照，累计数据量很大，也不等于问题仍在持续。

想停下载，可以强制退出 nsurlsessiond 吗？

有暂停入口时就在来源应用里操作，一次只改一个任务，看完读数再恢复，不要直接中断共享服务。