0. 一个前提投屏是三段不是一件事[发送端] --发现-- [接收端清单] --协商-- [能力约定] --传输-- [画面数据] ↑ 组播 ↑ 单播/控制通道 ↑ 单播媒体流“投屏不上”的投诉里“找不到设备”是发现层故障它一帧画面都不传。发现层用的是组播所以有一个反直觉的结论网页、文件一切正常单播好不代表投屏能发现设备组播好。1. 各种投屏协议到底走哪条路生态发现机制关键端口/地址传输Apple AirPlay / BonjourmDNSUDP5353组播224.0.0.251IPv6FF02::FB建立后走单播Google Cast安卓/ChromemDNS_googlecast._tcpUDP 5353 TCP8008/8009单播DLNA / UPnP电视、盒子SSDPUDP1900组播239.255.255.250单播MiracastWindows“连接到无线显示器”Wi-Fi Direct不经 AP 的局域网组播直连mDNS 的端口与组播地址见 RFC 6762。注意最后一行Miracast 不依赖局域网组播所以“Miracast 能用但 AirPlay 不行”完全可能别拿它证明网络没问题。2. 为什么组播这么脆802.11 里组播/广播帧不确认、不重传且通常被压到最低基础速率发送——成功率天然低于单播且下降得很早省电机制休眠中的无线网卡可能错过组播二层边界224.0.0.251 属链路本地控制块路由器不得转发到子网之外。跨 VLAN / 连了访客 Wi-Fi发现必然失败组播处理策略不对称链路本地组播224.0.0.251不走 IGMP很多交换机当广播泛洪而 SSDP 用的 239.255.255.250 属管理范围地址会进 IGMP snooping 判定——snooping 配得不对会只干掉DLNA 那一类发现AP 开关客户端隔离同 SSID 内互不可见直接致命多播转单播把组播拆成单播逐个发显著提升投递率主机侧入站 UDP 5353/1900 被防火墙或安全软件拦Windows 网络画像为“公用网络”、“网络发现”关闭IPv6 双栈不干净苹果设备优先用 FF02::FB组播被挡就出现“发现闪断”。3. 实操10 分钟定位dns-sd-B_airplay._tcplocaldns-sd-B_googlecast._tcplocalavahi-browse-art|grep-iEairplay|googlecast|_raopping接收端IPsudotcpdump-niany udp port5353sudotcpdump-niany udp port1900判定表抓包结果含义下一步有请求、无回应请求丢在中间或被接收端拦下查 AP 客户端隔离 / VLAN / ACL / 接收端防火墙无请求发送端自己没发查本机防火墙、mDNS 服务、“网络发现”请求回应都正常但连不上已越过发现层转向协商与设备占用排查变量隔离顺序一次只改一个换 SSID → 关本机防火墙 → 只留 IPv4 → 换一台发送设备。四个实验做完绝大多数“时有时无”都能落到具体某个开关上。4. 检查清单可直接抄进房间验收表会议室接收端与常用发送设备在同一二层域同 SSID/同 VLAN访客网络是否有意投屏明确写进房间说明不要靠临时放行AP 上多播转单播已开启客户端隔离策略已按投屏需求评审交换机IGMP snooping配置与 DLNA 类设备兼容改动前后拿抓包比对防火墙放行入站UDP 5353 / 1900本地子网IPv6 要么配置干净要么明确关闭不留半吊子状态跨网段房间已部署mDNS 反射/Bonjour 网关并纳入变更管理三段各有观测项发现成功率 / 协商成功率 / 传输质量报修模板含设备型号、SSID、协议、接收端 ping 结果。5. 小结投屏“找不到设备”绝大多数不是信号问题而是发送端与接收端不在同一个组播域或这个域里的组播被顺手关掉了单播正常不能作为投屏正常的证据把发现当成一条独立服务链来验收和监控这类“时有时无”的投诉就会从玄学变成清单上的一行。