三类痛点：能连上不等于能扛住并行上传
痛点 1：CI 矩阵一展开就“神秘断线”。单测与打包阶段各起一个上传步骤，短时间内建立多路 SSH/SFTP；若服务端的并发会话或半开连接上限偏紧，后到的 Job 会被拒绝或早期连接被回收，日志里往往只写 “connection reset” 或 “broken pipe”，容易误判为网络闪断。
痛点 2：交互式 SFTP 与自动化 rsync 抢同一预算。同事用大文件拖拽上传的同时，流水线在做增量同步，两者都走 SSH 子系统，却很少有人把它们放进同一张“连接与带宽”表里；结果是人工操作卡顿、自动化重试飙升，目录权限策略再完美也挡不住连接层抖动。
痛点 3：中间设备静默掐空闲连接。公司出口、云安全组或运营商 NAT 对“长时间空闲的 TCP”有 300~600 秒级别的清理；若传输大文件中间出现读盘停顿，连接在应用层仍“看似活着”，实际上已被中间盒摘掉。没有 keepalive 与分段校验时，只能依赖端到端重传，发布时间窗被白白拉长。
2026 年先选模型：四类上传架构怎么取舍
在动配置前，先用业务语言定模型。单会话串行适合极小团队与低频发布：实现简单，但吞吐最差。有限并发给 CI 明确上限（例如全局 2~4 条活跃 SSH），配合队列，通常是最划算的平衡。队列化上传把“谁先传”交给调度器（单独 runner 或集中代理），前端只投递任务，适合多产品线抢同一 Mac。分账号/分目录隔离把不同团队映射到不同 chroot 或前缀，结合 per-user 连接配额，能把故障面切开；与权限与审计一文中的最小权限思路一致。
若你已经在做暂存目录 + 软链切换，请把“发布瞬间”与“持续同步窗口”分开预算：原子切换只需要短窗口的高可靠连接，而日常同步可以更低并发、更长周期。
决策矩阵：团队规模、产物体积与实时性
下表用于评审对齐；阈值请按 RTT、磁盘与 CPU 压测。
| 模型 | 最适用 | 主要风险 | 你需要的最小控制面 |
|---|---|---|---|
| 单会话串行 | ≤3 人、日发布次数个位数 | 排队时间长、人工易插队 | 文档化顺序；可选简单锁文件 |
| 有限并发 | 中小团队 + 2~5 条流水线 | 仍需调 MaxSessions 与 Job 并行度 | sshd 上限 + CI max-parallel + 重试退避 |
| 队列化上传 | 多团队、多仓库共用入口 | 调度器单点需监控 | 队列状态页、失败重放、告警 |
| 分账号隔离 | 外包/多事业部同机 | 账号与密钥管理成本 | 分 chroot、审计日志、密钥轮换 |
五步落地：从 sshd 到 CI 并发度
运维按序执行；OpenSSH 系，改 sshd_config 后滚动重启并留存变更前后 sshd -T 输出。
- 归档 sshd -T 里 maxsessions/maxstartups/clientalive 生效值。
- 调 MaxSessions/MaxStartups/ClientAlive，重启 sshd 后跑 sshd -T。
- CI/本机 ssh 写 ServerAlive*，可短时 ControlPersist。
- 限制 matrix max-parallel 或上传互斥/队列。
- 日报记活跃 SSH 数、errno、吞吐。
# 1) 先看清当前生效上限（示例）
sshd -T | egrep 'maxsessions|maxstartups|clientalive'
# 2) 服务端 keepalive 基线（按合规要求调整；示例值需评审）
# /etc/ssh/sshd_config 片段
# MaxSessions 10
# MaxStartups 10:30:100
# ClientAliveInterval 60
# ClientAliveCountMax 3
# 3) 客户端 ~/.ssh/config 片段（CI 机器同样适用）
Host your-remote-mac
ServerAliveInterval 30
ServerAliveCountMax 6
ControlMaster auto
ControlPersist 300
# 4) GitHub Actions 思路：限制矩阵并行（示意）
# strategy:
# max-parallel: 2
# 5) rsync over SSH 与 SFTP 共用预算时，显式限制并发 i/o
# ionice/nice 或分时段窗口，避免与交互会话互抢磁盘
图形化 SFTP 客户端请在高级选项开启等效 keep alive；详见Mac 客户端与 CI 集成指南。
可引用数字：超时、连接与重试基线
无专门广域网优化时，可把客户端 ServerAliveInterval约 30 秒、服务端 ClientAliveInterval约 60 秒，以穿过多数防火墙静默窗口。MaxSessions常见默认值为 10，但若每台 Mac 上还跑着远程桌面、同步与 Agent，请为系统与其他服务预留余量，不要盲目拉满。
CI 重试建议采用指数退避：首次失败后等待 15~30 秒，第二次 60 秒，并记录断开时是否伴随 TLS/SSH 握手失败，以区分“配额问题”与“路径错误”。单次上传超 5 GiB 宜分片或断点工具；一致性靠暂存+软链，勿只加长超时。
FAQ、总结与为何用托管远程 Mac 做隔离
- 并行 Job 一多就断，一定是服务器坏了吗？优先对照 MaxSessions/MaxStartups、防火墙空闲超时与是否缺少 keepalive。
- SFTP 和 rsync 会抢资源吗？会，它们共享 SSH 与会话表；请统一并发预算。
- 与原子发布的关系？原子发布管一致性，本文管连接稳定性；两者一起设计才有可预期的发布窗。
小结：有限并发 + keepalive 可消多数「无故断线」。局限：笔记本当构建机易受睡眠与手改 sshd 影响。SFTPMAC：托管远程 Mac 与目录隔离便于固定配额与在线时长。
只加带宽能解决问题吗？
带宽只提高上限；会话数、磁盘与单连接队列仍可能先饱和。
Mac 与 Linux 的 sshd 默认值要分别核对吗？
要；以实际机器上 sshd -T 输出为准。
若你希望减少“多人共机”导致的连接争抢与会话抖动，在固定 Apple 环境里用目录隔离落地上传模型，可了解 SFTPMAC 远程 Mac 套餐与节点选择。