Hey there, let's work through your Chromecast detection and multicast issues together—this is a common pain point, but we can break it down step by step.

为什么组播请求会中断？ #

Based on your setup details, here are the most likely culprits:

• IGMP配置异常（Archer C80路由器）: 虽然你已经开启了IGMP snooping和代理，但这类设置偶尔会出现小问题。比如snooping的组播组老化时间过短，导致组播会话被过早清理；或者代理没有正确转发Chromecast依赖的SSDP发现协议流量。另外2.4GHz频段本身干扰极强，周围的其他路由器、IoT设备都可能导致组播包丢失，这也是昨天有包今天完全消失的可能原因。
• Windows侧网络适配器设置: 即使防火墙已经关闭，笔记本的WiFi适配器可能默认禁用了组播功能。你可以这样检查：打开「网络连接」→ 右键当前WiFi适配器→「属性」→「Internet Protocol Version 4 (TCP/IPv4)」→「高级」→「组播」标签，确保「启用组播」已勾选，并且IGMP版本选择v2（Chromecast通常使用这个版本）。另外，Windows的投屏相关服务可能崩溃了，按下Win+R输入services.msc打开服务列表，检查「Google Cast Service」或「Windows Connect Now - Config Registrar」是否处于运行状态，且启动类型为自动。
• 路由器组播过滤规则: 有些路由器会默认静默拦截特定组播地址，即使开启了IGMP功能也不例外。Chromecast依赖SSDP协议的组播地址239.255.255.250和UDP端口1900，你可以去Archer C80的设置里确认是否有规则拦截这个地址或端口。
• 隐性网络不匹配: 即使你认为设备都在2.4GHz网络，也最好再确认一遍！如果路由器的2.4GHz和5GHz用了相同的SSID，笔记本可能自动切换到了5GHz而你没察觉。分别查看笔记本的WiFi属性和电视的网络设置，确保两者在同一个子网和频段。

是否需要添加路由规则？ #

简短回答：大概率不需要，除非其他所有修复都无效。
Chromecast的设备发现依赖子网内的组播通信，同一网络内的设备本来就不需要额外路由规则。但如果路由器的IGMP代理配置错误，无法正确转发子网内的组播流量，你可以尝试添加一条允许239.255.255.250（UDP 1900）在笔记本和电视IP段之间通行的规则。不过这应该是最后一步，先优先排查IGMP和Windows侧的问题。

快速排查步骤 #

• 全设备重启: 有时候给笔记本、电视、路由器做一次断电重启，就能清除导致组播异常的临时网络缓存。
• 临时关闭IGMP snooping: 在Archer C80的设置里关闭IGMP snooping，看看Wireshark是否能重新捕获组播包。如果snooping没识别到Chromecast的组播组，可能会直接拦截发现流量。
• 优化Wireshark过滤规则: 别只看所有组播流量，直接过滤ssdp或igmp，这样能精准定位Chromecast相关的数据包，更容易判断是笔记本没发送请求，还是请求被拦截了。
• 用Google Home app测试: 在笔记本上安装Google Home官方应用，有时候Windows自带的投屏检测工具存在bug，官方应用的设备发现可靠性更高。

备注：内容来源于stack exchange，提问作者DM7823145