mDNS是什么意思？电视投屏搜得到、\\NAS名\连不上，家里的自动发现全归它管

上个月我表弟在书房电脑上敲\\fnnas\media想拖部电影，资源管理器转了半分钟，弹出来一句"找不到网络路径"。他喊我过去看，我把名字删了换成\\192.168.31.20\media，秒开。他问我是不是NAS坏了，我说不是，是你喊的名字没人应。

这事背后有个叫mDNS的东西在管。家里的电视投屏为什么能互相搜到、苹果手机为什么能找到打印机、Home Assistant为什么能自动发现四十多个设备，全是它在底下喊话。今天把这个东西拆开讲清楚，因为它坏的时候特别迷惑——症状永远是"IP能通，名字不行"，跟我在电视直连NAS看电影那次翻车是同一个根子。

先把两套查名字的路子分开

我以前写过一篇DNS解析，那是"正经"查名字：你问223.5.5.5，它一层层替你跑到权威服务器，最后把域名换成IP递回给你。中间有专门的服务器伺候你，你去的是户籍科，有局长有窗口。

mDNS是另一套。它没有服务器，或者说网里每台设备自己就是服务器。你的电脑想知道NAS叫什么IP，它不问任何人，直接朝整个局域网喊一嗓子："谁叫fnnas？报一下门牌号！"NAS听见了，自己回话："我，192.168.31.20。"

喊话不是瞎喊，有固定套路：包从UDP的5353端口发出来，扔给组播地址224.0.0.251，这个地址相当于"本楼全体住户"的群号，挂在这条网上的设备都能收到。觉得谁的IP谁应答，应答包也回到5353。协议写死TTL为255，意思很明确——这包只许在本条链路上转，不许出门。

所以mDNS管的名字有个专用后缀：.local。fnnas.local就是给mDNS认的名字，跟域名长得很像，但压根不走互联网那套DNS。我访问NAS管理页有时候直接敲http://fnnas.local:5666，能开，就是它翻译的。

为什么客厅能连、卧室就是打不开

mDNS文档里管自己的作用范围叫"链路本地"，链路本地四个字是字面意思：喊话只在这条二层链路里传，路由器默认不帮忙往外转。我在一台跟家里网完全隔离的测试机上写了几行Python，加入了224.0.0.251这个组播组，蹲了整整八分钟——一个包都没有。又朝这个地址连发了四个名字查询，包括n100.local和_http._tcp.local，零应答。链路上没人，喊破喉咙也没用。

这解释了我家两个真事。头一件：我把一台旧路由改AP划了IoT专网给智能设备用，从那晚起，客厅电视再也搜不到我挪进去的摄像头——两个网，组播过不去，谁也听不见谁喊。第二件更隐蔽：亲戚来我家连了访客WiFi，手机想投屏，客厅电视明明开着就是搜不到。访客网络开着AP隔离，隔离拦的正是这种喊话，我在这篇AP隔离里专门写过。

所以记住一张账：普通DNS问的是全世界的名字，mDNS只管本条链路上的名字。中间隔着路由器、隔着VLAN、隔着隔离开关，任占一样，喊话就断了。我后来用管理型交换机给监控划VLAN，NAS还能被电视搜到，是因为两台都在主网那个区里，没隔开。跨区要通，得专门配个mDNS反射器把喊话转过去，家用犯不着。

家里到底谁在靠它吃饭

我拿抓包工具在主网上蹲了一晚，5353端口上热闹得很，比我想象的多：

这些"_xxx._tcp"样式的名字是另一层东西，叫DNS-SD，服务发现，骑在mDNS上跑。翻译成人话：不光能喊"谁叫fnnas"，还能喊"谁会投屏""谁会打印"，设备自己举手。苹果管这套叫Bonjour，Linux上叫Avahi，名字不同喊的是同一口井。

还有个容易搞混的：安卓手机投屏走的SSDP，是另一套组播协议(239.255.255.250那组)，我在组播那篇里写过。两套协议干一样的活，各喊各的频道。所以投屏搜不到，得看双方是不是同一套频道里——好在大部分电视两头都听。

Windows电脑为什么最容易出现"名字失灵"

表弟那台Windows敲名字连不上，根子在微软的历史包袱。Windows自己有一套老办法认名字，顺序是：先问DNS，再问mDNS，然后LLMNR(5355端口广播)，实在不行翻NetBIOS老黄历(137端口)。四层下来，哪层通了用哪层。

坑在哪？Win10的1809版本之前，Windows压根不认.local，也不听mDNS。老系统上你敲\fnnas\，它走的是NetBIOS广播去问，NAS的Samba服务恰好也回NetBIOS，多数时候凑合能用。但一旦SMB服务把NetBIOS关了(新固件不少默认关)，或者中间隔了个不转发广播的东西，名字就死了——而mDNS这条路老Windows压根没有。

我表弟那台是Win10老版本常年没更新，卡的就是这个。办法有两个：一是老老实实用IP，二是把系统升上去。1809以后Windows原生认.local结尾的名字了，敲ping fnnas.local能通，就是mDNS在工作。注意它只解析不发布——别人能通过mDNS找到你这台Windows，但你没法用Windows机器名被找到，这是微软的实现，气人但没辙。

名字时灵时不灵，按这个顺序查

mDNS故障的特色是"玄学"：今天能开明天不能，客厅行卧室不行。我踩多了攒出一条固定顺序，照着走基本不绕路：

• 先换IP试。IP通名字不通，坐实是名字层的事，跟网速信号无关，别去重启路由器。
• 看两边是不是同一个网。访客WiFi、IoT专网、光猫自带的WiFi，都是另一条链路，喊话天生过不去，这是设计不是故障。
• 看系统版本。老Windows不认.local，苹果和安卓手机、Win10 1809以后、Linux都没问题。
• 查组播有没有被拦。有些路由器的IGMP Snooping配得激进，会把组播掐在交换芯片里不让泛洪，终端一个包都收不到；AP隔离开关同理，翻我那篇AP隔离看排查法。
• 都排除还不行，就别跟名字较劲了。NAS这种常年固定不动的设备，在路由器上绑个静态IP，手机电脑统统存IP访问，一劳永逸。

我自己家的折中是：手机电视这种天天变的设备靠自动发现，NAS和打印机这种不挪窝的钉死IP。自动发现是方便，但它天生不如一个写死的门牌号可靠。

顺嘴说一句安全，别慌

mDNS是喊话制，谁都能应答，也谁都能偷听。企业内网里这是大窟窿——有人伪造应答就能把你的登录凭据骗走，所以公司电脑常见组策略把这条路封死。家里风险低得多：喊话出不了你家这条链路，外面的人进不来应答。真要较真，别把陌生设备放进主网就行，访客网络不光防蹭网，顺手也把这些发现类协议隔在门外了，这是我那篇家庭VLAN的思路。

再啰嗦一句技术底子：mDNS跑在UDP上，无连接、发了不管，所以它轻但也丢包，2.4G频段干扰大的环境里名字解析偶尔超时，重试就好，跟TCP那套重传机制完全是两个脾气，我在TCP和UDP那篇里写过这对搭档的分工。

收尾给个总顺序：名字连不上，先换IP确认是名字层，再查同不同网段，然后看设备新旧和组播开关，搞不定的设备直接钉IP。我表弟那次最后就是给NAS绑了31.20的静态地址，从此书房电脑里存的全是IP，再没为名字生过气。