macOS 上的 timed 是什么，为什么会联网？

最后更新: 2026-07-31

它是什么

timed 是 Apple 放在 macOS 里的系统时间同步守护进程。它从 /usr/libexec/timed 启动，代码签名标识是 com.apple.timed。launchd 负责管理它，并让它使用专门的 _timed 用户运行。这不是 Time Machine，也不是用户后来安装的常驻软件。

按照 timed(8) 手册的定义，timed 会参考 NTP 等时钟来源，让系统时间保持准确。它还会估算当前时间存在多大不确定性。换句话说，它不只是把菜单栏里的时钟拨到某个数字，也要判断这个时间值有多可靠。

系统时间会写进文件、邮件和信息的时间戳。时钟出现偏差后，这些记录的先后顺序和实际发生时间可能对不上。证书有效期检查以及许多认证机制也依赖时间。轻微误差不等于所有网络连接都会立刻中断；但日期或时间偏差较大时，证书检查、认证及其他依赖准确时间的服务可能失败。因此，timed 维护的是系统基础状态，不是一个只影响时钟显示的小工具。

它为什么要联网

打开“自动设定时间与日期”后，Mac 需要从外部参考时钟取得时间，timed 就会查询当前配置的网络时间服务器。需要同步时，它可以发起请求；前一次没有成功时，也可能重试。Apple 列出的 macOS 时间服务包括 time.apple.com 和 time-macos.apple.com，使用的是 NTP 和 UDP 123 端口。

服务器并不一定永远是 Apple 的地址。用户可以改用其他 NTP 服务器，管理员也可以让受管理的 Mac 连接组织自己的时间服务。因此，看到 timed 前往另一台已配置的 NTP 服务器，不能单凭这一点判断系统异常。

开机、唤醒或网络恢复后，都可能触发时间检查。不过，Apple 没有公开一套稳定到每个数据包的请求时间表。不能因为某次唤醒后立即看到流量，就推断以后每次都会在完全相同的时刻联网。

当前检查到的系统启动配置含有 RunAtLoad、KeepAlive 和 3,600 秒的 StartInterval。这些字段说的是 launchd 怎样调度服务，不是 NTP 请求日志。它们无法证明 timed 每小时一定联网一次。内部调度、重试、Mac 进入睡眠、再次唤醒以及网络是否可用，都会改变实际看到的请求时间。

正常流量应该是多少

Apple 没有公布 timed 单次同步会传输多少字节，也没有给出可靠的每日流量标准。不同系统环境中的重试次数和实际范围同样没有得到验证，所以不能为它编一个固定的 KB、MB 或每日限额。看到某个精确数字时，首先要问清楚它来自实测、单台机器的短期记录，还是未经证实的推算。

可以确定的是，Mac 离线时不会产生网络校时流量。关闭自动设定时间后，也可以没有这部分同步流量。正常联网期间，timed 通常只是间歇交换短小的 NTP 报文，不会持续下载大块内容。它使用的流量远低于打开一个普通网页。

还要把进程存活和正在传输数据分开看。timed 出现在活动监视器里，不代表它一直联网。launchd 可以让服务保持运行，而此时网络流量仍然为零。反过来，开机、唤醒、断网重连或重试附近集中出现几次请求，也不能证明它长期按某个固定周期工作。只有观察实际时间段内的记录，才能知道这台 Mac 当时用了多少。

能不能关掉

一般情况下，建议保留自动校时。timed 的正常流量很少，维护准确时间却关系到时间戳、证书检查和认证。把它当作节省流量或提升速度的常规优化对象，通常得不到明显收益，反而要承担时钟逐渐漂移带来的问题。

确实需要停止网络自动校时时，可以前往：

Apple 菜单  > 系统设置 > 通用 > 日期与时间 > 自动设定时间与日期

关闭“自动设定时间与日期”即可。较早的 macOS 可能使用不同的入口名称或位置，不能把当前路径直接套到所有旧系统上。

关闭后，Mac 不再通过网络自动修正日期和时间，需要由用户手动维护。时钟逐渐偏离真实时间后，文件、邮件和信息可能留下不准确的时间戳。偏差扩大时，证书可能被判断为尚未生效或已经过期，认证及其他依赖时间的服务也可能出错。具体影响取决于偏差大小和所用协议，并非稍差几秒就一定让所有连接失效。

这个开关控制的是自动校时，不保证 timed 进程随即退出。系统配置使用了 KeepAlive，结束进程后，launchd 可以再次启动它。因此，在活动监视器里强制结束 timed，不等于关闭自动校时；直接删除系统组件也不是 Apple 提供的用户操作方式。

常见的误解

• “timed 固定每 15 分钟联网一次。” 没有可靠依据支持这个周期。Apple 没有公开固定的网络请求频率。已检查的启动配置里出现了 3,600 秒调度间隔，但那只是 launchd 的服务调度信息，不能证明每小时必有一次 NTP 请求。内部安排、重试、睡眠唤醒和网络状态都可能改变实际时间。

• “活动监视器里出现 timed，说明 Mac 中毒了或正在被监控。” 位于 /usr/libexec/timed、签名标识为 com.apple.timed 的实例是 macOS 自带组件。进程名本身却不能充当身份证明：其他目录里的第三方文件��使也叫 timed，也不会因此获得 Apple 系统组件的可信身份。

• “关掉 timed 能明显省流量，还能让网络变快。” 正常校时只需要少量、短暂的 NTP 报文，通常不是值得优化的流量来源。失去可靠时间后，时间戳可能混乱，证书检查和认证也可能遇到更严重的问题。现有资料没有给出关闭它可以明显提升速度的依据。

• “在活动监视器里结束 timed，就已经关闭自动校时。” timed 受 launchd 管理，并配置了 KeepAlive。进程退出后可以被重新拉起。真正面向用户的控制项，是“日期与时间”里的“自动设定时间与日期”。即使关闭该选项，守护进程本身也未必消失。

• “timed 主要在局域网里找其他 Mac 对时。” 默认配置指向 Apple 的网络时间服务，并不是以其他 Mac 为主要时间来源。受管理设备可以改用组织自己的 NTP 服务器，用户或管理员也能设置其他服务器，但这和“默认在局域网内找 Mac”不是一回事。

• “时钟只要有一点误差，所有网络连接都会断掉。” 这种说法夸大了影响。较大的日期或时间偏差可能让证书有效期判断出错，也可能干扰依赖时间的认证流程。究竟会不会失败，要看偏差有多大、具体服务使用什么协议。轻微误差不会必然造成整台 Mac 断网。

怎么看它到底用了多少

如果需要这台 Mac 的实际数字，可以在 Bytetally 的逐进程统计中查看 timed，并选择与问题对应的时间范围。观察开机、唤醒和网络恢复前后的记录，不要先假定它按固定周期请求。这样可以分清短暂的正常校时和持续出现、需要进一步核对的流量。

相关进程

常见问题