mDNSResponder —— Mac 的 DNS 解析器兼 Bonjour 服务

最后更新: 2026-07-30

它是什么

mDNSResponder 是 macOS 里最老、也最吃重的服务之一。它实际上干着两件互不相干的事，只是碰巧由同一个进程实现。

第一件是 DNS 解析。你 Mac 上任何一个 App 想把 example.com 这样的域名变成 IP 地址时，它并不会自己去问 DNS 服务器，而是交给 mDNSResponder：由它维护缓存、套用当前网络的 DNS 配置、真正发出查询。全机器所有 App 都从这里过。

第二件是 Bonjour，也就是苹果的零配置网络发现。你能在隔空播放菜单里看到 Apple TV、能直接找到 AirPrint 打印机、能看见另一台 Mac 共享出来的文件夹，全靠它——不需要任何人手动输 IP。它的做法是在局域网里收发组播 DNS 消息。

苹果曾经在 OS X Yosemite 里把这两件事拆给一个叫 discoveryd 的服务，结果那一版问题很多，后来又换回了 mDNSResponder。如果你在一些老的排查帖里见过 discoveryd，它就是这个进程的短命替代品。

它为什么要联网

两类完全不同的流量，分开看会清楚很多。

对外的 DNS 查询发往你网络通过 DHCP 下发的解析服务器，如果你手动改过 DNS 就发往你指定的那个。这类查询小、频繁，而且几乎什么操作都会触发：打开网页、收邮件、某个 App 后台查更新。

局域网组播发往 224.0.0.251 的 5353 端口，根本不会离开你的局域网。这是 Bonjour 那一半：你的 Mac 一边对外宣告自己提供哪些服务，一边听别人的宣告。在苹果设备密集的办公室或者学校网络里，哪怕你什么都不干，这类交互也几乎不会停。

第二类流量正是 mDNSResponder 在监控工具里看着吓人的原因——它一直在活动，目标地址还特别多。但这些大多只是几百字节的局域网例行寒暄。

正常流量应该是多少

很小。这是一个连接数极高、字节数极低的进程，把这两件事混为一谈，是关于它最常见的误读。

一次 DNS 查询加上响应，通常只有几十到几百字节。就算你一整天重度上网、查询上千次，累计一般也就在几 MB 这个量级。组播发现属于细水长流，同样构不成什么流量。

所以判断它的正确姿势是：看流量，别看连接数。几百个连接很正常，几百 MB 就不正常了，值得查一查——解析器配置有问题导致反复重试、某个 App 因为连不上主机而疯狂发查询、或者公共 Wi-Fi 的登录门户在和你的 DNS 设置打架，这几种情况都能把它的流量顶到远超正常的水平。

能不能关掉

不能，也别试。 这是一个最典型不过的「保持开启」类进程。

macOS 把 mDNSResponder 当成基础设施。你把它杀掉，launchd 几秒内就会重新拉起；而在这个空档里，你的 Mac 解析不了任何域名——在用户看来，这和「断网了」没有任何区别，哪怕物理连接完全正常。

真正可以调整的是 Bonjour 那一半。如果你在意的是局域网发现产生的动静，去系统设置里关掉隔空投送、打印机共享、文件共享和媒体共享，你的 Mac 就会少宣告、少监听不少东西，而域名解析照常工作。不过在家庭网络环境下，一般没什么必要折腾这个。

怎么看它到底用了多少

正因为 mDNSResponder 是替所有其他 App 扛 DNS 的，「连接数」和「流量」在它身上讲的是两个完全不同的故事——而大多数工具只给你看前一个。

Bytetally 对每个进程分别统计上传和下载，实时和历史都留，所以你能一眼分清：这个服务是单纯地忙，还是真的在搬数据。万一哪天 mDNSResponder 的数字看着不对劲，正是这个区分能告诉你，究竟是出了问题，还是只不过查询多了点。

相关进程

常见问题