Rsync不能排查丢包，但可作为现象触发器辅助诊断：一、通过传输卡顿、重试、连接重置等异常反推网络问题；二、结合ping、ss、/proc/net/snmp、nc等工具交叉验证真实丢包；三、排除权限、SSH配置、超时等非网络因素干扰。
Rsync 本身不是网络丢包排查工具，它不捕获、不统计、也不暴露底层网络丢包。它是一个文件同步工具，运行在应用层（基于 SSH 或 rsync daemon），依赖下层 TCP/IP 栈传输数据。所以严格来说：你不能用 rsync “排查丢包”，但你可以用它作为现象触发器和辅助验证手段，结合其他系统级工具定位丢包是否影响到实际业务传输。
下面分三类说明如何合理利用 rsync 辅助诊断：
一、用 rsync 行为异常反推网络传输问题
当 rsync 出现以下典型表现时，可能暗示链路存在丢包或不稳定：
- 传输中途卡住几秒后重传（
rsync: connection unexpectedly closed、error in rsync protocol data stream） - 反复重试相同 chunk（尤其在
-P显示进度时出现“retrying”或进度条反复回退） -
rsync: read error: Connection reset by peer或Broken pipe频发 - 启用
--partial --progress后，大文件传输总在固定偏移处失败（如每次都在 128MB 附近断开）
这些不是 rsync 的 bug，而是 TCP 层因丢包/乱序/超时触发重传或连接终止后的外在表现。
二、配合底层工具做交叉验证
仅看 rsync 报错没用，关键要快速确认是「真丢包」还是「假故障」：
-
✅ 先确认基础连通性与端口可达：
ping -c 3 target_ip nc -zv target_ip 22 # 确保 SSH 端口通（rsync over SSH 默认走 22）
-
✅ 检查传输过程中是否有 TCP 重传激增（真实丢包证据）：
在 rsync 运行时，另起终端执行：ss -i | grep :22 # 查看当前 SSH 连接的 retrans、rto、rtt 值 # 或更直接： cat /proc/net/snmp | grep -A1 Tcp | tail -1 | awk '{print $12}' # 查看 TcpRetransSegs 总数是否突增 ✅ 对比纯 TCP 传输行为（排除 rsync 自身逻辑干扰）：
用dd if=/dev/zero bs=1M count=100 | nc target_ip 9999模拟大流量发送，服务端nc -l 9999 > /dev/null，观察是否同样中断或速率骤降。若 nc 也失败，基本锁定网络层问题。
三、规避 rsync 误判：区分丢包与配置/权限问题
很多“像丢包”的失败其实与网络无关：
- 目标目录无写权限 → rsync 报
Permission denied (13)，不是丢包 - SSH 密钥过期或 agent 未加载 →
No authentication methods available，连接根本建不起来 -
rsync服务端未运行（daemon 模式）且未走 SSH → 直接Connection refused - 使用
-e "ssh -o ConnectTimeout=5"却遇高延迟链路 → 超时被误认为丢包
建议始终加 -v --stats 运行一次，看最后输出的 sent / received 字节数、bytes/sec 和 total size 是否匹配，再判断是传输中断还是校验失败。
不复杂但容易忽略。
