Mac 上的 kandji-daemon 是什么？

最后更新: 2026-08-05

它是什么

kandji-daemon 是 Iru Agent 内部的高权限后台服务。Iru Agent 以前叫 Kandji Agent，公司和产品也曾使用 Kandji 这个名字。它来自第三方企业管理软件，不是 Apple 开发的组件，也不是 macOS 自带服务。

公司把 Mac 纳入设备管理后，Apple MDM 负责一部分系统级管理工作，Iru Agent 则在这个基础上继续执行管理员下发的任务。kandji-daemon 会落实指定设置、管理软件、运行管理员提供的脚本，还会收集硬件和应用清单。公司如果启用了相关模块，它也会参与端点安全功能。

进程名看起来仍像旧品牌，并不代表安装有问题。应用虽然已经改名为 Iru Agent，但可执行文件、launchd 标签、Bundle ID 和日志子系统仍可能保留 kandji-daemon 或 io.kandji。常见标识包括 io.kandji.KandjiAgent 和 io.kandji.kandji-daemon。经过本机安装文件核对，这个可执行文件位于 /Library/Iru/ 下的 Iru Agent 应用内部；较早的安装可能使用不同路径。

它为什么要联网

kandji-daemon 通过 HTTPS 连接公司专属的 Iru/Kandji 设备管理服务。Agent 会定期报到，正常周期通常是每 15 分钟一次。管理员发起同步，或者用户主动要求同步时，它也会立即连接，不必等到下一轮定时检查。

每次报到不只是确认设备在线。kandji-daemon 会取得最新策略和 Library Item 状态，执行已经分配的管理任务，再回报执行结果。它还会上报应用清单，并检查 Agent 或受管应用是否需要更新。

管理员分配新软件或软件更新后，Iru 整套组件可能从分发服务或对象存储端点下载安装文件。这里没有经过核实的固定域名清单，也不能看到一次大下载就断定全部流量都来自 kandji-daemon。Iru 的其他辅助进程也会参与软件安装，有些大型下载可能由那些进程完成。

实际通信内容还取决于公司启用了哪些功能。端点检测与响应、漏洞管理、遥测和诊断都可能增加额外数据交换。具体收集哪些数据，要看公司购买并启用的模块，也要看管理员配置了哪些策略。

Apple 自己的 MDM 通信不能算到 kandji-daemon 头上。mdmclient、APNs 通道以及其他 Iru 辅助进程各自负责不同环节，包括设备报到、命令送达和软件安装。分析流量时需要把这些进程分开，不能把所有“与公司管理有关”的连接合并成 kandji-daemon 的活动。

正常流量应该是多少

目前没有经过验证的 kandji-daemon 单进程流量基准，也没有找到可靠的厂商公开带宽数据。因此，不能给它规定一个每天多少 MB、每月多少 GB 的“正常值”。任何具体数字都会制造一种并不存在的确定性。

设备空闲、策略没有变化时，流量可能主要来自周期性的元数据交换，每次连接持续时间较短。公司下发应用或安排更新时，相关传输可能达到安装包的量级。不过，大文件也可能由其他 Iru 辅助进程下载，不能只看 kandji-daemon 一个名字。

诊断、遥测和已启用的安全模块还会带来不固定的通信量。它们是否运行、运行多频繁、处理了什么事件，都可能改变最终结果。短时间内出现较大流量并不自动等于异常；一段时间几乎没有流量，也不代表管理服务已经失效。

判断时更有用的是上下文：当时是否刚分配软件，是否更新了策略，是否有人手动同步，是否启用了诊断或安全功能，以及同一时间其他 Iru 进程用了多少流量。缺少这些信息，仅凭总字节数很难得出可靠结论。

能不能关掉

公司管理的 Mac 应保留 kandji-daemon。Apple 没有提供专门控制这个服务的可靠开关，因此这里也没有可以照着进入的系统设置路径。

“登录项与扩展”里有时能看到相关受管组件，但这不等于用户可以在那里停用它。Iru 的管理配置正是用来阻止已注册用户关闭后台管理服务。部分部署会在“通用 > 设备管理”中允许移除注册描述文件，但权限由公司决定，也可能完全不可用。移除整个注册关系属于设备退管，不是 kandji-daemon 的单独开关。

停止或拦截 kandji-daemon 后，管理员下发的设置可能无法落实，设备和应用清单也可能停止上报。受管软件的安装与更新、管理员脚本以及已启用的端点安全功能同样可能受到影响。管理后台可能因此把设备标记为状态异常或不合规。

这不表示公司资源一定会立刻失去访问权限。是否限制访问，要看公司有没有配置合规判断或条件访问规则。不同组织的策略不同，不能把一种公司的处理方式当成普遍结果。

强制退出也不能永久停用管理。它的 launchd 任务设置了 KeepAlive，服务会再次启动。设备仍处于注册状态时，管理端还可能要求重新安装缺失的 Agent。需要正式移除时，应由公司的管理员完成退管流程。

常见的误解

• “这是 Apple 自带的系统服务。” 不是。kandji-daemon 随 Iru Agent 安装，属于 Iru；Iru 和这款 Agent 过去使用 Kandji 名称。macOS 本身不会凭空安装这个第三方服务。

• “名字陌生，所以它一定是恶意软件或挖矿程序。” 进程名陌生不能证明这些判断。公司明确注册和管理的 Mac 出现 kandji-daemon 很正常。如果设备所有者从未同意纳入 Iru/Kandji 管理，才需要向所有者或 IT 管理员核实安装来源。

• “在活动监视器里强制退出一次���它就不会再运行。” launchd 通过 KeepAlive 维持这个服务，退出只能造成暂时中断。设备没有退管时，管理系统还可能向它下发重新安装 Agent 的命令。

• “把普通登录项关掉就能停用它。” 这不是受支持的停用方式。管理描述文件会阻止已注册用户在系统设置中关闭这些后台服务。界面里看得到相关项目，也不代表它是一个由用户自由控制的普通登录项。

• “所有 MDM 流量都是 kandji-daemon 产生的。” Apple 的 mdmclient 和 APNs 通道承担独立的设备报到与命令传递工作。Iru 的其他辅助进程还会执行软件安装，并可能承担一部分大型下载。看到管理相关连接时，需要先确认真正发起连接的进程。

• “它一联网，就说明公司正在记录我的浏览内容。” 仅凭网络活动不能得出这个结论。已经确认的用途包括管理报到、资产清单、软件分发、遥测、诊断以及已启用的安全功能。究竟收集哪些数据，由公司的模块和策略决定，不能从进程联网这一件事继续外推。

• “只要拦截它，公司资源马上就会全部失效。” 这个结果并不普遍。设备可能在管理后台显示异常或不合规，但是否进一步限制公司资源，要看组织有没有设置相应的合规或条件访问规则。

怎么看它到底用了多少

既然没有可靠的公开基准，下一步就是按时间段查看这台 Mac 的实际记录。Bytetally 的逐进程统计可以单独查看 kandji-daemon，同时也应分别检查其他 Iru 辅助进程。再把流量发生时间与软件分配、更新、策略同步或诊断活动对照，才能判断一次传输是否反常。

相关进程

常见问题