当集群不只跑 CI，而是工程师远程直接操作 shell时，协作入口要可恢复：跨国抖动下纯 SSH 易冻屏；Mosh 靠状态同步改善观感，却把视线拉到 UDP 与 NAT。🚀
与 rsync 扇出 分流：那条线管产物一致落地；这里管人如何稳态排障。多节点同步见rsync 决策矩阵；网关与 Webhook 见OpenClaw 集群实战；索引见技术博客首页。
一句话：批量与自动化走 SSH；长会话交互排障优先 Mosh。二者都不替代 flock 与目录拓扑上的互斥。共享 DerivedData 或正式产物树时，交互与 CI 必须共用同一套窄门脚本，否则再稳的会话层也会写出裂脑目录。
痛点（交互入口）
- 高丢包时 SSH 输入与编译输出易堆缓冲，体感像死机。
- 企业常只放 TCP；Mosh 缺 UDP 则「能 ssh、不能 mosh」。
- 人手在 shell 里绕开 promote，会与 CI 的 flock 裂脑。
交互场景决策矩阵
| 维度 | SSH | Mosh |
|---|---|---|
| 恢复 | 靠 keepalive/重连，上下文易断 | 冻屏体感更好（非业务互斥） |
| 过墙 | TCP 单路径好审计 | 要 UDP 区间，DPI 更敏感 |
| 边界 | Runner、git+ssh、管道 |
长会话、移动网、跨洋排障 |
落地步骤
- 文档冻结：交互 Mosh、Job SSH。
- 按清单放 TCP22+UDP 区间，办公/热点/VPN 三网各测。
- 装
mosh-server，与 sshd 版本记入 runbook。 - promote 窄门脚本交互与 CI 共用 flock 路径。
- 双会话压测 promote：一持锁另一干净退出可告警。
可引用
- ① Mosh UDP 常用
60000–61000，可收窄并同步客户端。 - ② 窄门：
flock -n /var/tmp/m4-promote.lock bash -c './scripts/promote_artifacts.sh'。 - ③ 锁忙应报「排队」勿报 UNKNOWN。
端口/防火墙清单
贴进安全组与企业出口白名单，并在节点本机防火墙备注「用途+变更单号」。办公 Wi‑Fi、热点、VPN 三路径各验一次，避免「策略已下发、路径未走到」的假阴性。
| 通道 | 协议/端口 | 备注 |
|---|---|---|
| SSH 控制面 | TCP 22（或团队自定义端口） |
密钥轮换、Fail2ban/速率限制仍建议保留；自动化与 scp/git+ssh 共用此路径。 |
| Mosh 数据面 | UDP 60000–61000（默认区间，可服务端收窄） |
需已安装 mosh-server；仅放行 TCP 22 而无对应 UDP 时，表现为「能 SSH、不能 Mosh」。 |
| NAT/回程 | 有状态防火墙允许 established/related | 对称 NAT 与锥型差异影响 UDP；跨国链路把实测丢包、RTT 与 traceroute 摘要写进 runbook，值班换班可读。 |
验收：① 三网各 mosh user@host；② 换网后输入跟手；③ 改 UDP 区间同步客户端。
与构建锁/flock 组合策略
Mosh 不管写冲突；宽进严出：各分支独立工作树编译，只在提升/签章/发布窄门用 flock。
- 锁位：本机 SSD，勿在 SSHFS 长持锁。
- 临界区：只包复制、manifest、通知，勿包整段编译。
- 边界：Mosh 手动仍调同一 promote，禁绕锁。
- 验收：双会话提升，锁忙应干净退出可辨排队。
示例：flock -n /var/tmp/m4-promote.lock bash -c './scripts/promote_artifacts.sh'
FAQ
Mosh 能取代 flock 或 CI 互斥吗？ 不能；它只改善丢包与换 IP 时的终端体感，文件树安全仍靠拓扑与持锁路径。
已放行 TCP 22 仍连不上 Mosh？ 还需 UDP 区间与服务端 mosh-server，并确认回程未被 DPI 丢弃。
自动化 Job 也要全面 Mosh？ 通常不必；非交互批量用 SSH 配 keepalive、重试与超时更易做审计留痕。
运维指引。 端口与 NAT 因环境而异，以发行版文档为准。