Nearby Connections API长期Mesh网络连接不稳定问题咨询

可能的原因 #

• Mesh路由表/会话老化：主路由器长期运行后，内部Mesh会话或路由表可能堆积失效条目，阻断了设备间本地通信路径，但不影响公网流量（互联网路由逻辑独立）。
• API本地缓存失效：Nearby Connections依赖的网络拓扑缓存（如IP-MAC映射、SSID关联信息）长期未刷新，Mesh接入点的细微状态变化未被感知，重启路由器会强制同步拓扑修复缓存。
• 组播/广播限制触发：路由器的组播风暴防护、广播包阈值机制，可能在长期运行后自动阻断Nearby Connections依赖的组播包，重启后防护规则重置恢复正常。
• ARP缓存异常：即使配置了静态IP和MAC预留，路由器长期运行可能出现ARP映射错误，导致设备间无法直接通信，重启路由器会清空并重建ARP缓存。

Nearby Connections在Mesh网络的已知问题 #

• 官方文档未明确标注，但社区反馈显示，多接入点Mesh环境下，API的设备发现机制（如Wifi Direct、蓝牙扫描）易受漫游切换、信号干扰影响，长期运行后更易出现间歇性失效。
• 部分API版本在长连接场景下存在TCP/UDP会话超时未正确重连的问题，Mesh网络的转发延迟会加剧该问题，导致连接彻底中断，需路由器重启重置网络会话。

排查与解决建议 #

路由器侧操作 #

• 查看路由器系统日志，重点排查组播拦截、ARP缓存异常、Mesh会话超时的记录，定位是否有周期性阻断规则。
• 调整或禁用组播风暴防护、广播包限制功能，观察连接稳定性变化。
• 配置路由器每周自动重启，临时缓解长期运行的状态堆积问题。

应用侧优化 #

• 添加定期拓扑刷新逻辑：每隔3-6小时主动触发Nearby Connections的重新发现流程，强制刷新本地设备列表与网络缓存。
• 实现主动重连机制：当检测到连接断开超过5分钟，主动销毁现有连接实例并重新初始化发现/连接流程，不依赖API自动重连。
• 强制使用Wifi基础设施通信：禁用Nearby Connections的Wifi Direct fallback功能，减少Mesh接入点切换带来的干扰。

网络验证 #

• 使用Wireshark在两端抓包，连接丢失时检查Nearby Connections的发现包（如mDNS）是否被拦截，或设备间通信包是否可达。
• 临时将所有设备切换至同一接入点运行，观察是否仍出现问题，排除多接入点Mesh转发的影响。

内容的提问来源于stack exchange，提问作者hazem