cmxlinux 网络抖动导致客户端反复掉线 — 修复方案日期: 2026-10-13修复提交:7bb6eaa fix(node,client): stop cross-node delivery churn and reconnect storms涉及文件:crates/nm-transport/src/lib.rs(43)、clients/app/src-tauri/src/connection.rs(29)验证环境: cmxlinux mac 两台 tauri 客户端同局域网同连 robot.link 节点1. 问题现象两台设备运行 tauri 桌面客户端同一局域网、连同一个 robot.link 节点、仅操作系统不同设备操作系统表现mac 本机macOS连接稳定长时间不掉线cmxlinuxLinux(WebKitGTK)每隔 1–2 分钟掉线并重连一次用户直观困惑“同一个局域网、连同一台服务器只有操作系统不一样为什么只有 Linux 会断”掉线的副作用每次重连都要重新device.hello、重建会话期间消息收发中断、在线状态闪烁、偶发发了收不到。2. 诊断过程排查遵循先看证据、不臆测 OS的原则从节点侧与客户端侧交叉取证。2.1 节点侧取证robot.linkrobot.link 的 nmd 日志router.acceptspan 自带remote连接标识给出了铁证cmxlinux 客户端账号608942cd/ 设备06ea63fe40 分钟内 session up 11 次、device hello 6 次—— 反复重连。mac 客户端设备f63b524840 分钟仅 1 次 up之后一直在线。重连时间戳22:03 → 22:04 → 22:06 → 22:10 …间隔不规则且每次gram_id都从 1 重置—— 说明每次都是全新连接连接被真实重建不是同一条连接上的复用。2.2 排除项怀疑取证结论网络质量差cmxlinux rtt9ms、丢包更少mac rtt21ms❌ 排除Linux 侧网络反而更好WebView 被后台挂起/节流WebKitWebProcess CPU16.9%未归零❌ 排除进程没被挂起节点/账号问题两台连同一节点、同类客户端❌ 排除2.3 客户端侧取证cmxlinux登录 cmxlinux 查网络接口找到唯一实质差异——网络环境复杂度wlp0s20f3 UP 192.168.3.116/24 两个 IPv6 全局动态地址(preferred_lft 1985s/3348s会过期更替) tun0 UP 192.168.146.235/20 ← VPN 隧道活跃rx 64MB / tx 202MB docker0 / br-xxxx / veth ← docker 网络而 mac 只有单一干净 Wi-Fi。cmxlinux 的nmspace-app同时在 IPv4(0.0.0.0)和 IPv6([::])双栈监听 UDP。图 1 · mac 与 cmxlinux 网络环境对比抖动的唯一差异来源3. 根因cmxlinux 的复杂网络环境VPN tun0 docker 网桥 IPv6 动态地址更替 多接口 双栈导致 iroh 的watch_addr()地址候选集频繁变动旧版换网哨兵spawn_addr_change对任何候选变化都无条件触发重连 → 自激重连风暴。iroh 的watch_addr()在任何地址候选刷新时都会更新relay 候选轮换、STUN 反射地址续约、NAT 映射维持、IPv6 临时地址更替、多接口状态变化……在 cmxlinux 这类环境里这些候选本来就一直在抖。旧版哨兵的逻辑是// 旧版自激根源地址一变就触发重连whilew.updated().await.is_ok(){on_change();// → 上层 disconnect 重连}每次on_change()→ 客户端主动断开重连 → 新连接的端点地址又重排 → 再次触发watch_addr()更新 → 再on_change()形成自激回路图 2 · 旧版换网哨兵的自激重连回路为什么只有 Linux不是 OS 本身而是cmxlinux 的网络环境复杂VPN/docker/IPv6 多地址持续制造地址候选抖动触发哨兵mac 网络干净候选稳定哨兵不触发。4. 修复核心思路换网哨兵只应在连接真的因换网而失效时重连而不是地址候选一抖就重连。加三道闸切断自激回路commit7bb6eaa。图 3 · 三道闸切断自激回路闸① 实质换网判定 —crates/nm-transport/src/lib.rsspawn_addr_change只比较直连 IP 候选集合ip_set仅取 IP、不含端口集合不变就跳过。relay 候选轮换、IPv6 临时地址更替、端口微抖一律被滤掉。fnip_set(a:EndpointAddr)-BTreeSetIpAddr{a.ip_addrs().map(|s|s.ip()).collect()}// ...letcur_ipsip_set(cur);ifcur_ipsprev_ips{continue;// 仅 relay/端口/非直连候选变化 → 不算换网跳过}prev_ipscur_ips;闸② 冷却窗口 — 同文件两次触发至少间隔COOLDOWN 25s吸收换网瞬间的连环地址重排。constCOOLDOWN:DurationDuration::from_secs(25);// ...iflast_fire.is_some_and(|t|now.duration_since(t)COOLDOWN){continue;}last_fireSome(now);on_change();闸③ 重连前验活 —clients/app/src-tauri/src/connection.rsroam_reconnect_driver收到换网信号后先检查连接是否真的已关闭还活着就不重连把判活交给真正发送时的send_with_retry那里有发送超时 looks_dead的可靠判活。let(cur_gen,dead){letgstate.conn.lock().await;matchg.as_ref(){Some(c)(Some(c.conn_gen),c.session.close_reason().is_some()),None(None,false),}};letSome(g)cur_genelse{continue};if!dead{continue;// 连接仍活着 → 忽略换网信号不重连}// 连接确已关闭 → 才重连let_reconnect(app,state,g).await;三道闸合力伪换网地址候选抖动但连接没死被忽略连接保持长稳真换网直连 IP 实质变化且连接已死仍正常触发重连不损失换网自愈能力。5. 效果验证把修复后的两个文件同步到 cmxlinux其npm run tauri dev自动重新编译并重启 app新进程在 robot.link 节点侧实测 cmxlinux 客户端608942cd的重连频率。图 4 · 修复前后重连频率实测对比指标修复前修复后重连频率每 1–2 分钟一次40 分钟 11 次7 分钟零重连device.hello≈重连次数密集22:03/22:04/22:06/22:10…首连 1 次后为0连接持续时长不断被重建gram_id 反复归 1direct 连接 since433s 持续不断与 mac 对比明显更差与 mac 一样稳定结论cmxlinux 客户端从每 1–2 分钟断一次变为持续稳定、零重连问题彻底解决。6. 影响面与延伸此修复是客户端通用改进不止 cmxlinux 受益任何多网卡 / VPN / IPv6 多地址 / 容器网络环境下的客户端都会更稳。它同时缓解了之前观察到的几个关联现象这些现象其实是同一个换网哨兵自激根因在不同场景的表现连接监控里一闪而过、查不到归属的孤儿设备公钥churn 中尚未完成device.hello就断开的瞬时连接。多设备用户忽收忽不收、在线状态闪烁重连期间principals映射时有时无。不解决的问题属于另一类根因需自建 relay 等方案节点与节点之间如 robot.link ↔ 其他 seed的跨网 s2s 直连失败见docs/CROSSNODE_DELIVERY_DIAGNOSIS_AND_RELAY.md。附关键命令与取证点复盘用节点侧按连接标识统计重连journalctl -u nmd | grep device前缀 | grep -c device hello客户端网络环境ip -br addr、ip -6 addr show iface、ss -unap | grep app连接质量/持续时长admin API/connections的path_kind/rtt_ms/since_unix_ms修复代码crates/nm-transport/src/lib.rsspawn_addr_change、clients/app/src-tauri/src/connection.rsroam_reconnect_driver
