本文是排查手册：手机投屏时搜不到设备、连得上但很快断开、画面卡顿或延迟高，问题出在哪一层、怎么定位、怎么修。协议怎么选、接收端怎么装不在本文讨论范围内。
一、先搞清楚投屏的三个阶段
投屏失败几乎都能归到下面三个阶段中的某一个，先判断卡在哪个阶段，排查效率会高很多：
| 阶段 | 现象 | 主要依赖 | 常见根因 |
|---|---|---|---|
| 发现（Discovery） | 列表里搜不到电视 | 组播/广播报文 | AP 隔离、组播过滤、不同网段、访客网络 |
| 连接与控制（Control） | 能看到设备，点了没反应或提示失败 | 单播 HTTP/TCP | 防火墙、电视端服务被杀、端口被拦 |
| 传输与播放（Streaming） | 能播但卡、花屏、延迟高、没声音 | 带宽、编码 | 信道干扰、码率过高、编解码不兼容 |
二、三种主流协议的发现机制
2.1 DLNA / UPnP：SSDP 组播
DLNA 基于 UPnP，设备发现用的是SSDP（Simple Service Discovery Protocol）：
- 组播地址
239.255.255.250，UDP 端口1900； - 手机（控制点）发送
M-SEARCH请求，电视（MediaRenderer）用单播回复，回复里带一个LOCATION地址，指向设备描述 XML； - 电视上线时也会主动组播
NOTIFY ssdp:alive报文； - 控制阶段，手机通过 HTTP 访问
LOCATION，再用 SOAP 调用AVTransport服务的SetAVTransportURI、Play等动作； - DLNA 推送的通常是"媒体地址"，电视自己去拉流。手机作为媒体服务器时，电视会反过来访问手机上的 HTTP 端口。
所以 DLNA 需要两个方向都通：组播能到达，双向单播 HTTP 也能通。电视端只要运行一个 DLNA 接收端（如 喜乐投屏），就会在局域网内响应这类发现请求。
2.2 AirPlay：mDNS / Bonjour
AirPlay 的发现依赖mDNS + DNS-SD（苹果的实现叫 Bonjour）：
- 组播地址
224.0.0.251，UDP 端口5353（IPv6 为ff02::fb）； - 服务类型主要是
_airplay._tcp和_raop._tcp（音频）； - 发现之后的连接走 TCP（常见 7000 端口），镜像时还会用到其他动态端口。
224.0.0.x属于链路本地组播，默认不会被路由器转发到其他网段。这就是"电视接在另一个路由器下就搜不到"的原因。
2.3 Miracast：Wi-Fi Direct
Miracast 和前两者完全不同，它不经过路由器：
- 基于 Wi-Fi Direct（P2P），手机和电视之间直接建立一条无线链路；
- 发现靠 Wi-Fi 层的 P2P 探测，与 IP 组播无关；
- 视频流在源端实时编码（通常是 H.264），经 RTP 传给电视。
| 对比项 | DLNA | AirPlay | Miracast |
|---|---|---|---|
| 发现方式 | SSDP 组播 239.255.255.250:1900 | mDNS 224.0.0.251:5353 | Wi-Fi Direct P2P |
| 是否依赖路由器 | 是 | 是 | 否 |
| 典型用途 | 推送视频地址 | 推送 + 镜像 | 镜像 |
| 受 AP 隔离影响 | 是 | 是 | 一般不受 |
| 常见干扰源 | 组播过滤、跨网段 | 跨网段、mDNS 被拦 | 信道冲突、设备 P2P 驱动差 |
结论：如果 DLNA/AirPlay 搜不到但 Miracast 正常，问题基本出在路由器/局域网；如果三者都不行，就要怀疑电视本身或无线环境。
三、"搜不到设备"的网络层原因
3.1 AP 隔离（客户端隔离）
很多路由器、尤其是公司和酒店的网络，会开启"AP 隔离 / 无线客户端隔离 / Client Isolation"。开启后，同一个 Wi-Fi 下的终端之间互相访问不到，只能上网，组播和单播都会被拦。
判断方法：手机和电视都连上后，用同一网络下的电脑 ping 电视，如果 ping 不通、arp里也没有电视的 MAC，就要怀疑隔离。
处理：在路由器管理页面里关闭"AP 隔离"。不同品牌叫法不同，常见于"无线高级设置"。
3.2 访客网络
访客 Wi-Fi 本质上就是带隔离的独立网段，手机连主网络、电视连访客网络（或者反过来），一定搜不到。确保两台设备连的是同一个 SSID 的主网络。
3.3 2.4G / 5G 双频
双频合一通常没问题，因为两个频段桥接在同一个二层网络里。问题出在以下情况：
- 部分路由器给 5G 和 2.4G 分配了不同网段；
- 某些 Mesh 或旧固件在频段之间不转发组播。
判断方法：看手机和电视的 IP 是否在同一网段（比如都是192.168.1.x，子网掩码255.255.255.0）。不放心可以先让两台设备连同一个频段测试。
3.4 IGMP Snooping 与组播过滤
IGMP Snooping 是交换机/路由器用来"只把组播发给订阅了的端口"的机制。实现得好它能节省带宽；实现有缺陷时，SSDP、mDNS 这类报文会被误丢，表现为刚开机能搜到，过几分钟就搜不到了，或者时好时坏。
可以尝试：
- 在路由器里关闭 IGMP Snooping，或者开启"组播转发 / 多播增强"之类的选项后对比；
- 关闭"无线组播转单播"或"组播速率限制"后再测试；
- 升级路由器固件。
具体是开还是关效果更好跟设备有关，两种都测一下。
3.5 多层路由与中继
家里常见的"光猫路由 + 再接一个路由器"组合，如果第二个路由器工作在路由模式（下面的设备拿到192.168.0.x，上面的拿到192.168.1.x），两个网段之间组播不通，SSDP 和 mDNS 都过不去。
处理方式：
- 把第二个路由器改为AP 模式 / 桥接模式，关闭它的 DHCP，让所有设备在同一网段；
- 无线中继器选"桥接中继"而不是"路由中继"；
- Mesh 系统统一用主路由分配地址。
3.6 防火墙
- Windows 电脑做接收端：网络类型设为"公用网络"时，系统防火墙默认会拦截发现报文，改成"专用网络"，并允许接收程序通过防火墙；
- 手机端：部分安全软件、VPN、"代理/加速器"会接管流量，投屏前先关掉 VPN；
- 电视端：少数系统自带的"网络防护"也会拦截端口。
四、“能看到但连不上 / 很快断开”
4.1 电视端服务被杀
安卓电视和盒子内存小，系统为了省资源会杀后台：
- 投屏接收服务在后台被清理，设备从列表里消失或点击无响应；
- 开启"待机省电 / 快速待机"后，网络模块会在待机时休眠。
处理：
- 在电视设置里把接收应用加入"自启动/后台白名单"，关闭清理加速类工具对它的清理；
- 关闭"省电待机"中的"待机断网"类选项；
- 投屏前确保接收端应用在前台打开。
4.2 IP 变化与缓存
电视重新获取 IP 后，手机里可能还缓存着旧的LOCATION地址，点击就会失败。可以在路由器中给电视做DHCP 静态地址绑定，或者重启手机端投屏应用刷新列表。
4.3 手机侧的 HTTP 服务不通
DLNA 推送本地视频时，电视要回连手机。部分手机在"省电模式"下会限制后台网络，导致电视拉流失败。推本地文件失败而推在线视频正常时，优先怀疑这一点。
五、“卡顿、花屏、延迟高”
5.1 带宽与码率
推送在线视频时，由电视直接拉片源，卡顿多半是电视自身网速或片源 CDN 的问题；镜像时，所有画面由手机实时编码后经 Wi-Fi 发出，一份流要经过路由器两次（手机→路由器→电视），对空口占用更大。
建议：
- 镜像时把清晰度或帧率调低一档；
- 尽量让电视走有线网络，可以明显减少无线空口占用；
- 手机和电视都连 5G 频段。
5.2 Wi-Fi 信道干扰
在楼宇密集的环境里，2.4G 只有 1/6/11 三个互不重叠的信道，很容易拥挤。可以：
- 用 Wi-Fi 分析类工具看周围信道占用情况，手动选一个较空闲的信道；
- 5G 频段优先；注意部分 DFS 信道在检测到雷达信号时会切换，导致短暂断流；
- 路由器和电视之间尽量减少墙体遮挡，路由器不要放在电视柜后面的金属区域。
Miracast 的 P2P 链路如果和路由器工作在不同信道，设备需要在两个信道间分时切换，也会造成卡顿。
5.3 编码兼容
| 问题 | 可能原因 | 处理 |
|---|---|---|
| 有声音没画面 | 电视不支持 H.265/HEVC 硬解 | 换 H.264 片源或在发送端选兼容模式 |
| 4K 视频卡顿严重 | 电视解码能力不足 | 降到 1080p |
| 画面正常没声音 | 音频编码（如 DTS、杜比）不支持 | 换音轨或转码 |
| 10bit/HDR 片源偏色或黑屏 | 设备不支持对应格式 | 选 8bit SDR 版本 |
老旧盒子的芯片可能只支持 H.264 硬解，强行软解 H.265 会非常卡。
六、用电脑辅助排查：命令与脚本
以下命令在与手机、电视同一 Wi-Fi的电脑上执行。
6.1 基础连通性：ping 与 arp
# 查看本机 IP 和网段ipconfig# Windowsifconfig/ipaddr# macOS / Linux# ping 电视（IP 可在电视网络设置或路由器后台查到）ping192.168.1.23# 查看 ARP 表，确认能否拿到电视的 MAC 地址arp-a能拿到 MAC 但 ping 不通，可能是电视禁 ping，不能直接判定为隔离；ARP 表里也拿不到，才更像是二层隔离或不在同一网段。
6.2 用 Python 发送 SSDP M-SEARCH
importsocket MSEARCH=("M-SEARCH * HTTP/1.1\r\n""HOST: 239.255.255.250:1900\r\n"'MAN: "ssdp:discover"\r\n'"MX: 3\r\n""ST: urn:schemas-upnp-org:device:MediaRenderer:1\r\n""\r\n")sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM,socket.IPPROTO_UDP)sock.setsockopt(socket.IPPROTO_IP,socket.IP_MULTICAST_TTL,2)sock.settimeout(5)sock.sendto(MSEARCH.encode(),("239.255.255.250",1900))found=set()try:whileTrue:data,addr=sock.recvfrom(65507)text=data.decode(errors="ignore")location=next((l.split(":",1)[1].strip()forlintext.split("\r\n")ifl.lower().startswith("location:")),"")if(addr[0],location)notinfound:found.add((addr[0],location))print(f"{addr[0]:<16}{location}")exceptsocket.timeout:passprint(f"共发现{len(found)}个 MediaRenderer")- 搜到电视：说明组播和单播都通，问题在手机端（App 权限、VPN、省电）；
- 搜不到：把
ST改成ssdp:all再试；仍然没有，就回到第三节排查网络； - 能搜到但访问
LOCATION失败：用curl访问该地址，检查电视端服务是否存活。
curl-vhttp://192.168.1.23:49152/description.xml# 以实际 LOCATION 为准多网卡电脑（同时有有线、虚拟机网卡、VPN）可能从错误的网卡发出组播，测试前先断开其他网卡，或者在 socket 上绑定 Wi-Fi 网卡的 IP。
6.3 Linux 下用 gssdp 与 avahi 工具
# Debian/Ubuntusudoaptinstallgupnp-tools avahi-utils# SSDP 发现（图形界面）gssdp-device-sniffer# 浏览全部 mDNS 服务并解析地址avahi-browse-art# 只看 AirPlay 设备avahi-browse-rt_airplay._tcpmacOS 自带 Bonjour 工具：
dns-sd-B_airplay._tcp local.6.4 抓包确认报文是否到达
# SSDPsudotcpdump-ien0-nudp port1900# mDNSsudotcpdump-ien0-nudp port5353网卡名按实际情况替换（Linux 常见为wlan0）。如果能看到自己发出的 M-SEARCH，却始终看不到电视的 NOTIFY 或回复，基本可以确认组播在路由器上被拦了。
七、分场景快速定位
| 现象 | 优先怀疑 | 第一步动作 |
|---|---|---|
| 一直搜不到，电脑也 ping 不通电视 | AP 隔离、访客网络、不同网段 | 核对两边 IP 网段，关闭 AP 隔离 |
| 能 ping 通但搜不到 | 组播过滤、IGMP Snooping | 运行 SSDP 脚本/抓包，调整组播设置 |
| 开机能搜到，一会儿就消失 | IGMP Snooping、电视后台被杀 | 关闭清理/省电，测试组播设置 |
| 公司、酒店网络都不行 | 网络策略隔离 | 换成手机热点测试，或改用 Miracast |
| 能连上，本地视频播放失败 | 手机省电限制、防火墙 | 关闭省电模式和 VPN |
| 在线视频卡顿 | 电视网速、片源 | 电视接网线，测电视网速 |
| 镜像卡顿、延迟高 | 空口拥挤、信道干扰 | 切 5G，换信道，降低清晰度 |
| 有声无画或黑屏 | 编码不兼容 | 换 H.264 / 1080p 片源 |
八、最终排查清单
按顺序逐项检查，大部分问题在前几步就能定位：
- 手机和电视连的是同一个 Wi-Fi 的主网络，不是访客网络
- 两台设备的 IP 在同一网段，子网掩码一致
- 家里没有处于"路由模式"的二级路由器，中继或 Mesh 是桥接模式
- 路由器已关闭 AP 隔离 / 客户端隔离
- 尝试切换 IGMP Snooping、组播转单播等设置并对比效果
- 手机已关闭 VPN、代理、加速器和省电模式
- 电视端接收应用在前台，已加入自启动/后台白名单，关闭了待机断网
- 电脑能 ping 通电视，
arp -a能看到电视的 MAC - SSDP 脚本或
avahi-browse能发现电视 - Windows 接收端的网络类型是"专用网络"，防火墙已放行
- 镜像时双方都在 5G 频段，信道不拥挤，电视尽量走有线
- 片源编码是电视支持的格式（不确定时用 H.264、1080p 测试）
- 用手机热点做对照测试：热点下正常，说明问题在家里路由器
结语
投屏故障看起来五花八门，但按"发现 → 连接 → 传输"分层，再配合 ping、arp、SSDP/mDNS 脚本和抓包，基本都能找到具体原因。最常见的根因集中在 AP 隔离、跨网段和组播过滤这三类，排查时优先看这几项。文中的 SSDP 脚本对任何支持 DLNA 的接收端都适用，在电视上装一个支持 DLNA 的接收端，就可以用它来验证发现流程是否正常。
