“Connection reset by peer (104)”本质是TCP层RST报文强制断连，需先通过错误代码和日志定位中断环节（SSH静默掉线、服务端主动重置或文件系统限制），再结合ServerAliveInterval保活、--timeout/--partial续传及--no-times等参数精准修复。
rsync 传大文件时卡住或报超时，本质是网络连接或协议层中断，不是单纯“慢”。重点不是等它跑完，而是快速定位断在哪一环。
看错误代码和日志源头
先确认报错是否真为超时：
- 出现 Connection reset by peer (104) 或 rsync error: error in socket IO (code 10)：大概率是 SSH 层断开或服务器主动重置连接
- 报 rsync: connection unexpectedly closed 或 timeout 字样：直接指向超时，需查 --timeout 设置和底层连接稳定性
- 输出中夹杂 Operation not permitted 或 Permission denied：实际是权限/挂载限制导致卡在元数据操作，非网络超时，别被“卡住”误导
加 -vv 并重定向 stderr 查真实线索：
rsync -avv --timeout=600 source/ user@host:/dest/ 2>&1 | head -50
检查 SSH 连接是否“静默掉线”
rsync over SSH 时，90% 的“超时假象”来自 SSH 会话被中间设备（防火墙、NAT、服务器端 sshd）自动断开。
- 在本地 ~/.ssh/config 中为该主机添加保活配置：
Host your-server
ServerAliveInterval 45
ServerAliveCountMax 3 - 或命令行临时启用：
rsync -avz -e "ssh -o ServerAliveInterval=45" source/ user@host:/dest/ - 避免用 -o ConnectTimeout，它只管建连阶段，不解决传输中掉线
调高 rsync 自身超时并启用续传
默认无超时或仅数秒，大文件传输必须显式设值，且配合中断恢复机制：
- 用 --timeout=600（单位秒，建议 5–15 分钟）防短时抖动
- 必加 --partial：中断后保留已传部分，下次不会从头开始
- 如文件极大且易断，再加 --append（追加模式），跳过已校验一致的头部
- 示例完整命令：
rsync -avz --timeout=600 --partial --append source/bigfile.bin user@host:/data/
排除目标端文件系统限制
某些环境（Docker volume、NFS、macOS SMB 挂载）不支持设置时间戳或权限，rsync 会在每个文件末尾卡顿几秒再失败，看起来像“超时”。
- 加 --no-times --no-perms 快速验证：若立刻变快，说明是元数据问题
- 对 NFS 目标，加 --omit-dir-times 避免目录时间戳失败拖慢整体
- 用 --itemize-changes (-i) 查哪类操作失败：
例如 .f……. 表示时间戳没设上，.p……. 表示权限改不了
